Role
Solution architect
When is an architectural decision made in your company - and will anyone be able to say a year from now why it was that one? Most debt comes from decisions nobody wrote down.
Intro call
Four questions we would start with
When is the decision about a solution made?
If it is at the stage where the requirements are least known, the risk is unavoidable - the question is whether it is named.
What is left behind by an architect who leaves the company?
If it is diagrams without reasoning, the team knows the shape of the solution and not its reasons - and it is the reasons that decide whether something may be changed.
What do you not know about a solution until it reaches production?
Usually: how it behaves under load and what turns out to be hard to maintain. The question is whether the lessons come back anywhere.
Whose desk does an argument about choosing a technology end up on?
And whether that decision has recorded criteria, or rests on authority.
We take over the gathering and the documenting, you keep the decision
Establishing the requirements, laying out the options, maintaining the record of decisions and reviewing consistency can be taken off the desk. Choosing the solution stays with the architect.
- A decision has its criteria and its options recorded. - Not only what was chosen, but what was rejected and why - because that is the part that is useful two years later.
- The options are laid out side by side, not described. - The criteria next to each other, so that the conversation is about trade-offs rather than preferences.
- A departure from the standard is visible. - A solution that does not match the agreed pattern comes up at a review, not during an outage.
Scope
What can be taken off an architect's desk
Eighteen example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to the scale of your solutions.
Establishing the requirements
- The non-functional requirements collected from the project documentation
- Pointing out requirements that contradict each other (assessment: the architect)
- A comparison with the requirements of similar solutions in the company
- Open questions to settle before the decision
Options and decisions
- The options laid out against the agreed criteria
- The decision recorded with its reasoning and the rejected options (content: the architect)
- Linking the decision to the requirements that triggered it
- A register of decisions available to the teams
Standards and patterns
- A catalogue of the patterns used in the organisation
- Pointing out the right pattern for a problem (decision: the architect)
- A signal when a solution departs from the standard
- A register of deliberate departures
Solution reviews
- A list of review questions by type of solution
- A comparison of the design with earlier decisions
- Pointing out the same problem solved repeatedly in different teams
Architectural debt
- A summary of decisions taken conditionally, with a date for revisiting
- Pointing out solutions the teams are working around
- Linking production problems to architectural decisions
A day's work
Today
- You collect the non-functional requirements from several documents and conversations
- You compare the options in your head or in a one-off table
- You record the decision in a deck that is lost once the project ends
- You do not know whether another team has already solved the same problem
- Departures from the standard surface during an incident
- Decisions taken conditionally never come back for revisiting
With AI assistance
- The non-functional requirements are laid out before the decision
- The options stand side by side against the agreed criteria
- The decision is recorded with its reasoning and the rejected options
- You can see where in the company the same problem has been solved
- A departure from the standard is flagged at a review
- A conditional decision has a date for revisiting and a reminder
- Decisions you can justify
it is known why the solution looks the way it does
the decision is recorded with its criteria and options
- Consistent solutions
fewer teams solving the same problem differently
the register of decisions and patterns is available
- Time to a settlement
fewer weeks between the question and the answer
the options are laid out rather than described from scratch
- Visible architectural debt
conditional decisions come back for revisiting
they have a recorded date and a reminder
We start with recording decisions, because it is the cheapest step with the largest long-term effect.
- Step 1
A register of decisions with reasoning
The decision, the criteria, the rejected options, the requirements that triggered it.
- Step 2
Laying out the options
The criteria side by side before the conversation, instead of a table made for one meeting.
- Step 3
Standards and signals about departures
A catalogue of patterns and pointing out solutions that diverge.
- Step 4
Architectural debt
Conditional decisions with a date for revisiting, linked to production problems. Last, because it needs a history of decisions.
Common questions
Questions that come up at the first meeting
How is this different from what an analyst or a project manager does?
The analyst establishes what is to be built. The project manager is accountable for it being built on time. The architect settles how to build it - and their decisions outlive the project they were made in.
Will an architect still be needed?
An architectural decision is a judgement about the future made on incomplete knowledge, and nobody will make it for a person. We take over gathering the requirements, laying out the options and recording the decision, which is the work around the judgement. The biggest gain is in fact something other than time: recorded decisions stay in the company when the architect leaves it.
Does this fall under the AI Act?
Designing solutions is not a high-risk use. It is worth having the register of decisions cover decisions to use AI systems in what is being built, because it is architecture that determines whether a high-risk use comes into existence at all and how it will be overseen.
Still have a question that is not here? Book a call
Next step
Could you justify an architectural decision from two years ago today?
We will show you what an architect's work looks like when a decision is kept with its reasoning and a departure from the standard is visible.