Post on 29-Jan-2021
Software Engineering für betriebliche Informationssysteme (sebis) Fakultät für InformatikTechnische Universität München
wwwmatthes.in.tum.de
Useful EAM-Standards and Best-Practice Frameworks29.06.2016, Prof. Dr. Florian Matthes
1. Useful EAM-Standards and Best-Practice Frameworks
Outline
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 2
Enterprise architecture frameworks have a long history.
160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 3© sebis
1985 1990 1995 2000 2005 2010
PERA1989
GRAI/GIM 1.01992
GERAM1994
PERA2001
GERAM 1.6.31999
CIMOSA1984
CIMOSA1999
ARIS1991
ARIS 7.12008
JTA 1.01996
JTA 7.02005
TAFIM 1.31992
TAFIM 2.01994
TAFIM 3.01996
TAFIM2000
DoD EA TRM 0.42005
C4ISR 1.01996
C4ISR 2.01997
DoDAF 1.02003
DoDAF 1.52007
DoDAF 2.02009
TOGAF 11995
TOGAF 8.12003
TOGAF 92009
TISAF 1.01997
TEAF 1.02000
MODAF2005
MODAF 1.22008
EAP1992
EAP1996
FEAF 1.11999
FEA 1.02001
NIST EA1989 NC3SAF
2000NAF 2.0
2004NAF 3.0
2007
Zachmann1987
Zachmann1992
Zachmann 2.0.12008
IAF1993
E2AF2003
E2AF 1.52006
IAF 11995
IAF 21997
IAF v32001
IAF 4.02007
sebis EAMPC2008
sebis EAMPC2015
Legend:superseeded by
influenced by
Start ofdevelopment
Currentversion
No furtherdevelopment
Intermediateversion
TOGAF 9.12011
MODAF 1.2.42010
sebis BEAMS2010
Enterprise architecture frameworks have a long history.
§ Several frameworks for the Enterprise Architecture (EA Frameworks) have been developed over time
§ Their level of detail differs strongly § Zachmann - “1” page § TOGAF (Version 9 "Enterprise Edition") - “700+” pages
§ Generalized Enterprise Reference Architecture and Methodology (GERAM) § ISO Norm 15704 § Guidelines for creating frameworks§ (As of today) no well-accepted reference
§ DoDAF (Department of Defense) and NAF (Nato Architecture Framework) are binding for IT in the military domain
§ ARIS book of 1991 vs. ARIS method manual of the ARIS-Platform of 2007. Mainly relevant in DACH
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 4
The Zachman Framework for Enterprise Architecture
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 5
Level
of
Detail
Zachmann: Analogy to building construction
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 6
Building construction
Zachman, John A. (1987): A framework for information systems architecture. In: IBM Systems Journal 26 (3), p. 276–292.
Zachman: Different models depending on the stakeholder§ Bubble charts
§ Basic concepts for building§ Gross sizing, shape, spatial
relationships§ Architect/owner mutual understanding§ Initiate project
§ Architect‘s drawings§ Final building as seen by the owner§ Floor plans, cutaways, pictures§ Architect/owner agreement on building§ Establish contract
§ Architect‘s plans§ Final building as seen by the designer§ Translation of owner‘s view into a
product§ Detailed drawings – 16 categories§ Basis for negotiation with general
contractor
§ Contractor‘s plans§ Final building as seen by the builder§ Architect‘s plans constrained by laws of
nature and available technology§ „How to build it“ description§ Directs construction activities
§ Shop plans§ Subcontractor‘s design of a part/section§ Detailed stand-alone model§ Specification of what is to be
constructed§ Pattern
§ Building§ Physical building
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 7
Zachman, John A. (1987): A framework for information systems architecture. In: IBM Systems Journal 26 (3), p. 276–292.
Zachman: Framework 1987
§ 5 Levels§ Scope description
(ballpark view)§ Model of the business
(owner‘s view)§ Model of the information system
(designer‘s view)§ Technology model
(builder‘s view)§ Detailed description
(out-of-context view)
§ 3 perspectives§ Data description§ Process description§ Network description
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 8
Zachman: Framework 1987 – 2004
§ Zachman Framework started in 1987§ as „A framework for information systems architecture“!§ with 5 levels and 3 perspectives
§ In 1992 Zachman and Sowa§ extended the framework with 3 new perspectives
§ Persons (Who?)§ Time (When?)§ Motivation (Why?)
§ Added a meta-model for the owner’s, designer‘s und builder‘s level § Defined 7 rules for the concretion of the framework
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 9
Zachman, J. A. (1987): A framework for information systems architecture. In: IBM Systems Journal 26 (3), p. 276–292.Zachman, J. A. and Sowa, J. F. (1992): Extending and formalizing the framework for information systems architecture. In: IBM Systems Journal 31 (3), p. 590 –616.
Quasar Enterprise: Macro-structure of the Integrated Architecture Framework (IAF) (1)
§ The basic structure of CapGemini can be divided into two dimensions§ Architecture aspects: Different architectures of an enterprise§ Architecture layers: contextual, conceptual, logical und physical layer of
each architecture aspect
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 10
PhysicalWith What?
LogicalHow?
ConceptualWhat?
Busi
ness
Arc
hite
ctur
e
Info
rmat
ion
Arch
itect
ure
Info
rmat
ion
Syst
ems
Arch
itect
ure
Tech
nolo
gy In
frast
ruct
ure
Arch
itect
ure
Governance Architecture
Security Architecture
ContextualWhy?
Macro-structure of the Integrated Architecture Framework (IAF)
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
Quasar Enterprise: Macro-structure of the Integrated Architecture Framework (IAF) (2)
§ Business architecture – Structures the business processes and business services in order to match the business goals and to model the organization of the enterprise
§ Information architecture – Structures the information required in the business architecture
§ Information systems architecture – Structures the application landscape from a business perspective
§ Technology infrastructure architecture – Structures the used technical platforms and system software components
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 11
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
Creation of a regulation framework (1)
§ Creation of a regulating framework for questions, which should be addressed in the context of an enterprise architecture
§ Everything starts with a clear separation between business and IT
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 12
Business IT
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
Creation of a regulation framework (2)
§ Afterward it is important to distinguish between requirements and implementation
Business strategy IT strategy
Business architecture
(Business process, ,Business services,
Business objects,organizations, etc.)
Requirements
--
Implemen-tation
Business IT
Architecture of theapplication landscape
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 13
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
Creation of a regulation framework (3)
§ Business strategy, quality criteria and business architecture are driving the design of the application landscape
Business strategy IT strategy
Business architecture
(Business processes,Business services ,Business objects ,Organisation , etc.)
Requirements
-
Implemen-tation
Business IT
Architecture of theapplication landscape
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 14
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
Map of Quasar Enterprise
§ Creation of an unique view on the business architecture. On the part of the IT, the IAF architecture aspects and -layers are respected
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 15
Business
Contextual(Why?)
Conceptual(What?)
Logical(How?)
Physical(With What?)
Business strategy
Business architecture
(business services, business processes,
business objects, organisation etc.)
IT
Domains and(application)
services
LogicalAL components
and interfacesPhysische
Physical AL components
and interfacesPhysische
Technical services
Logicalapplication and
integration platforms
Physical application and
integration platforms
Technical Infrastructure (TI)Information Systems (IS)
As-is
To-b
e
IDEA
L
Inte
grat
ion
Idea
l app
licat
ion
land
scap
e
Business architecture
Inte
grat
ion
plat
form
Evolution
IT strategy
Engels, G.; Hess, A.; Humm, B.; Juwig, O. (2008): Quasar Enterprise, d-punkt Verlag.
TOGAF 9: Scope & goalsScopeTOGAF emphasizes business goals as architecture drivers, and provides a repository of best practices, including:§ TOGAF Architecture Development Method (ADM)§ ADM Guidelines & Techniques§ TOGAF Architecture Content Framework§ Enterprise Continuum§ TOGAF Reference Models§ TOGAF Capability Framework
Long-term goals§ An industry standard, generic enterprise architecture method….§ ….usable on its own or in conjunction with frameworks having products
relevant/specific to particular sectors.• Several frameworks are directly referenced:
-Zachman, Spewak, DoD Framework, FEAF, TEAF, …• Almost complete focus on artefacts, not method• TOGAF and…. (not TOGAF or….)
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 16
TOGAF as aBusiness Transformation Framework
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 1717
CapabilityCapability IncrementCapability Increment
People Dimension
■ Individual Training■ Collective
Training■ Professional
Development
Process Dimension
■ Concepts■ Business
Processes■ Information
Management
Material Dimension
■ Infrastructure■ Information
Technology■ Equipment
Planning, Monitoring, Controlling
Project-Portfolio
CapabilityBusiness strategy
Business model &
capabilitiesDesign options
TOGAF is a trademark of The Open Group
TOGAF as a Business Transformation Framework
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 1818
The current version 9.1 of TOGAF provides a basis for developing an organization-specific Business Transformation Framework.
Needs of the business shape non-architectural aspects of business operation
TOGAF Enterprise Continuum Tools
TOGAF Capability Framework
Business Vision and Drivers
Business Capabilities
Architecture Capability Framework
(Part VII)
Architecture Development Method
(Part II)ADM Guidelines and Techniques (Part III)
Enterprise Continuum and Tools
(Part V)TOGAF Reference Models (Part VI)
Architecture Content
Framework (Part IV)
The Architecture Capability operates a method
The method produces content to be stored in the Repository, classified
according to the Enterprise Continuum
TOGAF ADM & Content Framework
Operational changes update the Enterprise Continuum and
Repository
The Enterprise Continuum and Repository inform the business
of current state
The method delivers new business solutions
Business need feed into the method, identifying problems to be addressed
The method refines under-standing of business need
Informs the size, structure and culture of the capability
Effective operations of the Architecture Capability ensures realization of the
Business Vision
Sets targets, KPIs, plans and budgets for architecture roles
Business Capability drives the need for Architecture Capability Maturity
Learning from business operation creates new business need
Needs of the business shape non-architectural aspects of business operation
TOGAF Enterprise Continuum Tools
TOGAF Capability Framework
Business Vision and Drivers
Business Capabilities
Architecture Capability Framework
(Part VII)
Architecture Development Method
(Part II)ADM Guidelines and Techniques (Part III)
Enterprise Continuum and Tools
(Part V)TOGAF Reference Models (Part VI)
Architecture Content
Framework (Part IV)
The Architecture Capability operates a method
The method produces content to be stored in the Repository, classified
according to the Enterprise Continuum
TOGAF ADM & Content Framework
Operational changes update the Enterprise Continuum and
Repository
The Enterprise Continuum and Repository inform the business
of current state
The method delivers new business solutions
Business need feed into the method, identifying problems to be addressed
The method refines under-standing of business need
Informs the size, structure and culture of the capability
Effective operations of the Architecture Capability ensures realization of the
Business Vision
Sets targets, KPIs, plans and budgets for architecture roles
Business Capability drives the need for Architecture Capability Maturity
Learning from business operation creates new business need
TOGAF is a trademark of The Open Group
TOGAF core elements of version 9.1 (1)
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 1919
The structure of TOGAF 9.1 is organized along the structure and content of an Enterprise Architecture Capability.
The core of TOGAF describes the TOGAF Architecture Development Method (ADM) – a phase-oriented approach for developing an enterprise architecture.
Part II:ArchitectureDevelopmentMethod(ADM)
This collection includes several manuals and methods, supporting the implementation of TOGAF and the TOGAF ADM.
Part III:ADM Guidelines and Techniques
Introduction of the core concepts of enterprise architecture and in particular the TOGAF approach. Includes definitions and release notes with essential changes to previous TOGAF versions.
Part I:Introduction
This part describes the TOGAF Content Framework. It includes a structured meta-model for architecture artefacts, re-usable architecture building blocks and typical deliverables of enterprise architecting.
Part IV:Architecture Content Framework
Business Architecture Information Systems Architecture Technology Architecture
Architecture Realization
Architecture Principles, Vision and Requirements
Opportunities, Solutions and Migration Planning
Capabilities Work Packages Architecture Contracts
Implementation Governance
Standards Guidelines Specifications
PreliminaryArchitecture Principles
Architecture Requirements
Architecture VisionBusiness Strategy Technology Strategy Business Principles, Objectives and Drivers Architecture Vision Stakeholders
Requirements Constraints Assumptions Gaps
Organization
Function
Motivation
Organization Actor, RoleLocation
Drivers ObjectivesGoals Measures
Business Services, Contracts, Service
QualitiesFunctionsProcesses, Events, Controls, Products
Data Application
Data Entities
Physical Data Components
Logical Data Components
Information System Services
Physical Application Components
Logical Application Components
Platform Services
Physical Technology Components
Logical Technology Components
Business Architecture Information Systems Architecture Technology Architecture
Architecture Realization
Architecture Principles, Vision and Requirements
Opportunities, Solutions and Migration Planning
Capabilities Work Packages Architecture Contracts
Implementation Governance
Standards Guidelines Specifications
PreliminaryArchitecture Principles
Architecture Requirements
Architecture VisionBusiness Strategy Technology Strategy Business Principles, Objectives and Drivers Architecture Vision Stakeholders
Requirements Constraints Assumptions Gaps
Organization
Function
Motivation
Organization Actor, RoleLocation
Drivers ObjectivesGoals Measures
Business Services, Contracts, Service
QualitiesFunctionsProcesses, Events, Controls, Products
Data Application
Data Entities
Physical Data Components
Logical Data Components
Information System Services
Physical Application Components
Logical Application Components
Platform Services
Physical Technology Components
Logical Technology Components
1
Prelim Framework
and Principles
Requirements
H Architecture
Change Management
G Implementation
Governance
FMigration Planning E
Opportunities and Solutions
DTechnology
Architectures
CInformation
System Architectures
BBusiness
Architecture
AArchitecture
Vision
TOGAF is a trademark of The Open Group
TOGAF core elements of version 9.1 (2)
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 20
The structure of TOGAF 9.1 is organized along the structure and content of an Enterprise Architecture Capability.
This part includes necessary taxonomy and toolsusable for classifying and storing enterprise architecting results within organizations.
Part V:Enterprise Continuum and Tools
A selection of reference models, i. a. the TOGAF Technical Reference Model (TRM), and the Integrated Information Infrastructure Reference Model (III-RM).
Part VI:TOGAF Reference Models
For implementing and operating the architecture function of an enterprise necessary organization, processes, skills, rolls and responsibilities.
Part VII:Architecture Capability Framework
Business Capability for Architecture (Operating at a level of maturity)
Governance Bodies
Business Operations
Architecture Repository
Enterprise Continuum (used to classify inputs to and outputs from the Repository)
Project/Portfolio Governance
Projects/Portfolios
Contract
Skilled Resource Pool
Training
Architecture Professionals
Skills KnowledgeSkills Knowledge
Improves
Possess
Improves
Possess
Requires
Assigned
Roles and Responsibilities (both generic and
specific to a particular project)Requires
Project Portfolios governed
against their contracts
Population the Repository
Re-using building blocks and
complying with standards
Setting priority and focus Measuring success
Setti
ng
prio
rity
and
focu
s
Del
iver
ing
alig
ned
solu
tions
Parti
cipa
te in
Parti
cipa
te in
Enterprise Repositories(including Requirements
Repository,
Architecture Repository, Design
Stores and CMDB)
The Enterprise Continuum provides
structure and classification for assets in Enterprise Repositories.
Enterprise Repositories provide resources to be
classified within the Enterprise Continuum.
Enterprise Continuum
Architecture Context and Requirements
Deployed Solutions
Architecture Continuum
Generic Architectures
Specific Architectures
Generalization for future re-use
Adaption for use
Solutions Continuum
Generic Solutions
Specific Solutions
Generalization for future re-use
Adaption for use
External factors provide context
Contextual factors shape architectures
Solutions are instantiated within a deployment
Deployed solutions become Architecture Context
Guides and supports
Guides and supports
Guides and supports
Guides and supports
Enterprise Repositories(including Requirements
Repository,
Architecture Repository, Design
Stores and CMDB)
The Enterprise Continuum provides
structure and classification for assets in Enterprise Repositories.
Enterprise Repositories provide resources to be
classified within the Enterprise Continuum.
Enterprise Continuum
Architecture Context and Requirements
Deployed Solutions
Architecture Continuum
Generic Architectures
Specific Architectures
Generalization for future re-use
Adaption for use
Architecture Continuum
Generic Architectures
Specific Architectures
Generalization for future re-use
Adaption for use
Generic Architectures
Specific Architectures
Generalization for future re-use
Adaption for use
Generalization for future re-use
Adaption for use
Solutions Continuum
Generic Solutions
Specific Solutions
Generalization for future re-use
Adaption for use
Solutions Continuum
Generic Solutions
Specific Solutions
Generalization for future re-use
Adaption for use
Generalization for future re-use
Adaption for use
External factors provide context
Contextual factors shape architectures
Solutions are instantiated within a deployment
Deployed solutions become Architecture Context
Guides and supports
Guides and supports
Guides and supports
Guides and supports
Applications
Communication Infrastructure
Application Platform Interface
Communication Infrastructure Interface
Diversity
Application Platform
TOGAF is a trademark of The Open Group
TOGAF Architecture Development Method (ADM)
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 21
Remark: Every phase is validated against and validates the current requirements of the businessIteration is possible.
§ An iterative method, over the whole process, between phases and within phases
§ Each iteration = new decisions:• Enterprise coverage• Level of detail• Time horizon• Architecture asset re-use:
previous ADM iterationsother frameworks, systemmodels, industry models,…
§ Decisions based on:• Competence / resource availability• Value accruing to the enterprise.
Preliminary Phase
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 22
§ This phase prepares the organization for undertaking successful EA projects
• Understand business environment
• High level management commitment
• Agreement on scope• Establish principles• Establish governance structure• Agree on method to be adopted
Phase A – Architecture Vision
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 23
§ Initiates one iteration of the architecture process§ Sets scope, constraints,
expectations§ Required at the start of every
architecture cycle§ Creates the Architecture Vision§ Validates business context§ Creates Statement of Architecture
work
Phase B – Business Architecture
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 24
§ Describe current business architecture
§ Develop target business architecture§ Perform gap analysis§ Define roadmap for transforming the
business architecture§ Select and adapt relevant
architecture viewpoints§ Create architecture definition
document
Phase C – Information Systems Architecture
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 25
§ This phase is detailed in data architecture and application architecture§ Describe current
data/application architecture§ Develop target data/application
architecture§ Perform gap analysis§ Define roadmap for transforming
the data/application architecture§ Select and adapt relevant
architecture viewpoints§ Create architecture definition
document
Phase D – Technology Architectures
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 26
§ Describe current technology architecture
§ Develop target technology architecture
§ Perform gap analysis§ Define roadmap for transforming the
technology architecture§ Select and adapt relevant
architecture viewpoints§ Create architecture definition
document
Phase E – Opportunities and Solutions
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 27
§ Analyze existing culture of the enterprise
§ Consolidate gaps identified in phases B to D
§ Perform initial implementation planning (including dependencies)
§ Identify the major implementation projects
§ Group projects into Transition Architectures
§ Decide on approach• Make v Buy v Re-Use• Outsource• COTS• Open Source
§ Assess priorities
Phase F – Migration Planning
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 28
§ For projects identified in Phase E perform
• Cost/benefit analysis• Risk assessment
§ Develop a detailed Implementation and Migration Plan (roadmap)
Phase G – Implementation Governance
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 29
§ Provide architectural oversight for the implementation.
§ Defines architecture constraints on implementation projects
§ Architecture contract§ Monitors implementation work for
conformance § Realize EA compliance reviews§ Produce a Business Value
Realization.
Phase H – Architecture Change Management
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 30
§ Provide a continual monitoring and a change management process
§ Ensures that changes to the architecture are managed in a cohesive and architected way
§ Establishes and supports the EA to provide flexibility to evolve rapidly in response to changes in the technology or business environment
§ Monitors the business and capacity management.
§ Management of the governance structures (quality gates)
The TOGAF Architecture Content Framework provides an overview of possible information model elements.
Business Architecture Information Systems Architecture Technology Architecture
Architecture Realization
Architecture Principles, Vision and Requirements
Opportunities, Solutions and Migration Planning
Capabilities Work Packages Architecture Contracts
Implementation Governance
Standards Guidelines Specifications
Preliminary
Architecture Principles
Architecture Requirements
Architecture Vision
Business Strategy Technology Strategy Business Principles, Objectives and Drivers Architecture Vision Stakeholders
Requirements Constraints Assumptions Gaps
Organization
Function
Motivation
Organization Actor, RoleLocation
Drivers ObjectivesGoals Measures
Business Services, Contracts, Service
QualitiesFunctionsProcesses, Events, Controls, Products
Data Application
Data Entities
Physical Data Components
Logical Data Components
Information System Services
Physical Application
Components
Logical Application Components
Platform Services
Physical Technology
Components
Logical Technology
Components
TOGAF is a trademark of The Open Group 31© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 31
Pro§ Pervasive in practice
§ Trainings available
§ Certificates available
§ Compliant tools available
§ Internationally accepted
§ Open development
Contra§ Inconsistencies between parts
§ Adaptation necessary
§ Learning TOGAF ≠ mastering TOGAF
§ Lack of concrete guidelines for introducing TOGAF
§ Lean EAM countermovement
TOGAF bottom line
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 32
§ Research project between 2002 and 2004§ Funded by 4 million €
§ Motivation§ Increasing need for precise documentation on the enterprise architecture
level§ Communicating about architecture with others§ Analysis of architectures before their implementation
§ Since 2009, ArchiMate is an Open Group standard and complements TOGAF
ArchiMate‘s historical origin
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 33
Behavior
verbs
Passive Structureobjects
Active Structuresubjects
ArchiMate‘s layers and aspects
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 34
ArchiMate‘s layers and aspects (in detail)
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 35
ArchiMate‘s generic structure
Akin concepts at all layers facilitate learning the language and make its use more consistent:
BehaviorPassive structure
Active structure
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 36
[4]
ArchiMate‘s core concepts
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 37
[5]
ArchiMate‘s layered architecture (example)
Business Layer
ApplicationLayer
Technology Layer
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 38
[9]
ArchiMate‘s integration with TOGAF
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 39
ArchiMate‘s extensions mapped to TOGAF
BusinessLayer
ApplicationLayer
TechnologyLayer
Implementation&Migration
PassiveStructure Behavior
ActiveStructure
ArchiMate‘s core supports these phases:§ B, C, D
Implementation & migration extension:§ E, F, G
Motivation extension§ H, Preliminary, Requirements Management
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 40
ArchiMate‘s motivation extension
Different kinds of relationships:§ Association relation§ Realization relation§ Aggregation relation§ Specialization relation§ Contribution relation (+/-)§ Conflict relation
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 41
ArchiMate‘s migration and implementation extension
Different kinds of relationships:§ Specialization relation§ Composition relation § Aggregation relation§ Assignment relation§ Triggering relation§ Access relation§ Association relation
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 42
[10]
Relationship between the ArchiMate core and its extensions
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 43
Iteraplan “best practice” enterprise architecture modeling concepts and their relationships
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 44
www.iteraplan.de
Recently introduced concepts
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 45
Marc Lankhorst (2014): Enterprise Portfolio Management, Presentation Insight 2014.
Pro§ Predefined meta-model
§ Specific notation
§ Aligned with other frameworks (e.g. TOGAF)
§ Easier start of modeling due to existing concepts
§ Comprehensive documentation
§ Publicly available
Contra§ Maybe not prevalent in a specific
region (e.g. Germany)
§ Training necessary for every modeler
§ Limited extensibility
§ Terminology mapping required
Using domain-specific modeling languages
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 46
Discussion
1. Which EA frameworks are used in your company? 2. What are expected and realized benefits?
© sebis160629 Matthes Useful EAM-Standards and Best-Practice Frameworks 47
Technische Universität MünchenDepartment of InformaticsChair of Software Engineering for Business Information Systems
Boltzmannstraße 385748 Garching bei München
Tel +49.89.289.Fax +49.89.289.17136
wwwmatthes.in.tum.de
Florian MatthesProf.Dr.rer.nat.
17132
matthes@in.tum.de
Thank you for your attention. Questions?