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.
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
How we work
Active Architecture Decision Records
We implement ADRs as a living practice, not archived documentation: each structural decision documented with context, alternatives evaluated and reasoning, accessible in the repository and consulted before new decisions.
Fitness functions in the pipeline
We automate architectural conformance validation in the delivery pipeline, so that violations of coupling, layering or dependency patterns are detected when they arise, not in a quarterly audit.
Policy as Code with infrastructure criteria
We codify infrastructure policies with Open Policy Agent, making guardrails automatically verifiable at every deployment and eliminating the dependency on manual review for each configuration change.
Decision criteria by choice type
We define what each team decides independently, what requires cross-team alignment and what involves architectural review, so that each decision follows the right process without overloading the architect with what does not need their approval.
Standards review cycle with defined cadence
We establish periodic review of architectural standards at a frequency appropriate to the organization's pace of change, so that ADRs reflect the current state and do not become historical documents nobody consults.
Measurable gains
What changes in the result when this subcapability matures.
Time between architectural proposal and decision
Explicit criteria about what requires review and what can proceed autonomously reduces waiting time for architectural approval. What took weeks of scheduling and meetings now follows a process with defined timeline.
Incidents caused by inconsistent technical decisions across teams
Fitness functions that detect pattern violations in the pipeline prevent inconsistencies between teams from reaching production. Each violation detected at commit time costs less than the same violation discovered in an incident.
Integration cost between systems from distinct teams
Teams operating with shared criteria on interfaces, communication patterns and service contracts produce systems that integrate faster and with less rework than teams that discover incompatibility during integration.
Onboarding speed for new architects or tech leads
ADRs that document the reasoning behind each decision reduce the time a new member takes to understand why the system was built the way it was, replacing oral transfer with a consultable record.
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.
Other subcapabilities in this capability
Systems Anti-Overlap
Portfolio rationalization through the TIME framework that shows the CFO where duplicate licensing, maintenance and integration consume budget without delivering incremental value.
Business Capability Mapping
TOGAF Business Capability Planning and Wardley Mapping that expose the financial consequence of each technology gap and transform investment prioritization from urgency-driven to impact-sequenced.
Technology Radar
Technology Radar four-ring model adapted to organizational context that distinguishes Adopt from Hold with evidence, managing obsolescence risk and controlling stack complexity by intention.
Legacy Modernization
Six Rs migration strategy with Strangler Fig incremental decommissioning that eliminates legacy maintenance and opportunity cost without a big bang project that paralyzes the business for two years.
Want clarity on where to invest first?
A complete technology capability assessment with an evolution roadmap connected to financial result.

