Tweet
Tweet

Slide 1

Slide 1 text

Modern Enterprise Architecture: Architecting for Outcomes Simon Rohrer

Slide 2

Slide 2 text

My journey Developer Enterprise architect Agile transformation lead Head of tech arch & WoW Agile adoption lead Ways of working lead

Slide 3

Slide 3 text

Modern Enterprise Architecture Teams-of- Teams-of- Teams: > 150 Employees Interact with Your Customers Digitally Change is a Constant Heterogeneous Environment: Old/New, Big/Small, Slow/Fast, Monolith/Distributed Vendors/Internal Systems of Systems of Systems

Slide 4

Slide 4 text

A B C D E Aligning Value, People and Technology Architecting for Outcomes: Better Value, Sooner, Safer, Happier Governing Continuously: Conversational and Automated Practicing DevOps at Enterprise Scale Curating the Evolution of Enterprise Architecture and Organisation • Conway’s law ++ and reverse Conway manoeuvre • Removing complexity and increasing autonomy • Enterprise architecture as politics and diplomacy • Outcomes of quality, fl ow, safety to balance pure “value” • Happier customers, colleagues, citizens & climate • Continuous improvement - be the best at being better • A stream of continuous architecture decisions • Moving decisions down into the right level of the org • Automating common top-level system policies • Learning by observing: intention & re fl ection • Humility in architecture: all decisions are contingent • Fitness functions for socio-technical architecture at scale • Evolving fast and slow Modern Enterprise Architecture

Slide 5

Slide 5 text

Growth vs Fixed de fi nitions

Slide 6

Slide 6 text

Uncovering better ways of developing software by doing it and helping others do it Early and continuous delivery
 of valuable software Continuous attention to technical excellence and good design “Agile” Processes & tools Sprints, standups, user stories, story points Scrum Fixed mindset Growth mindset Frameworks & certi fi cations & coaches Individuals and interactions over processes and tools

Slide 7

Slide 7 text

You build it, you run it (/ you deploy it / you test it / you design it / etc) Culture, Automation, Lean, Metrics, Sharing The 3 ways: Systems Thinking, Amplify Feedback Loops, Culture of Continuous Experimentation & Learning Business = Dev, Customer = Ops “DevOps” A DevOps department / team / engineer Kubernetes, cloud, automating release pipelines CI/CD Fixed mindset Growth mindset One more hando ff in tech: Dev -> DevOps -> Ops/SRE

Slide 8

Slide 8 text

Where are we? How did we get here?

Slide 9

Slide 9 text

1990s 1995 1999 1994 1999 1994

Slide 10

Slide 10 text

Software ate the world

Slide 11

Slide 11 text

A paradigm shift happened in software development Plan • Requirements • High level design months Analysis & design team Code • Detailed design • Development months Development team Test months • Test plan • Test execution Test team Release • Change request • Deployment weeks Release team Operate • Incidents • Problem fixes forever Operations team Development/ operation team Days or hours

Slide 12

Slide 12 text

Not everyone noticed

Slide 13

Slide 13 text

Complexity in the existing (“legacy”) system landscape started to dominate the pace of change Business service Technical service Database

Slide 14

Slide 14 text

1. Autonomy 2. Explicit boundaries 3. Partitioning of functionality 4. Dependencies de fi ned by functionality 5. Asynchronicity [by default] 6. Partitioning of data 7. No cross-fortress transactions 8. Single point security 9. Inside trust 10. Keep it simple Patterns were documented to manage complexity but not everyone used them. They still don’t. Autonomous business capability 2008

Slide 15

Slide 15 text

Our problems are similar but different to those in the 1990s The enterprise software landscape is so complex we need to use project management techniques to coordinate multiple teams for simple features Civil engineering processes are the best way to deliver any software change 1990s 2020s Plan • Requirements • High level design months Analysis & design team Code • Detailed design • Development months Development team Test months • Test plan • Test execution Test team Release • Change request • Deployment weeks Release team Operate • Incidents • Problem fixes forever Operations team

Slide 16

Slide 16 text

An organization that lacks a viable program in enterprise architecture will pay a severe cost in IT complexity. Complexity is the enemy. Enterprise Architecture is the solution. The only solution. Roger Sessions, 2008 https://web.archive.org/web/20211021220626/https://simplearchitectures.blogspot.com/2008/11/job-of-enterprise-architect.html

Slide 17

Slide 17 text

Help the organisation view itself as a complex sociotechnical system(-of- systems-of-systems) & reduce that complexity over time based on outcomes and learning Enterprise architecture Tell the organization what to do Fixed mindset Growth mindset

Slide 18

Slide 18 text

A Aligning Value, People and Technology

Slide 19

Slide 19 text

Organisation architecture System architecture Drives Conway’s law (very roughly)

Slide 20

Slide 20 text

If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. Ruth Malan, 2008 https://web.archive.org/web/20221205155201/https://ruthmalan.com/traceinthesand/conwayslaw.htm

Slide 21

Slide 21 text

BUT!

Slide 22

Slide 22 text

Where all hell really breaks loose is when management decides to reorganise things. … if you try to change the organisation, the software won’t let it happen. Allan Kelly, 2018 https://www.youtube.com/watch?v=Cu0AU8vw3xw

Slide 23

Slide 23 text

Organisation architecture System architecture Drives System architecture Organisation architecture Constrains

Slide 24

Slide 24 text

???

Slide 25

Slide 25 text

We shape our buildings; thereafter they shape us Winston Churchill, 1943

Slide 26

Slide 26 text

We shape our architecture and then the architecture shapes us Gene Kim, 2022 https://web.archive.org/web/20231015100627/https://twitter.com/lbmkrishna/status/1547447927567953920?s=20

Slide 27

Slide 27 text

Organisation architecture System architecture Constrains Constrains

Slide 28

Slide 28 text

System architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other. Ruth Malan, 2008 https://web.archive.org/web/20221205155201/https://ruthmalan.com/traceinthesand/conwayslaw.htm

Slide 29

Slide 29 text

Organization architects (“managers”) System architects (“architects”) Organisation architecture System architecture Constrains Constrains

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Business architecture (“value streams”) Organisation architecture Drives Organization architects (“managers”)

Slide 32

Slide 32 text

Organisation architecture System architecture Constrains Constrains Business architecture (“value streams”) Constrains Constrains Constrains Constrains Organization architects (“managers”) System architects (“architects”)

Slide 33

Slide 33 text

Value Organization Technology & processes People, teams, teams-of-teams, departments Business services & business processes, IT services & IT components OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Work Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Aligning all 3 for sustainable fl ow

Slide 34

Slide 34 text

Level 0: an ideal 2- pizza stream- aligned team Value 2 pizza team - 20 people Software that fits inside the team’s head Full stack, full lifecycle, full burrito, T-shaped people - YBIYRI Self-organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value 2 pizza team - 20 people Software that fits inside the team’s head Full stack, full lifecycle, full burrito, T-shaped people - YBIYRI Self-organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value 2 pizza team - 20 people Software that fits inside the team’s head Full stack, full lifecycle, full burrito, T-shaped people - YBIYRI Self-organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value 2 pizza team - 20 people Software that fits inside the team’s head Full stack, full lifecycle, full burrito, T-shaped people - YBIYRI Self-organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Value pizza team 20 people Software that fits inside the team’s head Full stack, full ecycle, full burrito, -shaped people - YBIYRI Self-organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents

Slide 38

Slide 38 text

Level 1: an ideal team- of-teams Value Team-of-teams Dunbar number - <150 System-of-systems & domain that fits inside the team’s head “Tribe” Nested value Self-organizing? Nested DDD Shared data model? Eventually consistent Each component independently deployable & testable OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value Team-of-teams Dunbar number - <150 System-of-systems & domain that fits inside the team’s head “Tribe” Nested value Self-organizing? Nested DDD Shared data model? Eventually consistent Each component independently deployable & testable OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value Team-of-teams Dunbar number - <150 System-of-systems & domain that fits inside the team’s head “Tribe” Nested value Self-organizing? Nested DDD Shared data model? Eventually consistent Each component independently deployable & testable OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value Team-of-teams Dunbar number - <150 System-of-systems & domain that fits inside the team’s head “Tribe” Nested value Self-organizing? Nested DDD Shared data model? Eventually consistent Each component independently deployable & testable OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents

Slide 39

Slide 39 text

Level 2: an ideal business line OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Value Team-of-team-of-teams 1000–2000 System-of-system-of-systems Does this fit in anyone’s head? Department / business line Nested value Self-organizing??? Further nested DDD Minimally shared data model - just keys? Eventually consistent between subdomains Key paths and failure modes should be known OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Value Team-of-team-of-teams 1000–2000 System-of-system-of-systems Does this fit in anyone’s head? Department / business line Nested value Self-organizing??? Further nested DDD Minimally shared data model - just keys? Eventually consistent between subdomains Key paths and failure modes should be known OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Value Team-of-team-of-teams 1000–2000 System-of-system-of-systems Does this fit in anyone’s head? Department / business line Nested value Self-organizing??? Further nested DDD Minimally shared data model - just keys? Eventually consistent between subdomains Key paths and failure modes should be known OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Teams-of- Teams-of- Teams: > 150 Employees OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Value Team-of-team-of-teams 1000–2000 System-of-system-of-systems Does this fit in anyone’s head? Department / business line Nested value Self-organizing??? Further nested DDD Minimally shared data model - just keys? Eventually consistent between subdomains Key paths and failure modes should be known OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Systems of Systems of Systems

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

The best architectures, requirements, and designs emerge from self-organizing teams. agilemanifesto.org/principles.html, 2001

Slide 42

Slide 42 text

Value zza team 20 people Software that fits inside the team’s head stack, full le, full burrito, ped people - YBIYRI -organizing DDD Eventually consistent Independently deployable & testable “Monolith vs Microservice is missing the point” Emergent design & evolutionary* architecture OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents Value Team-of-teams Dunbar number - <150 System-of-systems & domain that fits inside the team’s head “Tribe” Nested value Self-organizing? Nested DDD Shared data model? Eventually consistent Each component independently deployable & testable OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Outcomes, hypotheses, bets User stories, tasks, changes, problems, incidents OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Value Team-of-team-of-teams 1000–2000 System-of-sys Does this fit in Department / business line Nested value Self-organizing??? Further n Minimally shared da Eventually consistent Key paths and failure m OKRs looking forward (Dev) KPIs & OLIs right now & looking back (Ops) Teams-of- Teams-of- Teams: > 150 Employees Self-organizing teams?

Slide 43

Slide 43 text

B Architecting for Outcomes: Better Value, Sooner, Safer, Happier

Slide 44

Slide 44 text

Standardisation Consistency Predictive planning Cost reduction Antipattern: traditional EA outcomes These are not the outcomes you’re looking for

Slide 45

Slide 45 text

Cloud Kubernetes Microservices Antipattern: “newer” EA outcomes These are not the outcomes you’re looking for

Slide 46

Slide 46 text

Customers Colleagues Citizens Climate Security Privacy Minimum viable compliance Quality Flow Pattern: align to business agility

Slide 47

Slide 47 text

We shape our architecture and then the architecture shapes us Gene Kim As the systems we build become larger, the coordination increases… …it can grow so so large that all our time and energy is spent coordinating - it is at the expense of our value creating activities https://web.archive.org/web/20231015100627/https://twitter.com/lbmkrishna/status/1547447927567953920?s=20

Slide 48

Slide 48 text

“Hello world” with tightly coupled complex architecture ¥$€ SOLUTION ARCHITECTS TESTING TEAM UI API LAYER GREETINGS SERVICE PLANET SERVICE “Hello world!” “!” /api Hello World T_HW “Hello wrld!”

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

Release trains are an iterative and incremental lifecycle, but they are not agile. https://www.jrothman.com/articles/2011/01/not-ready-for-agile-start-your-journey-with-release-trains/ Johanna Rothman, 2011

Slide 51

Slide 51 text

Autonomous team with their own valuable business capability Refactored Restructured organization and architecture ¥$€ EARTH GREETER MICROFRONTEND EARTH GREETER MICROSERVICE DB EARTH GREETER MICROSERVICE “Hello world!” ] “Hello world!”

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

C Governing Continuously: Conversational and Automated

Slide 54

Slide 54 text

Creating and reducing complexity may sound like perfect opposites. But in fact fundamental asymmetries exist between the two. https://hbr.org/2020/01/taming-complexity

Slide 55

Slide 55 text

Architecture governance to the rescue?

Slide 56

Slide 56 text

Antipattern: Architecture Review Boards

Slide 57

Slide 57 text

Initiate Plan Execute Close Analysis Design Build/Test Release Architecture board Review Architecture board Review How we used to govern architecture A project: waterfall / wagile / water-scrum-fall / “hybrid”

Slide 58

Slide 58 text

How does this work with modern delivery? Initiate Plan Execute Close Analysis Test/design/build Release Release Release Release Release Release Release Architecture board Review An agile or lean project

Slide 59

Slide 59 text

How does this work with modern delivery? Architecture board A product

Slide 60

Slide 60 text

Pattern: Black box architecture governance

Slide 61

Slide 61 text

Govern realised architectures, not (just) designs on paper “I think I need an new service” “I think my service needs to access data or functionality from another service” EA approve new services, new namespaces in Kubernetes (etc.) EA approve: • Service-to-service IAM • Firewalls “I want an exception to automated governance - e.g. synchronous request/response” EA approve: • Exceptions • Tech debt Enterprise Architecture as GitOps

Slide 62

Slide 62 text

Pattern: Continuous conversational “governance”

Slide 63

Slide 63 text

Continuous conversational governance Initiate Plan Execute Close Analysis Test / Design / Build Release Release Release Release Release Release Release Architecture C.o.P. Continuous conversation Agile/lean/DevOps/Continuous Delivery driven project

Slide 64

Slide 64 text

Continuous conversational governance A single product Architecture C.o.P. Continuous conversation

Slide 65

Slide 65 text

Continuous conversational governance across value streams Value stream B Value stream C Value stream A Value stream E Value stream F Value stream D Value stream M Value stream N Business unit Architecture C.o.P. Architecture centre of excellence

Slide 66

Slide 66 text

D Practicing DevOps at Enterprise Scale

Slide 67

Slide 67 text

Continuous conversational governance Architecture C.o.P. Architecture centre of excellence Enterprise scope Longer term timeframe Service management C.o.E.

Slide 68

Slide 68 text

Intention Reflection Working code deployed as running system Model storming Emergent design Discoverability & observability tooling Test-driven design Infrastructure-as- code Architecture decision records Continuous refactoring Whiteboard sessions Continuous conversational governance (after Ruth Malan)

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

E Curating the Evolution of Enterprise Architecture and Organisation

Slide 71

Slide 71 text

Continuous attention to technical excellence and good design enhances agility.

Slide 72

Slide 72 text

Evolutionary architecture fitness functions at enterprise level (“macro architecture”) •Number of 2-pizza teams required to implement a typical business feature - sociotechnical coupling & cohesion •Asynchronous connections ÷ synchronous connections

Slide 73

Slide 73 text

Theory #1 : gradual evolution Time Evolution

Slide 74

Slide 74 text

Theory #2 : punctuated equilibria Time Evolution

Slide 75

Slide 75 text

Reconciled: punctuated gradualism Continuous attention to complexity debt pay down and continuous improvement. Continuous funding. A step change: a business case explicitly to rewrite (or buy, or outsource, or write something new). Standalone funding. Time Evolution

Slide 76

Slide 76 text

Strangler fi g pattern

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

A B C D E Aligning Value, People and Technology Architecting for Outcomes: Better Value, Sooner, Safer, Happier Governing Continuously: Conversational and Automated Practicing DevOps at Enterprise Scale Curating the Evolution of Enterprise Architecture and Organisation • Conway’s law ++ and reverse Conway manoeuvre • Removing complexity and increasing autonomy • Enterprise architecture as politics and diplomacy • Outcomes of quality, fl ow, safety to balance pure “value” • Happier customers, colleagues, citizens & climate • Continuous improvement - be the best at being better • A stream of continuous architecture decisions • Moving decisions down into the right level of the org • Automating common top-level system policies • Learning by observing: intention & re fl ection • Humility in architecture: all decisions are contingent • Fitness functions for socio-technical architecture at scale • Evolving fast and slow Modern Enterprise Architecture

Slide 79

Slide 79 text

Thank you! @sirohrer