1 White Paper Publication date: May 31 st, 2012 Enterprise with TOGAF 9.1 and ArchiMate Henk Jonkers, Dick Quartel, Bas van Gils and Henry Franken Executive summary With the appearance of Version 2.0, the ArchiMate standard for enterprise architecture modelling now offers full modelling support throughout the architecture development cycle. It allows for the description and visualization of different architecture domains and their relationships, as well as the motivation behind the architecture, and the implementation projects and migration planning. ArchiMate complements TOGAF, the standard method of The Open Group for developing enterprise architectures. In this paper, we highlight what is new in the new versions of these two standards, and we illustrate how they can be used together to provide an integral approach to enterprise architecture. 1 ArchiMate and TOGAF are registered trademarks of The Open Group and logo s are registered trademarks of Company.
2 Page 2 of 18 Contents Introduction... 3 An Integrated Approach to Enterprise... 3 Way of Working: TOGAF... 4 The components of TOGAF...4 What s new in TOGAF 9.1?...4 The Development Method (ADM)...5 Way of Modelling: ArchiMate... 6 What s new in ArchiMate 2.0?...6 Summary of the ArchiMate core...7 Summary of the ArchiMate extensions...7 ArchiMate and TOGAF...9 Example case: ArchiSurance... 9 Motivation Application...11 Data...12 Technology...13 Gap Analysis...13 Implementation and migration planning...14 Summary and Conclusions References... 16
3 Page 3 of 18 Introduction Early in 2012, Version 2.0 of ArchiMate, the enterprise architecture modelling standard of The Open Group, was published. A few months before that, the 9.1 update of TOGAF came out, the standard framework and method for enterprise architecture development of The Open Group. ArchiMate was developed with the aim to provide a uniform representation for enterprise architecture descriptions  . It offers an integrated architectural approach by which organizations can describe and visualize different architecture domains, as well as their underlying relationships and dependencies. In Version 2.0 of the language, additional concepts have been added to model the motivation behind the architecture, and to support implementation and migration planning. With these extensions, ArchiMate provides full modelling support throughout the TOGAF architecture development cycle. In this paper, we outline an integrated approach to enterprise architecture based on these two standards of The Open Group. We briefly introduce TOGAF and ArchiMate, and highlight what is new in the new versions of these standards. We illustrate our approach with an example. An Integrated Approach to Enterprise Frameworks for enterprise architecture vary in the types of support that they offer. They may have, among others, any combination of the following ingredients (see Figure 1): A process ( way of working ) for creating architectures; this may be accompanied by guidelines, techniques and best practices. A set or classification of viewpoints. A language ( way of modelling ) for describing architectures (defining concepts and relationships, but also a notation). The concept of a (virtual) architecture repository, possibly containing predefined architectural artefacts and (reference) models. TOGAF ArchiMate Process Language Figure 1. Ingredients of an Integrated Enterprise Approach TOGAF and ArchiMate have a firm common foundation in their shared notion of enterprise architecture. Both adopt the central concept of viewpoints on a single underlying model repository, aimed at a specific set of stakeholders and concerns. On the other hand, the standards complement each other: TOGAF provides an elaborate method, including a process, guidelines and techniques, for enterprise architecture development, while ArchiMate provides a well-defined language, including a graphical notation, for enterprise architecture modelling. Together, these two standards make up a complete and integrated approach to enterprise architecture.
4 Page 4 of 18 Way of Working: TOGAF The components of TOGAF The main structure of TOGAF 9.1 consists of six components: 1. The core of TOGAF is formed by the Development Method (ADM), a step-wise iterative approach for the development and implementation of an Enterprise. The phases of the ADM will be explained in some more detail below. 2. A collection of Guidelines and Techniques to support the application of the ADM. The guidelines address adaptation of the ADM in order to deal with a number of usage scenarios, including different process styles (for example, the use of iteration) and specific specialist architectures (for example, the security architecture). The techniques support specific tasks within the ADM, such as, defining principles, business scenarios, gap analysis, migration planning and risk management. 3. The Content Framework (ACF) provides a detailed model of architectural work products, including deliverables, artefacts within deliverables and the architecture building blocks represented by deliverables. While the ACF defines a content metamodel that specifies the relevant types of building blocks, it does not provide a complete modelling language; this is where ArchiMate complements TOGAF. 4. The Enterprise Continuum describes a view of the architecture repository (a concept which is also 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 reused. This is based on architectures (in the Continuum) and solutions (in the Solutions Continuum) existing 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 Continuum: the TOGAF Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM). 6. The Capability Framework is a set of resources, guidelines, templates and background information provided to help the architect to establish an architecture practice within the organization. What s new in TOGAF 9.1? TOGAF 9.1 is a maintenance update to TOGAF 9, and does not contain many substantial changes compared to its predecessor (unlike the major upgrade from Version 8 to Version 9 in 2009). There are several editorial improvements and corrections throughout the document. The objectives of all the ADM phases have been reformulated, and the descriptions of the implementation- and migration-related phases have been extended. Also, some pieces have been removed from the standard (e.g., the document classification model and the building block example).
5 Page 5 of 18 The Development Method (ADM) The core of TOGAF is formed by the Development Method (ADM), a step-wise, iterative process for the development and implementation of an enterprise architecture (see Figure 2). Preliminary Preliminaryr 1. Getting the organization committed & involved H. Change G. Implementation Governance F. Migration Planning A. Vision Requirements E. Opportunities and Solutions B. D. Technology C. Information Systems s 4. Keep the process running G. Implementation Governance H. Change F. Migration Planning Preliminary A. Vision Requirements E. Opportunities and Solutions B. C. Information Systems s D. Technology G. Implementation Governance H. Change F. Migration Planning A. Vision Requirements E. Opportunities and Solutions 3. Making the architecture work B. C. Information Systems s D. Technology H. Change G. Implementation Governance F. Migration Planning Preliminary A. Vision Requirements E. Opportunities and Solutions B. C. Information Systems s D. Technology G. Implementation Governance H. Change F. Migration Planning Preliminary A. Vision Requirements E. Opportunities and Solutions B. D. Technology C. Information Systems s 2. Getting the architecture right Figure 2. Development Method (from ) The ten phases of the ADM can be grouped into four main parts, also shown in Figure 2: 7. Getting the organization committed 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, Vision, prepares for a single architecture development cycle, and includes the formulation of an architecture vision with a high-level overview of the change that is envisaged. 8. 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). 9. 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 analysis 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. 10. Keep the process running is concerned with the management, prioritization and version control of requirements on the architecture. The central Requirements process manages the requirements during an architecture development cycle. In Phase H, Change, new requirements are identified that may lead to the start of the new architecture development cycle. TOGAF also includes the identification of viewpoints, techniques and reference models. However, it does not define an actual modelling language. The TOGAF Content Framework does indeed identify relevant architecture building blocks, but it 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.
6 Page 6 of 18 Way of Modelling: ArchiMate Within larger organizations, one can typically find various architecture domains, such as organizational structures, products, business processes, information systems, applications and technical infrastructure. Traditionally, each architecture domain employs specific models and visualizations, which simplifies communication, discussion and analysis within the domain. However, the relations between these different domains are in many cases unclear. Moreover, these domains tend to (at least partially) overlap. Therefore, ArchiMate provides a unified way to model enterprise architectures, while integrating the various domains and describing them in an easily readable way, as illustrated in 0 ArchiMate is positioned at the level of enterprise architecture, which implies that the ArchiMate language does not provide the level of detail one would typically find in languages used at the design level , such as BPMN  for business process design and UML  for application and technical infrastructure design. ArchiMate has been designed in a structured way, by defining a generic structure that is made specific for the different architectural layers. It also defines a limited set of relation types that are used throughout the language. Finally, ArchiMate provides a standard graphical notation for the modelling concepts and relations. In this section, we briefly discuss the structure and main elements of the ArchiMate language. In  a more detailed account is provided of the requirements on the language, and the design decisions that underpin its design. Information architecture? Process architecture Product architecture? Application architecture?? Technical architecture? Figure 3. Integration of Architectural Domains What s new in ArchiMate 2.0? In the ArchiMate core, a large number of minor improvements have been made compared to ArchiMate 1.0: inconsistencies have been removed, examples have been improved, and additional text has been inserted to clarify certain aspects. Two new concepts have been added to the core, based on needs experienced by practitioners: Location, to model a conceptual point or extent in space that can be assigned to structural elements and, indirectly, of behaviour elements. Infrastructure function, to model the internal behaviour of a node in the technology layer. This makes the technology layer more consistent with the other two layers. Furthermore, ArchiMate 2 adds two extensions to the language. With these extensions, ArchiMate provides modelling support throughout the TOGAF ADM:
7 Page 7 of 18 The Motivation extension defines concepts to model the motivation for the choices made in the design of the architecture. This includes concepts such as stakeholder, driver, goal, requirement and principle. For motivation elements, a limited set of relationships has been defined, partly reused from the ArchiMate core. The Implementation & Migration extension defines concept to support the identification of implementation projects and migration planning. This includes concepts such as work package, deliverable, plateau and gap. Simultaneously with the publication of ArchiMate 2.0, The Open Group also launched a certification programme for AchiMate practitioners, tools and training courses. Summary of the ArchiMate core The ArchiMate core defines the concepts to model actual architectures, as described in Phases B, C and D of the TOGAF ADM. This is essentially the part of ArchiMate as described in Version 1.0 of the language, with the exception of the changes mentioned before. Figure 4 summarizes the most frequently used concepts of the ArchiMate core, positioned within the ArchiMate framework. The framework identifies three architectural layers, which largely correspond to the three phases for architecture development in the TOGAF ADM: the business layer, the application layer, and the infrastructure layer. Within each layer, three aspects are described: the active structure, i.e., the entities that perform behaviour (e.g., business actors, application components, infrastructure nodes), the behaviour (e.g., processes, functions, and services), and the passive structure, i.e., the (information) objects that are processed as part of the behaviour. Representation object service process interface role Location actor Application Relations assignment triggering realization access association used by Data object Application service Application function Application interface Application component Technology Artifact Infrastructure service Infrastructure function Infrastructure interface Node Network Passive structure Behaviour Active structure Figure 4. Summary of the ArchiMate Core Summary of the ArchiMate extensions As described in the previous sections, the ArchiMate core (and therefore, ArchiMate 1.0) chiefly supports modelling of the architectures in Phases B, C and D in the TOGAF ADM ( Getting the architecture right in Figure 2), as is illustrated in Figure 13. The resulting models are used as input for the subsequent ADM phases; modelling concepts specifically aimed at the other phases e.g., concepts for modelling principles, goals and requirements, or concepts to support migration planning were still missing in Version 1.0 of the language. However, as stated before, ArchiMate 2.0 provides two extensions for this: one for describing motivation (e.g. stakeholders, goals and requirements), supporting the phases for Getting the organization committed and involved and Keep the process running from Figure 2, and one for implementation and migration planning, supporting the phases for Making the architecture work from Figure 2. The next subsections outline these two extensions.
8 Page 8 of 18 Figure 5 adds the two extensions to the ArchiMate framework, and shows how the main concepts from the extensions are related to the core. The motivation extension of ArchiMate  adds concepts related to goal modelling and business requirements management. They can be used for the identification, description, analysis and validation of goals and requirements at business level and their realization in enterprise architecture models as described with the ArchiMate core concepts. The motivational concepts, based on sources such as OMG s Motivation Model , architecture principles  and goal-driven requirements engineering  are used to model the motivations, or intentions, that underlie the design of an enterprise architecture. These intentions influence, guide and constrain the design. Intentions are pursued by stakeholders, which can be individuals or groups such as a project team, enterprise or society. In addition, intentions may be organized into certain areas of interest, called drivers, such as customer satisfaction, compliance to legislation or profitability. The actual intentions are represented by goals, principles and requirements. Goals represent some desired result or end that a stakeholder wants to achieve; e.g., increasing customer satisfaction with 10 percent. Principles and requirements represent desired properties of solutions or means to realize the goals. Principles represent desired properties that are required from all possible solutions in a given context; requirements represent desired properties of specific, individual solutions. For example, a requirement Use a single CRM system is a specialization of a principle Data should be stored only once by applying it to the current organization s architecture in the context of the management of customer data. A constraint is a specific type of requirement that restricts the way in which a system is realized. Requirements are realized by core elements. Passive structure Behavior Active structure Motivation Core element Implementation & Migration Technology Application Figure 5. Summary of the ArchiMate Extensions The Implementation and Migration Extension defines a number of additional concepts that enable the modelling of the architecture change process and increase the insight into these changes as well as their manageability in terms of portfolio and project management and decision making. By defining concepts such as work package (to model implementation work at different levels of granularity, e.g., programs, projects, or project tasks), deliverable and plateau it is possible to connect ArchiMate with program and project management standards and best practices, such as MSP , PRINCE2  and PMBoK . Deliverables realize plateaus or core elements, and plateaus aggregate core elements. Relationships can be established between the enterprise architecture models created at different
9 Page 9 of 18 moments in time and the migration models. These differences are captured by the concept of gap. A gap is an important outcome of a gap analysis in Phases B, C, and D of the TOGAF ADM, and forms an important input for the subsequent implementation and migration planning. The gap concept is linked to two plateaus (e.g., baseline and target architecture, or two successive transition architectures), and represents the differences between these plateaus. ArchiMate and TOGAF Figure 6 shows a global mapping of the ArchiMate framework (core and extensions) to the phases of the TOGAF ADM. As indicated before, the core concepts are chiefly used to model the actual architectures in Phases B, C and D ( Getting the architecture right ). Moreover, the three layers of the ArchiMate core framework closely correspond to the three main types of architectures that these phases deal with. The concepts of the motivation extension are especially useful in the early ADM phases ( Getting the organization committed and involved ), to support stakeholder analysis and for the formulation of business goals and principles, as well as in Change and the Requirements phases ( Keep the process running ) to model and manage the requirements and constraints. Finally, the concepts of the implementation & migration extension mainly support the late ADM phases ( Making the architecture work ), to model implementation programs and projects, as well as plateaus and gaps for migration planning. Figure 6. TOGAF ADM and ArchiMate (from ) Example case: ArchiSurance Using a small example based on a fictitious insurance company, we illustrate how the different architectures as defined in TOGAF can be expressed with concepts of the ArchiMate core. ArchiSurance is a merger of three previously independent companies: Home & Away for homeowner s and travel insurance, PRO-FIT for car insurance, and Legally Yours for legal aid insurance. The new company has a single Front Office and three separate Back Offices. ArchiSurance has plans to rationalize their application portfolio, by integrating legacy applications with similar functionality from the old companies that are still in use. Note that these examples give an impression of the ArchiMate language, but do not show all the concepts. For a complete overview of the language, please refer to .
10 Page 10 of 18 Motivation Figure 7 shows a fragment of the motivation model for the proposed change. Stakeholder concerns, modelled as drivers, lead to business goals. These goals are realized by principles, which in turn are made more specific in terms of requirements. Figure 7. Motivation Extension Example The provides the context for system development trajectories, showing, among others, the main business processes, the actors (or roles) performing these processes, and the information (objects) exchanged between the processes. Figure 8 shows an example of a expressed in ArchiMate. We assume that the business architecture of ArchiSurance does not change in the application rationalization process.
11 Page 11 of 18 Figure 8. Baseline and Target Application The Application shows the applications or application components, their relationships and their functionality. Figure 9 shows the baseline Application of ArchiSurance. The functionality that the applications offer to their environment is modelled with services. The service concept plays a central role in ArchiMate, also in the and the Technology (although this is not shown in our example), and in particular as a linking pin between the different architectures. Figure 9. Baseline Application Figure 10 shows the target Application of ArchiSurance, in which the legacy applications have been replaced by a single back-office system and a single CRM system for the whole company.
12 Page 12 of 18 Figure 10. Target Application In ArchiMate, separate views can be used to show the relationships between the different architectures. As an example of this, Figure 11 shows how the services from the Application are used in the processes of the. Figure 11. -Application Alignment (Target) Data The Data shows the main data objects used within the applications, as well as their relationships. Figure 12 shows the Data of ArchiSurance, which we assume will not change in the application rationalization process. Figure 12. Baseline and Target Data
13 Page 13 of 18 Technology The Technology shows, among others, the devices and system software on which applications run, the networks connecting devices, and artefacts that form the physical implementation of application components or data objects. Figure 13 shows the baseline Technology of ArchiSurance. There are separate application servers for the different back-office applications. Figure 13. Baseline Technology In the target Technology, as shown in Figure 14, some of these application servers become redundant. However, to increase reliability and availability, an additional backup server is introduced. Figure 14. Target Technology Gap Analysis An important step in Phases B, C and D of the TOGAF ADM is a gap analysis, which reviews the differences between the baseline and target architecture. It shows which building blocks are carried over from baseline to target, which building blocks are new in the target architecture (which can be used as a basis to decide whether to buy or build these building blocks), and which elements have been eliminated from the baseline architecture (on purpose or accidentally; i.e., a gap analysis can also be used as a mechanism for validation of the target architecture). Subsequently, Phases E, F and G of the TOGAF ADM deal with the implementation of the proposed target architecture.
14 Page 14 of 18 TOGAF suggests the use of a gap matrix as a technique for gap analysis. However, ArchiMate models also form a useful starting point for gap analysis, and the results can also be presented as an ArchiMate view. Figure 15shows an example of this for the Technology. Figure 15. Technology Gap Analysis Implementation and migration planning Figure 16 shows an example of the use of work packages and deliverables. It shows one of the implementation projects, the integration of the back-office systems of ArchiSurance. This project is broken down in a number of project tasks, that product well-defined deliverables. Figure 16. Work Packages and Deliverables An important premise in TOGAF is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the ADM, a Baseline and Target are created, describing the current situation and the desired future situation. In Phase E, Transition s are defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target s. Transition s are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage. In order to support this, the plateau concept was introduced. Figure 17 shows an example with a single intermediary transition architecture. For example, after completion of the back-office integration project as described above, an intermediary situation is created with a single integrated back-office, but
15 Page 15 of 18 still two separate CRM applications. The gap concept is used to make the differences between two plateaus explicit (a gap is generally associated with elements in the architecture that are modified between the plateaus). Figure 17. Migration Planning Concepts Summary and Conclusions For several years, TOGAF has been the leading enterprise architecture method, developed and maintained by members of The Open Group. More recently, ArchiMate has been adopted as another standard of The Open Group, aimed at modelling enterprise architectures. With the publication of Version 2.0 of ArchiMate in early 2012, adding two extensions to the core language, thus providing complete modelling support throughout the architecture development cycle. TOGAF and ArchiMate have a shared vision on enterprise architecture the use of viewpoints, and the concept of an underlying common repository of architectural artefacts and models; i.e., they have a firm common foundation. However, they complement each other with respect to the definition of an architecture development process and the definition of an enterprise architecture modelling language. ArchiMate provides a concrete visualization for the architectures and views proposed in TOGAF. Thus, these two complementary open standards will reinforce each other and help to advance the enterprise architecture discipline in general.
16 Page 16 of 18 References  W. Engelsman, H. Jonkers and D.A.C. Quartel, ArchiMate Extension for Modeling and Managing Motivation, Principles, and Requirements in TOGAF TM, White Paper, The Open Group, Feb  H. Jonkers, H. van den Berg, M.-E. Iacob & D. Quartel, ArchiMate Extension for Modeling the TOGAF TM Implementation and Migration Phases, White Paper, The Open Group, Dec  H. Jonkers, E. Proper, M. Turner, TOGAF and ArchiMate: A Future Together. A Vision for Convergence & Co-Existence. Whitepaper, The Open Group, Nov  M.M. Lankhorst et al., Enterprise at Work Modelling, Communication and Analysis, Second Edition, Springer,  D.A.C. Quartel, W. Engelsman, H. Jonkers, M. J. van Sinderen, A Goal-Oriented Requirements Modeling Language for Enterprise. In Proceedings of the 13th IEEE International EDOC Enterprise Computing Conference, Auckland, New-Zealand, Sept. 2009, pp  The Open Group, ArchiMate 2.0 Specification, Van Haren Publishing, Also available on  The Open Group, TOGAF Version 9.1, Van Haren Publishing, Also available on  Object Group, Unified Modeling Language: Superstructure, v2.0. OMG Document Number formal/ , August 2005  Object Group, Process Modeling Notation, v1.1. OMG Document Number formal/ , January  M.M. Lankhorst, H.A. Proper, and H. Jonkers. The anatomy of the archimate language. International Journal of Information System Modeling and Design (IJISMD), 1(1):1-32,  Object Group, Motivation Model (BMM) Specification. Technical Report dtc/ , August  D. Greefhorst and H.A. Proper. Principles - The Cornerstones of Enterprise Ar-chitecture. Enterprise Engineering Series. Springer, Berlin, Germany,  H.A. Proper and D. Greefhorst. The Role of Principles in Enterprise. In H.A. Proper, M.M. Lankhorst, M. Schönherr, J. Barjis, and S.J. Overbeek (eds.), Proceedings of the 5th Workshop on Trends in Enterprise Research, TEAR 2010, Delft, The Netherlands, volume 70 of Lecture Notes in Information Processing, pages Springer, Berlin, Germany, November  E.S.K. Yu and J. Mylopoulos. Understanding why in software process modelling, analysis, and design. In Proceedings of the 16th international conference on Software engineering, Sorrento, Italy, Los Alamitos, California, pages , Los Alamitos, California,  G. Regev and A. Wegmann. Where do goals come from: the underlying principles of goal-oriented requirements engineering. In Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE05), Paris, France, August,  A. Van Lamsweerde. Goal-Oriented Requirements Engineering: A Guided Tour. In Proceedings of the 5 th International Symposium on Requirements Engineering,  J. Chittenden and J. Van Bon, Programme Based on MSP: A Guide, Van Haren Publishing,  The Project Institute, Project Body of Knowledge. Technical report, November  The Stationary Office, Managing Successful Projects with PRINCE2, 2009.
17 Page 17 of 18
18 Please contact us at or send a direct message to Henk Jonkers, Offices Corporate Headquarters R & D and Backoffice Capitool 15 P.O.Box AH Enschede The Netherlands +31 (0) Netherlands Consultancy and Academy Stationsstraat 79 F (6th floor) 3811 MH Amersfoort The Netherlands +31 (0) North America 161 Bay Street, 27th Floor Toronto, ON M5J 2S1 Canada United Kingdom 16th Floor Portland House Bressenden Place London SW1E 5RS United Kingdom +44 (0) Deutschland GmbH Lortzingstrasse Meerbusch-Büderich Germany Belgium Geldenaaksebaan Leuven Belgium
ArchiMate Extension for Modeling the TOGAF Implementation and Migration Phases A White Paper by: Henk Jonkers, Harmen van den Berg, Maria-Eugenia Iacob, and Dick Quartel December 2010 Copyright 2010 The
NAF Insight 8 maart 2012 Harmen van den Berg Let s get to know each other! Raise your hand: Who is TOGAF9 certified? Who is TOGAF8 certified? Who has ever attended a TOGAF training course? Who is ArchiMate
A Case Study by: Henk Jonkers, Iver Band, Dick Quartel January 2012 Copyright 2012, The Open Group This work is made available under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported
Building a strong data management capability with TOGAF and ArchiMate Bas van Gils email@example.com Dr. Bas van Gils +31-(0)6-484 320 88 firstname.lastname@example.org http://linkedin.com/in/basvg http://blog.bizzdesign.com
Building Business Capabilities using BiZZdesign Architect and ArchiMate October 17 th, 2013 Your presenter today Business and IT majors, University of Twente, Netherlands Experience in application, business
Developing Business Architecture with TOGAF Building Business Capability 2013 Las Vegas, NV Armstrong Process Group, Inc. www.aprocessgroup.com Objectives Introduce The Open Group Architecture Framework
ArchiMate and TOGAF What is the added value? Why use TOGAF next to ArchiMate? ArchiMate provides a (visual) language ArchiMate provides a content framework TOGAF provides a process TOGAF provides a way
Business Business Services Services and Enterprise and Enterprise This Workshop Two parts Background: Business Value of Enterprise TOGAF s and the Business Services We will use the key steps, methods and
Marc Lankhorst et al. Enterprise Architecture at Work Modelling, Communication and Analysis Third Edition 4y Springer Contents 1 Introduction to Enterprise Architecture 1 1.1 Architecture 1 1.2 Enterprise
The Fourth International Conference on e-learning (elearning-2013), 26-27 September 2013, Belgrade, Serbia MODELING UNIVERSITY METROPOLITAN ONLINE LEARNING SYSTEM ARCHITECTURE - THE TOGAF/ ARCHIMATE WAY
Linking BPMN, ArchiMate, and BWW: Perfect Match for Complete and Lawful Business Process Models? Ludmila Penicina Institute of Applied Computer Systems, Riga Technical University, 1 Kalku, Riga, LV-1658,
From Capability-Based Planning to Competitive Advantage Assembling Your Business Transformation Value Network Marc Lankhorst, BiZZdesign Iver Band, Cambia Health Solutions INTRODUCTIONS 2 1 Marc Lankhorst
ArchiMAte 2.0 A Pocket Guide The Open Group Publications available from Van Haren Publishing The TOGAF Series: togaf Version 9.1 togaf Version 9.1 A Pocket Guide togaf 9 Foundation Study Guide, 2nd edition
Visualizing the Business Impact of Technical Cyber Risks May 21, 2014 Henk Jonkers Senior Research Consultant, BiZZdesign Agenda Introduction and problem statement Enterprise Architecture with ArchiMate
Introduction In response to the demand I have seen via my Blog for TOGAF 9 questions I have put together this document of thirty multiple choice questions based on the TOGAF 9 specification. The multiple
Enterprise Architecture Review Arquitectura multivapa mediante Ajax y ORM Héctor Arturo Flórez Fernández * Fecha de recepción: octubre 29 de 2010 Fecha de aceptación: noviembre 23 de 2010 Abstract Enterprise
Using the ArchiMate Language with UML A White Paper by: Chris Armstrong, APG J.D. Baker, APG Iver Band, The Standard Sam Courtney, APG Henk Jonkers, BiZZdesign Veer Muchandi, Hewlett-Packard Martin Owen,
TOGAF TOGAF & Major IT Frameworks, Architecting the Family by Danny Greefhorst, MSc., Director of ArchiXL TOGAF is a registered trademark of The Open Group. Copyright 2013 ITpreneurs. All rights reserved.
NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5
ArchiMate Made Practical Modeling according to ArchiMate guided by a collection of good practices Colofon Title : ArchiMate Made Practical Date : 17 november 2007 Version : 2.0 Change : First translation
The Open Group Architectural Framework Background TOGAF is a step-by-step method for developing an enterprise architecture, using a set of prescribed tools. It is freely available on the Open Group website
Enterprise Architecture Assessment Guide Editorial Writer: J. Schekkerman Version 2.2 2006 Preface An enterprise architecture (EA) establishes the organization-wide roadmap to achieve an organization s
DEPARTMENT OF INFORMATICS TECHNISCHE UNIVERSITÄT MÜNCHEN Master s Thesis in Information Systems Scenario-based Analysis of Collaborative Enterprise Architecture Management Tools Nikolaus Katinszky DEPARTMENT
1 A Pragmatic View on Enterprise Architecture by Danny Greefhorst Published: June 1, 2012 (Article URL: http://www.tdan.com/view-articles/16108) This article from Danny Greefhorst describes some principles
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material,
Business Requirements as the Basis for Enterprise Architecture and Project Architectures Harmen van den Berg And the speaker is... Harmen van den Berg Manager BiZZdesign International Trainer for ArchiMate
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
Int'l Conf. Software Eng. Research and Practice SERP'15 225 Development of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert Fraunhofer Institute of Optronics, System Technologies and
Enterprise Architecture and ITIL Marco Vicente email@example.com Instituto Superior Técnico, Lisboa, Portugal July 2013 Abstract Business/IT alignment has become one of the most relevant concerns
Enterprise architect is an architecture repository used by many organisations. In this paper I describe a project for introducing an Enterprise Architecture with Archimate 2.0 in a repository based solution.
TOGAF 9 Level 1 + 2 Exam Study Guide Created by Nik Ansell http://ae.linkedin.com/in/nikansell Introduction This document was created to help focus the study areas of TOGAF 9 students, studying for the
Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky
Nº 130 A Lightweight Approach for Designing Enterprise Architectures Using BPMN: an Application in Hospitals O.Barros, R.Seguel, and A. Quezada DOCUMENTOS DE TRABAJO Serie Gestión Aceptado para presentacion
1 On the Notion and Use of Architecture Principles in Transformation by Danny Greefhorst, Erik Proper Published: November 1, 2011 (Article URL: http://www.tdan.com/view-articles/15655) Danny Greefhorst
SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
Open Group Standard ArchiMate 2.0 Specification The Open Group Publications available from Van Haren Publishing The TOGAF Series: TOGAF Version 9.1 TOGAF Version 9.1 - A Pocket Guide TOGAF 9 Foundation
2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture A Variability Viewpoint for Enterprise Software Systems Matthias Galster University of Groningen,
202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering
A Practical Approach to the Formulation and Use of Architecture Principles D. Greefhorst and H.A. Proper ArchiXL, Amersfoort, The Netherlands Public Research Centre Henri Tudor, Luxembourg Radboud University
Software Development in the Large! Peter Eeles Executive IT Architect, IBM firstname.lastname@example.org IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development
Requirements Management Practice Description 1. REQUIREMENTS MANAGEMENT (RM) 1.1 Description of the practice TRASYS provide solutions to effectively manage critical issues and reduce risks in project related
The Unified Software Development Process Technieche Universal Darmstadt FACHBEREICH IN-FORMAHK BLIOTHEK Ivar Jacobson Grady Booch James Rumbaugh Rational Software Corporation tnventar-nsr.: Sachgebiete:
A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box
Developing Developing ure ure Skills Skills In this session we will explore the architecture role and skills of Enterprise ure the TOGAF Skills Framework and varieties of s Is your organisation up to the
Enterprise Portfolio Management Managing large volumes of structured data Through its powerful capabilities as a structural modeling tool, ABACUS Summary provides of whitepaper a ready-to-go Summary solution
SETLabs Briefings VOL 6 NO 4 2008 Building Blocks for Enterprise Business Architecture By Eswar Ganesan and Ramesh Paturi A unified meta-model of elements can lead to effective business analysis Enterprise
The Use of UML Activity Diagrams and the i* Language in the Modeling of the Balanced Scorecard Implantation Process Mariela Haya, Xavier Franch and Enric Mayol Universitat Politècnica de Catalunya (UPC)
Global Standards and Publications EDITION 2016/2017 Colophon Title: Global Standards and Publications Edition 2016/2017 Publication of: Van Haren Publishing, www.vanharen.net ISBN Hard copy: 978 94 018
Global Standards and Publications Edition 2012 / 2013 Global Standards and Publications EDITION 2012/2013 Colophon Title: Global Standards and Publications Edition 2012 / 2013 Publication of: Van Haren
Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements
Reference Process for Enterprise Architecture enabled ICT Planning NSW GEA Toolkit R1 April 2015 Contact email@example.com Strategic Policy Department of Finance, Services & Innovation 1 Table of Contents
Landscape Maps for Enterprise Architectures L. van der Torre 1, M.M. Lankhorst 2, H. ter Doest 2, J.T.P. Campschroer 3, F. Arbab 4 1 University of Luxembourg, Luxembourg 2 Telematica Instituut, Enschede,
by Filippos Santas, IT Architect for Credit Suisse Private Banking in Switzerland and Certified SOA Trainer SERVICE TECHNOLOGY MAGAZINE Issue LI June 2011 This is second part in a multi-part article series.
Chapter 3 A Conceptual Framework for Principles Abstract This chapter provides the theoretical core of this book. It is concerned with a conceptual framework for architecture principles and related concepts.
Frameworks for IT Management Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net 18 ITIL - the IT Infrastructure
An Investigation of Agent Oriented Software Engineering Methodologies to Provide an Extended Methodology A.Fatemi 1, N.NematBakhsh 2,B. Tork Ladani 3 Department of Computer Science, Isfahan University,
Banking Transformation Framework Transform Your Bank in Measurable Steps Table of Contents 2 Establish a Platform for Transformation 3 Transform Your Business 3 Use the Reference Architecture As a Foundation
IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational
SCIENTIFIC PAPERS, UNIVERSITY OF LATVIA, 2010. Vol. 757 COMPUTER SCIENCE AND INFORMATION TECHNOLOGIES 23 29 P. Clarifying a vision on certification of MDA tools Antons Cernickins Riga Technical University,
A Concept Model for the UK Public Sector January 2012, Version 0.2 January 2012, Version 0.2 Introduction This paper is produced by the CTO Council Information Domain to scope and propose a concept model
SOA policy management White paper April 2009 Realizing business flexibility through integrated How integrated management supports business flexibility, consistency and accountability John Falkl, distinguished
Whitepaper Data Governance Roadmap for IT Executives Valeh Nazemoff The Challenge IT Executives are challenged with issues around data, compliancy, regulation and making confident decisions on their business
Concept of a Domain Repository for Industrial Automation Camelia Maga and Nasser Jazdi Institute of Industrial Automation and Software Engineering (IAS), Universität Stuttgart, Pfaffenwaldring 47, 70569
Syllabus REQB Certified Professional for Requirements Engineering Version 2.1 2014 The copyright to this edition of the syllabus in all languages is held by the Global Association for Software Quality,
How to simplify the evolution of business process lifecycles Dr Alexander Samarin Independent consultant, Switzerland www.improving-bpm-systems.com firstname.lastname@example.org Abstract. My experience shows that
ABACUS for Business Process Management Business Process Management (BPM) is one of the most popular methods for retaining business viability in a competitive market. ABACUS supports practitioners in managing
Global Standards and Publications Edition 2014/2015 Global Standards and Publications EDITION 2014/2015 Colophon Title: Global Standards and Publications Edition 2014/2015 Publication of: Van Haren Publishing,
Extended Enterprise Architecture Framework Essentials Guide Editorial Writer: J. Schekkerman Version 1.5 2006 Preface An enterprise architecture (EA) establishes the organization-wide roadmap to achieve
Data Migration through an Approach An Executive Overview Introducing MIKE2.0 An Open Source Methodology for http://www.openmethodology.org Management and Technology Consultants Data Migration through an
Interoperability architecture for electric mobility Allard Brand 1, Maria-Eugenia Iacob 2, Marten J. van Sinderen 2 1 Energie Data Services Nederland, 2 University of Twente 6th International IFIP Working
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
Implementation of GWEA: Case study of KZN Provincial Government By Irshad Abdulla (Senior Specialist: Architecture, SITA) Objectives Define problem statement High level overview of GWEA Overview of practitioner
Model bundling: Towards a value-based componential approach for language engineering Sybren de Kinderen 3,4, Qin Ma 1,4, and Henderik A. Proper 1,2,4 1 Public Research Centre Henri Tudor, Luxembourg, Luxembourg
How Application Portfolio Management and Enterprise Architecture Add Up to IT Governance Optimizing your organization s information system A MEGA White Paper By François Tabourot, Operational Governance
Leading the Evolution WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Discovery and management of business rules avoids business disruptions WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Business Situation More
Traceability Patterns: An Approach to Requirement-Component Traceability in Agile Software Development ARBI GHAZARIAN University of Toronto Department of Computer Science 10 King s College Road, Toronto,
Service Modelling & Service Architecture: From Service Renewal and Service Flows to Service Architecture Presenter: Professor Paul Buhler Head of the Global University Alliance SOA Research & Development
The OMG BPM Standards Derek Miers CEO, BPM Focus +44 (20) 8742 8500 UK Office +44 (7703) 178 500 UK Cell +1 (714) 600 9010 US Cell email@example.com A BPM Definition Business Process Management is primarily
Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.