There is an interesting post by Anne Thomas Maines from Burton Group exclaiming that SOA has gone the way of the Dodo:
Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever.
Of course the part we all want dead is the vague, hand-wavy, SOA hype. Those that bought into proprietary-SOA and its heavy-handed, “big bang” approach lost out and everyone else got sick of fuzzy SOA promises. But behind any hype in the enterprise space you can find good ideas. The fact is that the ideas behind SOA are as important to us (the distributed masses) as Object Orientation was to the development of complex applications. The difference is that OO required that a single developer to think differently, SOA requires a whole organization of people to think differently-
Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.
I believe this is true to a greater extent, but the large vendors have sold this “massive-shift” to companies with a hefty license price tag and endless services engagements. The fact that SOA requires a fundamental change has been the undoing of traditional SOA initiatives. The main hurdle that is often overlooked is the natural human resistance to change. The challenge of SOA is to be able to demonstrate change in a way that is recognizable by the people it affects. It doesn’t mean hooking together an suite of enterprise tools and dropping documents of new processes on peoples desks.
For Service Orientation (lets drop the A shall we?) to succeed it is important to understand the impact of change on the processes and people affected. The technology just helps facilitate this change; it does not provide the complete solution.
The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.
I disagree that “spectacular commitment” is required. If this was so, we’re in real trouble because anyone that’s worked in a large company knows that it is difficult to get commitment on anything. What we have found at MuleSource is companies have a lot more success when they do start small with a view to a grander goal. Small means manageable, it means there are only a few stakeholders and it means many risks are mitigated. Starting small means a team can test the waters, not just with technology but also assess how these changes affect people and processes. When a project is small the number users affect by the change is smaller and easier to obtain feedback and educate. One of the key benefits of Mule being open source is that people can try introducing Service Orientation without the hefty cost of entry.
The other thing we’ve learned is that for Service Orientation to take hold the people affected must be able to recognize the value of the changes they experience. Once you get buy-in from users its much easier to affect further change without hitting their pain threshold. Conversely, the traditional SOA “big bang” approach creates an unmanageable amount of change that is often impossible to correct and the project usually fails.
I’ve seen firsthand the struggles of the SOA approach and fundamentally the organizations that succeed are those that recognize Service Orientation is an evolution not a project. Lets hope the SOA hype died so we can focus on the value of Service Orientation.
