SOA...Where to start ???

We know, SOA is all about services. With lot of hype around SOA, intiatives/projects started by organizations and leading vendors throwing their products as the perfect solution for SOA, the question remains... Where to start ...

Here is my way of looking at it.....................

We all know, SOA is not about projects, not about products and not about creating webservices... it is about having an architecture style in the enterprise that revolves around business services. Implementing business processes that are nothing but a set of business services coupled loosely to realize a business use-case.

And,my first task is to build/implement business services and then the processes....Hold on...How can I identify these business services??First, identify the key business processes and model them.Most steps and activities would be nothing but business services. Now that you have the list of business services with you along their contracts (schemas- business documents that are exchanged by these services).You can then look at the existing implementations (there can be more than one) in the enterprise/applications that can realize these business services. You may have to wrap some existing implentations or create new implementations of these services. Here we can take the advantage of an ESB for all its features like message transformation, routing, messaging,service mapping etc.

Now that the services are ready for consumption, create a repository/registry to store the metadata about these services (ex. Contracts, Policies etc). You can automate the whole service lifecycle management and the policy enforcement. Some vendors in this area can be of help and now a days some of the ESBs come bundled with these features.
Then create loosely coupled business processes by orchestrating these business services. In my view it is essential but not madatory to have a orchestration engine in place to orchestrate these services.You can add additional capabilities like BAM to provide business visibility and associated agility.

Let us not forget that the basic building block of SOA are services and the better we design these services, the more complete/relevant the SOA is and their reusability will give business the desired agility.It requires an enterprise wide effort rather than projects to realize SOA. As organizations work in a set business units that manage their applications/systems and the way IT projects are funded by these business units, it would be a herculian task to start an enterprise wide SOA intiative. It is easy to have all of them buy to these principles, but the real task lies in making them all follow the same path. But with the SOA road-map, governance model in place and projects understanding and following the basic principles of SOA, may be we can climb half the Everest.

ESB (Product Evaluation), What to look for?

Recently, I visited one of the prospects in the retail industry to discuss about an intiative they were taking up to evaluate ESBs. With ample confusion in the industry about ESB, I assumed that they are looking for an off-the-shelf product/platforms claiming to be ESBs(I do not outrightly reject those claims) that can give them the desired benefits.

With an application landscape that consists of number of stand-alone home grown and packaged applications and predominantly point to point batch interfaces(file based) often developed as and when required by business, clearly there was plenty to look forward in terms of creating an Enterprise SOA?(I always restrict myslef from talking about Enterprise SOA with customers as this is not something which is a mere technolgy thing and can be acheived overnight)

But, having ESB in place, ofcourse helps an enterprise to move towards SOA. But, lets not forget that it is only a small part of the whole story. You can easily end up having a non SOA architecture inspite of having the ESB(s) in place that I would discuss in a later post.


So, coming to the point, what one should you look for in these products during evaluation..

- The architectural fit with existing platforms and technology
- Completeness of the stack and ESB features (ex. routing,transformation,service mapping etc)
- Additional features for SOA (ex.Business Process Management, Business Activity Monitoring and Portal etc)

Note: Mere claim by the vendors would not suffice, you have to look for the support details for their completeness..
- Performance (Some kind of benchmarking..)
- Fault tolerance, Management and Monitoring etc