This is an example version of the book: Delivering Enterprise Architecture with TOGAF and ArchiMate To celebrate our position in the Leaders Quadrant we published a special edition of our book Delivering Enterprise Architecture with TOGAF and ArchiMate. In this free ebook Delivering Business Outcome with TOGAF and ArchiMate with a foreword from Mike the Architect (http://www.mikethearchitect.com/) - Mike Walker, we provide vital information to help enterprise architects to realistically apply architecture modeling to their architecture engagements. When you are interested in reading, we recommend you to contact our sales department at: insidesales@bizzdesign.com. They can help you to purchase this book. Enjoy reading BiZZdesign www.bizzdesign.com Building Strong Organizations BiZZdesign www.bizzdesign.com Building Strong Organizations
Delivering business outcome with TOGAF and ArchiMate Maria-Eugenia Iacob Henk Jonkers Dick Quartel Henry Franken Harmen van den Berg
Delivering Business Outcome With TOGAF and Archimate Maria-Eugenia Iacob School of Management and Governance, University of Twente Henk Jonkers BiZZdesign Dick Quartel BiZZdesign Henry Franken BiZZdesign Harmen van den Berg BiZZdesign ISBN 978-90-79240-00-5 We acknowledge The Open Group for permission to include text and figures derived from its copyrighted TOGAF Version 9.1 and ArchiMate 2.0 standards. TOGAF and ArchiMate are registered trademarks of The Open Group
Table of contents Foreword from Mike Walker...7 Foreword from The Open Group...9 Preface by Henry Franken... 11 1. introduction: THE CASE FOR ENTERPRISE ARCHITECTURE...17 1.1 An integrated perspective on organizations...17 1.2 Why Enterprise Architecture?...21 1.3 Frameworks, languages and standards for Enterprise Architecture...22 1.4 Organization of this book...27 2. THE WAY OF THINKING...29 2.1 the Definition of Enterprise Architecture...29 2.2 the Role of EA in Linking Strategy to Design and Execution...30 2.3 drivers for Enterprise Architecture...31 2.4 ingredients of an Integrated Enterprise Architecture Framework...35 2.4.1 Methodological Framework (based on TOGAF )...37 2.4.2 Modelling Framework (based on ArchiMate )...38 3. THE WAY OF MODELLING: ARCHIMATE...43 3.1 ArchiMate Core...43 3.1.1 Modelling services...43 3.1.2 Modelling the business layer...46 business structure...46 business behaviour...49 business Information...52 summary of the business layer...56 3.1.3 Modelling the application layer...58 Application structure and behaviour...58 Application information...62 summary of the application layer...63 3.1.4 Modelling the Technology layer...64 summary of technology domain...70 3.1.5 Modelling relationships...71 structural relationships...71 derived relationships...73 dynamic relationships...74 other relationships...75 summary of relationships...77 3.2 Motivation extension...78 stakeholders, drivers and assessments...78 goals, principles and requirements...80 relationships for the motivation extension...82 summary of the motivation extension...84 3
Table of contents 3.3 Implementation and migration extension...85 modelling work packages...85 modelling migration...87 summary of the implementation and migration extension...89 3.4 Alignment between the ArchiMate core and the Motivation and the implementation and Migration extensions...90 4. THE WAY OF MODELLING VIEWPOINTS AND VIEWS...93 4.1 ArchiMate core viewpoints...94 4.1.1 Organization Viewpoint...97 4.1.2 Actor cooperation viewpoint...98 4.1.3 Business function viewpoint...99 4.1.4 Business process viewpoint...101 4.1.5 Business process cooperation viewpoint...102 4.1.6 Product viewpoint...104 4.1.7 Application behaviour viewpoint...105 4.1.8 Application cooperation viewpoint...106 4.1.9 Application structure viewpoint...107 4.1.10 Technical infrastructure viewpoint...108 4.1.11 Implementation and deployment viewpoint...109 4.1.12 Information structure viewpoint... 110 4.1.13 Service realization viewpoint...111 4.1.14 Layered viewpoint... 112 4.1.15 Landscape map viewpoint... 115 4.2 Motivation viewpoints... 116 4.2.1 Stakeholder viewpoint... 116 4.2.2 Goal refinement viewpoint... 117 4.2.3 Goal contribution viewpoint... 118 4.2.4 Principles viewpoint... 119 4.2.5 Requirements realization viewpoint...120 4.2.6 Motivation viewpoint...121 4.3 Implementation and migration viewpoints...122 4.3.1 Project viewpoint...122 4.3.2 Migration viewpoint...123 4.3.3 Implementation and Migration viewpoint...124 4.4 ArchiMate views for TOGAF viewpoints...126 4.4.1 Architecture Vision Viewpoints...128 4.4.2 Business Architecture Viewpoints...129 4.4.3 Data Architecture Viewpoints...132 4.4.4 Application Architecture viewpoints...133 4.4.5 Technology Architecture viewpoints...135 4.4.6 Other TOGAF viewpoints...136 4.4.7 TOGAF viewpoints versus ArchiMate viewpoints...138 4
Table of contents 5. THE WAY OF WORKING: TOGAF ADM WITH ARCHIMATE...139 5.1 Introduction...139 5.1.1 TOGAF: more than just architecture process model...139 5.1.2 ArchiMate and TOGAF...142 5.2 The ArchiSurance case study revisited...144 5.3 Preliminary Phase...146 5.4 Phase A: Architecture vision...151 5.5 Phase B: Business Architecture...160 5.6 Phase C: Information Systems Architecture...166 5.6.1 Data Architecture...168 5.6.2 Application architecture...171 5.7 Phase D: Technology Architecture...177 5.8 Phase E Opportunities and Solutions...184 5.9 Phase F - Migration planning...195 5.10 Phase G Implementation Governance...199 5.11 Phase H Architecture Change Management...200 5.12 Requirements Management...203 5.13 General Architecture Modelling Approach...208 6. THE WAY OF CONTROLLING...213 6.1 EA governance...213 6.1.1 Conceptual structure...215 6.1.2 Organizational structure...216 6.1.3 Governance approach...218 6.2 The benefits of architecture governance...219 6.3 Architecture Board...219 6.4 Architecture compliance...220 6.4.1 Levels of architecture conformance...221 6.4.2 Compliance reviews...221 6.5 EA maturity...223 7. THE WAY OF COMMUNICATING...235 7.1 Communication approach: the communication plan...238 7.2 The narrow and the broad approaches next to each other...244 8. THE WAY OF SUPPORTING EA WITH TOOLS...251 8.1 Problems regarding and the usage of tools for EA...252 8.2 The advantages of using architecture support tools...254 8.3 Requirements for architecture support tools...256 8.3.1 Modelling and designing...257 supporting architecture domains...257 supporting architecture frameworks...257 support for modelling...258 5
Table of contents 8.3.2 Visualization and publication of architectures...259 views and viewpoints...259 publishing...261 8.3.3 Analysis of architectures...261 impact of change analysis...261 deriving indirect relationships...261 comparing architectures...262 quantitative analysis...263 8.3.4 Storage and management of architectures...263 8.3.5 Selection of tools...265 8.3.6 Classification of existing tools...268 Appendices...271 Appendix 1 - Architecture Frameworks and Methods...271 the Zachman framework...271 dya: Dynamic Architecture...272 integrated Architecture Framework (IAF)...274 gartner s GEAM...275 dodaf...277 nolan Norton...278 Appendix 2 - Architecture principles...281 Appendix 3 - Communication techniques...287 Appendix 4 - The ArchiMate Core Metamodel...291 References...293 6
Foreword from Mike Walker For those of you that are fully immersed in the enterprise architecture world, you may know me as the blogger behind Mike The Architect. I started this blog in 2006, then hosted in microsoft.com where I covered both architecture- and Microsoft-related aspects. From 2008 onwards, www.mikethearchitect.com has been a blog where I post the latest CIO and enterprise architecture news, emerging thought, my architecture experiences and sometimes even a bit of controversy outside any influence of any one vendor. I was asked to write this foreword not because of my active participation within The Open Group, but rather as another passionate enterprise architect that sees the potential of bridging these two worlds of modeling and methodology together while realizing the subsequent impact it will have on the industry. I am truly delighted to see this book on the two very complementary topics of enterprise architecture. Bridging an enterprise architecture framework, TOGAF, with an architecture modeling language, ArchiMate, to show how these two areas are better together. Personally, I am delighted to see this because of my own personal passions for this space. Since I was a child I have always been fascinated by schematics, blueprints and diagrams. They made me want to go build electronics, so I did. From radios to 286 computers. What I reflected later on was that while there was a great deal of complexity and precision behind the models, they were also able to abstract this complexity in a consumable way. To build something truly great though, it required a blend of art and science, that drew me. It provided me a frame to insert my creativity in a in structured form. Much later in my enterprise architecture career, I used the concepts behind modeling and notions for creating visualizations that were intended to introduce simplicity to complex problems. I looked upon the same inspirations from models I admired in the past so that I could carry forward the creation of such models myself. To my dissatisfaction, there were no universal standards or a language that I could use to articulate comparable models that were applicable to my work in enterprise architecture. I found that either the models were not created or built in an ad-hoc nature with little consistency with other models. In several companies where I led architecture efforts, I drove for standardization on how models were to be built. In one case in the early 2000 s I drove for this standardization. To my disappointment, there wasn t a perfect match for the type of information I was trying to visually communicate to my architects and customers. We did have great supplemental modeling standards that excelled from a development perspective but it wasn t a fit for architectural models. In the end I leveraged these other modeling standards to derive to a set of diagrams that represented the elements of the architecture. I found it wasn t an ideal solution and continued to cause confusion with my architects and my customers respectively. The enterprise architecture industry has now solved this problem for us. The ArchiMate standard has provided a repeatable and predictable modeling standard. This fit-for-purpose standard provides the enterprise architecture discipline a standard that differentiates itself from other supplemental standards. ArchiMate, now at version 2.0, is not only the only enterprise architecture standard but also widely adopted by methodologies such as TOGAF and many of the mainstream EA tool providers as well. This provides the EA community of practitioners a pragmatic standard that fits into how we do our work and the tools we use to implement our work. This book is an essential addition to the bookshelf of all enterprise architecture practitioners. 7
With this book, you will not only understand what is ArchiMate, but also how to effectively and reliably apply it with a proven enterprise architecture method. I would predict that this book will prove to provide vital information to help enterprise architects to realistically apply architecture modeling to their architecture engagements. Mike Walker www.mikethearchitect.com 8
Foreword from The Open Group The Open Group ArchiMate Forum was established in 2008. Its creation within The Open Group was the result of a work item of The Open Group Architecture Forum to search for or create an architecture description language to complement TOGAF, the world s foremost Enterprise Architecture framework; that s exactly what ArchiMate is, a visual modelling language with clear semantics, allowing enterprise architects to model and analyse Enterprise Architectures in a uniform, well-defined and understandable way. ArchiMate 1.0 was published in 2009 and followed by ArchiMate 2.0, in January 2012, which now provides a number of important modelling extensions that make the fit between ArchiMate and TOGAF even closer. This fit improves collaboration through clearer understanding across multiple functions, including business executives, enterprise architects, systems analysts, software engineers, business process consultants and infrastructure engineers. This new ArchiMate standard enables the creation of fully integrated visual models of an organization s enterprise architecture, the motivation behind it, and the programs, projects and migration paths to implement it, thus providing full modelling support through all phases of the TOGAF Architecture Development Method (ADM). Standards prove their value if they are used actively by practitioners. So, we at The Open Group are happy to see that this book shows, in a practical and understandable way, how the two Enterprise Architecture standards of The Open Group, TOGAF and ArchiMate, can be used together to deliver Enterprise Architecture. We are confident that this book will further encourage the use of these standards, and prove to be an invaluable source of inspiration for enterprise architects. As with all standards that The Open Group manages, evolution is very much at the heart of what we and our members do. This can be clearly seen with ArchiMate 2.0 and its updated feature set. I look forward to seeing how ArchiMate develops in the future and would like to thank members of the ArchiMate Forum for their dedication and hard work. Allen Brown CEO, The Open Group 9
10
Preface by Henry Franken Rapidly and flexibly adapting to changing customer needs and company goals has become of vital importance to many organizations. The term agility has been coined as the name for this challenge. Changes in product, process, organizational structure, application and infrastructure are significant and continuous, and must be communicated clearly. Enterprise Architecture (EA) provides enterprise leadership with a powerful weapon: it places the enterprise on the roadmap towards a desired future state and towards higher efficiency and effectiveness through transformation. At the same time, EA enables organizations to adapt more quickly and effectively to unforeseen circumstances. EA captures and portrays the different business and IT domains and the relationships between them. EA is more than just modelling: it facilitates the integration and alignment of these domains and facilitates change management. The EA discipline has emerged from the need to derive maximum of business value from IT investments. Building EA capabilities and assets requires significant changes in culture for enterprises organized traditionally by function, discipline or line of business. Therefore, a sound method, a comprehensible modelling language and the right tools are essential for the development, maintenance and usage of an enterprise architecture. This book builds on state-of-the-art literature and on industry best practices, especially from The Open Group. The book addresses both the description of the different architecture domains and the cross domain relationships, while taking into account the concerns and interests of different stakeholders. By doing so the book provides a bridge between strategic (information management and planning) and tactical and operational activities in the organization. Many business leaders are not yet convinced of the necessity of EA. There still are questions for which they wait for good answers: What are the advantages and disadvantages of EA? What tools and resources are needed for EA? What is the best way to steer and control the EA process? How long does it take and when is business value delivered? What is needed to implement EA successfully and what problems may organizations expect to face? The authors have put a lot of energy into providing you this handbook. This book answers questions of those considering EA and provides a roadmap for establishing an EA practice. The core of this handbook supports experienced practitioners. I warmly recommend you to read this book and learn about the merits of EA and ways to deliver it! Dr. Henry Franken The Open Group: Chair ArchiMate Forum Professional life: CEO BiZZdesign Inc. 11
Who should read this book This book is meant as a toolbox for organizations that plan to build, document or further professionalize their enterprise architecture and use it their current practice. We assume that the reader is familiar with the field of Enterprise Architecture to a certain extent. Such a person is most likely the architect, i.e., someone who has affinity with modelling techniques, knows his way in the organization, is familiar with technology and has excellent communication skills (e.g., application, information, process, infrastructure, products and services, and enterprise architects). Goal of this book The goal of this book is to provide a roadmap for developers of Enterprise Architecture capabilities and assets, and to demonstrate that a comprehensive and pragmatic approach for Enterprise Architecture can be realized by combining two open standards for enterprise architecture: TOGAF and ArchiMate. The former standard, TOGAF [79], has been for more than a decade the world s leading architecture method. The latter, ArchiMate, is based on more recent research concerning the definition of an enterprise architecture description language and framework [46, 81], and is now also an Open Group standard. One of the strengths of TOGAF is its capacity to emphasize stakeholder concerns for each EA development phase. TOGAF also defines a set of viewpoints for each phase, which an architect may use to address these concerns (compliant with the ISO/IEC 42010:2007 standard [33]). There are three categories of viewpoints: catalogs, matrices and diagrams. For diagrams, TOGAF does not prescribe a specific (formal or informal) graphical notation: depending on a specific situation or preference, any suitable modelling language or informal diagramming technique may be used. ArchiMate is a modelling standard that can be used to represent several architectural viewpoints in a precise and coherent way. It follows the definitions and relationships of the concepts of Concern, Viewpoint and View proposed by the ISO/IEC 42010:2007 standard for architecture description. ArchiMate is therefore capable of defining stakeholder concerns by means of viewpoints, while the ArchiMate language is capable of modelling and addressing these concerns by means of selective views conforming to both standard and custom viewpoints. In this book we propose practical guidelines on how to combine TOGAF and ArchiMate. Furthermore, we provide an extensive comparison and analysis of the two standards. This analysis demonstrates that it is feasible to use ArchiMate 2.0 (core and extensions) to support all phases of the TOGAF Architecture Development Method (ADM). A scenario also supports this approach by taking a fictitious insurance company through all the phases of the TOGAF ADM cycle, while applying ArchiMate for the specification of all architecture deliverables prescribed by the TOGAF methodology (Chapter 5). Thus, this book offers an operational approach for the usage of ArchiMate as supporting modelling notation during the TOGAF ADM cycle. 12
Conventions and styles This book uses a few conventions to emphasize specific parts of the text. Important remarks are placed in a box, as shown below: All important remarks can be recognized like this. The book also provides a scenario that illustrates some topics with example models. Shaded boxes contain text describing elements of the scenario as shown below: ArchiSurance is a fictitious financial service provider, specialized in different insurance packages, such as life insurance, pensions, legal aid insurance, travel insurance, damage insurance and mortgages. Recently, ArchiSurance went through a structural change process as a consequence of several mergers and acquisitions. In order to deal with the resulting increase in complexity, and to support decisions about future changes, they decided to develop a new and consistent enterprise architecture. We also assume that the reader has some knowledge of systems or business modelling. The approach proposed in this book relies on the ArchiMate 2.0 language and techniques [2, 46, 81], which are used to illustrate how the various architecture artefacts could be created. Finally, we would like to make a clear distinction between the enterprise architecture discipline and other types of architecture disciplines such as software, project or solution architecture. Although enterprise architecture may include, refer to or overlap with all these other disciplines, it cannot be reduced to any of them since it aims to describe and guide the enterprise in its entirety. Nevertheless, in the remainder of this book the word architecture means enterprise architecture unless otherwise stated. 13
14
Acknowledgments We would like to thank in particular the following persons for their helpful support, insightful comments and contribution to this book: Iver Band Standard Insurance Company Remco Blom BiZZdesign Allen Brown The Open Group Garry Doherty The Open Group Roland Ettema Open Universiteit Nederland Bas van Gils BiZZdesign Andrew Josey The Open Group Marc Lankhorst - Novay Jorgen Mellink - BiZZdesign Erik Proper (Public Research Centre Henri Tudor and Radboud University Nijmegen) Mike Turner Nokia Mike Walker - Microsoft Furthermore, we would like to thank our families for their unconditional love and support. 15
16
1. Introduction: The Case for Enterprise Architecture After two decades of Business Process Redesign, in which many enterprises have migrated from function-based organizations (e.g., sales, production, logistics, etc.) to process-driven organizations, a lot of experience has been acquired in the field of business architecture. At the same time, IT has gained a lot of territory such that most of the internal business processes are now unthinkable without the support of complex information systems. Furthermore, the more recent service orientation trend defines a new organizing principle for organizations with far-reaching consequences for their Enterprise Architecture (EA). Organizations think more and more in terms of the services they deliver. The focus is rapidly shifting from the internal organization to the client and to his service needs. Therefore, service orientation recognizes that information systems should not be designed with the goal of supporting some internal business processes; instead, they should be organized in such a way that they can deliver within and, especially, across organizations, information services that can directly be encapsulated into business services. However, especially in large organizations, the step of aligning the business strategy and services with information and application services proves to be difficult. Research results and favourable experiences from practice suggest that building an enterprise architecture in which the business and IT architectures are aligned could be the solution for the problem. Thus, the Enterprise Architecture discipline has emerged from the need to derive maximum business value from IT investments. However, most organizations come to realize that building an EA is not a trivial task since it requires organizational change and significant resources. We hope that we will give a satisfactory answer to these questions throughout this book. Our arguments are based on literature, on our experience acquired in architecture projects and on information we have collected in discussions with architecture practitioners. Issues such as usefulness, advantages and disadvantages of EA and categories of problems for which EA is sought to be the solution are extensively addressed in the remainder of this chapter. 1.1 An integrated perspective on organizations The subject of Enterprise Architecture has raised a lot of interest in the last decades. During this period, the concept of architecture has evolved from being solely used in relation with software development to encompassing all aspects of the enterprise. As such, architecture was and remains an important issue in the IT practice. Enterprise architecture has been a perennial issue in IT management, and has appeared in the top ten most important issues in most surveys of IT executives conducted in the past twenty years [51]. Besides, any self-respecting consultancy company has by now its own position and methodology with respect to EA (e.g., Gartner, Capgemini, Atos, Accenture, etc.). A lot of academic research is also focusing on this area, a fact confirmed by the number of publications recently produced. So why does this field attract so much attention and why is EA so important for many organizations? There are a number of both external and internal reasons that are all related to a number of recent developments. From the technological point of view, the advances in the area of information technology and the globalization have led to a very dynamic distributed and interconnected business environment. From the political point of view, the deregulation of some industries, on one hand, and the growth of the amount of new laws and regulations, on the other hand, have raised 17
the number of concerns affecting organizations. External developments. For large organizations this rapidly changing environment represents an external threat. Often smaller and more flexible organizations are much faster in seizing and taking advantage of new opportunities. Irrespective of the size, standing still and not reacting to change is the worst choice for any organization. The alignment of a firm with its environment is critical for its competitiveness. A few relevant characteristics of this environment are discussed briefly in the sequel. Technological advancements. Take, for example, the incredible development of the internet, which has forced many organizations to adapt to this new distribution channel and to redefine themselves in terms of product and service portfolios. The number of internet users is growing rapidly, every day brings new IT applications and technologies and organizations are constantly busy adopting them, which means there is less time left for maintenance of existing systems, for the integration of legacy systems and for the integration or dismantling of systems in case of mergers and separations. Globalization has as immediate effect on competition growth. Not only the internet has caused the geographical expansion of market borders but has also lowered the entrance barriers for new players in these markets. Meanwhile, virtually anyone with a simple internet connection can do business. This means that an organization must be able to distinguish itself from its competitors in order to keep its share of the market. An organization which wants to do this must constantly evaluate and choose its competitive strategy. In this context Porter s work is very relevant [64] since it identifies the most important types of strategic business behaviour: Low-cost leadership : according to this strategy, a firm sets out to become the low cost producer in its industry. In this case the company is able to offer a product of comparable quality at a price, which is lower than the ones demanded by the direct competitors. The sources of cost advantage may include the pursuit of economies of scale, proprietary technology and other factors. Differentiation : an organization adopting this strategy seeks to be unique in its industry along some dimensions that are widely valued by the customers. It selects one or more attributes that many buyers in that industry perceive as important, such as higher quality, extra functionality, bundles of services, marketing campaigns, etc. Focus ( Low-Cost ): this strategy assumes that the organization concentrates on a specific regional market or a specific client target-group and within these borders it will act in a costefficient manner. Focus ( Differentiation ): this strategy assumes that the organization concentrates on a specific regional market or a specific client target-group and within these borders it distinguishes itself from its direct competitors (e.g., by excelling in terms of quality). These four strategies can be positioned along two dimensions as depicted in Table 1. 18
Competitive advantage Broad target group Narrow target group Low-Cost Low-Cost leadership strategy Focus Strategy ( Low-Cost ) Differentiation Differentiation strategy Focus Strategy ( Differentiation ) Table 1 - Porter s model of generic competitive strategies Regulation and deregulation imposed by governments, as well as standards of practice within the organization, count as another significant factor contributing to the dynamicity of the business environment. Examples of this are recommendations such as the COBIT standards or the Sarbanes-Oxley and Clinger-Cohen Acts. Regulations like these lead to significant transformations in the management and in the supporting systems of some organizations. Deregulation, for example, in the area of social services has also lead to important changes in the administrative organization of many companies. Therefore, the question is: how can an organization cope with all these changes? Before we explain the role of EA in mitigating of the dynamics of a firm s environment, we first analyse the state of affairs in our example organization: ArchiSurance. ArchiSurance, a provider of a large variety of financial services, has noticed that the internet has led to an increased competition in this market. After many deregulating adjustments of the government (e.g., deduction of interest rate for tyres, the sickness leave law, etc.), Archi- Surance s product and service portfolio is, to some extent, stable again. In terms of strategy, ArchiSurance has decided to consolidate its brand name and deliver higher-quality services in order to differentiate itself from its competitors. The focus lies on the young employee, which forms a very lucrative target group in the market of mortgages and insurance. Therefore, ArchiSurance has adopted an organizational model that requires a broad process-wise integration of various organizational, informational and technological aspects. The plan is to create a unique client service-point through which all the necessary data can be accessed in the different back-office databases. This would ensure that any claim can be processed in less than 24 hours. Despite the fact that service delivery is excellent, ArchiSurance has high tariffs. Since, due to the internet, the market has become very transparent, these high tariffs make them vulnerable in terms of price-competition. Therefore, they also want to lower their costs (and, consequently, the price of their products and services), while still maintaining the quality for which they are well-known. 19
From the example above, it is clear that the chosen organization model requires a great deal of integration of the business, applications and technology. Integration is important for organizations because it can lead to a decrease of the response times for requests of services and products, which has as a direct consequence the increase in quality. This is partly possible because being successful in integration also means having the right information at the right place at the right moment. Without integration, the available information often does not match the information needs, leading to additional laborious processing steps that disturb and complicate the streamlining of business processes. However, changing an organization in which technology, application and business are more and more entangled is a highly complex enterprise-wide process which should be coordinated in an architecture-driven fashion. Internal developments. Organizations seem to have more and more difficulties in setting up and carrying out changes internally. They have become complex intricate systems in which everything appears to be connected with everything and no one knows what happens when you change something, mostly because no one has a clear overview of the whole. Changes in organizations are often carried out in phased programs that span over more years, and are expected to accomplish certain business goals as result of several (multidisciplinary) projects. In such projects new or improved products and services are realized or the internal structure of business, software applications or technology infrastructure is redesigned. A change program assumes that important decisions will be made that are in line with the long-term vision, mission and strategy the company has. These decisions should be consistent and should carefully take into account the current situation of the company. This is feasible if such decisions are based on some sort of organizational blueprint. Enterprise architecture can fulfil the blue-print role, by documenting the organization in the form of architecture models, frameworks, constraints, principles and guidelines covering both a long-term and a short-term time-span. Organizations are in search of new ways to rationalize their investments in the IT portfolio. In most of the cases, this portfolio is highly heterogeneous and distributed. Furthermore, software applications overlap with each other in terms of functionality, having as a result a situation in which the same data is collected, stored and processed several times and perhaps in different formats. Besides, investment in IT is difficult to motivate since it is not always easy to assess in which way the IT will serve the business goals and strategy an organization pursues. This situation is described in the field literature as the problem of aligning the business with the IT. Finally, we must note the trend of the recent years towards the implementation of service-oriented architectures. This trend was fired up by technological developments in the area of web services, which have the potential of bringing greater flexibility and modularity in application architectures, making thus possible the rapid and on-demand composition of new (software) services out of internally or externally available services. It is expected that this new way of structuring enterprise architectures will lead to less maintenance and implementation costs and higher interoperability and integration. To say that each organization really struggles with all these problems is an overstatement. It is, however, a fact that some of them perceive many of these issues as serious. How is it nowadays still possible that organizations are not able to optimally benefit from their technology and still have to deal with (the reasons behind) unsuccessful technology implementation projects? Our argument 20
is that the use of a comprehensive Enterprise Architecture approach makes these problems controllable and increases the chances for success. 1.2 Why Enterprise Architecture? In the previous section, we have concluded that organizations have to stay aligned with their dynamic environment if they are to survive the threats they are confronted with, and to profit from new opportunities. Also, we have explained that adopting a certain differentiation strategy eventually may assume a higher degree of integration between business processes, applications and technology. Thus, change and integration appear to be important characteristics of dynamic organizations. However, changing an integrated system is a complex undertaking that requires a holistic approach. Numerous signals from the industry point out that there is a need for such an approach [68], based on (at least) the following grounds: The increasing complexity as result of mergers and acquisitions, outsourcing, internet, mobility, eusiness, etc.; High IT costs; A divide between business and IT within an organization, e.g., lack of trust, differences in perspective, or conflicts of interest; Lack of control on IT costs; Lack of control on the effects business changes induce in the supporting information systems. Many organizations are, therefore, in search of methods and techniques that would help them to control and diminish the business and IT complexity. Organizations need to have insight in the range and the impact of changes on the organization. They also need a communication means in order to be able to steer effectively the change process, such that the involvement of people and resources is optimally coordinated. Our claim is that the discipline of Enterprise Architecture incorporates such methods and techniques. Enterprise architecture relates to information systems development in the same way town planning relates to building and construction it applies to a macro (enterprise) level rather than a micro (individual application) level. An enterprise architecture describes how the many pieces of a firm s application and technology infrastructure (e.g., processors, networks, software, PCs, databases, applications, workflows, etc.) work together to support the goals and processes of the business. EA is the result of an interdisciplinary effort, in which all the stakeholders in the organization are involved and which is a means to implement the business strategy and to create the foundation for agile and consistent organizational change. The tangible results of this effort are the architecture descriptions (also called artefacts) in the form of texts, diagrams, principles and guidelines. Using architecture descriptions it becomes possible to efficiently and effectively document and communicate (to the different stakeholders) the essence of the business, of the information systems and of the IT infrastructure. These can be created using the ArchiMate description language [43, 81], which supplies the enterprise architect with a formally sound basis for modelling various organizational domains and the relationships between them. Moreover, architecture descriptions may facilitate various types of qualitative and quantitative analysis, such as performance, impact of change and costs/benefits analysis. Thus, a comprehensive Enterprise Architecture approach can respond to the above-mentioned needs of organizations by leading to a better understanding of the complexity of the transformation 21
process and by making this process manageable and controllable. Advantages. Putting information technology organization-wide at work in the right way has many advantages, such as flexibility in the management of organizational changes, the coherent management of organizational resources, and a better control over the costs, completion time and over the planning. Developing organization-wide information systems that follow and implement the corporate business strategy and seamlessly integrate with business processes is a complex undertaking in which many stakeholders and aspects must be taken into account. Zachman [89] argues that without a structured approach, this development process will end up in chaos and the disintegration of the organization. EA is a conceptual tool that helps organizations get a deeper understanding of their own structure and of the way they work. It provides a map of the enterprise and it is a route planner for business and technology change. Important uses of it are in systematic IT planning/architecting and in enhanced analysis and support for decision-making. In short, Enterprise Architecture has several important advantages and uses that have been confirmed in practice [71, 91]. Van den Berg and Steenbergen [6] establish a direct relation between the necessity of EA and the goals of EA. Moreover, when considering EA goals, they categorize them into strategic goals (that support organization-wide decisions with respect to the business model, priorities and infrastructure facilities), tactical goals (that support decisions with respect to the feasibility of a specific business goal) and operational goals (that support decisions within the context of a particular project). In the context of this book, only the strategic and tactical goals are considered. While Enterprise Architecture is not the silver bullet for all problems, it offers a different perspective on the management of an organization and on the effective execution of change management. In this context, an EA development method is essential. The question is not why an architecture should be developed, but rather when, how and to what extent. 1.3 Frameworks, languages and standards for Enterprise Architecture Over the years, a number of different approaches to enterprise architecture have been proposed (e.g., [5, 6, 11, 17, 32, 45, 46, 76, 78, 79, 89]). Each of them covers a part of the enterprise architecture discipline. Below, we will briefly review a number of well-known methods and frameworks for enterprise architecture.. The Zachman Framework was one of the first frameworks proposed for enterprise architecture (originally published in 1987 [89], but revised and extended in 1992 [76]) and it is still popular. It was derived through an analogy with structuring schemes used in other disciplines (e.g., building architecture, construction engineering and manufacturing) for the deliverables created during the design and production process of complex physical products. Among the strengths of the Zachman framework are its completeness and its ease of understanding (the analogy to building and construction and the classic 5WH formula - see Appendix 1, The Zachman framework - are very natural and intuitive), which also explains its longevity. The Zachman framework does not make any assumptions about specific modelling languages or notations to be used: for each cell, and depending on the specific situation or preferences, the most appropriate representation can be selected. TOGAF is one of the leading enterprise architecture methods. TOGAF originated as a methodology for development of technical architectures, but over the years its focus has shifted towards 22
enterprise architecture, version 9.1 being the third instalment of the Enterprise Edition [79]. The very core of this approach is a methodology called Architecture Development Method (ADM). The ADM is a step-wise iterative approach for EA development and implementation. One of the new elements introduced in TOGAF 9 is the Architecture Content Framework (ACF). Positioned as an architecture framework (i.e., similar in purpose to the Zachman Framework), the ACF not only provides a categorization of the various architecture domains within the enterprise, but also offers a conceptualization of these domains by means of the Content Metamodel. However, the TOGAF Content Metamodel is not intended to be a modelling language, and it does not prescribe how the concepts should be represented. The architect is free to choose the most appropriate representation to create views, which may be, among others, a model expressed in an existing formal modelling language (e.g., ArchiMate or UML), an informal graphical representation, a catalog, matrix, or text. UML, the Unified Modelling Language, is one of the most widespread languages for modelling software designs. As UML focuses on design, its scope is different from enterprise architecture. UML can be positioned in what in ArchiMate are called the Application and the Technology layers. Although they are more abstract, several of the ArchiMate concepts in these layers have been inspired by UML concepts. Commercial Architecture Modelling Tools are another source of enterprise architecture modelling notations. Many commercial tools define their own proprietary architecture modelling languages which, no matter how good these languages might be, may limit their suitability as an industry standard. The need for a comprehensive approach for enterprise architecture. The brief analysis presented in the paragraph above leads us to a few important conclusions: Many frameworks have been proposed for modelling enterprise architectures, which define ways of understanding and classifying architectural phenomena. However, detailed metamodels and a modelling notation to support them has been beyond the scope of most of these frameworks. Thus, there is a need for a standard modelling language for enterprise architectures. The ArchiMate open standard is a good candidate to play this role, by filling the modelling gap and replacing informal or proprietary techniques. When looking more closely at all the above mentioned approaches, we see that most of them address one or at most two of the following aspects: A framework for the subdivision of an architecture in different domains, sometimes including the relationships between these domains. A language, defining the concepts for describing an architecture, including a (preferably graphical) representation of these concepts. A process, or a way of working, which is in most cases a step-wise prescriptive method for developing architectural descriptions. A complete approach for enterprise architecture requires that all of the above mentioned aspects are covered. Moreover, it should indicate how these aspects are related to each other. Figure 1 illustrates this schematically. Most existing EA approaches cover one or two of the three abovementioned aspects. There are a number of frameworks though, that in combination with ArchiMate do cover all three aspects. Furthermore, we note that ArchiMate is the only enterprise architecture approach (and open standard) that fully complies with the definition of a modelling language (i.e., it has a formal abstract syntax (a metamodel), a concrete syntax (graphical representations for 23
its concepts and relationships) and semantic definitions for all its constructs). For example, both IAF [56] (see Appendix 1- Integrated Architecture Framework (IAF) for a short description) and the TOGAF ACF define concepts, but do not have a graphical notation. Framework (viewpoints) Language (concepts) EA Process Figure 1 - Ingredients of an EA approach These conclusions suggest the time is right for a comprehensive approach for enterprise architecture based on open standards, which is exactly what this book is aiming to promote. The approach proposed in the following chapters is based on our previous work concerning the definition of the ArchiMate enterprise architecture description language and framework [43, 46] and on the TOGAF ADM and it demonstrates that the combination of TOGAF (in particular the ADM) and ArchiMate is both operational and comprehensive. This choice is also motivated by the fact that both approaches are currently promoted as EA standards by The Open Group. This gives the enterprise architecture community the opportunity to use them together. An important argument for doing so is the neutral, flexible, open and cross-disciplinary nature of these standards. We also have to stress the compatibility of both TOGAF ADM and ArchiMate with any other approaches that practitioners deem important. In the remainder of this section, we will briefly describe the two above-mentioned standards. ArchiMate is an architectural modelling language developed with the explicit aim of creating an open standard, as part of a collaborative research project on enterprise architecture funded by the Dutch government involving several Dutch research institutes, major corporations and governmental and financial institutions. The results of the project are described in detail in [46]. The ArchiMate language consists of five primary components: A framework: a conceptual framework [81] consisting of rows (layers) and columns (aspects) which allows classification of architectural phenomena (this is a subset of the Zachman framework). This defines a theory or world view about how enterprises are structured. An abstract syntax in the form of a metamodel: this contains the formal definition of the languages. The ArchiMate metamodel defines the characteristics of each language construct, and its relationships to other language constructs. Besides, the metamodel positions the different language constructs in the cells of the ArchiMate framework and specifies the relationships that may exist not only between constructs but also between cells. In ArchiMate it becomes therefore possible to model the dependencies between the different layers, domains and views of the enterprise architecture, which thus becomes a coherent hole instead of a collection of isolated diagrams of different kinds. 24
The language semantics: this defines the meaning of each language construct and relationship type. It should be noted that ArchiMate s language semantics are very intuitive, such that a well-labeled ArchiMate diagram is can be largely understood by someone with a basic IT familiarity. A concrete syntax in terms of a visual notation: this defines how the language constructs defined in the metamodel are represented graphically. Viewpoints: this corresponds to the idea of diagram types in UML though it is much more flexible as there is no strict partitioning of constructs into viewpoints (i.e., concepts may be used in several different viewpoints). World view (Framework) Aspects Abstract Syntax (Metamodel) Concrete Syntax (Visual Notation) Layers Extensibility of meta model: ability to define new constructs Visualisation flexibility: multiple notations supported, ability to define custom notation View View View Figure 2 - Ingredients of the ArchiMate approach Multiple views - each view consists of a subset of constructs in the metamodel - ability to define custom views ArchiMate 1.0 [80] was the first official standard release and coincides with the language originally developed in the ArchiMate project. Recently, Version 2.0 of the standard has been published [81], which includes a Core (basically ArchiMate 1.0 with a number of small additions and corrections) and two extensions (Figure 3). The extensions are concerned with modelling concepts for the description of architecture artefacts regarding a) business goals, architecture principles and requirements; this extension is further referred to as the motivation extension; b) projects, programs, migration, transition architectures and gaps; this extension is further referred to as the implementation and migration extension. 25