INDIGO identifies two governance structure models: "embedded" demand center and "floating" demand center models for enterprises adopting SOA, as shown in Figure 2 and Figure 3.

The "embedded" demand center has a clear demarcation of roles, responsibilities, and reporting of both demand and supply centers; however, implementing the structure may be time consuming because most structures today that have a powerful central IT organization with a few large and powerful business units have in-house IT organizations. We believe that the "embedded" demand center model is best suited for those enterprises where business units have good IT systems analysis appreciation and skills (typically found today in industries like hi-tech, CSP, and financial services). The "floating" demand center has a clear demarcation of roles and responsibilities of supply center while the demand center is a separate entity under partial control of both business units and the supply center. This model may be easier to implement since this is not a major shift from the prevalent traditional centralized IT organization structure. Even if this model has an ease of implementation and the roles and responsibilities of the demand center are clear, there may still be some ambiguities in reporting relationships because there is a dual reporting to both the business unit and the supply center. We believe that the "floating" model is ideal when transitioning from traditional to "embedded" model as a transitional phase.

Whichever model is selected by an enterprise, it is important to understand the roles and responsibilities for the demand and supply centers in the various stages in SOA implementation and operations.

Responsibilities in SOA Implementation and Operations
The objectives of SOA governance are to identify the services that business users require and to focus on delivery excellence in provisioning these services. The roles and responsibilities for the demand and supply centers in implementing SOA in an enterprise entail keeping in mind that the twin objectives of governance is met. Figure 4 lists the roles and responsibilities in SOA implementation and operations. The roles and responsibilities mapping is based on the INDIGO premises that:

• Business units along with the demand center have control of how to leverage IT in their business processes
• Business units have trusted partners in the demand center who understand them and can translate business needs into requirements for services
• Supply center can leverage the economies of scale that are provided by aggregating the services demanded by different business units
• Supply center can exclusively focus on providing cost-competitive, high-quality services on time

Implementing SOA
A strategic decision to implement SOA is made after a buy-in from the CXOs based on the recommendations of the business-IT alignment, business process management (BPM) initiatives, and the supply center establishing enterprise standards for SOA. INSOAP (Infosys Service Oriented Analysis/ Adoption Process) is a process to design and realize SOA in order to achieve a better business and IT alignment. Typically, the decision to implement SOA will be in phases, and one such phased implementation that is in line with The Open Group Architecture Framework (TOGAF) is shown in Figure 5 (see the third entry in the References section).

Some of the important phases in implementing SOA based on the INSOAP are:

• As-is and to-be modeling
• Process-to-application mapping and assessment
• Services identification
• Services definition and modeling
• Services realization
• SOA hosting
• Project management
• Governance

The key processes of implementing SOA based on INDIGO are depicted in Figure 6. One of the first steps in implementing SOA is the demand center's mapping the as-is business architecture and process/applications to services mapping. Simultaneously, the supply center maps the as-is technical architecture and application portfolio metadata. Both the demand and supply centers jointly decide on the to-be architecture and SOA solution blueprint for the business units based on a service identification and matching process. The blueprint is the basis for the demand and supply centers definition of the granularity of services, classification and matching of services, and consolidation and rationalization of services. While the demand centers work on the service contracts and the service data model, the supply center works on service realization and hosting. Project management, risk assessment and mitigation, business continuity planning, service governance, and management are jointly performed by the demand and supply centers.

An important facet of implementing SOA using INSOAP is the services identification and matching process as depicted in Figure 7. The demand centers provide use cases associated with the business process. This, along with the applications and databases associated with the business process, is used by the supply center to identify composite and fine-grained services that need to be provisioned. This is the top-down mapping of business process to services. If there are legacy or existing applications in the enterprise, the supply center also performs a bottom-up mining for services from them. The demand and supply centers then match the set of services obtained from both the top-down mapping and bottom-up mining for services to arrive at a set of services that is required by the business units. This is the basis for the consolidation and rationalization of services. The supply center uses the output of the rationalization exercise to develop and realize the service required by the business units. The service realization decision is taken by the supply center based on a modeling of business drivers, pain points, and cost-benefit analysis with inputs from the demand centers. The evaluation of business impact of services realized and nonfunctional requirements implications are jointly performed by the demand and supply centers. The output of the rationalization exercise is also the basis for the supply center to take decisions on whether it will buy or build the services and retiring applications. Once the services are provisioned either in house or through third-party providers, governance mechanisms for operating SOA and supporting the business users need to be in place.

Operating SOA
The key processes of operating SOA based on INDIGO are supporting users using services, SLA, and QoS management, as shown in Figure 8. In SOA support, the supply will be responsible for setting up the infrastructure for technical and functional helpdesks. Usually enterprises follow the ITIL (IT Infrastructure Library) guidelines for managing helpdesk and support operations in the traditional IT applications context. We believe that similar guidelines can be followed in the SOA context too.

While the technical helpdesk and support is a responsibility of the supply center, the functional helpdesk and support is the responsibility of the demand centers. Typically enterprises would like three of four levels of support. The first level is a helpdesk for resolving simple issues, the second and third levels involve a more specialized support group that resolves more complex issues, and the fourth level is for SOA infrastructure and making enhancements to services. Both technical and functional helpdesk and support will leverage workflow tools and database systems that help categorize, resolve, and log escalating requests.

SLA and QoS management is critical to ensure that the users of services in the business units are satisfied with the services. The demand center and the supply center jointly decide on the planning process for provisioning new services. They also establish the processes to manage SLAs that include financial aspects, availability/continuity, QoS, incident resolution, and security aspects of the services provided. If a third-party vendor is providing the service, the supply center also establishes processes for vendor management to ensure QoS as per SLAs. The supply center also publishes processes for configuration, change, and release management that are acceptable to the demand center. A significant part of this might involve the infrastructure to manage SOA policies, using a combination of policy repositories, registries, and policy management infrastructures. Traditionally IT organizations have been leveraging guidelines of BS1500 and ITIL for SLA and QoS management.

Identifying Roles and Balancing Expectations
The reorganization of demand and supply centers can be tricky because traditionally senior executives in business units and the central IT function have different perspectives that are often not in sync with one another. While the business unit wants value from IT, the IT function more often than not focuses on reducing cost of services. Enterprises will need to establish a clear business case for the demand and supply centers and their objectives. Specific roles and responsibilities charting and reporting structures need to be prepared and communicated before attempting the reorganization accompanying a shift to SOA. In large enterprises this can take up to 12 months for the transition.