There is currently much debate about whether and how agility scales at the enterprise level. Many approaches exist, such as scaled Agile frameworks (SAFe, LeSS, DaD), Beta Codex, Beyond Budgeting, Sociocracy or Open Space, but success stories are rare.. Design thinking and Agile are the methods currently used to implement innovative point solutions at short notice. Companies rarely take enough time for long-term thinking. Fast innovation, sloppily integrated into the existing IT landscape, however, has lead to a complexity explosion that made IT tremendously expensive and increasingly sluggish for change. And this is not an IT problem but the result of bad funding decisions by business executives. Therefore it must be addressed at a business- and governance level, not by autonomous solution development teams. Many people of the Agile community perceive IT governance and architecture management as too rigid and heavyweight to be integrated with Agil. This is not surprising given the prevailing heavy and immature enterprise architecture frameworks and their ivory-tower use in practice. This presentation discusses why Agile will never scale without a consistent model of the business (=’business architecture’) that is understood, maintained an accepted by everybody, from CEO to software developer. It presents a lightweight, business-focused approach to architecture that should be integrated with common scaled agile frameworks (such as SAFe, LeSS, DaD) to really make them scale.

1. Architectural Thinking:
the Sucess Factor of Scaled Agile
Dr. Wolfgang Goebl
November 2018
1

2. About us
• Non Profit Association
• “Förderung des architekturellen Denkens in Unternehmen”
• Truly open Architectural Thinking Framework®
• architectural-thinking.com/participate
2

3. About us – current Status
3

4. Basic Assumption of my Presentation
4
vs.? And!
Design by a Genius Team Design
see [Westerman15]

5. “The more participation in design, the better. This is surely not
universally true.
Most great works of the human mind have been made by one mind, or
two working closely. This is true of most of the great engineering feats
of the 19th and early 20th centuries.
But now, team design has become the modern standard, for good
reasons. The danger is the loss of conceptual integrity in the product, a
very grave loss indeed. So the challenge is how to achieve conceptual
integrity while doing team design, and at the same time to achieve the
very real benefits of collaboration.”
[Brooks10]
5
Basic Assumption of my Presentation

6. 1. The Problem
6

7. The Problem
7
Dark Waters of Legacy IT
Disruptor Company
Agile! Agile!
Agile!
Innovation!
?
Architecture
?

8. 2. Attempts that verifiably do not work*
8
* in Isolation

9. Separated Disciplines
9
”It is all about Leadership”
“Cloud is the only remedy”
“Its all about
Innovation” “Be Agile”
“Microservices to the Rescue!”

10. A sole Discipline as Connector
10
Vision/Strategy
Management
Design
Thinking
Business
Analysis
Business
Process
Management
IT Operations
Project
Management
Programm
Management
EAM
(Agile-)Solution
Development
Business Units

11. Bloated EAM Frameworks
11
Archimate®
Zachmann
TOGAF®
[Carr18] [Kostic 16]

12. Ivory Tower Architects

13. Software/System Architecture only

14. Microservices as universal Remedy
https://de.slideshare.net/ITARENA/microservices-redundancy-maintainability-eberhard-wolff-technology-stream
Tiny modules
to the rescue
Redundant
Data makes
Agile scale!

15. The Cloud as universal Remedy
15

16. Hardcore Agility
16

17. 17
Autonomous Teams without a Plan

18. 18
Time-to-market Thinking only

19. 19
Focus on Culture/Leadership only
ChainsofLegacy
Company
Be agile!
Lead agile!
Run like
Hell!

20. 20
Design Thinking
Let’s have Fun!
... and create
yet another
unrealizable
point
solution!

21. Nexus™
21scrum.org/resources/nexus-guide

22. 22
Nexus™
Pros Cons
Extremely lean (12 pages) No real guidance
Architecture not mentioned

23. Large Scale Scrum™ (LeSS)
https://less.works/
23

24. Large Scale Scrum (LeSS) - Quotes
https://less.works/less/technical-excellence/architecture-design.html
24
• What to model:
• low-fidelity UI modeling
• algorithm modeling with UML activity diagrams,
• object-oriented software design modeling
• database modeling likewise.
“The real software architecture evolves as people do programming.”
“Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design”

25. 25
Large Scale Scrum (LeSS)
Pros Cons
Evolutionary Approach No Inception Phase
Team creates
Architecture
No ‘Architecture
Owner’ – Integrity??
Tekkie Architecture
only
Focus on Solution only
Enterprise Awareness?

26. Scaled Agile Framework® (SAFe®)
https://www.scaledagileframework.com/
26

27. 27
Scaled Agile Framework® (SAFe®)
EA’s Responsibility:
90% Tekkie
https://www.scaledagileframework.com/enterprise-architect/

28. 28
Pros Cons
Nexus to BizArch
(Value Stream)
No other BizArch Artefacts
(Information, Capabilities)
Explicit Architecture Roles - No Inception Phase
- Ignores Wisdom of EA&BA
- 90% Tekkie Architecture
Enterprise Awareness Hard to understand
Expensive Trainings needed.
Too heavyweight?
Scaled Agile Framework® (SAFe®)

29. Disciplined Agile Delivery (DaD)
disciplinedagiledelivery.com/
29

30. 30
Disciplined Agile Delivery (DaD)
disciplinedagiledelivery.com/
Inception Phase:
• foundation from which the project can be successful in a lightweight manner
• Enterprise awareness
• Vision, scope, connection with Biz-& EA of the company
• Enterprise as another customer

31. 31
Pros Cons
Understands Biz&IT
Architecture in depth
Not as widespread as SAFe®
‘Architecture Owner’ role
Evolves evolutionary from
team
Inception Phase
Enterprise Awareness
Easy to understand
Disciplined Agile Delivery (DaD)

32. 3. What might work
32

33. A new, more holistic Manifesto
33

34. 34
YES
A new, more holistic Manifesto

35. Sustainable solutions over working software
35
A new, more holistic Manifesto

36. 36
Considering all stakeholders over customer only
A new, more holistic Manifesto
Incl. Enterprise as a whole

37. 37
Malleable plans over strict plans & anarchy

38. Business (Architecture) over IT (Architecture)
38
A new, more holistic Manifesto
New

39. 39
Vision/Strategy
Management
Design
Thinking
Business
Analysis
Business Process
Management
IT Operations
Project
Management
Programm
Management
(Agile-)Solution
Development
Business Units
Architectural Thinking as a Mindset

40. 40
• Overlapping responsibilities between departments
• Unclear data- and process ownership
• Acting in departmental silos
• Weak links between departments
• Short term thinking
• Bad (IT-) funding decisions
• Ordering the wrong IT solutions
Business aspects/decisions are the reason of IT Chaos
Focus on Business Architecture

41. Focus on Business Architecture
• Model of the Business Architecture drives IT Architecture
• Capabilities
• Processes/Value Streams
• Business Information
• Applications
41
[BAGuild16]

42. Simple Model everybody agrees upon
42
Ear
Leg
Tooth
Trunk
Eye

43. Connect everything to Model
43
Ear
Leg
Tooth
Trunk
Eye
Require
ment
Budget Solution
Vision
Strategy
Project
Code
Architectural Thinking Framework®
Metamodel
(Draft)
Gover
nance

44. Connect Solution Stories and Biz Arch
44
CapabilityMap(ExampleBank)

45. 45
SolutionLevel
StoryMapBoard
EnterpriseLevel
CapabilityMap
Connect Solution Stories and Biz Arch

46. 46
Connect Solution Stories and EntArch

47. Modularize by Business Information
47

48. Manage technical Debt proactively
48
Dark Waters of Legacy IT

49. “Agility does not mean to maximize speed.
It means maneuverability, i.e. finding the right speed
to make the right deflection.”
49
Find right speed, modernize System

50. Culture to transform the System
• The “System” (business & IT structures) make a company Agile
• Agile culture
• alone does not transform a company
• is important but not a means by itself
50
+ Culture
+ (Reengineering-) Methods
----------------------------------
= Transformation

51. Strict Governance & autonomous Teams
51

52. Add Architectural to Design Thinking
52
Design Thinking Workshops are cool! But….
*) Architecture Maps and Architecture Owner must be in the room
*)

53. Architectural Thinking Framework®
53
https://architectural-thinking.com/architectural-thinking-overview/

54. 4. Conclusion
54

55. Conclusion: How to scale Agile
• Disciplines working together using the same Enterprise Model
• Strong focus on Business Architecture
• Integration of Scaled Agile- & Lightweight Architecture Framework
• Centralized governance AND autonomous teams
• Cultural Change AND (engineering) methods
• Collaboration between Enterprise- and Solution Architecture
55

56. Recommended Reading
[Ambler10]: S. Ambler: ‘Disciplined Agile Delivery’
[BAGuild16]: Business Architecture Guild, “A Guide to the Business Architecture Body of
Knowledge®” (BIZBOK® Guide, v6.5), http://www.businessarchitectureguild.org/
[Brooks10]: F. Brooks: ‘The Design of Design: Essays from a Computer Scientist’
[Carr18]: D. Carr 'State of Enterprise Architecture Survey: Results and Findings'
https://eapj.org/wp-content/uploads/2018/05/EAPJ-Special-Edition-State-of-EA-Survey.pdf
[Eckstein18]: J. Eckstein: ‘Company-wide Agility’
[Kostic 16]: N. Kostic: ‘Demystifying Enterprise Architecture‘
http://www.entarchs.com/blog/demystifying-enterprise-architecture.html
[Westerman15]: ‘Leading Digital Turning Technology into Business Transformation’
56

57. One last thing…
57
“Sometimes we are Agile without the Discipline.
Sometimes we are disciplined without the Agile.
We need both.”

58. Thank you!
58
Dr. Wolfgang Goebl
wolfgang.goebl@architectural-thinking.com
architectural-thinking.com