I plan to break this blog into 3 parts to provide some clarifications, some observations and some personal opinions about the SOA Manifesto. In this blog I want to deal with three specific points in the SOA Manifesto. In the next two blog I will deal with much of the rest of the SOA Manifesto.
The three specific points relate to the following:
"Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.""Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation."
"Business value over technical strategy"
"Verify that services satisfy business requirements and goals."
I have, for a very long time, challenged the wisdom of the term Service Oriented Architecture. If you track back over the last 5-6 years the term SOA has been used and misused almost on a daily basis. Vendors have often hijacked the term claiming that they sell SOA.
The term Service Orientation is the antecedent to SOA. You cannot have anything being a SOA if you didn't do some sort of SO, just as you cannot have an Object Oriented Architecture or implementation of one without practicing OO.
Clearly we can use C++ in an non-OO way. We can use C in a non-OO way, but oddly enough we can also use it in an OO-way. X-Windows was a great exemplar of an OOA that was done by using OO within a C based implementation. If we constrain things and use a classic OO language, like Smalltalk, then by definition you end up with an OOA.
Thus the terms OOA and SOA are types of things not instances. There may be many instances of an OOA and many of a SOA. Therefore we can use the phrase "my implementation of a distributed system is an instance of a SOA", and we can also say that "my implementation was created by applying the principles of SO". Hence SO is something you do and an instance of a SOA is something that you might create through the application of SO principles.
Why is this important? Isn't it obvious? For those that are SO practitioners it is obvious, but we are faced with myth that has dogged the rise of SOA. I have many customers who ask how do I sell SOA? It is not something that you sell because you cannot buy it. So we need clarity and common language so that when we engage with customers we do not add to the confusion but rather remove it and provide clarity. So obvious to us practitioners yes, and important YES, so that we can effectively engage with businessES who have need of business benefits that a SO approach can deliver through Service Enablement to provide an instance of a SOA within a business context.
"Business value over technical strategy"
Providing a business context is all important. In the dot-com boom days many projects were technology led and the business benefits unclear. Most if not all failed as a result. Motherhood and apple pie comes in here. It is common sense that we understand the business value prior to any technical strategy. The technical strategy supports the business value. Technical strategy is there to support the vision, mission and strategic goals that a business sets for itself. The technical and application roadmaps are constructed to do exactly this. The funny thing about "common sense" is that it is not common, and that is why we needed to state this value proposition business value over technical strategy.
"Verify that services satisfy business requirements and goals."
This principle may well seem obvious too. But it has profound consequences. One of the things that SO and SOA instances provide is a clean separation of Service Capability (Contract) from Service Implementation. It matters not if you use WSDL to do this or SOAML or Abstract BPEL. The important thing here is that before a service is constructed (implemented) we can, at worst, manually check that the collection of Service Capabilities match the requirements that gave rise to them. If these requirements are themselves derived from higher level business requirements we can check the derivation. And if the higher level business requirements are derived from business goals we can check their alignment too.
When we do this manually, and most good SOA practitioner do exactly this, we call it SOA governance and we call it Architecture Governance (although governance is actually wider than this). It is part of the alignment process that is done manually.
Given that Service Capabilities can be properly described in a formal and structured way (WSDL , SOAML and Abstract BPEL all do this) and given that we can encode the requirements that give rise to these Service Capabilities - I shall call them Service Requirements - it would make a lot of sense to get computers to check service requirements against service capabilities and automatically show that the "service satisfy business requirements". I'm not suggesting at this point that we can do the "satisfiability" test through different levels of requirements or indeed the business requirements against the business goals - although even this is possible. What I am suggesting is that the immediate requirements that give rise to the Service Capabilities can be automatically checked to show that the Service Capabilities meet the Service Requirements.
This oddly enough is what Testable Architecture is all about and the wider "satisfiability" is what Savara will deliver over time.
