The trigger for this blog is the publishing of a new white paper on SOA, but its more than just another paper on a topic that still creates controversy over its use, and from that its real value. This paper 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’.
Entitled ‘Navigating the SOA Open Standards Landscape Around Architecture’ http://www.oasis-open.org/committees/download.php/32911/wp_soa_harmonize_d1.pdf the paper is sponsored by, and combines the work, and the various ‘standards’, or ‘definitions’ of The Open Group, www.opengroup.org OASIS, www.oasis-open.org and OMG www.omg.org . In addition it is edited by an IBM employee; presumably it therefore reflects their PoV, and a real live rocket scientist! Sorry could resist it, actually an employee of NASA/Jet Propulsion Laboratory. If you look at the contributors then you will see other well known player’s 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 to you that it might be easier to follow if you read page 16 entitled ‘SOA Core Concepts’ first to get into you mind exactly what the core principles of SOA are held to be before getting into the details. Instead I want to discuss what this document doesn’t cover, because it falls outside its remit and yet for many is the key question; ‘When should I be using SOA?’
The point I usually hear is that using SOA is merely a substitute for using an EAI approach, yes we can do it with SOA, but in the integration there is so much bespoke work that the claimed abilities for reuse are actually very difficult to achieve. Funnily enough I am 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 and 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’ and that’s a really important point to grasp.
If you look at the world of Information Technology, or IT, built round 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 sure there is the business requirement driving this, but the expertise and focus is largely on the technology aspects to achieve this. Now think about the Business Technology, or Bus.Tech, 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 well 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, but 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’ http://www.capgemini.com/resources/thought_leadership/the-cloud-and-soa/
So may be we are now at the point when with SOA we have had the hype, been through the trough of disillusionment and are now beginning to reach the sensible growth based on using the technology in the right place for the right benefits? I hope so and see some evidence to support that view in good quality SOA deployments, but they are also linked to enterprises that are supporting new style front office deployments.
While SOA seems to have been through the hype, now it seems like the Cloud is really emerging as the buzz word in gov’t. I hope we can find real solutions and move through the hype to get really good deployments that can help gov’t move fast, deploy quickly and securely, and solve major problems economically.