The blind people touched the huge elephant and disputed about the question: What this object is? A blind man/woman who touched the elephant's leg thought it is a pillar. Another one touching his ear thought it is a big fan. The third blind man thought it is a pipe because he touched its trunk etc. The blind people argued and argued and could not agree upon a common definition of that object.
The context of that tale is philosophical. However, when we look at SOA definitions we find partial definitions from the viewpoint of Developers, Architects, Analysts, System Administrators and Business people.
Business people may describe SOA as a collection of Business Services and Business Processes.
For Administrators, SOA is an infrastructure mainly Enterprise Service Bus (ESB).
Therefore some SOA initiatives are ESB projects with no additional implementations.
From Developers' perspective SOA could be seen as Web Services or Application Logic accessed from multiple End User Devices or an integration functionality connecting various applications or data sources.
The Architects could refer to SOA as an abstract Enterprise architectural style composed of multiple layers including Services, Interfaces, Processes, Data architecture and Metadata.
The System Analysts may refer to SOA as an application functionality relating to Business user requirements.
Do not assume that all Architects will agree upon a common definition. As example for Architects disagreements upon a definition see Arnon Rotem-Galoz 's blog.
If you think of agreement between non-architects playing the same role (e.g. Developers, Business People etc.), you will surely be disappointed: many Developers definitions will be found as well as many Administrators definitions are available.
Truly, the definition spectrum is narrowed when identical role holders define SOA, but still no consensus exists.
There are many disputes about what SOA is, corresponding to the argument of the blind people about the Elephant's definition.
The results are:
· Multiple definitions and sometimes contradicting definitions
· Partial definitions, which may describe some SOA attributes
· Different kinds of initiatives called SOA, but describing totally different real world implementations.
· Non-SOA implementations classified as SOA. A good example for Non-SOA implementations labeled SOA could be found in my previous post SCS and SOA.
Returning back to the Elephant and the blind people tale, probably no Value could be found for the blind people in any of the definitions: No blind man could use the elephant as fan or as a pillar and a combination of very cooperative elephant; very imaginative blind man/woman and available water source are necessary for using the elephant as an inefficient pipe.
The analogy is not complete: the partial SOA definitions could or could not have real Value for the definer or his organization. For example a developer may develop effectively a useful service using his partial definition. In one hand an architect may create good enterprise architecture or a good data model which may lead to real measured value. On the other hand the incomplete architecture may cause damage.
Even if the incomplete definitions are valuable still an enterprise needs at least someone who is not SOA-blind and can see the "Elephant" and understand the following aspects:
- What an elephant is? - What the Enterprise architectures and architecture elements are and what is the relationships between them (including both business and IT architectures)?
- What are the elephant's capabilities? - Organizational and technological maturity.
- Which discrete tasks could be performed by the elephant? - Services
- Which assignments composed of series of tasks could be performed by the elephant or the elephant together with a human being? - Automated Processes and partially automated Processes including human tasks (e.g. a process of approving and giving a loan which includes some non-automated approval tasks)
- What kind of elephant training is required so he can fulfill the tasks? - Which training is required for employees (including Business people, Managers, Technical IT staff etc.)?
Enterprises with no previous SOA experience are in a way like the blind people in the elephant tale. Usually the group or SOA Competence Center should include experienced consultant who knows what SOA is and could lead or mentor the internal participants at least in its early stages of the SOA initiative.
In summary:
1. Select a practical SOA definition (not a theoretical one which may not applicable for the enterprise)
2. Probably the definition should be adapted for each enterprise.
3. It should be a complete definition including elements related to real measurable value.
4. The perspective required for a complete definition is wide and probably requires cooperation between experienced consultant and internal experts with deep knowledge of the organizational business, organizational culture and technology.
Comments