Defining SOA

Service Oriented Architecture means different things to different folks. To an IT Architect, it means the overall enterprise archtiecture definition and process that enables IT to develop and deploy business capability rapidly. To the LOB-IT liaisons it means the governance, organization and the process for project/program management. For them SOA means defining the various business bulding blocks that could potentially be reused which shall help them reduce cost. And finally for the CIO - SOA is basically the IT Strategy for delivering business capability.

The Architect shall refer to vendor site such as BEA, IBM, Oracle, SAP, Microsoft, etc. for product informatiion and sites such as The Server Side, W3C, JavaSoft, OASIS, etc. for standards or technical information. The LOB-IT and CIO's would typically attend some CIO Forums or subscribe to some very specific journals, articles etc. made specifically for them by vendors or analysts.

Again - everyone is looking at SOA from their point of reference. The IT specific approach shall work to an extent and get good business benefits. However to achieve the entire benefits, SOA has to be the Business Operations Strategy for the enterprise. Ofcourse, someone would then comment that the term Architecture means it is directed toward the IT organization. Ok then - this has been wrongly named - so what? It has the buz, marketing, hype whatever you want to call it - and executives are willing to give it a try (and pull out of it immediately - if they even get a wiff of failure).

Intel has termed this correctly as Services Oriented Enterprise (SOE) and have broken it down into two layers - Services Oriented Infrastructure (servers running on Intel) and Services Oriented Architecture (Business solutions running on SOA Platform). Unlike Intel (who wants to sell more of their chips) I would expect infrastructure to include network, hardware and software that manages and provides the service execution environment (yes! the one very similar to the telecommunication platform). IT (and in a few years business) should be able to change business logic in this run time environment with no or minimal downtime.

To get there - business needs to invest in the infrastructure up front but they won't without understanding the expected benefits. The right (and the only way) to do this is to adopt and Enterprise wide Architecture Framework (or commonly known as a methodology). Starting right from the head of the business operations (COO/President with full knowledge of the CEO and the board) enterprises need to adopt a Framework for doing business. They need to have the same rigor in business, similar to the ones in the IT operations department. This requires both business and IT transformations. In order to do this both business and IT needs to develop or adopt a Framework, which defines their basic principles, objectives as well as define the process on how they plan to implement SOA within their organization. There are two ways of doing this - take time and define a custom one or adopt one that has already been put together. My recommendation would be to adopt frameworks like Zachman or TOGAF (I shall elaborate on this in my later sections). I am currently in the process of reviewing these frameworks and hope to have some comments soon.

One more thing - I also feel strongly that there is a need for IT organizations to create an alliance to provide clarity round SOA. It is important that such an organization be driven by the customers rather than vendors - so that we get products that we really want and not the products that the vendors want to sell us. Feel free to lookup the SOA Alliance web site for additional details.