News

A SOA Post Mortem with Anne Thomas Manes

• By John K. Waters
• March 3, 2009

Almost two months have passed since industry analyst Anne Thomas Manes posted her incendiary blog entry, "SOA is Dead; Long Live Services." Penned as a tongue-in-cheek obituary to service oriented architecture, the posting provoked vehement responses, both critical and in support of her position that IT and development organizations need to rethink their service oriented application (SOA) strategies.

 "SOA met its demise on January 1, 2009," Manes wrote, "when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on ‘services.'"

The fires she sparked in the blogosphere are beginning to cool, but Manes is still hot to get the word out to enterprise architects that they need to focus on "more important and practical things than some vague architectural concept like SOA."

"I wasn't talking to the vendors, of course," Manes said in a recent interview. "I was, and am, talking to the end users, the architects who are saying, oh yeah we've got to do this SOA thing. I thought I needed to let them know that if they went before their planning boards with huge proposals for SOA this year, they were going to get cut down. I wanted to set their expectations."

Manes now wants to clarify a mistaken interpretation of her blog. "A lot of people took the meaning of the blog to be, big SOA is dead and little SOA will survive. That's the opposite of what I'm saying."

SOA has, in fact, proved itself at some large organizations, Manes allows, but the success stories are few and far between, because most organizations are simply not willing to make a big enough commitment to SOA. She points to Bechtel, British Telecom and MassMutual as examples of organizations that took the necessary plunge.

"It wasn't until I talked with the guy from BT that I started getting excited about the potential value SOA could provide," Manes says. "But in all of our research last year, talking with people about their SOA initiatives, it wasn't the SOA that had succeeded, but the IT transformation effort. SOA was just one aspect of that transformation."

And that means that even "big SOA" isn't always big enough, Manes says. "SOA needs to be part of a major transformational effort if you want to get the spectacular gains that everyone is talking about," she says. "As I said in the blog, if you want spectacular gains, you have to make a spectacular commitment to change."

Manes says that more than 50 percent of the responses she has received to date to her blog posting have been positive, and some even carried the ball further. Her favorite response came from enterprise architect Mike Kavis, who on his blog offered his own reason for SOA's failure: a lack of attention to architecture.

"I think that's really the secret here," Manes says. "SOA isn't about REST or SOAP or WS services, or ESB, or XML gateways or any of that technology. SOA is about architecture and doing the analysis of your systems to determine what are the right services to build. And then building those services and making sure that the services you deliver actually deliver business value. What I find is that most organizations are simply doing service oriented integration, which means that they are doing integration in the same way they've always done it, at least from an architectural perspective, just using this immensely slow and inefficient middleware to do it."

Manes's observations on the fate of SOA were aimed at end users, but she has also considered the SOA vendors. Her message to them: Don't hype SOA; focus on services.

"This is very hard, I know," Manes says. "Everyone has gone off and created a SOA platform now. For some vendors, the whole focus of their market strategy is around SOA. But the people who hold the purse string are not going to be too receptive when the IT group comes forward and says, we need another six million dollars this year to continue our SOA initiative. But even if it's just one million, you should expect a backlash."

That backlash is the result, Manes says, of promise unfulfilled. Last year, Manes and her Burton Group colleagues embarked on an extensive research effort to find out how companies in the midst of SOA initiatives were faring. "None of these companies, except for the very few success stories I mentioned, have been able to deliver on the promise of SOA, which is cost savings and increased business agility. In fact, in a lot of organizations, agility has been decreased, because they now have more moving parts, but don't have the appropriate management infrastructure in place and coordinated."

Not surprisingly, most of the negative responses to Manes's blog came from vendors, she says. Among that species of blog postings, however, was one from MuleSource CTO and co-founder Ross Mason that bucked the trend.

In response to Manes's assertion that "SOA is not simply a matter of deploying new technology and building service interfaces to existing applications" but something that "requires a massive shift in the way IT operates," Mason wrote:

"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 a suite of enterprise tools and dropping documents of new processes on people's desks."

San Francisco-based MuleSource) is best known as a provider of SOA infrastructure software based on the Mule open-source enterprise service bus (ESB) and integration platform. In his blog back in January he blamed larger vendors for the misgivings of SOA.

"I know it was a response that you might not have expected from a vendor," Mason says now. "But the truth is, the people who failed to deliver on the promise of SOA were the vendors. I've been on the receiving end of vendor promises of SOA, and I founded this company largely in response to that."

The reason that SOA has become almost a dirty word, Mason says, is that too many vendors have picked it up as a marketing tool to sell products. "They've diluted the message for short-term gain," Mason says. "SOA has nothing about product. It has nothing to do with technology, really, though technology is an enabler. But the promise of SOA is founded on sound principles."

In his blog posting, Mason suggests losing the "A" in SOA and focusing on service orientation.

"This is a cultural shift in the way you build software," he explains. "Service orientation is about understanding how to build applications so that, rather than building lots of glue code between apps so that they can talk to each other, you think of applications as services. Where people get tripped up is in defining what a service is."

Although he chides vendors for contributing to the "SOA fatigue" Manes points to in her blog, Mason believes that the analysts must share some of the blame.

"Gartner will throw some new buzzword that sounds interesting and the vendors will jump on it and even retrofit their message to it," he says. "You watch: We'll see the same thing this year around cloud computing. All vendors are jumping all over it, because it's an easy way to differentiate and to show thought leadership, and the vendors just can't help themselves."