Greek Mythology and Challenge of introducing SOA in an organization
I am writing another blog entry on SOA knowing very well the risk of triggering a yawn and ‘not again’ response from readers. In terms of sheer volume of debates and opinions generated, SOA will undoubtedly qualify as the most productive IT topics of recent times. However, the same can not be said about the true impact it had on the IT and business. Moving away from ‘Is SOA good or for real?’ debate, I wanted to touch upon the topic of how to deploy SOA for creating tangible benefits for organization. Offcourse I assume that debate around ‘Is SOA for real?’ has been settled (in favour of SOA. Now you know on which side of divide I belong to).
Once the initial debate on SOA among architect community in organization is over and decision makers decide to do something with it, the debate moves from ‘What’ to ‘How? More often than not, the first step undertaken by IT organizations is ‘SOA platform evaluation and establishment’. In my experience, this approach though fitting the logical pattern of establishing a platform capability first lacks effectiveness on two counts. First, the tangible business benefits of establishing SOA platform are not visible immediately and any attempt to demonstrate value invariably leads to maze of technical and architecture jargon. Second, the participation and engagement from business is almost always missing.
I have myself faced the challenge of explaining the benefits of SOA platform establishment to business users and the response almost always draws blank. Promises of Improved modularity of software, increased reusable potential, faster application development time, reduced maintenance effort etc. always evoke the response of ‘So what?’. Is there is a direct impact on my business? Will my new product introduction, sales revenues, profitability or channel response improve? If not, is this another expensive toy IT geeks have got for their fun?
Recently, I witnessed a painful phase in SOA platform establishment program for a customer wherein the scope had to be altered in the middle of the program to include tangible benefits to business, else the entire program faced the risk of being scrapped. How can IT decision makers avoid such situations and potential failure of initial attempts of SOA adoption?
An analogy from Greek mythology provides interesting approach to respond to this challenge. The story of ‘Trojan Horse’ from Homer’s Odyssey. ‘Trojan Horse’ was the trick Greeks used to enter the city of Troy during the Trojan war. In the context of SOA introduction, ‘Trojan Horse’ approach will involve deploying SOA principles, platform and patterns in the organization, but with the help of a ‘Trojan Horse’, an IT initiative that lends itself well to SOA principles adoption and delivers significant business value at the same time.
In my view, following are some of the attributes that can be considered for selecting such initiative.
Business attributes:
· Improving the performance of processes interfacing with customers or key partner channel
· Improved visibility into key data and processes
· Enabling a new business model for organization
· Addresses key regulatory and governance concerns
Technology attributes:
· Involves multiple applications or system of records on heterogeneous platforms
· Spans beyond the organizational boundaries to include customer and external partners
· Requires high level of scalability
· Includes IT modernization elements
Careful selection of sponsoring project, considering the above factors can provide a platform for SOA introduction coupled with business benefits. In my experience, initiatives related to Enterprise and partner integration, process integration and automation, process monitoring and reporting, supply chain visibility and executive dashboards are types of solutions that have the potential of being perfect ‘Trojan Horse’ for SOA.
Would like to know how you feel about the challenges related to initial introduction of SOA. Do share your views.
