system cartography & eam best practices...• challenges for eam • beams – situational ea...

© 2007 – 2014 Sabine Buckl & Wolfgang W. Keller - all rights reserved 0

System Cartography & EAM Best Practices

From application landscape maps towards

situational EA management


Agenda and learning objectives of this unit

• Agenda • Software and system cartography • Architectural descriptions – the ISO Std. 42010 • Challenges for EAM • BEAMS – Situational EA management

• At the end of this lecture you

• know the basics of software cartography and software maps • understand how software maps can be used to document architectures • can apply a standardized terminology for architectural descriptions

• understand the challenges arising in the context of managing complex

application landscapes and enterprise architectures (EA)

• know how to apply EAM best practices to typical EA-related problems

• explain the meaning of the terms current, planned, and target state of an

EA


Today’s application landscapes consist of

102 -103 networked information systems

• Complexity ~ number of relationships

• IT agility does not keep pace with the increasing dynamicity of the business

• Number of services >> number of applications

(smaller granularity + versioning)

• Extended enterprise: Coalitions, mergers, carve-outs, …


Application landscape city

• Shared characteristics

• networked system of semi-autonomous systems

• alive, mostly growing, unbounded lifetime

• people are key elements of the system

• created and managed by people

• to be financed by people

• a long-term balance of interests has to be achieved

• a holistic and long-term perspective is required (as-is, plan, to-be)

• heterogeneity: managed core & evolutionary periphery

• Challenges specific to application landscapes

• documentation of ownerships and derived rights and obligations

• system benefit vs. individual benefits value & utility functions

• shared vocabulary for communication holistic view

• problem-specific abstractions to master

the inherent complexity diagrams and views


Problems in managing application landscapes

• IT is covered by fog

• Business and management complain low transparency regarding costs

and benefit of IT

• IT projects start with analysis of related systems and their interfaces

• Recurring surveys to collect information

• Lack of interest of business and management

• “IT is not understandable and unnecessary complex”

• Strategic business goals are not concretized (e.g. „capability maps“)

• Responsibilities are unclear

• No lasting documentation of the owners of processes, applications,

interfaces, services and domains

• Rights and responsibilities for IT and business are not obligatory

derived.


A helpful analogy:

Urban planning and management

City Major

Urban Planner

Merchants

Young Families


Maps are established means for communication

City Major

Urban Planner

Merchants

Young Families


Drawing from different sources

Strategic Process Mgmt

Business Analysis

2012

Strategic IT Mgmt

2013

EA Management

2011

Strategic IT Mgmt

2009

Strategic IT Mgmt

2010

EAM Tool Survey

2005

EAM Tool Survey

2008

EAM Trends Survey

2011

First Release

2004

iteraplan 2.0

2008

iteraplan 2.9

2011

iteraplan 3.0

2012

LeanIT42 3.4

2014

Building Blocks

for EAM Solutions

2011

EAM Pattern

Catalog

2008

EAM Pattern

Catalog Wiki

2009


• Software and system cartography

• Architectural descriptions – the ISO Std. 42010

• Challenges for EAM

• BEAMS – Situational EA management

Agenda


Software cartography

• Software cartography provides models and methods for describing, evaluating and designing application landscapes.

• Models in software cartography – Software maps as graphical models of application

landscapes – Software maps enable automatic generation and

maintenance of software maps – Focus is on modeling, not painting! – Visualizations in accordance with interests of the

stakeholders – Methods in software cartography

• Documentation of application landscapes with software maps – Evaluation of application landscapes with metrics and

visualization of these metrics and software maps – Modeling of application landscapes with the help of software

maps


Consolidating existing software maps found in

practice

• Numerous interviews with various stakeholders

• Mostly time-consuming, manually created maps

Giro

System

Credit

System

ConFi

System

BoSha

System

CRM

System

Customer

DB

Gesellschaft 1

Leitungsbereich 1.1 Leitungsbereich 1.2

Leitungsbereich 1.3

Sparte 1.1.1

Sparte 1.1.2

Sparte 1.2.1

Sparte 1.3.1 Sparte 1.3.2

AS

1.1.2.1

AS

1.1.2.2

AS

1.1.1.1

AS

1.1.1.2

AS

1.1.1.4

AS

1.1.1.3

AS

1.3.2.2

AS

1.3.1.3

AS

1.3.1.1

AS

1.2.1.1

AS

1.2.1.2

AS

1.2.1.3

AS

1.2.1.4

AS

1.2.1.5

AS

1.1.1.5

AS

1.1.2.3

AS

1.3.1.2

AS

1.3.2.1

AS

1.2.1.6

AS

1.3.1.4

Leitungsbereich 1.1 Leitungsbereich 1.2

Leitungsbereich 1.3

Sparte 1.1.1

Sparte 1.1.2

Sparte 1.2.1

Sparte 1.3.1 Sparte 1.3.2

AS

1.3.1.3

AS

1.3.1.2

AS

1.3.1.1

AS

1.3.1.4

AS

1.1.1.1

AS

1.1.1.2

AS

1.1.1.3

AS

1.1.1.4

AS

1.1.1.5

AS

1.1.2.1

AS

1.1.2.2

AS

1.1.2.3

AS

1.2.1.1

AS

1.2.1.2

AS

1.2.1.3

AS

1.2.1.5

AS

1.2.1.6

AS

1.3.1.2

AS

1.3.2.1

AS

1.3.2.2

AS

1.2.1.4

Acquisition Distribution

Online Shop

(100)

Warehousing

Inventory Control System (200)

Product Shipment

System (Germany)

(400)

Campaign

Management

System (1500)Customer Complaint

System

(1900)

Headquarter

Subsidiary

Munich

Subsidiary

Hamburg

Subsidiary

London

Warehouse

Customer Relationship

Management System

(2100)

Inventory Control System (200)

Map Symbols & Visual Variables Visualization Rules

Legend

Monetary Transactions

System (300)

Monetary Transactions System

(300)POS System

Price Tag Printing

System

A Business process A

Business application system A with

id 1 and status unmodifiedA (1)

A (1)Business application system A with

id 1 and status modified

A Organizational unit AP1

O1

O2

A (1)

P2

full x specific

intersection

A (1) supports P1 at O1

full y specific

intersection

P1

O1

O2

A (1)

P2

full x specific

intersection

A (1) supports P1 and P2 at O1

full y specific

intersection

P1

O1

O2

A (1)

P2

full x specific

intersection

A (1) supports P1 at O1 and O2

full y specific

intersection

P1

O1

O2

A (1)

P2

full x specific

intersection

A (1) supports P1 and P2 at O1 and O2

full y specific

intersection

Creation Date: 2006-12-31Target Landscape SoCaStore

P1 P2

P1 is a predecessor of P2

x-sequence

Contact: EA-Group


Examples for application landscapes (1)

• Multinational insurance company

• ~160 applications (location Munich, worldwide usage)

[Wi07]



• Insurance company

• ~150 applications (location Germany,

functionally used)

[Wi07]



• Logistics service provider

• ~150 applications (one company division)

[Wi07]



• Automobile manufacturer

• ~2500-3000 applications (worldwide)

[Wi07]


Principles of software maps illustrated by example

SupportBusiness Areas

Access Channels Business AdministrationCustomer Management

Giro Construction Financing Credit Bonds&Shares

Giro

System

Credit

System

ConFi

System

Clearing&Settlement

ClearingSettlement

Internet Branch

Credit4

Banker

Cash4

Cashier

Call Center

CallCenter

System

BoSha

System

Customer Relationship

Management

Customer

DB

FI/CO

CO

System

FI System

HR

HR

System

Data Warehouse

DW

System

CRM

System

Back Office

Document

DMS

www.

myBank.

com

banking.

myBank.

com

brokerage.

myBank.

com

52%

30% 8%

10%

52%

30% 8%

10%

52%

30% 8%

10%

20%30%

20%30%

52%

30% 8%

10%

20%30%

20% 30%

20%30%

20%30%

20%30%

20% 30%

70%

30%

70%

30%

50%

30%20%

50%

30%20%

50%

30% 20%

10%

40%

25% 25%

40%10%

30%30%

40%10%

30%30%

52%

30% 8%

10%

40%10%

30%30%40%

10%

30%

30%

information flows

key performance indicators

base map

business

applications

The layering principle

• Problem-specific map type (base map)

• Rule-based layout of visual elements

• Hide / show details based on layers

[Wi07]


Relevant information for software cartography

• Central subject of research: (business) applications systems and their

environment

• Classification of relevant information

– Functional:

Organizational units, business processes, functions, business

services, …

– Plan and strategic aspects:

Strategies, targets, projects, applications, …

Lifecycles, versions, …

– Economical:

Running costs, maintenance costs, investments, …

– Technical:

Interfaces, programming languages, middleware systems, software

architectures, …

– Operative:

uptime/downtime of systems, dependencies, (geographic)

locations,…


Information visualization on software maps (1)


Information visualization on software maps (2)

0 50

AS

1.3.1.4

AS

1.3.1.3

AS

1.1.2.3

Response time in seconds

Online Connector

Offline Connector

Manual Connector

Availability per day

> 99,5 % // 99,5 – 99,0 % // <99,0 %Application conforms to

architectural standards

Application does not conform

to architectural standards






Agenda


Scope

• Software-intensive systems

• Individual systems

• „Systems of systems“ (also application landscapes, enterprise architectures)

Goals

• Supports documentation, explanation, and communication of architectures.

• Does not provide a graphical notation nor defines any conformance of systems,

projects, organizations, processes, methods, or tools

• Defines notions in the context of architectural description – how to describe an

architecture

Architecture framework

Predefined set of concerns, stakeholders, viewpoints, and viewpoint

correspondence rules; established to capture common practices for architecture

descriptions within specific domains or user communities

ISO Std 42010: Recommended practice for architectural

description of software-intensive systems


Conceptual model of architectural descriptions

according to the ISO Std 42010

[IS07] Red Adaptations to the ISO Standards, e.g. multiplicities are inserted according to the description in the standard

1..* fulfills

inhabits

influences

has an

provides

participates in

1 described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies 1..*

1..*

important to

has

conforms

1..* selects

1..* used to cover

1..* is addressed to

0..1 has source

1..*

1..*

participates in consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1 1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Notions: System and environment

System

A collection of components organized

to accomplish a specific function or

set of functions.

Software-intensive

Software contributes essential

influences to the design, construction,

deployment, and evolution of the

system as a whole.

Environment

Environment or context, which exerts influence on a system’s design. This comprises

also other systems interacting with the latter one. The environment determines

settings and circumstances of developmental, operational, political, and other

influences upon that system.

Delimitation between the system and its environment

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Example: Apple’s iTunes store

• System

– iTunes Store Server

– …

• Environment

– client-PCs of the customer

– …


Notions: Architecture and architectural

description

Architectural description

Collection of products to document an architecture.

An architectural description selects one or more viewpoints for use. The selection

viewpoints typically will be based on consideration of the stakeholders to whom the

architectural description is addressed and their concerns.

Every system has an architecture, whether understood or not;

whether recorded or conceptual.

Architecture

Fundamental organization of a

system embodied in its components,

their relationships to each other, and

to the environment, and the

principles guiding its design and

evolution.

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Notions: Concern, stakeholder, and mission

Concern

Those stakeholders’ interests,

which pertain to the development,

operation, or other key characteristics

of the system (e.g., performance, reliability,

security, evolvability, distribution, …)

Mission

Use or operation for which a system is intended by one or more stakeholders to

meet some set of objectives.

The architectural description has to be aligned with the stakeholders‘

concerns.

Stakeholder

Individual, team, or organization

(or collections thereof) with

interests in, or concerns relative

to, a system.

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Example: Apple’s iTunes store

• Mission

– Profitable sales of music, videos, and

applications by means of an internet platform

– …

• Stakeholder and concerns

– Management of the iTunes store Germany

– Responsible for operating and maintaining the website

– …


Notions: Viewpoint and view

View

Representation of a whole system

from the perspective of a related

set of concerns. Views are the actual

description of the system

Viewpoint

Specification of the conventions for

constructing and using a view. A pattern

or template from which to develop individual views by establishing the purposes

and audience for a view and the techniques for its creation and analysis.

Separation between viewpoint and view

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Notions: Library viewpoint

Library viewpoint:

Viewpoint-definition from

literature.

Reuse of techniques and notations for architectural descriptions in

order to avoid ad-hoc notations for “boxes-and-lines everywhere

viewgraphs”

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Notions: Rationale and model

Rationale

Describes the reasons, leading to the

selection of an architecture as well as

the intention an architect pursues with

his decisions.

Modeling method

Specification of the conventions for

constructing and using a model. The

modeling method determines the language to be used to describe the model.

Model

Represents a certain aspect of an architecture, according to a notation defined

through a viewpoint.

1..* fulfills

inhabits

influences

has an

provides

participates in

1

described by

1..*

organized by

1..*

identifies

has 1..*

1..*

identifies

1..*

1..*

important to

has

conforms

1..*

selects

1..* used to cover


0..1

has source

1..*

1..*

participates in

consists of

1..*

aggregates

1..*

1

1

1

1

1 1

1

1

1

1 *

1

1

1..*

1

1

1

1 1

Mission

Environment

Rationale

Architecture

View

System

Arch. Description

Concern

Stakeholder

Library Viewpoint

Viewpoint

Model

Modeling method

conforms


Example: Apple‘s iTunes store

Rationale – Ease of use for the customer – It shouldn’t be possible for customers to download registered video and music

material without paying it – …

SW-developer

Operator

…

Changeability

…

Hardware requirements

Scalability

System uptime

…

Class diagram

server release 1

Class diagram

server release 2

Deployment-

diagram server

Structural

design

Installations-

view

Stakeholder Concern Viewpoint View Model

Class diagram

client release 1

Structural changes

since the last

release

Initial structure

of the client

Server landscape

http://images.google.de/imgres?imgurl=http://www.securedataservice.de/images/auge_gross.gif&imgrefurl=http://www.securedataservice.de/&h=363&w=600&sz=91&hl=de&start=63&tbnid=vl8CTBGUaprEHM:&tbnh=82&tbnw=135&prev=/images?q=auge&start=54&gbv=2&ndsp=18&svnum=10&hl=de&sa=N

http://images.google.de/imgres?imgurl=http://www.securedataservice.de/images/auge_gross.gif&imgrefurl=http://www.securedataservice.de/&h=363&w=600&sz=91&hl=de&start=63&tbnid=vl8CTBGUaprEHM:&tbnh=82&tbnw=135&prev=/images?q=auge&start=54&gbv=2&ndsp=18&svnum=10&hl=de&sa=N






Agenda

Reality

enact describe

enterprise enterprise

as-is to-be

transform

plan development

Models


From application landscapes to Enterprise

Architectures – a holistic perspective

Fundamental organization of a system [enterprise] embodied in its components,

their relationships to each other, and to the environment, and the principles

guiding its design and evolution. [IS07]

• consists not only of IT but also of business aspects

• can be divided into layers and crosscutting functions

Requirem

ents

& P

roje

cts

Blu

eprints

& S

tandard

s

Business Capabilities

Business & Organization

Business Services

Applications & Information

Infrastructure Services

Infrastructure & Data

Str

ate

gie

s &

Obje

ctive

s

Me

asure

s &

KP

Is


Evolution trajectory of managed evolution

[Mu08]


EAM uses three EA models

• A current (as-is) state of the EA reflects the actual architecture (status

quo) at a given point in time.

• A planned state of the EA is derived from planned and budgeted

projects for transforming the EA until a certain point in time.

• A target (to-be, envisioned) state of the EA describes an ideal state to be

pursued according to the strategies and architectural principles of the

organization.

Current

Plan

Target


Every software map has time-references

planned fortoday 2011-01-01 2011-06-01 2012-01-01

modeled at

2011-01-01

2011-06-01

2012-01-01

today

Current state

of the EA

Planned state

of the EA

Target state

of the EA

Legend

varia

nts

2015-01-01 2015-06-01 2016-01-01

2015-01-01

2015-06-01

2016-01-01


Challenges for EA management – Address the

organizational specificities

EAM Concerns

Organizational Context

EAM Goals

Bid

ire

ctio

nal in

teg

ratio

n w

ith

oth

er

ma

na

ge

me

nt fu

nction

s

Architectural

Principles

Target

Architecture

Planned

Architecture

Current

Architecture


Challenges for EA management – Integration

with other management functions • Example of a mature organization

• All architectural changes are performed through projects. • EA management has to be integrated in the project lifecycle. • EA management has to exchange information with other enterprise-level

management functions

Architecture Management

Multi-Project Management

Portfolio Management Strategy Management

Project Lifecycle

Define

Measure Plan

Measure

Prioritize

& Commit

Implement

Measure

Deploy

& Migrate

Requirements

Management Identify

Measure

Innovation Management

Synchronization Management


Challenges for EA management – Integration

of different information sources Comparison with Data-Warehouse

architecture

Business intelligence for Enterprise

Architectures

Process

Architecture

ARIS,

Embarcadero,

…

EPK,

BPMN

…

Application

Architecture

ADL,

DLS,

UML, …

Rational Software

Architect,

Together,

…

Service

Architecture

(Management)

Mercury Universal

CMDB, Tivoli,

…

ITIL, Cobit

MOF

(Microsoft),

…

Systems and

Assets

Management

Open View,

SMS,

Tivoli,

…

SNMP,

…

Project Planning,

Business

Intelligence

SAP BW,

MS Project,…

Gantt

diagrams,

Cubes, …

Specialized

Architecture

Planning & Modeling

Frameworks,

Methods,

Best Practices

Tools &

Vendors

Enterprise Architecture

Frameworks: Information Model,

Viewpoints, Views, …

Adaptive, alfabet, BoC, Casewise, IDS Scheer,

MEGA, Telelogic, Troux Technolgies, …

Data import & export processing & filtering

[Ma08]






Agenda

EAM Concerns

Organizational Context

EAM Goals

Bid

irectional in

tegra

tion w

ith o

ther

managem

ent

functions

Architectural

Principles

Target

Architecture

Planned

Architecture

Current

Architecture


How to start?

• Various EAM frameworks exist, but distribution in practice is limited because of either

reasons

• too abstract for practical utilization (e.g. Zachmann)

• too extensive for practical utilization (e.g. TOGAF)

• usually a “complete or nothing” approach

• limited adaptability of frameworks to company needs

• Greenfield approaches

• are usually not based on best

practices

typical errors are repeated

• are usually not adequately

documented

• tend to grow unlimited

1993 1999 1980s 1990 1996 2005 2008

GRAI/GIM 1.0

1992

GERAM 1.6.3

1999

CIMOSA

1984

CIMOSA

1999

TEAF 1.0

2000

ARIS

1991

ARIS 7.1

2008

TAFIM 1.3

1992

TAFIM 2.0

1994

TAFIM

2000

JTA 1.0

1996

JTA 7.0

2005

DoDAF 1.0

2003

C4ISR 2.0

1997

DoDAF 2.0

2009

TISAF 1.0

1997

Zachman

1987

Zachman 2.01

2008

EAP

1992

FEAF 1.1

1999

TOGAF 1

1995

DoD EA TRM 0.04

2005

NIST EA

1989

2002

PERA

1989

PERA

2001

GERAM

1994

C4ISR 1.0

1996

TAFIM 3.0

1996

TOGAF 9

2009

DoDAF 1.5

2007

TOGAF 8.1

2003

FEA 1.0

2001

EAP

1996

IAF v3

2001

E2AF

2003

E2AF 1.5

2006

IAF

1993

IAF 1

1995

IAF 2

1997

IAF 4.0

2007

Zachman

1992

MODAF

2005

NAF 3.0

2007

NAF 2.0

2004

NC3SAF

2000

MODAF 1.2

2008

Legend: Start of

development

Intermediate

version

No further

development

Current

version

influenced

superseded by

2010

sebis EAMPC

2008

sebis EAMPC

Wiki 2009

sebis EAML

2010


A pattern is a general, reusable solution to a

common problem in a given context

Alexander et al. [Al77] (Architecture)

Each pattern describes a problem which occurs over and over again in our

environment, and then describes the core of the solution to that problem, in

such a way that you can use this solution a million times over, without ever

doing it the same way twice. Each pattern is a three-part rule, which

expresses a relation between a certain context, a problem and a solution.

Buschmann et al. [Bu96] (Software Architecture)

A pattern for software architecture describes a particular recurring design

problem that arises in specific design contexts, and presents a well-proven

generic scheme for its solution. The solution scheme is specified by

describing its constituent components, their responsibilities and

relationships, and the ways in which they collaborate.

Gamma et al. [Ga94] (Software Engineering)

Descriptions of communicating objects and classes that are customized to

solve a general design problem in a particular context.


Enterprise architecture management patterns

An enterprise architecture management pattern (EAM pattern) is

• a general, reusable solution to a common problem

• in a given context,

• identifies driving forces,

• known usages and

• consequences.

An EAM pattern takes a holistic perspective:

It address problems at the enterprise (systems of systems) level.

It considers social, technical and economic forces in a balanced manner.

It is discovered in working solutions rather than being invented or hoped for.

It uses a clear, accessible and informal language that allows practitioners to

describe their knowledge and experience.

[Bu08,Er10]


A catalog of interrelated EAM patterns

• Tailor the EAM function to the specific situation (context and problem) of the

enterprise and follow an incremental strategy based on EAM patterns

representing proven practices.

• Systematically document the dependencies between

• methodology patterns (M-Pattern), Which processes and roles are required to address a problem?

• viewpoint patterns (V-Pattern), and

Which viewpoints help stakeholders to collaboratively perform the activities?

• information model patterns (I-Pattern) Which information has to be available to generate a view?

• Draw attention to the consequences implied by a pattern (labor, required

information, political resistance, …)

Process Support

Process Support

Map

Landscape

Planning

Problem

Problem

Problem


Overview of the pattern catalog version 1.0

Basis: literature, experience from sebis research projects,

structured interviews of 25 enterprise architects

Selection based on relevance and adoption by an

extensive online questionnaire

43 concerns, 20 M-Patterns, 53 V-Patterns, and

47 I-Patterns


Selected literature

[Al77] Alexander, C.; Ishikawa, S.; Silverstein, M.: A Pattern Language: Towns, Buildings,

Construction. Oxford University Press, USA, 1977.

[Bu96] Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M.: Pattern-oriented

software architecture: a system of patterns. John Wiley & Sons, Inc., USA, 1996

[Bu08] Buckl, S.; Ernst, A.; Lankes, J.; Matthes, F.: Enterprise Architecture Management Pattern

Catalog (Version 1.0, February 2008). Technical Report TB0801, Technische Universität

München, Chair for Informatics 19 (sebis), 2008.

[Bu11] Buckl, S.; Developing Organization-Specific Enterprise Architecture Management

Functions Using a Method Base PhD Thesis, TU München, 2011.

[Er10] Ernst, A.: A Pattern-based approach to Enterprise Architecture Managemen. PhD thesis,

Technische Universität München, Munich, Germany, 2010.

[Ga94] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. M.: Design Patterns: Elements of

Reusable Object-Oriented Software (Addison-Wesley Professional Computing

Series). Addison-Wesley Professional, 1994.

[Ma08] Matthes, F.; Buckl, S.; Leitel, J.; Schweda, C.: Enterprise Architecture Management Tool

Survey 2008. Technische Universität München, Chair for Informatics 19 (sebis),

München, 2008. 978-3-00-024520-6.

[Wi07] Wittenburg, A.; Softwarekartographie: Modelle und Methoden zur systematischen

Visualisierung von Anwendungslandschaften. PhD thesis, Technische Universität

München, Munich, Germany, 2007.


Fragen?

system cartography & eam best practices...• challenges for eam • beams – situational ea...

Documents