Service-oriented architecture is an attractive vehicle for attaining greater business agility. It has the potential to dramatically improve productivity and increase shareholder value with a comparatively modest (though far from dismissible) incremental investment in information technology.

Applications composed of services allow companies to modify business processes more easily and deliver new, composite software solutions faster and cheaper. But there is a more important element: when successfully managed as a broad architectural initiative, services can chip away the complexity of existing software systems.

The simplification of software systems is critical to business agility because it allows the transfer of resources from costly software maintenance to discretionary projects that will make a bigger difference to a company's future.

When combined with sound principles of governance, and undergirded with a commitment to manage the delivery of "service-as-product," the migration to SOA can streamline an entire software portfolio, enterprise-wide. It fundamentally changes the cost structure of IT.

Unlike other cost-reduction approaches that, for example, shift expenses to another quarter, the adoption of SOA can lead to enduring benefits valued in the hundreds of millions of dollars for large corporations or networks of closely aligned trading partners.

But SOA Is Easier Said Than Done
SOA requires a conscious and careful balance between long-term structural agility and more immediate and localized time-to-market pressures. These concerns have long been at odds within most organizations.

In many respects, the challenges of service-oriented architecture resemble challenges already met under the guise of mainframe or ASP models of computing, EAI, ERP, or earlier architectures that attempted to drive standards throughout IT. Similar challenges surface whenever the needs of multiple constituents must be met, or priorities must be balanced between individual business needs and the common good.

Our mainframe colleagues (and more recently ASP operators) are accustomed to balancing the needs of multiple customers. However, development, production, and life-cycle management tended to be centralized. With SOA, these functions are more often distributed. Every team providing services, regardless of its location or competency level, has an implied obligation to manage its services as "living assets" on which other teams rely. Some do it better than others.

The act of publishing and consuming Web services alone won't make an organization more agile. Without additional effort and new coordinating skills on the part of IT management, SOA will deteriorate into just another incomplete technical strategy, further complicating the software legacy for years to come.

The successful exploitation of a service-oriented architecture requires a level of inter-team collaboration that has very little to do with shared whiteboards and instant messaging. It's all about jointly managing dependencies and objectively trading off one set of interests against another.

Although a service-based architecture results in a looser coupling between components of applications, the architecture also creates new, tighter interdependencies between the organizations that produce, consume, and manage services.

Service consumers must increasingly rely on providers to deliver an acceptable Quality of Service. While Web service management solutions are emerging (just as MSPs did to manage the Internet operations of the '90s), Quality of Service remains difficult to uniformly guarantee. Modern development tools enable virtually any project team or business unit to set up a Web service and register it in UDDI, with no commitment to manage it responsibly for use by other teams, or even a declaration of any intention to maintain it. Management of this exposure is still largely up to central IT.

Compounding that, Web services offer a level of abstraction and interoperability that companies find very attractive for EAI, and the number of systems exposed as services for integration purposes is likely to explode. The danger is that services will be handled as individual touch-points for application integration, outside any unified strategy, thereby increasing complexity.

As a manager in one large telco lamented, "We've had too much enterprise application integration and not enough enterprise integration architecture." Services, if not managed as part of an overall architecture, present similar risks.

Investing in SOA
Implementing SOA is akin to fighting terrorism - it requires a blend of high decentralization in the field; cooperation among loosely coupled agencies; and tight, centralized command.

Executives who are serious about leveraging SOA for business agility must invest accordingly. Not just in Web service technology, but also in organizational solutions that give service providers and consumers the necessary support, allow architecture to exercise its authority, and preserve the autonomy of individual business units to meet profitability goals.

One way to supply this broad coordination is to establish a "service competency center" (SCC). Enterprise architecture is a likely candidate, or perhaps some other high-ranking IT group that reports to the executive team. Once formed, the SCC facilitates the enterprise-spanning collaboration that SOA demands, and documents the resulting business agility (see Figure 1).

 

Consolidate to Save
First and foremost, it is the SCC's responsibility to secure a new baseline of enterprise agility by reducing complexity in existing software systems. A well-defined architecture that supports the organization's strategic goals provides the means. The architecture identifies the core set of services required to execute the strategy.

Service reuse is the primary means of consolidation. Each time one team uses a service provided by another (instead of building from scratch), the savings is two-fold: duplicate development costs - valued anywhere between $10,000 and $10 million - are avoided, and as much (or more) is saved in future maintenance.

The popularity of the waiver process in some companies suggests that architecture has had trouble making similar Total Cost of Ownership reductions stick in the face of individual business imperatives. With services, the focus begins to shift away from battles over physical architecture and platform vendors to negotiations around service management.

The SCC leverages internal architecture and design reviews to put pressure on project teams to use services, but it must provide assurance of ongoing service availability, support, and responsiveness to change requests or project teams will quickly defect.

Managing Corporate Assets
This brings us to the second responsibility of the SCC: to ensure that the supply and ongoing stewardship of core services deliver maximum value to the enterprise at minimum cost over time.

As an extension of Project Portfolio Management, SCC activities may include:

• Anticipating and monitoring demand for services
• Defining the right mix of services to meet demand
• Establishing corporate priorities for service delivery
• Provisioning services from internal or external sources

Business units underwriting the original development of a service are often unprepared for this. Managing a service for other groups incurs new costs, and loyalties are divided. Once a service is delivered, businesses may move on to other projects. Meanwhile, new service consumers with additional requests are left hanging.

Garden-variety IT organizations simply don't have the business knowledge or skill set to manage a service as an asset. The SCC may choose to perform an ownership function, at least temporarily, until service owners can be identified. But this has its drawbacks, too.

The migration to SOA requires policies for service ownership as well as contingency plans for when ownership must shift away from the original service producer. The initial justification for a service should include such plans, or perhaps the service should not be approved for use by other teams. This places the business case for services front and center over the course of their lifetime.

A more commercial appreciation of services as products can smooth the transition to SOA. But this model also involves a shift in how teams measure success.

Weighing the Priorities
Wherever possible, the SCC should help software teams make a successful transition from software developer to service provider. At the highly distributed, free-enterprise end of the SOA spectrum, service producers continue to manage their own business cases for the services they provide.

Not to be underestimated are practices borrowed from the vendor community, such as software product management and marketing communications techniques for defining and releasing services as products and promoting them to potential consumers. This includes requirements management.

As more services are delivered and the service architecture matures, service consumers inevitably develop conflicting requirements for service enhancements. While the SCC should expect service providers to act as commercial entities, serving the greatest consumer needs on a business-priority basis, the SCC should be prepared to resolve debates. Otherwise, consumers will take enhancements into their own hands and fragment the service architecture.

The SCC is uniquely qualified to negotiate between conflicting interests - especially if it can bring quantitative data to light - and relay the priorities of the executive team.

The SCC can ensure that a comprehensive measurement strategy is in place to: