=Paper=
{{Paper
|id=None
|storemode=property
|title=Towards a Reference Model for SOA Governance
|pdfUrl=https://ceur-ws.org/Vol-592/Paper04.pdf
|volume=Vol-592
|dblpUrl=https://dblp.org/rec/conf/caise/OttKBRK10a
}}
==Towards a Reference Model for SOA Governance==
https://ceur-ws.org/Vol-592/Paper04.pdf
Towards a Reference Model for SOA Governance
C. Ott1, A. Korthaus2, T. Böhmann3, M. Rosemann2, H. Krcmar1
1
Technische Universität München, Lehrstuhl für Wirtschaftsinformatik, München, Germany
2
Queensland University of Technology, Business Process Management, Brisbane, Australia
3
ISS International Business School of Service Management, Hamburg, Germany
christian@coonet.de, axel.korthaus@qut.edu.au, boehmann@iss-
hamburg.de, m.rosemann@qut.edu.au, krcmar@in.tum.de
Abstract. 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 gov-
ernance approach for SOA more successfully. We have reviewed the highly ad-
vanced 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 de-
fine benefits ownership for services.
Keywords: Service-Oriented Architecture (SOA), SOA governance
1 Introduction
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 gov-
ernance as the process of “specifying the decision rights and accountability frame-
work 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:
2 C. Ott, A. Korthaus, T. Böhmann, M. Rosemann, H. Krcmar
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 pro-
posing 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 expli-
cate 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 Related work and research approach
The knowledge bases of corporate and IT governance form obvious points of refer-
ences 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 gov-
ernance 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. Map-
ping 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 cov-
ered 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 Land-
gate, 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.
Towards a Reference Model for SOA Governance 3
3 The service lifecycle
3.1 Overview
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 con-
straints, this paper covers only three of these layers: service portfolio-, service pro-
ject- 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 pro-
ject, 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 im-
plement 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 analy-
sis and design phase, most authors include service implementation, service publish-
ing, 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.
3.2 Detailed view
In this section, we focus on the main differences as compared to traditional IT gov-
ernance 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.
4 C. Ott, A. Korthaus, T. Böhmann, M. Rosemann, H. Krcmar
Management Service SOA specific
Layers Lifecycle Governance Activities
Service
Portfolio Service Create a SOA Assure the consultation of Find business sponsor /
Management Analysis roadmap potential users of services service owner
Service Design Decide on granularity and orchestration
Service
Service
Project Implementation
Management
Service Determine Develop
Publishing access rights pricing model
Service Develop and implement a process to consistently
Service Operation record, assess and prioritise change requests
Operation
Management Service
Retirement
Fig. 1. Interrelationship of management layers, lifecycle stages and selected activities.
3.2.1 Service Portfolio Management
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 busi-
ness 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 be-
fore 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, can-
not make a perfect distinction, as there is uncertainty involved in the estimation of
development and maintenance cost and possible revenues. Considering this, an en-
terprise 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 man-
ner, because to enable performance measurement and encourage a high quality of
Towards a Reference Model for SOA Governance 5
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 archi-
tect 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.
3.2.2 Service Project Management
Most steps of the basic service lifecycle, as mentioned above, are part of service pro-
ject management. These include analysis, design, implementation and deploy-
ment/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: “De-
cide on granularity and orchestration”, “Determine access rights” and “Develop pric-
ing 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 rep-
resentatives [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 of-
fered 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.
3.2.3 Service Operation Management
Within operation management, the actual service operation, which involves activities
such as training, monitoring of service level agreements (SLAs) and change manage-
ment, as well as the retirement phase are governed. Incident and capacity manage-
ment have not been included in the service operation phase as they are not service-
specific. 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 Roles and assignment of responsibilities
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
6 C. Ott, A. Korthaus, T. Böhmann, M. Rosemann, H. Krcmar
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 lit-
erature 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 pub-
lished (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 frame-
work 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 re-
sponsibilities 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. Conse-
quently, 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, busi-
ness 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
Towards a Reference Model for SOA Governance 7
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 ex-
ternal 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 com-
petitive 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 ser-
vice 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 market-
able services to expand their business case.
5 Summary
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 organi-
sations in evaluating their own governance structure and in identifying the main ob-
stacles to financial returns on their SOA investments. By comparing their own organ-
isational governance model to the roles, activities and their alignment as proposed by
our framework, organisations can identify divergences, which might point to weak-
nesses 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 organi-
sation 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 manage-
ment. 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 govern-
ance at the expense of other governance aspects such as policies, processes and met-
rics, 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.
8 C. Ott, A. Korthaus, T. Böhmann, M. Rosemann, H. Krcmar
References
1. IT Governance Institute (ITGI) (2007). Cobit 4.1. Isaca, Rolling Meadows.
2. Weill, P. and J.W. Ross (2004). IT Governance: How Top Performers Manage IT Decision
Rights for Superior Results. Harvard Business School Press, Boston, Mass.
3. Bernhardt, J. and D. Seese (2008). A Conceptual Framework for the Governance of Service-
Oriented Architectures. In Proc. of the 3rd Workshop on Trends in Enterprise Architecture
Research (TEAR 2008). Sydney, Australia, Dec. 1.
4. Malinverno, P. (2006). Service-Oriented Architecture Craves Governance. Gartner Re-
search, 20. Jan. 2006, 1-6.
5. Schelp, J. and M. Stutz (2007). SOA-Governance. HMD-Praxis der Wirtschaftsinformatik,
253, 66-73.
6. Bell, M. (2008). Service-Oriented Modeling: Service Analysis, Design, and Architecture.
Wiley, Hoboken, NJ.
7. Dodani, M.H. (2006). Who Took the Cookie from the Cookie Jar? Journal of Object Tech-
nology 5(4), May-June, http://www.jot.fm/issues/issue_2006_05/column3/
8. ITIL (2007). IT Infrastructure Library v3. OGC, TSO, http://www.itil-officialsite.com/
home/home.asp
9. OECD (2004). OECD Principles of Corporate Governance. Org. for Economic Co-
Operation and Development. http://www.oecd.org/dataoecd/32/18/31557724.pdf
10.Ott, C., Korthaus, A., Böhmann, T., Rosemann, M. and Krcmar, H. (2010): Towards a Ref-
erence Model for SOA Governance (Extended Version). Working Paper. http://eprints.
qut.edu.au/31057/1/Ott-Korthaus-Boehmann-Rosemann-Krcmar-SOA_Governance.pdf
11.Malinverno, P. (2006b). Sample Governance Mechanisms for a Service-Oriented Architec-
ture. Gartner Research, 27. April 2006, 1-5.
12.Archer, N.P., and F. Ghasemzadeh (2004). Project Portfolio Selection and Management. In
Morris, P.W.G. and J.K. Pinto (eds.). The Wiley Guide to Management Projects. John Wiley
& Sons, NY.
13.Cooke-Davies, T. (2004). Project Success. In Morris, P.W.G. and J.K. Pinto (eds.). The
Wiley Guide to Management Projects. John Wiley & Sons, New York.
14.Riedl, C., Boehmann, T., Rosemann, M. and H. Krcmar (2008). Quality Management in
Service Ecosystems. Information Systems & E-Business Management, Springer, 1-23.
15.Deb, M., Helbig, J., Kroll, M. and A. Scherdin (2005). Bringing SOA to Life: The Art and
Science of Service Discovery and Design. SOA Web Services Journal, 27, 42-47.
16.Schepers, T.G.J., Iacob, M.E. and P.A.T. Van Eck (2008). A Lifecycle Approach to SOA
Governance. In Proc. of the 2008 ACM Symp. on Applied Computing (SAC ’08), Brazil,
ACM, 1055-1061.
17.Ren, M. and K. Lyytinen (2008). Building Enterprise Architecture Agility and Sustenance
with SOA. Comm. of the Association for Information Systems, 22 (March), 75-86.
18.Gerlach, J., Neumann, B., Moldauer, E., Aro, M. and D. Frisby (2002). Determining the
Cost of IT Services. Comm. of the ACM, 45(9), Sept., 61-67.
19.Ross, J.W., Vitale, M.R. and C. M. Beath (1999). The Untapped Potential of IT Chargeback.
MIS Quarterly, 23(2), 215-237.
20.Kajko-Mattsson, M., Lewis, G.A. and D.B. Smith (2007). A Framework for Roles for De-
velopment, Evolution and Maintenance of SOA-Based Systems. In Proc. of the Int. Work-
shop on Systems Development in SOA Environments (SDSOA ’07), 7-12.