EAM Grundlagen für die Praxis · EAM Grundlagen für die Praxis Prof. Dr. Florian Matthes EAMKON...

Chair of Software Engineering for Business Information Systems (sebis)

Faculty of Informatics

Technische Universität München

wwwmatthes.in.tum.de

EAM Grundlagen für die PraxisProf. Dr. Florian Matthes EAMKON Workshop, Stuttgart, 21. Mai 2019

Zeitplan

10:00 – 11:30 Vorstellungsrunde

Kontext, Ziele und Grundkonzepte des EAM

Neue Herausforderungen durch die Digitalisierung

11:30– 11:45 Kaffeepause

11:45 – 12:45 Verstehen Sie Ihre Rolle als Architekt

Verstehen Sie den Kontext Ihrer Arbeit als Architekt

12:45 – 13:30 Mittagessen

13:30 – 15:30 Verwenden Sie Business Capabilities als Grundlage für die strategische Planung

Nutzen Sie bewährte Bausteine und Muster, die zu Ihrem Unternehmen passen

15:30 – 16:00 Kaffeepause

16:00 – 17:30 Etablieren Sie ein agiles, schlankes und kollaboratives EAM

Taktiken für die erfolgreiche Zusammenarbeit in Agilen IT Organisationen

17:30 Ende der Veranstaltung

© sebis190521 Matthes EAM Grundlagen für die Praxis 2

Research background


more>

System cartography

EAM pattern catalog

Business capability modeling

Capability models in M&A

Building blocks for EAM

Agile EAM

Architecture metrics

Complexity metrics

Cloud & big data adoption

(EAM) patterns for agile IT

organizations

User-centered social software

Adaptive case management

platform

TUM living lab connected

mobility

Blockchain-based systems

engineering

CoreMedia AG (Hamburg, 1996)

infoAsset AG (München, 1999)

Noumena Digital (CH, 2018)

Tr8cy Ltd. (UK, 2019)

UnternehmerTUM

Enterprise Architecture

ManagementPlatforms & Ecosystems High-Tech Spin-Offs

https://wwwmatthes.in.tum.de/pages/1ikp2ty2hao59/Research

Education experience


Master Course Business Informatics

Strategic IT Management and EAM

Euro CIO Professional Programme

Business and Enterprise Architecture

EAMKON Conferences & Workshops

User Group Architekturmanagement

EAM Grundlagen für die Praxis

GI Arbeitskreis Unternehmensarchitektur, Fachgruppe

Architekturen, Fachbereich Software Engineering

EAM Teaching & Training

Project partners since 2005

Enterprises


Deutsche Börse Systems

http://www.rwe.com/generator.aspx/language=de/id=450/home.html

http://de.wikipedia.org/wiki/Datei:Versicherungskammer_Bayern_logo.svg

Project partners since 2005


Consultants

Software vendors

Start-ups

http://www.cirquent.de/de/de/index.html

Vorstellungsrunde

(kurz)

7

Context, goals and

basic concepts of EAM

8

Humans: Employees, Customers, Suppliers, Partners, Markets, Communities, …

Laws & Regulations

Other Resources: Energy, Matter, Information, Technology…

Enterprise

Enterprises have to adapt their business capabilities to an increasingly

turbulent environment.


Business Capabilities

Information Management Capabilities

SCM

Vision, Goals, Strategy

Procurement SalesLogistics

Holistic

Optimization

ERP CRM

Agile

Transformation

Accelerating

ChangesDisruptive

Changes

10

Accelerating speed of change

Source: McKinsey Global Institute, 2014

0,5

0,75

1

3

3

13

38

0 5 10 15 20 25 30 35 40

Instagram

Twitter

Facebook

iPhone

Internet

TV

Radio

Years

190521 Matthes EAM Grundlagen für die Praxis

Time to reach 50 million users worldwide (in years)

© sebis

Application landscape complexity


• 102 – 103 networked and highly diverse information systems

• Complexity ~ number of relationships between systems

• IT does not keep pace with accelerating speed of business

• Maintenance costs eat up IT budget and limit ability to transform

Challenges managing application landscapes

IT lies in dense fog

Business and management criticize low cost/benefit transparency of IT

Each IT project starts with an analysis of systems and interfaces

Repeated Excel-surveys regarding security, compliance, …

Lack of interest on the part of business and management

No familiarization with terms and notions of IT

No explication of business strategies and goals (e.g. capability maps, KPIs)

Unclear responsibilities

No sustainable documentation of process-, application-, interface-, service- and domain-ownership

No binding rights & obligations for IT and business

Agility of IT doesn’t keep pace with the increasing business dynamics


Software projects provide functionality and affect the IT platform efficiency.


Pla

tform

effic

iency

Platform functionality

Initial state

∆ Efficiency

∆ Functionality

Platform replacement

?

Target state

Source: Stephan Murer, Credit Suisse 2007

Managed evolution balances efficiency and functionality.


Pla

tform

effic

iency

Platform functionality

Initial state

Target state

Murer S., Worms C., Furrer F.: Managed Evolution. In: Informatik-Spektrum, Vol. 31, No. 6., 2008.

Understanding and managing system complexity


(~number, variety and dynamicity of elements and their dependencies)

Business Architecture Management

IT Architecture Management

Rutz, U. (2012): IT Complexity Management @ Commerzbank. Presentation at EAMKON Conference, Stuttgart, April 2012.

Differentiate between necessary and unnecessary complexity.

Align the IT architecture with the future business architecture.

A coherent transformation requires a coordinated set IT projects.

Business Architecture

What is an enterprise architecture?


Common language for business and IT

Technical, social, economic and legal aspects

Layers and crosscutting concerns

Static and dynamic relationships more important than element details

Current, planned and target architecture

Str

ate

gie

s &

Pro

jects

Princip

les &

Sta

ndard

s


Organization & Processes

Business Services

Applications & Databases

Infrastructure Services

Infrastructure Elements

Vis

ions &

Goals

Questions &

KP

Is

Legal A

spects

Security

BEAMS , EAM Pattern Catalog and EAM KPI Catalog

https://wwwmatthes.in.tum.de/pages/ste22z023rd3/BEAMS

https://wwwmatthes.in.tum.de/pages/3b4t6l34g936/EAM-Pattern-Catalog

https://wwwmatthes.in.tum.de/pages/19kw70p0u5vwv/EAM-KPI-Catalog

EAM uses more than one EA model

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.

[Past states of the EA]


Current

Plan

Target

An enterprise architecture has to be visualized to make it accessible to

different stakeholders.


EAVIST 2014 and EAM Pattern Catalog

https://wwwmatthes.in.tum.de/pages/6u8f5ki1t2yz/EAVIST-2014-Enterprise-Architecture-Visualization-Tool-Survey

https://wwwmatthes.in.tum.de/pages/3b4t6l34g936/EAM-Pattern-Catalog

The architecture model should focus on the current stakeholders and their

information demands.


StakeholderConcern

(Info Demand)

Viewpoint

ViewModel

Board of

directorsStrategic relevance

of Capabilities

Candidate Strategic

Relevance

Capability Map

?

CIOBusiness / IT

AlignmentBusiness Support

Map

Business

Architecture Model

?

Example Merger & Acquisitions

Example IT Landscape Management

Principle

Example 1: Using a business capability map to communicate business goals.


Sales and Service

Product and Service Processing

Bank Support

Business Management and

Planning

Savings and

Investment

Marketing and Intelligence

Corporate

CommunicationsHuman Resources SecurityICT Management Facility Management

Bank

Marketing

Partner

Intelligence

Product and Service

Procurement

Internal

Demand

Third-party

Products

Utility Services

Product and Services

Design and Marketing

Product/

Service Design

Third-party

Research

Product

Marketing

Strategic

Planning

Regulatory

Compliance

Bank

Governance

Cash and

Liquidity Mgmt.

Market

Intelligence

Customer

Intelligence

Utility Service DeliveryInternal Product

Processing

Third-party Product

Processing

Value-rich Service

Delivery

Customer Portfolio

Management

Customer Relationship

Management

Business Partner

Management

Customer Advice

(non-fee services)

Product and Service

Sales

ReportingCollaboration AccountingArchiving and

Document Mgmt.Risk Management

Financial

Management

Capability

Capability

Capability High strategic relevance

Medium strategic relevance

Low strategic relevance

Example 2: A business support map relates BA architecture elements with IT

architecture elements.


Example 3: A business support migration roadmap plan visualizes important

transformation events in the life-cycle of a business application.

22© sebis190521 Matthes EAM Grundlagen für die Praxis

Example 4: An infrastructure management cluster map visualizes the used

database, location of the application, and the status of the component.

23© sebis190521 Matthes EAM Grundlagen für die Praxis

Architecture management has to be integrated with other

management functions.

Architectural changes are performed through a coherent set of projects.


Architecture Management

Multi-Project Management

Project Portfolio ManagementStrategy Management

Agile Project & Product Management

Define

MeasurePlan

Measure

Prioritize

& Commit

Implement

Measure

Deploy

& Migrate

Requirements

ManagementIdentify

Measure

Application Lifecycle Management

Innovation Management

Example of a mature IT organization

Enterprise architecture management


Influence factors, activities and artifacts

EAM Questions

Organizational Context

EAM Goals

Maturity of other (IT) management functions

Architectural

Principles

Target

Architecture

Planned

Architecture

Current

Architecture

Enterprise Context

Influence factorschanging over time

More >

https://wwwmatthes.in.tum.de/pages/znw2ffp1fkhj/Pattern-based-Design-Research-in-Enterprise-Architecture-Management

Core concepts of EAM


Top management

Business

stakeholders

Software

development

IT operations

Project managers

Software architects

Software developers

Top management

Strategy office Views

Business owners

Application owners

IT operations

Metrics

Reportsreflect

adapt EA Team

model

describe

The EA team uses methods & models to address concerns of stakeholders by using specific views.

New challenges through

digitalization

27

From products to services


Customers buy less physical

products that need to be

transported, stored,

maintained and disposed of.

Customers prefer digital

services they need to pay only

on demand.

From products to services


Thomas Kaeser: „Der Kunde kauft keine Kompressoren oder

Druckluft-Anlagen, sondern lediglich Druckluft als Dienstleistung.“

Results-oriented control & management


Digital devices enable companies to create new forms of controlling their own business.

Sale of products Achieve measurable results for individual customers

Book My reading habits (Kindle)

CD My music preferences (Spotify)

Car My orders (Sixt), my driving behaviour

Fire detector My risk profile as a tenant

… …

The Outcome Economy shifts the focus from selling things to selling results.

Accenture, Technology Vision 2015

Customer-centric business networks

190521 Matthes EAM Grundlagen für die Praxis 31

Example: Integration of digital mobility services

My fleet, my data, my app, my

users, ...

Example: Car2Go

Seamless customer-centric

integration of all mobility services

Example: Apple cards, calendars,

wallet, Siri, third party apps

Classic mobility service providers

Mobility information service providers

© sebis

From a company-centric design of IT architecture ...


My business processes and my business applications

ERP CRMSCM

© sebis

… to Outside-In Thinking


The IT architecture is based on the (future) skills of partners and customers

Example: Flixbus

© sebis

Customer-centric business networks


Which position do I want to play in the digital ecosystem?

Partner Coordinator

Customer

Partner

Partner

PartnerCoordinator Partner

Partner

Partner Partner

EA models are a good starting point for ecosystem models


Accelerating

Changes

Disruptive

Changes

BMW

MAGNA STEYR

Google

DriveNow

Sixt

(Information) Technology

Markets & Regulations

Digitalization leads to new priorities in the design of

IT application landscapes


Previous requirements

for IT architecture

Requirements of network

organizations

Functionality

Connectivity

Flexibility

Modular, service-oriented application landscape architecture


• Separation of front-end and back-end systems

• Modularization of back-end systems

• Flexible and fault-tolerant coupling via service interfaces

ESB

Back-End

System

Back-End

System

Back-End

System

Internal ESB

Front-End

System

Front-End

System

Customer Partner

Functionality

Connectivity

Flexibility

Flexible digital offerings through digitalized business processes and separation of customer

channel systems


• Separation of internal ESB and external bus based on Internet technologies

• Return channels and powerful data analysis systems

• Systems for modelling and managing dynamic service networks

ESB

Back-End

System

Back-End

System

Back-End

System

Internal ESBREST,….PartnerMonitoring

& Analytics

Modeling &

Management

Front-End

System

Front-End

System

Customer Partner

Kaffeepause

15min

39

Zeitplan















Understand your role in

enterprise change

management

41

Implementing architectures is a process of change.


Labyrint IT Strategy Solutions

https://wwwmatthes.in.tum.de/file/1tznzi4mzdkqz/sebis-Intranet/Teaching/SITM/Public/TUM_Teeuwen_color_v01.pdf

Example: DB Mobility Logistics


Example: ABN AMRO


The color theory distinguishes five fundamental approaches to change.




Understand your primary change approach and the change culture of your

enterprise.

Is there a difference between thinking and doing?

Are there different change cultures in parts of your enterprise?

Consider the dominant color of the environment and deliberately choose an appropriate approach to change.




A transformation unit


A transformation network


Understand the influence of

your organization on your

EAM work

50

Enterprise architecture management


Influence factors, activities and artifacts

EAM Questions


EAM Goals


Architectural

Principles

Target

Architecture

Planned

Architecture

Current

Architecture

Enterprise Context


More >


Changes in the enterprise context are often a trigger and driver for EA

initiatives.

Examples

New CIO or CEO

Post-merger integration

Preparation for a carve-out

IT cost-cutting initiative

Market crisis business consolidation

International growth strategy

Changes in legal regulations (Basel II, Solvency, Energy market, …)

Digital transformation of the business

Mobile workforce

Social media

From car manufacturing to mobility services

Industry 4.0

From software vendor to service provider


Your organizational context influences the design of your EAM work.

IT organization Decentralized, centralized or federated

Upper management support Bottom-up initiative

Top-down initiative

Budgeting EAM team has a budget at its disposal for conducting EA-related projects

EAM team has a certain budget at its disposal for supporting projects (e.g. to provide a budget for attaining architectural principles)

EAM team has no budget at its disposal.

Enterprise culture Innovation

Communication

Acceptance of formal models

Interest in performance data

Change management approach


More >


Your EAM goal(s) should fit the enterprise context

Increase coherence

Increase strategic alignment of business and IT (two-way)

Provide strategic guidance for IT (one-way)

Increase transparency

Accelerate project execution for new business initiatives

Support multi-project planning and controlling

Support IT and business innovations

Manage and reduce (IT) complexity (redundancy, heterogeneity, size)

Reduce operating costs by standardization

Increase agility by architectural measures

Migration to and consolidation of standard software

Technology blueprints (web-applications, SAP applications, Big data applications)

Portals, service buses, data warehouse, …

Identify, assess and manage security risks

Ensure and document legal compliance

Increase disaster tolerance

Increase top management satisfaction


Typical examples

How does EAM add value to your organization?

EAM Benefits

Organizational alignment (common goals consensus)

Information availability (access, standardized faster & better decisions)

Resource portfolio optimization (no redundancy reduced cost & skill variation)

Resource complementarity (integration, interoperability performance, re-use)

Proxy Measures for Evaluating EA Quality


Tamm et al. (2011) "How Does Enterprise Architecture Add Value to Organisations?," Communications of the Association for Information Systems: Vol. 28.

Appropriate scope-detail-cost balance Intermediate deliverables

Appropriate CIO skills Skilled architecture team

Compatible organizational culture Sufficient (on-going) funding

Clear and agreed-upon arch. principles Suitable management practices

Documentation tools Stakeholder acceptance & involvement

Effective presentations Top management support and involvement

Effective project management Use of consultants

Mittagessen

(bis 13:30)

56

Zeitplan















Most frequent EA challenges

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

1. Ad hoc EAMdemands

2. Unclear businessgoals

3. Hard to findexperienced

enterprise architects

4. EA demandsunclear for EAM

team

5. Enterpriseenvironment

changes too quickly

Agree (%)

Neither (%)

Disagree (%)

n=102

58

Hauder, M., Roth, S., Schulz, C., Matthes, F.: Organizational Factors Influencing Enterprise Architecture Management Challenges, 21st European

Conference on Information Systems (ECIS 2013), Utrecht, Netherland, 2013.

© sebis190521 Matthes EAM Grundlagen für die Praxis

Agile EAM

Business

Capability

MapsAgile EAM

Business

Capability

Maps

Use business capabilities

for strategic planning

59

The classical layers and elements of a business architecture


The classical layers and elements of a business architecture


61

Business Strategy

Business Processes

Business Models

Management

External Demands Strategic Direction The Market Promise Customer Value

Organisation

Skills &CompetenciesNetwork

Goals &Metrics

BusinessPlanning

Cost Profit

SupplyValue

PropositionDemand

Value

Proposition

Profit Income

Q4

Q2

Q1BCQ3

Performancemanagement

Cost Profit

SupplyValue

PropositionDemand

Value

Proposition

Profit Income Cost Profit

SupplyValue

PropositionDemand

Value

Proposition

Profit Income

Organisation

Key

Characteristics

Feelings

EmotionsBenefits

Market Promise

Source: Siamak Amjadi (Nordea), What is Business Architecture? Dansk IT EA 2012, 31/10/2012

These models are too fine-grained

to describe an organization and

change often

These models are too abstract to

describe an organization

Business capabilities are an additional layer for the business architecture

62© sebisSITM & EAM – WS 18/19 – 3.3 Capability-based planning

Business Process

Business Models

Business Strategy

Mission

Vision

OrganizationManagement &

Governance


Business capabilities are an ideal black-box description of the business.

63© sebisSITM & EAM – WS 18/19 – 3.3 Capability-based planning

Business Models

Business Strategy

Mission

Vision


Business capabilities focus on the ‘what’ and not on the ‘how’!

What is a business capability?


A functional building block of the business architecture that supports the business model

and the business strategy. It defines the organization’s capacity to successfully perform

a unique business activity.

Definition

Characteristics

People Dimension: knowledge, skills, and experiences of the enterprise’s staff

Process Dimension: concepts, business processes, and information management

Material Dimension: underlying assets, such as infrastructure, IT, and equipment

Dimensions

Stability

independent from the organizational model, technologies, and vendor solutions

Abstraction

encapsulate and abstract from any explicit resource, business process, or IT

Horizontal Structure

a complete and non-overlapping functional decomposition of the enterprise

Vertical Structure

can be broken down into more granular business capabilities

Business capabilities in context


Business Capability Map

Complete and non-

overlapping view on the

enterprise’s

business capabilities

Business Model

Complete view on

value creation

Key

PartnersKey

Activities

Value

Proposition

Customer

Relationships

Customer

Segments

Key Resources Channels

Cost Structure Revenue Streams

Business Capability

View on one business

capability with its

dimensions and lifecycle

Business

Capability

People Processes Resources

Capability

Increments

Life cycle

Business

Capability

Business

Capability

Business

Capability

Business

Capability

Business

Capability

Business

CapabilityBusiness

Capability

Business

Capability

Use a business capability map to communicate business goals.


Sales and Service


Bank Support


Planning

Savings and

Investment


Corporate


Bank

Marketing

Partner

Intelligence

Product and Service

Procurement

Internal

Demand

Third-party

Products

Utility Services



Product/

Service Design

Third-party

Research

Product

Marketing

Strategic

Planning

Regulatory

Compliance

Bank

Governance

Cash and

Liquidity Mgmt.

Market

Intelligence

Customer

Intelligence


Processing

Third-party Product

Processing

Value-rich Service

Delivery

Customer Portfolio

Management


Management

Business Partner

Management

Customer Advice

(non-fee services)

Product and Service

Sales



Financial

Management

Capability

Capability

Capability High strategic relevance

Medium strategic relevance

Low strategic relevance

Strategic

Relevance Map

SR-Map

Capability

Condition Map

CC-Map

Strategic

Gap Map

SG-Map

Use a business capability map to assess the current capabilities.


Sales and Service


Bank Support


Planning

Savings and

Investment


Corporate


Bank Marketing

Partner

Intelligence

Product and Service

Procurement

Internal

Demand

Third-party

Products

Utility Services



Product/

Service Design

Third-party

Research

Product

Marketing

Strategic

Planning

Regulatory

Compliance

Bank

Governance

Cash and

Liquidity Mgmt.

Market

Intelligence

Customer

Intelligence


Processing

Third-party Product

Processing

Value-rich Service

Delivery

Customer Portfolio

Management


Management

Business Partner

Management

Customer Advice

(non-fee services)

Product and Service

Sales



Financial

Management

Capability

Capability

Capability Advanced condition

Medium condition

Poor condition

Strategic

Relevance Map

SR-Map

Capability

Condition Map

CC-Map

Strategic

Gap Map

SG-Map

Use a business capability map to identify EA demands.


Sales and Service


Bank Support


Planning

Savings and

Investment


Corporate


Bank Marketing

Partner

Intelligence

Product and Service

Procurement

Internal

Demand

Third-party

Products

Utility Services



Product/

Service Design

Third-party

Research

Product

Marketing

Strategic

Planning

Regulatory

Compliance

Bank

Governance

Cash and

Liquidity Mgmt.

Market

Intelligence

Customer

Intelligence


Processing

Third-party Product

Processing

Value-rich Service

Delivery

Customer Portfolio

Management


Management

Business Partner

Management

Customer Advice

(non-fee services)

Product and Service

Sales



Financial

Management

Mobile

Banking

Offer

Options for

additional sales

channels

Online

Services

Online

ServicesCustomer

Database

Enhance Risk

Management

Enhance

Security

Customer

Database

Capability

Capability

Capability Strong gap

Medium gap

Small or no gap

Strategic

Relevance Map

SR-Map

Capability

Condition Map

CC-Map

Strategic

Gap Map

SG-Map

Digital business capabilities


Example: Axel Springer SE (2015)

Example: Business capability map of Novartis


How are business capability maps used in industry (2018)?

The BCM is used more often for strategic

tasks (e.g., target architecture definition)

then for operational tasks (e.g., mapping of

applications, mapping of responsibilities).

No correlation between the strategic or

operational usage and the experience of

an organization with BCMs could be

determined.

2

6

2 2

1

2

4

2

0

1

3

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 n/a

BCM – Years in use Experiences with BCMs vary between one

and ten years

Many participants of the study are just

starting to use the concept of BCMs

Other participants already work with BCMs

for six to eight years – this correlates to the

time, when EAM was introduced as corporate

function.

4

109

0

2

5 5

9

4

2

0

2

4

6

8

10

12

Ja,intensiv

Ja,häufig

Ja,gelegentlich

Nein n/a

BCM – Strategic and operational use

Strategisch Operational

© sebis 71190521 Matthes EAM Grundlagen für die Praxis

Source: Aleatrati Khosroshahi, P. et al.: Business Capability Maps: Current Practices and Use Cases for Enterprise Architecture

Management. 51st Hawaii International Conference on System Science (HICSS), Waikoloa Village, Hawaii, USA, 2018

How are business capability maps used in industry (2018)?

Almost all organizations map applications to the business capability map

Responsibilities, processes, projects, etc. are also mapped to the business capability map

Information - Organizations C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19 C20 C21 C22 C23 C24 C25 Summe

Pre

de

fin

ed

Applications x x x x x x x x x x x x x x x x x x x x x x 22

Responsibilities x x x x x x x x x x x x x x 14

Processes x x x x x x x x x x x x x 13

Projects x x x x x x x x x x x x 12

Costs x x x x x x x x 8

Business objects x x x x x x x x 8

Technologies x x x x x x x x 8

Services x x x x x x x 7

Business Demands x x x x x x 6

User Stories x x x x x 5

As c

om

me

nts

Orte/Regionen x x x 3

Business Funktionen x 1

Support (regional, zentral) x 1

Business Organisationen x 1

Schnittstellen x 1

Strategische Ausrichtung x 1

Capability Priorität x 1

© sebis 72190521 Matthes EAM Grundlagen für die Praxis

Source: Aleatrati Khosroshahi, P. et al.: Business Capability Maps: Current Practices and Use Cases for Enterprise Architecture

Management. 51st Hawaii International Conference on System Science (HICSS), Waikoloa Village, Hawaii, USA, 2018

Process to develop a business capability mapExample: Medium-sized state-owned organization (2018)


Gap Action Recommendation

Gap 1 Action Recommendation 1

Action Recommendation 2







Product Management

Research

Partner Analysis

Production

Procurement

Plant Management

Sales

Market Analysis

Customer Service

Corporate ManagementStrategy

ManagementPortfolio

ManagementPublic Relations

Enterprise ServicesFinance and Accounting

IT ServicesHuman

Resources

Product Management

Research

Partner Analysis

Production

Procurement

Plant Management

Sales

Market Analysis

Customer Service

Corporate ManagementStrategy

ManagementPortfolio

ManagementPublic Relations

Enterprise ServicesFinance and Accounting

IT ServicesHuman

Resources

• Define collaboration mode

• Define time line

• Define roles

• Define expected outcomes

• Create understanding of BCM concept

• Motivate participants

• Prepare BCM draft

• Prepare business capability description

template

• Collect data in expert interviews

• Consolidate collected data

• Moderate group discussion

• Document evolving BCM

• Collect data on strategic relevance

• Collect data on improvement potentials

• Collect information on possible actions

• Consolidate data in strategic relevance

and improvement potential

• Visualize gaps

• Prioritize possible actions

• Present results

BUSINESS CAPABILITY NAME

Person Responsible: Parent Capability:

Description:

Desired Business Outcome:

Capability Dependencies:

Important Decisions:

[Will be completed after the Workshop]

Business

Capability Map &

Business

Capability

Description

Gaps and action

recommendations

Process steps Activities Artifacts

Creation

of BCM

Identification of

actions

Enrichment

of BCM

Workshop

Workshop

Kick-off Workshop

Workshop

Problem Identification

& CS Motivation

IV

I

III

II

Use practice-proven patterns

and building blocks

74

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.

Enterprise architecture management patterns


Core concepts of the EAM pattern catalog


Top management

Business

stakeholders

Software

development

IT operations

Project managers

Software architects

Software developers

Top management

Strategy office Views

Business owners

Application owners

IT operations

Metrics

Reportsreflect

adapt EA Team

model

describe

The EA team uses methods to address concerns of stakeholders by using specific visualizations.

EAM has to be a sustainable management function and not a one-off project

Develop & Describe

Gather information and describe the current state of the EA

Develop long-term vision (target state) of the EA and architectural principles

Design medium-term planned states of the EA

Communicate & Enact

Communicate current state to the different stakeholders

Enact planned states by influencing projects

Enforce architectural principles

Analyze & Evaluate

Assess current state of the EA and identify potentials for improvement

Evaluate different planned states of the EA

Analyze the gaps between the

current state & target state of the EA

planned states & target state of the EA

Configure & Adapt

Measure performance of the EA management function

Adapt the EA management function by reassessing

goals, concerns

environmental influences

…


EAM method building blocks (2012)


BEAMS online method base

https://wwwmatthes.in.tum.de/pages/ste22z023rd3/BEAMS

Influence factors for EAM

© sebis


79

EAM Questions


EAM Goals


Enterprise Context


More >


EAM pattern catalogs


EAM pattern catalog V1.0 (2008)

• 43 Concerns

• 20 M-Patterns

• 53 V-Patterns

• 47 I-Patterns

EAMPCV1.0

EAM pattern catalog V2.0 (2015) –

Extension of EAM pattern catalog V1.0

• Influence Factors

• 12 Stakeholders

• 15 Concerns

• 13 M-Patterns and architecture principles

• 25 V-Patterns

• 43 I-Patterns

• DC-PatternsEAMPCV2.0

https://wwwmatthes.in.tum.de/pages/146i8lzdg690d/EAM-Pattern-Catalog-V1-2008

https://wwwmatthes.in.tum.de/pages/ugsyi19wmmvl/Enterprise-Architecture-Management-Pattern-Catalog-V2-2015

EAM pattern catalog version 1.0 (2008)


Basis: literature, experience from sebis research projects,

structured interviews of 25 enterprise architects

Selection based on relevance and adoption by an

extensive online questionnaire

Stakeholders

Viewpoint patterns

Information model

patterns

Data collection patterns

Vie

ws / A

rtifacts

DC1

C1

?

V2

123

V3

Report

V1

I1 I3

DC2

S3

I2

DC3

C2

?C3

?

S1 S2

Concerns

e.g. CIO

e.g. reduce functional

redundancy

e.g. Business support map

e.g. Business capabilities,

business applications &

business support

e.g. import monthly from CMDB

Method patterns e.g. Management of

Homogeneity, Buy

before makeM1 P1

!

Structure of the EAMPC V2 (2016)


Influence factors

Maturity levels I1 I2 ML1e.g. Regulatory requirements

Architecture principles

Example: pattern for application consolidation


I108I108

M71M71

C157?

C157?

V108V108

S45

DC1DC1

S45



I108I108

M71M71

C157?

C157?

V108V108

S45

DC1DC1

S45

Stakeholder 45: Enterprise Architect

Further: CIO, Domain / Solution Architect, Technical

Architect



I108I108

M71M71

C157?

C157?

V108V108

Concern 157: Detection of

consolidation potentials

S45

DC1DC1

S45



I108I108

M71M71

C157?

C157?

V108V108

M-Pattern 71: Elimination of functional

redundancies and standardization, e.g.

integration platform, architecture blueprints

© sebis

S45

DC1DC1

S45



I108I108

M71M71

C157?

C157?

V108V108© sebis

Organizational Unit 1

Map Symbols Visualization Rules

D (1)

Domain (1)

hosting PC

(1) and (2)

DomainD

C Physical Component


PC(1)

PC(2)


Physical Component

Physical

Component

Physical

Component

Physical Component

Physical

Component

Physical

Component

Physical Component

Physical

Component

Physical Component

Physical

Component

Physical Component

Physical

Component

Physical Component

PC (1)PC (1)

includes Sub-

Component

(1) and (2)

E(1)

E(2)

E Sub-PC

Physical

Component

CPotential for

Consolidation

V-Pattern 108: Consolidation Potentials in clusters

S45

DC1DC1

S45



I108I108

M71M71

C157?

C157?

V108V108© sebis

*

*

Organizational Unit Phyisical Component

hosting

**name: String name: String

consolidate: Boolean*

*includes

I-Pattern 108: Consolidation Potential

S45

DC1DC1

S45



I108I108

M71M71

C157?

C157?

V108V108

S45

DC1DC1

S45

DC-Pattern 1:

Organizational Unit: Enterprise Architect, CSV format, On demand

Physical Component: Enterprise Architect, Technical Architect, CMDB, Daily

Example: pattern for regulatory requirements


I113

M34M34

C179?

C179?

S45

DC2DC2

S45

I113

V113V113



I113

M34M34

C179?

C179?

S45

DC2DC2

S45

Stakeholder 45: COO

Further: Enterprise Architect

I113

V113V113



I113

M34M34

C179?

C179?

M-Pattern 34: Security assessment of the EA

e.g. which applications have confidential data

© sebis

S45

DC2DC2

S45

I113

V113V113



I113

M34M34

C179?

C179?

M-Pattern 34: Security assessment of the EA

e.g. which applications have confidental data

© sebis

S45

DC2DC2

S45

I113

V113

I-Pattern 113:

Regulatory issues

V-Pattern 113: Overview of regulatory issues

Business Capability / Business

Application

POS System

(GermanyMunich)

(1600)

POS System

(GermanyHamburg)

(1620)

POS System (Great

Britian) (1650)

Business Capability 1

Regulatory

Compliance Issues:

23

Regulatory

Compliance Issues:

50

Regulatory

Compliance Issues: 3

Business Capability 2Regulatory


Regulatory

Compliance Issues:

45

Regulatory


Business Capability 3Regulatory


Regulatory

Compliance Issues:

14

Regulatory


Visualization Rules

Less then 10% of

requirements

breached

Less then 40% of

requirements

breached

Over 40% of

requirements

breached

V113



I113

M34M34

C179?

C179?

© sebis

S45

DC2DC2

S45

I113

V113

Business Application Business Capability

1 1

Regulatory Compliance Issues

*

name: String name: String

Amount issues: Integer

I-Pattern 113:

Regulatory issues

V113



I113

M34M34

C179?

C179?

© sebis

S45

DC2DC2

S45

DC-Pattern 2

Business Capability: Business / Domain Architect, CSV, on Demand

Physical Component: Application Owner, On Demand, Event Driven

I113

V113V113

EA Visualization Tool Survey 2014


461 Seiten, englisch

300 Screenshots und Diagramme

266 Tabellen

18 Hersteller- und Toolprofile

26 Visualisierungstypen

zahlreiche Statistiken zur Verwendung

von Visualisierungen

PDF oder gedruckt

Download >

© sebis 97

https://wwwmatthes.in.tum.de/pages/6u8f5ki1t2yz/EAVTS2014-Enterprise-Architecture-Visualization-Tool-Survey

Nutzung von Visualisierungstypen (N=109)


388

1112

1821

2427

2829

3941

4248

5050

5154

6364

7374

778282

0 10 20 30 40 50 60 70 80 90

3D

Sunburst

Tag Cloud

Treemap

Gauges

Business Model Canvas

Geographical Map

Scatter Chart

Line Chart

ArchiMate

EPC Diagram

Kiviat/Spider

Dashboard

Pie Chart

Treeview

Bubble Chart

UML Diagram

BPMN Diagram

Bar Chart

ER Diagram

Graph/Tree

List

Flow Diagram

Timeline

Cluster Map

Matrix

EAVIST 2014

© sebis 99


eam-initiative.orgA wiki-based knowledge community for EAM


EAM foundations are

made available in the

form of wiki articles.

A concept map is

used as navigation

tool

“Start small, think big”

is a basic directive of

the initiative.

The website structure

is guided by a wiki-

approach.

The community is

based on

participation.

The goal of the eam-

initiative.org is the

advancement of the

EAM domain.

http://eam-initiative.org

http://eam-initiative.org/pages/ggx22htadwg4/EAM-Initiative-Home

Kaffeepause

30min

102

Zeitplan















Most frequent EA challenges

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

1. Ad hoc EAMdemands

2. Unclear businessgoals

3. Hard to findexperienced


4. EA demandsunclear for EAM

team

5. Enterpriseenvironment

changes too quickly

Agree (%)

Neither (%)

Disagree (%)

n=102

104

Hauder, M., Roth, S., Schulz, C., Matthes, F.: Organizational Factors Influencing Enterprise Architecture Management Challenges, 21st European

Conference on Information Systems (ECIS 2013), Utrecht, Netherland, 2013.

© sebis190521 Matthes EAM Grundlagen für die Praxis

Agile EAM

Business

Capability

MapsAgile EAM

Business

Capability

Maps


Establish an

agile, lean, and collaborative

EAM

predictable

systems

chaotic

systems

complex dynamic

systems

dynamicity of

the system

environment

complexity of the system structure

high

low high

low

Classification of systems based on their complexity


specialize

& automate

(Taylorism)

experiment

& learn

(MVP)

Agile, collaborative management

(emergent structures)

dynamicity of

the system

environment

high

low high

low

The system management approach has to fit

the system complexity at hand

complexity of the system structure


Agile EA management principles


Individuals and interactions over formal processes and tools

IT Project 3IT Project 2

IT Project 1

Top management

Business

stakeholders

Software

development

IT operations

Project managers

Software architects

Software developers

Top management

Strategy office

Business owners

Application owners

IT operations

Purchasing

EA Team

• Ensure top management

support

• Maintain a good relationship to

people form other

management areas

© sebis



Focus on demands of top stakeholders and speak their languages


IT Project 1

Architecture

blueprints

Top management

Business

stakeholders

Software

development

IT operations

Project managers

Software architects

Software developers

Top management

Strategy office

VisualizationsBusiness owners

Application owners

IT operations

Purchasing

EA Team

Stakeholder-specific

architecture views

Metrics

Reports

Architecture-

approval and

requirements

Architecture

changes

model

collect

motivate

Business

and IT

strategy

Individual

architecture

aspects

Business

and org.

constraints

• A single number or picture is

more helpful than 1000 reports

• Communicate, communicate,

communicate

• Avoid waste

• Benefit form existing model

management processes



Reflect behavior and adapt to changes


IT Project 1

Architecture

blueprints

Top management

Business

stakeholders

Software

development

IT operations

Project managers

Software architects

Software developers

reflect

adapt

Top management

Strategy office

VisualizationsBusiness owners

Application owners

IT operations

Purchasing

EA Team

Stakeholder-specific

architecture views

Metrics

Reports

Architecture-

approval and

requirements

Architecture

changes

model

collect

motivate

Business

and IT

strategy

Individual

architecture

aspects

Business

and org.

constraints

© sebis

• Iterative and Incremental

(one cycle ~12 months)

• Use building blocks and

patterns

• Request 360° feedback

• Adapt models and processes

• Continuous collaboration

Related approaches: Lean management

1. Specify value from the standpoint of the end

customer by product family.

2. Identify all the steps in the value stream for each

product family, eliminating whenever possible

those steps that do not create value.

3. Make the value-creating steps occur in tight

sequence so the product will flow smoothly

toward the customer.

4. As flow is introduced, let customers pull value

from the next upstream activity.

5. Begin the process again and continue it until a

state of perfection is reached in which perfect

value is created with no waste.

1. Specify

customer value

2. Map value

stream

3. Avoid delays

and waste

4. Create flow

through pull

5. Seek perfectio

n


Risk: Over-fitting of EA function to

current demands

Related approaches: Collaborative EAM


Bente, Stefan, Uwe Bombosch, and

Shailendra Langade. Collaborative

Enterprise Architecture: Enriching EA

with Lean, Agile, and Enterprise 2.0

Practices. Newnes, 2012.

…instead of overloading the stakeholders with bureaucratic

processes and unsolicited artifacts

Establish a lean set of processes and rules…Lean

…instead of blueprinting the whole future rigidly on a drawing

board

Adopt evolutionary problem solving…Agile

…instead of relying only on experts and top-down wisdom

Foster and moderate open participation… Enterprise 2.0

© sebis


Challenges of


in large-scale

agile transformation

Multiple case studies of agile EA governance in large IT organizations


Case OrganizationHeadquarter

LocationCompany Size [Employees]

Number ofInterviews

Global Insurance Company Germany 140,000+ 12

Car Manufacturer Germany 130,000+ 20

Information Technology Company Germany 7,000+ 8

Retail Company Germany 50,000+ 20

Public Sector Insurance Company Germany 6,700+ 16

Overview of the observed large-scale agile transformations


Case Organization

Global Insurance Company

Car ManufacturerInformation

Technology CompanyRetail Company

Public Sector Insurance Company

Transformation

Begin Beginning of 2016 Beginning of 2017 Beginning of 2015 End of 2017 Mid of 2016

Applied

Scaling

Frameworks

LeSS

Scaled Scrum

Spotify Model

LeSS

SAFe

Scaled Scrum

LeSS

SAFe

Scaled Scrum

SAFe

Scaled Scrum

Spotify Model

eScrum

Nexus

SAFe

Scaled Scrum

Transformation

Approach

Initially factory

approach with

dedicated co-

locations

Now enterprise

scaling

Top-down driven

by the CIO and

senior executives

Line of business

piloting

Steered by a

central

transformation

team

Piloting with

large projects

Line of business

piloting

Driven by

management

board

Piloting with large

projects

Line of business

piloting

Transformation

Scale

Enterprise-wide

transformation

Enterprise-wide

transformation

Enterprise-wide

transformation

Enterprise-wide

transformation

Enterprise-wide

transformation

Value contribution of enterprise architects has not yet reached agile teams

Main findings

1. Models provided by enterprise architects (EAs)

too abstract, lacking concrete technical guidance

2. Limited EAs’ capacity for individual support

3. Communication mostly via solution/domain

architects

4. Agile teams not included in architectural

development

5. Limited know-how of current technical

architectures

6. No feedback culture, lack of feedback

mechanisms

7. Agile teams least satisfied with current situation


Self-perception and external perception of enterprise architects differ significantly

Uludağ et al. (2019): What to Expect from Enterprise Architects in Large-Scale Agile Development? A Multiple-Case Study

1

2

3

4

5

6

7

8

9

10

Models

Availability

Communication

InvolvementSupport

Feedback

Recommendation

Enterprise Architects Agile Teams Managers

1

2

3

45

6

7

n=25 (13 enterprise architects; 8 agile team members, 4 managers)

Perception of different stakeholder groups

Dissatisfaction of agile teams is reflected by the Net Promoter Score


Recommendation of enterprise architects to agile teams (1-10)

n=25

Uludağ et al. (2019): What to Expect from Enterprise Architects in Large-Scale Agile Development? A Multiple-Case Study

1

10

4

15

3

3

6

4

4

0

5

10

15

20

25

30

Agile Teams (ATs) Enterprise Architects (EAs) Managers (Ms) Total

Promoters (9-10) Passives (7-8) Detractors (1-6)

Recurring challenges with EAM in agile organizations


SUPPORTVALUE CONTRIBUTION

ARCHITECTURE PRINCIPLES ARCHITECTURE BOARDS

Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study

1. Low commitment of agile teams regards

implementing architecture principles due to low

intrinsic motivation or acceptance issues

2. Lack of appropriate tools and (automated)

mechanisms for verifying the compliance of agile

teams with architecture principles

3. Lack of knowledge and understanding why principles

are important and why they should be considered

4. Poor communication of existing and new

architecture principles towards agile teams

1. EA governance bodies tend to decide over the

heads of agile teams without knowing their

concerns

2. Lack of involvement of agile teams in relevant

architecture processes and discussions

3. Rigid and tedious EA governance procedures slow

down the development speed of agile teams

1. Lack of capacity and high workload of enterprise

architects’ make it difficult for them to deliver their

services on time and in appropriate quality

2. Lack of time availability of enterprise architects

does not allow them to adequately accompany

and support agile teams

3. Enterprise architects cannot cope with the speed

of the decision-making process of agile teams

4. Enterprise architects encounter acceptance issues

by agile teams

1. Lack of technical-know of enterprise architects make

the architecture artifacts provided by the enterprise

architects less relevant to agile teams

2. Lack of regular feedback mechanisms between

enterprise architects and agile teams

3. Communication between agile teams and enterprise

architects is facilitated via a third persons leading to

loss of information, dissatisfactions by agile teams,

and their unwillingness to communicate with


reflect

adapt EA Team

model

collect

motivate


Tactics for improved

collaboration

with agile teams

Tactics for improved collaboration


Principle-Based Intentional Architecting1

Define Architecture Principles as Quality Gate

Policies 2

Empower Communities of Practices for Architecture3

Influence Agile Teams Based on Nudging4

Establish an Agile Architecture Governance

Approach5

Apply Agile and Lean Tools for Architectural Work6

Conduct Architecture Spikes to Assist Agile Teams7

Be a Supportive Enterprise Architect8


Tactic #1 – Principle-based intentional architecting

Architecture principle (APs) guide design decisions

APs prevent “Analysis Paralysis” and “Big Design

Upfront” by focusing on the essence of architecture

Before: APs were enforced top-down by enterprise

architects

Now: APs are collaboratively created by enterprise

architects and agile teams in a Community of

Practice (CoP) (see Tactic #3)

CoP votes on the adoption, refinement or rejection of

APs

APs driven by legal requirements should not be voted

on

Agile teams have the responsibility to adhere and

the freedom to neglect APs

Application of APs can be facilitated by nudging (see

Tactic #4) and architectural thinking


Greefhorst and Proper (2011): Architecture Principles - The Cornerstones of Enterprise Architecture

Uludağ et al. (2019): Establishing Architecture Guidelines in Large-Scale Agile Development Through Institutional Pressures


Assess

AimA

ct

Determine drivers

Determine principles

Specify principles

Classify principles

Validate and accept principles

Apply principles

Manage compliance

Handle changes

Managing architecture principles

Tactic #2 – Define architecture principles as quality gate policies

Verifying and controlling the adherence of agile teams to architecture principles (APs) is almost non-existent or only sporadic

APs can be integrated into the CI/CD pipeline of agile teams for automatizing compliance checks

Quality Gates (QGs) are milestones during software delivery process where APs are checked automatically

Based on the fulfillment of APs, enterprise architects make decisions about whether an application may proceed or not

The CI/CD pipeline checks architectural conformity and gives feedback to agile teams in case of violating predefined rules

The QG concept can be used mainly for technical software APs

High-level APs must be specified in one or more guidelines and KPIs to be included in the GQ concept



Feedback Feedback Feedback Feedback Feedback Feedback Feedback

Check-In BuildSmoke & DVT

TestsFunctional

TestsIntegration

TestsIntegrate

Change Management

Deploy toProduction

QG

Public Interface

QG

Public Interface

QG

Public Interface

QG

Public Interface

QG

Public Interface

QG

Public Interface

QG

Public Interface

Communities of Practices for Architecture

Communities of Practices (CoPs) are groups of

people who share a common interest and deepen

their expertise in a specific area by interacting

regularly

CoPs can be set up for a variety of domains, e.g.

architecture, including enterprise, domain,

business, and software architecture, etc.

A CoP for Architecture (CoPA) aims to create a

common understanding of architectural themes

A CoPA is usually organized by enterprise

architects and attended by architecture

enthusiasts

A CoPA regularly takes place between 1-4 weeks

A CoPA is open to all interested parties and does

not force participation

Process for handling architectural decisions

CoPAs can also be empowered to make

architectural decisions, e.g. new technologies,

standards or principles

Everyone in the CoPA is allowed to make

proposals for new standards

After an initial discussion, a small group of

experts is formed that elaborates the problem

definition until next CoPA meeting

In the next meeting, the expert group presents the

solution to the community

CoPA members discuss about the solution and

vote whether it should be defined as a standard,

rejected or reworked until the next meeting

Tactic #3 – Empower communities of practices for architecture



Tactic #4 – Influence agile teams based on nudging

Agile teams (ATs) cannot be controlled by traditional

EAM measures with a reasonable effort

Top-down driven EAM initiatives have low

acceptance in agile environments

Enforcement-centric view of EAM must be

complemented by an influence-centric view through

nudging: Show ATs benefits of complying with EAM measures

Use visuals, metaphors or gamification approaches to

motivate ATs

Create transparency on compliance adherence

Avoid financial awards or punishments for

(non-)compliance


Winter (2016): Establishing ‘Architectural Thinking’ in Organizations

Aier (2018): Regeln, Steuerung und Gehorsam oder “einfach mal laufen lassen”


Example: Architecture Belt Ensuring compliance of ATs to architecture principles (APs)

based on the analogy of belts from martial arts

ATs rank up by fulfilling APs (from white to black belt)

Compliance checks are based on self-assessment of ATs or

on automated tests (see Tactic #2)

Agile Teams

Compliance with governance regulations

Tactic #5 – Establish an agile architecture governance approach

Protect agile teams (ATs) from tedious EA governance

procedures

Classify architecture decisions based on their

importance and extent of impact

Introduce EA governance bodies empowered with

authority to increase decision-making speed

Self-GovernanceDecisions having low strategic importance and affecting only one AT

are decided by the team itself

Community GovernanceDecisions affecting multiple ATs with low strategic importance are

decided by the CoPA (see Tactic #3)

Expert Group GovernanceDecisions having high strategic importance are decided by an expert

group, so-called “Center of Excellence for Architecture” (CoEA),

consisting of representatives of architects, IT executives, and AT leads

CoEA members are themselves involved in large-scale agile

development, thus, knowing the needs of AT



Extent of Impact

hig

h

highlow

low

Str

ate

gic

Im

port

an

ce

Community

Governance

Self-

Governance

Expert Group

Governance

Expert Group

Governance

Decision-Making Authority

low high

Tactic #6 – Apply agile and lean tools for architectural work

EA team works in small iterations, i.e. bi-weekly

Sprints

EA team performs common Scrum ceremonies,

e.g. Sprint Planning or Sprint Retrospective

EA team uses basic Scrum artifacts, e.g.

Product and Sprint Backlog or Burn-Down Chart

EA team prioritizes incoming stakeholder

requests based on their strategic importance

EA team requests feedback from its customers

and performs inspect and adapt events, e.g.

Sprint Review

EA team complements Scrum by using a

Kanban board to visualize work and limit work-

in-progress

EA team uses team collaboration tools to

manage backlogs, to track tasks, and to

visualize progress



Tactic #7 – Conduct architecture spikes to assist agile teams

An Architecture Spike deals with unknown architectural requirements, e.g. new technologies

An Architecture Spike is an experiment to reduce risk and to improve the technical understanding of the tools used

eXtreme Programming recommends that agile teams conduct Architecture Spikes themselves, but in practice, we found that also software and enterprise architects perform them to provide agile teams technical support

Software and enterprise architects build small MVPs and provide them as architectural patterns (template, code, architectural skeleton, architectural runway)


Marchesi et al. (2003): Extreme Programming Perspectives


ArchitecturalSpike

Release Planning

IterationAcceptance

TestsSmall

Releases

Spike

System Metaphor Release Plan Latest VersionCustomer Approval

BugsNew User Story Project Velocity

User Stories

Requirements

Next Iteration

Test Scenarios

Confident Estimates

Uncertain Estimates

ArchitecturePatterns

Tactic #8 – Be a supportive enterprise architect

Behavioral changes

Provide more technical guidance instead of being a

“PowerPoint Architect” (see Tactic #7)

Start with the simplest architecture that can possibly work

and avoid “Big Design Upfront” and “Analysis Paralysis”

Apply “Servant Leadership” instead of traditional

“Command and Control”

Participate in common planning, review, and retrospective

to leave the “Ivory Tower”

Accept the loss of decision-making power

Use didactic skills and examples to raise architectural

thinking within teams

Use code where appropriate for short demonstrations

Increase accessibility and value of artefacts

Use light-weight and collaborative tools used by teams

(Slack, Wiki, Trello, Confluence, Jira, etc.)



Supporting Architect

Classic Architect

Zusammenfassung


Als erfolgreicher Unternehmensarchitekt

• schaffen Sie einen unternehmensweiten Ordnungsrahmen

für die Zusammenarbeit zwischen Geschäft und IT

• helfen Sie die zunehmenden Komplexität des Geschäfts zu beherrschen

• unterstützen Sie kohärente strategische Transformationen

• verstehen Sie die neuen Herausforderungen und Chancen durch die Digitalisierung

• verstehen Sie Ihre Rolle als Architekt

• verstehen Sie den (sich ständig ändernden) Kontext Ihrer Arbeit als Architekt

• verwenden Sie Business Capabilities als Grundlage für die strategische Planung

• nutzen Sie bewährte Bausteine und Muster, die zu Ihrem Unternehmen passen

• etablieren Sie ein agiles, schlankes und kollaboratives EAM

• nutzen Sie Taktiken für die erfolgreiche Zusammenarbeit in agilen IT Organisationen

Wertbeitrag

Selbstverständnis

Wissen

Lernen

Selbstreflektion

Handeln!

Technische Universität München

Faculty of Informatics

Chair of Software Engineering for Business

Information Systems

Boltzmannstraße 3

85748 Garching bei München

Tel +49.89.289.

Fax +49.89.289.17136

wwwmatthes.in.tum.de

Florian Matthes

Prof. Dr.

17132

[email protected]

http://wwwmatthes.in.tum.de/

EAM Grundlagen für die Praxis · EAM Grundlagen für die Praxis Prof. Dr. Florian Matthes EAMKON...

Documents

Transcript of EAM Grundlagen für die Praxis · EAM Grundlagen für die Praxis Prof. Dr. Florian Matthes EAMKON...