book

Architecture Modernization

Name: Architecture Modernization
ISBN: 9781633438156

by Jean-Georges Perrin, Nick Tune

February 2024

Intermediate to advanced

488 pages

16h 26m

English

Manning Publications

Read now

Unlock full access

Inside front cover
Architecture Modernization
Copyright
dedication
contents
front matter
forewordsprefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A road mapHow to read this bookliveBook discussion forumabout the authorsabout the cover illustration
1 What is architecture modernization?
1.1 Architecture is more than technologies and patterns1.2 Independent value streams: The building blocks of modern architecture1.2.1 Minimizing change coupling with well-defined domain boundaries1.2.2 Architecting at multiple scopes for global optimization1.3 Modernization as a portfolio-driven evolutionary journey1.4 Topics not covered in this bookSummary
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 mindset2.2.1 Prepare to embrace Conway’s law2.2.2 Prepare to embrace collaborative architecture practices2.2.3 Prepare to connect architecture and strategy2.2.4 Prepare to move beyond business and IT silos2.3 Industry example: Hitting the right note—modernizing music royalty processing at ICE2.4 Beware of modernization silver bullets2.4.1 Beware of bolt-on modernization2.4.2 Beware of the structure and process fallacy2.4.3 Prepare to invest in quality technical practices2.5 Prepare to support leaders at all levelsSummary
3 Business objectives
3.1 Business justifications for architecture modernization3.1.1 Falling behind faster-moving competitors3.1.2 Architecture stifling business growth3.1.3 Pursuing an exit strategy3.1.4 Growth by acquisition3.1.5 Poor UX holding the company back3.1.6 Inefficient internal tooling and processes3.1.7 Improving hiring and retention3.2 Connecting modernization to growth strategies3.2.1 Growth strategy: Product development3.2.2 Growth strategy: Market penetration3.2.3 Growth strategy: Market development3.2.4 Growth strategy: Diversification3.3 Identifying north stars3.3.1 Choosing the right north star3.3.2 Using a north star framework3.3.3 Industry example: North stars at DanskeSummary
4 Listening and mapping tours
4.1 Who to meet4.2 Who conducts the tour?4.3 Conducting an effective tour4.3.1 Create a safe space4.3.2 Harness a toolbox of techniques4.3.3 Structured vs. unstructured discussions4.4 Bringing groups together4.4.1 Industry example: Clinical oncology structured exploration workshop4.4.2 Industry example: Kickstarting modernization in a large Scandinavian enterpriseSummary

5 Wardley Mapping
5.1 The Strategy Cycle5.2 Creating a Wardley Map5.3 Grasping evolution5.3.1 Evolution characteristics5.3.2 Rapid learning exercise: Grasping evolution5.4 Climatic forces5.4.1 Everything evolves5.4.2 Components coevolve5.4.3 Past success breeds inertia5.4.4 Change is not always linear5.4.5 Assessing the effect of climatic changes5.5 Making strategic decisions5.5.1 Accelerators to evolution5.5.2 De-accelerators to evolution5.5.3 Market playsSummary
6 Product taxonomy
6.1 Defining the building blocks6.1.1 Independent value streams6.1.2 Domains6.1.3 Products6.1.4 Platforms6.1.5 Product groups and portfolios6.1.6 Industry example: Salesforce product taxonomy (2017)6.1.7 Building blocks cheat sheet6.2 Designing a product taxonomy6.2.1 Start with the easier parts6.2.2 Use appropriate techniques6.2.3 Expect constant evolution6.2.4 Distribute design responsibility6.3 Mapping modernization opportunities, risks, and challenges6.3.1 Dependencies and misaligned boundaries6.3.2 Unclear or lacking ownership6.3.3 Skills gaps6.3.4 Product and domain modernization6.3.5 Complexity and cognitive load6.3.6 Macrolevel constraints and challenges6.4 What is a product?6.4.1 Products vs. features vs. components6.4.2 Products vs. variants vs. journeys6.4.3 Product modeSummary
7 Big picture EventStorming
7.1 Understanding EventStorming7.1.1 Notation7.1.2 Chaotic exploration7.1.3 Optimized for learning and collaboration7.1.4 When to use EventStorming7.2 Running an EventStorming session7.2.1 Planning a session7.2.2 Preparing the space7.2.3 Kicking off the session7.2.4 Building the timeline7.2.5 Sorting the timeline7.2.6 Timeline walk-through7.3 Surfacing problems and opportunities7.3.1 Problems7.3.2 Opportunities7.3.3 Addressing problems and opportunities7.4 Facilitator tips and challenges7.4.1 Modeling heuristics7.4.2 Common challengesSummary
8 Product and domain modernization
8.1 Industry example: Business property tax modernization8.2 Identifying product requirements8.2.1 Involve the right people8.2.2 Identify the costs of not modernizing8.2.3 Don’t mindlessly reverse-engineer the code8.2.4 Analyze system information8.2.5 Spend time with real users8.2.6 Continuous discovery8.2.7 What have people given up asking for?8.2.8 We’ve always done it that way8.2.9 Finding shadow IT8.2.10 Industry example: Department for Levelling up, Housing, and Communities8.3 Modernizing the domain model8.3.1 Industry example: Royalties domain modeling8.4 Process modeling EventStorming8.4.1 Notation8.4.2 Planning a workshop8.4.3 Facilitating a workshop8.5 Domain Storytelling8.5.1 Notation8.5.2 Planning and facilitating a workshop8.5.3 Replaying stories8.5.4 When to use Domain StorytellingSummary
9 Identifying domains and subdomains
9.1 The value of good domain boundaries9.2 Domain identification principles9.2.1 Domain boundaries depend on your goals9.2.2 Concepts can be coupled by multiple characteristics9.2.3 Not all dependencies are equally costly9.2.4 Explore multiple models9.2.5 Industry example: The British Broadcasting Corporation9.2.6 Don’t rely on superficial knowledge9.2.7 Good boundaries are not a panacea9.2.8 Prepare for constant evolution9.3 Domain boundary heuristics9.3.1 The five guiding domain-boundary heuristics9.3.2 Subdomain boundary heuristics9.3.3 Subdomain grouping heuristics9.3.4 Industry example: Airline domain decomposition9.4 Identifying domains and subdomains with EventStorming9.4.1 Pivotal events9.4.2 Chunking the timeline9.4.3 Looking for scattered subdomains9.4.4 Subdomains versus user journeys/processes9.4.5 Analyzing subdomains9.4.6 Planning a series of workshopsSummary
10 Strategic IT portfolio
10.1 Utility vs. strategic IT dichotomy10.1.1 Tailored operating model10.1.2 Identifying strategic IT10.2 Core Domain Charts10.2.1 Example Core Domain Chart10.2.2 Assessing model complexity10.2.3 Core domain evolution10.2.4 Industry example: Events industry scale-up10.2.5 Comparisons with Wardley Mapping10.3 Core Domain Chart patterns10.3.1 Decisive core10.3.2 Indefensible core10.3.3 Big bet future core10.3.4 High-leverage supporting10.3.5 Table stakes supporting10.3.6 Mission-critical supporting10.3.7 Suspect supporting10.3.8 Hidden core10.3.9 Black swan core10.3.10 Portfolio patterns10.4 Industry example: Strategy-aligned architecture at VintedSummary
11 Team Topologies
11.1 Team Topologies principles11.1.1 Sustainable fast flow11.1.2 Small, long-lived teams as the standard11.1.3 Team-first thinking11.1.4 You build it, you run it11.1.5 Good boundaries minimize cognitive load11.1.6 Embrace Conway’s law11.2 Team Topologies patterns11.2.1 The four team types11.2.2 The three interaction modes11.2.3 Industry example: Global cosmetics brand11.3 Validating candidate value streams11.3.1 Independent service heuristics11.3.2 Mandate levels11.3.3 Good product team/bad product team11.4 Sensing and evolving team topologies11.4.1 Organizational sensing11.4.2 Industry example: Awkward interactions when becoming multiproduct11.4.3 Evolutionary patterns11.5 Team grouping patternsSummary
12 Loosely coupled software architecture
12.1 Coupling types and strength12.1.1 Local versus global complexity12.2 Modeling architectural flows12.2.1 Model exploration whirlpool12.2.2 Domain Message Flow Modeling12.2.3 Industry example: Modernizing an accounting system12.3 Individual subsystem design12.3.1 Using a canvas12.3.2 Software design EventStorming12.4 Subsystem modernization strategies12.4.1 The modernization strategy selector12.4.2 Migration patterns12.4.3 Assessing current-state complexity12.5 Industry example: Domain-driven modernization of a gigs platform to support new marketsSummary
13 Internal developer platforms
13.1 Developer experience13.1.1 Zero to production in less than a day13.1.2 Roll out the red carpet for teams to do continuous delivery13.1.3 Delightful onboarding experience13.1.4 Frictionless local development experience13.1.5 Industry example: HMRC’s Multi-channel Digital Tax Platform (UK government)13.2 Platform capabilities13.2.1 Golden paths13.2.2 Pipelines and environments13.2.3 Observability13.2.4 Software applications catalog13.2.5 Great platform documentation13.2.6 Security and compliance13.2.7 API management13.2.8 FinOps13.3 Industry example: Platform-powered business model revolution at La Redoute13.4 Managing internal developer platforms13.4.1 Platform as a product13.4.2 Adequately staffed13.4.3 Build vs. curate13.4.4 Technology standardization vs. flexibility13.4.5 Platform engineer experience13.5 When to build a platformSummary
14 Data mesh revolutionizing data engineering
14.1 Setting up the context for complex data14.1.1 The dawn of data engineering14.1.2 New needs around data14.1.3 More problems than solutions14.2 The four principles of data mesh14.2.1 Principle of domain ownership14.2.2 Principle of data as a product14.2.3 Principle of the self-serve data platform14.2.4 Principle of federated computational governance14.2.5 No principle lives in isolation14.3 Building your first data quantum14.3.1 The smallest element with value14.3.2 Logical architecture14.3.3 Your new best friend: The data contract14.3.4 Physical architecture14.4 Navigating through the planes14.4.1 The infrastructure experience plane14.4.2 The data product experience plane14.4.3 The mesh experience plane14.5 First and next stepsSummary
15 Architecture modernization enabling teams
15.1 AMET primary purposes15.1.1 Kickstarting modernization15.1.2 Sustaining modernization momentum15.1.3 Facilitating better design15.1.4 Facilitating long-lasting, durable change15.1.5 Communicating the vision and progress15.1.6 Promoting success stories and learnings15.2 Industry example: Enabling modernization at a European telco15.3 Winding down an AMET15.3.1 Evolving investment and involvement15.3.2 Establishing an architecture operating model15.4 Staffing an AMET15.4.1 Patience and relationship building15.4.2 Should an AMET be full time?15.4.3 Bringing in external help15.5 Empowering an AMET15.6 Naming an AMET15.7 An AMET is not always necessarySummary
16 Strategy and roadmaps
16.1 Think big: Building a compelling vision16.1.1 Crafting a modernization strategy deck16.1.2 Industry example: Building and evolving a modernization strategy at IgluCruise.com16.2 Nail it: Delivering a first slice within three to six months16.2.1 Planning a first slice16.2.2 Choosing where to start16.2.3 When to think about internal developer platforms16.2.4 What if things don’t go to plan?16.3 Scale it: Ramping up modernization16.3.1 Playbooks16.3.2 Seeding and spreading expertise16.3.3 Sequencing modernization work16.3.4 Balancing discovery, design, and delivery16.3.5 Balancing modernization and other work16.3.6 Visualizing and communicating the journey16.4 Continuously assessing and adapting16.4.1 Metrics16.4.2 Pulse surveys16.4.3 Gatherings16.4.4 Continuous feedback channels16.4.5 Spend time with people doing the work16.4.6 Be prepared to make the difficult decisionSummary
17 Learning and upskilling
17.1 Planting seeds17.1.1 Industry example: Planting the DDD seed at a French HR-tech unicorn17.2 Upskilling for upcoming project needs17.3 Establishing a continuous learning environment17.3.1 Communities of practice17.3.2 Regular small learning opportunities17.3.3 Mentoring17.3.4 Empowering influencers17.3.5 Blogging and public speaking17.3.6 Internal conferences17.4 Industry example: Learning-driven modernization at CloudSuiteSummary
index
Inside back cover

Content preview from Architecture Modernization

12 Loosely coupled software architecture

This chapter covers

Minimizing coupling in software architecture
Designing software architecture aligned to the domain
Validating the design of individual subsystems
Determining the optimal level of modernization for each subsystem
Migrating subsystems from the current to the target state

Achieving independent value streams in software development requires a loosely coupled software architecture. Loose coupling in the software means lower change coupling across value streams, resulting in few organizational dependencies that affect flow. For some leaders, grasping the importance of loosely coupled architecture takes time. But there are no quick fixes to address the technical requirements of fast flow; ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781633438156Publisher Support Publisher Website

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Architecture Modernization

by Jean-Georges Perrin, Nick Tune

12 Loosely coupled software architecture

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.