BiZZdesign Building Strong Organizations. Building Strong Organizations. This is an example version of the book:

Transcription

1 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 ( - 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: [email protected]. They can help you to purchase this book. Enjoy reading BiZZdesign Building Strong Organizations BiZZdesign Building Strong Organizations

2 Delivering business outcome with TOGAF and ArchiMate Maria-Eugenia Iacob Henk Jonkers Dick Quartel Henry Franken Harmen van den Berg

3 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 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

4

5 Table of contents Foreword from Mike Walker...7 Foreword from The Open Group...9 Preface by Henry Franken introduction: THE CASE FOR ENTERPRISE ARCHITECTURE An integrated perspective on organizations Why Enterprise Architecture? Frameworks, languages and standards for Enterprise Architecture Organization of this book THE WAY OF THINKING the Definition of Enterprise Architecture the Role of EA in Linking Strategy to Design and Execution drivers for Enterprise Architecture ingredients of an Integrated Enterprise Architecture Framework Methodological Framework (based on TOGAF ) Modelling Framework (based on ArchiMate ) THE WAY OF MODELLING: ARCHIMATE ArchiMate Core Modelling services Modelling the business layer...46 business structure...46 business behaviour...49 business Information...52 summary of the business layer Modelling the application layer...58 Application structure and behaviour...58 Application information...62 summary of the application layer Modelling the Technology layer...64 summary of technology domain Modelling relationships...71 structural relationships...71 derived relationships...73 dynamic relationships...74 other relationships...75 summary of relationships Motivation extension...78 stakeholders, drivers and assessments...78 goals, principles and requirements...80 relationships for the motivation extension...82 summary of the motivation extension

6 Table of contents 3.3 Implementation and migration extension...85 modelling work packages...85 modelling migration...87 summary of the implementation and migration extension Alignment between the ArchiMate core and the Motivation and the implementation and Migration extensions THE WAY OF MODELLING VIEWPOINTS AND VIEWS ArchiMate core viewpoints Organization Viewpoint Actor cooperation viewpoint Business function viewpoint Business process viewpoint Business process cooperation viewpoint Product viewpoint Application behaviour viewpoint Application cooperation viewpoint Application structure viewpoint Technical infrastructure viewpoint Implementation and deployment viewpoint Information structure viewpoint Service realization viewpoint Layered viewpoint Landscape map viewpoint Motivation viewpoints Stakeholder viewpoint Goal refinement viewpoint Goal contribution viewpoint Principles viewpoint Requirements realization viewpoint Motivation viewpoint Implementation and migration viewpoints Project viewpoint Migration viewpoint Implementation and Migration viewpoint ArchiMate views for TOGAF viewpoints Architecture Vision Viewpoints Business Architecture Viewpoints Data Architecture Viewpoints Application Architecture viewpoints Technology Architecture viewpoints Other TOGAF viewpoints TOGAF viewpoints versus ArchiMate viewpoints

7 Table of contents 5. THE WAY OF WORKING: TOGAF ADM WITH ARCHIMATE Introduction TOGAF: more than just architecture process model ArchiMate and TOGAF The ArchiSurance case study revisited Preliminary Phase Phase A: Architecture vision Phase B: Business Architecture Phase C: Information Systems Architecture Data Architecture Application architecture Phase D: Technology Architecture Phase E Opportunities and Solutions Phase F - Migration planning Phase G Implementation Governance Phase H Architecture Change Management Requirements Management General Architecture Modelling Approach THE WAY OF CONTROLLING EA governance Conceptual structure Organizational structure Governance approach The benefits of architecture governance Architecture Board Architecture compliance Levels of architecture conformance Compliance reviews EA maturity THE WAY OF COMMUNICATING Communication approach: the communication plan The narrow and the broad approaches next to each other THE WAY OF SUPPORTING EA WITH TOOLS Problems regarding and the usage of tools for EA The advantages of using architecture support tools Requirements for architecture support tools Modelling and designing supporting architecture domains supporting architecture frameworks support for modelling

8 Table of contents Visualization and publication of architectures views and viewpoints publishing Analysis of architectures impact of change analysis deriving indirect relationships comparing architectures quantitative analysis Storage and management of architectures Selection of tools Classification of existing tools Appendices Appendix 1 - Architecture Frameworks and Methods the Zachman framework dya: Dynamic Architecture integrated Architecture Framework (IAF) gartner s GEAM dodaf nolan Norton Appendix 2 - Architecture principles Appendix 3 - Communication techniques Appendix 4 - The ArchiMate Core Metamodel References

9 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, 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

10 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 8

11 Foreword from The Open Group The Open Group ArchiMate Forum was established in 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

12 10

13 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

14 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

15 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

16 14

17 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

18 16

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 Motivation Extension Implementation & Migration Extension ArchiMate Core ArchiMate Core Figure 3 - ArchiMate core and extensions ArchiMate does not include an architecture method to guide an organization through the whole architecture development program. As mentioned before, the solution is to combine ArchiMate with the existing methodological support provided by TOGAF ADM. A quick examination of both TOGAF ADM and ArchiMate is sufficient to see that, in terms of scope, there is significant overlap between them [47]. With concepts defined in the ArchiMate Core, models can be created that mainly fill in the views related to the Phases B, C and D of the TOGAF ADM, i.e., the phases concerned with creating the business, information systems and technology architectures. The Implementation and Migration extension of ArchiMate adds concepts to support the late ADM phases, related to the implementation and migration of architectures: Phase E (Opportunities and Solutions), Phase F (Migration Planning), and Phase G (Implementation Governance). In the TOGAF ADM, Requirements Management is a central process that applies to all phases of the ADM cycle. Furthermore, TOGAF formulates requirements on requirements management, but refrains from mandating or recommending existing languages, methods and tools from the area of requirements engineering. The Motivation extension of ArchiMate is such a requirements specification language that meets the TOGAF requirements. As such, it covers primarily the Preliminary Phases, Phase A, Phase H, and the Requirements Management phase of the ADM. Figure 4 illustrates the correspondence between the ADM phases and the concepts defined in the Core and extensions of ArchiMate. With respect to viewpoints, as it will become clear later in this book, models can be created using ArchiMate to describe most of the views defined by viewpoints prescribed by TOGAF 9.1 s Architecture Content Framework. Conversely, some of the ArchiMate viewpoints that deal with the relationships between architectural layers are difficult to map onto the TOGAF ADM phases, in which views are confined to a single architectural layer. This is precisely where ArchiMate nicely complements TOGAF, since it allows the explicit modelling of the dependency relationships between architectural layers, thus increasing the coherence of the architecture descriptions. 26

29 Figure 4 - The TOGAF ADM and the ArchiMate framework (taken from [81], The Open Group) 1.4 Organization of this book Wijers [87], as well as Van den Heuvel and Proper [27], have identified a number of aspects that should be include in a complete architecture approach: The way of thinking articulates a basic view on the problem domain and focuses on the assumptions regarding the types of solutions, analysts and designers. The way of modelling defines the concepts of the language that is used to denote, document, analyse, visualize or animate the architecture descriptions. The way of working describes a structured manner to apply the method, for example, in terms of tasks, subtasks, ordering of tasks, etc. It furthermore provides guidelines and suggestions on how these tasks should be performed. The way of controlling focuses on implementation and governance aspects of the architecture development process (e.g., quality, progress reports, periodic assessments, monitoring, accountability issues, planning, governance structures, management of changes, etc.). The way of communicating describes how the meaning of the abstract concepts defined by the way of modelling is conveyed to the different stakeholders, for example in terms of textual or graphical notation. The way of supporting concerns the support that is offered by (potentially automated) tools for the handling (i.e., creation, presentation, modification, etc.) of architectures and for the application and usage of the architecture method. Table 2 shows how we used the aspects identified in [87] complemented with the communication aspect [27] to structure the book content into chapters. 27

30 EA ways Book Chapters Way of thinking Chapter 2 Way of modelling Chapters 3 and 4 Way of working Chapter 5 Way of controlling Chapter 6 Way of communicating Chapter 7 Way of supporting Chapter 8 Table 2 Book structure More specifically, Chapter 2 contains a discussion of the EA core concepts and describes the architecture framework that forms the foundation of the ArchiMate language. In Chapter 3 we present the architecture modelling concepts and the relationships between these concepts, as defined by the ArchiMate 2.0 Specification [81]. Chapter 4 (also part of the EA way of modelling) defines and illustrates a rich set of viewpoints that can be used in practice to provide support for the visualization, presentation and analysis of the architecture from different perspectives. The source of these viewpoints can be found in both ArchiMate and TOGAF. In Chapter 5, we revisit each of the TOGAF ADM phases, and show, also by means of a running example, how ArchiMate can be used for the specification of the different deliverables prescribed by the TOGAF method. Chapter 6 focuses on EA governance. In addition to this, the topic of EA maturity and its impact on governance is addressed. Besides examining how the two standards can be integrated with each other in terms of scope, we also address one of the most difficult challenges that needs to be overcome in the enterprise architecture field the need to communicate architectures to business stakeholders (Chapter 7). Communication, which is already a challenge faced at the application level, is much more difficult at the enterprise level because of the increased complexity and because of the nature of the audience. Effective communication with management is essential as architectures are used for achieving business-it alignment and making IT investment decisions. Finally, the book discusses architecture tool support issues (Chapter 8). We believe this is necessary in order to provide the reader with insights concerning the functional requirements for software facilitating the production, management and storage of architecture artefacts. Next to the chapters mentioned in Table 2, several appendices containing supplementary materials and an introductory chapter (that makes the case for enterprise architecture and provides an overview of the addressed topics addressed) are also included in this book. 28

31 2. The Way of Thinking In this chapter, we first discuss and define the concept of enterprise architecture. Next, we explain the role of enterprise architecture in linking business strategy to design and execution, and we give a classification of drivers that impact enterprise architecture and organizational change. Finally, we identify the necessary ingredients of a complete and integrated approach to enterprise architecture, and show how the two open standards for enterprise architecture of The Open Group that we adopt in this book, TOGAF and ArchiMate, together provide these ingredients. 2.1 The Definition of Enterprise Architecture The word architecture is associated in the field literature with two interpretations. Very often one can guess from the context which of the two interpretations is intended. The first refers to the inherent organization of a system. System theory states that a (complex) system can be divided in smaller, less complex sub-systems that, when combined, form the original system. This combination of lower-level systems and the manner in which they function together defines the inherent architecture of the original system and is by some authors referred to as the architecture. In this line of thinking, the ISO/IEC 42010:2007 standard (formerly the ANSI/IEEE standard) [33] proposes a definition that is considered to be the reference: The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. The second interpretation relates to the assertion that it is necessary to make explicit the inherent architecture of a system by means of architecture descriptions. Next to documenting the decomposition of the system, an architecture description may refer to many other aspects such as function, data, time, motivation, etc. The ISO/IEC 42010:2007 standard is very precise in this respect and makes a clear distinction between architecture (which is conceptual/intangible) and architecture descriptions (which are concrete/tangible). Architecture decription is defined as: A collection of products to document an architecture. Architecture description is thus the second connotation of the word architecture. The relation between architecture as description and architecture as inherent organization is that the architecture description represents and conveys the essence of the inherent organization. In the theory and practice of EA, the second interpretation is the most commonly used, and therefore we adopt it as well. Furthermore, the definition of EA we propose below fits very well in the architecture as description line of thinking. In this book we adhere to the following definition of the concept of enterprise architecture that is based on the existing literature [6, 46, 79, 84]: 29

32 Enterprise architecture is the complete, consistent and coherent set of methods, rules, models and tools which guides the (re)design, migration, implementation and governance of business processes, organizational structures, information systems and the technical infrastructure of an organization according to a vision. This definition can be complemented with additional characteristics, such as those mentioned below. Enterprise architecture comprises a collection of simplified representations of the organization, from different viewpoints and according to the needs of different stakeholders [82]. Enterprise architecture is a design or a description that makes clear the relationships between products, processes, organization, information services and technological infrastructure [82]; it is based on a vision and on certain assumptions, principles and preferences; consists of models and underlying principles; provides frameworks and guidelines for the design and realization of products, processes, organization, information services, and technological infrastructure. 2.2 The Role of EA in Linking Strategy to Design and Execution Business strategy should be the foundation on which every enterprise is built. Nevertheless, many organizations experience a gap between their strategic decisions and the implementation of these decisions in their daily operations (both the primary processes and supporting processes such as marketing, finance, etc.). A first step to make the business strategy more concrete is by means of a description of the organization s business model: i.e., the rationale of how an organization creates, delivers and captures value. A business model specifies, on the one hand, the organization s value propositions, cusomter segments, delivery channels, customer relationships, and revenues: in other words, everything related to the offer to the customers. On the other hand, it specifies, at a global level, the infrastructure needed to realize this offer, in terms of key resources, activities, partners, and the costs associated with these elements. Enterprise architecture models can be used to specify how the business strategy and business model are translated into organization and system design, and thus to link models at the strategic level to models at the design level and, indirectly, to the business operations. This is illustrated in Figure 5. On the one hand, EA provides a high-level design of the organizational structure and processes, IT systems and infrastructure, and their relationships, which conforms to the constraints and guidelines specified by strategy models and business models. On the other hand, it provides constraints and guidelines for the detailed design models of the various aspects of the organization and supporting IT systems and infrastructure. Enterprise architecture plays a central role in the implementation trajectory, from business strategy to business execution. Conversely, it also plays an important role in the support of organizational governance. 30

33 Figure 5 Enterprise architecture - bridging strategy and design 2.3 Drivers for Enterprise Architecture In Section 1.1 we argued that external developments cause organizations to (partially) change. Here we further investigate what are the driving forces of the architectural paradigm. More specifically, we propose a model that allows us to position and characterize the main factors impacting EA. A change strategy should pay attention to both the internal and external domains, since all the drivers of the change process originate from these domains [26]. The external domain s dynamic nature causes organizations to continuously react to with new trends, opportunities and threats. Therefore, an organization must at the right moment take advantage of certain circumstances in the external domain. By means of a SWOT analysis ( Strengths, Weaknesses, Opportunities and Threats ) the most relevant developments in an organization s environment can be brought to the attention and analysed. In the internal domain, the organization must decide upon the manner in which they further develop or change their processes, systems and organization, which best follows the developments in the external domain but, at the same time, stays in line with the internal business strategy. A classification, as well as several examples, of drivers for architecture and the consequences they have for the internal structure and development of an organization are given on the next page. 31

34 Organizations are confronted with the following issues [23]: - Organizations strive to raise the service level for their customers by offering an integrated multi-channel contact centre through which all the necessary exchanges of information should take place (e.g., the storage and retrieval of client-information, claims, etc.). Such an approach has important consequences for the business (e.g., adjustments in business processes and in organization structure), for the application services (e.g., a CRM system) and for technology infrastructure (e.g., a fast data base system, network, etc.). - Organizations strive to open new distribution channels (e.g., internet). Such a goal assumes adjustments in the way the business is organized, for example, according to new principles such as the client-to-client process chains. Furthermore, this could also lead to the integration of new applications in the existing application architecture or to an extension of the technology infrastructure. - Organizations may customise their differentiation strategy, and consequently, their products and services to the individual wishes and requirements of their customers. - Low-cost leadership : increasing competition and market transparency due to the expansion of Internet cause an increasing pressure on the market prices, and lead to the initiation of change processes having as target the reduction of costs. Typical examples of such processes are the introduction of Shared Service Centres, outsourcing of (a part of the) secondary (administrative) or primary (production) processes are outsourced either to specialized companies or to companies located in developing countries, or the disposal of loss making business units, etc. [39]. Henderson and Venkatraman [26] argue that, depending on the driver s origin in terms of domain (external or internal) and of layer (business layer, application layer and technology layer), different alternatives and change strategies can be adopted by an organization. Several such strategies are explained below. External Internal Business layer Application layer Technology layer Figure 6 - External-business driven change 32

35 External-business driven change. In Figure 6 we present a change strategy driven by an external opportunity in the business domain. An external cause (usually a business opportunity) has as effect the internal transformation of some aspects (correlated with each other) of the business, application and technology layers leading to a desired target situation in which the selected opportunity is implemented. In this case the transformation of the business layer is central to the whole change process, while the other layers will be merely adjusted according to the choices made in the business layer. External-application driven change. External changes can be driven by factors originating in the application domain. Take for example, the case of new IT solutions such as an ERP system, a Workflow Management System etc. In this case, the changes in the application layer are decisive and will steer the changes in the other two layers, as depicted in Figure 7. External Internal Business layer Application layer Technology layer Figure 7 - External-application driven change External-technology driven change. The last category of external changes stems from the technology domain. Technological developments can lead to new opportunities, such as in the case of mobile and internet technologies. These new technologies can be used by organizations to open up new distribution channels and expand their market. However, it should be mentioned that being dependent on a certain supplier/technology brings a lot of risks in case that supplier/technology disappears or fails to gain popularity. In this strategy, the changes in the technology layer are decisive and steer the changes in the other two layers, as depicted in Figure 8. External Internal Business layer Application layer Technology layer Figure 8 - External-technology driven change 33

36 Internally driven change. Next to externally driven changes, there are internal developments that cause large scale change processes. Take, for example, the case of internal reorganization of departments, moving to another location, the migration to a new release of a software application, or the replacement of old computers. The source of the change in this case is internal can be located in one of the layers. Often the source also determines to what extent changes in the other layers are also necessary. This form of change strategy is depicted in Figure 9. External Internal Business layer Application layer Technology layer Figure 9 - Internally driven change Externally managed change. In contrast to the externally driven strategies, this last type of strategy describes the cases certain organizations are capable of putting a lot of pressure on the external domain and force this domain to change according to their own needs. Thus, a part of the change process costs is supported by parties in the external domain. This type of change process is typically initiated and steered by organizations having a monopoly position (e.g., Microsoft), or by (consortia of) large market players (e.g., The Open Group), standardization organizations, governments, etc. Thus, (large) organizations can influence the course technological developments take and, can indirectly share the costs of change with other external parties. This type of strategy is depicted External Internal Business layer Application layer Technology layer Figure 10 - Internally managed change We can conclude that external drivers may trigger significant change processes in organizations. These changes often have impact on multiple aspects and layers of the enterprise. In Chapter 5 (the way of working) we explain how the change process should be carried out. Below we give a few examples of internal and external drivers that may be considered as a reason for change in the case of ArchiSurance: 34

37 Because the increasing internationalization, companies tend to focus more and more on their core business and outsource all the secondary processes and services which do not belong to this core. This is also the reason why ArchiSurance wants to concentrate more on the claim handling process (appraisal, evaluation, examination, administration, financial handling) and less on the development front-office activities. To this purpose, ArchiSurance wants to market its products and services through external partners such as specialized intermediaries (e.g., insurance agents). Part of this reorganization process is also ArchiSurance s intention to discard a few loss making business units. In order to accomplish the above-mentioned goals, the senior management of ArchiSurance has formulated a strategic plan that asserts the following objectives for the coming year: Cost reductions through the optimization of the business. The strict division in departments must be reconsidered and the shared processes and resources must be brought under a central department (internally driven change). The extensive application integration with the chain partners, such as garages, intermediaries, other insurance companies (for the handling of damage claims in which multiple insurance companies are involved) and banks (external-application driven change). The divestment of the travel insurance business unit, due to the fact that the travelling business is going through a difficult period and the market forecasts for travel insurance are quite bad (external-business driven change). 2.4 Ingredients of an Integrated Enterprise Architecture Framework Enterprise architecture is more than just a modelling exercise. It is the result of an interdisciplinary effort, in which all the stakeholders in the organization are involved and which is designed with a certain business strategy in mind. Moreover, enterprise architecture is seen as a means to implement this strategy, by creating the foundation for agile organizational change. The result is an architecture description in the form of texts, diagrams, principles and guidelines which together may provide the basis for all stakeholders to align their work with both the organizational strategy (vertically) and with all organizational units (horizontally). In short, enterprise architecture functions as a bridge between strategy (formulated in terms of business goals and strategic choices) and operational activities. However, to govern and change effectively using enterprise architecture, organizations must rely on a particular architecture framework that inflicts some structure both to the architecture program and to the architecture artefacts. An architecture framework is a foundational structure, or set of structures, that can be used for the development of a broad range of different architectures. It should describe a method for the design of a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. 35

38 An important ingredient of an architecture framework is a way of working, i.e., a method for the creation of architectures. This could include: A process: a set of phases, steps or activities to be performed, as well as constraints or guidelines for the order in which these are performed. This process may or may not be described explicitly. Guidelines and best practices for the application of the process. Most architecturedevelopment processes allow the architect a certain degree of freedom. The guidelines and best practices help him to make decisions on how to apply the process. Techniques to be used during the process, such as modelling techniques, analysis techniques, requirements elicitation techniques, etc. An important technique that an architecture framework may include is a modelling language, used to create uniform architectural descriptions. Such a language defines the concepts and relationships used within each of the architectural domains, as well as the possible relationships between domains. A complete language also needs a uniform notation (preferably graphical) to represent the concepts and relationships. Using an architectural modelling language, it should be possible to create models that show the coherence between different domains. In the case of enterprise architecture, this includes domains such as products, processes, organization, information supply, and technical infrastructure. The resulting models are based on a vision, and on certain explicit constraints, principles, and preferences. Most EA frameworks define a set of viewpoints which can be used during the development or communication of architectures. Each of these viewpoints is tailored towards the needs of one or more stakeholders, addressing one or more concerns, and provides insight into the present and/or future state of the architecture. Furthermore, a framework could provide facilities to help with the storage and retrieval of architectural artefacts, and with the reuse of architectural assets: A repository represents a physical storage place for architectural assets, and provides facilities for version control, access control, etc. Reference models are reusable models or model skeletons that could serve as a starting point for architectural development. A complete approach to EA requires all of these aspects being covered. Moreover, such an approach should indicate how these aspects are related to each other. Figure 11 summarizes these aspects, and illustrates how they are covered by using a combination of TOGAF and ArchiMate, the two open standards of The Open Group that we adopt in this book: On the one hand, TOGAF and ArchiMate have a firm common foundation in their notion of enterprise architecture, that is based on the ISO/IEC definition of architecture. They share the central concept of viewpoints, allowing for different views on a single underlying model, aimed at a specific set of stakeholders and concerns. On the other hand, TOGAF and ArchiMate complement each other in that TOGAF provides an elaborate method, including a process, guidelines, and techniques, for EA development, while ArchiMate provides a well-defined language, including a graphical 36

39 notation, for architectural modelling. Figure 11 Ingredients of an enterprise architecture approach Methodological Framework (based on TOGAF ) As our methodological framework for enteprise architecure, we basically follow the TOGAF Standard. The core of TOGAF is formed by the Architecture Development Method (ADM), a stepwise, iterative process for the development and implementation of an enterprise architecture. The ADM consists of ten phases, which will be explained in detail later in this book. These ten phases can be grouped into four main parts, as shown in Figure 12: 1. Getting the organization commited and involved : the Preliminary Phase prepares the organization as a whole for working under architecture, and involves activities such as establishing an architecture capability, tailoring the architecture methods and techniques for the specific characteristics of the organization, and defining an initial set of architecture principles; Phase A, Architecture Vision, prepares for a single architecture develpment cycle, and includes the formulation of an architecture vision with a high-level overview of the change that is envisaged. 2. Getting the architecture right concerns the description of the actual baseline and target architectures, and an analysis of the gaps between baseline and target. The three phases in this group are concerned with three main types of architectures: business architecture (Phase B), information systems architectures (Phase C), and technology architecture (Phase D). 3. Making the architecture work is concerned with the implementation of the developed architecture, and planning the migration to the new situation. It includes Phase E, Opportunities and Solutions, in which the gap analyis results are consolidated and potential implementation work packages are identified; Phase F, Migration Planning, in which work packages are prioritized and a migration plan is established; and Phase G, Implementation Governance, safeguarding the compliance of implementation projects with the architecture. 4. Keep the process running is concerned with the management, prioritization and version control of requirements on the architecture. The central Requirements Management process manages the requirements during an architecture development cycle. In Phase H, Change Management, new requirements are identified that may lead to the start of the new architecture development cycle. 37

40 Preliminary 1. Getting the organization committed & involved 4. Keep the process running H. Architecture Change Management A. Architecture Vision B. Business Architecture Preliminary Preliminary G. Implementation Governance Requirements Management C. Information Systems Architectures H. Architecture Change Management A. Architecture Vision B. Business Architecture H. Architecture Change Management G. Implementation Governance F. Migration Planning A. Architecture Vision Requirements Management E. Opportunities and Solutions B. Business Architecture C. Information Systems Architectures D. Technology Architecture F. Migration Planning E. Opportunities and Solutions D. Technology Architecture H. Architecture Change Management G. Implementation Governance Preliminary A. Architecture Vision Requirements Management B. Business Architecture C. Information Systems Architectures G. Implementation Governance F. Migration Planning Requirements Management E. Opportunities and Solutions D. Technology Architecture C. Information Systems Architectures 2. Getting the architecture right 3. Making the architecture work F. Migration Planning E. Opportunities and Solutions D. Technology Architecture Figure 12 TOGAF Architecture Development Method TOGAF also includes the identification of viewpoints, techniques and reference models. However, it does not define an actual modelling language. TOGAF does define an Architecture Content Framework that identifies relevant architecture building blocks, but this does not constitute a precisely defined language, nor does it provide a notation for these building blocks. ArchiMate complements this by defining a fully worked out (graphical) modelling language, including the definition of relevant viewpoints. This language also provides a concrete visualization of the views identified in TOGAF. The way of working based on TOGAF will be further explained in Chapter Modelling Framework (based on ArchiMate ) The main purposes of a modelling framework are: to identify a commonly accepted set of architecture concepts; to establish the relationships between these concepts and show how they fit together as a whole; to provide one or more standard (graphical) notations for these concepts and relationships. In essence, the enterprise architecture modelling framework is the metamodel of an organization s architectural thinking. Many such frameworks have been proposed in the literature [11, 34, 45, 76, 78, 89, 90]. Also, many organizations choose to define their own specific framework that best suits their needs. However, we argue that organizations without an apparent affinity to a more specialized framework (such as DoDAF for US defense, or FEAF for US government), should strongly consider ArchiMate and TOGAF as the starting points for framework and method adoption. If needed, they could then augment or replace elements as necessary to meet their requirements. In the remainder of this section, we present the modelling framework that forms the foundation of our approach, and which is based on the ArchiMate Standard [43]. The way of modelling based on ArchiMate will be fully explained in Chapters 3 and 4. 38

41 Core framework Figure 13 depicts the modelling framework that underlies the ArchiMate 2.0 core language [46, 81]. The core language is used to model the actual architectures, and therefore it is mainly used in the second part of the TOGAF ADM as described above, Getting the architecture right. This framework decomposes an enterprise along two dimensions: layers, which represent successive abstraction levels at which an enterprise is modelled, and aspects, which represent different concerns of the enterprise that need to be modelled. The layer dimension distinguishes three layers: Business layer, which offers products and services to external customers that are realized in the organization by business processes; Application layer, which supports the business layer with application services that are realized by (software) application components; Technology layer, which offers infrastructural services (e.g., processing, storage and communication services) that are needed to run applications, and are realized by computer and communication devices and system software. The aspect dimension distinguishes the following modelling aspects: The structure aspect (also called active structure), which represents the actors (systems, components, people, departments, etc.) involved and how they are related; The behaviour aspect, which represents the behaviour (e.g., processes and services) performed by the actors, and the way the actors interact; The information aspect (also called passive structure), which represents the problem domain knowledge that is used by and communicated between the actors through their behaviours. The structuring into dimensions allows one to model an enterprise from different viewpoints, where a viewpoint is characterized by one s position along each dimension. A viewpoint represents a certain perspective on the enterprise that is of interest to one or more stakeholders. A stakeholder typically focuses on a (small) range along each of the dimensions. The intersection of these ranges defines a viewpoint. For example, each cell in Figure 13 represents the intersection of a single layer and single aspect. A viewpoint may span multiple or only part of a layer or aspect. Furthermore, depending on the choice of viewpoints, they may (and often will) overlap. Information Behaviour Structure Motivation Business layer Application layer Technology layer Implementation and Migration Figure 13 - ArchiMate core modelling framework (adapted from [46, 81]) 39

42 Each viewpoint comprises a subset of ArchiMate concepts that are used to model an enterprise architecture covering the particular aspects represented by that viewpoint. Accordingly, overlapping viewpoints may include the same concepts. In the remainder of this section, we briefly describe each of the aspects and layers of the ArchiMate framework. Business layer. The business layer of an enterprise architecture establishes the value proposition, business strategy and the working model of the enterprise. The value proposition embodies the added-value an organization delivers to its environment (e.g., product-market combinations). The working model of the enterprise describes how the organization delivers (or should deliver) that added-value to the environment, in other words how the enterprise is (or should be) internally organized. Application layer. In order to deliver its added-value to the environment, the business layer makes use of services delivered by the application layer of the enterprise. Applications are assumed to support all the processes taking place within the business layer of the enterprise. Furthermore, applications must interoperate (exchange information) and ensure the consistent management of data. Technology layer. The application components within the application layer, in turn, make use of services provided by the technology layer. Communication lines, nodes, networks and devices are the primary components of this layer and form together the technical infrastructure of the organization. Structure, behaviour and information. The previous division in layers can be complemented (and further refined) if we consider the nature of the elements we want to model in each of the architectural layers. We assume the actor as being the core concept for modelling systems and organizations (and their architectures). Thus, a system or organization may be regarded as primarily consisting of a set of actors ( active entities ). For these actors, three aspects may be considered: (1) they have structure (describing, e.g., the decomposition of actors in subactors and how actors are related); (2) they show behaviour (e.g., they perform processes, interact with each other, and offer services to their environment) and (3) they are likely to use and exchange information (in other words, they communicate). Note that a system as a whole is also an actor, which shows behaviour and communicates internally and externally (with its environment). The structure aspect encompasses the active structural elements of the Enterprise Architecture. Examples hereof are the department structure, role structure, the overview of people and resources or an organizational chart. In architecture models concepts such as actor, role, collaborations and interfaces give a representation to structural elements of an organization. Structural elements exhibit behaviour in order to achieve a certain goal. The behaviour aspect encompasses the processes and interactions carried out by these structural elements or the services offered by structural elements. 40

43 Examples of this are the process of creating a new mortgage or insurance policy. Also on the application layer there are application components that display behaviour, such as the daily backup of the customer files. In architecture models concepts such as process, function and application function give a representation to the behaviour elements of an organization. The information (or passive structure) aspect encompasses the passive structural elements of an Enterprise Architecture. Examples hereof are an insurance policy (business layer), orders data base (application layer) or a java bean (technology layer). In architecture models one can recognize information aspects represented by means of concepts such as data object, artefact and contract. Extensions As mentioned before, the core of ArchiMate focuses on modelling of the actual architectures. In version 2.0 of ArchiMate, two language extensions were introduced specifically aimed at the other ADM phases. To support the modelling of intentions of stakeholders, thus documenting the motivation behind the choices made in the architecture, the extended ArchiMate framework adds a fourth aspect: the Motivation aspect. This aspect resembles the motivation (or why) column of the Zachman framework [76], and mainly supports the early ADM phases ( Getting the organization committed and involved ), as well as the change management and requirements management phases ( Keep the process running ). The motivation aspect is concerned with the goals and intentions of the enterprise [19, 81]. Requirements modelling and management is positioned within this aspect. For example, in this aspect models of the stakeholders of the enterprise, including their concerns and the assessment of these concerns are included. A concern is interpreted as some area of attention or interest. For example, a CEO may be concerned with executing the mission of the enterprise, a CIO with the clarity of the enterprise architecture and its ability to adapt to change, and a system s manager with the capacity and reliability of the computing and networking platforms used within the enterprise. These concerns may be assessed using a SWOT 1 analysis, identifying the main strengths, weaknesses, opportunities and threats. For example, this analysis may reveal that the enterprise s architecture lacks traceability, which makes it difficult to handle change. In addition, the users or customers of the enterprise may be considered as stakeholders. Customers may be concerned, e.g., with the diversity of the products and services that are offered or the privacy of their information. Also these concerns may be assessed (not necessarily in terms of SWOT) to reveal customer needs. Stakeholders and their concerns may be identified from the enterprise s business plan. This aspect models amongst others the vision, mission, strategies, policies, principles and guidelines of the enterprise, constituting the high-level constraints for the design of the enterprise architecture. Guidance on how this can be done could be also found in The Business Motivation Model [9, 60]. 1 SWOT stands for Strengths, Weaknesses, Opportunities and Threats 41

44 Finally, this aspect also models the goals, requirements and expectations that further constrain the design of the enterprise architecture. These goals, requirements and expectations may originate from the constraints set in the principles domain, or from the assessment of drivers in the stakeholders domain. This assessment may reveal strengths, weaknesses, opportunities or threats that need to be addressed by means of changing existing goals or setting new ones. Another extension of the original ArchiMate framework is the Implementation and Migration layer [42, 81], that mainly supports the implementation-oriented phases of the TOGAF ADM ( Making the architecture work ). This layer includes concepts such as implementation programs and projects to support program, portfolio and project management, and a plateau concept to support migration planning. This aspect aims at covering the main concepts of program and project management standards and best practices, such as MSP [62], PRINCE2 [63] and PMBoK [65]. Concepts that are specific to one of these methods are not part of the extension, but may be defined as specialization of the generic concepts. In this way, the set of concepts and relationships that are defined in the extension is kept at a minimum. 42

45 5. The Way of Working: TOGAF ADM with ArchiMate This chapter proposes a pragmatic approach to the architecture development process, based on open standards. The way of working gives structure to the manner in which the EA development process is carried out, for example, in terms of tasks, subtasks, ordering of tasks, etc. It furthermore provides heuristics, guidelines and suggestions on how these tasks should be performed [87]. In this chapter, we argue that organizations need a complete approach to guide the development of enterprise architecture, from strategy and requirements to implementation and governance. As mentioned before, our goal is to demonstrate that such an approach can result from the combination of two standards currently promoted by The Open Group: TOGAF [79] and ArchiMate [81]. TOGAF [79] has been for more than a decade the world s leading architecture framework and method. ArchiMate is based on previous work concerning the definition of an enterprise architecture description language and framework [43, 46]. This will be done by revisiting each of the TOGAF ADM phases, and showing, also by means of a running example, how ArchiMate can be used for the specification of the different deliverables prescribed by the TOGAF method. 5.1 Introduction One of the strengths of TOGAF is its emphasis on stakeholder concerns for each EA development phase. This emphasis may suggest that TOGAF also describes how an architect should address these concerns. This, however, is only true to a certain extent. What TOGAF actually offers is an open interface for the declaration of such concerns. The actual specification of the concerns is left to any suitable modelling language which is capable to capture such concerns and is compliant with the ISO/IEC 42010:2007 (formerly IEEE 1471) standard. ArchiMate is such a modelling standard. As explained in the previous chapter, 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. The ArchiMate framework is therefore capable of defining stakeholder concerns in viewpoints, while the ArchiMate language is capable of addressing these with corresponding views showing those aspects of the architecture conforming to defined viewpoints TOGAF: more than just architecture process model TOGAF originated as a framework and methodology for development of technical architectures, but has evolved into a generic enterprise architecture framework and method. In February 2009, TOGAF Version 9 was officially launched as the second instalment of the Enterprise edition, and at the end of 2011, Version 9.1 was published [79]. TOGAF consists of six main components: 1. The core of TOGAF is formed by the Architecture Development Method (ADM), a step-wise iterative approach for the development and implementation of an enterprise architecture (see Figure 42). In this chapter, we go through all the phases of the ADM cycle and emphasize 139

46 which of the architecture artefacts could be specified using ArchiMate. It should, however, be noted that more emphasis is put on the ADM phases A to D, which are concerned with the actual development of the four architectures that TOGAF distinguishes: business architecture, application architecture, data architecture and technology architecture. The data architecture and application architecture together are called the information systems architecture. These are the phases for which ArchiMate provides very well suited modelling formalisms and viewpoints. The rest of the views are also covered partly by native ArchiMate viewpoints and partly by proposed extensions to ArchiMate. Preliminary H. Architecture Change Management A. Architecture Vision B. Business Architecture G. Implementation Governance Requirements Management C. Information Systems Architectures F. Migration Planning E. Opportunities and Solutions D. Technology Architecture Figure 42 - TOGAF ADM (taken from [79], The Open Group) 2. The ADM is accompanied by a collection of guidelines and techniques to support its application. The guidelines address adaptation of the ADM to deal with a number of usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (e.g., security). The techniques support specific tasks within the ADM, such as defining principles, business scenarios, gap analysis, migration planning and risk management. 3. The Architecture Content Framework provides a detailed model of architectural work products, including deliverables, artefacts within deliverables and the architecture building blocks that deliverables represent. Although the content framework includes an (informal) description of a metamodel of possible building blocks (Figure 43 shows an overview of this metamodel, in relation to the ADM phases), it is not intended to be a specification of a modelling language, as it does not provide (graphical) representations for the different types of building blocks. 140

47 Figure 43 - TOGAF content framework overview (taken from [79], The Open Group) 4. The Enterprise Continuum describes a view of the architecture repository (a concept which has also been worked out in TOGAF), and provides methods for classifying architecture and solution artefacts, showing how the different types of artefacts evolve, and how they can be leveraged and re-used. This includes architectures (collected in the Architecture Continuum) and solutions (collected in the Solutions Continuum) that exist both in the enterprise and in the industry at large, which the enterprise has collected for use in the development of architectures. 5. Two reference models for possible inclusion in the enterprise s Enterprise Continuum: the TOGAF Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM). 6. The Architecture Capability Framework is a set of resources, guidelines, templates and background information provided to be of assistance to the architect in establishing and architecture practice within the organization. 141

48 5.1.2 ArchiMate and TOGAF The ArchiMate standard provides a language and associated viewpoints for enterprise architecture modelling; it does not offer methodological support for the development of enterprise architectures. Lankhorst and van Drunen [47] have researched the possibility of using of ArchiMate and TOGAF 8 combined. They concluded that the structure of the ArchiMate core language and framework corresponds well with the three main architectural domains that the TOGAF ADM addresses. They also argue that ArchiMate is particularly well suited for assisting architects in maintaining consistency between the different phases, due to ArchiMate s layered approach, where layers are coupled by means of logical services. In Table 57, we propose a mapping of the ArchiMate core and extensions viewpoints onto the TOGAF ADM phases, that makes the relationship between ArchiMate and TOGAF explicit, precise and operational, and that also confirms and extends the conclusions of [47]. The motivation behind this mapping will become explicit during the sections 5.3 to 5.12, in which all the phases of the TOGAF ADM will be revisited, also by means of the ArchiSurance running example. TOGAF ADM phase [79] ArchiMate viewpoint[81] Preliminary phase ArchiMate Framework, Motivation extension viewpoints, Organization viewpoint, Actor collaboration viewpoint A. Architecture vision Introductory viewpoint, Landscape map, Motivation extension viewpoints, B. Business architecture Introductory viewpoint, Organization viewpoint, Actor cooperation viewpoint, Business Product viewpoint, Business function viewpoint, Business process cooperation viewpoint, Information structure viewpoint, Motivation extension viewpoints, Implementation and Migration viewpoints C. Inf. Sys. architecture Data Motivation extension viewpoints, Implementation and Migration viewpoints, Information structure viewpoint, Business pro- architecture cess viewpoint, Application structure viewpoint C. Information systems architecture Application architection viewpoints, Application Behaviour viewpoint, Application Motivation extension viewpoints, Implementation and Migrature cooperation viewpoint, Application structure viewpoint, Application usage viewpoint, Service realization viewpoint, Landscape map viewpoint, Layered viewpoint D. Technology architecture Motivation extension viewpoints, Implementation and Migration viewpoints, Infrastructure viewpoint, Infrastructure usage viewpoint, Information structure viewpoint, Layered viewpoint E. Opportunities and solutions Motivation extension viewpoints, Implementation and Migration viewpoints, Introductory viewpoint, Layered viewpoint, application landscape viewpoint 142

49 F. Migration planning Layered viewpoint, Motivation extension viewpoints, Implementation and Migration viewpoints, Organization viewpoint, Actor collaboration viewpoint G. Implementation Governance - H. Architecture Change Management collaboration viewpoint Motivation extension viewpoints, Organization viewpoint, Actor Requirements Management Motivation extension viewpoints Table 57 - Mapping ADM - ArchiMate viewpoints Also with respect to the TOGAF content framework and metamodel (see Figure 44), the Archi- Mate concepts and relationships can be roughly mapped onto the Business Architecture, Information Systems Architectures and Technology Architecture, which, again, mostly corresponds to the phases with the same name in the TOGAF ADM. Finally, we note that ArchiMate viewpoints that deal with the relationships between architectural layers are difficult to map onto the structure of TOGAF, in which views are confined to a single architectural layer. This is precisely where ArchiMate could complement and reinforce TOGAF: it provides a vendor-independent set of concepts that would help to create a consistent, integrated architecture model. It should be noted that also within the Open Group, efforts are made to further elaborate on the synergy between TOGAF and ArchiMate. Figure 44 - Main ArchiMate concepts positioned in the TOGAF content metamodel 143

50 5.2 The ArchiSurance case study revisited The case study described below is used in the remainder of this chapter as a running example, illustrating how ArchiMate can be used to produce EA deliverables during the execution of the TOGAF ADM cycle. Therefore, in each of the remaining sections, one ADM Phase is discussed, thereby indicating which of the outputs of that phase are realizable using ArchiMate viewpoints. Also, examples of some of these output deliverables are given, in the particular context of the ArchiSurance case study. An overview of the ArchiSurance views is shown in Figure 46. ArchiMate core views are coloured in grey, and extension views in yellow. Note that for the ArchiSurance running case the following principle holds: a view created or used in a certain phase of the ADM cycle can be always reused, refined or extended in the subsequent phases of the ADM cycle, if required. ArchiSurance is a merger of three previously independent insurance companies (Figure 45): - The original ArchiSurance, the largest of the three, offered homeowner s and travel insurance. - PRO-FIT was a company specializing in car insurance. - LegallyYours was a small company specializing in legal aid insurance. ArchiSurance offers all the insurance products of the original companies. It has a common front-office for customer contacts, and for each class of insurance products, there is a separate back-office. Home & Away Homeowner s and Travel insurance PRO-FIT Car insurance ArchiSurance LegallyYours Legal Expense insurance Figure 45 - ArchiSurance 144

51 The problem ArchiSurance faces is the inflexibility of their application architecture, which makes it difficult to anticipate and respond to changes in the business environment. As a result of several mergers, in the last decade, the application landscape within ArchiSurance has become scattered. Whenever a new company was acquired and new insurance products have been added to the portfolio, new applications were introduced in the existing architecture. The rationale behind this was the choice to manage each (new) insurance product as one complete/separate IT and information entity. This was, at the time, a strategic choice for market responsiveness over the synergy between the different business lines. Over time, this has resulted in the creation of information silos. As the business grew, these information silos became more and more problematic, since they led to the same customer-related information being stored and processed in up to five applications. This causes several problems, including data redundancy, functional overlap and non-standard communication between application instances. Especially the functional overlap has become critical in the last years because of data synchronization requirements. All these circumstances create internal instabilities, unnecessary costs and non-transparencies for the business. This is unacceptable for ArchiSurance because, next to the internal problems, this state of affairs within the EA creates an inflexible organization that is incapable to respond fast to new changes and demands. An example of such a change is the need to share information with other parties involved in the insurance supply chain (e.g., contracted sales partners, insurance consultants). ArchiSurance decided to start a project, with the objective to clean up the application landscape. While the project is sponsored by top management, enterprise architects were made responsible in terms of the end result. Carrying out such a project requires the use of a systematic architecture development method, able to guide the EA process during the migration from the as-is situation to the to-be situation. TOGAF was the obvious candidate for this, because of its wide acceptance and proven track-record. However, as argued above, TOGAF offers little guidance and support for modelling. Therefore, ArchiSurance intends to use a combination of TOGAF and ArchiMate as the basis for a rationalization of their application portfolio. An overview of the views that could be produced in each phase is depicted in Figure 46. This overview is by no means exhaustive but is shows some of the most representative types of views. 145

52 Figure 46 - Overview of ArchiSurance views 5.3 Preliminary Phase In Figure 47 the TOGAF ADM s Preliminary Phase is summarized. On the top of the diagram the objectives targeted in this phase are defined. The main steps taking place during this phase (indicated at the bottom of Figure 47) are assumed to lead to the transformation of the artefacts indicated under the heading Input into the architecture deliverables listed under the Output heading. For each TOGAF ADM phase a similar diagram (which can be used as a quick reference card) is provided as a summary of the detailed description of that phase (to be found in [79]). 146

53 Input 1. Reference Materials External: TOGAF, other EA frameworks 2. Non-Architectural Inputs: business strategies, principles, goals, and drivers, portfolio/project management, (architecture) governance, IT strategy 3. Architectural Inputs: Pre-existing models can be used as a base-line (e.g., Existing Organizational Model for EA, EA Framework, EA Principles, EA Repository) Objectives 1. Determine the Architecture Capability desired by the organization 2. Establish the Architecture Capability Preliminary Phase Steps 1. Scope the Enterprise Organizations Impacted 2. Confirm Governance and Support Frameworks 3. Define and Establish Enterprise Architecture Team and Organization 4. Identify and Establish Architecture Principles 5. Select and Tailor Architecture Frameworks 6. Implement Architecture Tools Output 1. Organizational Model for EA 2. Tailored Architecture Framework 3. Configured and deployed tools 4. Initial EA Repository 5. Request for EA Work 6. Governance Framework Figure 47 Preliminary Phase 3 Table 58 indicates which of the outputs prescribed for this phase can be supported either by one of the ArchiMate viewpoints and can be created using an EA tool supporting it. Such a table has been created for all the phases of the TOGAF ADM, with the intention of clearly specifying to what extent architecture artefacts (as prescribed by TOGAF) can be created using ArchiMate. Other viewpoints are written in bold. They designate TOGAF viewpoints (specified in ArchiMate). Preliminary Phase Outputs [79] Organizational Model for Enterprise Architecture, including: Scope of organizations impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Re-use requirements Budget requirements Requests for change Governance and support strategy Supporting ArchiMate viewpoints Organization viewpoint - n.a. (most likely a document) Organization viewpoint, Actor collaboration viewpoint Motivation extension viewpoints use-case viewpoint Motivation viewpoint - n.a. (most likely a document) - n.a. (most likely a document) 3 This summary, as well as those of the subsequent phases, are based on the descriptions in [79], The Open Group. 147

54 Tailored Architecture Framework, including: Tailored architecture method Tailored architecture content (deliverables and artefacts) Architecture Principles Configured and deployed tools, including evaluation report if conducted Initial Architecture Repository, populated with framework content TOGAF + ArchiMate framework TOGAF+ ArchiMate viewpoints Principles viewpoint e.g., BiZZdesign Architect, SoftwareAG toolset, etc. e.g., BiZZdesign Architect, SoftwareAG toolset, etc. Restatement of, or reference to, Business Principles, Business Goals, and Business Drivers Motivation extension viewpoints Request for Architecture Work - n.a. (most likely a document) Governance Framework - n.a. (most likely a document) Table 58 - Modelling support for the outputs of the Preliminary phase To make the mapping presented in Table 58 more concrete we explain below how to create a few of the above-mentioned outputs in the context of the ArchiSurance case. Following the development activities as prescribed in the ADM, the ArchiSurance project started with the Preliminary Phase. The first decision taken by the top management was to consult with the Architecture Steering Committee (ASC) and give them the task to initiate a new architecture program that would lead to the development of the future architecture. As a result, the ASC defined a governance structure and identified the necessary roles and responsibilities as documented (using an ArchiMate organization view) in Figure 48. The Core Architecture Team s (CAT) first activity was to scope the EA project. As mentioned before, the new project will have important consequences for the customer-related information management of the three merging business units: the original ArchiSurance, PRO-FIT and LegallyYours. The main goal of the project is the development of an integrated EA in which the CRM systems and the back-office applications of the three formerly independent companies are integrated. Furthermore, the CAT produced an inventory of all business and architecture high-level principles that will govern the project, and to which the future architecture of the Relations domain must conform. Their specification (shown in Figure 49) is a principle view. 148

55 Figure 48 - Preliminary phase - Roles & responsibilities and EA governance authority structure Figure 49 - Preliminary phase - High-level architecture principles 149

56 The main deliverables that were created in the Preliminary Phase of the ADM include: organizational model for enterprise architecture, tailored architecture framework, request for Architecture Work. The organizational model for enterprise architecture is a description of organization, roles, and responsibilities within the enterprise related to the enterprise architecture practice. Of particular importance is the definition of boundaries between different enterprise architecture practitioners and the governance relationships spanning across these boundaries. Within a single enterprise, the customised architecture method, content framework, or language may be different for architectures at different hierarchical levels. In the case of ArchiSurance, for diagrams in their Corporate Enterprise Architecture, a subset of the ArchiMate language has been chosen as shown in Figure 50. For ArchiSurance s Domain Architectures, however, full ArchiMate and some ArchiMate extensions are used. The Request for Architecture Work was produced in the form of a document that was sent from the sponsoring organization to the architecture organization to trigger the start of the architecture development cycle (the table of contents of this document is presented in Figure 51). Figure 50 - Subset of ArchiMate used in ArchiSurance s Corporate Enterprise Architecture 150

57 Figure 51 - Request for Architecture Work Contents 5.4 Phase A: Architecture vision Van den Berg and Steenbergen [6] argue that the architecture process is placed fairly far from an organization s primary processes (e.g., it has no direct impact on business processes such as the sales of services or the production of goods). The influence is rather indirect: enterprise architecture ensures that the necessary adjustments in the business processes, information processes and technology infrastructure, due to changing requirements from both inside and outside the organization, are carried out in a coherent and consistent way. The importance of this coherence is not necessarily obvious for everybody, since adjustments can be made without having a structured enterprise architecture program in place. Therefore it is important to be able to point out clearly and communicate what is the added value of EA and of an EA program in facilitating a consistent change process. To do this, first an architecture vision must be defined. Such an architecture vision, explained in a vision document, represents a common starting point for all the change processes. The architecture vision phase focuses on the following aspects [6, 77, 79]: Motivating the enterprise architecture program (and formulating its mission statement ) and relating it to internal or external architecture drivers (for a detailed description of EA drivers see Section 2.2); Raising the level of trust of the organization in the role and function of architecture; Receiving the support and commitment of the top management, line management, shareholders and employees; Giving focus to the work of the architecture team; Validating the goals, principles and corresponding guidelines of the organization; Identifying the relevant stakeholders and their goals and interests; Defining the most important organizational requirements and constraints; Receiving the formal approval for the architecture program. A summary of the TOGAF ADM approach for the architecture vision phase is given in Figure

58 Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Business Principles, Business Goals, and Business Drivers 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework Objectives 1. Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture 2. Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision Steps 1. Establish the Architecture Project 2. Identify Stakeholders, Concerns, and Business Requirements 3. Confirm and Elaborate Business Goals, Business Drivers, and Constraints 4. Evaluate Business Capabilities 5. Assess Readiness for Business Transformation 6. Define Scope 7. Confirm and Elaborate Architecture Principles 8. Develop Architecture Vision 9. Define the Target Architecture Value Propositions and KPIs 10. Identify the Business Transformation Risks and Mitigation Activities 11. Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval Phase \ A: Architecture vision Figure 52 - Phase A: Architecture vision Output 1. Approved Statement ofarchitecture Work 2. Refined statements of Business Principles, Business Goals, and Business Drivers 3. Architecture Principles 4. Capability Assessment 5. Tailored Architecture Framework 6. Architecture Vision 7. Additional content populating the Architecture Repository Table 59 indicates which of the outputs prescribed for this phase, can be supported either by one of ArchiMate s viewpoints or by one of its proposed extensions and can be created using an EA tool supporting it. However it should be noted that deliverables of the Architecture Vision typically covers the breadth of scope identified for the project, at a high level [79]. Therefore more informal viewpoints and diagramming techniques are often employed. Both ArchiMate and the motivation extension provide such viewpoints: Application landscape map viewpoint [81], Introductory viewpoint [81] and the (ArchiMate s requirements extension) use-case viewpoint. Architecture Vision Phase Outputs [79] Approved Statement of Architecture Work, including in particular: Scope and constraints Plan for the architectural work Roles and responsibilities Risks and mitigating activity Work product performance assessments Business case and KPI metrics Refined statements of Business Principles, Business Goals, and Business Drivers Architecture Principles Capability Assessment Supporting ArchiMate & TOGAF viewpoints Motivation viewpoints Implementation & Migration viewpoints Organization viewpoint, Actor collaboration viewpoint - n.a. (most likely a document) Stakeholder viewpoint Motivation viewpoints Motivation viewpoints Principles viewpoint Stakeholder viewpoint 152

59 Tailored Architecture Framework (for the engagement), including: Tailored architecture method Tailored architecture content (deliverables and artefacts) Configured and deployed tools TOGAF + ArchiMate framework TOGAF + ArchiMate viewpoints BiZZdesign Architect, SoftwareAG, etc. Architecture Vision, including: Refined key high-level stakeholder requirements Baseline Business Architecture, V 0.1; Target Business Architecture, V 0.1 Baseline Technology Architecture, V 0.1; Target Technology Architecture, V 0.1 Baseline Data Architecture, V 0.1; Target Data Architecture, V 0.1 Baseline Application Architecture, V 0.1; Target Application Architecture, V 0.1 Stakeholder and requirements viewpoints Introductory Viewpoint (i.e., Solution Concept Diagram), Value chain diagram, Organization viewpoint, Actor cooperation viewpoint, Business function viewpoint, Business process viewpoint, Business process cooperation viewpoint, Information structure viewpoint Introductory Viewpoint (i.e., Solution Concept Diagram), Infrastructure viewpoint, Infrastructure usage viewpoint, Information structure viewpoint, Layered viewpoint Information structure viewpoint Introductory Viewpoint (i.e., Solution Concept Diagram), Application Behaviour viewpoint, Application cooperation viewpoint, Application structure viewpoint, Application usage viewpoint, Service realization viewpoint, Application Landscape map viewpoint, Layered viewpoint Product viewpoint Communications Plan - n.a. (most likely a document) Additional content populating the Architecture e.g., BiZZdesign Architect, SoftwareAG Repository toolset, etc. Table 59 - Modelling support for the outputs of the Architecture vision phase In order to make the mapping presented in Table 59 more concrete it is explained below how a few of the above-mentioned outputs should be created in the ArchiSurance case. 153

60 The architects and management of ArchiSurance have agreed on a Statement of Architecture Work for the introduction of their new CRM system. Figure 53 summarizes the contents of this document. Figure 53 - Example of a Statement of Architecture Work New CRM system for ArchiSurance Next to the Statement for Architecture work, in Phase A, a main concern was to determine what the ArchiSurance s long term vision concerning the total application landscape and how the new project will fit in. Any EA project within a given scope (in our case the ArchiSurance domain) basically deals with multiple gaps on different layers (business, application and technology) created by the need to migrate from the current to the desired situation. In this respect, it is important to emphasize the role TOGAF plays in getting from business scenarios to business processes and applications, which eventually have to be consistent with each other. This creates a gap with the as is state of the EA (in TOGAF terminology, the baseline architecture). This gap, between baseline architecture (i.e., ArchiSurance with sub-administrations) and the target architecture (i.e., ArchiSurance with one CRM and Backoffice), must be bridged on both business and operational level. The ArchiMate language is rich enough to model the baseline and target architectures for the different phases, at varying levels of detail. Furthermore, ArchiMate could be also used for defining the transition between them, by the modelling one or more intermediary architectures. This is also the core of the ArchiSurance project, which is covered in the next ADM phases. 154

61 In Phase A, the CAT s first activity consists in drafting the model that describes the application domain in the current and desired situations (i.e., the Baseline Application Architecture, V 0.1 and Target Application Architecture, V 0.1, see Figure 54 and Figure 55). It should be noted that most deliverables produced in this phase are rather high-level and their main purpose is to scope the architecture development process and provide overview. Therefore, the application landscape viewpoint is used, which is more appropriate at this stage, than other (more detailed) application layer viewpoints. Currently, back-office functionality (e.g., policy administration, financials, claim data management) is divided over four different applications, and there is a separate CRM system for the Legal Aid department (see the application landscape map in Figure 54). Products Business Func ons Maintaining Customer & Intermediary Rela ons Homeowner s insurance Travel insurance Liability insurance Web portal Auto insurance Legal Expense insurance Call center applica on Customer rela onshipmanagement system Legal Expense CRM Contrac ng Claim Handling Financial Handling Home & Away Policyadministra on Home & Away Financial applica on Auto Insurance applica on Legal Expense BO system Document Processing Document management system Figure 54 - Phase A - ArchiSurance application landscape map: baseline In the envisaged target situation, there will be a single back-office system for all types of insurance, covering all back-office functionality, as well as a single CRM system for all departments (see the application landscape map in Figure 55). 155

62 Products Business Home Functions Insurance Maintaining Customer & Intermediary Relations Contracting Claim Handling Financial Handling Travel Insurance Liability Insurance Web portal Car Insurance Call center application Customer relationship management system Home & Away Policy administration ArchiSurance Car insurance application back-office system Home & Away Financial application Document Document management system Processing Figure 55 - Phase A - ArchiSurance application landscape map: target Legal Aid Insurance Legal Aid CRM ArchiSurance CRM system Legal Aid back office system One way to specify, at a high level, all target (or baseline) architectures (i.e., business, application and technology) and their interdependencies is by using the Introductory viewpoint of ArchiMate [81]. Figure 23 shows an example of such a view. As stated in [79]: Once the current and desired business capabilities are understood, their likely implications for the organization s technology capability can be assessed, creating an initial picture of new IT capability that will be required to support the Target Architecture Vision. In the case of ArchiSurance such an understanding can be achieved using a stakeholder view, by means of which such assessments can be specified as depicted in Figure 56. Figure 56 - Phase A Current capability assessment According to [79], business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Besides, several future business scenarios, that the future architecture must support, have been examined and specified. These scenarios focus on the exchange of information with the customer, in order to provide better insurance services. These scenarios can be represented as UML Use Case Diagram, as indicated in Figure

63 Figure 57 - Phase A Use Case Diagram From an early stage, the various interest groups must be involved in the architecture program because their ideas, involvement and support are critical for the success of the whole process. Stakeholders are organizations, teams or individuals that play a key role or have certain concerns with respect to the architecture program. Different stakeholders, playing different roles, also have different concerns. Concerns are the key drivers of the stakeholders, which, from their perspective, are decisive for the acceptance of the architecture program. The concerns may refer to any aspect of the architecture program, ranging from specific process or technology design issues to cross-domain quality aspects such as reliability, security or flexibility. One must make an inventory of all stakeholders and their concerns in the architecture vision phase. An example of such an inventory (realized using the stakeholder viewpoint) for the ArchiSurance case is given in Figure 58. The driver concept from the ArchiMate motivation extension is used to model the concerns. Figure 58 - Phase A - Stakeholders concerns (realized using the stakeholder viewpoint) Furthermore, one must relate these concerns to the goals of the future architecture. This need has been formulated in TOGAF in terms of the specification of the refined key high-level stakeholder requirements. This can be achieved using the goal refinement viewpoint (as proposed in the motivation extension) and instantiated for a subset of the ArchiSurance case in Figure

64 Figure 59 - Phase A Goal refinement view Central to this viewpoint is the concept of goal. The goals of the enterprise architecture must be grounded in the overall business strategy of the organization. Furthermore, goals also give indications about the desired end-state architecture and are the foundation of the design of the future architecture. They should be used to express both functional and non-functional requirements as precise as possible. They also allow the architects to identify the gaps and to help prioritise migration plans, which the organization will use to achieve its end-state architecture. The importance of carefully documenting and defining the goals of the architecture process has been emphasized by other literature sources as well. For example in [1] goals, in the form of the common requirements vision (CRV), are acknowledged as an essential deliverable that forms a justification vehicle for the investment in architecture and for the alignment between business and IT. This deliverable targets the senior managers - in order to gain formal approval and support for the EA process - and is developed by business strategists, business technologists and the architecture team and IT managers. The goals of the architecture project must be SMART (Specific, Measurable, Attainable, Realistic and Time-based). In order to make them measurable, all high-level (soft) business goals must be refined into lower-level hard goals and must be related to key performance indicators (KPIs), as early as possible. Thus, even high-level goals, such as, increased flexibility, increased agility, flexible outsourcing, improved information exchange can be eventually expressed in terms of optimal reuse of resources (e.g., services, personnel, applications, etc.), amount of time spent on development of new components, time-to-market, lower support costs, lower acquisition costs, lower personnel costs, time savings. These goals must receive the broad support from the organization. If the goals of the architecture project are not well understood and accepted by everybody, or if the different stakeholder have different goals, then there is a high risk the acceptance of EA will be low and the architecture project will fail. Another deliverable prescribed in this phase is a refined version of architecture principles. Architecture principles are statements, which can be both, domain-specific, or cross-domain. Architecture principles can prescribe, for example, organization-wide cultural norms, quality requirements, general and domain-specific design aspects concerning current and future state architecture, etc. A description of architecture principles and of the manner in which principles should be phrased can be found in Appendix 2. A concrete example of architecture principle for the business layer is given below: 158

65 Due diligence principle: Each process has at least an administrative role, an execution role and a control role attached. The execution role and the control role cannot be assigned to the same person or organization. A refined version of the ArchiSurance architecture principles modelled using the ArchiMate principle viewpoint can be found in Figure 60. In order to increase their readability and maintainability, principles could also be structured and clustered in some meaningful way. Figure 60 - Phase A - Architecture principles We conclude this phase by emphasizing the importance of one other deliverable. Since an enterprise architecture consists of large volumes of complex and inter-dependent information, effective communication of targeted information to the right stakeholders at the right time is a critical success factor. 159

66 A communications plan allows for this communication to be carried out within a planned and managed process. Such a plan should be prepared at the outset of a specific architecture development cycle, i.e., during the Architecture Vision phase. Note that the topics of communicating architectures and communication plan are extensively discussed in Chapter 7. Figure 61 shows a typical table of contents for a communications plan. 1. Identification of stakeholders and grouping by communication requirements 2. Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and Critical Success Factors 3. Identification of mechanisms used to communicate with stakeholders and allow access to architecture information 4. Identification of a communications timetable, showing which communications will occur with which stakeholder groups, when, and where Figure 61 - Communications Plan Contents 5.5 Phase B: Business Architecture The TOGAF ADM is a business-driven approach. This means that the actual design process begins with the business layer, and then continues with the application and technology layers respectively. The business architecture to be built in this phase corresponds to the first layer in the ArchiMate framework. A fully fledged architecture of the business layer does not only describe the products, services, functions, processes, information and the organization domains but will also specifies which relationships and dependencies exist both within and across the domains of this layer and across layers (i.e., between this layer and the other two layers application and technology). The importance of having insight in these dependencies has been explained in Chapter 1. An overview of the Enterprise Business Architecture phase is given in Figure 62. Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Business Principles, Business Goals, and Business Drivers, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Approved Statement of Architecture Work, Architecture Principles, Enterprise Continuum, Architecture Repository, Architecture Vision Objectives 1. Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns 2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures Phase B: Business Architecture Steps 1. Select Reference Models, Viewpoints,and Tools 2. Develop Baseline BA Description 3. Develop Target BA Description 4. Perform Gap Analysis 5. Define Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalise the Business Architecture 9. Create Architecture Definition Document Output 1. Refined and updated versions of the Architecture Vision phase deliverables 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. BA components of an Architecture Roadmap Figure 62 Phase B: Business Architecture 160

67 Table 60 indicates which of the outputs prescribed for this phase, can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Business Architecture Phase Outputs [79] Refined and updated version of the Statement of Architecture Work Refined and updated version of Business Principles, Business Goals, and Business Drivers Architecture Principles Draft Architecture Definition Document, including:: Baseline Business Architecture*, Version 1.0 (detailed), Target Business Architecture*, Version 1.0 *The BA (baseline and target) must include: Organization structure - identifying business locations and relating them to organizational units Business goals and objectives - for the enterprise and each organizational unit Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally Business processes, including measures and deliverables Business roles, including development and modification of skills requirements Business data model Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report Supporting ArchiMate & TOGAF viewpoints Stakeholder viewpoint, Goal refinement viewpoint; Organization viewpoint, Actor collaboration viewpoint Principles viewpoint, stakeholder and goal refinements viewpoints Principles viewpoint Introductory Viewpoint (Solution Concept Diagram), Organization viewpoint, Actor cooperation viewpoint, Business Product viewpoint, Business function viewpoint, Functional Decomposition Diagram, Business process viewpoint, Business process cooperation viewpoint, Information structure viewpoint, Business Footprint Diagram, Business Service/Information Diagram 161

68 Draft Architecture Requirements Specification, including such Business Architecture requirements as: Gap analysis results Technical requirements - identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (for example, guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework) Updated business requirements Implementation and Migration viewpoint Motivation extension viewpoints Motivation extension viewpoints Business Architecture components of an Architecture Roadmap Migration viewpoint Table 60 - Modelling support for the outputs of the Business Architecture phase In the remainder of this section several models are presented that constitute the specification of only a few of the deliverables prescribed in Table 60. However, it should be noted that many other views can be created to cover most of the deliverables. Phase B marks the start of a refinement process in which the business scenarios defined in the previous phase are further formally specified in the business communication model (this can be represented as an ArchiMate business function view) showing which information is exchanged by the actors involved (see Figure 63). Figure 63 - Phase B - Business Communication 162

69 They also constitute the starting point for devising ArchiMate models of business processes, business functions and customer data for the as-is and to-be situation of the ArchiSurance EA. These models contain concepts such as business processes, actors and roles, business objects and business collaborations. However, the architecture specification is not yet complete if one manages to model each of the above-mentioned domains (i.e., products, services, organization, process, function, information). It is precisely the way domains are connected to each other that interest architects. A selection of questions that refer to issues related the architecture coherence is given below: In which way products and services are realized by business processes? What role executes a certain business process and which role controls the results of a business process? What type of communication takes place between roles (e.g., departments) and what is the contribution of a business process to business function? In order to incorporate the coherence elements in the architecture, the architecture team must describe the relationships between domain-specific models. Coherent models are models that do not focus on any of the three architecture layers, but rather on what should be modelled between them. Coherence is important because it makes explicit the relationships between the different layers/domains, since precisely these relationships ensure the alignment between the layers, that is, the Business-IT alignment. To summarize, one may say that a coherent model is a model that states (in the form of models and design principles), at a certain moment in time, how domains are related to each other. For the ArchiSurance case, among others, the following models have been produced: a business product model (Figure 64), the business functions model (the Functional Decomposition diagram, see Figure 65), function support maps showing which business processes support the business functions (see Figure 66 and Figure 67), the organizational chart (see Figure 68) and a business objects model (see Figure 69). Figure 64 -Phase B - Archisurance business product view 163

70 Figure 65 - Phase B - Business functions of ArchiSurance (TOGAF Functional Decomposition Diagram) Figure 66 - Phase B - Function support map 164

71 Figure 67 - Phase B - Relation business functions/processes Figure 68 - Phase B - Organizational model Figure 69 - Phase B- Business objects 165

72 In the ArchiSurance case presented in Section 5.2, the business architecture of ArchiSurance does not change, i.e., baseline and target are the same. In this case, the business architecture is used only as context for the other architectures. Nevertheless, some of the important outputs mentioned by the TOGAF ADM in this phase are business requirements and the specification of how these requirements relate to the target business architecture. This could be done using the requirements realization view defined for the Motivation extension of ArchiMate. Figure 70 illustrates the decomposition of a possible goal - Revise claim handling process into sub-goals, which results in a requirement to explicitly check customer information. Two alternatives solutions are identified for the requirement to check customer information, i.e., manually by an employee or automated using a CRM application. In this case, both alternatives are realized by the Claim accept service, which is implemented by a separate sub-process in the entire claim handling process. Hence, this sub-process is likely to change in the target business architecture and, indirectly, also results in a change of the application architecture, as a consequence of the original Revise claim handling process goal. Figure 70 - Phase B - Relating goals and requirements to business architecture 5.6 Phase C: Information Systems Architecture The Information Systems Architectures phase focuses on the specification of the application and data domains and of the relationships and dependencies that exist both between these domains and between these domains and domains of the other two architectures (business Phase B and technology Phase D). As mentioned before, in the Information Systems Architectures phase of the TOGAF ADM, two types of architecture are considered: Application Architecture and Data Architecture. TOGAF does not prescribe an order in which these architectures should be developed. Two opposite ways of working can be distinguished: 166

73 An application-driven approach, which best fits the underlying principle key applications form the core underpinning of mission-critical business processes. In this approach, Application Architectures are developed before Data architectures. A data-driven approach, which best fits the underlying principle data represents the corporate assets. In this approach, Data Architectures are developed before Application Architectures. In practice, both architectures usually evolve in parallel (Figure 71 illustrates this), although depending on the approach and the specific circumstances of the architecture project under consideration, the emphasis may gradually shift, during the execution of Phase C, from the Application Architecture to the Data Architecture, and vice versa. Develop Application Develop Architecture Develop Business Technology Architecture Develop Architecture Data Architecture (Phase B) (Phase C) (Phase D) Figure 71 - Application Architecture or Data Architecture first? An overview of the Information Systems Architecture phase is given in Figure 72. Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Application Principles, Data Principles, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document, Draft Architecture Requirements Specification, BA components of an Architecture Roadmap. Objectives 1. Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns 2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures Phase C: Information Systems Architectures Steps Detailed steps for Phase C are given separately for each architecture domain. Output 1. Refined and updated versions of the Architecture Vision phase Deliverables, including updated Statement of Architecture Work 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. Information systems components of an Architecture Roadmap Figure 72 Phase C: Information Systems Architecture This phase is further refined into two separate sub-phases, each of which is described in the following two paragraphs. 167

74 5.6.1 Data Architecture An overview of the Data Architecture sub-phase is given in Figure 73. Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Data Principles, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document, Draft Architecture Requirements Specification, BA components of an Architecture Roadmap. Objectives 1. Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns 2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Data Architectures. Phase C: Data Architecture Steps 1. Select Reference Models, Viewpoints, and Tools 2. Develop Baseline Data Architecture Description 3. Develop Target Data Architecture Description 4. Perform Gap Analysis 5. Define Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalise the Data Architecture 9. Create Architecture Definition Document Output 1. Refined and updated versions of the Architecture Vision phase Deliverables, including updated Statement of Architecture Work 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. DA components of an Architecture Roadmap Figure 73 Phase C: Data Architecture Table 61 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Data Architecture sub-phase Outputs [79] Refined and updated version of the Statement of Architecture Work Validated and new Data Principles Draft Architecture Definition Document, including: Baseline Data Architecture*, Version 1.0 Target Data Architecture*, Version 1.0 Supporting ArchiMate & TOGAF viewpoints Stakeholder viewpoint, Goal refinement viewpoint; Organization viewpoint, Actor collaboration viewpoint Principles viewpoint Information structure viewpoint, Business process viewpoint, Application structure viewpoint, Class Diagram, Data Dissemination Diagram *The DA (baseline and target) must include: Business data model Logical data model Data management process models Data Entity/Business Function matrix 168

75 Draft Architecture Requirements Specification, including such Data Architecture requirements as: Gap analysis results Data interoperability requirements Relevant technical requirements that will apply to this evolution of the architecture development cycle Constraints on the Technology Architecture about to be designed Updated business requirements, if appropriate Updated application requirements, if appropriate Implementation and Migration viewpoint Goal refinement and requirements realization viewpoints; Goal refinement and requirements realization viewpoints; Goal refinement and requirements realization viewpoints; Use-case, Stakeholder, Goal refinement viewpoints; Goal refinement and requirements realization viewpoints; Data Architecture components of an Architecture Roadmap Migration viewpoint Table 61 - Modelling support for the outputs of the Data Architecture sub-phase 169

76 The data architecture of the data domain is defined as a coherent whole of collectively usable data collections together with the corresponding software means, services, standards, rules and guidelines that ease the use of that data in both predictable and unpredictable situations. The standards and rules are mostly concerned with the specification of quality requirements that must be satisfied by the data stored in the above-mentioned collections, and is to be specified in the Data principles and Data architecture requirements deliverables. A complete data architecture is one in which all the information objects of the business layer are transparently realized by data components. A good data architecture is complete, consistent and stable. The consistency criterion refers to the fact that in data architecture data must be unambiguously and uniquely defined. The documentation must point out precisely which definitions, assumptions and design decisions are envisaged for the data architecture. A data architecture should be designed in such a way that it is easily adaptable and extensible without having to change any of the applications using that architecture. Another often used term for data architecture is data infrastructure. Finally, it should be noted that the design of the data architecture must be discussed with the relevant stakeholders. The design of the data architecture can be completed by performing the following steps [69]: 1. Make a list of the candidate entities. 2. Define the selected entities, their attributes and relations. 3. Relate entities to applications, business, etc. 4. Document the data architecture. For documenting the data architecture in the ArchiSurance case, the following models have been produced: -the information structure view showing business and data objects and the relationships between them (see Figure 74), and covering the business and logical data model deliverables prescribed by TOGAF ADM, -the business process view showing which business processes create/consume data (see Figure 67), and covering the Data Entity/Business Function matrix deliverable prescribed by TOGAF ADM, and -the application structure view showing which applications create/use data (see Figure 75), and (partly) covering the Data management process model deliverable prescribed by TOGAF ADM. 170

77 Figure 74 - Phase C - ArchiSurance information structure view Figure 75 - Phase C - ArchiSurance application structure view Application architecture The goal of the application architecture phase is not to provide a detailed design of the various applications, but rather to give an overview of these applications, of the relationships between them and of the goals/requirements and processes supported by them. An overview of the Application Architecture sub-phase is given in Figure

78 Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Application Principles, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document, Draft Architecture Requirements Specification, BA and DA components of an Architecture roadmap. Objectives 1. Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns 2. Identify candidate Architecture Roadmap components based Phase C: Application Architecture Steps 1. Select Reference Models, Viewpoints, and Tools 2. Develop Baseline Application Architecture Description 3. Develop Target Application Architecture Description 4. Perform Gap Analysis 5. Define Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalise the Application Architecture 9. Create Architecture Definition Document Output 1. Refined and updated versions of the Architecture Vision phase Deliverables, including updated Statement of Architecture Work, Validated or new application principles 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. AA components of an Architecture Roadmap Figure 76 Phase C: Application Architecture Table 62 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Application Architecture sub-phase Outputs [79] Refined and updated version of the Statement of Architecture Work Validated and new Application Principles Draft Architecture Definition Document, including: Baseline Application Architecture*, Version 1.0 Target Application Architecture*, Version 1.0 Supporting ArchiMate & TOGAF viewpoints Stakeholder viewpoint, Goal refinement viewpoint; Organization viewpoint, Actor collaboration viewpoint Principles viewpoint Application Behaviour viewpoint, Application cooperation viewpoint, Application structure viewpoint, Application usage viewpoint, Service realization viewpoint, Landscape map viewpoint, Layered viewpoint, Application Communication Diagram, Application and User Location Diagram, System Use-Case Diagram *The AA (baseline and target) must include: Process systems model Place systems model Time systems model People systems model 172

79 Draft Architecture Requirements Specification, including such Application Architecture requirements as: Gap analysis results Application interoperability requirements Relevant technical requirements that will apply to this evolution of the architecture development cycle Constraints on the Technology Architecture about to be designed Updated business requirements, if appropriate Updated data requirements, if appropriate Implementation and Migration viewpoint Goal refinement and requirements realization viewpoints; Goal refinement and requirements realization viewpoints; Goal refinement and requirements realization viewpoints; Use-case, Stakeholder and Goal refinement viewpoints; Goal refinement and requirements realization viewpoints; Application Architecture components of an Architecture Roadmap Migration viewpoint Table 62 - Modelling support for the outputs of the Application Architecture sub-phase A UML Use Case Diagram [61], called a System Use Case diagram in TOGAF, is a good starting point for a more detailed functional design of an application. Figure 77 shows an example of such a diagram for ArchiSurance, which identifies the use-cases for two prospective applications: The new back-office system, for which two use-cases are identified in which the actor Backoffice employee is involved. An online portfolio management application, which may be used by customers or intermediaries to access their insurance portfolio. Figure 77 - Example of a System Use Case diagram 173

80 During Application Architecture sub-phase we begin always with the description of the current situation (the baseline) by producing an architecture description for each view. The concerns of the stakeholders are decisive for the selection of the appropriate views. These can also be selected from the viewpoint types indicated in Table 65. Generally speaking, for each application the following elements must be specified: the goal/requirements it serves, the function it fulfils, the data it creates, uses, updates or deletes, and the relationships/dependencies it has with other applications. Relating goals and requirements to application and application services can be realized using the requirements realization viewpoint. An example of such a view for the ArchiSurance case is given in Figure 78. Such models may also be included in the Draft Architecture Requirements Specification deliverable. Figure 78 - Phase C - ArchiSurance requirements realization view The (baseline and target) application architectures for the ArchiSurance case are developed using as input the business architecture produced in phase B, and they are at the very core of the Draft Architecture Definition Document. In this context, an important aspect also to be considered in Phase C is formed by the relationships that exist between the Business Architecture and the Application Architecture (i.e., the business-application alignment ). ArchiMate facilitates this process as the business process model is used as a starting point to model the application and information models (see Figure 79). This is the result of one of ArchiMate s strengths built in its formal metamodel to clarify the relationship between, on the one hand, the business concepts and on the other hand, the information and application concepts. While TOGAF does not strongly emphasize this issue, ArchiMate stresses the importance of these relationships and explicitly defines viewpoints to address them. For example, Figure 79 also shows how the business architecture and the application architecture are aligned, by modelling which sub-processes make use of which application services. 174

81 Figure 79 - Phase C - Process-application support (Application Usage view) Figure 80 shows another way to specify how the Business Architecture and the Application Architecture of ArchiSurance are aligned, by modelling which business functions that make up the Handle Claim process make use of which application components. Alternatively, instead of using a diagram, the same information can be presented in an Application-Business function matrix (i.e., a cross-table), as is also shown in Figure 80. Especially for large models, this form of presentation may be easier to understand. Figure 80 - Business-application alignment In the ArchiSurance case, the most prominent differences between Baseline and Target are found in the Application Architecture. A view that clearly highlights the differences is one showing the main application components and the application functions that they fulfil. Figure 81 shows this view for the Baseline situation. It clearly shows the presence of two CRM systems, but also that the back-office systems show overlap in their application functions. Figure 82 shows the same view for the Target state. The two CRM systems have been replace by a single system, and there is a new back-office system that takes care of all the required application functions. 175

82 Figure 81 - Phase C Baseline application architecture Figure 82 - Phase C Target application architecture Once the Baseline and Target Application Architectures have been modelled, a gap analysis can be performed, highlighting the differences between the two. The results of this gap analysis can be used, among others, to review the Target Architecture and identify possible accidental omissions. The gap analysis results may be included in the Draft Architecture Requirements Specification deliverable. The results can be presented in a gap matrix, as described in the TOGAF ADM Guidelines & Techniques; alternatively, they can be shown graphically, e.g., using colours, as shown in Figure 83. The gap analysis technique, and examples of gap analysis results for ArchiSurance (including a gap analysis between the Baseline and Target Technology Architectures) will be presented in Section

83 Figure 83 - Phase C Application architecture gap analysis 5.7 Phase D: Technology Architecture This phase has as general goal the realization of an adequate general architecture description of the technology layer, meeting the following criteria: steady, generic, extensible, adaptive, secure and cost-efficient. The importance of the technology architecture resides in the steady character of this infrastructure: once a choice has been made for a certain infrastructure it is expensive and time-consuming to change it. Furthermore, an adequately functioning technology infrastructure is adaptable. In other words, it can accommodate sudden needs, thus facilitating a flexible architecture. Next to this, the following goals are central in this phase: To derive principles for the design of the technology layer from the architecture vision; To describe the current situation of the technology layer architecture; To design one or more target architectures for the technology layer; To make explicit and comprehensible the dependencies between the infrastructural components; To make explicit and comprehensible the dependencies between the domains of the technology layer and the application layer; To incorporate the concerns of the stakeholders in the design of the target architecture. An overview of the Enterprise Technology Architecture phase is given in Figure

84 Input 1. Reference Materials External: Architecture reference materials, Product information on candidate products 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Technology Principles, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document, Draft Architecture Requirements Specification, BA, DA and AA components of an Architecture Roadmap. Objectives 1. Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns 2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures Phase D: Technology Architecture Steps 1. Select Reference Models, Viewpoints, and Tools 2. Develop Baseline Application Architecture Description 3. Develop Target Application Architecture Description 4. Perform Gap Analysis 5. Define Roadmap Components 6. Resolve Impacts Across the Architecture Landscape 7. Conduct Formal Stakeholder Review 8. Finalise the Application Architecture 9. Create Architecture Definition Document Output 1. Refined and updated versions of the Architecture Vision phase Deliverables, including updated Statement of Architecture Work, Validated or new Technology principles 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. TA components of an Architecture Roadmap Figure 84 - Phase D: Technology Architecture Table 63 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Technology Architecture phase Outputs [79] Refined and updated version of the Statement of Architecture Work Validated and new Technology Principles Draft Architecture Definition Document, including: Baseline Technology Architecture*, Version 1.0 Target Technology Architecture*, Version 1.0 *The TA (baseline and target) must include: Technology Components and their relationships to information systems Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology stack Environments and locations - a grouping of the required technology into computing environments (e.g., development, production) Supporting ArchiMate & TOGAF viewpoints Stakeholder viewpoint, Goal refinement viewpoint; Organization viewpoint, Actor collaboration viewpoint Principles viewpoint Infrastructure viewpoint, Infrastructure usage viewpoint, Information structure viewpoint, Layered viewpoint, Environments and Locations Diagram, Platform Decomposition Diagram 178

85 Expected processing load and distribution of load across technology components Physical (network) communications Hardware and network specifications Draft Architecture Requirements Specification, including such Data Architecture requirements as: Gap analysis results Requirements output from Phases B and C Implementation and Migration viewpoint Motivation extension viewpoints Motivation extension viewpoints Updated technology requirements Technology Architecture components Migration viewpoint of an Architecture Roadmap Table 63 - Modelling support for the outputs of the Technology Architecture phase In order to show the consequences for the hardware landscape of the proposed changes, the technology architects of ArchiSurance constructed a Networked Computing/Hardware diagram for both the Baseline and Target situation. In the Baseline, there are separate application servers for the different back-office applications (see Figure 85). Figure 85 - Phase D Baseline technology architecture 179

86 In the Target Technology Architecture, the back-office application will run on a single application server. However, in order to improve the reliability and availability of the application, a back-up application server for the back-office will be introduced (see Figure 86). Figure 86 - Phase D Target technology architecture Another useful view is a Platform Decomposition diagram describing the internal structure of a hardware platform. It may show, e.g., the infrastructure services that a platform offers to the Application Architecture, and the system software that realizes these services (see Figure 87 for an example). Figure 87 -Phase D Platform Decomposition diagram 180

87 The information systems architecture, consisting of a data architecture and an application architecture, makes use of the services offered by the technology layer. Furthermore, some of the software and data components are (physically) mapped on technology infrastructure components. This mapping is an important criterion for the security, reliability, availability and extensibility of software. This mapping must be made explicit documented in a model. Therefore, another view that is relevant in this phase is that in which the application architecture is mapped onto the technology architecture: in Figure 88, we see a small example of a view that shows which infrastructure services are used by which applications. Again, for large models, an alternative representation using a matrix (cross-table) might be easier to understand. Another useful mapping, which is not shown in this example, is the mapping of applications onto the technology artefacts that realize them (i.e., an application deployment view). Similarly, data object can also be mapped onto the physical artefacts that realize them. Figure 88 - Phase D Application/technology support map The Gap Analysis technique is widely used in the TOGAF Architecture Development Method (ADM) for the validation of an architecture under development, although the emphasis of its use is in Phases B, C, and D. In principle, a gap analysis shows all the differences between Baseline and Target Architectures. However, its basic premise is to highlight a shortfall between the Baseline and the Target Architecture, which may include items that have been deliberately omitted, accidentally left out, or not yet defined. A key step in a gap analysis is to consider what may have been forgotten. The architecture must support all essential information processing needs of the organization. The most critical source of gaps to be considered is the stakeholder concerns that have not been addressed in previous architectural work. Some example of potential sources of gaps, relating to the four architectural domains that TOGAF recognizes, are shown in Figure

88 Data Domain gaps: Data not of sufficient currency Data not located where needed Not the data that is needed Data not available when needed Data not created Data not consumed Data relationship gaps Business Domain gaps: People gaps (e.g., training requirements) Process gaps (e.g., process inefficiencies) Tool gaps (e.g., duplicate or missing functionality) Information gaps Financial gaps Facilities gaps (e.g., buildings, offices space, etc.) Application Domain gaps: Applications impacted Applications eliminated New applications introduced created Technology Domain gaps: Technologies impacted Technologies eliminated New technologies introduced created Figure 89 - Potential sources of gaps (from 79]) TOGAF suggests the use of a Gap Matrix to support gap analysis in Phases B, C, and D of the ADM. The creation of a Gap Matrix involves the following steps: 1. Set up a matrix with all the Architecture Building Blocks (ABBs) of the Baseline Architecture on the vertical axis, and all the ABBs of the Target Architecture on the horizontal axis. 2. Add to the Baseline Architecture axis a final row labelled New, and to the Target Architecture axis a final column labelled Eliminated. 3. If an ABB exists in both the Baseline and Target Architectures, put Included in the intersecting cell. 4. Each ABB from the Baseline Architecture that is missing in the Target Architecture should be reviewed. If it was correctly eliminated, mark it as such in the Eliminated column. If not, an unintentional omission in the Target Architecture has been uncovered that must be addressed in the next iteration of the architecture design - mark it as such in the Eliminated column. 5. If an ABB from the Target Architecture does not exist in the Baseline Architecture, mark it in the New row as a gap that needs to filled, by introducing a new block. When the matrix is complete, anything in the Eliminated column or New row is a gap, which should either be explained as correct or marked to be addressed in a new iteration. The Architecture Building Blocks can be very diverse in nature (they could be, e.g., business services or functions, application services or components, infrastructure building blocks, etc.), and for the complete enterprise architecture, the potential number of ABBs will quickly become very large. Therefore, in practice, we will usually create multiple Gap Matrices, e.g., one for each of the architectural domains (business, application, data, and technology). 182

89 For a gap analysis regarding their technology architecture, the infrastructure architects of ArchiSurance have drawn up a gap matrix with the application servers in the Baseline and Target Technology architectures (see Figure 90). This matrix provides the following information: The ArchiSurance Back-office Server and the Generic Application Server are present in both the Baseline and Target Architectures. In the Target Architecture, separate application servers for the Home & Away and Car backoffices have been eliminated intentionally. In the Target Architecture, the Web server has been left out by accident; this is an indication that the Target Architecture should be revised to include the Web server. The Back-up Back-office Server is a new building block in the Target Architecture. This is an indication that this server should be realized in some way in the new situation, e.g., by buying a new server, or by reconfiguring one of the eliminated back-office servers as a back-up server. Target Baseline ArchiSurance Back-office Server Generic Application Server Back-up Backoffice Server Eliminated Building Blocks Home & Away Application Server Intentionally eliminated Car Application Server Intentionally eliminated ArchiSurance Back-office Server Included Web Server Unintentionally excluded REVISE Generic Application Server Included New Building Blocks GAP Server to be reconfigured as back-up server Figure 90 - Example of a Gap Matrix: Application servers of ArchiSurance When using a visual modelling language such as ArchiMate, there are also several options to show the gaps between Baseline and Target in a visual way, e.g., using colours. 183

90 Figure 91 shows an example for the Technology Architecture of ArchiSurance: The blue elements are elements that are present in both the current and the future situation (Figure 85 and Figure 86 in the previous chapter, respectively). The grey elements only exist in the Baseline Architecture. These will have to be reviewed: they have either been eliminated intentionally, and will be phased out, or it is an unintentional omission in the Target Architecture (which, in this example, is the case for the web server and web portal, as indicated by the red oval and exclamation mark). The orange element, the back-up server, is new in the Target situation. Figure 91 -Visualization of the gap between Baseline and Target Technology Architecture 5.8 Phase E Opportunities and Solutions Phase E is the first phase in which the implementation of the Target Architecture is addressed. The focus is on how to structure and prioritise the change activities regarding the IT portfolio and other portfolios depending on IT into projects, work packages etc. Most often, this phase is approached from an enterprise strategic change perspective, which will lead to the definition, in a top-down fashion, of a phased delivery of the Target Architecture. If such a top-down approach is not possible, TOGAF recommends a tactical opportunistic one, in which the projects escaping the control of the corporate planners are influenced to achieve some of the planning objectives. During this phase, the following aspects are relevant and should be considered by the architecture team: 184

91 The inputs of this phase are extensive (practically all artefacts created in the phases A to D, and especially the gap analysis results). In the previous three phases several architecture models have been developed using viewpoints. These give together a global overview of the baseline situation and of one or more target situations for the three architectures: business, information systems and technology infrastructure layers. The most critical input in this phase are the results of the gap analysis carried out in previous phases and revealing the differences between the current state and a target state architecture, which must be bridged in order to achieve the desired target. Therefore, architects and planners have to consolidate, integrate, and analyse both these artefacts and existing building blocks, and case studies from the Architecture Repository, before deciding how to define an initial critical path. A technique that TOGAF suggests for grouping the gaps identified during the gap analysis in Phases B to D, and assessing potential solutions and their dependencies to one or more gaps, is a Consolidated Gaps, Solutions, and Dependencies Matrix, an example of which is shown in Figure 92. This matrix can be used as a planning tool when creating work packages. The identified dependencies will drive the creation of projects and migration planning in Phases E and F. Consolidated Gaps, Solutions, and Dependencies Matrix No. Architecture Gap Potential solutions Dependencies 1 Business New order Processing Process Use COTS software tool process Implement custom solution Drives applications (2) 2 Application New ordapplication COTS software tool X Process Develop in-house 3 Information Consolidated Customer Use COTS customer base Information Develop customer data mart Base Figure 92 - Example of a Consolidated Gaps, Solutions, and Dependencies Matrix A high-level Implementation and Migration Strategy (that will be further detailed into an Implementation and Migration Plan) is defined and describes the implementation approach, based on the initial critical path. Work packages, projects and portfolios are now identified. Furthermore, it is important at this stage to carry out an impact analysis of the foreseen changes onto the existing enterprise and IT infrastructure in order to evaluate the required effort. The architectures from Phases A to D are used to develop a series of Transition Architectures that show how to gradually move from the Baseline Architecture to the Target Architecture, in all the architectural domains (see Figure 93). If the risk and impact of the envisaged change is of small scale it might be possible to move from the Baseline to the target in one step. However, migration often requires consideration of a number of business and technical issues related to the change of operational systems. In such a case, the change must be incremental and each step is described by a Transition Architecture. Nevertheless, organizations may simultaneously work at several Transition Architectures. For example, one Transition Architecture is being built, another is being designed, and another is being planned. 185

92 Figure 93 - Migration through transition architectures Much of the success of the architecture change depends on the involvement of key stakeholders, such as those from corporate strategic planning, in the definition of the potential Transition Architectures and of the Implementation and Migration Plan. An overview of the Opportunities and Solutions phase is given in Figure 94. Input 1. Reference Materials External: Architecture referencematerials, Product information 2. Non-Architectural Inputs:Request for ArchitectureWork, Capability Assessment, Communication Plan, Planning Methodologies 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Governance models and frameworks, Tailored Architecture Framework, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document,Draft ArchitectureRequirem entsspecification,change requests. Objectives 1. Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D 2. Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value 1. Steps 2. Determine/Confirm Key Corporate Change Attributes 3. Determine Business Constraints for Implementation 4. Review/Consolidate Gap Analysis Results 5. Review IT Requirements from a Functional Perspective 6. Consolidate/Reconcile Interoperability Requirements 7. Refine and Validate Dependencies 8. Confirm Readiness/Risk for Business Transformation 9. Formulate High-Level Implementation/Migration Strategy 10. Identify and Group Major Work Packages 11. Identify Transition Architectures 12. Create Portfolio/Project Charters, Update Architectures Phase E: Opportunities And Solutions Output 1. Refined and updated versions of the Architecture Vision, BA, ISA and TA phases Deliverables, including Updated Statement of Architecture Work, Architecture Vision 2. Draft Architecture Definition Document 3. Draft Architecture Requirements Specification 4. Consolidated and validated Architecture Roadmap 5. Capability Assessment, 6. Transition Architecture, Version Implementation and Migration Plan, Version 0.1, including the high-level Implementation and Migration Strategy Figure 94 Phase E: Opportunities and Solutions 186

93 Table 64 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Opportunities and Solutions Architecture phase Outputs [79] Refined and updated version of the Statement of Architecture Work Architecture Vision including definition of types and degrees of interoperability Draft Architecture Definition Document, including: Identification of increments Interoperability and co-existence requirements Inclusion of project list and project charters Supporting ArchiMate & TOGAF viewpoints Stakeholder viewpoint, Goal refinement viewpoint; Organization viewpoint, Actor collaboration viewpoint Motivation extension viewpoints; introductory viewpoint, layered viewpoint, application landscape viewpoint, etc. (see viewpoints used during Phase A) Migration viewpoint Motivation extension viewpoints Programs and projects viewpoint, Project Context Diagram Draft Architecture Requirements Specification Motivation extension viewpoints Consolidated and validated Architecture Migration viewpoint Roadmap Capability Assessment, including: Stakeholder viewpoint, goal refinement viewpoint + most likely documents - Enterprise Architecture Maturity Profile - Transformation Readiness Report Transition Architecture, Version 1.0, Migration viewpoint including: Implementation and Migration viewpoint, layered view, -Consolidated Gaps, Solutions, and Dependencies Assessment Benefits Diagram, - Risk Register, Version 1.0 most likely other documents - Impact analysis - project list - Dependency Analysis Report - Implementation Factor Assessment and Deduction Matrix implementation and Migration Plan, V 0.1, including the high-level Imple- viewpoint + most likely a document Migration viewpoint, programs and projects mentation and Migration Strategy Table 64 - Modelling support for the outputs of the Opportunities and Solutions phase 187

94 In the remainder of this section we will shortly discuss the contents of the following deliverables: Capability Assessment. Transition Architecture, Version 1.0, including: consolidated gaps, solutions, and dependencies assessment, risk register, version 1.0, impact analysis - project list, dependency analysis report, implementation factor assessment and deduction matrix. Implementation and Migration Plan, Version 0.1, including the high-level implementation and migration strategy. Capability Assessment A capability assessment should address at least the following factors: The organizational impact on shaping the Transition Architecture, The assignment of responsibilities within the organization for the implementation, Corporate cultural requirements for handling change; Thus, typical contents of a Capability Assessment are shown in Figure 95. Figure 95 - Capability assessment - Contents 188

95 The factors evaluated in a capability assessment should be documented. For this purpose TOGAF suggests the use of an Implementation Factor Assessment and Deduction matrix, an example of which is shown in Figure 96. Figure 96. Implementation Factor Assessment and Deduction Matrix (taken from [79], The Open Group ) Implementation and Migration Plan After completion of enterprise s capability assessment it must become clear to what extent the organization is prepared to undergo the change. Furthermore, the results of this assessment must be the basis on which decisions will be taken with respect to the approach selected for the migration towards and implement the target architecture. In terms of methodology, three essentially different approaches are mentioned by TOGAF: Green field: the baseline architecture is discarded and a completely new architecture is put in place Revolutionary: substantial parts of the old architecture will be replaced and the change is radical Evolutionary: the change is gradual and phased and consists of small steps which will incrementally introduce new capabilities in the baseline architecture The green field and revolutionary approaches may be the most profitable strategically, but are also the most costly and create potentially high risks, since they significantly impact the organization. The most common approach is the evolutionary one. The approach selected for migration must be documented in the form of a Implementation and Migration Plan. This is basically a schedule for the implementation of the solution described by a Transition Architecture and includes timing, cost, resources, benefits, and milestones for the implementation. Typical contents of an Implementation and Migration Plan are shown in Figure

96 1. Implementation and Migration Strategy Strategic implementation direction Implementation sequencing approach 2. Interaction with other management frameworks Approach to aligning architecture and business planning Approach to integration of architecture efforts Approach to aligning architecture and portfolio/project management Approach to aligning architecture and operations management 3. Project charters Capabilities delivered by projects Included work packages Business value Risk, issues, assumptions, dependencies 4. Implementation Plan Phase and work-stream breakdown of implementation effort Allocation of work packages to phase and work-stream Milestones and timing Work breakdown structure Resource requirements and costs Figure 97 - Implementation and Migration Plan - Contents Transition Architecture Once the Implementation and Migration Plan is defined, the next step is to assess the missing business capabilities identified in the Target Architecture and decompose these capabilities into increments each having clearly identified and measurable (business) value. These increments are documented and called transition architecture(s). These are further mapped onto work-packages, projects and activities that meant to deliver the capability increments. A Transition Architecture shows the enterprise at incremental states reflecting periods of transition that sit between the Baseline and Target Architectures. It is used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage. 190

97 Typical contents of a Transition Architecture are shown in Figure Opportunity portfolio: Consolidated gaps, solutions, and dependency assessment Opportunity description Benefit assessment Capabilities and capability increments Interoperability and co-existence requirements 2. Work package portfolio: Work package description (name, description, objectives, deliverables) Functional requirements Dependencies Relationship to opportunity Relationship to Architecture Definition Document and Architecture Requirements Specification 3. Milestone and milestone Transition Architectures: Definition of transition states Business Architecture for each transition state Data Architecture for each transition state Application Architecture for each transition state Technology Architecture for each transition state 4. Implementation Factor Assessment and Deduction matrix, including: Risks Issues Assumptions Dependencies Actions 5. Consolidated Gaps, Solutions, and Dependencies matrix, including: Architecture domain Gap Potential solutions Dependencies Figure 98 - Transition Architecture - Contents We illustrate the use of Transition Architectures, and the use of ArchiMate models as part of these architectures, by means of the ArchiSurance case. During the execution of Phase E, the Baseline and Target Architectures of ArchiSurance, as developed in Phases B to D, as well as the results of the gap analysis, were carefully examined and consolidated by the architecture team, resulting in a final version of the Architecture Definition Document. Subsequently several possible Transition Architectures were defined, describing intermediary plateaus in order to fill the gap between the as-is and to-be architectures. In this way, the whole transition process unfolds smoothly over the available time interval and without disruptions of the overall business operations. For example, for the application rationalization process that ArchiSurance envisioned, two intermediary situations can be imaged (assuming that the system development capacity is not sufficient to carry out the two integration projects simultaneously): 191

98 (A) A situation in which the two CRM applications have been replaced by a common application, but in which there are still separate back-office systems. (B) A situation with a single back-office system, but still two separate CRM applications. In this case, these two Transition Architectures represent alternative intermediary situations between Baseline and Target, which can be shown graphically as depicted in Figure 99. If there is a big gap between Baseline and Target, it is also possible that multiple (sequential) plateaus are needed to bridge the gap. Figure 99 - Baseline, Target, and Transition Architectures Architectural views may also be used to show the content of each of the transition architectures. For example, in Figure 100, ArchiMate views are used to sketch the Application Architecture for the alternative Transition Architectures, which may support the choice between these alternatives. Figure Phase E Transition architectures 192

99 Based on these transition architectures, implementation projects can be planned. For example, a project can be defined for the integration of the CRM applications, and a project for the integration of the back-office applications. The order in which these projects are carried out is depends on which of the transition architectures is selected. A selection is made based on the original goals, principles and organizational requirements specified in the architecture vision. The prioritization/selection of the alternative transition architectures that must be implemented will strongly depend on these goals. TOGAF proposes the following views of the type Core Diagram that may be produced in Phase E: Project Context diagram, showing the scope of projects and work packages as part of a broader transformation roadmap. This diagram links a project or work package to the organizations, functions, services, processes, applications, data, and technology that will be added, removed, or impacted by the project. Figure 101 shows a (fragment of a) Project Context diagram for the ArchiSurance case. We assume that there will be two projects, one for the integration of the back-office systems, and one for the integration of the CRM systems. The former project is subdivided in three work packages: one for making modifications to existing software, one for phasing out legacy applications and technology, and one for hardware upgrades. The diagram shows the application and technology components that are affected by these projects and work packages. Green elements indicate a new component (in this case, the back-up application server), blue elements indicate components that need to be modified, and red elements indicate components that will be phased out (i.e., they are part of the Baseline Architecture but no longer present in the Target Architecture). Figure ArchiSurance Project Context diagram 193

100 Benefits diagram, showing opportunities identified in an architecture definition, classified according to their relative size, benefit, and complexity. The diagram can be used by stakeholders for selection, prioritization and sequencing decisions on identified opportunities. Figure 102 shows an example of a (fragment of a) Benefits diagram for the ArchiSurance case. We observe that the realization of a single CRM application is of medium complexity, while it results in some benefits that have a high priority. In contrast, the realization of a single back-office system has a high complexity, while the resulting benefits only have a medium priority. Therefore, it is likely that the project for the integration of the CRM applications will be assigned a higher priority than the project for the integration of the back-office applications. Figure ArchiSurance Benefits diagram 194

101 5.9 Phase F - Migration planning The list with possible alternative transition architectures was finalized in the previous phase and a first version of a migration plan was defined. In this phase, the migration plan will be consolidated and finalized and will be subsequently broken into smaller parts. Independent projects will be created that will cover and plan/implement each of these parts. The architecture models must be seen as a reference frame for governing these projects. Furthermore, it must be checked whether the projects deliver results that remain conformant with the architecture design models. Thus the goals central to this phase are to identify top-level projects that eventually will lead to the realization of the desired target architecture, to assign people and assets to projects and to plan the projects. An overview of the Migration Planning phase is given in Figure 103. Input 1. Reference Materials External:Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment, Communication Plan 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Governance models and frameworks, Statement of Architecture Work, Architecture Vision, Architecture Repository, Draft Architecture Definition Document, Draft Architecture Require-ments Specification, Change requests, Consolidated Architecture Roadmap, Capability Assessment, Transition Architecture V 1.0, Implementation and Migration Plan V 1.0. Objectives 1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan 2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio 3. Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders Steps 1. Confirm Management Framework Interactions for Implementation and Migration Plan 2. Assign a Business Value to Each Project 3. Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles 4. Prioritise Migration Projects through Cost/Benefit Assessment/Risk Validation 5. Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document 6. Generate the Architecture Implementation Roadmap and Migration Plan 7. Establish the Architecture Evolution Cycle and Document Lessons Learned Phase F: Migration Planning Output 1. Implementation & Migration Plan,V Finalised Architecture Definition Document 3. Finalised Architecture Requirements Spec. 4. Finalised Architecture Roadmap 5. Finalised Transition Architecture 6. Re-Usable Architecture Building Blocks 7. Requests for Architecture Work for the architecture aspects of implementation projects 8. Architecture Contracts for implementation projects 9. Implementation Governance Model 10. Change Requests from lessons learned Figure 103 Phase F: Migration planning Table 65 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Migration planning phase Outputs [79] Implementation and Migration Plan, V 1.0 Finalized Architecture Definition Document Finalized Architecture Requirements Specification Supporting ArchiMate viewpoints Motivation extension viewpoints, Organization viewpoint, Actor collaboration viewpoint, Program and project viewpoint See viewpoints used in the previous Phases Motivation viewpoints 195

102 Finalized Transition Architecture ArchiMate viewpoints, Migration viewpoint, Project Context Diagram, Implementation and Migration viewpoint, most likely other documents Finalized Architecture Roadmap Migration viewpoint Reusable architecture building blocks existing architecture models Request for Architecture Work for the architecture aspects of implementation projects - n.a., most likely a document Architecture Contracts (standard) for implementation projects - n.a., most likely a document Implementation Governance Model Organization viewpoint, Actor collaboration viewpoint Change Requests arising from lessons learned - n.a., most likely a document Table 65 - Modelling support for the outputs of the Migration Planning phase Phase F focuses on the creation of a viable Implementation and Migration Plan. This plan is defined by portfolio and project managers. Most Phase F activities concern the evaluation of dependencies between projects, costs, and benefits. To help in the prioritization of project, a business value will be assigned to each project. During the execution of o project, the actual business value of each project should be closely monitored. For the assessment and monitoring of business values, TOGAF proposes a technique that consists of a matrix with a value index dimension and a risk index dimension. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure. Each criterion should be assigned an individual weight. The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known. Figure 104 shows such a matrix for the projects proposed in the ArchiSurance example. Project A, the integration of CRM systems, turns out to have a slightly higher estimated business value than Project B, the integration of back-office systems (e.g., a single CRM system will improve customer relations, which may lead to increased sales; a single back-office system, on the other hand, will not directly affect the service to the customers). Also, Project B has a larger size (costs and resources), which also constitutes a higher risk. Based on these observations, the management decides to assign a higher priority to Project A than to Project B. 196

103 (Project size indicated by size of circle) Project A Value Project B Figure Sample project assessment with respect to business value and risk (adapted from [79]) Risk The prioritised list of projects will form the basis of the detailed Implementation and Migration Plan. The Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that ensures that business value is delivered and that the resources are made available to complete the necessary architecture work. Based on the Baseline, Target and Transition architectures, implementation projects can be identified, and the order in which the projects will be carried out can be planned. In the ArchiSurance example in the previous phase, two alternative Transition Architectures were identified for the application rationalization process of ArchiSurance. Two top-level projects may be defined to realize the Target Architecture: a project for integrating the CRM systems (Project A), and a project for integrating the back-office systems (Project B). The order in which these projects are carried out depends on which of the alternative Transition Architectures is chosen. Based on the business value and risk assessment shown in Figure 104, Project A has received a higher priority and will be carried out first. This leads to the situation described by Transition Architecture A. Subsequently, Project B will be carried out, leading to the situation described by the Target Architecture. This is illustrated in Figure 105. Figure Sequencing of projects During Phase F, the EA evolution is confirmed, consolidated and finalized. Therefore, the most prominent deliverable of this phase is the Implementation and Migration Plan, V 1.0, which can be (partially) specified using the migration viewpoint, as shown in Figure

104 Figure Phase F Migration view Besides the architecture roadmap, during Phase F another important activity is to identify and prioritize the projects that will implement the various parts of the target architecture. One useful principle to remember when doing this is: think big, start small!. In other words, the implementation should begin with the most important architecture components. Especially for organizations that first start working with architecture it is important to achieve some quantifiable results fairly quickly. Therefore, the first project should be a short one ( short-term win ). Depending on the architecture maturity level, an organization may choose to broaden the scope of each iteration. The chosen projects must be planned according to the existing project planning methods, such as Prince II. However, Prince2 deliverables would need to be mapped to EA deliverables. In the ArchiSurance case, the identification of projects and their prioritization and deliverables can also be documented in a diagrammatic way using the project viewpoint of the ArchiMate implementation & migration extension, as depicted in Figure 107. Such a diagram could be part of the TOGAF ADM deliverable Implementation and migration plan, V1.0. Figure Phase F - ArchiSurance project portfolio 198

105 5.10 Phase G Implementation Governance The implementation and migration plan defined in the previous phase will serve as input for the definition of an implementation program, up to the level of individual implementation projects and deployment schedule. It is important at this moment to identify clear goals and responsibilities, to formulate recommendations for each implementation project and govern and manage an Architecture Contract covering the overall implementation and deployment process. An overview of the Implementation Governance phase is presented in Figure 108. Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work, Capability Assessment 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Statement of Architecture Work, Architecture Vision, Architecture Repository, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap, Transition Architecture including Implementation Governance Model, Architecture Contract, Request for Architecture Work (from phase E and F), Implementation and Migration Plan Phase G: Implementation Governance Objectives 1. Ensure conformance with the Target Architecture by implementation projects 2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests Steps 1. Confirm Scope and Priorities for Deployment with Development Management 2. Identify Deployment Resources and Skills 3. Guide Development of Solutions Deployment 4. Perform Enterprise Architecture Compliance Reviews 5. Implement Business and IT Operations 6. Perform Post-Implementation Review and Close Implementation Output 1. Architecture Contract (signed), as recommended in the architecture-compliant implemented architectures 2. Compliance Assessments 3. Change Requests 4. Architecture-compliant solutions deployed Figure 108 Phase G: Implementation Governance Table 66 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Implementation Governance phase Outputs [79] Supporting ArchiMate viewpoints Architecture Contract (signed), as recommended in the architecture-compliant implemented - n.a., most likely a document architectures Compliance Assessments - n.a., most likely a document Change Requests - n.a., most likely a document Architecture-compliant solutions deployed including the architecture-compliant implement- - n.a., most likely a software system ed system Table 66 - Modelling support for the outputs of the Implementation Governance phase 199

106 As one may notice none of the outputs can be specified using ArchiMate. Therefore this phase is not further investigated. However, an in depth discussion of EA governance is presented in Section Phase H Architecture Change Management The goal of the architecture maintenance phase is to take care that changes are incorporated in the Enterprise Architecture in a consistent and architected manner. The better an organization is in maintaining its architecture the faster can that organization react to new opportunities, threats or external changes in the environment. Therefore, in this phase is specified when, under what circumstances and by means of which governance process changes to the enterprise architecture may be applied. Besides this, in this phase it is also discussed under which circumstances a new iteration of the ADM cycle will be initiated. There is a natural mechanism that controls and determines whether an organization should remain in the current iteration or it should trigger a new one. In this mechanism two complementary forces play an important role: rationalization and innovation. Rationalization is always determined by costs and economic arguments. The idea of EA rationalization is to use architecture in order to obtain a maximum of business efficiency improvement with the means available within the existing EA, while EA innovation will attempt the significant renewal of EA, for instance through the acquisition of new tools, the usage of new architecting (modelling, specification) techniques, the design/development of new viewpoints of the EA, the extension of EA scope to other business units or application domains etc. Often, innovation also leads to a substantial change in the EA vision of a company on long term and may indicate EA s entrance in a new maturity phase (see Section 6.5). Therefore, the balance between the two drivers is essential for the evolution of the EA. Below it is explained how the mechanism works (see Section 6.5). Let us assume that a new business goal has emerged, as shown in Figure 109. The first action to be taken is to check whether the respective goal can be achieved using the existing architecture. Figure When to iterate If this is the case, it means the rationalization prevails innovation and the current development status of EA is sufficient for the immediate needs of the enterprise. It also means that the possible EA innovation requirements can be characterised mostly as small-scale changes that must also be incorporated in the architecture descriptions as part of the architecture maintenance phase of the current iteration. Thus, EA is subject to an exploitation process in which the enterprise will try to obtain the maximum of benefit by using it and that a new iteration is not necessary. If, even with small-scale changes, working within the current architecture is not sufficient any more to support the materialization of the new goal then the need for innovation prevails rational- 200

107 ization and it is necessary to step into a new iteration of EA process. As a consequence the architecture vision documents, in which the mission, scoping, roadmap and the business case for EA are stated, will be revised according to the new (business) goals. Thus, large scale changes of the current enterprise architecture will result, and a new ADM cycle should be initiated. An overview of the Architecture Change Management phase is presented in Figure 110. Input 1. Reference Materials External: Architecture reference materials 2. Non-Architectural Inputs: Request for Architecture Work from phases E & F 3. Architectural Inputs: Organizational Model for Enterprise Architecture, Tailored Architecture Framework, Statement of Architecture Work, Architecture Vision, Architecture Repository, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap, Change Request technology & business changes, from lessons learned, Transition Architecture including Implementation Governance Model, Architecture Contract, Request for Compliance Assessments, Implementation and Migration Plan Phase H: Architecture Change Management Objectives 1. Ensure that the architecture lifecycle is maintained 2. Ensure that the Architecture Governance Framework is executed 3. Ensure that the enterprise Architecture Capability meets current requirements Steps 1. Establish Value Realisation Process 2. Deploy Monitoring Tools 3. Manage Risks 4. Provide Analysis for Architecture Change Management 5. Develop Change Requirements to Meet Performance Targets 6. Manage Governance Process 7. Activate the Process to Implement Change Output 1. Architecture Contract (signed), as Requirements Impact Assessment 2. Architecture Requirements Specification Figure 110 Phase H: Architecture Change Management From a methodological point of view, the enterprise architecture change management process of an organization determines how changes are managed, and what techniques and methodologies are used for this. The process includes a filtering function that determines which phases of the architecture development process are impacted by changing requirements. For example, changes that affect only migration may be of no interest in the architecture development phases. There are many existing approaches to change management in general, and various management techniques and methodologies include an approach for this (e.g., project management methods such as PRINCE2, service management methods such as ITIL, management consultancy methods such as Catalyst, etc.). A change management process already in place in a field other than architecture may well be adapted for use in relation to the architecture practice. If no change management process is already in use, TOGAF proposes an approach to change management aimed particularly at the support of a dynamic enterprise architecture. The approach is based on classifying required architectural changes into three categories: A simplification change, which can normally be handled via change management techniques. Such a change is often driven by a requirement to reduce investments. An incremental change, which may be handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change. Such a change is often driven by a requirement to derive additional value from existing investments. 201

108 A re-architecting change, which requires putting the whole architecture through the architecture development cycle again. Such a change is often driven by a requirement to increase investments in order to create new value for exploitation. Another way of looking at these three choices is to say that a simplification change to an architecture is often driven by a requirement to reduce investment; an incremental change is driven by a requirement to derive additional value from existing investment; and a re-architecting change is driven by a requirement to increase investment in order to create new value for exploitation. The following activities may be undertaken to determine which of the above-mentioned types we are dealing with: 1. Registration of events that may impact the architecture 2. Resource allocation and management for architecture tasks 3. Assessment of the course of action to be followed (by the role or process responsible for architecture resources) 4. Impact evaluation TOGAF also provides a rule of thumb for deciding whether a change can be handled by change management (a maintenance change ), or whether a full architecture redesign is required (in which case a new Request for Architecture Work is issued to start a new ADM cycle): If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-entry of the ADM. If the change impacts only one stakeholder, then it is more likely to be a candidate for change management. If the change can be allowed under a dispensation, then it is more likely to be a candidate for change management. For example: If a change has a significant impact on the business strategy, this will most likely affect most of the stakeholders. Therefore, this will most likely require a re-architecting approach. As a result of the emergence of a new technology or standards, there may be a need to refresh the Technology Architecture, but not the whole enterprise architecture. This can often be handled by an incremental change. A dispensation is used as a mechanism to allow for a change that leads to (temporary) noncompliance with the architecture: e.g., a request for unusual service levels for specific business reasons, or the deployment of non-standard technology or products to support specific business initiatives. Dispensations are only granted for a limited time period, which ensures that they are a trigger for the Architecture Compliance process. Table 67 indicates which of the outputs prescribed for this phase can be supported either by ArchiMate viewpoints or by TOGAF viewpoints (also specified in ArchiMate). Change Management phase Outputs [79] Architecture updates (for maintenance changes) Supporting ArchiMate viewpoints - n.a., most likely a document 202

109 Changes to architecture framework and principles (for maintenance changes) New Request for Architecture Work, to move to another cycle (for major changes) Statement of Architecture Work, updated if necessary Compliance Assessments, updated if necessary Architecture Contract, updated if necessary Tailored TOGAF ADM, ArchiMate framework, Principles viewpoint - n.a. (most likely a document) Stakeholder viewpoint, Organization viewpoint, Actor collaboration viewpoint, most likely also documents; also see the outputs of Phase A. - n.a., most likely a document - n.a., most likely a document Table 67 - Modelling support for the outputs of the Change Management phase As one may easily notice, the outputs that can be specified using ArchiMate or its extensions, have been already discussed in the Preliminary Phase or in Phase A. The rest of the outputs can not be specified using ArchiMate or its extensions. For more information on this phase the reader should refer to the original TOGAF 9.1 specification [79] Requirements Management Generally speaking, when attempting to solve a given architectural problem, the first step is to analyse the problem and elicit goals and requirements that address the problem. These goals and requirements are represented by a requirements model. The second step is to conceive a composition of products, services, processes and applications that realizes the previously identified goals and requirements and translate them into enterprise architecture models. Both steps can again be repeated for (the problem of) further refining and realizing the elements of the architecture. Therefore, requirements management are considered to be a combination of requirements engineering, i.e., identifying, analyzing, refining and modelling requirements, and requirements maintenance, i.e., communicating and tracing requirements. Figure 111 illustrates the relationship between requirements and architecture models, and indirectly, also the relationship between the requirements management and enterprise architecture processes. Enterprise architecture process As-is architecture (baseline) To-be architecture design To-be architecture realization Problem Architecture requirements Realization requirements Requirements management process Figure Relationship between enterprise architecture and requirements management 203

110 These processes are typically divided into distinct phases, which result in a series of requirements and architecture models, such that, models in succeeding phases refine models from preceding phases (as represented by the dashed arrows in Figure 112). For example, Figure 112 illustrates this two-phase process during the design and realization of an enterprise architecture. Below this process is explained in more detail. Requirements engineering cycle The idea of problem chains leads to a distinction between two views on an architecture model: (i) architecture model as a design artefact that represents a solution for some design problem, and (ii) architecture model as a frame of reference that delineates the design or solution space. These views are illustrated in the left part of Figure 113. Change Architecture model A1 Change Architecture model A1 Problem-oriented RE Problem investigation Requirements model M Solution-oriented RE Requirements Model M1 Investigate alternative solutions Architecture model A2 Requirements Requirements model M2 model Solution validation Figure Requirements engineering cycle Architecture model A2 In general, the requirements engineering process is triggered by some organizational change that needs to be addressed. This problem cannot be approached from scratch, but has to take the current state of the organization into account, as represented by architecture model A1. This means that any requirement or goal specified in the requirements model M should be defined relative to architecture A1 in order to address the change. In this situation, architecture A1 acts as a frame of reference for the (problem-oriented) requirements engineering process. Subsequently, a new architecture A2 is designed that realizes a solution for the requirements and goals identified in the model M. In this situation, architecture A2 is considered a design artefact that is the result of (solution-oriented) requirements engineering. The right part of Figure 113 depicts a further decomposition of requirements engineering into three steps: Problem investigation, which focuses on the problem, i.e., the organizational change, by identifying and analyzing its cause in terms of the involved stakeholders and their concerns, and by setting goals to deal with the change. Investigate solution alternatives, which refines the goals in order to find possible solutions to realize them. Analyses are performed to reveal conflicts between (refined) goals or contribution relationships between goals in which goals contribute positively or negatively to other goals. Typically, these analyses trigger the identification and elaboration of alternative solutions. 204

111 Solution validation, which validates alternative solutions and chooses the best among them. This choice is amongst others influenced by the conflict and contribution relationships that have been identified. These steps constitute a generic requirements engineering cycle (RE cycle) that can be repeated at successive phases in the development of the enterprise architecture, as indicated by the dashed arrows in Figure 113. Furthermore, the identification, analysis and refinement of solution alternatives in the second step may be repeated as well, which leads to sub-cycles. Enterprise architecture process Architecture As-is Architecture A1 Architecture An Architecture To-be Change 1 Problem investigation 2 Investigate alternative solutions Model M1 3 Solution validation Requirements management process Figure Application of the requirements engineering cycle Figure 113 illustrates the repeated application of the RE cycle in the phases of some architecture development process. The models in the centre of the cycle illustrate the requirements models that are produced during the application of the engineering cycle. It is important to observe that the elicitation of some goal in a certain cycle does not necessarily imply its refinement towards a solution in the same cycle. Depending on the type of goal, a goal may have to wait until a suitable design phase has been reached before it is addressed. For example, goals that are related to technology may have to wait till later phases in which one specifically examines and decides how enterprise applications are implemented using software and hardware. Preliminary H. Architecture Change Management A. Architecture Vision B. Business Architecture G. Implementation Governance Requirements Management C. Information Systems Architectures F. Migration Planning E. Opportunities and Solutions D. Technology Architecture Figure Application of the RE cycle to the TOGAF ADM 205

112 Figure 115 depicts an alternative illustration of the application of the RE cycle, assuming the architecture development process is structured according to the TOGAF ADM. An overview of Requirements Management as proposed by TOGAF ADM is presented in Figure 115. Input 1. Architecture Repository 2. Organizational Model for EA 3. Tailored Architecture Framework, 4. Statement of Architecture Work 5. Architecture Vision 6. Architecture Requirements 7. Requirements Impact Assessment Objectives 1. Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases 2. Manage architecture requirements identified during any execution of the ADM cycle or a phase 3. Ensure that relevant architecture requirements are available for use by each phase as the phase is executed Steps 1. Identify/document requirements (ADM phase) 2. Baseline requirements (RM) 3. Monitor baseline requirements (RM) 4. Identify changed requirements (ADM phase) 5. Identify changed requirements and record priorities (RM) 6. Assess impact of changed requirements on current phase, assess impact of changed requirements on previous phases, determine whether to implement change, or defer to later ADM cycle, issue Requirements Impact Statement, V n+1 (ADM phase) 7. Implement requirements arising from Phase H (ADM phase) 8. Update the requirements repository with information relating to the changes requested, including stakeholder views affected (RM) 9. Implement change in the current phase (ADM phase) 10. Assess and revise gap analysis for past phases (ADM phase) Requirements Management Output 1. Requirements Impact Assessment 2. Architecture Requirements Specification Figure 115 Requirements Management Table 68 indicates which of the outputs prescribed for this phase, can be supported by Archi- Mate viewpoints. Requirements Management Outputs [79] Requirements Impact Assessment Supporting ArchiMate viewpoints Stakeholder viewpoint (assessments) Architecture Requirements Specification Motivation extension viewpoints Table 68 - Modelling support for the outputs of Requirements Management As one can easily see, they are all motivation extension viewpoints. Below we briefly discuss the viewpoint suggested by TOGAF in this phase and other viewpoints that may be useful. The only viewpoint that TOGAF suggests in relation to the Requirements Management process is a Requirements Catalog, which is simply a list of requirements. However, in our experience, diagrammatic views based on formal modelling of goals, principles and requirements are often very helpful: They allow for proper requirements analysis. They help to obtain a clear view of the relationships between the different architecture requirements, and between the requirements and the business goals and architecture principles identified in the Preliminary Phase and Phase A of the ADM. Based on these relationships, traceability of requirements and goals can be achieved. For the creation of requirements models and views, the modelling concepts introduced in Section 3.2 can be used. 206

113 In Phase A of the ADM cycle for their application portfolio rationalization trajectory, ArchiSurance has conducted a stakeholder analysis and identified the main business goals and architecture principles. Figure 116 shows a fragment of the results of this analysis. Figure Stakeholders, business goals, and architecture principles The next step is to identify an initial set of requirements for the Target Architecture that realize these goals and principles. This is shown in Figure 117. Figure Requirements based on business goals and architecture principles Finally, once the Target Architecture has been described, a view can be constructed to show which of the elements in the architecture realize which of the requirements. This is shown in Figure 118. Figure Requirements realization 207

114 5.13 General Architecture Modelling Approach There exists a large diversity of architectures, even within the border of just one organization. Architectures may vary in depth, scope, form or with respect to the described aspects. Research results indicate that organizations experience difficulties in coping with this variety of architectures. The recurring questions are: which architecture models are necessary, how should they be described (in terms of scope, level of detail, description and modelling techniques, etc.) and how they relate to each other. If an organization has formulated its vision on architecture, then this vision contains a description of the goals the organization intends to achieve during the architecture process. However the vision document does not give any answer to the afore-mentioned questions. Therefore, in this section we propose a generally applicable modelling methodology. Architecture models are an important means for the realization of the goals stated in the architecture vision document. Architecture models have a significant contribution in documenting and recording the essence of the area that is subject to change, both in terms of its current state and of possible alternatives for its future state. Since architecture models unambiguously express the essence of architecture, they will speed up analysis and design of the change process. Below a step-wise approach for the realization of architecture models is proposed. This approach conforms to the IEEE standard 1471 that pleads for a viewpoint-oriented architecture design. Goal & Target group. The first step is to clearly state the goal and the target group of the architecture model. Normally, for the target group one or more stakeholders that have been identified in the architecture vision document are the most likely candidates. Besides addressing specific stakeholders, an architecture model also serves one or more interests and/or goals. The main categories of architecture goals are: designing: models may support designers in the design process, from the initial sketches to the detailed design; deciding: models that incorporate decision information assist the managers in the decisionmaking process by delivering insight in different aspects of a certain focus area and by supporting different (automated) analysis techniques (e.g., impact-of-change, costs/benefits, performance etc.); informing: models containing target-group-specific information play an important role in the communication of changes to stakeholders and may convince them of the necessity of change and diminish their resistance. Specifying the type of goal one is pursuing is an important component of the modelling approach. The type of goal is decisive for the following modelling steps. Decide/Inform. For the inform and decide goal-categories one must follow the approach shown in Figure

115 1. Goal Inform and Decide Target group Scope and focus Select Viewpoint GenerateView Controle goal Communicate results 8. Iterate Figure 119 Modelling approach for Inform and decide goals This structured approach takes into account the individual concerns and wishes of the stakeholders and facilitates their involvement in the process. Design. Models that serve a design goal should be built following a slightly different procedure. Essentially, designing is about making choices. A designer reflects and decides upon the desired characteristics of a product before the product will be built. Obviously, the role of designer is being used here in a very generic sense. In the context of EA, it will be the enterprise architect or the domain architect that designs an EA model. The prescriptive steps of the architecture design are shown in Figure Goal Target group Scope and Focus Design Select viewpoint Describe current state Describe target state 7. Check goals 8. Gap analysis 9. Iterate Figure 120 Modelling approach for design goals 209

116 Scope & focus. The next things to be decided, after the goal and target group, are the scope and focus of the architecture model. Here the following rule of thumb holds: Make sure that the model contains only those details that are relevant for its goal and target group. No more and no less! Three dimensions must be considered for the definition of the focus and scope: the model domain, the level of detail and the time horizon. In order to specify the focus and limit the scope, one must answer the following questions: 1. Domain: What domain(s) is (are) (partly) modelled? The designer can choose from the following domains: environment, products & services, function, process, information, organization, application, data and technology infrastructure. What are the resources (people and means) that fall under the selected domain(s)? 2. Level of detail: What is the level of detail targeted by the model? The designer can choose from: a. detail: at this level of detail the model describes extensively the domain area that is subject to change up to the smallest components. Often these models are limited to only one domain, or at most a layer of the architecture. b. coherence: models at the coherence level of detail generally describes the relationship/ dependencies between layers or between the domains of one layer, but not both of them. c. overview: this is the highest level of detail. Models at this level of detail describe globally the relationships/dependencies between layers and domains. 1. Time horizon: What is the time-stamp of the architecture model? Theoretically speaking, a model of the architecture can be built at any moment in time. In practice however, architects use three timeframes: a. current state: this is a model of reflecting the present state of affairs with respect to the selected domain(s); b. short-term state: this is description of one or more alternative architectures of the selected domain(s) for the near future (usually one or two years); c. long-term state: this is description of one or more alternative architectures of the selected domain(s) for the distant future (usually one three or more years). The above-mentioned three dimensions must be documented in the architecture model. Choose viewpoint. For each goal, target group and level of detail the designer must select a viewpoint. A set of generic reference viewpoints is presented in Table 69 (also see Section 4.1). 210

117 goal\ level design organization business function business process information structure application structure application behaviour technology infrastructure stakeholder goal refinement goal contribution principles requirements realization motivation decide actor cooperation view stakeholder goal refinement goal contribution principles requirements realization motivation detail coherence overview inform organization business function business process information structure application structure application behaviour technology infrastructure stakeholder goal refinement goal contribution principles requirements realization motivation actor cooperation business process cooperation application cooperation product stakeholder goal refinement principles requirements realization motivation landscape maps layered view service realization view organization structure view business process cooperation view business products view stakeholder goal refinement principles requirements realization motivation actor cooperation business process cooperation application cooperation product stakeholder goal refinement principles requirements realization motivation Table 69 Viewpoints classified by goal and level of detail service realization implementation and deployment application usage layered view motivation migration landscape maps layered view motivation programs and projects migration Implementation and Migration service realization implementation and deployment application usage layered view motivation programs and projects migration Implementation and Migration 211

118 Model current state. The next step is the description of the current state. This step is only necessary if the organization does not posses an architecture description yet. A good overview of the current state of affairs is necessary in order to compare it with the target architecture. Knowing the differences between the current and the future architectures is important in order to plan the resources necessary for the implementation of the design. However, it should be noted that much information concerning the current architecture may be already available in existing enterprise information sources. These sources should be used to import as much information as possible into the model of the current state. The model of the current state and the amount of imported information must be limited though to just enough in order to understand the gaps between the current and the future target states and to recognize and address any contradictions. According to [38], many organizations spend too much time in documenting in great detail the current-state architecture, which delivers little value. Therefore, it is essential to find an optimal level of accuracy and detail when modelling the current state. Furthermore, the current and the target state of a selected architecture area should generally contain a comparable amount of detail. Model target state. The design of one or more alternatives for the desired future-state of the targeted domain(s), is the next step to be overtaken. The designer may adopt different design strategies in which one domain or aspect is considered the reference and all the others are subordinated. Examples of reference aspects/domains are: products and business services, processes, functions, resources (people and assets), data infrastructure, technology infrastructure. Check goals. During and after each modelling activity the designer must validate the proposed goals and principles. This should be done together with the relevant stakeholders, such that their opinion is immediately taken into account in the decision-making/design process. Perform a gap analysis. As soon as the current and desired situation for a viewpoint is modelled, the architect can carry out a first gap analysis. As indicated in Section 5.8 an EA-wide gap analysis is performed as part of the ADM cycle. At this point it might be however interesting, to execute this small scale analysis, which can reveal issues that lead to changes in the priority of certain goals. If this is the case, priorities must be changed in the architecture vision document and the modifications must be communicated to and discussed in the architecture team. Communicate & iterate. Communicate the results to the concerned stakeholder. Incorporate the feedback from stakeholder in your design or reject the proposed changes based on arguments. If it turns out during these feedback sessions that significant changes are necessary, reiterate these phase. ArchiSurance has designed a number of models for each layer. These represent both the current and the desired situation and can be found in the Chapters 3 and 4 of this book. 212

119 8. The Way of Supporting EA with tools Being able to rapidly react and adapt to changing client requirements and business goals is for many organizations of vital importance. The modifications in product, process, organization, application and infrastructure following from an adequate response of the organization to the changing environment are significant and must be correctly evaluated in advance. This is where enterprisewide architecture and architecture tools play an essential role. Enterprise architecture tools can not only help organization visualize the structure, organization and behaviour of all architectural domains and layers but can also make possible the analysis and representation of the relationships between these. In particular it becomes possible to visualize how a certain change will propagate in the architecture and to calculate the extent to which the performance of a certain architectural element will influence the overall performance of the business. Despite the above-mentioned benefits, it is not easy to build support for, select, and implement a shared EA toolset. For most organizations, it involves selecting and customizing an EA methodology. TOGAF explicitly recommends to customize the method to the specific requirements of the organization in the Preliminary phase of the ADM. The EA methodology, in order to be successful, must ultimately be embraced by the parts of the IT and business community that interact with EA. All stakeholders are more likely to benefit from the methodology if they feel a sense of ownership for it. The same principle applies to the selection of a modelling language and a toolset. Most organizations need to integrate multiple methodologies, diagramming techniques and /or toolsets to meet their needs. If these processes are planned and executed by a small number of people, adoption will likely be poor. Even after these decisions are made, it takes significant time and effort to design and configure the toolset, build diagram templates, design multiple environments and the processes to support them, convert and load existing data, train users, etc. Even after the new toolset is up and running, support personnel are needed to ensure the consistency, quality and completeness of data, keep the software up-to-date, and resolve problems. Hence the costs and risks of selecting and implementing EA toolsets are high, and organizations should determine when the timing is right to acquire and implement these tools. Therefore, in this chapter we discuss the role these tools may play in supporting the architecture program, more importantly, the requirements such architecture tools must meet. First, the most significant bottlenecks with respect to tool usage in the current architecture practice are discussed (Section 8.1), and then the benefits that may be derived from the proper use of architecture tools (Section 8.2) are shown. Section 8.3 gives an overview of the requirements for architecture tool support. The following categories of requirements are distinguished: requirements related to modelling and design (Section 8.3.1); requirements related to visualization and publication of models (Section 8.3.2); requirements related to analysis of architectures (Section 8.3.3); requirements related to the storage and administration of architectures (Section 8.3.4). Also some guidelines for the tool selection process and for the manner in which an organization should prioritise its selection criteria are presented (Section 8.3.5). The chapter ends with a classification of the existing architecture tools (Section 8.3.6). 251

120 8.1 Problems regarding and the usage of tools for EA In many organizations architectures can be recognized as huge wall posters, full of blocks, boxes and lines. Besides, architectures are documented occasionally in large Word documents or colourful PowerPoint presentations. An examination of existing architectures and the current tool usage reveals a number of problems that are explained in the following sections. We hope that we have given in the previous chapters sufficient convincing arguments for the benefits of architecture to make the efforts to solve these problems worthwhile. Isolated architecture for each domain. Many existing architectures are limited to the description, through models and principles, of isolated architecture domains. More precisely, such architectures consist of isolated fragmented components, such as a process architecture, an application architecture, and an infrastructure architecture. The explanation for this situation is that on one hand it is very difficult to precisely describe relationships and dependencies between large architecture domains while only using Word or Power- Point, and on the other hand each of these architecture fragments are designed by different teams of architects. Often the responsibility for each domain is clearly assigned to a certain person, while no one is appointed to take care of what happens between domains. Limited insight in architecture coherence. The most important consequence of the fact that architectures are developed in isolation is that there is barely any insight in the relationships that are established between these isolated architecture fragments. Often this kind of insight is to be found only in the heads of a handful of experienced architects, but it is hardly ever described in documents or models. This means that this type of knowledge is extremely vulnerable and, most importantly, it is very costly to transfer it to other people or to recover it in case it is lost. Besides, it is very difficult to assess the impact a certain change would have in the different layers of the organization. Therefore, in the event that an assessment would be necessary the answer is either incomplete (leading to increased risks of mismanagement as result of incomplete information) or it requires a lot of time/ effort. Modelling architectures. Many architects do not make use of dedicated enterprise architecture tools [71]. They model, design, visualize and analyse using office applications such as Word, PowerPoint and Excel. In order to document the relationships between architecture domains (e.g., specifying which processes are supported by which applications) often matrices/tables made in Excel or Word are used. If someone would want to search information that lies between domains, then this person would have to combine different tables in order to build the complete picture. Obviously, such tools are very appropriate for reporting and presentation purposes, and can be occasionally used during the design of architecture fragments. However in order to maintain the coherence and consistence between the models of fairly large enterprise architectures more specialized tool environment is necessary. Furthermore, thick reports are not very famous for their readability and accessibility, especially for untrained people. Insight via schemes and diagrams. One of the most important goals of architecture is to provide insight and overview. It is therefore not a coincidence that most of the time architectures are visualized by means of schemas and diagrams and in not in long textual descriptions that score low in terms of overview and insight. 252

121 The construction of such schemas using the available office application is not only difficult but also time consuming, especially when large diagrams are involved: the architect will have to go through the trouble of creating the graphical representations (e.g., appropriate shapes, boxes arrows, etc.), selecting the relevant architecture components and expressing them in terms of the created graphical constructs, and arranging their layout manually. Limited number of views for stakeholders. Since designing architecture diagrams is not a trivial task, most organizations choose to only produce one or two views on a particular piece of architecture. This means that the different architecture stakeholders (such as project leaders, managers, system and process owners) most often do not receive the view which would be the most adequate for their concerns. For instance, a system owner would be interested in which way his system relies on other applications, which processes uses his system and what infrastructure components are essential for the well-functioning of his system. Most likely such information is not covered completely by any of the available views and must be indirectly derived from several other documents, diagrams etc. The consequence is that information remains hidden and stakeholders fail to become aware of it. Eventually this results in insufficient architecture awareness and usage within the organization. Architecture standardization and simplification. In many organizations employ specialized architects for each architecture domain. Within each domain specific architecture concepts, semantics, notation, and styles for modelling, visualization and documentation are used. Often domains are modelled in isolation, and there is no coordination between architects. The result is that architectures are insufficiently standardised. It is not uncommon to see in that what some people call information system, is regarded as application service by others, which not only creates a lot of confusion but also a lot of ambiguity with respect to the content of the architecture. Architecture consistency. A considerable disadvantage of the fact that organizations develop isolated domain architectures (Sections 0 and 0) is that the overall consistency of the total architecture is very hard to maintain or even doesn t exist. The same effect has the lack of standardization (Section 0). It is the responsibility of the domain architect to make sure his domain remains consistent both internally and with other domains. This is realized mostly manually, since tools such as PowerPoint, Word, Excel, Visio etc. are not equipped with mechanisms to check and enforce consistency. It also requires a lot of intensive contacts and agreements with other architects for the communication of any single change that is made both within and outside the respective domain. Architecture maintenance. Although architectures are relatively stable structures (they do not change on a daily basis), their maintenance is certainly relevant. It is a matter of common knowledge that the development of architectures is an expensive undertaking and it would be a waste of effort and money not to keep it up-to-date. It should be however noted that architecture maintenance is as work-intensive as designing and developing it. Carrying out consistently changes in all architecture documents and visualizations might become quite a challenge, especially when this are created by means of office applications. This is most probably the main source of inconsistencies and obsolete information within architecture descriptions. Architecture analysis. For many organizations the consistent and coherent development and visualization of architecture is already a challenge. Carrying out analyses, which assume the exis- 253

122 tence of such architecture, is even more difficult to achieve. Especially, if the architecture consists of fragments and isolated domains it is either impossible to apply analysis techniques or the results are completely unreliable. The best example in this sense is the impact-of-change analysis which may, in the best case, indicate the effects of a certain change within the boundaries of the fragment under analysis and not in the rest of the architecture, while some changes may have serious implications from the business layer, all the way to the infrastructure. Incomplete analysis results may lead to wrong decisions and force organizations to rely on the knowledge and experience of (error-prone) architects to complement the missing information. 8.2 The advantages of using architecture support tools In the previous sections the problems one may encounter when dealing with architecture toolsupport in organizations have been addressed. Obviously, not all organizations have the same problems to the same extent, but they all experience some difficulties if the available tool support is limited. In this paragraph the advantages of making proper use of dedicated tools are explained. We do not yet present our view on what a good tool support is (more information on the requirements that should be met in order to adequately support architecture design and maintenance one can find in Section 8.3), but we sketch few of its benefits. In the remainder of this section the focus is mostly on the immediate benefits with respect to the current situation and less on the long term opportunities that with further tool development may become reality. Insight and overview. An important added-value of an enterprise architecture tool is that one can easily gain insight and have a clear overview of both the various architecture domains and the architecture as a whole. In an EA tool models are not stored as separated independent models. Instead, architecture is regarded (i.e., designed, maintained and stored) as a whole, and models and domains are inter-related. It becomes therefore possible to create cross-domain overviews of the architecture. An example of such an overview can be found in Table 49. Visualizations. Visualizations of architectures are very important especially in order to inform the different stakeholders about the content of architecture or about important changes and design decisions. Some EA tools offer functionality for the (partially) automatic generation of views and visualizations that can be tailored for a particular stakeholder, both in terms of contents (the architecture contents and relationship types that are presented) and in terms of form (the graphical appearance of the selected contents). The figure below gives an example of two different visualizations of the same architecture fragment. Figure 132 Multiple visualizations of architecture models 254

123 For the architect the use of an EA tool means that he can easily and rapidly generate different visualizations based on a common architecture model. Think for instance to a system owner that want to see in one diagram the relationship between his/her system and other systems, while a system administrator wants to see in a table which applications run on which servers. An EA tool may make the generation of such on-demand visualizations effortless. Communication. It is obvious that the use of an EA tool contributes to the improvement of the communication. While so far architecture is hidden in thick reports and posters having the size of whole wall, with an EA tool one can effortlessly generate the most appropriate views for a customised active communication of architecture to each stakeholder. Thus it becomes possible to administer the architecture in small appealing, comprehensible and digestible pieces. The consequence is that slowly the architecture takes its place in the organization and comes to life as part of the organizational culture. As soon as the architecture will gain some popularity people will realize its benefits and will feel encouraged to use it effectively. Models and principles. A good EA tool offers support not only for modelling but also for the description of architecture principles. Think for instance of modelling goals, guidelines and principles. An EA tool allows these principles to be related to the architecture model to which they apply. Trough the coupling of principles to models it also becomes possible to see to what extent the created models conform to the related principles or whether a model will be affected by the change of a certain principle. In the example below the relationship between principles and model elements is established by means of colours. Figure 133 Linking principles to models Clarity. The use of EA tool allows the unambiguous specification of architecture and increases the clarity of the models. While without an EA tool one has to deal with different notations and concepts for different domains, with an EA tool this problem doesn t exists. An EA tool enforces the use of a uniform standardised set of concepts and notations. Furthermore, because all architects use the same tool they are forced to agree on the way they will specify relationships between domains and on the way they will visualize them. This has at least one important advantage: that architecture is regarded as a consistent whole, which makes communication and use of architecture easier. Consistency, reuse, and traceability. The use of EA tool increases the consistency of the architecture. Because an EA tool makes possible the integration of isolated architecture fragments, any inconsistencies can be detected faster and easier. The very use of an EA tool makes the sources of possible inconsistencies disappear. It is also possible that the EA tool is also equipped with consistency and model checking mechanisms that will proactively detect such mistakes. Another advantage is that an EA tool makes possible the reuse of architecture elements. If a domain architect wants to create a visualization of an architecture fragment, then it is often necessary that the architect also specifies the relationships with other architecture fragments or domains. If one makes use of an EA tool, this must only happen once, and these relationships will be stored 255

124 and made available for any future use. Furthermore, the right EA toolset can enable application and infrastructure designers to elaborate directly on EA documents, and allow various stakeholders to easily trace the extent to which designs reflect architectural guidance. Analysis of architectures. The use of an EA tool facilitates the execution of analysis of architecture models. Examples of such techniques are the derivation of indirect relationships and of dependencies throughout the architecture, impact-of-change analyses, performance analyses (e.g., response time, utilization of resources, estimates of necessary resource capacity, etc.) and comparison of architectures. Many of the existing tools support these types of analysis only to some limited extent also because there is little demand for this type of functionality. That can be explained by the fact that most organizations have not reach yet the necessary level of architecture maturity when these analyses can become useful. Administration. The use of an EA tool simplifies the administration of the architecture. The architecture elements (processes, applications, data, infrastructure, etc.) are described/stored only once (as opposed to being specified in multiple PowerPoint presentations, Word-documents and Excel tables). The different visualizations of the architecture can be generated from the central architecture model. In this case a change, for example, of the name of an application component will be automatically carried out in all the generated views in which the respective application was referred. Also the management of the different versions of the enterprise architecture can be supported and automated by an EA tool. Speed. In contrast to the use of office applications, the use of EA tool facilitates the rapid development of architecture. It is possible to automatically generate views and to make automatically changes all the existing views simultaneously and consistently etc. This means that an architect will spend significantly less time with the maintenance and visualization of architecture models, because these activities are for the most part automated by the use of the EA tool. Moreover, the architect will mostly focus on the actual design and the communication of these designs to stakeholders. 8.3 Requirements for architecture support tools In this section requirements are identified, which an enterprise architecture tool must fulfil in order to deliver the added value mentioned in the section 8.2. The focus is on requirements that are specific for enterprise architecture specification and not on general tool requirements. We then discuss shortly the categories of tools that are currently available on the market and how should organizations proceed in the selection of such a tool [72]. We concentrate more on end-user aspects and less on the internal architecture or on a vision for the future of such tools. For this type of discussion we refer to [18, 46]. We distinguish the following categories of functionality for EA tool support [46]: Modelling and design of architectures; Analysis of architectures; Visualization and publication of architectures; Storage and management of architectures. The main important requirements are also summarized in Table 80. In the remainder of this section each of these aspects is further analysed. 256

125 Category Modelling and design Analysis Visualization and publication Storage and management Requirements Supporting architecture domains, Supporting architecture frameworks, Supporting for modelling Impact of change analysis, Deriving indirect relationships, Comparison of architectures, Quantitative analysis Design and generation of views and viewpoints, Reporting and publishing Migration to repository support, Interface, User management Artefact reuse, Content organization, Artefact sharing, Version management, Labelling, Locking, Easy Output, Tool integration, Artefact transformation, Standards conformance, Support for architecture frameworks, Tool life cycle constraints, etc. Table 80. Summary of EA tool requirements Modelling and designing In order to create architecture models an EA tool must be capable to accommodate various architecture concepts, domains and frameworks. Furthermore it must provide support for the creation and modification of models. Supporting architecture domains Which architecture domains, concepts and frameworks an EA tool must support also depends on the approach that has been taken by the organization. In this book, the TOGAF/ArchiMate approach [46] has been chosen. The concepts and domains recommended by ArchiMate and TOGAF generally give a sufficiently broad and uniform coverage of all enterprise architectures. In the most cases is relatively easy to map concepts and domains operated by organizations onto ArchiMate concepts and domains. A description of these concepts can be found in Chapter 3. Supporting architecture frameworks In order to offer an organization the necessary support for the chosen architecture framework, an EA tool should be equipped with functionality that allow not only the architecture concepts, but also the division of the architecture in viewpoints recommended by such frameworks and the modelling of the framework itself. In this book we plead for the adoption of TOGAF and ArchiMate as comprehensive architecture approach. Nevertheless, many organization with a complex business or a complex legacy portfolio, may have to integrate and customize a variety of frameworks, besides those mentioned before. Thus, an EA tool must be flexible enough to support any of the currently recommended frameworks (e.g. Zachman, TOGAF, DYA, 4+1 etc.) and any organizationspecific and custom-made framework. The figure below gives two examples of such frameworks in which the different views on the architecture are combined in an architecture framework overview. 257

126 Figure 134 Example of EA framework Support for modelling Most important, an EA tool must provide excellent support for architecture modelling. Modelling contains the following aspects: simple model editing functionality, user-friendly interface, a good graphical interface (with a familiar and intuitive look-and-feel), easy manipulation of models, etc. Such requirements do not only apply to architecture tools, but to most modelling environments. For an overview of such aspects see [72]. Very important is the possibility to assign certain properties to the model elements (both concepts and relationships). Examples of such properties are: the insertion of a time dimension (e.g., the plateau during which this relationship is valid), the specification of an owner or of a functional quality of an application, etc. (see [72] for more examples of such properties). It must be possible to define, visualize and publish such properties, as depicted in the Figure

127 Certainly relevant is also the possibility to read (i.e., import) architecture descriptions from other tools. Often, organizations may already have many architecture descriptions produces with domain specific tools (such as, process models, application management tools, overview tables in Excel, etc.), when they decide to use a dedicated EA tool. Therefore, the implementation of an EA tool and the migration of models to the new EA tool are considerably simplified if the EA tool is capable or importing/translating such domain specific models. Figure Properties Visualization and publication of architectures A second essential functional requirement for an EA tool is possibility to visualize and publish (parts of) the architecture. Views and viewpoints An EA tool must provide stakeholders with appropriate support for the work with views and viewpoints. This covers the following two aspects: Generating views based on a model. Different stakeholders that may have not been involved in the design process must be given the possibility to extract from the architecture the information they need in the form they need. Thus, an EA tool must facilitate the generation of views of a selected type based on an existing architecture model. The following aspects should be considered in the view generation: Other selections from the architecture model (e.g., only processes and applications or applications and application services, etc.). Other visualizations / representations of the architecture model (actors as blocks, actors as stick-figure, etc.). Filtered selections from the architecture model (e.g., inclusion/exclusion of certain relationship types to be shown in a view). Different ways of representing relationships (e.g., as arrows, by means of colour of an object, by means of nesting, etc.). 259

128 In the figure below a few examples are given. Figure 136 Generating views based on a model Generating views based on viewpoints. An EA tool must make possible the definition of new (stakeholder-specific) viewpoints and the adaptation of the prescribed ones. Furthermore, the tool must allow the creation and modification of views based on these viewpoints. The following aspects should be considered in the definition of viewpoints: Inclusion of exclusion of certain concepts and relationships in a viewpoint (e.g., a layered viewpoint without services); The selection of the form/notation for the presentation of concepts and relationships (e.g., colour, shape, font, size, etc.); The presentation of concepts, relationships, properties and profiles in the form of tables, colours, labels and landscape maps. In Figure 137 an example of a landscape map can be found. Figure 137 Example of landscape map In Chapter 4 and in [18] a detailed collection of example viewpoints is presented. 260

129 Publishing Besides creating views on architecture it is obviously necessary to offer people in the organization the means to publish them. It should be at least possible to do this in Word and HTML (for an intranet), or to have a publication portal around the repository. Also it should be possible to export/ copy models and views to PowerPoint-presentations Analysis of architectures It is not sufficient for an EA tool to only support modelling and visualization. Analyses of architectures are also important as a means to control and steer both architecture and organization [31]. Impact of change analysis One of the basic forms of architecture analysis is the impact-of-change analysis, which makes possible the identification and visualization of all architecture elements that will be affected by a certain change. This is also a manner of emphasizing the dependencies that exist between domains. Such analyses are not only relevant for the architect but also for other stakeholders. Examples of questions that can be answered by means of impact-of-change analysis are: What are the consequences of the failure of a certain infrastructure component on the running applications? Which applications make use of this service? Which processes make (indirect) use of this fileserver? Which applications and infrastructure might be overloaded if there is a significant increase in the deliveries for this product? It is important that the EA tool supports the presentation of the analysis results both graphically in the architecture model and in overview tables. After all these results constitutes yet another view on the architecture! Deriving indirect relationships Relationships between various concepts both within and between domains and layers are part of the architecture. These relationships are direct relationships in the sense that they are explicitly added by the architect to a certain model and, as such, part of the architecture. One type of analysis that must be supported by an EA tool is the derivation and visualization of indirect relationships. As we have explained in Section 3.1.5, the derivation mechanism may be based on a composition operator. To make this mechanism more intuitive we give an example: let us assume that a process uses an application service, which is realized by a component that on its turn used an infrastructure service. One indirect relationship that can be derived from this model is that the process makes use of the infrastructure service (as shown Figure 138). 261

130 Figure 138 Derivation of indirect relationships In [10] the mathematical grounds for the derivation mechanism are laid and the applied for the case of ArchiMate indirect relationships derivation. Comparing architectures Often people design more than just one architecture, with the intention of comparing them and select the one which best meets certain requirements. Another, situation when the comparison of architectures may prove valuable is when snapshots of the same architecture are taken at different moments in time (Figure 139). It is therefore important to have functionality that emphasize and report differences between architectures. Figure 139 Comparison of architectures 262

131 Quantitative analysis Quantitative analysis of architectures examines the performance of the total business system as documented in the architecture. Different stakeholders may have interests in the result of such an analysis as explained in [30]: A user is interested in the response time of a process or system. A process owner or process manager is concerned with the completion time of a process. A product manager is interested in the amount of time that is necessary for the manufacturing of a certain product. A system owner or system administrator would like to know the utilization of a system. Such analyses are only possible if formally sound modelling language have been used to document the architecture [30] and the data in the repository is kept accurate and up-to-date. This is always a critical issue for quantitative analysis Storage and management of architectures Maintenance and storage of architecture models is obviously of great importance for the organization. Especially large enterprises architectures can accumulate enormous amounts of data. A broad range of deliverables such as, models, data and documents that document business processes and information technology resources, often created using different tools, can be part of the EA. As the volume of this information grows, keeping track of it and maintaining it becomes increasingly difficult. Enterprise architecture repositories lie in the core of the problem. Repositories provide a foundation for managing and maximizing the use of the data collected during architectural exercises. A repository of architecture artefacts is also necessary in order to make enterprise architectures effective, push it into use and to get value out of them. For instance repositories facilitate enterprise architecture analysis. To this end, modelling tools and repositories have components that create visual representations of models, perform model/data query and analysis and can generate reports. Several metadata repositories exist, but enterprises should not expect to find a solution that works out of the box. There is a certain amount of tailoring that needs to be done in order to meet the specific needs of an enterprise and to achieve the integration of such a repository in its overall EA. Integration is an important challenge for enterprises that want to create an architecture repository. For this purpose the repository must communicate with the other enterprise architecture tools (e.g., it has interfaces to other modelling tools and the import / export of models between the repository and various tools is possible) and associated applications. It is interesting to notice the trend of some architecture tool vendors (e.g., Troux, Telelogic, BiZZdesign) of complementing their original modelling tools with integrated repository support. This indicates the rise of a new generation of repository based EA Tools. An immediate effect is the reduction in modelling tool proliferation: a single tool can be used to carry out process, data, application, and technology modelling, analysis and storage of models. Furthermore repositories contribute to the increased EA awareness across the organization architecture and other domain specific models (e.g. business process models, infrastructure or software models etc.), HTML, Excel Spreadsheets, and Word documents (i.e., EA work products) are produced and shared among a large audience. 263

132 Thus, a repository makes possible that architecture artefacts are available for concurrent usage and modification (multi-usage), while supporting version management. When selecting a repository, the following aspects should be taken into account: Migration to repository support EA tool/repository support should not be a burden to the organization, nor to its system administrators: it should be easy to install and it should support migration of existing artefacts. Interface EA tools should be endowed with a user-friendly Model Development Interface. Modelling support EA tools should provide modelling support for different stakeholders (e.g., business architects, application architects, security architects, infrastructure architects, enterprise architects, etc.), and, ideally, also for different modelling languages and notations (primarily standard notations, such as, ArchiMate, UML diagrams [61], IDEF diagrams, BPMN, proprietary notations and the possibility of defining customised notations). User management EA tool/repository support should be equipped with role-based access control, with the flexibility to craft roles based on the environments and quality assurance processes that each organization needs. In addition, integration with Windows authentication, or whatever users log in with every day, will help drive adoption. Artefact reuse To allow users and tools to refer to/reuse existing artefacts from/in other artefacts, some form of referential integrity is required. Furthermore, artefacts should be treated as independent entities with individual life cycles, this meaning that each artefact is identifiable, retrievable and updatable independently. Content organization It should be possible to organise content in the repository according to the following principles: nesting, hierarchies, networks, user-defined relationships. Rich data types - Repository support should include the possibility to store (or at least refer to) foreign artefacts such as documents, multimedia content, dates, pictures, templates, hypertext, hyperlinks etc. Artefact sharing To allow users and tools, possibly from different departments, to edit different parts of a single artefact simultaneously, artefacts need to be accessible, even updatable, concurrently in a distributed environment. This means that the EA tool and repository support must be accommodated with some concurrency mechanism that supports concurrent access to artefacts, providing an explicit (pessimistic) locking mechanism. Also it should support distributed access and should provide the user with edit functionality from remote locations. Working offline, for instance by means of check-in/check-out functionality should be possible. If an object is removed from the repository than the same happens with all the references to that object. Therefore the repository must be aware of the relationships between objects. Version management - All objects in the repository must have their own version and their own version history, such that models can refer to older versions of a certain object. Labelling - It must be possible to assign labels to objects in the repository (e.g., component current situation, valid until , etc.), such that the tool can produce a snapshot of the architecture based on these labels (e.g., using queries such as all objects that belong to the current situation ). Locking - The repository must be endowed with a robust locking mechanism (algorithms), such that consistency of data is guaranteed and such that at a certain moment in time just one user can modify an object. Easy Output - EA tools must be endowed with the following easy output functionality: Report Generation, Multiple views on models, Composite Documents, Portal Support, Publishing - web site generation, etc. 264

133 Analysis Support for analyses (performance, impact, consistency checks, model comparison etc.) and simulation is desirable. Tool integration To make artefacts originating from EA tools easily accessible to other tools and conversely, EA tools/repository should support import from and export to other file formats than the native ones. Artefact transformation When different tools exchange artefacts, these may need to be translated into concepts specific to the receiving tool (language/notation). Therefore metamodelling functionality that facilitates the definition of such model transformations is desirable. Artefact parameterization Parameterized artefacts extend the support for artefact reuse by leaving some parts (parameters) open. Upon reuse, the parameters need to be filled in. Scalability EA tool support and repository must scale well: increases in stored data or number of users should not lead to degradation in performance. Frequently used operations must perform within (tenths of) seconds. Security - The repository should utilize a variety of security measures ensuring that databases remain secure. Standards conformance - In order to make possible the import and (export) of information (e.g., models) from (to) other tools, the compliance with important standards (e.g., MOF, UML, XML, SOAP, WSDL, UDDI, JMI, etc.) should be taken into account when assessing the suitability of EA tool/repository support. Support for architecture frameworks EA tools should also provide support/guidelines for usage in combination with (well-known and/or proprietary) architecture frameworks and methodologies Tool life cycle constraints - support, upgrades, extendibility and customization, user interfaces/ programmability, help desk, customer base and popularity of the acquired system, etc. Some additional requirements for repository support can be found in [72] Selection of tools In order to come to a decision with respect to the selection of a particular EA tool, most organizations undergo a selection process. There is a lot of literature available on software package selection. Therefore, here we only briefly outline the selection process and emphasize the specific aspects concerning EA tools. During such a process several available tools will be screened based on a list of requirements and wishes of the organization. It is therefore sensible to start the whole process by considering a large number of potential suppliers (the long list ) and approach them with a standard list of questions reflecting the most important requirements. Based on the received reactions, one should make a first selection and come up with a short list of maximum five tool suppliers that will be asked to give demonstrations of their tools. Consequently, one tool will be selected for experimentation within a small pilot project. Depending on the results of the pilot either the final decision will be taken or a second pilot must be carried out with another tool. During the last phase the contractual negotiations with the supplier can also be initiated. In the figure below the whole process is summarized [36]. Similar approaches are proposed in [25] and [72]. 265

134 1 Preparation 2 Specification of the list of requirements 3 Exploration of the tool market 4 Shortlist 5 Demonstrations, References, establishing consolidation preferences 7 Workshop/ pilot-project 6 Contract negotiations Figure 140 The selection process [36] 8 Decision making Step 1 Preparation. The selection process starts with an analysis of the current situation that will identify: The groups that are involved in the architecture process; The architecture areas these groups are targeting; The extent to which conventions and standards for the specification of these areas are available; The means/tools they currently use; The requirements concerning possible migration of data and models. Eventually, this analysis must result in a clear picture of the EA tool stakeholders. More concretely: It will lead to an identification of the departments that have requirements for an EA tool and the representatives (e.g., users, managers/decision makers, administrators) these departments will delegate to represent their interests in the selection process. It will specify the parties that will be involved only during the selection process, such as: legal consultants, procurement personnel, etc. It will specify the scope of the selection process. In this phase of the selection process can also be decided if contacts with similar organizations (possibly from the same branch) that have completed or are currently carrying out such a tool selection process are necessary. Step 2: Specification of the list of requirements. In this step all the involved parties will produce a document containing all the requirements for architecture tool support. They will be clustered according to some clear criteria. For example, one may think of the following categories of requirements: Functionality of the EA tool (e.g., notations supported, export functionality, etc.); Administration aspects; Technical aspects; Contractual aspects (i.e., licences, support, new releases, etc.); Security aspects; Performance aspects. 266

135 Once completed, the list of requirements must undergo a prioritization operation. Thus requirements that are essential (the knock-out criteria) will be assigned priority 1. These are the minimal criteria a software supplier must fulfil in order to come on the short list of possible candidates. It should be avoided that too many criteria are regarded as knock-out (KO) criteria, because this could lead to the exclusion of too many suppliers (or even of all of them). A comprehensive list of tool selection criteria can be found in [72], which can serve as basis for any selection process. Step 3: Exploration of the tool market. Based on market research, a first list of possible suppliers must be created. This is the long list. All suppliers on this list will be asked to answer a standard questionnaire concerning the product they offer. This questionnaire is also known as the Request for Information (RFI). Step 4: Testing tools/ Evaluate RFIs / Shortlist consolidation. In this phase the information received in the previous phase is evaluated. In order to proceed as efficiently as possible, a first sorting of the suppliers on the long list will be made based on the KO criteria of step 2. Then a thorough evaluation of the remaining candidates must be carried out such that a short list of three to four names will be produced. Step 5: Demonstrations, references and establishing preferences. With the suppliers on the short list appointments should be made for demonstration and presentation of their products, such that a better understanding of the tool features and capabilities can be achieved rapidly. In order to effectively benefit from the contact with the suppliers it is recommendable to steer the presentations towards the demonstration of the tool in situations that mimic the daily practice of the organization. This also will ensure certain homogeneity of all presentations making the task of comparing much easier. During the demo-sessions the participants in the audience must fill in an evaluation form, for which they have been instructed in advance. The forms must be filled in either during or right after the demonstration, but, in any case, before the next demonstration. The questions from RFI may constitute the basis for this form. After the demonstrations and possible reference-visits it should become possible to come to a conclusion regarding the preference for a certain supplier and the ranking of the suppliers on the short list. Step 6: Contract negotiations. In this step the procurement and legal departments will come into play. They will check if the selected offer indeed fulfils essential criteria, such as: the extent to which the product meets the wishes and demands of the organization; the financial aspects such as the size of the investment, the yearly maintenance costs, estimation of the amount of necessary customization work, education costs, etc.; information regarding the supplier (previous experiences, continuity expectation, etc.); the contractual clauses. Step 7: Workshop/pilot-project. After the selection, the tool this must undergo a testing in a practical setting. It is sensible to select an organization-specific architecture case that requires the usage of all the required essential functionality. The preparation of the case can begin quite early, long before the final tool selection has been made. This practical test must not be very large. 267

136 Organise an interactive workshop that will take one or two days. However make sure that the testers (normally employees selected from the actual end users group) get the opportunities to play around with the tool. It is also possible to prepare a heavier evaluation procedure, in the form of a real-life practical situation. Such a pilot project may have as additional goals the configuration of the tool, getting a grip on the tool usage etc. Step 8: Decision making. At the end of the selection process a final report must be delivered, possibly accompanied by an implementation plan. The management team in charge will then take the formal decision for the acquisition and introduction of the selected tool Classification of existing tools There are several enterprise architecture tools available on the software market. Many of them were originally dedicated to specific sub-domain (i.e., process design, system design etc.) but recently they have extended their scope to whole architectures. Nevertheless, there are a few tools that have been from the very beginning designed for EA. The following categories of EA-support tools can be distinguished [46]: Enterprise architecture modelling tools: These tools provide support for modelling and visualization of several architecture domains, mostly on a higher abstraction level; Software development tools: these tools were originally intended for the specification of software and have enlarged their scope with support for new concepts and diagramming functionality; Business process design tools: these tools were originally meant for the modelling of processes and have been enhanced with IT-related concepts and diagrams; Business process management tools: these tools were dedicated to the operational management of business processes (e.g., the monitoring of the performance of operational processes); IT-management tools: these tools were devoted to the management of IT (also called IT portfolio management tools); Repositories: these tools were originally intended for the storage and retrieval of objects. Through their enhancement with modelling and analysis functionality these tools have become fit for use as EA support tools. The relationships between these categories can be graphically depicted as in Figure 141. EA modelling IT Management Software Design and Development Business Process Management Business Process Design Repositories Figure EA tool support classification [46] 268

137 Below a number of tools are positioned according to the above-mentioned categorization (note that institutions such as Gartner and the Meta Group publish regularly overviews, characterizations and classifications of the existing tools): Enterprise architecture modelling tools: BiZZdesign Architect; Metis; IBM Rational System Architect; Casewise Modeler; ARIS. Software development tools: Rational Rose; Enterprise Architect (Sparx systems). Business process design tools: BiZZdesigner; Casewise Modeler; ARIS; MEGA; Proforma ProVision. Business Process Mangement tools: Oracle BPA suite; Cordys; Mendix; BizAgi; Intalio BPM; Bonitasoft; Lombardi. IT-management tools: BiZZdesign Architect Metis (Troux Technologies); PlanningIT. Repositories: BiZZdesign Enterprise Modeling Server Rochade; Adaptive. 269

138 This book is an essential addition to the bookshelf of all enterprise architecture practitioners. This book provides vital information to help enterprise architects to realistically apply architecture modeling to their architecture engagements. Mike Walker, 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. This book will further encourage the use of these standards, and prove to be an invaluable source of inspiration for enterprise architects. Allen Brown - CEO, The Open Group This book answers questions of those considering enterprise architecture and provides a roadmap for establishing an enterprise architecture 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. BiZZdesign Academy Phone + 31 (0) Fax + 31 (0) [email protected] Internet BiZZdesign Academy, 2012 ISBN: BiZZdesign

139 Interested in reading more? Order your book here! BiZZdesign Building Strong Organizations BiZZdesign Building Strong Organizations