Marc Lankhorst (auth.) - Enterprise Architecture at Work_ Modelling, Communication and Analysis.pdf

The Enterprise Engineering Series
Series Editors
Jan Dietz
Erik Proper
José Tribolet
Editorial Board
Terry Halpin
Jan Hoogervorst
Martin Op ’t Land
Ronald G. Ross
Robert Winter
For further volumes:
http://www.springer.com/series/8371

Marc Lankhorst et al.
Enterprise
Architecture
at Work
Modelling, Communication and Analysis
Third Edition

Marc Lankhorst
Novay
Enschede
The Netherlands
ISSN 1867-8920 ISSN 1867-8939 (electronic)
ISBN 978-3-642-29650-5 ISBN 978-3-642-29651-2 (eBook)
DOI 10.1007/978-3-642-29651-2
Springer Heidelberg New York Dordrecht London
ACM Computing Classification (1998): H.1, D.2.11, J.1
Library of Congress Control Number: 2012943469
# Springer-Verlag Berlin Heidelberg 2005, 2009, 2013
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recita-
tion, broadcasting, reproduction on microfilms or in any other physical way, and transmission or
information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts
in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being
entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication
of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the
Publisher’s location, in its current version, and permission for use must always be obtained from
Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center.
Violations are liable to prosecution under the respective Copyright Law.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publica-
tion does not imply, even in the absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general use.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for
any errors or omissions that may be made. The publisher makes no warranty, express or implied, with
respect to the material contained herein.
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)

Foreword to the Third Edition
On January 31, 2012, The Open Group published version 2.0 of the ArchiMate®
language for enterprise architecture modelling. This latest technical standard is now
more aligned with TOGAF®, the world’s most popular enterprise architecture
framework. This is an important milestone in the development of the profession,
and this book, now in its third edition, provides much of the background and
foundations of this development.
When Novay and its partners started the ArchiMate R&D project in 2002, they
wanted to develop better means for communicating enterprise architectures. Until
then, architects expressed their architectures either in proprietary tools and
frameworks, with all the ensuing problems of vendor lock-in, or in fuzzy
PowerPoint pictures that you could understand only if the architect was present to
explain what all the boxes and lines meant. A well-founded open standard for
architecture description was sorely needed.
Shortly after the project, consultants and educators began using it, the first
commercial tools started to appear, and an active user community emerged. In
2008, The Open Group had just created a working group to establish a description
language to complement TOGAF, when it was contacted by the ArchiMate Foun-
dation. Since ArchiMate was already developed with TOGAF as one of its inputs,
the match between the two created a great opportunity. In 2008, the ownership of
ArchiMate was transferred to The Open Group and became a standard in 2009.
This proved to be an all-important step. With the rising popularity of TOGAF
and the professional support of The Open Group, ArchiMate adoption figures have
grown rapidly. At the time of writing, The Open Group’s ArchiMate Forum has
some 70 member organisations, over 10 commercial and several open-source tools
support the language, and its active LinkedIn group counts nearly 1700 members.
ArchiMate 2.0 provides a number of important extensions that make the fit
between TOGAF and ArchiMate even closer. It improves collaboration through
clearer understanding across multiple functions, including business executives,
enterprise architects, systems analysts, software engineers, business process
consultants and infrastructure engineers. The new standard enables the creation of
fully integrated models of an organisation’s enterprise architecture, the motivation
v

behind it, and the programs, projects and migration paths to implement it.
ArchiMate already follows terms defined in the TOGAF framework, and version
2.0 of the specification enables modelling through all phases of the TOGAF
Architecture Development Method (ADM).
ArchiMate 2.0 provides enterprise architects with the tools and concepts neces-
sary to create a consistent, integrated model that aligns more closely with TOGAF.
It will increase interoperability and help enterprise architects establish a common
language across the enterprise, raising the value and awareness of the discipline.
The growing use of models and standards is a sure sign of the maturation of any
engineering discipline. This does not mean that enterprise architecture becomes a
deterministic exercise, though. Rather, these instruments help managers and
architects predict the effects of their actions, spot opportunities, and control risk,
in the same way that navigational aids help a ship’s captain steer an optimal course
in the prevailing currents and winds.
The Open Group Allen Brown
Reading, UK, February 2012 President & CEO
vi Foreword to the Third Edition

Foreword to the Second Edition
Have you ever built a new house, or rebuilt an existing one? If you did, most likely
an architect has been involved guiding you through the whole process of permits,
drawings and construction. In this process, the architect creates insightful two- and
three-dimensional drawings, models and views of the house. These show the
structure of the house, its division into rooms (like the kitchen, living, bedrooms,
and bathroom), its windows with views of the light, the networks of electricity, gas
and plumbing, etc. The architectural design process of a house is a well-established
discipline, using internationally accepted standards for describing and visualising
the design, and various ways to present the design and analyse and calculate the
strength of the proposed construction. The architect is well trained in the design
methods, the modelling language and certain supporting tools.
Building or rebuilding an organisation is a much more complex and challenging
task. First of all because the steps one has to take in order to (re)build an
organisation are not standardised. One could start by first (re)designing business
processes, followed by the application (re)design. Or one could first design generic
application services, followed by designing business processes on top of these.
Since a few years, The Open Group Architectural Framework (TOGAF) defines a
standard way to take these steps. This enables enterprise architects to (re)design an
organisation and its supporting IT systems in a uniform and standard way. The
release of the improved TOGAF 9 version in February 2009 will lead to an even
more uniform and better way to do this.
Secondly, building an organisation is a complex and challenging task because of
the multifarious dependencies within an organisation. Many (often unknown)
dependencies exists between various domains, like strategy, products and services,
business processes, organisational structure, applications, information manage-
ment, and technical infrastructure. Besides a having good overview over these
different domains, one needs to be aware of their interrelationships. Together,
these form the enterprise architecture of the organisation. In many cases, different
languages and concepts are use to describe each domain, with no support for
describing and analyzing relationships to other domains.
vii

Until recently, a uniform and easy to use language for modelling and visualising
enterprise architectures was lacking. ArchiMate, the modelling language described
in this book, fills in this gap. It provides instruments to support enterprise architects
in describing, analyzing and visualising the relationships among domains in an
unambiguous way. ArchiMate is supported by different tool vendors and service
providers. Many organisations are using it already as their company standard for
describing enterprise architecture and its value has been proven in practice!
Just like an architectural drawing in classical building architecture describes the
various aspects of the construction and use of a building, ArchiMate offers a
common language for describing the construction and operation of business pro-
cesses, organisational structures, information flows, IT systems, and technical
infrastructure. This insight helps stakeholders to design, assess, and communicate
the consequences of decisions and changes within and between these business
domains.
Moreover, ArchiMate is now The Open Group’s open and independent
modelling language for enterprise architecture. The specification of ArchiMate
1.0 has been released by The Open Group in April 2009. You can expect an even
greater uptake of this language now that it has become a standard. Moreover, the
synergy with TOGAF will provide enterprise architects with a very powerful
approach, supported by methods, modelling languages and tools. Because
ArchiMate is an open standard, it facilitates (model) interoperability and exchange
of best practices. It is not a proprietary language from one tool vendor or service
provider.
This book is about ArchiMate. It explains the background and the results of the
research project that led to the realisation of the ArchiMate language. It also
contains a description of the ArchiMate language itself, and many examples of its
use for modelling, visualising and analysing enterprise architecture. The
descriptions are based on the ArchiMate 1.0 specification published by The Open
Group, and this second edition of the book adds more details on the relation
between ArchiMate and TOGAF.
I cordially invite you to read this book. Reaching a second edition already proves
its practical value. Convince yourself and start using ArchiMate!
dr.ir. H.M. Franken, CEO, BiZZdesign
Chairman, ArchiMate Forum of The Open Group
Enschede,
The Netherlands,
February 2009
viii Foreword to the Second Edition

Foreword to the First Edition
‘Architecture’, in a broad sense, is the synergy of art and science in designing
complex structures, such that functionality and complexity are controlled. The
notion of architecture is used in a wide range of domains, from town planning to
building and construction, and from computer hardware to information systems,
each being characterised by the types of ‘structures’ or ‘systems’ being designed.
However, we can recognise some common concerns in all these approaches.
To begin with, architecture, and hence the architect, is concerned with under-
standing and defining the relationship between the users of the system and the
system being designed itself. Based on a thorough understanding of this relation-
ship, the architect defines and refines the essence of the system, i.e., its structure,
behaviour, and other properties.
This representation of the system’s essence, also called the ‘architecture’ of the
system, forms the basis for analysis, optimisation, and validation and is the starting
point for the further design, implementation, and construction of that system. The
resulting artifacts, be they buildings or information systems, naturally have to
conform to the original design criteria. The definition of the architecture is the
input for verifying this.
During this process, the architect needs to communicate with all stakeholders of
the system, ranging from clients and users to those who build and maintain the
resulting system. The architect needs to balance all their needs and constraints to
arrive at a feasible and acceptable design.
Fulfilling these needs confronts the methodology for defining and using
architectures with demanding requirements. These can only be met if the architects
have an appropriate way of specifying architectures and a set of design and
structuring techniques at their disposal, supported by the right tools. In building
and construction, such techniques and tools have a history over millennia. In
information systems and enterprise architecture, though, they are just arising.
Important for an architecture description language is that the properties of the
system can be represented in their bare essence without forcing the architect to
include irrelevant detail. This means that the description language must be defined
at the appropriate abstraction level.
ix

If the architecture is concerned with the relationship between an enterprise and
its IT support, the architect should be capable of expressing the structure,
behaviour, and coherence of both the business processes and the IT support, such
that one can use these specifications to get a thorough understanding of the
architecture, to optimise it according to specific business goals, and to develop a
strategy for introducing improvements in the current situation. This implies that the
architecture description language should embrace easily understandable human
notions of business processes and their IT support, far away from low-level
implementation issues. It requires a level of comprehensibility of the description
language by a broader audience than just the few specialists that are capable of
understanding the obscurities of formal, mathematically oriented languages.
The very same applies to the methods that allow the architect to structure and
manipulate architectural specifications such that their complexity can be controlled.
Not in the least, the language and methods are the basis for unambiguous mutual
understanding and successful collaboration between the stakeholders of the archi-
tecture. All stakeholders need to be aware about the implications of the choices in
the architecture, and be capable of possibly influencing such choices.
This book presents the results of a research project that produced just that: a
comprehensible, high-level design language for enterprise architecture, accom-
panied by a set of techniques and guidelines for visualisation and analysis of
architectures. These results were validated in practice in real-life case studies in
cooperation with several large, information-intensive organisations. Currently,
various companies, ranging from vendors of architecture tools to consultants and
other users of enterprise architecture, are implementing the results of the project.
This project is a prime example of the knowledge transfer for which the
Telematica Instituut1
was founded. Both government and industry fund this
Dutch national research institute. Its mission is to boost the innovative and compet-
itive power of society by bridging the gap between academic research and its
industrial application. The ArchiMate project, from which this book results, is a
prime example of fruitful cooperation between these worlds. This proves the
success of this knowledge transfer.
I hope and trust that the ArchiMate project not only proves to be an example of
high-quality research in the important field of enterprise architecture, but also will
have a considerable impact in practice.
Scientific Director, Telematica Instituut Prof.dr.ir. C.A. Vissers
Enschede, December 2004
1
In April 2009, the Telematica Instituut changed its name to Novay.
x Foreword to the First Edition

Preface
Many stakeholders within and outside the company can be identified, ranging from
top-level management to software engineers. Each stakeholder requires specific
information presented in an accessible way, to deal with the impact of such wide-
ranging developments. To predict the effects of such developments and
modifications of an organisation’s business and IT, it is necessary but very difficult
to obtain an overview of these changes and their impact on each other, and to
provide both decision makers and engineers implementing the changes with the
information they need.
This book is about enterprise architecture, the practice that tries to describe and
control an organisation’s structure, processes, applications, systems, and technol-
ogy in such an integrated way. More specifically, we focus on methods and
techniques for making and using integrated descriptions by means of architecture
models, visualisation of these models for various stakeholders, and analysis of the
impact of changes.
The unambiguous specification and description of components and especially
their relationships in an architecture requires a coherent architecture modelling
language. Such a language must enable integrated modelling of architectural
domains and should be appreciated both by people from IT and by people with a
business background. In this book, we present such an enterprise modelling lan-
guage that captures the complexity of architectural domains and their relations and
allows the construction of integrated enterprise architecture models. We provide
architects with concrete instruments that may improve their architectural practice.
Furthermore, we provide techniques and heuristics for communicating with all
relevant stakeholders about these architectures. Central to the communication of
architectures is the notion of viewpoint. Viewpoints define abstractions on the set of
models representing the enterprise architecture, each aimed at a particular type of
stakeholder and addressing a particular set of concerns.
An architecture model is not just useful to provide insight into the current or
future situation; it can also be used to evaluate the transition from ‘as is’ to ‘to be’.
We therefore provide analysis methods for assessing both the qualitative impact of
xi

changes to an architecture and quantitative aspects of architectures, such as perfor-
mance and cost issues.
In order to make the approach we envisage practically feasible, architects require
a tool environment, which supports the definition, generation, editing, visualisation,
analysis, and management of architecture models and views. Moreover, such an
environment should work in concert with existing domain-specific modelling tools,
since we cannot expect architects to start using other tools, let alone other
languages, than the ones they are used to. Although some tool developers are active
in the enterprise architecture market, none currently provide a complete solution;
some are focused on IT portfolio management, others on business process
modelling, or on software architecture. We therefore present the design of a
viewpoint-driven enterprise modelling environment that can provide just this sup-
port, and a vision on the future of model-driven enterprise architecture tooling.
Currently, we are working with a number of commercial tool vendors to realise
these ideas.
The modelling language and the other techniques in the book have been proven
in practice in numerous real-life case studies. To put these instruments into context,
the book also addresses the use of enterprise architecture models and techniques in
governance, with a focus on alleviating the infamous business–IT alignment
problem.
xii Preface

Audience
The intended audience of this book is twofold. On the one hand, we target
enterprise, business, and IT architecture practitioners, especially those who are
looking for better ways of describing, communicating, and analysing (enterprise)
architectures. On the other hand, we aim for students of IT and (IT) management
studying the field of enterprise architecture.
xiii

Overview of the Book
In the first chapter, we give an introduction to architecture in general and enterprise
architecture in particular, outline its drivers, and describe the architecture process.
Chapter 2 explains the methods and techniques currently used in this field. Follow-
ing this, we outline the foundations of our approach to enterprise architecture
modelling (Chap. 3). We then describe our view of architecture as being primarily
a means of communication with all the stakeholders involved (Chap. 4).
Architectures are fruitfully used both in requirements analysis and design for
new applications, business processes, etc., and to gain insight into existing systems
(in the broad sense). In our approach, the use of architecture models has a central
role; the modelling language used throughout the rest of the book is introduced in
Chap. 5. Having a language is not enough: the architect also needs to be guided in
its use, which is the topic of Chap. 6.
Many stakeholders with different goals or concerns in mind can view
architectures. Each of these requires its own depictions of (part of) an architecture
model, and the creation, use of such views and viewpoints is the topic of Chap. 7.
Given that we have accurate models of an architecture, we can subject these models
to various types of analysis, to establish for example what the impact of a change
might be, or whether the performance of the technical infrastructure is sufficient
given the applications and business processes that use it. These analyses are
discussed in Chap. 8.
The practical applications of these modelling, visualisation, and analysis
techniques are the topic of the next three chapters. In Chap. 9, experiences and
best practices from case studies regarding the alignment of business, applications,
and infrastructures are presented. These provide the context in which architectures
are designed. Chapter 10 describes software tools that are currently available and
our vision on and prototypes of future software support for enterprise architecture.
Chapter 11 presents our practical experience with applying the techniques and
prototypes in a number of real-life case studies. Finally, Chap. 12 provides a vision
of the future: what is next; what comes ‘after’ architecture?
xv

Acknowledgements
This book has resulted from the ArchiMate project, a Dutch research initiative that
has developed concepts and techniques to support enterprise architects in the
visualisation, communication, and analysis of integrated architectures. The
ArchiMate consortium consisted of Telematica Instituut (now Novay), ABN
AMRO, Stichting Pensioenfonds ABP, the Dutch Tax and Customs Administration,
Ordina, Centrum voor Wiskunde en Informatica, Radboud Universiteit Nijmegen,
and the Leiden Institute of Advanced Computer Science. Chapter 9 of this book
results from the GRAAL project, a daughter project of ArchiMate. The GRAAL
project was co-financed by the Telematica Instituut and the Centre for Telematics
and Information Technology (CTIT) of the University of Twente, Enschede, The
Netherlands.
Our special thanks go to Henk Jonkers for his help in editing the third edition of
this book, to make it compliant with ArchiMate 2.0.
ArchiMate is now a trademark and a technical standard of The Open Group.
More information on the ArchiMate standard can be found at http://www.
archimate.org and http://www.opengroup.org/archimate.
xvii

Contents
1 Introduction to Enterprise Architecture . . . . . . . . . . . . . . . . . . . . 1
1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 The Architecture Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Drivers for Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Internal Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 External Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Enterprise Architecture and Other Governance Instruments . . . 11
2.1.1 Strategic Management: Balanced Scorecard . . . . . . . . . 12
2.1.2 Strategy Execution: EFQM . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Quality Management: ISO 9001 . . . . . . . . . . . . . . . . . . 15
2.1.4 IT Governance: COBIT . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.5 IT Service Delivery and Support: ITIL . . . . . . . . . . . . . 17
2.1.6 IT Implementation: CMM and CMMI . . . . . . . . . . . . . 18
2.2 Methods and Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Enterprise Architecture Methods . . . . . . . . . . . . . . . . . 19
2.2.2 The IEEE 1471–2000/ISO/IEC 42010 Standard . . . . . . 20
2.2.3 The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . 22
2.2.4 The Open Group Architecture Framework (TOGAF) . . . 23
2.2.5 OMG’s Model-Driven Architecture (MDA) . . . . . . . . . 26
2.2.6 Other Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Description Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 IDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.3 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.4 ARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.5 Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . 34
xix

2.3.6 Architecture Description Languages . . . . . . . . . . . . . . . 36
2.3.7 Suitability for Enterprise Architecture . . . . . . . . . . . . . . 37
2.4 Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1 Service-Oriented Technologies . . . . . . . . . . . . . . . . . . . 39
2.4.2 Relevance and Benefits for Enterprise Architecture . . . . 40
3 Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Getting to Grips with Architectural Complexity . . . . . . . . . . . . 43
3.1.1 Compositionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.2 Integration of Architectural Domains . . . . . . . . . . . . . . 45
3.2 Describing Enterprise Architectures . . . . . . . . . . . . . . . . . . . . . 47
3.2.1 Observing the Universe . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.2 Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.3 Observing Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.4 Views and Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.5 Ways of Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.6 Enterprise Architecture Models . . . . . . . . . . . . . . . . . . 52
3.3 Pictures, Models, and Semantics . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.1 Symbolic and Semantic Models . . . . . . . . . . . . . . . . . . 54
3.3.2 Symbolic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.3 Semantic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.4 Semantics in ArchiMate vs. UML . . . . . . . . . . . . . . . . 59
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4 Communication of Enterprise Architectures . . . . . . . . . . . . . . . . 61
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2 System Development as a Knowledge Transformation Process . 63
4.2.1 System Development Community . . . . . . . . . . . . . . . . 63
4.2.2 System Development Knowledge . . . . . . . . . . . . . . . . . 64
4.2.3 Explicitness of Knowledge . . . . . . . . . . . . . . . . . . . . . . 66
4.2.4 Transformations of Knowledge . . . . . . . . . . . . . . . . . . 67
4.3 Conversation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Architectural Conversations . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.1 Knowledge Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.2 Conversation Techniques . . . . . . . . . . . . . . . . . . . . . . . 72
4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 A Language for Enterprise Modelling . . . . . . . . . . . . . . . . . . . . . 75
5.1 Describing Coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Service Orientation and Layering . . . . . . . . . . . . . . . . . . . . . 77
5.3 Three Dimensions of Modelling . . . . . . . . . . . . . . . . . . . . . . 78
5.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Business Layer Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5.1 Business Structure Concepts . . . . . . . . . . . . . . . . . . . . 81
5.5.2 Business Behaviour Concepts . . . . . . . . . . . . . . . . . . . 84
5.5.3 Higher-Level Business Concepts . . . . . . . . . . . . . . . . 87
xx Contents

5.6 Application Layer Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.6.1 Application Structure Concepts . . . . . . . . . . . . . . . . . 90
5.6.2 Application Behaviour Concepts . . . . . . . . . . . . . . . . 91
5.6.3 Business–Application Alignment . . . . . . . . . . . . . . . . 93
5.7 Technology Layer Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.7.1 Technology Structure Concepts . . . . . . . . . . . . . . . . . 93
5.7.2 Technology Behaviour Concepts . . . . . . . . . . . . . . . . 96
5.7.3 Application–Technology Alignment . . . . . . . . . . . . . . 96
5.8 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.9 Motivation Extension Concepts . . . . . . . . . . . . . . . . . . . . . . . 100
5.9.1 Stakeholder, Driver and Assessment . . . . . . . . . . . . . . 102
5.9.2 Goal, Requirement, Constraint and Principle . . . . . . . . 102
5.9.3 Motivation Extension Relations . . . . . . . . . . . . . . . . . 104
5.10 Implementation & Migration Extension Concepts . . . . . . . . . . 104
5.10.1 Implementation-Related Concepts . . . . . . . . . . . . . . . 104
5.10.2 Migration Planning Concepts . . . . . . . . . . . . . . . . . . . 105
5.11 Language Extension Mechanisms . . . . . . . . . . . . . . . . . . . . . 106
5.11.1 Adding Attributes to ArchiMate Concepts
and Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.11.2 Specialisation of Concepts . . . . . . . . . . . . . . . . . . . . . 107
5.12 ArchiMate and TOGAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.13 Modelling Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.14 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6 Guidelines for Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.2 The Modelling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.2.1 Modelling as a Transformation Process . . . . . . . . . . . . . 117
6.2.2 Basic Modelling Activities . . . . . . . . . . . . . . . . . . . . . . 118
6.2.3 Types of Modelling Actions . . . . . . . . . . . . . . . . . . . . . 120
6.3 Guidelines for Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3.1 Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.3.2 What to Capture in a Model? . . . . . . . . . . . . . . . . . . . . 127
6.3.3 Modelling and Abstraction . . . . . . . . . . . . . . . . . . . . . . 129
6.3.4 Structuring Models and Visualisations . . . . . . . . . . . . . 131
6.3.5 Constructive Use of Modelling Breakdowns . . . . . . . . . 134
6.4 Readability and Usability of Models . . . . . . . . . . . . . . . . . . . . 137
6.4.1 Reducing the Visual Complexity of Models . . . . . . . . . 137
6.4.2 Representation Conventions . . . . . . . . . . . . . . . . . . . . . 139
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7 Viewpoints and Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.1 Architecture Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.1.1 Origin of Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.1.2 Architecture Viewpoints . . . . . . . . . . . . . . . . . . . . . . . 149
7.1.3 Viewpoint Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 150
Contents xxi

7.2 Models, Views, and Visualisations . . . . . . . . . . . . . . . . . . . . . 152
7.2.1 Example: Process Illustrations . . . . . . . . . . . . . . . . . . . 154
7.2.2 Example: Landscape Maps . . . . . . . . . . . . . . . . . . . . . . 155
7.3 Visualisation and Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.3.1 Actions in Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.4 Creating, Selecting, and Using Viewpoints . . . . . . . . . . . . . . . 161
7.4.1 Classification of Viewpoints . . . . . . . . . . . . . . . . . . . . . 161
7.4.2 Guidelines for Using Viewpoints . . . . . . . . . . . . . . . . . 164
7.4.3 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.4.4 Creation of Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.4.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.4.6 Obtaining Commitment . . . . . . . . . . . . . . . . . . . . . . . . 167
7.4.7 Informing Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . 168
7.5 Basic Design Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.5.1 Introductory Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . 171
7.5.2 Organisation Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . 171
7.5.3 Actor Cooperation Viewpoint . . . . . . . . . . . . . . . . . . . . 171
7.5.4 Business Function Viewpoint . . . . . . . . . . . . . . . . . . . . 173
7.5.5 Product Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.5.6 Service Realisation Viewpoint . . . . . . . . . . . . . . . . . . . 177
7.5.7 Business Process Cooperation Viewpoint . . . . . . . . . . . 177
7.5.8 Business Process Viewpoint . . . . . . . . . . . . . . . . . . . . . 178
7.5.9 Information Structure Viewpoint . . . . . . . . . . . . . . . . . 179
7.5.10 Application Cooperation Viewpoint . . . . . . . . . . . . . . . 180
7.5.11 Application Usage Viewpoint . . . . . . . . . . . . . . . . . . . 181
7.5.12 Application Behaviour Viewpoint . . . . . . . . . . . . . . . . 183
7.5.13 Application Structure Viewpoint . . . . . . . . . . . . . . . . . 184
7.5.14 Infrastructure Viewpoint . . . . . . . . . . . . . . . . . . . . . . . 184
7.5.15 Infrastructure Usage Viewpoint . . . . . . . . . . . . . . . . . . 184
7.5.16 Implementation & Deployment Viewpoint . . . . . . . . . . 186
7.6 Viewpoints for the ArchiMate Extensions . . . . . . . . . . . . . . . . 186
7.7 ArchiMate and TOGAF Views . . . . . . . . . . . . . . . . . . . . . . . . 187
7.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8 Architecture Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.1 Analysis Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.2 Quantitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.2.1 Performance Views . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
8.2.2 Performance Analysis Techniques for Architectures . . . 194
8.2.3 Quantitative Modelling . . . . . . . . . . . . . . . . . . . . . . . . 196
8.2.4 Quantitative Analysis Technique . . . . . . . . . . . . . . . . . 201
8.3 Portfolio Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
8.4 Functional Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.4.1 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.4.2 Dynamic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
8.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
xxii Contents

9 Architecture Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
9.2 The GRAAL Alignment Framework . . . . . . . . . . . . . . . . . . . . 222
9.2.1 System Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
9.2.2 The Aggregation Hierarchy . . . . . . . . . . . . . . . . . . . . . 224
9.2.3 The System Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.2.4 Refinement Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.2.5 Comparison with Other Frameworks . . . . . . . . . . . . . . 226
9.3 Alignment Phenomena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.3.1 Service Provisioning Layers . . . . . . . . . . . . . . . . . . . . . 228
9.3.2 Infrastructure Architecture . . . . . . . . . . . . . . . . . . . . . . 229
9.3.3 Business System Architecture . . . . . . . . . . . . . . . . . . . 232
9.3.4 Strategic Misalignment . . . . . . . . . . . . . . . . . . . . . . . . 235
9.3.5 Conway’s Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
9.3.6 The FMO Alignment Pattern . . . . . . . . . . . . . . . . . . . . 238
9.4 The Architecture Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.4.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.4.2 IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
9.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
10 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
10.1 Reasons for Enterprise Architecture Tooling . . . . . . . . . . . . . 245
10.2 The Architecture Tool Landscape . . . . . . . . . . . . . . . . . . . . . 246
10.3 Tool Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
10.4 Workbench for Enterprise Architecture . . . . . . . . . . . . . . . . . 248
10.4.1 Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.4.2 Viewpoint Definition . . . . . . . . . . . . . . . . . . . . . . . . 250
10.4.3 Transparency and Extensibility . . . . . . . . . . . . . . . . . 251
10.4.4 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . 251
10.4.5 Exchange Formats . . . . . . . . . . . . . . . . . . . . . . . . . . 252
10.4.6 Workbench at Work . . . . . . . . . . . . . . . . . . . . . . . . . 252
10.5 View Designer Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
10.5.1 Viewpoint Rules for Creating Views
and Visualisations . . . . . . . . . . . . . . . . . . . . . . . . . . 255
10.5.2 Defining Actions in Models and Views . . . . . . . . . . . 256
10.5.3 Interactive Visualisation . . . . . . . . . . . . . . . . . . . . . . 258
10.5.4 Example: The Landscape Map Tool . . . . . . . . . . . . . 259
10.5.5 Comparison with Model–View–Controller
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
10.6 Impact-of-Change Analysis Tool . . . . . . . . . . . . . . . . . . . . . . 262
10.7 Quantitative Analysis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 264
10.8 Commercial Tool Support for ArchiMate . . . . . . . . . . . . . . . . 265
10.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Contents xxiii

11 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
11.1 Process and Application Visualisation at ABP . . . . . . . . . . . . 269
11.1.1 ABP Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . . 270
11.1.2 Case Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
11.1.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
11.1.4 Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
11.1.5 Design of the Visualiser . . . . . . . . . . . . . . . . . . . . . . 277
11.1.6 Case Study Results . . . . . . . . . . . . . . . . . . . . . . . . . 278
11.2 Application Visualisation at ABN AMRO . . . . . . . . . . . . . . . 279
11.2.1 CITA Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . . 280
11.2.2 Case Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
11.2.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
11.2.4 Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
11.2.5 Tool Design and Results . . . . . . . . . . . . . . . . . . . . . 290
11.3 Design and Analysis at the Dutch Tax and Customs
Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
11.3.1 Case Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
11.3.2 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
11.3.3 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . 298
11.3.4 Case Study Results . . . . . . . . . . . . . . . . . . . . . . . . . 302
11.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
12 Beyond Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 303
12.1 The World Before Enterprise Architecture . . . . . . . . . . . . . . . 303
12.2 The Advent of Enterprise Architecture . . . . . . . . . . . . . . . . . . 305
12.3 The Extended Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Appendix A – Language Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . 309
Appendix B – Graphical Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Appendix C – Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
xxiv Contents

Contributors
F. Arbab Centre for Mathematics and Computer Science (CWI), Amsterdam, The
Netherlands; Leiden Institute of Advanced Computer Science (LIACS), Leiden,
The Netherlands
S.F. Bekius Dutch Tax and Customs Administration, The Hague, The Netherlands
M. Bonsangue Leiden Institute of Advanced Computer Science (LIACS), Leiden,
The Netherlands
H. Bosma Ordina, Nieuwegein, The Netherlands
J. Campschroer Ordina, Nieuwegein, The Netherlands
M.J. Cuvelier Stichting Pensioenfonds ABP, Heerlen, The Netherlands
F.S. de Boer Centre for Mathematics and Computer Science (CWI), Amsterdam,
The Netherlands; Leiden Institute of Advanced Computer Science (LIACS),
Leiden, The Netherlands
P. Fennema BiZZdesign, Enschede, The Netherlands
L. Groenewegen Leiden Institute of Advanced Computer Science (LIACS),
Leiden, The Netherlands
S.J.B.A. Hoppenbrouwers Radboud University, Nijmegen, The Netherlands
M.-E. Iacob University of Twente, Enschede, The Netherlands
W.P.M. Janssen Inzycht, Enschede, The Netherlands
H. Jonkers BiZZdesign, Enschede, The Netherlands
D. Krukkert TNO, The Netherlands
M.M. Lankhorst Novay, Enschede, The Netherlands
P.G.M. Penders Crescimento Universal, Buren, The Netherlands
xxv

H.A. Proper Radboud University, Nijmegen, The Netherlands; CRP Henri Tudor,
Luxembourg
D.A.C. Quartel BiZZdesign, Enschede, The Netherlands
R.J. Slagter GriDD, Enschede, The Netherlands
A.W. Stam Almende, Rotterdam, The Netherlands
H.W.L. ter Doest Dimpact, Enschede, The Netherlands
R. van Buuren Novay, Enschede, The Netherlands
L. van der Torre University of Luxembourg, Luxembourg
P.A.T. van Eck University of Twente, Enschede, The Netherlands
D. van Leeuwen BiZZdesign, Enschede, The Netherlands
G.E. Veldhuijzen van Zanten Dutch Tax and Customs Administration,
Apeldoorn, The Netherlands
R.J. Wieringa University of Twente, Enschede, The Netherlands
xxvi Contributors

Chapter 1
Introduction to Enterprise Architecture
In current business practice, an integrated approach to business and IT is indis-
pensable. As a real-life example, take the Dutch government, who are currently
undertaking a massive redesign of the entire chain of organisations involved in the
social security system. Within this context, the collection of employees’ social
security premiums is transferred from the central social security organisation to the
tax administration. This sounds logical, since collecting taxes is superficially very
similar to collecting social security premiums. However, this seemingly simple
change entails a major redesign of organisational structures, business processes,
IT applications, and technical infrastructure. Enormous flows of data need to be
redirected within and among the different organisations: more than 600,000 payroll
tax returns are filed each month, a large proportion of which arrive within a peak
period of a couple of days.
Controlling such changes cannot be done by just ‘winging it’. But how can
we get to grips with this complex, multi-faceted world?
1.1 Architecture
It is often said that to manage the complexity of any large organisation or system,
you need architecture. But what exactly does ‘architecture’ mean? Of course, we
have long known this notion from building and construction. Suppose you contract
an architect to design your house. You discuss how rooms, staircases, windows,
bathrooms, balconies, doors, a roof, etc., will be put together. You agree on a master
plan, on the basis of which the architect will produce detailed specifications, to be
used by the engineers and builders.
How is it that you can communicate so efficiently about that master plan? We
think it is because you share a common frame of reference: you both know what a
‘room’ is, a ‘balcony’, a ‘staircase’, etc. You know their function and their relation.
M. Lankhorst et al., Enterprise Architecture at Work, The Enterprise
Engineering Series, DOI 10.1007/978-3-642-29651-2_1,
# Springer-Verlag Berlin Heidelberg 2013
1

A ‘room’, for example, serves as a shelter and is connected to another ‘room’ via a
‘door’. You both use, mentally, an architectural model of a house. This model
defines its major functions and how they are structured. It provides an abstract
design, ignoring many details. These details, like the number of rooms, dimensions,
materials to be used, and colours, will be filled in later.
A similar frame of reference is needed in designing an enterprise. To create an
overview of the structure of an organisation, its business processes, their application
support, and the technical infrastructure, you need to express the different aspects
and domains, and their relations.
But what is ‘architecture’ exactly? Even in building and construction, the term is
not without ambiguity. It can signify the art and science of designing the built
environment, or the product of such a design. Thus, the term architecture can
encompass both the blueprint for a building and the general underlying principles
such as its style, as in ‘gothic architecture’. There are different schools of thought
on this. Some say we should reserve the term ‘architecture’ in the context of
IT solely for such principles and constraints on the design space, as e.g. Dietz
argues (2006), who uses the term ‘enterprise ontology’ for the actual designs. In this
book, we will use the ISO/IEC/IEEE FDIS 42010:2011 standard (ISO/IEC/IEEE
2011) definition of architecture:
Architecture:
fundamental concepts or properties of a system in its environment, embodied
in its elements, relationships, and in the principles of its design and evolution.
This definition accommodates both the blueprint and the general principles.
More succinctly, we could define architecture as ‘structure with a vision’. An
architecture provides an integrated view of the system being designed or studied.
As well as the definition of architecture, we will use two other important notions
from the IEEE standard. First, a ‘stakeholder’ is defined as follows:
Stakeholder:
an individual, team, or organisation (or classes thereof) with interests in, or
concerns relative to, a system.
Most stakeholders of a system are probably not interested in its architecture,
but only in the impact of this on their concerns. However, an architect needs to be
aware of these concerns and discuss them with the stakeholders, and thus should
be able to explain the architecture to all stakeholders involved, who will often have
completely different backgrounds.
2 1 Introduction to Enterprise Architecture

1.2 Enterprise Architecture
More and more, the notion of architecture is applied with a broader scope than just
in the technical and IT domains. The emerging discipline of Enterprise Engineering
views enterprises as a whole as purposefully designed systems that can be adapted
and redesigned in a systematic and controlled way. An ‘enterprise’ in this context
can be defined as follows (The Open Group 2011):
Enterprise:
any collection of organisations that has a common set of goals and/or a single
bottom line.
Architecture at the level of an entire organisation is commonly referred to as
‘enterprise architecture’. This leads us to the definition of enterprise architecture:
Enterprise architecture:
a coherent whole of principles, methods, and models that are used in the
design and realisation of an enterprise’s organisational structure, business
processes, information systems, and infrastructure.
Enterprise architecture captures the essentials of the business, IT and its evolu-
tion. The idea is that the essentials are much more stable than the specific solutions
that are found for the problems currently at hand. Architecture is therefore helpful in
guarding the essentials of the business, while still allowing for maximal flexibility
and adaptivity. Without good architecture, it is difficult to achieve business success.
The most important characteristic of an enterprise architecture is that it provides
a holistic view of the enterprise. Within individual domains local optimisation will
take place and from a reductionistic point of view, the architectures within this
domain may be optimal. However, this need not lead to a desired situation for the
company as a whole. For example, a highly optimised technical infrastructure that
offers great performance at low cost might turn out to be too rigid and inflexible if it
needs to support highly agile and rapidly changing business processes. A good
enterprise architecture provides the insight needed to balance these requirements
and facilitates the translation from corporate strategy to daily operations.
To achieve this quality in enterprise architecture, bringing together information
from formerly unrelated domains necessitates an approach that is understood by all
those involved from these different domains. In contrast to building architecture,
which has a history over millennia in which a common language and culture has
been established, such a shared frame of reference is still lacking in business
and IT. In current practice, architecture descriptions are heterogeneous in nature:
1.2 Enterprise Architecture 3

each domain has its own description techniques, either textual or graphical, either
informal or with a precise meaning. Different fields speak their own languages,
draw their own models, and use their own techniques and tools. Communication
and decision making across these domains is seriously impaired.
What is part of the enterprise architecture, and what is only an implementation
within that architecture, is a matter of what the business defines to be the architec-
ture, and what not. The architecture marks the separation between what should not
be tampered with and what can be filled in more freely. This places a high demand
for quality on the architecture. Quality means that the architecture actually helps in
achieving essential business objectives. In constructing and maintaining an archi-
tecture, choices should therefore be related to the business objectives, i.e., they
should be rational.
Even though an architecture captures the relatively stable parts of business and
technology, any architecture will need to accommodate and facilitate change, and
architecture products will therefore only have a temporary status. Architectures
change because the environment changes and new technological opportunities
arise, and because of new insights as to what is essential to the business. To ensure
that these essentials are discussed, a good architecture clearly shows the relation of
the architectural decisions to the business objectives of the enterprise.
The instruments needed for creating and using enterprise architectures are still in
their infancy. To create an integrated perspective of an enterprise, we need
techniques for describing architectures in a coherent way and communicating
these with all relevant stakeholders. Different types of stakeholders will have
their own viewpoints on the architecture. Furthermore, architectures are subject
to change, and methods to analyse the effects of these changes are necessary in
planning future developments. Often, an enterprise architect has to rely on existing
methods and techniques from disparate domains, without being able to create
the ‘big picture’ that puts these domains together. This requires an integrated set
of methods and techniques for the specification, analysis, and communication of
enterprise architectures that fulfils the needs of the different types of stakeholders
involved. In this book, we will introduce such an approach. Architecture models,
views, presentations, and analyses all help to bridge the ‘communication gap’
between architects and stakeholders (Fig. 1.1).
Of course, architects play a central role in this process. In this book, we will not
go deeper into the various compentencies and skills they needs, but we refer the
reader to (Wieringa et al. 2008) and (Op ’t Land et al. 2008, Chap. 6) for more on
this subject.
1.3 The Architecture Process
Architecture is a process as well as a product. The product serves to guide managers
in designing business processes and system developers in building applications in a
way that is in line with business objectives and policies. The effects of the process

reach further than the mere creation of the architecture product – the awareness of
stakeholders with respect to business objectives and information flow will be raised.
Also, once the architecture is created, it needs to be maintained. Businesses and IT
are continually changing. This constant evolution is, ideally, a rational process.
Change should only be initiated when people in power see an opportunity to
strengthen business objectives.
The architecture process consists of the usual steps that take an initial idea through
design and implementation phases to an operational system, and finally changing or
replacing this system, closing the loop. In all of the phases of the architecture process,
clear communication with and between stakeholders is indispensable. The architec-
ture descriptions undergo a life cycle that corresponds to this design process (Fig. 1.2).
The different architecture products in this life cycle are discussed with stakeholders,
approved, revised, etc., and play a central role in establishing a common frame of
reference for all those involved.
1.4 Drivers for Enterprise Architecture
It need not be stressed that any organisation benefits from having a clear under-
standing of its structure, products, operations, technology, and the web of relations
tying these together and connecting the organisation to its surroundings. Further-
more, there are external pressures to take into account, both from customers,
suppliers, and other business partners, and from regulatory bodies. Especially if a
company becomes larger and more complicated, good architectural practice
becomes indispensable. Here, we briefly outline the most important and commonly
recognised internal and external drivers for establishing an enterprise architecture.
Models
Architects
Presentation
View
Stakeholders
viewpoint
Analysis
analysis question
Fig. 1.1 Communicating about architecture
1.4 Drivers for Enterprise Architecture 5

1.4.1 Internal Drivers
Business–IT alignment is commonly recognised as an important instrument to realise
organisational effectiveness. Such effectiveness is not obtained by local optimisations,
but is realised by well-orchestrated interaction of organisational components (Nadler
et al. 1992). Effectiveness is driven by the relationships between components rather
than by the detailed specification of each individual component. A vast amount of
literature has been written on the topic of alignment, underlining the significance of
both ‘soft’ and ‘hard’ components of an organisation.
Parker and Benson (1989) were forerunners in using the term ‘alignment’ in
this context and emphasising the role of architecture in strategic planning. The
well-known strategic alignment model of Henderson and Venkatraman (1993)
distinguishes between the aspects of business strategy and organisational infrastruc-
ture on the one hand, and IT strategy and IT infrastructure on the other hand
(Fig. 1.3). The model provides four dominant perspectives that are used to tackle
the alignment between these aspects. One can take the business strategy of an
enterprise as the starting point, and derive its IT infrastructure either via an IT
strategy or through the organisational infrastructure; conversely, one can focus on
IT as an enabler and start from the IT strategy, deriving the organisational infra-
structure via a business strategy or based on the IT infrastructure. In any of these
perspectives, an enterprise architecture can be a valuable help in executing the
business or IT strategy.
Nadler et al. (1992) identify four relevant alignment components: work, people,
the formal organisation and the informal organisation. Labovitz and Rosansky
(1997) emphasise the horizontal and vertical alignment dimensions of an
organisation. Vertical alignment describes the relation between the top strategy
and the people at the bottom, whereas horizontal alignment describes the relation
Idea
Design
Use
Management
Formal models
Analysis
Napkin
Whiteboard
PowerPoint
Link with
implementation
Maintenance
Version control
Visualisation
for different
stakeholders
Architecture
process
Fig. 1.2 The architecture description life cycle

between internal processes and external customers. Obviously, the world of
business–IT alignment is as diverse as it is complex. In coping with this complexity,
enterprise architecture is of valuable assistance.
In Fig. 1.4, enterprise architecture is positioned within the context of managing
the enterprise. At the top of this pyramid, we see the mission of the enterprise: why
does it exist? The vision states its ‘image of the future’ and the values the enterprise
holds. Next there is its strategy, which states the route the enterprise will take in
achieving this mission and vision. This is translated into concrete goals that give
direction and provide the milestones in executing the strategy. Translating those
goals into concrete changes to the daily operations of the company is where
enterprise architecture comes into play. It offers a holistic perspective of the current
and future operations, and on the actions that should be taken to achieve the
company’s goals.
Next to its architecture, which could be viewed as the ‘hard’ part of the
company, the ‘soft’ part, its culture, is formed by its people and leadership, and is
of equal if not higher importance in achieving these goals. Finally, of course, we see
the enterprise’s daily operations, which are governed by the pyramid of Fig. 1.4.
To some it may seem that architecture is something static, confining everything
within its rules and boundaries, and hampering innovation. This is a misconception.
A well-defined architecture is an important asset in positioning new developments
within the context of the existing processes, IT systems, and other assets of an
organisation, and it helps in identifying necessary changes. Thus, good architectural
practice helps a company innovate and change by providing both stability and
flexibility. The insights provided by an enterprise architecture are needed on the
one hand in determining the needs and priorities for change from a business
Organisational
infrastructure
and processes
External
Business Information Technology
Functional Integration
Strategic Fit
Internal
IT infrastructure
and processes
Business
Strategy
IT Strategy
Fig. 1.3 Strategic alignment model (Henderson and Venkatraman 1993)

perspective, and on the other hand in assessing how the company may benefit from
technological and business innovations.
Moreover, architecture is a strategic instrument in guiding an organisation
through a planned course of development. As Ross et al. (2006) show with
numerous case studies, successful enterprises employ an ‘operating model’ with
clear choices on the levels of integration and standardisation of business processes
across the enterprise (Fig. 1.5). This operating model should fit both their area of
business and their stage of development.
Mission
Goals
Strategy
Actions
Vision
as is to be
enterprise architecture culture
domain/aspect
architectures people
leadership
Operations
… people
processes IT
products
Fig. 1.4 Enterprise architecture as a management instrument
Coordination Unification
Diversification Replication
Standardisation of
business processes
Data
integration
Low High
High
Fig. 1.5 Operating model (Ross et al. 2006)

Ross et al. explain the role of enterprise architecture as the organizing logic for
business processes and IT infrastructure, which must reflect the integration and
standardisation requirements of the operating model. They also describe the
‘engagement model’, i.e., the governance needed to ensure that business and IT
projects meet local and corporate objectives and conform to the enterprise
architecture.
Finally, in an increasingly networked world, no enterprise can focus solely on its
own operations. To get to grips with the wealth of interconnections with customers,
suppliers, and other partners, an enterprise architecture is a valuable asset. A promi-
nent example of this is outsourcing part of a company’s business processes and/or IT
operations. For any sourcing project to be successful, it is paramount to have a clear
insight into precisely what the activities and responsibilities are of all the partners
involved, and what the services and interfaces between these partners are.
1.4.2 External Drivers
Next to the internal drive to execute effectively an organisation’s strategy and
optimise its operations, there are also external pressures that push organisations
towards adopting enterprise architecture practice. The regulatory framework
increasingly demands that companies and governmental institutions can prove
that they have a clear insight into their operations and that they comply with the
applicable laws on, say, financial transactions.
In the USA, the Clinger–Cohen Act (1996), also known as the Information
Technology Management Reform Act, demands that every government agency
must have an IT architecture, which is defined as: ‘an integrated framework for
evolving or maintaining existing information technology and acquiring new infor-
mation technology to achieve the agency’s strategic goals and information
resources management goals.’ Section 5125 (b) of the Act assigns the Agency
Chief Information Officer (CIO) the responsibility of ‘developing, maintaining, and
facilitating the implementation of a sound and integrated information technology
architecture.’ The US Department of Defense even requires all IT to comply with
this Act, including that in weapons and weapons system programmes.
The Clinger–Cohen Act has been an important stimulus for the development of
enterprise architecture as a discipline, not just in a government context, but in
general. Although most European governments do not impose such strict
requirements on their agencies, these architecture practices are making inroads in
Europe as well.
The capital adequacy framework known as Basel II (2004), endorsed by the
central bank governors and the heads of bank supervisory authorities in the Group
of Ten (G10) countries, puts requirements on banking organisations with respect
to their financial risk management, to promote stability in the financial world.
The Basel II framework imposes strict regulations on banks in terms of risk
measurement and management, with wide-ranging implications for both their

organisations and their IT systems. The framework provides explicit incentives in
the form of lower capital requirements for banks to adopt more comprehensive and
accurate measures of risk as well as more effective processes for controlling their
exposures to risk. This encompasses both credit risk and operational risk, the latter
being defined as the risk of loss resulting from inadequate or failed internal
processes, people and systems or from external events. Given this wide scope and
the detailed requirements on risk management, compliance with Basel II can hardly
be envisaged without a sound architectural approach.
Another US act, the Sarbanes–Oxley Act (2002), also has a major impact. This
act, formally known as the Public Company Accounting Reform and Investor
Protection Act, was drawn up in the aftermath of the Enron scandal, to force
companies to adopt good corporate governance practices and to make company
executives personally accountable. These accountability regulations make it very
important for a company that it is clear what the responsibilities of each employee
are. IT systems must provide the necessary accounting information to be able to
perform the audits required by the Act, and should enforce their users to have
appropriate authorisation. Again, enterprise architecture may be of assistance in
providing the necessary insight, and many companies are improving their architec-
ture practice to conform to these regulations. And given that this Act applies to all
companies that have their stocks quoted on the US stock exchanges, it has a
worldwide impact.
1.5 Summary
Architecture is the art and science of designing complex structures. Enterprise
architecture, more specifically, is defined as a coherent whole of principles,
methods, and models that are used in the design and realisation of an enterprise’s
organisational structure, business processes, information systems, and infrastruc-
ture. Architecture models, views, presentations, and analyses all help to bridge the
‘communication gap’ between architects and stakeholders.
Architecture is an indispensable instrument in controlling the complexity of the
enterprise and its processes and systems. On the one hand, we see internal drivers
for using an architectural approach, related to the strategy execution of an
organisation. Better alignment between business and IT leads to lower cost, higher
quality, better time-to-market, and greater customer satisfaction. On the other hand,
external drivers from regulatory authorities and other pressures necessitate
companies to have a thorough insight into their structure and operations. All of
these drivers make a clear case for the use of enterprise architecture.

Chapter 2
State of the Art
This chapter gives an overview of currently used methods and techniques in
enterprise architecture. Naturally, this description is a snapshot, and we cannot
claim to be exhaustive, since the field of enterprise architecture is evolving rapidly.
However, it provides this broad overview of current methods and techniques to give
the reader an impression of the advances in this field.
First, we position enterprise architecture relative to a number of well-known
standards and best practices in general and IT management. Second, we outline
the most important frameworks and methods for enterprise architecture currently
in use. Next, we discuss service orientation, the most important architectural
paradigm that has emerged over the last few years. Finally, we describe a number
of relevant languages for modelling organisations, business processes, applications,
and technology.
Based upon this state of the art, in the next chapter we will describe what we see
as missing in current methods and techniques, and how our own approach tries to
fill some of these gaps.
2.1 Enterprise Architecture and Other Governance
Instruments
Enterprise architecture is typically used as an instrument in managing a company’s
daily operations and future development. But how does it fit in with other
established management practices and instruments?
Here, we describe how enterprise architecture is positioned within the context of
corporate and IT governance by relating it to a number of well-known best practices
and standards in general and IT management, as outlined in Fig. 2.1. In the next
subsections, we will outline the relation of enterprise architecture with some
well-known management practices in each of these areas, not to be exhaustive
M. Lankhorst et al., Enterprise Architecture at Work, The Enterprise
Engineering Series, DOI 10.1007/978-3-642-29651-2_2,
# Springer-Verlag Berlin Heidelberg 2013
11

but to show the position and role of enterprise architecture in a management
context:
– strategic management: the Balanced Scorecard;
– strategy execution: EFQM;
– quality management: ISO 9001;
– IT governance: COBIT;
– IT delivery and support: ITIL;
– IT implementation: CMM and CMMI.
Others have also written extensively on this role of enterprise architecture as a
governance instrument; see e.g. (Ross et al. 2006).
2.1.1 Strategic Management: Balanced Scorecard
Kaplan and Norton (1992) introduced the balanced scorecard (BSC) as a manage-
ment system that helps an enterprise to clarify and implement its vision and
strategy. Traditionally, management focus has strongly been on financial aspects.
Kaplan and Norton argue that financial measures alone are inadequate to guide the
future development of an organisation, and that they should be supplemented with
measures concerning customer satisfaction, internal processes, and the ability to
innovate.
The BSC therefore suggests viewing an enterprise from four perspectives. The
Customer perspective asks how the enterprise should appear to its customers, with
measures like customer satisfaction. The Financial perspective is focused on the
business value created by the enterprise, entailing measures such as shareholder
value. The Internal Business Processes perspective looks at the effectiveness
and efficiency of a company’s internal operations, paying special attention to the
primary, mission-oriented processes. Finally, the Learning and Growth perspective
addresses the corporate and individual ability to change and improve, which is
Strategic
Management
Strategy
Execution
Quality
Management
IT Governance
IT Delivery & Support
IT Implementation
General Management IT Management
Fig. 2.1 Management areas relevant to enterprise architecture
12 2 State of the Art

critical to any knowledge-intensive organisation. For each of the four perspectives
the BSC proposes a three-layered structure:
1. mission (e.g., to become the customers’ preferred supplier);
2. objectives (e.g., to provide the customers with new products);
3. measures (e.g., percentage of turnover generated by new products).
To put the BSC to work, a company should first define its mission, objectives,
and measures for each perspective, and then translate these into a number of
appropriate targets and initiatives to achieve these goals.
What is important in the BSC is the notion of double-loop feedback. First of all,
one should measure the outputs of internal business processes and not only fix
defects in these outputs but also identify and remedy the causes of these defects.
Moreover, such a feedback loop should also be instituted for the outcomes of
business strategies. Performance measurement and management by fact are central
to the BSC approach.
If we look at the role of enterprise architecture as a management instrument, it
would be especially useful within the Internal Business Processes perspective of the
BSC. Many operational metrics can be tied to a well-defined enterprise architecture
and various performance analyses might be carried out. However, enterprise archi-
tecture has a broader use. In the Learning and Growth perspective, a company’s
ability to evolve, to anticipate, and to respond to a changing environment is vital.
To determine an organisation’s agility, it is important to assess what the impact and
feasibility of future changes might be. Impact analysis of an enterprise architecture
may assist in such an assessment.
2.1.2 Strategy Execution: EFQM
Another important management approach is the EFQM (European Foundation
for Quality Management) Excellence Model (EFQM 2003). This model was first
introduced in 1992 as the framework for assessing applications for The European
Quality Award, and was inspired by the Malcolm Baldridge Model in the USA and
the Deming Prize in Japan.
The EFQM model has a much broader scope than ISO 9001 (see Sect. 2.1.3).
It not only focuses on quality management, but provides an overall management
framework for performance excellence of the entire organisation. The EFQM
model consists of nine criteria for excellence, five of which are ‘enablers’, covering
what an organisation does, and four are ‘results’, covering what that organisation
achieves. These criteria and their mutual relationships are shown in diagrammatic
form in Fig. 2.2. Leadership and Policy & Strategy determine the direction and
focus of the enterprise; based on this, the People of the enterprise, its Partnerships &
Resources, and its Processes make it happen; stakeholders of the results achieved
are its Customers, its People, and Society in general; and these stakeholder results
contribute to the enterprise’s Key Performance Results, which comprise both
2.1 Enterprise Architecture and Other Governance Instruments 13

financial and non-financial aspects. The EFQM model provides principles,
measures, and indicators for assessing the performance of an enterprise in all of
these aspects, and these measurements are the basis for continuous learning,
innovation, and improvement.
All this also points to the main difference between the EFQM model and the
BSC: whereas the latter is focused on developing effective strategic management,
the former concentrates on measuring and benchmarking the performance of
an organisation with respect to a number of best practices. Both are complementary:
the BSC helps to make strategic choices, and the EFQM model assists in continuous
improvement necessary to execute this strategy.
Positioning enterprise architecture with respect to the EFQM model, we view it
especially as an important instrument for the Policy & Strategy and the Processes
aspects. Based on its mission and vision, an organisation will determine the policies
and strategies needed to meet the present and future needs and expectations of
its stakeholders. An enterprise architecture is a valuable instrument in operatio-
nalising and implementing these policies and strategies. First of all, it offers insight
into the structure and operation of the enterprise as a whole by creating a bird’s-eye
view of its organisational structure, business processes, information systems, and
infrastructure. Such an overview is indispensable when formulating a coherent
strategy. Furthermore, an enterprise architecture helps in developing, managing,
and communicating company-wide standards of operation, needed to ensure that
company policies are indeed implemented. Finally, by providing a better under-
standing of the effects of changes, it is of valuable assistance in creating roadmaps
for the future, needed to assess and execute the longer-term enterprise strategy.
Partnerships
& Resources
Leader-
Ship
Processes
People
Policy &
Strategy
Key
Performance
Results
People
Results
Customer
Results
Society
Results
Innovation & Learning
Enablers Results
Fig. 2.2 The EFQM Excellence Model (EFQM 2003)

2.1.3 Quality Management: ISO 9001
The ISO 9001:2000 standard (ISO 2000) of the International Organisation for
Standardisation (ISO) outlines criteria for a good quality management system
(QMS). Based on a quality policy and quality goals, a company designs and
documents a QMS to control how processes are performed. The requirements of
the standard cover everything from how a company plans its business processes, to
how these are carried out, measured, and improved.
Starting from general, overall requirements, the standard states the responsi-
bilities of management for the QMS. It then gives requirements for resources,
including personnel, training, the facility, and work environment. The demands
on what is called ‘product realisation’, i.e., the business processes that realise the
company’s product or service are the core of the standard. Key processes, i.e., those
processes that affect product or service quality, must be identified and documented.
This includes planning, customer-related processes, design, purchasing, and
process control. Finally, requirements are put on measurement, analysis, and
improvement of these business processes. Once the quality system is installed, a
company can request an audit by a Registrar. If it conforms to all the criteria, the
company will be ISO 9001 registered.
Although the standard has earned a reputation as being very ‘document-heavy’,
this mainly pertains to its previous versions of 1987 and 1994. Notwithstanding
these criticisms, the business value of a good QMS is universally acknowledged.
In Europe, industrial companies increasingly require ISO 9001 registration from
their suppliers, and the universal acceptance as an international standard is growing.
Looking at enterprise architecture from the perspective of quality management in
general and ISO 9001 in particular, we see its main contribution in the integrated
design, management and documentation of business processes, and their supporting
IT systems. A well-designed and documented enterprise architecture helps an
organisation to conform to the ISO 9001 requirements on process identification
and documentation; conversely, the need for a QMS may direct focus to an enterprise
architecture initiative, by putting the emphasis on those processes and resources that
are critical for the company’s product or service quality. In this way, quality
management and enterprise architecture form a natural combination: the former is
concerned with what needs to be designed, documented, controlled, measured, and
improved, and the latter determines how these high-quality processes and resources
are organised and realised.
2.1.4 IT Governance: COBIT
The COBIT (Control Objectives for Information and related Technology) standard
for IT governance was initially published in 1996 by the Information Systems Audit
and Control Association. Now in its the third edition, issued in 2000 by the IT

Governance Institute (COBIT 2000), COBIT, an internationally accepted IT control
framework that provides organisations with ‘good practices’ that help in
implementing an IT governance structure throughout the enterprise. It aims to
bridge the gaps between business risks, control needs, and technical issues. The
basic premise of COBIT is that in order to provide the information that the
organisation needs to achieve its objectives, IT resources need to be managed by
a set of naturally grouped processes.
The core of the COBIT framework are the control objectives and management
guidelines for 34 identified IT processes, which are grouped into four domains:
planning and organisation, acquisition and implementation, delivery and support,
and monitoring. Here, ‘control’ is defined by COBIT as the policies, procedures,
practices, and organisational structures designed to provide reasonable assurance
that business objectives will be achieved and that undesired events will be
prevented or detected and corrected. The control objectives can help to support
IT governance within an enterprise. For example, the control objectives of the
‘Assist and advise IT customers’ process consist of establishing a help desk,
registration of the customer queries, customer query escalation, monitoring of
clearance, and trend analysis and reporting.
Next to the framework of control objectives, COBIT provides critical success
factors for achieving optimal control over IT processes, key goal indicators, which
measure whether an IT process has met its business requirements, and key perfor-
mance indicators, which define measures of how well the IT process is performing
towards achieving its goals.
COBIT also offers a maturity model for IT governance, consisting of five
maturity levels:
1. Ad Hoc: There are no standardised processes. Ad hoc approaches are applied on
a case-by-case basis.
2. Repeatable: Management is aware of the issues. Performance indicators are
being developed, basic measurements have been identified, as have assessment
methods and techniques.
3. Defined: The need to act is understood and accepted. Procedures have been
standardised, documented, and implemented. BSC ideas are being adopted by
the organisation.
4. Managed: Full understanding of issues on all levels has been reached. Process
excellence is built on a formal training curriculum. IT is fully aligned with the
business strategy.
5. Optimised: Continuous improvement is the defining characteristic. Processes
have been refined to the level of external best practices based on the results of
continuous improvement with other organisations.
This maturity model closely resembles the Capability Maturity Model (CMM)
for software development and its successor the CMMI (see Sect. 2.1.6).
According to COBIT, well-defined architectures are the basis for a good internal
control environment. In many enterprises, the IT organisation will be responsible
for establishing and maintaining the enterprise architecture. Whereas COBIT

focuses on how one should organise the (secondary) IT function of an organisation,
enterprise architecture concentrates on the (primary) business and IT structures,
processes, information and technology of the enterprise. Thus, enterprise architec-
ture forms a natural complement to COBIT. Relative to the maturity levels of
COBIT, enterprise architecture will of course be most relevant in the upper level. At
the Repeatable level, a first awareness of the value of architecture may arise, but
there is typically no established architectural practice at the enterprise level. Only
from the Defined level upwards is it recognised and used as an important instrument
in planning and managing IT developments in coordination with business needs.
2.1.5 IT Service Delivery and Support: ITIL
ITIL (IT Infrastructure Library) (Hanna et al. 2008) is the most widely accepted set
of best practices in the IT service delivery domain. It was originally developed by
the UK Office of Government Commerce (OGC), to improve management of IT
services in the UK central government. The OGC’s objectives were on the one hand
to create a comprehensive and consistent set of best practices for quality IT service
management, and on the other hand to encourage the private sector to develop
training, consultancy, and tools that support ITIL. Over the years, ITIL has gained
broad support and has become the worldwide de facto standard for IT service
management. The ITIL users group, the IT Service Management Forum (itSMF1
),
actively promotes the exchange of information and experiences to help IT service
providers manage service delivery.
ITIL comprises a series of documents giving guidance on the provision of good IT
services, and on the facilities needed to support IT. ITIL has a process-oriented
approach to service management. It provides codes of practice that help organisations
to establish quality management of their IT services and infrastructure, where
‘quality’ is defined as ‘matched to business needs and user requirements as these
evolve.’ It does this by providing guidance on the design and implementation of
the various processes within the IT organisation. The core of ITIL consists of two
broad groups of processes:
– Service Delivery, comprising service-level management, availability manage-
ment, financial management for IT services, IT service contingency management,
and capacity management;
– Service Support, covering problem management, incident management, service
desk, change management, release management, and configuration management.
ITIL is complementary to COBIT. The high-level control objectives of COBIT
can be implemented through the use of ITIL. Its help desk module, for example,
1
http://www.itsmf.com

complements and provides details on the help desk process including the planning,
implementation, post-implementation, benefits and costs, and tools. So, COBIT’s
control objectives tell what to do and ITIL explains how to do it, i.e., what the
best-practice processes are to realise these objectives.
Management of the IT assets of an organisation is central to ITIL. This is where a
well-developed enterprise architecture is very valuable. It provides IT managers
with a clear understanding of the IT applications and infrastructure, the related
business processes, and the various dependencies between these domains. Nearly
all of the core processes identified by ITIL will benefit from this.
2.1.6 IT Implementation: CMM and CMMI
The Capability Maturity Model for Software (Paulk et al. 1993), also known as the
CMM and SW-CMM, is a model for judging the maturity of an organisation’s
software engineering processes, and provides organisations with key practices
required to help them increase the maturity of these processes. In 2000, the
SW-CMM was upgraded to CMMI (Capability Maturity Model Integration),
which addresses the integration of software development with other engineering
activities and expands the scope to encompass the entire product life cycle, includ-
ing systems engineering, integrated product and process development, and supplier
sourcing. The CMM’s popularity has sparked off the development of similar
maturity models in other fields, including enterprise architecture; see, e.g., the
NASCIO Enterprise Architecture Maturity Model (NASCIO 2003).
In the CMMI maturity models in their most common form, there are five
maturity levels, each a layer in the foundation for ongoing process improvement,
designated by the numbers 1 to 5 (CMMI Product Team 2002):
1. Initial: Processes are usually ad hoc and chaotic. The organisation does not
provide a stable environment. Success in these organisations depends on the
competence and heroics of the people in the organisation and not on the use of
proven processes.
2. Managed: The projects of the organisation have ensured that requirements are
managed and that processes are planned, performed, measured, and controlled.
However, processes may be quite different in each specific instance, e.g., on a
particular project.
3. Defined: Processes are well characterised and understood, and are described in
standards, procedures, tools, and methods. These standards are used to establish
consistency across the organisation. Projects establish their defined processes
by tailoring the organisation’s set of standard processes according to tailoring
guidelines.
4. Quantitatively Managed: Quantitative objectives for quality and process per-
formance are established and used as criteria in managing processes.

Quantitative objectives are based on the needs of the customer, end users,
organisation, and process implementers.
5. Optimising: Process performance is continually improved through both
incremental and innovative technological improvements. Quantitative process-
improvement objectives for the organisation are established, continually revised
to reflect changing business objectives, and used as criteria in managing process
improvement.
The CMMI provides numerous guidelines for assessing the maturity of an
organisation and the improvements needed in various process areas to proceed
from one level to the next. Next to this familiar staged representation of the maturity
model in terms of consecutive maturity levels, there is now a continuous representa-
tion as well.
In any software engineering project of substantial size, software architecture
plays an important role. The context of this software architecture may be given by
an enterprise architecture, which provides constraints and guidelines for individual
software projects. As such, enterprise architecture is something that becomes
especially useful (or even necessary) at CMMI Level 3 and beyond, where projects
have to conform to organisation-wide standards and guidelines.
2.2 Methods and Frameworks
To provide more insight into the different aspects that an enterprise architecture
model may encompass, we will outline a number of well-known architecture
frameworks. Frameworks structure architecture description techniques by
identifying and relating different architectural viewpoints and the modelling
techniques associated with them. They do not provide the concepts for the actual
modelling, although some frameworks are closely connected to a specific
modelling language or set of languages.
Most architecture frameworks are quite precise in establishing what elements
should be part of an enterprise architecture. However, to ensure the quality of the
enterprise architecture during its life cycle the adoption of a certain framework is
not sufficient. The relations between the different types of domains, views, or layers
of the architecture must remain clear, and any change should be carried through
methodically in all of them. For this purpose, a number of methods are available,
which assist architects through all phases of the life cycle of architectures.
2.2.1 Enterprise Architecture Methods
An architecture method is a structured collection of techniques and process steps for
creating and maintaining an enterprise architecture. Methods typically specify the
2.2 Methods and Frameworks 19

various phases of an architecture’s life cycle, what deliverables should be produced
at each stage, and how they are verified or tested. The following methods for
architecture development are worth mentioning:
– Although meant for software development, the Rational Unified Process (RUP)
(Jacobson et al. 1999) is of interest here, as it defines an iterative process, as
opposed to the classical waterfall process, that realises software by adding
functionality to the architecture at each increment. An extension towards enter-
prise IT architecture is given by McGovern et al. (2004) in the form of the
Enterprise Unified Process.
– The UN/CEFACT Modelling Methodology (UMM) is an incremental business
process and information model construction methodology. The scope is
intentionally restricted to business operations, omitting technology-specific
aspects. The Business Collaboration Framework (BCF), which is currently
under development, will be a specialisation of the UMM aimed at defining
an enterprise’s external information exchanges and their underlying business
activities. See UN/CEFACT (2004).
– The TOGAF Architecture Development Method (ADM) (see Sect. 2.2.4), devel-
oped by The Open Group, provides a detailed and well-described phasing for
developing an IT architecture. The current version of TOGAF (The Open Group
2011) provides a framework and development method for developing enterprise
architectures.
– The Chief Information Officers Council has created The Federal Enterprise
Architecture Framework (FEAF) accompanied by a practical and useful manual
for developing enterprise architecture for governmental organisations (CIO
Council 2004). Other initiatives of the US government include the Federal
Enterprise Architecture (FEA) of the Federal Enterprise Architecture Program
Management Office (FEAPMO 2004) and the Treasury Architecture Develop-
ment Process by the Department of the Treasury (US Treasury 2004).
Various consulting companies have developed their own architecture methods and
frameworks. Examples include Sogeti’s DYA, Capgemini’s IAF, IBM’s Enterprise
Architecture method, and Microsoft’s Motion. Because of the often proprietary
nature of these methods, we do not discuss them in this book.
2.2.2 The IEEE 1471–2000/ISO/IEC 42010 Standard
In 2000, the IEEE Computer Society approved IEEE Standard 1471-2000 (IEEE
Computer Society 2000), which builds a solid theoretical base for the definition,
analysis, and description of system architectures. IEEE 1471, which has since been
subsumed by the ISO/IEC 42010 standard (ISO/IEC/IEEE 2011), focuses mainly
on software-intensive systems, such as information systems, embedded systems,
and composite systems in the context of computing. IEEE 1471 uses the civil
architecture metaphor to describe software system architectures. In this sense,

it is similar to the framework of Zachman (see Sect. 2.2.3), although it does not try
to standardise the system architecture by establishing a fixed number, or the nature
of views (as in the case of the 36 cells of Zachman’s framework). IEEE 1471 also
does not try to standardise the process of developing architectures, and therefore
does not recommend any modelling languages, methodologies, or standards.
Instead, IEEE 1471 provides, in the terms of a ‘recommended practice’, a number
of valuable concepts and terms of reference, which reflect the ‘generally accepted
trends in practice for architecture description’ and which ‘codify those elements on
which there is consensus’.
First of all, the standard gives a set of definitions for key terms such as acquirer,
architect, architecture description, architectural models, architecture, life cycle
model, system, system stakeholder, concerns, mission, context, architectural
view, architectural viewpoint. As essential ideas we note a clear separation
between an architecture and its architecture descriptions (defined as means to
record architectures), and the central role of the relationship between architectural
viewpoint and architectural view. The standard also provides a conceptual frame-
work, which is meant:
– to explain how the key terms relate to each other in a conceptual model for
architecture description (this model is shown in Fig. 2.3 and uses the UML
notation for class diagrams (see also Sect. 2.3.5));
– to explain the role of the stakeholders in the creation and use of an architecture
description;
Environment
Concern
has source
0..1
used to
cover 1..*
provides
identifies
1..*
is addressed
to 1..*
has
1..*
has
1..*
is important
to 1..*
fulfills
1..*
inhabits
influences
Mission
System
Stakeholder
Architecture
Architectural
Description
Rationale
View
Viewpoint
Library
Viewpoint
Model
aggregates
1..*
consists of
1..*
participates in
1..*
establish methods for
1..*
conforms to
participates
in
organised
by 1..*
selects
1..*
identifies
1..*
has
1..*
has an
described
by 1
fulfills
1..*
Fig. 2.3 Conceptual model of architecture description (based on IEEE Computer Society 2000)
2.2 Methods and Frameworks 21

– to provide a number of scenarios for the architectural activities during the life
cycle: architectures of single systems, iterative architecture for evolutionary
systems, architecture for existing systems, and architectural evaluation.
Furthermore, the standard gives six architecture description practices:
– Architectural documentation referring to identification, version, and overview
information.
– Identification of the system stakeholders and of their concerns, established to be
relevant to the architecture.
– Selection of architectural viewpoints, containing the specification of each view-
point that has been selected to organise the representation of the architecture and
the reasons for which it was selected.
– Architectural views corresponding to the selected viewpoints.
– Consistency among architectural views.
– Architectural rationale for the selection of the current architecture from a
number of considered alternatives.
IEEE 1471 also provides a number of relevant architectural viewpoints together
with their specifications in terms of concerns, languages, and modelling and
analysis methods (see Annex D of the standard). It is important to note that
architecture descriptions that are compliant with IEEE 1471 can be used to meet
the requirements of other standards, like the Reference Model of Open Distributed
Processing (described in Sect. 2.2.6).
2.2.3 The Zachman Framework
In 1987, John Zachman introduced the first and best-known enterprise architecture
framework (Zachman 1987), although back then it was called ‘Framework for
Information Systems Architecture’. The framework as it applies to enterprises is
simply a logical structure for classifying and organising the descriptive
representations of an enterprise that are significant to the management of the
enterprise as well as to the development of the enterprise’s systems.
The framework (Fig. 2.4) in its most simple form depicts the design artefacts that
constitute the intersection between the roles in the design process: that is, owner,
designer, and builder; and the product abstractions: that is, what (material) it is
made of, how (process) it works and where (geometry) the components are relative
to one another. Empirically, in the older disciplines, some other ‘artefacts’ were
observable that were being used for scoping and for implementation purposes.
These roles are somewhat arbitrarily labelled planner and subcontractor and are
included in the framework graphic that is commonly exhibited.
From the very inception of the framework, some other product abstractions were
known to exist because it was obvious that in addition to what, how, and where, a
complete description would necessarily have to include the remaining primitive
interrogatives: who, when and why. These three additional interrogatives would be

Marc Lankhorst (auth.) - Enterprise Architecture at Work_ Modelling, Communication and Analysis.pdf

Marc Lankhorst (auth.) - Enterprise Architecture at Work_ Modelling, Communication and Analysis.pdf

Related slideshows

More Related Content

Marc Lankhorst (auth.) - Enterprise Architecture at Work_ Modelling, Communication and Analysis.pdf