Not Dead Yet
SOA success stories such as National Instruments' notwithstanding, there's a common industry perception that a critical mass of SOAP-based SOA initiatives have failed to deliver their promised benefits and have run out of steam. In response, a range of pundits have weighed in on SOA's future.
At one extreme of sensationalism, Burton Group's Anne Thomas Manes issued a blog post in January declaring, "SOA Is Dead; Long Live Services," and followed up with an open invitation to a wake. A less-dire November report from Gartner found that a growing number of organizations are delaying their SOA adoption plans, and the number of organizations with no plans to adopt SOA has almost tripled, from 6% in 2007 to 16% in 2008. As discussed earlier, the percentage of companies deferring SOA adoption recorded by our survey was even larger.
"The biggest challenge is to show to the business the benefits of using SOA," says Krishna Komanduri, a technical director with brokerage firm Charles Schwab. "But, because of the current economic situation, the business isn't enthusiastic about implementing new technologies when it's hard for them to see and realize the benefits. In many cases, [SOA] requires organizational changes both in the business and technology--which is very difficult."
Part of the problem: The percentage of overall software reuse within organizations was only marginally higher after initiating SOA, with a 32% reuse rate cited before the SOA project versus 39% after. The key for maximizing Web service reuse in an enterprise is good SOA governance. However, good governance is hard to find in many IT shops, especially those with outdated incentive structures that encourage developers to write pages of code rather than reuse existing Web services components.
But far and away the major reason respondents who aren't evaluating or implementing SOA cite for not pursuing the initiative is a lack of a viable business case--43% say it's because SOA initiatives have developed a reputation for overpromising and underdelivering.
We're convinced that one of the main reasons for this is that when SOA started out a few years ago, vendors sold the concept to CIOs and other corporate decision makers as being about specific (and expensive) products like Web services or SOA management products, enterprise service buses, SOA gateways, and hardware acceleration devices for Web services. But SOA is about much more than deploying new technology and building service interfaces to existing applications. It requires significant redesign of an enterprise's application portfolio as well as transformation of the entire business. Because so much of SOA is actually about business practices--not technology--in many cases there's been a push back from units reluctant to change or to invest in an IT infrastructure that may require multiple years to pay back the investment.
Other hurdles identified in our survey by nonadopters: that a SOA initiative would increase rather than reduce IT costs and would amplify rather than simplify complexity of the IT environment (17% and 15%, respectively). Roughly the same percentage say they've had difficulty enlisting executive supporters and evangelists for their SOA efforts.
However, the fact that National Instruments is actively considering both SOAP and REST Web services in its SOA implementation is a strong indicator that there's room for these new initiatives and new architectural principles that have value under the broader service orientation umbrella. Whether SOAs are implemented in REST, SOAP, or a combination of both, we believe that a snowball effect will arise over the coming years: As more Web services can be invoked, more applications will be written to invoke them. With the increased availability of Web services components, application designers will evolve from thinking about application architectures as monolithic, siloed software efforts and move toward the exploitation of configurable, component-based SOAs.
NI's Mueller says some of this is happening already; in fact, he became a victim of his own success when the SOA project team was forced to fight for money and resources from other groups. Meuller explains that when his Web architecture team started work on the SOA project, it became clear that the demand at NI for SOA stretched way past the original audience. Immediately, internal groups that were working on projects requiring heavy interoperability came around and wanted in.
"After about six months of work, we went live in June 2008 with version 1.0 of our internal SOA system," says Mueller. "We've had to take a strong hand in metering uptake to maintain stability."
Mueller says there's been friction over money and resources, since Web marketing paid for the SOA tier and now it's primarily being used by other groups. "Who pays for it and supports it long term is an unresolved question."
That doesn't sound like a dying technology to us.