SOA initiatives have gathered momentum in the past year with more enterprises either implementing SOA or considering implementing in the near future. The implementations we studied reveal that one of the critical challenges in SOA is designing an effective governance mechanism. A good understanding of governance concepts is essential to implementing and operating a successful SOA. Reliable governance for SOA leads to a manifold increase in an enterprise's ability to achieve the goal of business agility through SOA.

Defining IT Governance
The IT Governance Institute defines IT governance as "a structure of relationships and processes to control the enterprise in order to achieve the enterprise's goals by adding value while balancing risk versus return over IT and its processes." Another definition by Peter Weill describes IT governance as "specifying the framework for decision rights and accountabilities to encourage desirable behavior in the use of IT." The objective of IT governance is to assist enterprises in leveraging IT to achieve business goals, while governance is essentially the structure, the roles, and the responsibilities that help deliver IT services effectively and efficiently. Successful governance mechanisms that help enterprises meet their business goals typically consist of simple and transparent mechanisms. Half of the managers in the top 50 percent of governance performers could explain governance, while fewer than 30 percent of managers could do so among weaker performers (see second reference in the References section)!

Governance Guidelines for SOA
The IT organizations today are dominated by a central IT function. The IT function has a near-unilateral responsibility for governance. However many business units have established in-house IT functions that work in tandem with the central IT function to cater to specialized needs. This bifurcation of roles and responsibilities between in-house and central IT functions is easy since most applications are "owned" by a business unit that controls budget for design, development, and support for specific applications. This is the first point of departure in the service-oriented architecture (SOA) context where multiple business units "own" and "use" the same set of services. This implies that the aggregation of requirements for services now comes from multiple business units while the budgets for design, development, and support for specific applications have to be apportioned among multiple business units. In such a case the delivery of services will necessarily have to come in from a central IT function rather than from in-house IT functions in business units, and the central IT function will enter into service-level agreements (SLA) with multiple business functions for provisioning the same services.

The following are typical scenarios that we have come across in large enterprises that are adopting SOA:

• A large bank where the IT function developed a proof of concept of SOA architecture and was contemplating next steps. The challenges for the bank were: How to obtain a buy-in from business functions on moving to the SOA architecture? What will be an ideal governance mechanism in the steady state with SOA?
• A health insurer was in a legacy modernization program across the enterprise with SOA and introduced a new organization between IT function and business functions to own the services.
• In another large bank's migration to SOA, a business division with senior executive commitment pilots the migration helped get budget commitment for the enterprise SOA initiative.

Challenge of single ownership
Proxy for single ownership that is managed by a new organization layer between central IT and business functions. Establish SOA governance committee with representatives from business units and central IT function.

Challenge of managing multiple owners
Map services to business processes/projects/cost and profit centers to apportion investment and operating costs. Usage-based funding appears elegant but may be arduous to implement enterprise-wide and works best in a high-trust environment. An SOA governance committee/SOA management organization decides on investment and running costs based on previously agreed upon cost-apportionment rules. Prioritization of enhancements and new development is determined yearly/semiannually by the SOA governance committee/SOA management organization.

Challenge of aligning SOA with enterprise IT architecture
SOA needs to be consistent and aligned with enterprise-wide IT architecture policies with a representation from the enterprise architecture group part of the SOA management organization/SOA governance committee. The same team should set IT policies, deliver and maintain SOA infra/development/maintenance, manage vendors, and ensure quality of service (QoS). A significant part of this alignment would be deployment of appropriate IT infrastructures like policy registries, policy repositories, and policy management infrastructures to enable this alignment.

Challenge for small enterprises that cannot afford costly governance mechanisms
Heads of the business units decide on governance mechanism for ownership and funding at periodic meetings, while day-to-day operations reside with IT managers in the function/unit.

These guidelines determine the SOA governance model an enterprise desires to establish based on a bifurcation of demand (to mitigate ownership challenges) and supply (for provisioning enterprise-wide, shareable, standardized services). The governance guidelines are based on the INDIGO (Infosys Design for IT Organization Governance) research program.

Demand and Supply Centers Are the Cornerstones of the Governance Model
One of the key guidelines in INDIGO revolves around bifurcation of responsibilities in services provisioning between demand and supply centers. The rationale for bifurcating the IT function into demand and supply centers is based on the premise that it enhances accountability to the business unit, leverages scale and scope economies for delivering services, and prescribes clear roles and responsibilities, which are illustrated in Figure 1.

The role of the demand center is to advise business units on business-IT alignment in the context of SOA. The analysts in the demand center understand the language of business and bring SOA closer to the business users; additionally, they usually come from the business units (seen as "one of us" by the business users) and have a good appreciation for IT. The demand center focuses on a business case-driven approach to how SOA can increase the effectiveness and efficiency of business processes. Once the demand center has identified the services required by the business users, it passes on the requirements to the supply center that delivers the services.

The aim of the supply center is to deliver best-in-class services that are cost competitive, of high quality, and on time. The supply center has a world-class SOA infrastructure to provide these services to the business users. The SOA infrastructure can be either in-house or, as increasingly is the case, outsourced to best-of-breed IT services vendors. The supply center does not need to be collocated with the demand center, but it can be based in geographies that have the best competitively priced delivery capabilities. The supply center is accountable to business users and this is governed by SLAs.

The supply center is typically the existing central IT function and is headed by the CIO of the enterprise. The supply center is responsible for delivering new SOA-based services, supporting existing systems, and running the SOA infrastructure. The supply center usually needs three divisions that:

• Establish enterprise-wide SOA infrastructure standards and provide associated infrastructure services
• Manage design and delivery teams for providing SOA-based services for business units in collaboration with the respective demand centers
• Perform vendor management, SLA management, quality management, and internal control activities that ensure smooth delivery of services