Thought Leadership for the Global C-Suite

The VITO Report

Subscribe to The VITO Report : eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get The VITO Report : homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


VITO Report Authors: Elizabeth White, Liz McMillan, Roger Strukhoff, Timothy Fisher, Ernest de Leon

Related Topics: SOA & WOA Magazine, VITO Report

Article

Building Blocks of SOA Governance

Establishing demand and supply centers is a reliable approach for SOA governance

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.

More Stories By Dr. Srinivas Padmanabhuni

Dr. Srinivas Padmanabhuni is a principal researcher with the Web Services Centre of Excellence in SETLabs, Infosys Technologies, and specializes in Web Services, service-oriented architecture, and grid technologies alongside pursuing interests in Semantic Web, intelligent agents, and enterprise architecture. He has authored several papers in international conferences. Dr. Padmanabhuni holds a PhD degree in computing science from University of Alberta, Edmonton, Canada.

More Stories By Sriram Anand

Dr. Sriram Anand is a principal researcher at Infosys Technologies, Bangalore. Prior to joining Infosys he worked in IT consulting as well as product engineering in the US for over 12 years. His interests include enterprise architecture, service-oriented architecture, and legacy integration and software engineering methodologies. Dr. Anand is experienced in designing enterprise architectural strategy for leading U.S. companies in the financial services, retail, and pharmaceutical domains. He holds a Bachelor?s degree from IIT-Madras with a PhD from SUNY-Buffalo, USA.

More Stories By N. Dayasindhu

N. Dayasindhu, PhD, is a senior research associate at the Software Engineering Technology Labs, Infosys Technologies. His research helps IT organizations align better with business functions. He has published in peer-reviewed journals and conferences and has consulted for Fortune 500 enterprises.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.