SOA seems to be going through a cooling phase. While there is broad opposition to declaring it dead, there is also a general feeling that SOA has not delivered on its promise. With spotlight moving to other emerging technologies, an expert recently said the conversation had shifted to Cloud from SOA. ThoughtWorks, a noted Agile software development company, has always advocated a light-weight, incremental approach to SOA. Business Technology spoke to Sriram Narayan on the road traveled by SOA so far and how it can move ahead.

Sriram Narayan is a technology principal at ThoughtWorks. Over the course of eleven years in the IT industry, he has helped a few organizations re-factor their architectures towards an SOA. He maintains a website at http://sriramnarayan.com/

Businesses seem to have become lukewarm to SOA. Why?

SOA projects have been unfortunately identified with heavy cost, high risk, long duration and complex efforts, which have a lower rate of success than general software development projects.

SOA projects typically involve different buckets of cost. You put together an in-house enterprise architectural team as part of the governance board. You also need a team to do the actual implementation, which can be either in-house or be outsourced. There is the cost of vendor and product selection. SOA projects are complex as you have different sections of business users as stakeholders. It might be a year before implementation begins.

A typical budget for SOA projects is $10 million dollars to be spent over a two to five year timeframe. After spending so much money and effort you might still face an uncertain outcome. This is not realistic in the present economic environment where IT budgets are being cut. So, SOA has become a dirty word among the executives.

But the principles behind SOA remain sound and no good enterprise architect would ignore them. It is the eco system which has failed as a whole and given SOA a bad name.

Is disappointment with SOA affecting SOA uptake in India?

India is not as mature as markets in USA or Europe, where companies have a long tradition of in-house application development to gain competitive advantage.  They are drawn to SOA, which is seen as a means of furthering competitive advantage via integration. In India, we largely prefer buy over build. A typical IT project would involve implementing packaged software such as ERP or banking product and then customizing it for specific needs of customers. I have not come across any company in India that has used SOA to boost its performance and revenue. 

Even if a customer is interested in building an SOA-enabled IT system, there is a problem with the quality of SOA consultancy available. Many consultants typically have tie-ups with product vendors and interpret SOA as an excuse to push select products than building a system with loosely coupled services.

Indian consumers are just waking up to ideas of integrated customer experience. While this can prod a business towards SOA, Our markets are still nascent in this regard.

For instance, Indian telcos are aggressively outsourcing their functions to different vendors. They usually focus on business SLAs than worry about underlying IT architecture, which is left to the vendors. This may have implications for integration and business/IT alignment. For example, a telco may subject the same customer to separate registrations for its broadband and mobile services. For now, customers do not seem to mind it. But when customers start asking for better services, companies will find that they are constrained by IT.

Is the SOA community introspecting and learning from its experience?

ThoughtWorks has been championing a distinct approach, Guerilla SOA. Avoid big bang approaches and make small investments. You don’t need to start off with a big plan, don’t need an army of developers to do SOA. Just involve a few people, start with a single business process and if results are good move on.

Is this similar to following Agile approach software?

Very much. Agile teams don’t ask for a fully specified scope document. Similarly, a Guerilla SOA project would not start with a blueprint for the complete enterprise. This helps in overcoming many of the pitfalls of traditional approaches to SOA.

In the traditional model, a project starts with 1000 applications within an enterprise and tries to boil it down to 50 services. It would try to define an enterprise-wide canonical data model to enable these services exchange information. The stakeholders of different applications may not agree on the model and the effort becomes long drawn. But you cannot wait forever and in the meanwhile, you call IT vendors to start building services in areas, which you feel have already crystallized. After they develop, you realize what has been developed does not meet the needs of some of the applications. A centralized and orchestrated approach to SOA looks good on paper but often does not work in practice.

Instead, we advocate that you start off with a small team. Identify a candidate business process or convert one monolith application into a couple of services. Don’t ask for big funding and you don’t really need an ESB at this point. Your requirements may be as simple as a web server. If you succeed, move to a neighboring process, factoring in the learning. If things go wrong, roll back. As you grow, try to develop standards.

A practical and a small-scale approach to SOA has a better chance of succeeding than a big bang approach.