InformationWeek Analytics: State Of SOA

Reports of SOA's demise have been greatly exaggerated, according to the 270 business technology professionals InformationWeek Analytics surveyed for this report on the state of service-oriented architecture. But that's not to say there isn't trouble in SOA-ville: Just 23% of respondents say that their organizations have deployed a SOA, and a mere 7% of these report that the resulting systems are available for external use. Twenty-nine percent are experimenting or in development, while 31% have no plans. Much-touted business benefits of SOA, such as increased flexibility and business agility, reduced costs, and improved time to market, weren't major factors speeding increased adoption. The percentage of overall software reuse within organizations rose by just 7 points after initiating a SOA project, from 32% to 39%.

SOA governance, tragically, is DOA.

Still, enterprise IT groups rarely turn on a dime, and they don't lightly abandon technology investments and strategic decisions. When asked if their SOA projects have been successful in delivering a positive business impact, respondents overwhelmingly say results were as expected. Both positive and negative extremes ("more successful" and "less successful") rate nearly identical low scores. One interpretation: It's human nature to resist admitting mistakes, so these IT pros are reluctant to cede defeat. But our take--supported by survey results and discussions with a wide range of stakeholders--is that many companies are moving forward with SOA implementations, though a significant number have decided to shift course and take the path of least resistance. In essence, that means building their SOAs on the Web, using Internet-delivered APIs, and swapping in more agile REST-based Web services as a simpler alternative to heavyweight SOAP-based Web services where appropriate. In fact, when asked to indicate their past, present, and estimated future use of SOAP-based Web services vs. REST-based Web services, respondents show a marked drop-off in use of SOAP, from 54% a year ago to a projected 42% in the next 18 months. The number primarily using or considering REST-based Web services is predicted to grow by a proportional amount, from 14% to 24% over the same time frame.

The REST philosophy has simplicity going for it, and when resources get tight, faster and easier usually wins. However, the two styles can complement each other; it doesn't have to be a case of one or the other. A REST-based approach is a natural for data-oriented applications that focus on simple database look-up scenarios. Many apps fit this model, especially on the Web. Another explanation for the increasing popularity of REST is the growing number of rapid prototyping tools, such as Ruby on Rails, that can be used to build these types of apps.

REST isn't the best solution for all Web services, of course. Our advice: Don't be married to one method or the other. To simplify your application development process and make it more accessible to more people, first consider REST for straightforward operations. Choose SOAP only when your requirements demand it, as with applications that require complex data retrieval operations or network independence. Here SOAP is the more viable option.

An example of an IT pro taking this balanced approach is Ernest Mueller, whose company has experienced rapid growth of its internal all-SOAP SOA implementation. Mueller manages the Web systems team at National Instruments, a supplier of measurement and automation products for engineers and scientists. Two years ago, as part of a business/technology alignment effort, Meuller and a multidiscipline Web architecture team identified two major areas in which NI needed consistent, reusable systems.

DIG DEEPER

Close Scrutiny

Governance is the cornerstone of big IT projects--including SOA.

Get our report

>> >All Analytics Reports <<

"The first was application delivery on the Web, for which we constructed a reusable Java-based delivery platform for our applications to use," Mueller says. "The second was initially framed as back-end access for our Web site to transact with our ERP systems and other internal data and functionality repositories. After some research, we decided that a full SOA tier was the solution. We had some internal Web services, but wanted the additional functionality an ESB and BPEL engine would give us."

Based on these needs, the team selected Oracle's SOA Suite as its platform. Mueller says that while NI's SOA project has been slow to define standards and governance--a trend in our poll--the company is happy overall with its SOAP implementation internally. However, the team is looking at REST as NI starts to expose services externally, thanks to what Mueller sees as REST's better ease of use.

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.