I recently came across an article titled “SOA is dead, long live services!” It grabbed my attention (in fact, it is subject of a very lively discussion in the blogosphere), and got me thinking about how SOA has come to reach the “trough of disillusionment” stage. I decided to put some thoughts together, a sort of “a posteriori” analysis of my own experiences. So, why do SOA projects fail? We have the usual litany of suspects: market over-hype, vendor “marketecture”, lack of skilled resources, funding, etc. But that would be too easy, maybe even a cop out. Perhaps, some honest introspection is necessary. A closer inspection of the reasons revealed a completely different picture. I put together my own set of reasons for the failures and state of affairs with SOA, and here is what I came up with.
Failure to understand the intent of SOA
There is *still* a serious lack of understanding of what SOA is all about, and how to go about it. For instance, I’m sure my fellow SOA practitioners have heard comments like these: “We have a lot of legacy applications, so we do not do SOA at present, but all new applications are going to be SOA!” Or this little gem: “Our CxO is convinced SOA is the way of the future, that we need to do SOA, so we’re implementing this application using SOA“. Or this one: “We have budget approval for X million US dollars to buy SOA.” SOA is not a new programming language to code an application with. It is not an excuse to procure new hardware or software infrastructure or deploy the latest technology. It is a comprehensive, enterprise-wide design paradigm, which aims to make IT flexible and agile enough to respond to business imperatives. (Design is *still* king: Funny how something’s never change). SOA is a way to think about and arrange your IT portfolio around business needs and imperatives, which in turn allows the business to remain competitive. SOA has to be originated within the business and initiated by the business, albeit in partnership and collaboration with IT. Ultimately, the aim of SOA is to promote business agility and reduce business risk. IT therefore needs to reposition itself to become an enabler and not a hindrance.
Failure to view SOA as an enterprise-wide undertaking
A typical approach which leads to failure is to take a “project” view of SOA, rather than a holistic, business process, “across-the-enterprise” view. Granted it might be easier to fund, administer and govern initiatives by projects, but the unfortunate side effect of the project approach is that the results tend to be “silos” of disparate, disjointed solutions. They frequently do not interoperate, exhibit overlaps, and even worse, do not address the entire problem. The result: one ungodly mess. After all an application or a service by itself might be well designed and implemented, but the real measure of its success is evident and can be quantifiably measured only when it can be used (and reused) in a flexible, fruitful and goal-oriented way.
Failure to ensure Solutions Architecture fit into Enterprise Architectures
One approach to mitigate the risk of ending up with a “stove-pipe” solution portfolio has been to invest in Enterprise Architecture (EA) initiatives. However, the results of such initiatives never usually seem to find their way into Solutions Architectures (SA) or Applications Architectures. TThere seems to be this great disconnect – an impedance mismatch between the strategic EAs and tactical SAs. EA teams (strategic perspective) and SA teams (tactical/operational perspective) are driven by differing imperatives, so they do not communicate with each other. Since they do not effectively collaborate, IT investments are usually hard to map, track and calculate in terms of earned value for the business.
Failure to apply SOA to technology, people and processes
As was alluded to before, one of the major reasons for failure is that SOA efforts are usually bred and incubated within IT departments inside an enterprise (and usually die quiet, unheralded deaths within IT confines, as well). As the name suggests, SOA involves service orientation – a profound mindset and paradigm change. Reorienting a business enterprise as a collection of interoperating services necessarily involves mapping processes – however informal or undocumented they may be – and the human entities (people) who execute and govern these processes. Therefore, unless the processes and the people are heavily involved and invested in service orienting the enterprise, any such efforts are bound to encounter organizational resistance. This inability to overcome organizational inertia is, by and large, the single largest culprit in SOA failures.
Failure by stakeholders to act as effective change agents
SOA is effectively a profound change inducer – an agent of change. Change is diametrically opposite to status quo. Change requires time to be assimilated into the enterprise. The more profound the change, the more time it requires for assimilation. Change of this order of magnitude requires commitment and buy-in by the stakeholders, typically, business leaders and corporate executives. They have the organizational authority to introduce, implement, oversee and manage change. They also have the authority to introduce directional corrections if the initiative goes off-track for some reason. More than anything, the stakeholders should realize that effective change requires a lot of TLC and nurturing. After all, Rome was not built in a day. Instant gratification might be a good thing, but in SOA terms, it also induces myopic thinking, forms unrealistic expectations, and ultimately leads to disappointment and failure.
Conclusion
SOA is hard to visualize and it is complicated to implement. Ensuring successful SOA initiatives requires patience, perseverance and discipline from all players in the enterprise. Never lose sight of the big picture. Have enough personal and organizational fortitude to endure distress caused by temporary setbacks and inconveniences. Be open to change – it is inevitable. Think about the entire application portfolio. Listen to vendors, but draw your own conclusions. Think business services and processes – always. Learn lessons at the operational level (SAs) and apply them at the strategic level (EAs). SOA can actually be a positive, gratifying experience!!
