Architecture Modernization: Socio-technical alignment of software, strategy, and structure

brief contents
contents
forewords
preface
acknowledgments
about this book
Who should read this book
How this book is organized: A road map
How to read this book
liveBook discussion forum
about the authors
about the cover illustration
1 What is architecture modernization?
1.1 Architecture is more than technologies and patterns
1.2 Independent value streams: The building blocks of modern architecture
1.2.1 Minimizing change coupling with well-defined domain boundaries
1.2.2 Architecting at multiple scopes for global optimization
1.3 Modernization as a portfolio-driven evolutionary journey
1.4 Topics not covered in this book
Summary
2 Preparing for the journey
2.1 Is leadership prepared?
2.1.1 Are business and product leaders truly ready to slow down the delivery of new features to allow modernization?
2.1.2 Do leaders understand that legacy systems and ways of working are complex and difficult to change?
2.1.3 How will leaders react when the unexpected occurs (which is inevitable) and there are major delays or increased costs?
2.1.4 Are leaders ready to change how they work? Can you imagine leadership supporting changes to funding models, work prioritization, and development processes and empowering teams to make more decisions?
2.1.5 Are leaders willing to invest sufficient time and funds into learning and training for all employees so that they can carry out modernization skillfully?
2.1.6 Will technologists be able to articulate to business leaders and other stakeholders the business and organizational benefits of their ideas?
2.2 Prepare to embrace a new architecture mindset
2.2.1 Prepare to embrace Conway’s law
2.2.2 Prepare to embrace collaborative architecture practices
2.2.3 Prepare to connect architecture and strategy
2.2.4 Prepare to move beyond business and IT silos
2.3 Industry example: Hitting the right note—modernizing music royalty processing at ICE
2.4 Beware of modernization silver bullets
2.4.1 Beware of bolt-on modernization
2.4.2 Beware of the structure and process fallacy
2.4.3 Prepare to invest in quality technical practices
2.5 Prepare to support leaders at all levels
Summary
3 Business objectives
3.1 Business justifications for architecture modernization
3.1.1 Falling behind faster-moving competitors
3.1.2 Architecture stifling business growth
3.1.3 Pursuing an exit strategy
3.1.4 Growth by acquisition
3.1.5 Poor UX holding the company back
3.1.6 Inefficient internal tooling and processes
3.1.7 Improving hiring and retention
3.2 Connecting modernization to growth strategies
3.2.1 Growth strategy: Product development
3.2.2 Growth strategy: Market penetration
3.2.3 Growth strategy: Market development
3.2.4 Growth strategy: Diversification
3.3 Identifying north stars
3.3.1 Choosing the right north star
3.3.2 Using a north star framework
3.3.3 Industry example: North stars at Danske
Summary
4 Listening and mapping tours
4.1 Who to meet
4.2 Who conducts the tour?
4.3 Conducting an effective tour
4.3.1 Create a safe space
4.3.2 Harness a toolbox of techniques
4.3.3 Structured vs. unstructured discussions
4.4 Bringing groups together
4.4.1 Industry example: Clinical oncology structured exploration workshop
4.4.2 Industry example: Kickstarting modernization in a large Scandinavian enterprise
Summary
5 Wardley Mapping
5.1 The Strategy Cycle
5.2 Creating a Wardley Map
5.3 Grasping evolution
5.3.1 Evolution characteristics
5.3.2 Rapid learning exercise: Grasping evolution
5.4 Climatic forces
5.4.1 Everything evolves
5.4.2 Components coevolve
5.4.3 Past success breeds inertia
5.4.4 Change is not always linear
5.4.5 Assessing the effect of climatic changes
5.5 Making strategic decisions
5.5.1 Accelerators to evolution
5.5.2 De-accelerators to evolution
5.5.3 Market plays
Summary
6 Product taxonomy
6.1 Defining the building blocks
6.1.1 Independent value streams
6.1.2 Domains
6.1.3 Products
6.1.4 Platforms
6.1.5 Product groups and portfolios
6.1.6 Industry example: Salesforce product taxonomy (2017)
6.1.7 Building blocks cheat sheet
6.2 Designing a product taxonomy
6.2.1 Start with the easier parts
6.2.2 Use appropriate techniques
6.2.3 Expect constant evolution
6.2.4 Distribute design responsibility
6.3 Mapping modernization opportunities, risks, and challenges
6.3.1 Dependencies and misaligned boundaries
6.3.2 Unclear or lacking ownership
6.3.3 Skills gaps
6.3.4 Product and domain modernization
6.3.5 Complexity and cognitive load
6.3.6 Macrolevel constraints and challenges
6.4 What is a product?
6.4.1 Products vs. features vs. components
6.4.2 Products vs. variants vs. journeys
6.4.3 Product mode
Summary
7 Big picture EventStorming
7.1 Understanding EventStorming
7.1.1 Notation
7.1.2 Chaotic exploration
7.1.3 Optimized for learning and collaboration
7.1.4 When to use EventStorming
7.2 Running an EventStorming session
7.2.1 Planning a session
7.2.2 Preparing the space
7.2.3 Kicking off the session
7.2.4 Building the timeline
7.2.5 Sorting the timeline
7.2.6 Timeline walk-through
7.3 Surfacing problems and opportunities
7.3.1 Problems
7.3.2 Opportunities
7.3.3 Addressing problems and opportunities
7.4 Facilitator tips and challenges
7.4.1 Modeling heuristics
7.4.2 Common challenges
Summary
8 Product and domain modernization
8.1 Industry example: Business property tax modernization
8.2 Identifying product requirements
8.2.1 Involve the right people
8.2.2 Identify the costs of not modernizing
8.2.3 Don’t mindlessly reverse-engineer the code
8.2.4 Analyze system information
8.2.5 Spend time with real users
8.2.6 Continuous discovery
8.2.7 What have people given up asking for?
8.2.8 We’ve always done it that way
8.2.9 Finding shadow IT
8.2.10 Industry example: Department for Levelling up, Housing, and Communities
8.3 Modernizing the domain model
8.3.1 Industry example: Royalties domain modeling
8.4 Process modeling EventStorming
8.4.1 Notation
8.4.2 Planning a workshop
8.4.3 Facilitating a workshop
8.5 Domain Storytelling
8.5.1 Notation
8.5.2 Planning and facilitating a workshop
8.5.3 Replaying stories
8.5.4 When to use Domain Storytelling
Summary
9 Identifying domains and subdomains
9.1 The value of good domain boundaries
9.2 Domain identification principles
9.2.1 Domain boundaries depend on your goals
9.2.2 Concepts can be coupled by multiple characteristics
9.2.3 Not all dependencies are equally costly
9.2.4 Explore multiple models
9.2.5 Industry example: The British Broadcasting Corporation
9.2.6 Don’t rely on superficial knowledge
9.2.7 Good boundaries are not a panacea
9.2.8 Prepare for constant evolution
9.3 Domain boundary heuristics
9.3.1 The five guiding domain-boundary heuristics
9.3.2 Subdomain boundary heuristics
9.3.3 Subdomain grouping heuristics
9.3.4 Industry example: Airline domain decomposition
9.4 Identifying domains and subdomains with EventStorming
9.4.1 Pivotal events
9.4.2 Chunking the timeline
9.4.3 Looking for scattered subdomains
9.4.4 Subdomains versus user journeys/processes
9.4.5 Analyzing subdomains
9.4.6 Planning a series of workshops
Summary
10 Strategic IT portfolio
10.1 Utility vs. strategic IT dichotomy
10.1.1 Tailored operating model
10.1.2 Identifying strategic IT
10.2 Core Domain Charts
10.2.1 Example Core Domain Chart
10.2.2 Assessing model complexity
10.2.3 Core domain evolution
10.2.4 Industry example: Events industry scale-up
10.2.5 Comparisons with Wardley Mapping
10.3 Core Domain Chart patterns
10.3.1 Decisive core
10.3.2 Indefensible core
10.3.3 Big bet future core
10.3.4 High-leverage supporting
10.3.5 Table stakes supporting
10.3.6 Mission-critical supporting
10.3.7 Suspect supporting
10.3.8 Hidden core
10.3.9 Black swan core
10.3.10 Portfolio patterns
10.4 Industry example: Strategy-aligned architecture at Vinted
Summary
11 Team Topologies
11.1 Team Topologies principles
11.1.1 Sustainable fast flow
11.1.2 Small, long-lived teams as the standard
11.1.3 Team-first thinking
11.1.4 You build it, you run it
11.1.5 Good boundaries minimize cognitive load
11.1.6 Embrace Conway’s law
11.2 Team Topologies patterns
11.2.1 The four team types
11.2.2 The three interaction modes
11.2.3 Industry example: Global cosmetics brand
11.3 Validating candidate value streams
11.3.1 Independent service heuristics
11.3.2 Mandate levels
11.3.3 Good product team/bad product team
11.4 Sensing and evolving team topologies
11.4.1 Organizational sensing
11.4.2 Industry example: Awkward interactions when becoming multiproduct
11.4.3 Evolutionary patterns
11.5 Team grouping patterns
Summary
12 Loosely coupled software architecture
12.1 Coupling types and strength
12.1.1 Local versus global complexity
12.2 Modeling architectural flows
12.2.1 Model exploration whirlpool
12.2.2 Domain Message Flow Modeling
12.2.3 Industry example: Modernizing an accounting system
12.3 Individual subsystem design
12.3.1 Using a canvas
12.3.2 Software design EventStorming
12.4 Subsystem modernization strategies
12.4.1 The modernization strategy selector
12.4.2 Migration patterns
12.4.3 Assessing current-state complexity
12.5 Industry example: Domain-driven modernization of a gigs platform to support new markets
Summary
13 Internal developer platforms
13.1 Developer experience
13.1.1 Zero to production in less than a day
13.1.2 Roll out the red carpet for teams to do continuous delivery
13.1.3 Delightful onboarding experience
13.1.4 Frictionless local development experience
13.1.5 Industry example: HMRC’s Multi-channel Digital Tax Platform (UK government)
13.2 Platform capabilities
13.2.1 Golden paths
13.2.2 Pipelines and environments
13.2.3 Observability
13.2.4 Software applications catalog
13.2.5 Great platform documentation
13.2.6 Security and compliance
13.2.7 API management
13.2.8 FinOps
13.3 Industry example: Platform-powered business model revolution at La Redoute
13.4 Managing internal developer platforms
13.4.1 Platform as a product
13.4.2 Adequately staffed
13.4.3 Build vs. curate
13.4.4 Technology standardization vs. flexibility
13.4.5 Platform engineer experience
13.5 When to build a platform
Summary
14 Data mesh revolutionizing data engineering
14.1 Setting up the context for complex data
14.1.1 The dawn of data engineering
14.1.2 New needs around data
14.1.3 More problems than solutions
14.2 The four principles of data mesh
14.2.1 Principle of domain ownership
14.2.2 Principle of data as a product
14.2.3 Principle of the self-serve data platform
14.2.4 Principle of federated computational governance
14.2.5 No principle lives in isolation
14.3 Building your first data quantum
14.3.1 The smallest element with value
14.3.2 Logical architecture
14.3.3 Your new best friend: The data contract
14.3.4 Physical architecture
14.4 Navigating through the planes
14.4.1 The infrastructure experience plane
14.4.2 The data product experience plane
14.4.3 The mesh experience plane
14.5 First and next steps
Summary
15 Architecture modernization enabling teams
15.1 AMET primary purposes
15.1.1 Kickstarting modernization
15.1.2 Sustaining modernization momentum
15.1.3 Facilitating better design
15.1.4 Facilitating long-lasting, durable change
15.1.5 Communicating the vision and progress
15.1.6 Promoting success stories and learnings
15.2 Industry example: Enabling modernization at a European telco
15.3 Winding down an AMET
15.3.1 Evolving investment and involvement
15.3.2 Establishing an architecture operating model
15.4 Staffing an AMET
15.4.1 Patience and relationship building
15.4.2 Should an AMET be full time?
15.4.3 Bringing in external help
15.5 Empowering an AMET
15.6 Naming an AMET
15.7 An AMET is not always necessary
Summary
16 Strategy and roadmaps
16.1 Think big: Building a compelling vision
16.1.1 Crafting a modernization strategy deck
16.1.2 Industry example: Building and evolving a modernization strategy at IgluCruise.com
16.2 Nail it: Delivering a first slice within three to six months
16.2.1 Planning a first slice
16.2.2 Choosing where to start
16.2.3 When to think about internal developer platforms
16.2.4 What if things don’t go to plan?
16.3 Scale it: Ramping up modernization
16.3.1 Playbooks
16.3.2 Seeding and spreading expertise
16.3.3 Sequencing modernization work
16.3.4 Balancing discovery, design, and delivery
16.3.5 Balancing modernization and other work
16.3.6 Visualizing and communicating the journey
16.4 Continuously assessing and adapting
16.4.1 Metrics
16.4.2 Pulse surveys
16.4.3 Gatherings
16.4.4 Continuous feedback channels
16.4.5 Spend time with people doing the work
16.4.6 Be prepared to make the difficult decision
Summary
17 Learning and upskilling
17.1 Planting seeds
17.1.1 Industry example: Planting the DDD seed at a French HR-tech unicorn
17.2 Upskilling for upcoming project needs
17.3 Establishing a continuous learning environment
17.3.1 Communities of practice
17.3.2 Regular small learning opportunities
17.3.3 Mentoring
17.3.4 Empowering influencers
17.3.5 Blogging and public speaking
17.3.6 Internal conferences
17.4 Industry example: Learning-driven modernization at CloudSuite
Summary
index
A
B
C
D
E
F
G
H
I
K
L
M
N
O
P
R
S
T
U
V
W
X