How can we help a big organization to improve itself?

1. Enterprise Architecture for
an agile world
Roland Bair – March 2020

2. Who am I and why am I here
• Roland (36, Vienna)
• Studies: Apprenticeship, Business Informatics, Organizational
Development
• Roles: Developer, Team Lead/Architect, “Enterprise Architect”, Startup
CTO, Startup Advisor, Change Consultant, “Enterprise Architect”,
“Enterprise Architect”, ?
• Why

3. The Backbone of this presentation
 The areas of Enterprise Architecture
 The relevant agile world
 Challenges with the traditional EA approach
 The journey + learnings

4. Main Areas of Enterprise Architecture
Standards & Lifecycle
Management
Technological
Standards
Application
Blueprints
Architecture
Patterns
Governance
Project Alignment
Roadmap Review
Architecture
Principles
Architecture Evolution
Goals
Definition
Implementation &
Adaptation

5. The Backbone of this presentation
 The areas of Enterprise Architecture
 The relevant agile world
 Challenges with the traditional EA approach
 The journey + learnings

6. The relevant agile world
• Business environments change more frequently – VUCA world
• Organizational capability to adapt becomes more important -
constant change
• Speed of adaption also becomes more important
• Number of decision increases
1. Create “right-sized”
areas of responsibility
3. Make employees part
of the journey
2. Decrease size of
changes
• Faster decision
making is required
• Change size increase
risks and costs
• Employees need to
adapt frequently

7. The Backbone of this presentation
 The areas of Enterprise Architecture
 The relevant agile world
 Challenges with the traditional EA approach
 The journey + learnings

8. The traditional EA setup
Acceptance of
organisation
Outside-in
Real Experts
vs. Agile
Approach
Duration of
Programs
Required
Completeness
Dependency of
business projects
EA Roles
Technological
Experts
Domain Experts
People Leaders
C. Leaders & CoachesA. Small improvements B. Method experts

9. The question
How can we design enterprise architecture to
Increase local autonomy
Decrease size of changes
Deliver iterative value
Involve employees as leaders and coaches
1. Create “right-sized” areas of
responsibility
3. Make employees part of the
journey
2. Decrease size of changes
Relevant Agile world
EA challenges
C. Leaders & CoachesB. Method expertsA. Small improvements

10. Help of existing approaches
• Traditional EA – TOGAF-style, Zachman et al.  iterations
• Architecture Thinking  Lean, BA-focus
• Agile Enterprise Architecture  breaking down EA work
• Strategic EA  distinct and clear dimensions
• Sociotechnological approaches  Conveys Law, Wardley Maps

11. The Backbone of this presentation
 The areas of Enterprise Architecture
 The relevant agile world
 The problems with the traditional approach
 The journey + learnings

12. Story Outline
• Company background & what’s wrong
• Goals
• “Iteration 1”
• Design
• Iteration 2
• Design
• Transition
• Learnings

13. Background
• > 40 year old organisation: paper & manual, founder-owned
• Multiple growth periods and expansion to over 40 countries
• Ever increasing digitization with multiple “bi-modal IT” models
• Changing owners and leadership teams with different styles
• Heterogenous culture, styles, systems
• Batch based paper  Real-
Time Digital
• Project/Software  Service
 Product
• B2B  B2B2C  B2C
• Scarce expert knowledge
• Fast Decision Making & Slow
execution
• Team based way of working
• Java, .NET, old stuff
• Monoliths, SOA,
Microservices
• Files, DBs, ESBs, APIs
• PCs, VMs in DCs, Cloud
PoCs

14. What’s wrong?
Lots of coordination and discussions & not-invented-here syndrome
30% high-level use cases duplicated
High implementation lead-time

15. Goals / Metrics
• Reduce Time To Market
• Baseline?
• Architecture alone won’t fix it
• Number of changed systems for standard projects
• Number of required teams for new projects

16. “Iteration One” Plan
1. Design the Business Architecture
1. Create list of high level use-case with subject matter experts
2. Interview key business users for pain points
3. Interview product management for strategic and tactical short-comings
4. Design grouping principles (EA team)
5. Group Domain Services and indicate dependencies (EA team)
2. Approval
1. Get approval by Product/Technology steering
3. Implement in projects
1. Adapt projects & product roadmaps
2. Govern dependencies

17. Design Phase Outcome
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Questions
Business Services
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service …
Function 1
Questions
Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
Function 1 Function 1 Function 1 Function 1
FEService 1
FEService 3
FEService 5
FEService 7
FEService 9
FEService11
FEService13
FEService15
FEService17
FEService19
FEService 2
FEService 4
FEService 6
FEService 8
FEService10
FEService12
FEService14
FEService16
FEService18
FEService20
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service …
High Level Use Cases Grouped into Services
Service Dependencies
Principles

18. 1 week later
Approval in progress
FEService 1
FEService 3
FEService 5
FEService 7
FEService 9
FEService11
FEService13
FEService15
FEService17
FEService19
FEService 2
FEService 4
FEService 6
FEService 8
FEService10
FEService12
FEService14
FEService16
FEService18
FEService20
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service …

19. 2 months later
Approval in progress
FEService 1
FEService 3
FEService 5
FEService 7
FEService 9
FEService11
FEService13
FEService15
FEService17
FEService19
FEService 2
FEService 4
FEService 6
FEService 8
FEService10
FEService12
FEService14
FEService16
FEService18
FEService20
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service …
FEService 1
FEService 3
FEService 5
FEService 7
FEService 9
FEService11
FEService13
FEService15
FEService17
FEService19
FEService 2
FEService 4
FEService 6
FEService 8
FEService10
FEService12
FEService14
FEService16
FEService18
FEService20
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service 10
Service 1
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
Service 8
Service 9
Service …

20. STOP!

21. What happened ?
Steering:
• “Is it the right solution”?
• “What’s the impact to project X, program Y?”
1. Big change with big uncertainties
2. Unclear/Unwanted impact to running projects
3. Who takes the risk / blame?

22. Changes
• Goal of first iteration: “Reusability” / Clear responsibilities
• Bring in the organization
• Bring together people with strong/conflicting views
• Change transition

23. Change Transition
4Ps - William Bridges Transition Model
1. Purpose: Why are we doing it?
2. Picture: How will the outcome look and feel?
3. Plan: How do we get there?
4. Part: How can I contribute and participate?

24. Iteration 2 Plan
1. Establish Design Group – nominated by steering
2. Validate high-level use cases (workshops)
3. Group high level use cases into domain services to maximize team
independence (workshops)
4. Validate continuously with overall organization
5. Visualize implementation dependencies
6. Transition into overall organization (Part: Trainings, Material, Assessment)

25. Reality
1. Weekly alignment workshops with Design Group for ~3 months
• In parallel: interviews, discussions, workshops for upcoming questions and
concerns – e.g. MDM discussions, process
2. Weekly grouping workshops with Design Group for ~4 months
• In parallel: validation against business processes
3. “Approval”
4. Organisation-wide presentation for Q&A
5. Delivery planning
6. ?

26. Outcome
High Level Use Cases Grouped into Services Service Dependencies
Potential Delivery Plan Transition Plan
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1
Project 1 Project 1

27. Learnings
1. Not everyone used to high level abstraction  create stable boundaries and a clear
outline
2. Diverse group from across the organisation  requires team setup and leadership
3. Use efficient feedback mechanisms for overall organization  e.g. World Café >
Presentation
4. Even a continuous initiative requires priority and focus, First Version should be more
focused
5. Talk about the why – early and often!

28. Learnings
1. Aligned vision > correct/best vision
2. Few easy grouping principles + iterative > correct grouping principles
3. Terminology is important!
4. Right level of detail (aka Illusion of aligned understanding)
5. Right sizing requires operational assumptions
6. Some projects, products, systems align “automatically”
7. People governance over system governance
8. “There is another organism on this planet that follows the same pattern. Do you know what it is?” Agent Smith ~1999
• aka the “Change Agent” network

29. Thank you!