I recently came across two different definitions of service-oriented architecture (SOA):
- SOA is essentially a set of principles used during the design and development of systems that must enable interoperability with other systems. … SOA tends to be a loosely coupled system of functionality exposed over a network (i.e., Internet) that allows users to combine and use the resources exposed. (Info-Tech Research Group)
- SOA is the underlying structure supporting communications between services. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. Each interaction is self-contained and loosely coupled, so that each interaction is independent of any other interaction. (SearchSOA)
And I asked a connection, Grady Booch, if he would share his expert opinion and answer the following question, do these two definitions align, or is one correct or more correct?
Here is his reply:
My take is that these two perspectives are in reasonable harmony. Three things that both of them don’t address, however:
- SOA is more than just message-passing on steroids…and yet, a naive interpretation of the first definition could lead one to conclude that. It would be valuable to describe what SOA is not (it’s not just message-passing).
- The hard part of SOA is reaching the right granularity of service. Too fine-grained and it requires too much work to make the parts fit and leads to misuse, unless you provide patterns of good use. Too coarse and it’s hard to integrate with new, unforeseen uses.
- SOA is not just about web services; one may still have an SOA architecture and use more than heavyweight web services.
On a related note Grady points out that:
Quality and value are two of the forces that shape as well as are emergent from the architecture of a software-intensive system. Interestingly, these factors—quality and value—appear to be consistent with architectural elegance and simplicity. (From a review of Inherent Quality Simplicity)
Here is one of Grady’s presentations (“SOA as an Architectural Pattern: Best Practices in Software Architecture”), and here is the SOA Manifesto (Grady, of course, is one of the noted authors).
Looking forward to reading your comments and opinions in relation to the noted definitions, and in general about SOA. Here also is an interesting job posting involving SOA (Director of Insights), and here a some additional links as food for thought:
- SOA Consortium discussion paper (“Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture”)
- Study on cloud and service oriented architecture for e-government
- TechRepublic SOA white papers & case studies
- SOA migration case studies and lessons learned
My sincere thanks to Grady for his commentary.
Ron Richard, I.S.P, ITCP/IP3P
LinkedIn Profile and Personal Website
- Change, exponential power, enterprise architecture, governance and stakeholder engagement - March 4, 2013
- Take testing activities up a level - February 4, 2013
- Your service-oriented architecture expert opinion - February 4, 2013
Thanks Karl, great to have an expert from France read and comment; and Thanks Regine, great also to have an expert from the UK do the same (Grady of course is US based; my thanks again for his contribution). It would be great if other experts from different parts of the world also commented from various EA, SOA, Cloud, Governance, SLAs, ALM and other perspectives such as “Business Architecture: The Missing Link between Business Strategy and Enterprise Architecture”.
I totally agree with Grady, SOA has elements described in both definitions. SOA is an architect style, a set of principles and a methodology for designing and developing software in the form of inter-operable services. These services are built as software components and have well-defined business functionality which can be reused for different purposes. They are orchestrated through loose coupling.
I tend to agree with G. Booch that the two above definitions are neither compatible nor complete. SOA is a design as well as an implementation pattern. On the design side the difficulty is in fact getting the granularity of service correct, on the implementation side the difficulty historically has been governance and lifecycle management – specifically services that have been “orphaned” by their original implementors/consumers but are still in use by other consumers and duplicate but highly similar services all being carried on the IT Budget of the organization
Cloud Computing somewhat reduces the ALM and governance issues by putting the costs of service continutity and reference management on the vendor. But this brings into necessity much stronger reliance on SLAs (Service Level Agreements)) – something that to date is not yet really automated.