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.
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 SearchCIO.com 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 SearchCIO.com 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 SearchCIO.com 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.
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