OASIS SOA Reference Model - a positive start but limited in scope
On Monday 3rd May, the standards consortium OASIS
announced the formation of a committee to develop a core reference model designed to “guide and foster the creation of specific, service-oriented architectures (SOA)”. When I first read the announcement I was encouraged on a number of fronts. Firstly, the formation of the committee recognises, as our own research shows, that organisations are increasingly confused by the seemingly endemic and varied use of the term SOA in vendor propositions. Secondly, and as a consequence of the first point, the initial membership of the committee includes a variety of users of technology, such as Boeing, General Motors and VISA, in contrast to the vast majority of standards-setting bodies (the Liberty Alliance is a notable and successful exception).
As I dug a little deeper, however, my enthusiasm waned. The absence of the likes of BEA, IBM, Microsoft, Oracle and SAP from the roll call of members is disappointing since these are the vendors that users are likely to turn to first as they embark on their SOA initiatives. They are also, as a result, a potentially valuable source of first-hand experience. I can’t say I am surprised by their absence, given that their insight into SOA best practice is a valuable resource in their pursuit of new business opportunities. I hope, just as we have seen with the Liberty Alliance, that the participation of their customers and prospects will help to bring them to the table.
I was more concerned, however, with the implication of some of the language used in the announcement - “the new OASIS SOA Reference Model (SOA-RM) Technical Committee will promote the continued development of multiple SOAs” and “The reference model … will be an abstract, designed to be used as a tool by software and enterprise architects developing specific SOAs”. It appears that the foundation of the committee is based on the same train of thought which permeates much of the current dialogue surrounding SOA: that SOA is something that you implement. This predominantly development-centric perspective on SOA is, in our opinion, too simplistic and the cause of the much of the confusion which the committee has been established to reduce.
We believe, as we outline in our report
“SOA: handle with care”, that SOA is something that you do not something that you implement. It is an approach through which IT services are managed throughout their lifecycle and delivered in line with business priorities. The development-centric perspective on SOA focuses on the issues faced by software developers in building and integrating web services but this is only part of the story. An SOA initiative must also take account of the IT service perspectives of the other key stakeholders – IT operations and the business groups that control the purse strings – to provide a more complete picture of “service-oriented IT”.
Don’t get me wrong. I remain positive about the SOA-RM and applaud the committee founders for shifting the focus from, some would argue, intangible and highly technical standards specifications to more meaningful advice and guidance. However, the committee needs to extend its scope to consider not only the IT services that automate aspects of business functions and are the primary concern of developers but also the infrastructure services that provide that platform that underpin those services and the lifecycle services that are responsible for the design, implementation, operation and alteration of both business function and infrastructure services.
