Anand Gopalan's Blog Integration Consortium

I find more and more definitions of SOA being floated out every day , also hundreds of new chapters on SOA Business benefits. I feel selling of SOA is already been done , Every business organization which has not implemented SOA so far, has already realized the need for it. But what they lack is the customized plan to take the SOA Route for its business problem

I feel the need of the hour is not

what is SOA,

what are its business benefits( BAM, Orchestration, Legacy modernization........), architectural selling points ( loose coupling, reusability .....), what is SOA security, SOA Governance ( must have in survival kit ( of its own business:) )of every SOA Vendor.

I feel we can approach the same by defining various levels

Again I am aware of the fact there was already some effort had been put in defining SOA Maturity models, various levels of SOA ( Soa Lite , matured etc).

How this approach will differ is when its comes to customization and a holistic approach involving all users within an organization

SOA Level 0: Involves studying the need for SOA for a specific business organization, defining approaches for new SOA based applications and Migration of existing applications to SOA. There will be SOA Councils set up within organization, who will clear identify SOA entry points for their business apllications, educate the respective teams with the new SOA culture, Governance. At the end of this phase , there should be a blue print to approach the SOA Route.

SOA level 1: This is where we start thinking in terms of implementation of SOA Plan. At the technology level it could be using web services, open standards,BPEL, at the Governance level on basic Policies, contracts that needed to be in place. Again emphasis here is not getting all SOA Ingredients into the implementation, but choosing what makes immediate business sense to embark. For example if there are less critical application being SOA Enabled there may not be need for full fledged BAM or business reporting to be in place.

I shall gather my thoughts in the mean time and try to refine the above post also come up with more levels.

Again my objective here is to arrive at a SOA Implementation plan that is measurable and all business users should be able to validate their SOA phase against a common SOA Implementation Matrix.

SOA level 2: This is where the business reasses its SOA Strategy and see if benefits surpass cost associated with. After which they embark on a much larger scale of SOA implementation plan.

The above discussion points may not give a ready to implement methodology. But the intent being to stir up a thought on how to arrive at an SOA standard which focuses on impementation and be able to measure one's SOA capability at various predefined end points.

I had another interesting conversation today with my colleague today on SOA enablement. Is the term "SOA Enablement " is rightly understood.  Let me try to explore through the popular example SOA Legacy modernization . In most of the vendor whitepapers that discuss on this topic , they comeup with web services wrapper over existing legacy applications and claim that is SOA. Surely it is a step towards SOA, but not exactly the SOA enablement. This is where the overlap that lies today between SOA and its benefits. The above example would have provided the  business with benefits like  reuse of existing assets, no rip and replace, Loose coupling, Increased ROI, but that does not necessarily mean ,they have SOA in place.

For this solution was possible even in EAI days , when web services was just added to its capabilities. But difference being EAI was purely an IT approach. There needed a bridge between business and IT , not just from a solution perspective , but right from analysis phase. That is where SOA came into rescue. There is no new component in SOA which was not there in EAI. Yes there was BPM, there was limited BAM capability. There was still alignment happening through business processes. But was absent was open standards. This is where SOA started gaining pace, in terms of open standards like BPEL,WS* standards,

SOA is the collection of best practices in architecture that has evolved over time in aligning the business goals with IT.

Not to sidetrack from my initial point SOA enablement, this is where I feel a standard for SOA enablement, level of SOA would have helped clear this confusion. if we have level 0 and some one who was doing legacy enablement would have had an oppurtunity to realize that what they achieved is not fully SOA , more work remains to reach industry accepted SOA level.