Posted on January 9, 2009
I received a couple of wake-up alerts from some friends about the noise that Anne Thomas Manes article “SOA is Dead; Long Live Services” has made. The result of this noise has been: “Since SOA is Dead, what are we going to do next?“.
When better reading the article, though, what I think Anne actually wrote was that the need for a Service Oriented Architecture is here and well alive. What has to be revised is, probably, the hype around the all-powerful-magic-acronym, i.e. SOA.
I think the main point that Anne makes is that SOA has an interest if it is part of a real transformation, that goes beyond the tools or the IT projects or the tools themselves. This seems to be confirmed by the following quote from Anne’s post:
Business people no longer believe that SOA will deliver spectacular benefits…
…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. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.
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 think we experiment this with many of our customers (and, by the way, not only in the domain of SOA….). We are all caught in the spiral of delivering results before we even start working. The ROI is calculated on a quarter-based scale which prevents, so often, from engaging in transformations that could span the next one or two quarters timeframe.
Howard, vice president and service director for Burton Group, expressed last summer a similar concept:
Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said. This is difficult, given that businesses tend to focus on immediate rather than long-term cost savings, and point solutions rather than strategic goals…
..”We can spend a lot of time and energy making all this shared stuff that makes IT more efficient, but it doesn’t solve business problems,” …
..A good SOA project requires leadership from a C-level executive who can spur changes in a company’s culture,…We need to get better at trusting each other as human beings. None of this is really about technology,”
The problem’s not technology: people and processes are at the heart of what’s wrong with SOA as it currently exists in enterprises.
So, the problem comes back to the cultural shift that is required. Anne continues
Although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever…
…SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”
A couple of years ago, I wrote an article, “Two Faces of the same coin”, in which I started to develop the concept that the “Process Factor” is actually at the heart of the SOA game. What I think is that the difficulty to push a BPM-based approach resides in the lack of this cultural shift, which manifests itself in the difficulty of an organization to put itself under discussion and to reconsider the way in which internal power is distributed. One of the evidences of this is that it is easier to push for a “messaging-based” integration instead than a “BPM-based” integration. The reason, in my opinion, is that when a “messaging-based” approach is pushed, no change in the internal power distribution is required. On the other hand, a BPM approach implies that someone clearly identifies a process and that someone is clearly appointed to “manage such process”. Even in an “undocumented process” already exists in the organization, the very fact that it is “formally defined” scrambles the power positions. And this is something that people do not accept very openly.
In this sense, I agree with what Anne wrote. The tools or the projects (especially if they are big) by themselves are not able to promote the change that is required. If SOA means flexibility, it needs to go hand-in-hand with a flexible organization, one that is willing to adapt.