Delivery and product
Give architecture decisions an owner
When every team solves the same problem its own way and nobody owns the whole, the system drifts. We set up a light decision process, a review rhythm and checks that teams actually use.
- Duration
- 4 to 8 weeks
- Model
- Set up and hand over
- Output
- Decision process, reviews and fitness functions
Signs architecture has no owner
Governance problems rarely look like governance problems. They look like slow delivery and repeated arguments.
- Teams solve the same problem, such as authentication, retries or configuration, in several different ways.
- Important decisions live in chat threads and meetings, so they are argued again six months later.
- Nobody can say why a technology was chosen, or whether it is still the standard.
- Architecture reviews, where they exist, happen after the code is written and slow everyone down.
- Dependencies between services grow without anyone deciding that they should.
- New teams start from a blank page instead of a template that already works.
- Security and compliance requirements are checked by hand, late and inconsistently.
Light enough to be used
Heavy governance fails for the same reason that no governance fails: teams route around it. An architecture board that meets monthly and approves slides becomes a queue, and the real decisions move elsewhere.
We set up the lightest process that still leaves a trail. Significant decisions are written as short Architecture Decision Records next to the code. A review rhythm catches decisions early, while they are still cheap to change. Reference templates make the standard path the easy path.
Where a rule matters enough to be enforced, it becomes a fitness function: an automated check in the pipeline that measures dependencies, layering, latency budgets or security settings. Rules that cannot be checked are kept few and explicit.
Scope
Included
- Architecture Decision Record format, storage and workflow
- Review rhythm: what is reviewed, when and by whom
- Decision rights between teams and the architecture role
- Fitness functions in the delivery pipeline
- Reference templates for services, APIs and infrastructure
- Technology radar: adopt, trial, hold
- Inventory of existing decisions worth recording
- Coaching for the people who will run the process
Not included
- Making every architecture decision for your teams
- Organisation design and reporting lines
- Tool procurement
- Running the reviews indefinitely
How the work runs
- Weeks 1 to 2Listen and take inventory. Interviews with teams and leads show where decisions stall and where standards diverge. Existing decisions worth keeping are listed.
- Weeks 2 to 4Design the process. Decision records, review rhythm, decision rights and the first fitness functions are designed with your leads and sized to your organisation.
- Weeks 4 to 6Run it for real. The process runs on live decisions. Templates and checks are added to the pipeline, and the rough edges are fixed.
- Final weeksHand over. The people who will run the process take it over, with a short guide and the first quarter of decisions already on record.
What you receive
The process is designed for your size and lives in your repositories.
Who this service is not for
- A team of a few engineers working in one codebase. At that size, a shared conversation is enough governance.
- Organisations looking for an approval board that slows change down. Our aim is faster, better-recorded decisions.
- Companies that want an external architect to make every decision permanently. For ongoing capacity, see Embedded Architect.
Frequently asked questions
Will this slow our teams down?
It should do the opposite. Most decisions stay with the teams; only decisions that affect other teams or are expensive to reverse go through review, and the review has a time limit.
What is a fitness function?
An automated test for an architectural property. For example, a check that fails the build if a service calls a database it does not own, or if a response time budget is exceeded.
Who runs the process after you leave?
Usually a small group of senior engineers or architects from your teams. We coach them while the process runs for real, so the handover is a continuation, not a restart.
Do you record old decisions too?
Only the ones that still shape the system. Writing down the few decisions everyone keeps asking about saves the most time.
Does this work for remote and distributed teams?
Yes. Decision records and pipeline checks work asynchronously by design, which is why they suit distributed teams well.
Start with a short technical call
Thirty minutes. You describe how decisions are made today, and we tell you what the lightest workable process would look like.