When looking into the topic of Enterprise Architecture it’s a common mistake that it is only about the rational element of change within an organisation. Enterprise culture and the will to change cannot be forgotten in the equation.

The past few weeks we’ve been talking about the maturity of Service-Oriented Architecture and creating Roadmaps in order to become more mature. In all the models that we’ve discussed organizational culture is not part of the measurement.

In fact, a quick google action learned me that most articles on the web are about creating cultural change within an organization using Enterprise Architecture. So, it seems to be a goal, not a means. In my opinion that’s strange. When looking at organizations and the way they are build, the way they are created, culture is one of the main aspect. Because Enterprise Architecture is about building organizations, it should be about culture as well. It has to be.
Any organization has it’s own culture. And this is a good thing. An organization might not want to mature as much as some models make us believe.

For example, why would a young, creative and fast growing department in a company want to mature in a way that they use the same processes as an older and far more formalised department?

In some organisations departemental competition is even part of their culture. Why change this if it’s a typical cultural aspect of a company?

I don’t know how cultural aspect should be embedded within architectural frameworks, but it seems like a good idea. Any thoughts?

The past few weeks we’ve been talking about Service-Oriented Architecture and Maturity. But how do we do assessments to measure the maturity? What models are there that we can use. In a presentation I will talk about two major models that are here today that we can use. A model from The Open Group and one from Oracle.

When talking Service-Oriented Architecture, we all have our specific view on things. This perception means that we can never have a full blown focus on where the complete architecture is headed to. Going from ‘service bus centric development’ to the utopia that’s a context-driven, event based organization. SOA isn’t something we achieve overnight. It isn’t as simple as changing the underlying technology layers into something like the Oracle SOA Suite, it’s an organizational change. Thus this is a large challenge, not only for architecture or applications, but for the entire stack of operations and decisions. It’s time to grow up.

The Open Group Service Integration Maturity Model, OSIMM, helps us with this challenge. In October 2011 The Open Group released version 2 of this model and it offers us a clear insight in how change is made and how the ‘utopia’ of SOA can be achieved. This also gives us insight in how this is such a large transition that it has to be achieved using ‘baby steps’.

Using a maturity model, such as The Open Groups OSIMM, we can plot a path for organizations on how to achieve the next level of enterprise service integration maturity. The levels taken in account, combined with the dimensions in the Maturity Matrix, offer us a model in which we can easily define the next steps to take.

One of the standard assumptions is that IT drives the growth of a SOA. It seems that this is, in practice, true. When we look at the dimensions in the model we learn that Methods, Applications and Architecture are the axes on which the SOA transition go fastest. But we have to take the rest of the dimensions along. Without the support (or the drivers) from the business views we cannot create a valuable and valued environment.

One of the other things we learn from The Open Group’s model OSIMM is that the level of maturity is, even with the large adopters of Service-Oriented Architecture, not complete. There are some organizations that can show us a level 7 maturity on (almost) all dimensions, but not completely enterprise-wide. This model really shows us how Service-Oriented Architecture is an Enterprise Architecture implementation.

Today I hosted a session on the Principles of Service-Oriented Architecture for my colleagues at Capgemini. A very interesting session because everyone had a very clear view on the Oracle SOA Suite and a technical background. What we wanted to do was creating a common view on what a Service-Oriented Architecture is, what the benefits are that can be achieved and what is needed to create a Service-Oriented Architecture.

During this very interactive session we moved from a clearly technology view on the matter (Oracle SOA Suite) to an architectural view slicing from business to technology. And this is where SOA really kicks in, because it’s a philosophy.

Here’s the presentation on SlideShare.

There’s a lot to do about Business Agility in our line of work (I realize I do a large assumption here, but I guess a save one). Software Development is more and more about facilitating change for the business. This is, as I see it, an essential move forward. But when looking at agility, we need to take into account that the platforms we run our software on can be easily changed as well.

When looking at IT-platforms, in my view hardware, Operating System, Database Server and Application Server (and of course anything that comes around it) we tend to think that change comes with choice. The more choice, the more flexibility. Platforms designed for specific tasks and therefore more flexible. However, this is not the right way to look at it.

IT-platforms should be pre-configured, pre-build and so: as much prefab as possible. This makes sure that we can use the platforms for whatever purpose we want. In that way we can easily scale up (and down) if we need to. And it doesn’t matter anymore where our applications are running.

Virtualization is one of the elements that are essential in this equation. Virtualization give us the possibility to run our applications without having to worry about the location where it runs. In that way it offers us just the flexibility we need in order to offer agility.

Hardware also needs to be standardized, multi-purpose but also flexible. This would imply that we get stacks that are able to run all our (virtual) machines. That would probably mean we have to have an overkill of performance, e.g. more CPU, memory etc. than necessarily needed. But hardware is more efficient now that in the past.

The platforms of choice should also be modular. This means that we can always add more power, more storage, more memory for better performance without having to worry about downtime or any of those other boring things.
In the end all that matters is the flexibility that we can offer to the complete organization.

PS: yes. I’m back. After being absent for over four months, I really needed a break for personal reasons, I’m back and ready to roll on more SOA, Agile, BPM, Oracle subjects.

This week is Oracle OpenWorld 2011. Yesterday afternoon I gave my session on incorporating Oracle Application Express within the Oracle SOA Suite. Because of the large amount of questions I got to publish my presentation online, here it is.

When looking at Oracle Application Express we learn that we can use it perfectly for generating User Interfaces on top of datasources. These sources don’t necessarily have to be inside the database. Since APEX 4.0 there are great possibilities to consume web services in a APEX environment, when we use these as our datasources (and even as our Business Logic layer) we can incorporate the power of APEX within the Oracle SOA Suite.

In the presentation I show two great examples on how you can use this in real live. Extending functionality of both Oracle E-Business Suite and Oracle CRM On Demand using the SOA Suite and Application Express. There are a lot more examples to think of.

Since the release of the (first) Oracle Exadata Database Machine in 2009 and the soon followed acquisition of Sun Microsystems in 2010 Oracle is in the Hardware business. Not a bad position to stand in. But sales are not as promised and one of the large complaints about the Exadata (Database) and ExaLogic (Middleware) machines an often heard complaint is that the machines are simply ‘too big’. And it’s probably true. An Exadata machine can hold an extremely large Data Warehouse, but will it effectively run your database applications with economics in mind? But we have to take into account that the Exadata machine offers great flexibility and extra features we would love to see on other database machines.

So now, just a week before Oracle OpenWorld 2011, the answer is here. Oracle now offers us the Oracle Database Appliance. (Sounds as if we’re dealing with fancy kitchen machines, doesn’t it?) It’s a full grown machine that offers flexibility and some of the neat features the Exadata machine offers us. Only, this time it’s smaller. The flexibility mainly lies in the fact that Oracle offers an increasable licensing model with it.

When you purchase the Database Appliance, you can start off as small as 2 cores licensed. And, as your applications grow, either in size or complexity, you can mature toward a full grown 24 processor core machine. Without changing the underlying hardware configurations. So it really can be seen as an investment.

The Oracle Database Appliance in itself (not even looking at the flexibility of the license structure) is quite impressive. Two Oracle Enterprise Linux based Database Servers in one package. Each based on two Intel-Xeon 6-core CPU’s (hence the license model going from 2 times 1 core to 2 times 12 cores) and a stunning 96 Gigabytes of memory. Besides this, the machine contains 12TB (triple-mirrored, so effectively 4TB) of hot-swappable disks of database storage. Plus, the now essential SSD’s for Database redo-log’s and HDD’s for the server OS.

This all sounds pretty good to me. A system that offers a lot, but still can ‘grow’ together with the needs that you have for your database systems. Of course, this is without mentioning the costs of the machine itself. But all in all it looks positive. It just might be what Oracle needs in the Hardware business.

Here is a video of the official release of The Oracle Database Appliance.

We’ve talked about it here before; Agile Software is not the same thing as Agile Software Development. Of course, one of the hottest topics possible these days in Agile Software Development. Recently we even learned that Agile Software Development has become the mainstream development method. But this is not why we develop. It’s just the means to an end.

When looking at Business Agility, or to be more precise Business Software Agility it has nothing to do with scrum or other development methods. It’s about the ability to change, during production and on the long run. This is where new insights (like SOA, BPM, the Cloud, etcetera) come into place.

Looking at the principles of Lean and Agile, it learns us that we should look at value and worth instead of costs. Single processes instead of bulk. Flexibility and change are key words in every lean environment. When we take a look at the principles of Service Oriented Architecture, it has the exact same goals. Software built on those principles offer organizations a framework that can change, easily.

But software build with SOA-tooling and –related technologies is not per se Agile. This is a misunderstanding. And something methodologies like Scrum will not automatically create Agile Business Software. The software has to be designed in a way that it still offers flexibility and therefore is able to change. In other words: when an Service Oriented Architecture is lousy build, despite of the amount of new technology in it, it will not be Agile. Even when the process of coming there is agile.

This does not mean that Agile Software Development is a bad thing. On the contrary, it is one of the most important parts of delivering software that the business actually needs. But we still have to focus on the outcome, not the process coming there.

For coming Oracle OpenWorld, from 2 till 6 October this year, my paper on Oracle Application Express within the Oracle SOA Suite was selected. Two hot Oracle-topics combined into a one hour power session on how to work effectively with two technologies that somewhat collide with each other. But it isn’t such a strange topic, I’ve been talking about it for quite a while now.

When taking an abstract look at Oracle APEX, we see a technology that uses the Oracle Database to generate user interfaces on top of data in a fast manner. It doesn’t really care what the source of the data is. Tables in the database itself, or web services. Using this ‘clean’ look on the technology it is quite possible to combine the powerful features of APEX with the essentials for Service Oriented Architecture embedded in the Oracle SOA Suite.

There are three basic approaches to this. First is using APEX merely as a way to show content that is offered by a web service. Second is building APEX applications on top of the Oracle Database as if we where using Oracle ADF’s Business Components. Simply build screens on top of a database. Use SOA components for everything else. Third is a wider approach, combining method one and two into something completely different. A completely clean web application build using Oracle Application Express that calls and receives answers from web services and BPEL processes.

It is as simple as that. (There is some more to it, but I will tell you about that during oow11…)

Are there any specific parts that you would like to hear about during this session? Some difficulties you want us to tackle? Tell me in the comments! It’s time to build up an awesome session!

A common mistake that, as turns out, really needs to be disrupted: introduction of new technologies will not, I repeat, will not create Business / IT Alignment. Implementation of any new technology driven solution will, in fact, only create a larger gap between two worlds that shouldn’t be disconnected in the first place. For Business and IT Alignment there is only one remedy: communication.

When we take a deeper look into the reasons why we still tend to look at Business and IT as two completely separated worlds, we learn that it simply is a small gap introduced by common misunderstandings. Nothing technology can solve. In fact, this might be the cause of the misery.

It’s commonly mistaken that modern technologies such as BPM implementations and service oriented implementations create business IT alignment. But they won’t. They can assist in creating an environment where there’s larger common ground and help communicate about the wishes and needs organizations actually will help further. But that’s it. We still need to do the hard work.

A while ago I overheard a conversation between two very experienced software architects. They discussed a business case for a SOA implementation. It was Business / IT Alignment. Despite of their experience in the field, they didn’t recognize the pit they where falling into. But that’s not that bad. As long as the problem owner knows this. (If there is one in unaligned business and IT)

But, without being silly, how can technology implementations help us align business and IT processes? It’s easy: some new technologies will offer us a way to communicate. This all started a long while ago with analysis and design techniques and methods. Take ERD’s, UML, IDEF0. But also User Experience Design, Structured Design, SADT. And architecture visions like TOGAF. All developed to make sure end users, product owners, problem owners, developers, designers and everyone else understood each other.

This didn’t exactly happen. There are some things to blame, like development teams not working on the design and never getting in touch with end users. But Business and IT Alignment simply didn’t happen. But now things, can, be a little bit different.

Different approaches to software development, like the largely popular agile software development method Scrum and models that can actually be executed, like the new BPMN 2.0 specification, just might make the difference. Less translation, less interpretation, more communication and more cooperation. 

Sounds like a solution.