Patterns
names changed to protect everyone, including us
Problems we help solve.
These are illustrative patterns, drawn from situations that come up again and again. They are not client case studies. If one looks familiar, that is the point.
On this page
Illustrative pattern
Untangling a legacy platform
The situation
A core system has grown for fifteen years. It still works, but every change takes months and only a few people dare touch it.
How we approach it
- Map what the platform actually does, including the parts nobody wrote down
- Find the seams where a capability can be lifted out cleanly
- Move one capability at a time, with old and new side by side
- Switch off each old part only when nothing depends on it
What you are left with
A smaller legacy core every quarter, and no single day where everything has to go right.
What usually goes wrong
A full rewrite is proposed, runs late, and the old system keeps changing underneath it.
Illustrative pattern
Connecting fragmented services
The situation
Departments bought or built their own systems. Each one works; together they rely on spreadsheets, exports and people copying data between screens.
How we approach it
- Agree the handful of business events every system cares about
- Define stable contracts for them, owned by a named team
- Route integrations through those contracts instead of direct links
- Retire the manual workarounds one by one
What you are left with
Systems that can change independently, and integrations you can list on one page.
What usually goes wrong
Point-to-point integrations multiply until nobody knows which ones matter, and a small change breaks something far away.
Illustrative pattern
Moving batch integrations to real time
The situation
Important data moves between organisations in overnight files. Customers now expect answers in seconds, and new message standards are arriving.
How we approach it
- Model the messages and their lifecycle before choosing technology
- Separate validation, routing and business rules so each can change
- Run real-time and batch side by side, reconciling the two
- Move traffic across in measured steps
What you are left with
Real-time flows with clear audit trails, and a batch path you can retire on your own schedule.
What usually goes wrong
The new format is bolted onto the old batch process, so the system gets the complexity of both and the speed of neither.
Illustrative pattern
Giving an institution a digital front door
The situation
A school, association or public-facing organisation has an outdated website that staff cannot update, so the real information lives in social posts and PDFs.
How we approach it
- Start from what visitors come to do, not the organisation chart
- Model the content so each fact has one home
- Build a fast, accessible site that works on prepaid mobile data
- Hand over simple publishing so staff keep it current
What you are left with
A site people can find things on, and staff who can keep it true.
What usually goes wrong
A redesign makes it look newer but keeps the same structure, and within a year it is out of date again.
Illustrative pattern
Making architecture decisions stick
The situation
There are standards documents, but each project reinterprets them. Important choices are made in meetings and remembered differently by everyone who was there.
How we approach it
- Write a few principles with the teams who must apply them
- Record significant decisions in a short, consistent format
- Review the decisions that are expensive to reverse, and only those
- Check the running systems against the decisions now and then
What you are left with
Faster decisions, a record of why, and standards people actually use.
What usually goes wrong
An architecture board is created, becomes a queue, and teams learn to route around it.
Illustrative pattern
Starting a new product on solid ground
The situation
A new product or venture needs to launch quickly, but it will hold customer data and may need to pass enterprise security reviews later.
How we approach it
- Put security, environments and automated releases in place first
- Decide in advance what will trigger each next investment
- Build the first version on boring, well-supported technology
- Keep the design notes so due diligence is a reading exercise
What you are left with
A product that can launch small and grow, with nothing to rebuild when it does.
What usually goes wrong
Either it is over-built for a scale that never arrives, or shortcuts become the foundations of everything that follows.
Next step
every system is tangled in its own way
Recognise one of these?
Tell us which, and what is different about yours. The differences are usually where the interesting work is.