News Stay informed about the latest enterprise technology news and product updates.

Six ways to fail with your SOA implementation

A service-oriented architecture is one way to make application development more agile, a growing business requirement. Here are the top risks for SOA failure, so you get it right.

The notion of using a service-oriented architecture (SOA) implementation to align internal software development with the needs of a changing business has attracted plenty of detractors in the decade or so since it was hailed as the new solution for IT and business alignment.

More SOA resources
SOA growth and change: TechTarget survey shows SaaS, BPM emerging

Successful SOA means a long process made of small projects
But the struggling economy, paradoxically, might be just the catalyst for giving SOA a serious look, according to experts who follow the field.

As the economy lurches toward 2010, one-step forward, two steps back, CIOs can count on this constant: Their businesses are subject to relentless change. Companies need to adapt their business processes to the marketplace, automating, integrating and innovating those processes if they wish to survive. IT must change along with the business, or risk losing out as the organization's IT provider of choice, given the growing options available through Software as a Service.

A SOA approach that breaks down business silos by identifying, delivering and managing common business functions that can be used and reused by multiple business applications would seem to be more agile than the teetering heaps of self-propelled, isolated applications that describe most enterprise environments today.

A mature SOA implementation, in which developers can compose new applications from sets of reliable services and quickly put up a new business process, is a valuable asset in an economy where IT and business alignment can be one thing one Monday and another by the next.

Companies are reaping value from taking a SOA approach. According to a recent survey from Cambridge, Mass.-based Forrester Research Inc., among the 60% of 80 respondents from Global 2,000 organizations using SOA, 22% said SOA has delivered "most or all of the benefits" they expected.

Forty-one percent of SOA users told Forrester they will expand their use of service-oriented architecture, even though it has delivered less benefit than expected. Similarly, a survey of 168 respondents, where 70% of respondents had a SOA implementation, showed that 38% of those planned to expand it in 2009.

But the lifestyle change from a SOA implementation continues to prove difficult. Another 17% of respondents in the Forrester survey said they will not expand their SOA use until they resolve problems with their current deployments. About 20% said they have reaped little or no benefit and plan to cut back on the use of SOA. The survey showed 15% as not very satisfied or dissatisfied with their SOA results

The technical risks are significant. The three main ones are standards immaturity, inadequate resources and vendor risk, according to Chris Haddad and Anne Thomas Manes, analysts at Midvale, Utah-based Burton Group Inc. The possible consequences of those risks include interoperability problems, nonreusable services, unstable operations and loss of support services. And any of those can cause a SOA implementation to fail.

"Service Oriented Architecture Roadmap: Keeping on Track," a report by Haddad and Thomas Manes, outlines the following six causes of SOA failure:

Lack of leadership: Organizations resist change; therefore, a SOA initiative requires strong leadership with high-level endorsement. Further, the survey showed the No. 1 obstacle to achieving desired results was agreeing on business requirements (59%), which starts with leadership.

Lack of governance: Even with strong leadership and an inspired team, a SOA initiative will fail without equally strong governance. For example, Kelly Emo, SOA product marketing manager at Hewlett-Packard Co., said she recalls the SOA environment of four or five years ago, when enthusiastic developers started throwing services on the enterprise service bus, a platform for realizing a SOA implementation.

"You had this plethora of services that got into production, but nobody knew what they were for, who owned them, what would happen if the service stopped performing at expected levels and duplicate services popped up," Emo said. That is what governance needs to solve.

Establishing a center of excellence can meet both SOA governance and leadership needs. The Forrester respondents who established centers of excellence ranked their centers' leadership and governance roles as a bigger factor in SOA success than their role in providing training on detailed technical skills.

"As architects plan for SOA … they should think of the center of excellence first as a governance body and only second as a training body," said Randy Heffner, an analyst at Forrester.

What is your main objective for SOA?
  • Integrate legacy applications: 33%
  • Implement business process management: 27%
  • Provide better scaling of applications: 23%
  • Reuse code: 17%
  • Source: survey, January 2009 N=97

    Lack of metrics: People who hold the purse strings want evidence that an investment generates a return. Metrics provide the means to measure ROI.

    Conflicting incentives: People do what they are paid to do. IT people who get bonuses for delivering applications as quickly as possible for the lowest possible cost aren't going to spend extra time or money to ensure the application supports SOA principles unless they are incentivized to do so, such as through performance objectives.

    Lack of coordination: A successful SOA initiative demands a coordinated effort to develop consistent design practices. If each development team works in isolation, the teams will be at odds and reuse won't happen.

    A large transportation company Emo worked with, for example, established a small SOA center of excellence run by a couple of enterprise architects well trained in SOA best practices. The architects' first job was to assess the skill sets of the company's development teams, looking for people who could "think broadly" about the standards and requirements demanded by SOA.

    The upshot for the company is a two-tiered group: senior developers who are building out the SOA services, or so-called service owners; and the developers who write the core pieces of code to support the services -- or "good old heads-down software development," Emo said.

    Ineffective software development lifecycle (SDLC) processes: SOA adds stress to the SDLC process, in terms of requirements management, design, testing, configuration and change management. Organizations with lax processes are at greater risk of failure than are those with strong ones.

    Let us know what you think about the story; email: Linda Tucci, Senior News Writer

    Dig Deeper on Enterprise application development, DevOps and software agility

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.