eam grundlagen für die praxis · eam grundlagen für die praxis prof. dr. florian matthes eamkon...
TRANSCRIPT
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 3
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
Education experience
© sebis190521 Matthes EAM Grundlagen für die Praxis 4
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 5
Deutsche Börse Systems
Project partners since 2005
© sebis190521 Matthes EAM Grundlagen für die Praxis 6
Consultants
Software vendors
Start-ups
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 9
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
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 11
• 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
© sebis190521 Matthes EAM Grundlagen für die Praxis 12
Software projects provide functionality and affect the IT platform efficiency.
© sebis190521 Matthes EAM Grundlagen für die Praxis 13
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 14
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 15
(~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?
© sebis190521 Matthes EAM Grundlagen für die Praxis 16
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
Business Capabilities
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
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]
© sebis190521 Matthes EAM Grundlagen für die Praxis 17
Current
Plan
Target
An enterprise architecture has to be visualized to make it accessible to
different stakeholders.
© sebis190521 Matthes EAM Grundlagen für die Praxis 18
EAVIST 2014 and EAM Pattern Catalog
The architecture model should focus on the current stakeholders and their
information demands.
© sebis190521 Matthes EAM Grundlagen für die Praxis 19
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 20
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 21
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 24
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 25
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 >
Core concepts of EAM
© sebis190521 Matthes EAM Grundlagen für die Praxis 26
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 28
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 29
Thomas Kaeser: „Der Kunde kauft keine Kompressoren oder
Druckluft-Anlagen, sondern lediglich Druckluft als Dienstleistung.“
Results-oriented control & management
© sebis190521 Matthes EAM Grundlagen für die Praxis 30
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 ...
190521 Matthes EAM Grundlagen für die Praxis 32
My business processes and my business applications
ERP CRMSCM
© sebis
… to Outside-In Thinking
190521 Matthes EAM Grundlagen für die Praxis 33
The IT architecture is based on the (future) skills of partners and customers
Example: Flixbus
© sebis
Customer-centric business networks
© sebis190521 Matthes EAM Grundlagen für die Praxis 34
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 35
Accelerating
Changes
Disruptive
Changes
BMW
MAGNA STEYR
DriveNow
Sixt
(Information) Technology
Markets & Regulations
Digitalization leads to new priorities in the design of
IT application landscapes
© sebis190521 Matthes EAM Grundlagen für die Praxis 36
Previous requirements
for IT architecture
Requirements of network
organizations
Functionality
Connectivity
Flexibility
Modular, service-oriented application landscape architecture
© sebis190521 Matthes EAM Grundlagen für die Praxis 37
• 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
© sebis190521 Matthes EAM Grundlagen für die Praxis 38
• 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
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 40
Understand your role in
enterprise change
management
41
Implementing architectures is a process of change.
© sebis190521 Matthes EAM Grundlagen für die Praxis 42
Labyrint IT Strategy Solutions
Example: DB Mobility Logistics
© sebis190521 Matthes EAM Grundlagen für die Praxis 43
Example: ABN AMRO
© sebis190521 Matthes EAM Grundlagen für die Praxis 44
Example: ABN AMRO
© sebis190521 Matthes EAM Grundlagen für die Praxis 45
The color theory distinguishes five fundamental approaches to change.
© sebis190521 Matthes EAM Grundlagen für die Praxis 46
Labyrint IT Strategy Solutions
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 47
Labyrint IT Strategy Solutions
A transformation unit
© sebis190521 Matthes EAM Grundlagen für die Praxis 48
A transformation network
© sebis190521 Matthes EAM Grundlagen für die Praxis 49
Understand the influence of
your organization on your
EAM work
50
Enterprise architecture management
© sebis190521 Matthes EAM Grundlagen für die Praxis 51
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 >
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 52
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 53
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 54
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 55
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
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 57
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 60
The classical layers and elements of a business architecture
© sebis190521 Matthes EAM Grundlagen für die Praxis 61
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
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
Business capabilities focus on the ‘what’ and not on the ‘how’!
What is a business capability?
© sebis190521 Matthes EAM Grundlagen für die Praxis 64
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 65
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 66
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
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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 67
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 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.
© sebis190521 Matthes EAM Grundlagen für die Praxis 68
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
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 69
Example: Axel Springer SE (2015)
Example: Business capability map of Novartis
© sebis190521 Matthes EAM Grundlagen für die Praxis 70
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)
© sebis190521 Matthes EAM Grundlagen für die Praxis 73
Gap Action Recommendation
Gap 1 Action Recommendation 1
Action Recommendation 2
Gap 2 Action Recommendation 3
Action Recommendation 4
Gap 3 Action Recommendation 2
Action Recommendation 4
Action Recommendation 5
Gap 4 Action Recommendation 6
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 75
Core concepts of the EAM pattern catalog
© sebis190521 Matthes EAM Grundlagen für die Praxis 76
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
…
© sebis190521 Matthes EAM Grundlagen für die Praxis 77
EAM method building blocks (2012)
© sebis190521 Matthes EAM Grundlagen für die Praxis 78
BEAMS online method base
Influence factors for EAM
© sebis
190521 Matthes EAM Grundlagen für die Praxis
79
EAM Questions
Organizational Context
EAM Goals
Maturity of other (IT) management functions
Enterprise Context
Influence factorschanging over time
More >
EAM pattern catalogs
© sebis190521 Matthes EAM Grundlagen für die Praxis 80
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
EAM pattern catalog version 1.0 (2008)
© sebis190521 Matthes EAM Grundlagen für die Praxis 81
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)
© sebis190521 Matthes EAM Grundlagen für die Praxis 82
Influence factors
Maturity levels I1 I2 ML1e.g. Regulatory requirements
Architecture principles
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 83
I108I108
M71M71
C157?
C157?
V108V108
S45
DC1DC1
S45
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 84
I108I108
M71M71
C157?
C157?
V108V108
S45
DC1DC1
S45
Stakeholder 45: Enterprise Architect
Further: CIO, Domain / Solution Architect, Technical
Architect
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 85
I108I108
M71M71
C157?
C157?
V108V108
Concern 157: Detection of
consolidation potentials
S45
DC1DC1
S45
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 86
I108I108
M71M71
C157?
C157?
V108V108
M-Pattern 71: Elimination of functional
redundancies and standardization, e.g.
integration platform, architecture blueprints
© sebis
S45
DC1DC1
S45
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 87
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
Organizational Unit 2
PC(1)
PC(2)
Organizational Unit 3
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
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 88
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
Example: pattern for application consolidation
© sebis190521 Matthes EAM Grundlagen für die Praxis 89
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 90
I113
M34M34
C179?
C179?
S45
DC2DC2
S45
I113
V113V113
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 91
I113
M34M34
C179?
C179?
S45
DC2DC2
S45
Stakeholder 45: COO
Further: Enterprise Architect
I113
V113V113
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 92
I113
M34M34
C179?
C179?
Concern 179: Where do we have
regulatory issues?
© sebis
S45
DC2DC2
S45
I113
V113V113
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 93
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
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 94
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
Compliance Issues: 3
Regulatory
Compliance Issues:
45
Regulatory
Compliance Issues: 2
Business Capability 3Regulatory
Compliance Issues: 0
Regulatory
Compliance Issues:
14
Regulatory
Compliance Issues: 0
Visualization Rules
Less then 10% of
requirements
breached
Less then 40% of
requirements
breached
Over 40% of
requirements
breached
V113
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 95
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
Example: pattern for regulatory requirements
© sebis190521 Matthes EAM Grundlagen für die Praxis 96
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
190521 Matthes EAM Grundlagen für die Praxis
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
Identifizierte Visualisierungstypen
190521 Matthes EAM Grundlagen für die Praxis
EAVIST 2014
© sebis 98
Nutzung von Visualisierungstypen (N=109)
190521 Matthes EAM Grundlagen für die Praxis
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
Beispiel Cluster Map
190521 Matthes EAM Grundlagen für die Praxis
Steckbrief Screenshots von jedem Tool
EAVIST 2014
© sebis 100
eam-initiative.orgA wiki-based knowledge community for EAM
© sebis190521 Matthes EAM Grundlagen für die Praxis 101
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
Kaffeepause
30min
102
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 103
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
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 105
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 106
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 107
Agile EA management principles
190521 Matthes EAM Grundlagen für die Praxis 108
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
Agile EA management principles
© sebis190521 Matthes EAM Grundlagen für die Praxis 109
Focus on demands of top stakeholders and speak their languages
IT Project 3IT Project 2
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
Agile EA management principles
190521 Matthes EAM Grundlagen für die Praxis 110
Reflect behavior and adapt to changes
IT Project 3IT Project 2
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 111
Risk: Over-fitting of EA function to
current demands
Related approaches: Collaborative EAM
190521 Matthes EAM Grundlagen für die Praxis 112
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 113
Challenges of
enterprise architects
in large-scale
agile transformation
Multiple case studies of agile EA governance in large IT organizations
© sebis190521 Matthes EAM Grundlagen für die Praxis 114
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 115
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 116
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 117
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 118
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
enterprise architects
reflect
adapt EA Team
model
collect
motivate
© sebis190521 Matthes EAM Grundlagen für die Praxis 119
Tactics for improved
collaboration
with agile teams
Tactics for improved collaboration
© sebis190521 Matthes EAM Grundlagen für die Praxis 120
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
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 121
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
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 122
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 123
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 124
Winter (2016): Establishing ‘Architectural Thinking’ in Organizations
Aier (2018): Regeln, Steuerung und Gehorsam oder “einfach mal laufen lassen”
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 125
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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
© sebis190521 Matthes EAM Grundlagen für die Praxis 126
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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)
© sebis190521 Matthes EAM Grundlagen für die Praxis 127
Marchesi et al. (2003): Extreme Programming Perspectives
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
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.)
© sebis190521 Matthes EAM Grundlagen für die Praxis 128
Uludağ et al. (2020): Improving the Collaboration Between Enterprise Architects and Agile Teams: A Multiple-Case Study
Supporting Architect
Classic Architect
Zusammenfassung
© sebis190521 Matthes EAM Grundlagen für die Praxis 129
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