Home/What we do/Solution design
A buildable shapeSolution Architecture
A complex requirement turned into a structured approach: what is built, what is connected, and in what order.
Overview
A complex requirement is not a shopping list. It is a set of decisions about what is built, what is connected, what is left alone, and in what order. Architecture is the record of those decisions.
We hold more than one credible option long enough to compare them against constraint and capability. The result is a shape that can be implemented — not a diagram that assumes a different organisation.
Four stages before a path is treated as settled.
Each stage leaves an artefact you can challenge. Nothing is carried forward on confidence alone.
- 01
Understand
Study the work, the systems, the people, and the constraints as they are.
- 02
Define
Name the actual problem. Write the non-goals.
- 03
Explore
Hold more than one credible path long enough to compare them.
- 04
Structure
Turn the choice into architecture, owners, and sequence.
Inside solution design.
Requirement structure
Turn a dense brief into a set of decisions.
Architecture options
Show two or three credible paths, with consequences.
Integration design
Decide how existing systems should meet, not how they should be replaced.
Interface contracts
Make the joins between teams and tools explicit.
Non-goals
Protect the work by saying what will not be done yet.
Delivery sequence
Order the build so value appears before everything is finished.
The terms of the work.
A working note.
The kind of thing this work produces — inspectable, arguable, and short enough to be read.
OPTION 1 Thin integration over the core OPTION 2 Replace the core in phases OPTION 3 Automate around the core and leave it CONSTRAINT Core cannot move this year. Team can integrate, cannot rebuild. FIT Option 1. Option 2 exceeds change load. Option 3 adds tools without a spine.
When this usually appears
- A transformation that needs a spine
- Vendors proposing incompatible stacks
- A product idea without a system view
- Legacy platforms that still have to work
Solution design, asked directly.
Frequently asked questions
Is this enterprise architecture in the classic sense?
It is closer to a decision record: what we will join, what we will not, and why.
Do you write RFPs?
We can shape what should be asked. A vendor list without a problem statement is not useful.
Adjacent work.
Bring the situation as it is.
You do not need a polished brief to start. A conversation is usually enough to name the problem and decide whether there is work here at all.