Services · Methods
Architecture methods and measures
The working tools behind the services: how architecture governance can make teams faster instead of slower, and how to tell whether the flow of work is actually improving. None of it is a framework to install. Each method is small, and each is only worth having if teams use it without being asked.
Methods
Architecture guardrails
A handful of principles the organization has actually agreed on, written so a team can check a decision against them without asking anybody. Guardrails are not fences. They mark where a team can move freely, so the few things that do need a conversation stand out.
The test of a guardrail is whether a team can apply it on a Tuesday afternoon without an architect in the room. If it needs interpreting every time, it is an opinion, not a guardrail.
Read more: How Guardrails Empower Teams
Architecture decision records
A short, dated note for each decision that matters: the context, the options that were considered, what was chosen, and what it costs. Decision records keep guardrails honest — they show when a principle was set aside and why — and they are how the next team learns what was already settled instead of re-arguing it.
They also shorten decision latency. A question that has been answered once, in writing, does not have to wait for a meeting the second time.
Read more: Settling the Few Things · Michael Nygard: Documenting Architecture Decisions
Tech radar
A shared, regularly revised view of which technologies to adopt, trial, assess or hold — the format Thoughtworks made public with its Technology Radar. The value is less in the list than in the conversation that produces it: teams see what others have learned, and choices stop being made in isolation.
A radar works as a guardrail for technology — a default that teams can depart from, with a decision record when they do.
Read more: Staying Ahead of the Curve · Thoughtworks Technology Radar
Domain logic placement
Business rules drift into systems that were never meant to own them — a price rule in the checkout, an eligibility rule in the CRM, a discount in the ERP. Each copy is reasonable on its own; together they mean nobody can change the rule in one place.
The method is to map where each rule actually lives today, decide which capability should own it, and move it deliberately. It is where capability design and solution architecture meet.
Read more: Where logic ends up matters · What a Capability Is, and Is Not
Architecture enablement
Guardrails, decision records and a radar only help if teams can use them. Enablement is the coaching and the practice around them: pairing with teams on real decisions until the organization holds architecture as a competence rather than waiting for it in a queue.
Read more: Equipping, Not Reviewing
Flow metrics for organizations
Most measures describe output — how much was built, how fast it shipped. The friction that slows an organization down sits between the teams, in the waiting and the rebuilding, and it needs measures of its own. These four come from Organizational Flow and are reported separately, never summed into a score: a single number acquires a target, and a measure with a target stops measuring.
- Decision latency
- The time from when a decision is needed to when it is made. It rarely shows up in any report, because the wait is spread across calendars and inboxes. Measured for a handful of real decisions, it is often the largest delay in the whole flow.
- Handoff loss
- How much context has to be rebuilt each time work crosses a boundary — between teams, systems or suppliers. It shows up as clarifying questions, rework and meetings whose only purpose is to explain what someone else already knew.
- Ownership clarity
- Whether the people around a capability can name who owns it, and give the same answer. Disagreement here predicts both decision latency and handoff loss.
- Learning cycle time
- How long before the outcome of a choice reaches the person who made it. When it takes a quarter, the organization repeats the same mistake for a quarter.
Read more: Observing Organizations · Key concepts · Self-assessment
DORA and organizational flow
The DORA metrics — deployment frequency, lead time for changes, change failure rate and time to restore — are the best-researched measures of software delivery there are, set out inAccelerate by Nicole Forsgren, Jez Humble and Gene Kim. They describe how well a team gets a change into production once the change is decided.
What they do not show is the time before that: the weeks a change waits for a decision, an owner or another team. A team can have excellent DORA numbers and still deliver slowly, because the delay sits upstream of the pipeline. The two sets of measures belong together — DORA for the delivery, decision latency and handoff loss for the organization around it.
Read more: Optimize for Speed and Deploy with Confidence
Using this in an assignment
These methods are part of the architecture enablement anddiagnostic work TROi offers, on site in the Stockholm area and remotely. Get in touch or write to christoffer.rasten@troi.se.