160629 Matthes Useful EAM-Standards and Best-Practice ......cimosa 1999 aris 1991 aris 7.1 2008 jta 1.0 1996 jta 7.0 2005 tafim 1.3 1992 tafim 2.0 1994 tafim 3.0 1996 tafim 2000 dod

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


The Zachman Framework for Enterprise Architecture


Level

of

Detail

Zachmann: Analogy to building construction


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


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


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


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


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



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


Business IT



§ 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




§ Business strategy, quality criteria and business architecture are driving the design of the application landscape

Business strategy IT strategy


(Business processes,Business services ,Business objects ,Organisation , etc.)

Requirements

-

Implemen-tation

Business IT

Architecture of theapplication landscape



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


Business

Contextual(Why?)

Conceptual(What?)

Logical(How?)

Physical(With What?)

Business strategy


(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


Inte

grat

ion

plat

form

Evolution

IT strategy


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….)


TOGAF as aBusiness Transformation Framework


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


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 core elements of version 9.1 (1)


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








PreliminaryArchitecture Principles


Architecture VisionBusiness Strategy Technology Strategy Business Principles, Objectives and Drivers Architecture Vision Stakeholders


Organization

Function

Motivation





Data Application

Data Entities




Physical 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 core elements of version 9.1 (2)


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


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





Adaption for use





Adaption for use




Adaption for use


Adaption for use

Solutions Continuum

Generic Solutions

Specific Solutions


Adaption for use

Solutions Continuum

Generic Solutions

Specific Solutions


Adaption for 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 Architecture Development Method (ADM)


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


§ 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


§ 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


§ 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


§ 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


document

Phase D – Technology Architectures


§ Describe current technology architecture

§ Develop target technology architecture

§ Perform gap analysis§ Define roadmap for transforming the

technology architecture§ Select and adapt relevant


document

Phase E – Opportunities and Solutions


§ 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


§ For projects identified in Phase E perform

• Cost/benefit analysis• Risk assessment

§ Develop a detailed Implementation and Migration Plan (roadmap)

Phase G – Implementation Governance


§ 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


§ 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.








Preliminary

Architecture Principles


Architecture Vision

Business Strategy Technology Strategy Business Principles, Objectives and Drivers Architecture Vision Stakeholders


Organization

Function

Motivation





Data Application

Data Entities




Physical 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


§ 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


Behavior

verbs

Passive Structureobjects

Active Structuresubjects

ArchiMate‘s layers and aspects


ArchiMate‘s layers and aspects (in detail)


ArchiMate‘s generic structure

Akin concepts at all layers facilitate learning the language and make its use more consistent:

BehaviorPassive structure

Active structure


[4]

ArchiMate‘s core concepts


[5]

ArchiMate‘s layered architecture (example)

Business Layer

ApplicationLayer

Technology Layer


[9]

ArchiMate‘s integration with TOGAF


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


ArchiMate‘s motivation extension

Different kinds of relationships:§ Association relation§ Realization relation§ Aggregation relation§ Specialization relation§ Contribution relation (+/-)§ Conflict relation


ArchiMate‘s migration and implementation extension

Different kinds of relationships:§ Specialization relation§ Composition relation § Aggregation relation§ Assignment relation§ Triggering relation§ Access relation§ Association relation


[10]

Relationship between the ArchiMate core and its extensions


Iteraplan “best practice” enterprise architecture modeling concepts and their relationships


www.iteraplan.de

Recently introduced concepts


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


Discussion

1. Which EA frameworks are used in your company? 2. What are expected and realized benefits?


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

[email protected]

Thank you for your attention. Questions?

160629 Matthes Useful EAM-Standards and Best-Practice ......cimosa 1999 aris 1991 aris 7.1 2008 jta 1.0 1996 jta 7.0 2005 tafim 1.3 1992 tafim 2.0 1994 tafim 3.0 1996 tafim 2000 dod

Documents