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 [
While definitions differ considerably, most authors agree on the basic elements a
governance framework should address, namely the organisational structure, processes,
policies and metrics [
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. 2
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 [
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.
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
[
A significant amount of research has been published regarding the lifecycle of a
single service (cf. [
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. Management
Layers Service
Portfolio Management
Service
Project Management
Service Operation Management
Service Lifecycle Service
Analysis Service Design
Service Implementation
Service Publishing Service Operation
Service Retirement
SOA specific
Governance Activities Create a SOA roadmap
Assure the consultation of potential users of services
Find business sponsor /
service owner
Decide on granularity and orchestration Determine access rights
Develop pricing model Develop and implement a process to consistently
record, assess and prioritise change requests
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 [
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 [
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. 4
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], [
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 [
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. 5
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.