On Monday, Anne Thomas Manes published SOA is Dead; Long Live Services on her blog at the Burton Group. My last check using Google showed that at least 50 bloggers have referenced her posting. Some have delighted in Anne’s statement that “It’s time to accept reality. SOA fatigue has turned into SOA disillusionment.” This point-of-view is further supported by a presentation Anne gave earlier this year that reported a Burton Group study that showed 50% of SOA projects were a complete failure and another 30 percent were considered not wholly successful in the 20 companies studied. This is pretty dismal stuff.
Paul Krill from Computerworld reported on Anne’s posting in SOA gets an obituary. You need to read to nearly the end of his article to see — as Alex Niehaus correctly points out in his blog — that Anne is really saying that the acronym should be dead, but that services should live on. Anne essentially argues the SOA acronym is tainted and projects using that acronym will have difficulty getting funded. Alex argues, however, that the acronym should not be prematurely abandoned because it represents a concept that is just getting traction in the industry.
Let me try a different angle. We are all assuming Anne has a full view of how SOA is perceived. Presumably her view is informed by the work she does, who she speaks with, and studies done by the Burton Group and others. That would seem pretty complete. (Note, however, the one study quoted above involved only 20 companies.) Nevertheless, her view conflicts with data I have on the interest in SOA. I maintain a Web site that is devoted to Web services, SOA, and related technologies. In December, based on Google Analytics, my Web site had nearly 25,000 unique visitors who viewed over 71,000 pages (and those numbers were down from other months, most likely because of time off for the religious holidays). You should also be aware that my site is not one of the big SOA sites such as SearchSOA.com or ZapThink. I would expect those sites had a lot more traffic. But getting back to my site, the top search term used in December to find the my site was actually the acronym “SOA” and over a quarter of the the query terms used “SOA” or similar phrases. The number of people and how they find my site tells me there is definitely interest in SOA as a term. This is in contrast to the SOA fatigue or disillusionment that Anne sees. Of course, interest does not necessarily lead to projects. Yet, this activity does provide a view that is counter to Anne’s.
So, how should we look at this conflicting information?
On the one hand, there is no reason to doubt that projects fail (as Anne reported). In fact, many IT projects fail whether they involve SOA or not. And the technology used — be it SOA, a database management system, packaged software, etc. — is rightly (and wrongly) blamed for the project failures. Frankly, it is not unheard of to use the technology as a scapegoat when the problem was in the scope of the project, management, changes made during development, or a whole array of other things that can cause projects to fail.
On the other hand, what is SOA really? The underlying technology is pretty simple. It uses a way to connect (be it REST or SOAP) and something to send along the connection (an XML vocabulary). At the end of the connections are things that are called services. Services can range from existing software (with minimal changes) to wholly new or re-developed software. Is the need for IT to connect to internal and external systems/services dead? Of course not. Is there something more universal and standard than SOAP/REST and XML? No. This is why I agree with Anne that services are very much alive.
How you assemble the connections and services constitutes a service-oriented architecture (SOA). This is where it can become a large project. And, generally, large IT projects fail. Anne states that 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.” This also might be a part of the problem Anne is seeing. Massive shifts require culture change. Culture change is really hard to achieve (see the discussion of SOA Rage that occurred last year). If SOA is conflated with massive shifts in operations and culture change in some companies, no wonder the acronym has become tainted in those organizations.
Anne also states that “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 couldn’t disagree with her more. I have always thought that when it comes to introducing technology, it is better to start small, prove the technology in some useful area, and then expand its adoption. Often, incremental shifts work better than massive shifts when it comes to introducing technology (or culture change) into an organization. You might very well eventually end up with the spectacular gains Anne refers to, but you get there incrementally. Little changes are easier to manage than big changes. It is also easier to fund incremental projects in most organizations.
If you truly can’t get funding for a projects that use the acronym SOA at your company, then it is obvious the you shouldn’t use the acronym. Is the SOA acronym dead for the industry? I don’t think so. I agree with Alex Niehaus when he says changing the acronym “unnecessarily confuses large numbers of people who thought they understood what was going on and who had just begun to dip their toes into the SOA water.” So, the title of this posting is a modification of Anne’s title to reflect what I believe is the reality in the industry.
Now is not the time to for our industry to abandon the SOA acronym. It might be very well be the time to scale back expectations for a “massive shift in the way IT operates” and concentrate on some relatively short-term wins in your company to prove the technology.