Assessing Architectural Decision-Making Maturity for Decentralization

Why Assess Architectural Maturity?

Before diving into models and charts, it's important to frame why this assessment matters. In your experience, you've likely seen projects suffer from one of two extremes: the "Waterfall Wasteland," where a central architecture review board becomes a bottleneck, stifling progress; or the "Agile Outback," where uncoordinated teams create a chaotic mesh of services that are impossible to maintain or evolve.

Assessing maturity helps you diagnose which anti-patterns are prevalent and provides a common language for discussing improvements. It turns vague feelings of "our process is too slow" or "teams are building inconsistent solutions" into a data-driven analysis. This analysis is fundamental for an architect acting as a change agent, as it provides the evidence needed to justify investments in new processes, tools, or training, and helps prioritize where to focus your efforts for the greatest impact.

A Holistic View: The Responsibilities of an Architecture Function

To begin, it's useful to place decision-making within the broader context of what an architecture function is responsible for. A narrow focus solely on decisions can miss weaknesses in other areas that undermine the entire process.

The Risk and Cost Driven Architecture (RCDA) model, developed by Eltjo Poort, provides a clear, high-level framework. It defines five core responsibilities for a mature architecture function.

As you can see, "Making Decisions" is a central pillar, but it relies heavily on the others. You cannot make good decisions without "Understanding Context," and decisions are of little value if they are not followed through in "Fulfillment." This holistic view is essential for a complete diagnosis.

Deep Dive: Assessing Decision-Making Maturity

Now, let's zoom in on the "Making Decisions" responsibility. A mature organization doesn't just make decisions; it has a sophisticated process for how they are prioritized, timed, justified, and, crucially, delegated.

The RCDA model provides specific behaviors to look for when assessing this area. The most critical concept for our goal of enabling decentralization is the principle of "Decentral unless…".

The "Decentral unless…" principle is the philosophical underpinning of modern, scalable architecture governance. It reframes the architect's role from one of making all important decisions to one of designing a system where decisions can be made safely and effectively at the most local level possible. Your assessment should seek to discover whether the organization defaults to central control or empowered autonomy.

A Practical Adoption Model for Decision-Making

While the RCDA model gives us the "what" to look for, we need a more granular tool to measure the "how." The Architectural Decision (AD) Adoption Model by Olaf Zimmermann provides a five-level maturity scale specifically for the process of making and capturing architectural decisions.

This model is exceptionally useful because it defines a clear progression, allowing you to pinpoint an organization's current level and see a clear path to the next.

The levels in Zimmermann's model are:

1. Undefined and Unconscious: Decisions are intuitive, undocumented, and chaotic.
2. Ad-hoc and Unstructured: Some individuals or teams see the need for ADRs, but practices are inconsistent and localized ("hero-driven").
3. Encouraged and Supported: ADRs are used more systematically for significant issues, minimal templates exist, and there's a community of practice forming. Governance is still somewhat centralized.
4. Systematic, Selective and Diligent: Decision-making is a well-defined process, reviews are mandatory, and tools are integrated. However, governance may still be bureaucratic and centrally managed.
5. Optimized and Rigorous: Decision-making is largely autonomous and decentralized ("Decentral unless..."). Processes are automated, ADRs are widely reused, and the focus is on continuous improvement.

Notice the critical shift between Level 4 and Level 5: it's the transition from a managed, central process to an autonomous, decentralized ecosystem. This is the transformation we are aiming to enable.

Performing the Assessment: A Practical Exercise

Now, let's put this into practice. The goal of an assessment is to create a visual representation—like the spider charts in both resources—that shows the current state ("as-is") versus the desired future state ("to-be"). This gap analysis immediately reveals the key areas for improvement.

Scenario:
Imagine you've just joined a 150-person engineering organization as a principal engineer. You observe the following about their architectural decision-making:

• A few teams use Markdown ADRs stored in their own Git repos, but there is no standard template (Structure, Scope).
• Decisions are made during sprint planning, but there's no formal process for identifying which decisions are "architecturally significant" (Process).
• There's a monthly "Architecture Guild" meeting, but attendance is optional and it's mostly for show-and-tell, not for seeking advice on upcoming decisions (Review Culture).
• There is no central repository or way to search for past decisions across teams (Structure, Tool support).
• New engineers learn about the architecture by asking senior team members (Learning).

Your Task:
Based on this scenario, take a moment to plot the organization on the AD Adoption Model's seven dimensions. For each dimension (Usage, Scope, Structure, etc.), assign a score from 1 to 5 based on the level descriptions. Where does the organization seem to be strongest and weakest?

This exercise highlights that an organization isn't at a single "level," but has varying maturity across different dimensions. In this scenario, the scores for Tooling, Scope, and Review Culture would likely be very low (Level 2), while Process might be slightly higher if some teams are diligent (pushing Level 3).

The result of this assessment directly informs your action plan. The low scores point to the highest-leverage areas for decentralization:

• To improve Scope and Review Culture: You would propose instituting the Advice Process and formalizing the Architecture Guild as a collaborative forum, not a review board.
• To improve Structure and Tooling: You would champion a standard ADR template and a lightweight, searchable ADR log (e.g., using a tool like adr-tools or a shared wiki space).

This is how assessment leads directly to identifying key areas for decentralization: you find the weakest dimensions that are holding back team autonomy and introduce the appropriate lightweight governance mechanisms we discussed previously. For instance, a more mature organization might use clearly defined guardrails, like the ones shown in the "Standard Strength Guidelines" image, to clarify which decisions require central alignment and which do not.

Conclusion

In this lesson, we have developed a structured approach to evaluating an organization's decision-making capabilities. We have seen that maturity is not just about documentation, but about a holistic practice encompassing how decisions are discovered, prioritized, justified, and delegated.

Key Takeaways:

• Maturity Assessment is a Diagnostic Tool: It provides a data-driven basis for identifying weaknesses and building a case for change, moving beyond anecdotal evidence.
• Decision-Making is a Core Responsibility: Use a holistic framework like RCDA's five responsibilities to understand how decision-making fits into the larger architectural function.
• "Decentral Unless…" is the Goal: The North Star for a modern architecture practice is to default to team autonomy, with centralization being a deliberate exception, not the rule.
• Use a Granular Model for Practical Assessment: The AD Adoption Model provides a concrete ladder with seven dimensions to pinpoint an organization's exact strengths and weaknesses in its decision-making process.
• Assessment Informs Action: The output of a maturity assessment is a prioritized list of areas for improvement, which you can then address using the lightweight governance tools from our previous lesson.

Preview of the Next Lesson

Now that we know how to assess an organization's current state and identify opportunities for decentralization, the next logical step is to create a concrete roadmap for change. In our next lesson, we will focus on this final piece of the puzzle: designing a transformation plan for an architecture function to shift from a control-oriented to an enabling role. We will synthesize what we've learned about guardrails, decision-making, and maturity into an actionable plan to guide an organization toward greater autonomy and effectiveness.