Teams and evolutionary architecture
How team structure shapes systems (Conway's law), who owns what, the roles of enabling and platform teams, and how an evolutionary architect guides change with principles, practices and a paved road.
key idea / coordinatorservice / good pathin progress / watch outproblem / failureneutral
Loosely coupled organizations
Microservices without a matching change in how people are organised blunt the payoff: you pay for the architecture and keep the coordination. Newman borrows a checklist from Accelerate: a loosely coupled team can do all of these on its own.
This is the stream-aligned team: one team owns the end-to-end delivery of a valuable slice of work (a part of the domain), with few hand-offs. Use the six abilities as a test of progress.
From Building Microservices, ch. 15, "Loosely Coupled Organizations".
Conway's law and team structure
Melvin Conway observed in 1968 that an organisation designing a system will produce a design that copies its own communication structure. Four groups on a compiler give a four-pass compiler. So loosely coupled organisations tend to yield loosely coupled systems, and the reverse.
From Building Microservices, ch. 15, "Conway's Law", "Evidence", "Geographical Distribution" and "Conway's Law in Reverse".
Small teams and autonomy. Most developers want teams of roughly 5 to 10; Newman cites a study finding productivity worst for projects averaging 9 or more. But adding people does not scale delivery by itself: adding manpower to a late project makes it later (Brooks). The real cost at scale is coordination.
- Amazon's two-pizza team is about autonomy, accountability and an owner mindset, not about headcount.
- Netflix built small independent teams on purpose, so the services would be independent.
- Dunbar and W. L. Gore: keep units under about 150 people so everyone knows each other. Timpson cut its rulebook to two rules and lets stores decide.
- Do not copy blindly (two-pizza teams, "Spotify model"): understand why a model works first.
From Building Microservices, ch. 15, "Team Size", "Small Teams, Large Organization", "On Autonomy" and "People".
Strong versus collective ownership
Strong ownership: one team owns a microservice and decides every change; outsiders ask or send a pull request the owner may accept. Collective ownership: any team may change any service, so teams must coordinate closely.
- Inside a team: collective ownership is healthy. Everyone can change the code.
- Between teams: prefer strong ownership for autonomy. Mix them: let teams pick a language but fix the cloud platform.
- Full life-cycle ownership goes further: one team designs, changes, deploys, runs and retires the service, with no tickets to other groups.
- Local choices still need coordination when they affect others, such as an API style other teams must call.
From Building Microservices, ch. 15, "Strong Versus Collective Ownership" and "Balancing Models".
Enabling, platform teams and communities
Autonomous teams still need help. The Team Topologies vocabulary used in the book names the supporting cast around stream-aligned teams:
| Group | Job | Time commitment |
|---|---|---|
| Enabling team | Surveys what teams do, connects people, spots shared pain (e.g. test data), helps rebalance local versus global choices | Full-time or ring-fenced |
| Community of practice | Peer sharing and learning across teams | A few hours a week; fluid membership |
| Platform team | Self-service tooling: desired-state deployment, log aggregation, service-to-service auth | Full team; has users |
The platform team's users are developers, so it should collect their feedback, and judge itself by how easy shipping becomes, not by the platform it builds. As one Uswitch story put it, the company did not change its organisation to adopt Kubernetes; it adopted Kubernetes to change its organisation.
From Building Microservices, ch. 15, "Enabling Teams", "Communities of Practice" and "The Platform".
Shared microservices and internal open source
One service per team is the goal, yet shared services are common. Understand why before fixing it.
You can also add people to the owning team, which is easier on a standardised stack. Internal open source copies the open source model: a small group of core committers owns the service and vets patches from outside the team. The reviewers must keep quality and consistency, and also be helpful, not gatekeepers who throw their weight around.
| Factor | Guidance |
|---|---|
| Maturity | Open a service to outside patches once its core is stable and changes are rare; an unstable service has no clear definition of a good patch |
| Tooling | Pull requests, inline review comments, and easy build and deploy via pipelines and a central artifact store |
| Reviews | Peer review (Accelerate: better results than external approval boards); pairing is the quickest form |
| Orphaned services | Teams aligned to bounded contexts still own quiet services; small services are cheap to rewrite |
From Building Microservices, ch. 15, "Shared Microservices" through "The Orphaned Service".
Case study: realestate.com.au
Newman's 2014 snapshot of REA (an example, not a template) shows structure and architecture aligned.
Because each line of business could rely on coarse, batch-style integration, it could take its services down at will. Autonomy applied to both the teams and the parts of the business, and services grew from a handful in 2010 to hundreds by 2014.
From Building Microservices, ch. 15, "Case Study: realestate.com.au".
The evolutionary architect
Architecture is the shape of the system. It happens by design or by accident, and "architecture" is also a social construct: it is the part of the design that the people building it understand and share. The architect owns the technical vision and sees the whole system, not just one facet.
Newman's image is the town planner (from Erik Doernenburg), not the designer of one building. A planner sets zones and the movement between them, and does not say which building goes where.
- Making change possible: like Mies van der Rohe's skyscraper with a fixed service core and flexible floors, fix the hard-to-change essentials and leave space to adapt.
- Architecture is not only "the hard-to-change" stuff: it also creates room for change in the design.
- Habitability: the environment, tools and practices must be pleasant to work in. Involve developers in choices and spend real time with teams: half a day per team every few weeks, doing normal work.
- Inside a zone, teams may vary technology (watch hiring and movement of people). Between zones, avoid mixing REST, gRPC and RMI.
From Building Microservices, ch. 16, "What Is Software Architecture?", "Making Change Possible" to "Habitability".
Goals, principles, practices and standards
To decide well without being everywhere, give people a small framework. Strategic goals say where the business is going. Principles are a few rules that serve those goals. Practices are detailed, usually technology-specific, and change more often.
| Level | Example | Changes |
|---|---|---|
| Goal | Cut time to market for features | Rarely |
| Principle | Teams control the full life cycle and ship independently | Sometimes |
| Practice | Deploy each service into its own isolated cloud account | Often |
| Constraint | We run on Azure | Hard to change; revisit now and then |
Large organisations can have different practices per place (a .NET set and a Java set) under the same principles. Check progress with fitness functions from Building Evolutionary Architectures: measure a property, such as response time under 100 ms, and investigate when it leaves bounds. They support, not replace, talking to the people building it.
From Building Microservices, ch. 16, "A Principled Approach" to "Guiding an Evolutionary Architecture".
The required standard. Autonomy has limits. Decide what every microservice must do so the whole is cohesive and one bad service cannot hurt everyone.
Interfaces: one standard is good, two is tolerable, twenty is not. Safety: if one service returns a success code for an error, circuit breakers elsewhere stop working, so response codes must mean what they say.
From Building Microservices, ch. 16, "The Required Standard" to "Architectural Safety".
Governance and the paved road
Technical governance is agreeing how things are done, making sure people know, and making sure it happens. It should be a group activity led by those doing the work, and it reviews principles and tracks technical risk. The architect's best tool is making the right thing the easy thing: the paved road.
| Tool | What it is | Caution |
|---|---|---|
| Exemplars | Real services in production that get things right, to imitate | Use real, used services, not toy "perfect" examples |
| Tailored template | A starter (e.g. Spring Boot plus your libraries, health, metrics, auth, pipeline) | Can become a mandated monster; ideally optional, open to contributions. Shared code couples services |
| Service mesh / sidecar | Offload common behaviour from the template | Netflix uses sidecars for non-JVM services |
Netflix (JVM) and Monzo (Go) speed up new services by standardising a stack; a template per language would be needed otherwise, which quietly narrows language choice.
From Building Microservices, ch. 16, "Governance and the Paved Road", "Exemplars", "Tailored Microservice Template" and "The Paved Road at Scale".
Technical debt, exceptions and your team
Sometimes the vision loses to the deadline. That is technical debt: a short-term gain with an ongoing cost, which you want to pay down. Debt also appears when the vision changes and old parts no longer match. At REA, product owners were judged on features, so technical debt grew until they were also made accountable for technical health.
- Debt: keep a view of how much exists. Light guidance may do, or a regular debt log.
- Exceptions: record them; if they pile up, change the rule. In high-trust teams with light principles you may not need this.
- Architect in a stream-aligned org: often part of an enabling team, connecting people and adapting the vision, not commanding.
- Build your team: many small services give people places to step up and own something, easing the load on you.
From Building Microservices, ch. 16, "Technical Debt", "Exception Handling", "Architecture in a Stream-Aligned Organization" and "Building a Team".
Recap
- Pair microservices with autonomous, stream-aligned teams or the benefit shrinks.
- Conway's law: system structure copies communication structure; it can run in reverse too.
- Coordination is the main cost at scale; small teams with strong ownership reduce it.
- Collective ownership is good inside a team, strong ownership between teams.
- Enabling teams, communities of practice and a platform team support stream-aligned teams; guide rather than mandate.
- Shared services: understand why, then consider splitting, internal open source or pluggable modules.
- The architect is a town planner: set zones and standards between boxes, keep the inside flexible.
- Goals, few principles, changing practices; paved road, exemplars and optional templates; log debt and exceptions.
Quick check
Show answer
Features need all three teams, with hand-offs and coordination, and the system will mirror those layers. Reorganise around slices of the domain (stream-aligned teams) to change the design.
Show answer
If the platform is hard to use or does not fit, teams bypass it and lose the reasons behind the rules. Explain the rules and make the platform the easy path.
Show answer
The practices: they are low-level and technology-specific, so they change more often. The principles should stay stable.