The trigger for this post was a new whitepaper we published on SOA. The paper is far from being just another rehash on this topic – which continues to create controversy. It is the combined work of the three most prolific providers of various ‘standards’ that relate to aspects of SOA and – as is often the case – the result has in the past been more likely to create confusion rather that clarification. It’s the old joke; ‘the nice thing about standards is that there are so many to choose from’.
The paper, entitled ‘Navigating the SOA Open Standards Landscape Around Architecture’ was sponsored by – and combines the work and ‘standards’ – of The Open Group, OASIS and OMG. In addition, it was edited by an IBM employee. It presumably therefore reflects their point of view and a real live rocket scientist (actually an employee of NASA/Jet Propulsion Laboratory!) If you look at the contributors, you will see other well-known players’ involvement including Mats Gejnevall of Capgemini. So I think we can call this a genuine ‘master document’ aimed at bringing a lot of the existing parts together within a very clear common reference model.
I don’t want to go through the document in detail, though I certainly recommend reading it. But I will suggest it might be easier to follow if you read page 16 entitled ‘SOA Core Concepts’ first, to appreciate exactly what the core principles of SOA are held to be, before getting into the details. Here, I want to discuss what the paper doesn’t cover – because it falls outside its remit – which for many is the key question: ‘when should I be using SOA?’
The reason I usually hear is that using SOA is merely a substitute for using an enterprise application integration approach. Yes we can do it with SOA, but in the integration there is so much bespoke work that the claimed capabilities for reuse are actually very difficult to achieve. Funnily enough, I’m often in agreement with this statement, because the actual work being performed really was direct one-to-one application integration. But, if we go back to the white paper (to page 16), it offers the ‘Core Principles of SOA’ and the first generic principle ends with the statement: ‘a paradigm for Business and IT architecture’. This is a key point to grasp.
If you look at the world of information technology, which is built around applications, then architecture is focussed on the computing system element. The job is to understand which, where, and how the various elements will have to be integrated. Yes, there is the business requirement driving this, but the expertise and focus is largely on the technology aspects needed to achieve this. Now, think about the business technology: this new fast-changing front office world, using web 2.0 and ultimately clouds. It’s not the same thing at all. For a start, it’s not based on monolithic state-full applications, but on clusters of ‘services’, meaning small self-contained functions.
If you work your way through the attributes, then pretty well everything about a ‘services’ environment is a reversal of an application environment; try it; state-full v stateless; close coupled v loose coupled; deterministic v non-deterministic, etc. My personal catch-all is to say that applications are first and foremost all about transactional data, whereas services are all about the flexible process and there will be no transactional data involved. This explains the business architecture point; the business managers want to be able to change and vary their front office processes frequently and quickly usually in response to external conditions. Conversely the enterprise architects working in IT must control change, to ensure the stability of the transactional procedures and the all-important enterprise data. Two very different goals and therefore not-surprisingly not always seen together.
The whole issue of using SOA looks very different when driven from building and deploying support for flexible front office activities by using ‘services’ rather than when looked at as a possible way to carry out back office data centric application integration. Indeed, SOA also becomes critical as the mechanism to link the two environments by providing a stable API to existing applications, as well as the environment for the deployment and orchestration of the ‘services’. If you are not using services or providing front office support in this manner, then you probably have a fair argument to say that SOA is not providing any real value to your project.
There is another point to consider too and that’s clouds – by which I mean genuine clouds and not running applications in a highly virtualised computing centre that may, or may not be shared. Adoption of SOA is a very necessary part of moving towards being able to use clouds, a point that Russ Daniels the leader of Cloud Computing at HP and I felt so strongly about, that we wrote a joint white paper called ‘The Cloud and SOA’.
So we may now be at the point when we have had the hype of SOA, been through the trough of disillusionment and are beginning to reach the sensible growth, based on using the technology in the right place for the right benefits. I hope so and have seen some evidence in good quality SOA deployments, but they are also linked to enterprises which are supporting new style front office deployments.