Introduction
In our last lesson, we focused on the practical skill of authoring an Architecture Decision Record (ADR), using the example of a standardized logging strategy that would impact eight different teams. We established that an ADR is not just an artifact of documentation, but a powerful tool for structuring thought and preserving the crucial context behind a decision.
However, documenting a decision is only one part of the equation. When a change, like our logging strategy, cuts across multiple domain boundaries, the process of reaching that decision becomes paramount. How do you empower teams to make such choices without creating chaos or descending into endless committees?
This lesson directly addresses that challenge. Our goal is to identify changes that cross domain boundaries and propose lightweight governance mechanisms for handling them. We will explore how to define those boundaries and then assemble a toolkit of practices that foster alignment and collaboration, shifting the architectural function from a centralized gatekeeper to a distributed enabler.
The Challenge of Cross-Domain Changes
As organizations scale, systems are broken down into domains, often owned by different teams. A "domain" in this context is a cohesive area of business functionality with its own data and logic. A change is "cross-domain" when it cannot be implemented by a single team in isolation—it requires coordination because it affects a shared contract, a common capability, or the workflow of another team.
Without a process for managing these changes, one of two things tends to happen:
- Architectural Gridlock: Fear of breaking things leads to a centralized, slow-moving review board that becomes a bottleneck for all significant work.
- Organizational Chaos: Teams make local optimizations that inadvertently create system-wide problems, leading to integration failures, duplicated effort, and technical debt.
Visually, we can think of the different ways domains might interact.
The "Full mesh federation" pattern on the left, where every domain is responsible for its own connections, illustrates the potential chaos of unmanaged autonomy. The complexity of N-to-N connections becomes unmanageable. Our goal is to introduce just enough process—lightweight governance—to move towards a more intentional and less complex model without creating the rigid bottleneck of a single "distribution domain" for all decisions.
Identifying Boundaries: The Role of Context Mapping
Before we can manage changes across boundaries, we must first be able to see them. In the world of software architecture, particularly influenced by Domain-Driven Design (DDD), the primary tool for this is the Context Map.
A Context Map is a visualization of the different bounded contexts in your system and the relationships between them. A bounded context is a conceptual boundary within which a specific domain model is defined and consistent. For example, the meaning of "Customer" in a sales context might be very different from its meaning in a support context.
Empowering Teams: Decentralizing Architectural Decision-Making
This article by Nick Tune provides a case study of an organization implementing decentralized decision-making. We'll start with the section describing how they first mapped their system to enable this shift.
Please read the section Creating the Context Map. Pay close attention to how the map helps teams understand dependencies and identify which other teams they need to consult.
As the article highlights, creating a Context Map forces you to make boundaries and ownership explicit. When a team considers a change, they can use the map to answer a critical question: "Who else will be affected?" This act of visualization is the first step in identifying a cross-domain change. The map makes dependencies visible, transforming an abstract organizational structure into a concrete diagram that can guide communication.
Lightweight Governance: A Toolkit for Decentralized Decisions
Once we can identify a cross-domain change, we need a process for handling it. The goal is "lightweight" governance—mechanisms that guide and align rather than command and control. This involves moving away from the architect as a gatekeeper and toward a model of enablement.
Let's explore a set of complementary tools and processes that form a robust framework for this.
1. The Advice Process
The philosophical foundation of lightweight governance is the Advice Process. It is a simple but powerful rule: any person or team can make any decision, but they must first seek advice from everyone meaningfully affected and people with relevant expertise.
Empowering Teams: Decentralizing Architectural Decision-Making
Now, let's look at the core principle that this organization adopted to empower its teams.
Read the section titled The Advice Process. Notice how it shifts authority to the teams while mandating consultation.
The Advice Process is not consensus or democracy. The decision-maker is not obligated to follow the advice, but they are obligated to seek it out and consider it. If they choose to go against the advice, they should document their reasoning—often in an ADR, which perfectly captures this rationale. This strikes a balance between autonomy (speed) and responsibility (alignment).
2. Architectural Principles
If the Advice Process is the "how," then Architectural Principles are the "why." They are a set of shared values and beliefs that guide technical decisions. They articulate what the organization values (e.g., "Build vs. Buy," "Data is a Strategic Asset," "Default to Asynchronous Communication").
Architecting Autonomy at Scale: Raising Teams without Creating ...
This article by Shweta Aggarwal and Ron Klein offers a framework for scaling autonomy. It has an excellent section on how principles function as a "social contract."
Please read the section Architecture principles and guidelines. Focus on how a high-level principle is translated into concrete, actionable guidelines.
When a team proposes a cross-domain change, they should be able to justify it in the context of these principles. The principles provide a common language for debating alternatives and ensure that even when teams act independently, their decisions converge toward a coherent whole.
3. Architectural Forums
To make the Advice Process tangible, you need a venue for discussion. An Architectural Advisory Forum (AAF) or guild meeting serves this purpose. This is not a formal review board that approves or rejects decisions. Instead, it is a collaborative space where teams can:
- Present proposed ADRs for cross-domain changes.
- Share findings from technical spikes or experiments.
- Seek advice from peers and experts.
- Raise awareness of upcoming changes that might affect others.
Empowering Teams: Decentralizing Architectural Decision-Making
Let's return to Nick Tune's article to see how the forum works in practice.
Read the section The Architectural Advisory Forum. Observe that the agenda includes upcoming work (spikes and ADRs), emphasizing early visibility over late-stage gating.
This forum transforms governance from a bureaucratic hurdle into a routine of collaborative learning.
4. Technology-Enforced Governance
While principles and processes are crucial, some of the most effective governance is embedded directly into your tools and platforms. For changes that cross API boundaries, a schema-first or API-first approach provides powerful, automated governance.
In this model, the API contract (e.g., an OpenAPI specification for REST, or a Protobuf schema for gRPC) is defined first, in a language-neutral format, and stored in its own repository. This contract is the source of truth. Changes to it follow a clear process, often involving a pull request that makes the change visible to all dependent teams.
The following video by Michael Bryzek provides an outstanding real-world example of this in action. He describes a system where API definitions are the starting point for all development, and automated tooling provides the governance.
Design Microservice Architectures the Right Way
This talk, "Design Microservice Architectures the Right Way," demonstrates how to build a scalable and maintainable microservices ecosystem. We'll focus on the parts that exemplify technology-enforced governance.
Please watch these three segments: API as a First-Class Citizen: This section explains how API schemas are managed in a dedicated repository. Notice how CI/CD with linters automatically enforces consistency and detects breaking changes before any code is written. Code Generation from Spec: Here, you'll see how client libraries and server stubs are generated from the API specification. This ensures implementations can't deviate from the contract. Automated Dependency Management: This part describes a system that automatically creates pull requests to update dependencies across all microservices, ensuring that changes (like a new client library) are propagated consistently and safely.
This technology-driven approach provides strong guardrails. It makes it easy for teams to do the right thing (use the generated client) and hard to do the wrong thing (violate the API contract). It automates the enforcement of cross-domain rules, which is the very essence of lightweight governance.
Conclusion
In this lesson, we have constructed a comprehensive framework for managing architectural changes that cross domain boundaries. We moved from the challenge of identifying these changes to implementing lightweight mechanisms that promote both autonomy and alignment.
Key Takeaways:
- Identify Boundaries with Context Maps: Before you can manage cross-domain changes, you must make the boundaries and dependencies visible. A Context Map is the primary tool for this.
- Embrace the Advice Process: Shift decision-making authority to teams, but require them to seek advice from affected parties and experts. This is the core principle of decentralized governance.
- Govern with a Toolkit: Lightweight governance isn't a single tool, but a combination of practices:
- Architectural Principles provide the "north star."
- Architecture Forums provide a venue for collaboration.
- ADRs document the decision and its rationale.
- Technology-Enforced Contracts (like API schemas) provide automated guardrails.
- The Goal is Enablement, Not Control: These mechanisms are designed to help teams move faster and more safely, not to slow them down with bureaucracy.
Preview of the Next Lesson
We've discussed how to manage decisions across team boundaries. This logically leads to the next question: how are those team boundaries formed in the first place, and how do they influence the systems we build? In our next lesson, we will dive into the heart of sociotechnical architecture by exploring Conway's Law, which famously states that organizations design systems that mirror their own communication structures. We will see how this law has profound practical implications for system design in large organizations.