Empowering Teams: Decentralizing Architectural Decision-Making

Learning from Slime Mold: A Metaphor for Decentralized Architecture

Image source

Physarum polycephalum, commonly known as slime mold, offers an unexpected lesson for software architects, because it can create a complex and efficient network independently and without a central decision-maker.

Scientists uncovered the remarkable decision-making ability of this single-celled organism by placing food sources in positions corresponding to cities around Tokyo and observing how the slime mold responded.

The slime molds spread out, detecting locally for nutrients and repellents, making local decisions about which direction to go in search of food. Over time, a network of nutrient-carrying tubes emerged that looked remarkably similar to the Tokyo subway system in some places, but was more efficient.

This natural phenomenon challenges the traditional approach, where architectural decisions are often centralized, made sometimes from an ivory tower.

The question becomes: can software teams learn from slime molds to create more effective architectural decision-making processes?

The image above shows how after 26 hours the slime mold had created a similar network to that of the Tokyo subway [Image source]

Our Transformation Journey

Our journey toward decentralized architectural decision-making began in 2020, while wrestling with a familiar problem, a legacy solution with multiple code lines, mixed versions of .NET and different libraries and packages scattered throughout. Manual deployment processes involving Windows installers and file copying were prone to errors and manual environment changes. These errors resulted in slow lead times, with three-to-six-month release cycles, user acceptance testing (UAT) phases, cycles of bug fixing, and minimal value delivery to customers.

The organization set an ambitious goal: re-architect to a cloud-native SaaS platform while adopting modern engineering practices. This transformation required technical changes and a fundamental shift in how architectural decisions were made and implemented across teams.

Establishing Teams for Fast Flow

The first step in the transformation involved restructuring teams based on principles from the book Team Topologies by Matthew Skelton and Manuel Pais. The company established three product engineering teams, an enabling team of SMEs and experts to support the product engineering teams, and a platform team that initially focused on re-platforming, but evolved into a team that now supports engineering teams and reduces their cognitive load.

Drawing from the book “Accelerate: The Science of Lean Software and DevOps”, by Nicole Forsgren, PhD, Jez Humble, and Gene Kim and DORA research, two key capabilities stood out as essential for this transformation: loosely coupled architecture and empowered teams. To support fast flow across teams, the organization needed a loosely coupled architecture that could be distributed across teams, while empowering those teams to solve problems in the best way possible.

The Advice Process: Foundation for Decentralized Decision-Making

The advice process became central to supporting empowered, stream-aligned teams. This process, which has entered Thoughtworks Tech Radar’s trial quadrant, states that any team can make any decision they need to, as long as they have sought advice from all meaningfully affected parties and those with expertise, and record these decisions publicly alongside reasons for going against advice if necessary, including pros and cons.

This simple yet powerful framework shifts decision-making authority to teams while ensuring appropriate consultation and documentation. The shift requires three supporting tools: architectural principles to guide decisions, architectural decision records to document them, and an architectural advisory forum to share and discuss them.

Creating the Context Map: Defining Boundaries and Ownership

Before teams could make independent decisions, they needed clear boundaries and ownership. The product engineering teams inherited a fifteen-year-old legacy platform written in mostly old technologies and different architectural styles, including single-tenant desktop tools. To enable teams to work independently while improving fast flow, they needed an approach to understand the whole system while identifying loosely coupled business areas.

A context map was created by applying domain-driven design principles to identify loosely coupled, business-focused areas known as bounded contexts. The team mapped relationships and contracts between these contexts, visualizing all areas within the system and their interconnections. Each bounded context was then assigned to a specific team, making that team responsible for any re-architecting, new feature development, and bug fixes within that context.

Creating a context map for a legacy system with complex dependencies and contracts between different areas proved challenging. The goal was not to merely identify loosely coupled areas within the system, but to ensure they aligned with business flow, making the context map useful for everyone in the company, including engineers, QAs, product teams, and anyone needing to understand the software architecture and team ownership.

The first view of the context map for the legacy platform, shows the scale and complexity.

Context map definition requires continuous review and refinement to maintain proper alignment. Even after multiple reviews, grey areas and shared contexts remain. Grey areas are parts of the system without clear ownership that cannot be identified as independent, bounded contexts, or parts of existing ones. Shared contexts are those accessed by different teams or across all teams. These areas can become sources of frustration, especially when complex, urgent bugs arise in shared or grey area context situations, the teams refer to as “context map wars.”

Despite these challenges, the context map provides significant benefits. Defining complex dependencies between different bounded contexts empowers teams to be fully aware of the impact of their decisions. When making changes within their bounded context, teams can review the context map to understand what will be affected, which bounded contexts will be impacted, and with which teams they need to consult or collaborate. This leads to more collaborative decision-making processes and motivates teams to consider removing dependencies, resulting in a more loosely coupled architecture.

Grey areas and shared contexts provide valuable insights into parts of the system needing re-architecting. Identifying these areas and marking them as technical debt for prioritized resolution makes everyone’s life easier. The context map builds team ownership for assigned contexts, enabling independent work and planning.

Architectural Principles: Guiding Decision-Making

Architectural principles serve as core ideas that guide how teams think, act, and build software. Company principles were developed through collaborative sessions with various experts and SMEs from across the business, starting with the business strategy presentation and shaping principles accordingly. With shared understanding across engineering, QA, and architecture, the teams created principles to guide their work.

These principles act as the dotted line and shape around what teams build, influencing architectural decisions and guiding decision-making. Our organization developed sixteen architectural principles from the workshop. Each principle includes a clear statement of what it aims to achieve, links to strategic goals from the business strategy, a rationale explaining the benefits, and implications, both positive and negative.

For example, the “isolate tenant database” principle clearly states the approach to tenant isolation, links back to business strategic goals, provides a succinct rationale for quick consumption and recall, and acknowledges implications such as increased hosting costs due to the tenancy approach.

Architectural principles help align teams to business strategy, create consensus across teams, since they are formed by the teams themselves, and become the foundation of decision-making.

Decisions form the core of software architecture, and practicing software architecture means working with decisions. Software development itself represents a constant stream of decisions. In a decentralized decision-making process, everyone contributes to architectural decisions, from developers to architects. For this approach, identifying whether a decision is architecturally significant and will impact the system now or in the future matters more than who made the decision or how long it took.

Recording architectural decisions captures the why behind every what, creating valuable context for future learning and shared understanding. Architectural Decision Records (ADRs) are short documents with a defined format that record a single architectural decision and, most importantly, the rationale behind it.

ADR format includes:

• A unique identifier and title representing the decision itself
• The author, typically from teams with team leads, writes the ADRs
• Status (new, draft, proposed, adopted, or superseded)
• The decision section contains a short, self-explanatory description in one to three sentences.
• Relevant architectural principles that guided the decision
• Context describing factors that triggered the need for the decision
• Alternatives considered, with pros and cons for each option and why they were not chosen
• Consequences of the decision, both positive and negative
• A section to record advice received, including the advice itself, the person who gave it, and the date

ADRs support recording architectural decisions while guiding the decision-making process itself. When teams struggle with confidence in making decisions instantly, drafting an ADR provides structure. The context section serves as a reminder of why the decision is needed and what problem it resolves. The options section allows listing all alternatives with pros and cons, aligning them with architectural principles.

When additional investigation is needed, teams can raise spikes for exploration. For instance, when introducing new technology, where uncertainty about its fit with architecture exists, teams can investigate, share learnings, and build confidence for decision-making. Once ready, the decision is made and recorded along with its consequences.

Timing for seeking feedback or advice depends on the nature of the decision. For impactful decisions affecting multiple system parts, or when lacking business or technical knowledge, seeking advice during the decision-making process yields better results. ADRs are immutable documents; once marked as adopted, they cannot be changed. If a decision needs revision, the previous ADR is superseded and a new one created.

After almost five years, we created more than two hundred ADRs. The documents are kept centralized and organized, initially on wiki pages, but later moved to work items for better management. Notification systems for team channels and emails ensure everyone is informed when ADRs are created or updated. ADRs act as living documentation for the project, with defined formats enforced through templates.

The Architectural Advisory Forum: Sharing and Collaboration

The Architectural Advisory Forum (AAF) represents the company’s weekly meeting and is open to all teams, architects, QAs, and SMEs. The forum follows a set agenda beginning with upcoming spikes, because there is a correlation between team spikes and future decisions. Sharing upcoming spikes provides early visibility to all teams, providing better feedback when decisions are made.

The forum then covers upcoming ADRs that people want to present. While notifications alert teams to new ADRs, the forum provides an opportunity for quick presentations and questions. Additional agenda items include DORA metrics and Azure spend, because both correlate with architectural decisions. Weekly monitoring allows teams to observe the impact of decisions, whether through resource changes affecting costs or performance metrics. Service level objectives (SLO) dashboards have since been added to provide additional visibility.

The First ADR: Lessons from Experience

The first team to make an individual architectural decision, record it in an ADR, and share it at the Architectural Advisory Forum faced unique challenges and responsibilities. The team was assigned ownership of a line of business context, a complex area in the legacy system with numerous dependencies and relationships with other bounded contexts.

This context faced several architectural challenges: a single-tenant monolith desktop tool for creating and managing lines of business, quality issues, limitations requiring frequent development intervention, slow lead time with infrequent production releases, and performance bottlenecks. The team’s solution introduced the line of business as a microservice with its own datastore and default configuration.

This decision brought significant architectural transformation. Introducing the line of business as a microservice meant applying all microservice principles, including having a single Azure Cosmos DB per microservice. This introduction represented a move from one shared SQL database to multiple Azure Cosmos DBs, requiring data synchronization and dual writes to manage dependencies and contracts with other bounded contexts still relying on the single SQL database. The microservice would be independently deployable and scalable, improving lead time and enabling faster production releases.

The experience of making this first decision brought mixed emotions. The empowerment to work with architecture and make architectural decisions was exciting, like shopping with everything on sale, wanting to try every new technology and architectural style. However, the responsibility was significant, with the awareness that the decision impacted teams, and required extensive conversations to understand and resolve dependencies.

From the program leadership perspective, watching teams make independent decisions felt like being the first test driver in a Tesla using autopilot and hoping to avoid crashing. Staying out of decisions required conscious effort to avoid undermining the advice process and resorting back to make the decisions for the team. The flood of messages from concerned stakeholders needed redirection back to the ADR process and AAF rather than informal channels.

When presented at AAF, the ten-minute presentation extended to over an hour due to extensive questions and dynamic discussion. The magnitude of the change generated diverse opinions, leading to substantial feedback in the ADR’s advice section. Offline conversations continued with advisors to understand their views and consider their feedback. Despite strong disagreement from some parties and concerns from supporters, the team ultimately adopted the decision without changes.

Reflecting on this first ADR reveals areas for improvement. The decision missed a stronger connection to product vision because it involved both architectural and product decisions. Not all participants in the advice process understood the overall product vision, limiting their ability to provide effective feedback aligned with product direction. This lack of understanding led to the creation of product decision records linked with ADRs when necessary.

With current knowledge, a more iterative approach would be preferable, making smaller decisions with multiple ADRs for faster feedback and greater flexibility. Getting more advice during the decision-making process rather than waiting for AAF has become standard practice. Collaborating early with affected teams and domain experts while distinguishing between advice and opinion remains crucial for effective decision-making.

The Decision-Making Evolution

Teams experiencing decentralized decision-making follow a predictable pattern through four distinct phases. Initially, teams don’t realize they can make decisions, being accustomed to receiving decisions from others. They seek approval and rubber stamps that don’t come, requiring leadership to hold strong and break from centralized decision making.

Once teams realize their autonomy, decisions begin flowing. They explore new technologies, frameworks, libraries, practices, and patterns with excitement and energy. The process comes to life with visible momentum.

The third phase arrives when teams feel the impact of their decisions. Large, complex decisions reveal their consequences, and teams learn from both good and bad choices, a necessary part of growth that all architects experience.

Finally, the system self-corrects and reaches equilibrium. Teams hold each other accountable, questioning decisions, giving feedback, and actively seeking input. Well-thought-out ADRs come to AAF, and experienced teams provide guardrails for new teams and members joining the organization.

Benefits and Outcomes

Decentralized architectural decision-making improves trust and transparency throughout the organization. Teams need trust that they will make appropriate decisions, that are perhaps not always perfect, but with commitment to making the best choices given circumstances and constraints. Transparency in sharing decisions and seeking advice becomes fundamental to the process.

Better alignment between teams emerges as they work independently while building ownership for their bounded contexts. Architectural principles guide teams to follow the overall architectural vision, reminding them they are working on the same product rather than in silos, making decisions about their specific contexts while contributing to the whole.

Decentralized decision-making leads to stronger architectural decisions through collaboration and sharing. It supports fast flow as teams work independently and more efficiently. The approach does not eliminate the need for architects. Teams still require support from experienced architects who can facilitate workshops like event storming, threat modeling, and risk storming.

Architects serve as conduits between teams, spotting connections and impacts that individual teams might miss. They engage with complex, interesting problems, freed from routine decision-making to focus on challenges requiring their expertise.

Conclusion

Our company’s transformation from centralized architectural control to decentralized decision-making demonstrates that teams, like slime molds, can create efficient, adaptive systems through local autonomy within structured frameworks. The combination of context mapping, architectural principles, ADRs, and advisory forums provides the necessary scaffolding for teams to make confident decisions while maintaining architectural coherence.

After five years and over two hundred ADRs, the evidence is clear: empowered teams make stronger decisions through mandatory consultation and transparent documentation than through traditional approval hierarchies.

While the journey involves predictable challenges, from initial disbelief to eventual self-correction, the outcomes justify the investment. Teams achieve faster delivery, better alignment, and increased ownership, while architects focus on complex problems and cross-team facilitation rather than routine approvals.

Organizations considering this approach should prepare for the cultural shift required, but can expect significant improvements in both technical decision quality and team engagement. The lesson from both nature and our experience is compelling: distributed intelligence, properly supported, outperforms centralized control.