The idea behind it
An architecture zoning map borrows from city planning. A city zoning plan says what may be built where, which roads connect districts and which utilities every building must connect to. Applied to a technology estate, zones are business domains with a common purpose and a single owning team, roads are the approved ways services talk to each other, utilities are the shared platforms every service must use, and no-build rules mark what teams must not create themselves. The idea draws on Eric Evans's bounded contexts from domain-driven design, which give each domain its own model and boundary.
The map lets architects govern by rule instead of by review. Teams that build inside a zone, use the permitted roads and consume the shared utilities need no separate approval for each new service. Two rules do most of the work. Each zone owns its data, so no service reads another zone's database directly, a principle known in microservices design as database per service. Cross-zone calls also stay shallow, because long chains of synchronous calls couple services tightly and spread failures. No-build rules prevent teams from rebuilding commodity capabilities such as identity, secret management or payment processing that the organization should buy or share. A deviation then becomes a visible exception rather than a quiet choice.
What's inside
- Six architecture zones, each with a purpose and example services: customer engagement, core business, data and analytics, shared services, infrastructure, and a no-build zone for bought capabilities.
- Integration roads: three permitted patterns and when to use each, with direct database access between zones prohibited.
- Shared utilities every service must use, such as the identity provider, API gateway and secret manager.
- No-build rules, each with its rationale.
- The PowerPoint version has three slides: the zones, the roads and utilities, and the no-build rules.
Format: PDF (2 pages) and PowerPoint file.
A look inside
Page 1 of 2 of the PDF. Select an image to enlarge it.
Who uses it
- Enterprise architects, to publish the estate's building rules on one page instead of reviewing each service.
- Platform engineering teams, to set the shared utilities every service must consume.
- Engineering leads and product teams, to know where a new service belongs and how it may integrate.
- CTOs, to stop duplicate builds of identity, secrets and observability across teams.
When to use it
- Architecture review has become a queue that slows every new service.
- Several teams have each built their own user store, secret handling or logging stack.
- A service reads another domain's database directly and a schema change breaks it.
- An acquisition or platform migration brings in systems that need a place on the map.
- A team proposes building a capability, such as email delivery or payments, that could be bought.
How to use it
Replace the sample zones and services with your own and give the map to teams as the rules for building new services.
- Replace the six sample zones with your own domains, keeping a purpose statement and the services that belong in each.
- Assign each zone to one owning team or team cluster.
- Confirm the permitted integration patterns (synchronous API, asynchronous events and batch) and adjust the named technologies to the ones you run.
- List your shared utilities, such as the identity provider, API gateway, observability platform, secret manager and event bus, with the rule for each.
- Review the no-build rules and their rationales, and decide which capabilities go in your No-Build Zone to be procured as SaaS.
- Publish the map to teams as the rules for new services, and route any deviation through a formal architecture exception.
You leave with: A short map of your estate that tells any team where a new service belongs, how it may connect to others, which shared platforms it must use and what it must not build.
Where it goes wrong
- Drawing zones around the current org chart or systems instead of business purpose and data ownership.
- Allowing direct database access between zones for convenience, which couples their schemas.
- Publishing shared utilities as recommendations rather than mandatory, so teams keep building their own.
- Drawing the map once and never updating it as zones and platforms change.
Get the canvas
It is free. Enter your work email and we send the download link.
Questions
What is architecture zoning?
Architecture zoning divides a technology estate into domains, each with a purpose and an owner, and sets rules for how they connect. It borrows from city planning: zones, roads, utilities and building restrictions. Teams that follow the rules can build without a separate architecture review for each service.
Why prohibit direct database access between domains?
A service that reads another domain's database depends on its internal schema. When the owning team changes the schema, the other service breaks. Sending cross-domain access through an API or event lets each domain change its data store independently.
What belongs in a no-build zone?
Capabilities that the organization should buy rather than build, because they are commodities or carry specialist risk. The template's examples are email delivery, payment processing, HR and CRM, all procured as SaaS. Building one requires a formal architecture exception.