Chapter 5: Architecture
Core Finding
High performance is possible with all kinds of systems, provided that systems — and the teams that build and maintain them — are loosely coupled.
Architecture type (mainframe vs. microservices, greenfield vs. legacy) matters far less than architectural characteristics.
System Types and Performance
Researchers studied many system types (greenfield, systems of engagement, systems of record, embedded, mainframe, SaaS, custom in-house, custom outsourced, packaged COTS).
Key findings:
- Low performers were more likely to be working on: (1) custom software developed by another company (outsourced), and (2) mainframe systems they were developing (not integrating against)
- Integrating against mainframe systems was NOT significantly correlated with lower performance
- No significant correlation between most system types and performance
- Greenfield, systems of engagement — no significant advantage over other types
Implication: Focus on architectural characteristics, not implementation details. Microservices on Kubernetes with a tightly coupled design won’t save you.
The Two Critical Architectural Characteristics
Teams in the high-performing group agreed with:
- “We can do most of our testing without requiring an integrated environment”
- “We can and do deploy or release our application independently of other applications/services it depends on”
These two characteristics: testability and deployability.
Loosely Coupled Architecture (2017 finding)
The biggest contributor to continuous delivery in 2017 — larger than test and deployment automation — was whether teams could:
- Make large-scale changes to system design without permission from outside the team
- Make large-scale changes without depending on other teams to make changes in their systems
- Complete their work without coordinating with people outside the team
- Deploy and release on demand, regardless of other services
- Do most testing on demand, without an integrated test environment
- Perform deployments during normal business hours with negligible downtime
In loosely coupled teams: little communication required between delivery teams, architecture allows independent testing, deploying, and changing.
Conway’s Law and the Inverse Conway Maneuver
Conway’s Law: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” (Conway 1968)
Inverse Conway Maneuver: Organizations should evolve their team and organizational structure to achieve the desired architecture. The goal: architecture that supports teams getting work done from design through deployment without high-bandwidth communication between teams.
Architectural approaches that enable this:
- Bounded contexts and APIs to decouple large domains into smaller units
- Test doubles and service virtualization to test services in isolation
- True microservices architecture (but must be strict about testability and deployability)
Warning: Many “SOA” architectures still require testing and deploying services together — these do not enable high performance.
Architecture Enables Scaling
Metric: number of deploys per day per developer.
As developer count increases:
- Low performers: deploy with decreasing frequency per developer
- Medium performers: deploy at constant frequency
- High performers: deploy at significantly increasing frequency per developer
High performance teams scale linearly or better as they add more people. Low performers slow down.
The factors that enable this scaling: generative culture, modular architecture, CD engineering practices, effective leadership.
Tool Choice
When teams can decide which tools they use, it contributes to software delivery performance and organizational performance.
Rationale: Technical professionals make tool choices based on what best completes their work and supports their users. Forcing standardization (approved lists) prevents teams from choosing the most suitable approach.
The nuance: There is a place for standardization — particularly around infrastructure architecture and configuration. The goal is not chaos; it’s ensuring procurement and tool decisions serve engineers, not the other way around.
“When the tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will.”
Infosec example: Making preapproved, easy-to-consume security libraries available lets devs do the right thing without friction.
The Right Role for Architects
Architecture discussions often focus on tools: microservices vs. serverless, Kubernetes vs. Mesos, which CI server.
“What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about.”
Architects should:
- Collaborate closely with engineers who build and operate systems
- Help teams achieve better outcomes
- Provide tools and technologies that enable outcomes — not impose technology for its own sake
- Focus on enabling teams to make changes independently, not on technical choices