Methodology for SOA adoption
January 31, 2007
I have found this common question among attendees from the recently concluded MindTree(http://www.mindtree.com) Osmosis tech fest and last year’s Opengroup’s EA conference where Kamran (MindTree CTO) presented case studies on SOA implementation:
I know the “why” of SOA but not sure of the “how”. Is there a methodology?
The often misleading answer to this question is to tie an SOA adoption to a complete Enterprise Architecture (EA) definition exercise. This leads to the following impressions/myths:
- SOA is for large organizations or programmes
- SOA adoption must be a big-bang approach
The truth is : SOA can be adopted just as easily for mid-sized opportunities as it can for large engagements. The difference is in the methodology used.
At MindTree, we have created an approach to SOA adoption. Inputs for this came from a couple of true blue-blooded SOA implementations in the travel industry – one for a large content aggregator that owns a couple of Global Distribution Systems(GDS) for airline industry alike the Sabre and Amadeus of the world, the second is for an organization that is the premier trade organization for the Airline travel industry.
Both these implementations were multi-million dollar initiatives – dont be carried away by the size and lead to one of the myths described above!
In both initiatives, SOA adoption was incremental – this is the beauty of the model adopted.
Lets look at an outline to SOA adoption. It would comprise of:
- Establish drivers for SOA – defines the case for using SOA
- Perform portfolio analysis – establishes choice of technology for SOA implementa-tion, influences build, wrap or retire decisions on business processes.
- Define the architectural goals and the scope of SOA deployment.
- Define technology architecture and choice of tools & frameworks.
- Define roadmap for the SOA components
- Plan for implementation
- Define implementation and reuse governance
Those who have looked at EA frameworks would catch a sense of resemblance with some of the steps defined above. It is a valid observation and in fact leads us to one of the two SOA adoption models i.e a Combined EA and SOA model.
On the other hand, some of the steps might appear too expensive for a mid-sized organization. This leads to a variant in the model and is termed the Basic SOA model.
An outine to the basic model would look like:
- Check for existence of suitably articulated drivers for SOA adoption . Doesnot includethe task of identifying the drivers.
- Define the architectural goals and the scope of SOA deployment – set the expecta-tions that scope is limited to discovery, build and deployment of services only
- Technology and choice of tools & frameworks
- Plan for implementation – of the services and applications on top
How does an organization decide to go with one of the two models? This can be partly answered by the scope of SOA adoption. The scope can be quantified in the maturity of the SOA deployment and the services there-in. Attention given to progressive SOA deployment can ensure that an enterprise can start with one model and move on to a higher and better one over a period of time.
The level of SOA deployment is listed below, in increasing order of sophistication:
- Level 0 – Identify data and behavior to be deployed as services.
- Level 1 – Design, build and expose services.
- Level 2 – Support multiple channels and clients in service invocation.
- Level 3 – Publish, discover and compose services. Also called as Orchestration.
- Level 4 – Secure services & perform metering to determine usage
- Level 5 – Operate and manage the services and associated infrastructure
- Level 6 – Ensure reuse and capture metrics on benefits incurred
The levels are achieved in an iterative manner in most real world deployments as rarely does one identify all the services before attempting to design, build and deploy the first set of services for use by client applications.
More on the methodology and approach along with consulting can be provided on request.