Subcapability 02 of 05 · Enterprise Architecture

Technical Governance

Architecture Decision Records and fitness functions as code that enable technical autonomy within explicit criteria, replacing the approval committee with verifiable systemic coherence.

What is at stake

Each squad makes technical decisions independently. In six months, integration between areas becomes a two-quarter project because each team chose incompatible approaches. The architect is invited to fix the problem after the cost was already paid. Technical governance that arrives after the damage carries double cost: the remediation work and the work that had to stop for it.

What it is, in practice

Technical governance without explicit criteria produces one of two costly extremes. Cascading approval: every technical decision escalates to someone without context to decide well. Or full autonomy: each team chooses technology, standards and approach without coordination. In both cases, integration and maintenance cost grows without any visible signal until the stack becomes the bottleneck for every initiative.

How we work

Measurable gains

What changes in the result when this subcapability matures.

Frequently asked questions

Are Architecture Decision Records the same as technical documentation?

ADRs document the decision and the reasoning behind it, not the implementation. The difference is that technical documentation explains how something works. An ADR explains why it was done that way, which alternatives were considered and in what context the decision makes sense. When the context changes, the ADR documenting the original decision is the starting point for reassessment.

How to prevent the ADR process from becoming bureaucracy nobody uses?

By limiting scope to genuinely structural decisions, those with high reversal cost, and keeping the format short. A good ADR fits on one page. The criterion for when to write an ADR is simple: if the decision will cost more than one sprint to reverse, it deserves a record. If it fits in a PR comment, it does not need an ADR.

Do fitness functions work with any language and stack?

Fitness functions are language-agnostic. They are automated checks that validate properties of the system: coupling, test coverage by layer, naming convention conformance, build time. Any architectural property that can be measured can become a fitness function. The implementation depends on the stack, but the concept is universal.

How to implement governance in organizations with multiple autonomous teams?

By separating what is a company-wide standard, what is a domain standard and what is team autonomy. Company standards apply to everyone and are few. Domain standards apply to teams that share technical context. Team autonomy covers implementation details. Effective governance defines all three levels clearly.

When does it make sense to have an Architecture Review Board?

When there are recurring decisions with systemic impact and no formal review process. The ARB solves the coordination problem, but only until ADRs and fitness functions document and validate the criteria automatically. As criteria become explicit and verifiable, the ARB can meet less frequently and focus on genuinely new decisions.

Want clarity on where to invest first?

A complete technology capability assessment with an evolution roadmap connected to financial result.