Although the lack of elaborate governance mechanisms is often seen as the main reason for failures of SOA projects, SOA governance is still very low in maturity. In this paper, we address this drawback by presenting selected elements of a framework that can guide organisations in implementing a governance approach for SOA more successfully. We have reviewed the highly advanced IT governance frameworks Cobit and ITIL and mapped them to the SOA domain. The resulting blueprint for an SOA governance framework was refined based on a detailed literature review, expert interviews and a practical application in a government organisation. The proposed framework stresses the need for business representatives to get involved in SOA decisions and to define benefits ownership for services.
Governance has been seen as one of the key success factors of IT for many years and enterprises currently invest considerable resources into the implementation of IT governance frameworks such as Cobit [1]. In their seminal work, [2] define IT governance as the process of "specifying the decision rights and accountability framework to encourage desirable behaviour in the use of IT." Many enterprises presently face the challenge of developing adequate governance mechanisms for Service-Oriented Architectures (SOAs), which introduce new complexities due to the amount of services to be managed. To date, however, no widely accepted framework for SOA governance has emerged [3]. Given that the lack of a comprehensive governance approach has been cited as the most common reason for failures of post-pilot SOA projects [4], work in this area is highly relevant. While definitions differ considerably, most authors agree on the basic elements a governance framework should address, namely the organisational structure, processes, policies and metrics [5], [6]. To provide a working definition for the rest of this paper, we build on [3] and [7] by specifying: SOA governance focuses on the decisions across the entire service lifecycle to enable organisations to realise the benefits of SOA. It is an approach to exercising control and mitigating risk by establishing organisational structures, processes, policies and metrics suitable to ensure that the SOA is always in line with the organisation's strategies and objectives and complies with laws, regulations and best practices.
For reasons of scope, we concentrate on the organisational aspects in this paper by deriving a set of activities and roles that are required in an SOA context and by proposing their responsibilities along the service lifecycle. The resulting framework can guide organisations in designing or evaluating their own governance structure.
The paper is structured as follows. In section 2, we point to related work and explicate our research approach. Section 3 outlines selected activities along the service lifecycle. Section 4 describes selected roles and the assignment of responsibilities. The paper concludes with summary and further research opportunities in section 5.
The knowledge bases of corporate and IT governance form obvious points of references for research into SOA governance. While from an IT governance perspective, standard works like [2] and well-received frameworks such as Cobit [1] and ITIL [8] are the most prominent examples, the OECD Principles of Corporate Governance are among the most influential guidelines in the area of corporate governance [9]. For a detailed discussion of related work on SOA governance, such as the body of academic literature and approaches published by IT vendors and open standards organisations like OASIS, OMG and The Open Group, and how it relates to the approach presented here, please refer to our extended report in [10].
Starting from the existing knowledge base, we analysed the widely-used IT governance frameworks Cobit and ITIL and provided an initial evaluation of their utility in a case study in order to derive the core of the SOA governance framework. Mapping the roles and activities proposed by the two frameworks to an SOA environment revealed a need for extensions, as some criteria that are specific to SOAs are not covered there. Furthermore, the mapping necessitated a re-naming and re-grouping of activities into a service lifecycle. In a second step, we conducted a detailed review of literature related to service lifecycle management and SOA governance, focusing on the identification of main concepts, and conducted a series of interviews with experts in the field of service management. For the identification of the relevant roles and their responsibilities, we conducted a comprehensive content analysis using published job profiles from Seek.com, Australia's best known recruitment website.
In order to critically evaluate the utility of the framework, we applied it at Landgate, a public sector organisation. Landgate is the Statutory Authority responsible for Western Australia's land and property information and seeks to evolve its IT business applications to implement new services for its clients and to collaborate more closely with partners. The application of the governance framework to Landgate showed how the model supports organisations in identifying new IT management activities when moving into a service-oriented paradigm and which consequences this new paradigm has for the establishment of accountabilities.
The service lifecycle
Cobit and ITIL are very detailed and widely used frameworks that propose a large number of best practices and processes as well as measures, roles and responsibilities to aid management in the planning and organisation, acquisition and implementation, delivery and support, operation, monitoring and evaluation of IT systems. In Cobit alone, there are 197 single steps grouped in 34 processes, which are part of 4 main phases, offering an extensive repository of relevant activities and a highly elaborated set of assignments to roles. Some of the issues covered, such as infrastructure, data or technology and support, will not change significantly independent of the underlying paradigm (e.g. when SOA is replaced by another IT design paradigm) and therefore have not been further analysed. The structures of Cobit and ITIL do not allow for an explicit representation of different decision levels. Thus, we looked at management models to find a suitable high-level structure. Drawing from IT-management, we suggest that decision rights can be distributed into distinct layers. Due to space constraints, this paper covers only three of these layers: service portfolio-, service project-and service operation management. While acknowledging that there is a broad variety of definitions, we agree with [12] who stress that portfolio management deals with selecting and prioritising the best projects to proceed with. Portfolio management is about choosing the right project, whereas project management is about doing the project right [13]. Hence, in the portfolio management stage of our proposed framework, the goal is to identify the most relevant services from a larger service portfolio and decide if and when to implement them. Once a business sponsor has been identified and accepts responsibility for the service, a project is started and the service can be developed. The development process and the publishing or deployment of the service are governed in the service project management stage. Once in place, the operation management of a service covers operation and use, including performance and change management, as well as the retirement phase.
A significant amount of research has been published regarding the lifecycle of a single service (cf. [14] for a comprehensive overview). Starting with a service analysis and design phase, most authors include service implementation, service publishing, service operation as well as service retirement or withdrawal. In addition to that, [14] mention a negotiation phase. The latter is primarily relevant if a service or part of its sub-services are provided or sourced externally.
In this section, we focus on the main differences as compared to traditional IT governance by introducing new activities that provide managers with a foundation upon which SOA-related decisions can be based and by discussing those that require changes. Fig. 1 gives an overview and shows how management layers, lifecycle stages and activities are interrelated.
Fig. 1. Interrelationship of management layers, lifecycle stages and selected activities.
As a first step within the service portfolio management phase, a service roadmap is developed by identifying and prioritising service candidates (e.g. by analysing business processes). The proposed services are subsequently analysed further. In this step, all potential users should contribute to the definition of requirements to ensure high reusability of the service. After the feasibility study has yielded a positive outcome and a business case has been developed, identifying a business sponsor who is willing to fund the development and operation of the service [15] is an essential activity before a project can be started. Besides that, portfolio management is also responsible for the development of an overarching service taxonomy and service descriptions as well as for monitoring across projects. Please refer to [10], where we discuss how Cobit activities need to be adapted to a SOA environment using the examples "Create an SOA roadmap", "Assure consultation of potential users of services" and "Find business sponsor / service owner". As an example, we pick out the last activity here:
Find business sponsor / service owner: An important step refers to the issue of funding [16]. Adapting services to the requirements of different users will be more expensive than developing them for the sole purpose of a single user [17]. In many cases, the benefits might outweigh the cost so that a mechanism is required for identifying those services that are worth adapting. This mechanism, however, cannot make a perfect distinction, as there is uncertainty involved in the estimation of development and maintenance cost and possible revenues. Considering this, an enterprise architect (see section 5) can identify potential users, help them express their needs and recommend a certain design of a service, but should not appoint a business sponsor or owner. The latter should be found in a less hierarchical manner, because to enable performance measurement and encourage a high quality of decision making, the holder of the decision right should bear the economic risk as well. As multiple ownership would cause an increase in coordination effort, it will be helpful if services are owned by one of the potential users. The enterprise architect can encourage this by promoting a business case for the adapted service. If none of the potential users is willing to sponsor the service, the enterprise architect or a centralised committee could ultimately own the service as well and should therefore be provided with a dedicated budget.
Most steps of the basic service lifecycle, as mentioned above, are part of service project management. These include analysis, design, implementation and deployment/publishing. The analysis phase is fragmented, as this task is to a large extent conducted in the portfolio management phase, before a service sponsor can be found. By focusing on the major differences compared to traditional software development, we identify and discuss in [10] the following particularly interesting activities: "Decide on granularity and orchestration", "Determine access rights" and "Develop pricing model". Other important aspects include issues regarding service contracts and business object governance. Let's take an example from "service publishing":
Develop pricing model: Among traditional IT cost accounting methods (for an overview see [18]), activity-based costing is seen as one of the most effective representatives [19]. Under the SOA reuse paradigm, where services are shared among several business units or departments, new mechanisms like negotiation [18] between service owners and consumers should be considered. In addition, a pricing model for the external market has to be developed if the service is also offered to external customers. It differs from the internal pricing model as it does not aim at discouraging over-or underutilisation, but aims at maximising profit.
Within operation management, the actual service operation, which involves activities such as training, monitoring of service level agreements (SLAs) and change management, as well as the retirement phase are governed. Incident and capacity management have not been included in the service operation phase as they are not servicespecific. Retirement is a responsibility of the portfolio manager; however, it strongly affects the service owner as well. It could therefore be included in the portfolio as well as in the operation management phase. In [10], we discuss in more detail the activity of consistently recording, assessing and prioritising change requests.
We conducted a literature review and a comprehensive content analysis of more than 300 published job profiles at Seek.com (keyword: "SOA"), focusing on roles that are either not mentioned in the IT Governance frameworks or whose responsibilities change significantly under a SOA paradigm. Among these are the roles of Business Analyst, Enterprise/Business Architect, Project Manager, Service Owner and Service Librarian. Due to space constraints, we refer the reader to our discussion in [10] and briefly discuss the following two roles here as an example:
Service Owner [11], [15]: Although the service owner is mentioned as a key role, there is no definition of corresponding responsibilities and tasks in any of the literature or the published job profiles we reviewed. We define the service owner as the one who sponsors the development and operation of the service, in other terms, the benefits owner. This might be the business unit that launched the request or a centralised committee if none of the potential users is willing to fund the service or the organisation is structured hierarchically and business units or departments do not hold decision rights for the investment. As the one bearing the financial risk of the service project, the service owner must hold the right to determine a pricing model and "sell" it to other users as well as to make decisions about changes. Service Librarian [20]: The service librarian is a new role in SOAs. The service librarian is responsible for the service repository and ensures the quality of published (meta-)data about as well as ease of discovery of and access to registered services.
The assignment of responsibilities calls for a detailed mapping of the involvement of the different roles in the activities of SOA governance. We use so-called RACI charts for each of the management layers in our proposed initial SOA governance framework to show the recommended responsibilities. The RACI charts map activities of the SOA lifecycle to roles of stakeholders in a SOA initiative and propose their responsibilities by specifying which roles are (r)esponsible, (a)ccountable, (c)onsulted or (i)nformed regarding specific activities. Roles are represented as columns and service lifecycle activities as rows. By providing these RACI charts, our framework offers a tangible and easy-to-apply tool for the analysis of responsibilities along the whole service lifecycle. While a detailed discussion of the RACI charts is beyond the scope of this paper, two aspects of the assignment of responsibilities became particularly prominent. The first aspect is the involvement of top management and business executives in SOA development, the second aspect is the alignment of ownership for individual services. The involvement of business executives documents the degree to which the design of a service-oriented architecture is backed and driven by business concerns. In many organisations, SOA is seen as "yet another way" of software development. Consequently, few responsibilities have been changed since it was introduced. The business potential of this new paradigm is often not realised and SOA remains a means of integration for an organisation's software architecture. If this is to be changed, business representatives, especially business executives, have to be involved in decision making even more than proposed by Cobit for a traditional IT environment [1]. At first sight, this seems to increase the complexity of decision making, which would contradict executives' striving for reduction of information. Yet, management is not required to look at technical details but to understand the business implications. They can provide support for the development of interdepartmental services to leverage the reuse potential of SOA and promote the utilisation of services by selling them to external customers. Within the proposed framework, it is recommended that executives be involved in the development of an SOA roadmap and the prioritisation of services by evaluating the business potential and business value. Moreover, they can help find a business sponsor and should receive accountability for determining access rights. The business executives are expected to evaluate if a service contributes to the competitive advantage of the organisation, which could be lost once the service is offered to competitors.
Turning to ownership, the framework proposes to designate either individual service users or a central committee as service owner. A single owner that bears all cost but also appropriates all benefits of a service has several advantages. Single service ownership facilitates performance management for services and encourages owners to look for business opportunities of their internal processes, turning them into marketable services to expand their business case.
This paper has presented selected parts of a new framework for SOA governance. We focused on what changes to traditional IT governance approaches are required in order to utilise the business potential of service-orientation. Initial validation at a Western Australian government agency showed that the framework can assist organisations in evaluating their own governance structure and in identifying the main obstacles to financial returns on their SOA investments. By comparing their own organisational governance model to the roles, activities and their alignment as proposed by our framework, organisations can identify divergences, which might point to weaknesses in their own approach. Once obstacles have been identified, however, major changes within the organisational structure as well as a change in mindset are often required. Therefore, it has to be borne in mind that opposition from within the organisation is likely to arise and that the implementation of required changes might take a considerable amount of time, potentially necessitating the involvement of external consultants with experience in the fields of SOA governance and change management. The proposed framework should be seen as a starting point for the research community and, at this stage, stays below the level of elaboration of its archetypes Cobit and ITIL. Its current limitations include the preliminary empirical evidence in Australia only at this stage, the emphasis on organisational aspects of SOA governance at the expense of other governance aspects such as policies, processes and metrics, and its yet untested economic efficiency. To arrive at a fully-fledged reference model for SOA governance, further work is required to evaluate the framework in real world organisations and to inform its refinement. In addition to that, we see research opportunities in broadening the scope by integrating the different players of a service ecosystem, such as service brokers, service consumers and service providers, into the model and examine who will have the market power to set standards and force other players to comply with them in an ecosystem environment.