One architecture decision
Architecture Peer Review
A senior architect reviews one design, vendor proposal or significant technical direction before you commit. Fixed fee.
Explore Peer ReviewServices
Architecture expertise.Start where your decision is.
Four kinds of work: assessment, solution design, governance during delivery and assurance before a commitment. Each is a defined engagement with an agreed scope and deliverables, led by a named senior architect. None is a compulsory step towards the next.
Assess
Understand and evaluate
What is actually there, what are the risks, and what matters for the decision?
The result
Explore AssessA defensible understanding of the situation and our recommendation on what should happen next.
Architect
Define and design the response
What should we change, how should it be designed, and in what order?
The result
Explore ArchitectA coherent architecture direction, selected designs and transition that your delivery team can use for planning and implementation.
Govern
Preserve architecture integrity during delivery
Who challenges significant technical decisions while teams and suppliers build?
The result
Explore GovernContinuing architecture authority and a usable record of significant decisions, exceptions and actions within the contracted capacity.
Assure
Evaluate evidence for the next commitment
Do the evidence and agreed criteria support this milestone, release or acceptance?
The result
Explore AssureA scoped technical conclusion against agreed criteria, showing what supports the commitment and which conditions remain.
Two specialisations
Software with AI inside.
Software built with AI.
AI is our deep specialisation, in two forms. The same practice covers existing software, legacy estates and transactions. Your team or delivery partner builds and runs the system.
Architecture for AI systems
Agents, RAG and AI features that use your data and act in your core systems. We design and review their integration, access, evaluation, failure handling and controls.
Architecture for AI-built software
Products built fast with AI coding tools that now carry real users. We find out what to keep, what to fix first and whether your team can change the code safely.
Four service areas
Start with the area
that fits your decision.
Each area offers standalone engagements with an agreed result.
Assess
Understand and evaluate
We investigate a software or AI system, test design choices and set out a clear next step. A named senior architect leads the work, checks what our tools find and stands behind the recommendation. Specialists join where agreed.
Assessment conclusion · system maps · priorities · next actions
Explore AssessExample · Assess
The portal reads the order system's database directly
Before launch, a new customer portal reads customer data straight from the order system's database. The finding sets out the evidence, the consequence, the action and what we did not examine.
Inspect the Assess example
- Evidence
- Verified: the portal's code queries the order system's customer and order tables, using a database account that can read every customer record. Reported by your team: those tables change in most order-system releases.
- Finding
- Inferred: an order-system release can break the portal without warning. Because the portal's account can read every customer record, one faulty query could also show a customer someone else's orders.
- Action / check
- Fix now, before launch: put an API between the portal and the order system, and remove the portal's database account. Engineering then checks that every portal page works with that account switched off.
- Owner / limit
- We own the finding; the portal supplier and your order-system team make the change. Not examined: the nightly reports, which may read the same tables. Still open: whether the API can be ready before launch.
Architect
Define and design the response
We define the software or AI solution, integration or transition your delivery team needs. You get the agreed designs, justified choices and a usable handoff, grounded in your business and operating constraints.
Chosen direction · software & AI designs · transition handoff
Explore ArchitectExample · Architect
An API between the portal and the order system
The target design sets how a new customer portal connects to the order system. It compares the options, gives the reasons and conditions, and sets out what engineering builds.
Inspect the Architect example
- Options
- Three ways to connect the portal: a nightly copy of the order data, the integration platform you already use, or an API on the order system itself.
- Chosen design
- An API on the order system with four calls: customer details, order status, order history and new orders. Each call returns only the signed-in customer's data.
- Reasons / conditions
- A nightly copy would show yesterday's order status; the integration platform adds licence cost and another team for four calls. Condition: your order-system team owns and versions the API, so changes are announced before they reach the portal.
- Handoff / limit
- We hand over the API contract, the access rules and the sequence for moving each portal page to the API. Engineering estimates, builds and tests. The nightly reports stay outside this design until they are examined.
Govern
Preserve architecture integrity during delivery
A named senior architect keeps significant architecture decisions aligned with the agreed direction while your teams and suppliers build: ongoing challenge, exception handling and escalation, within the authority and hours we agree.
Decision records · exception reviews · risk escalation
Explore GovernExample · Govern
A request to bypass the API for one release
Close to launch, the team building a new customer portal asks to bypass the order-system API for one release. The record separates our advice, your decision, who acts and when it is reviewed again.
Inspect the Govern example
- Request / risk
- The order-history call will not be ready for launch, so the supplier asks to read order history straight from the database for one release. Risk: the portal depends on those tables again, and a temporary workaround can become permanent.
- Recommendation
- Allow it for one release only: a read-only database account that sees order history and nothing else, with its removal planned in the next release.
- Decision / action
- Your product owner accepts or rejects the exception; the supplier implements it. A named senior architect advises, records the exception and escalates under the agreed governance terms if a condition slips.
- Conditions / limit
- Reviewed again when the next release is planned, and closed only when the temporary account is removed. We cannot block a release unless your contract gives us that right.
Assure
Evaluate evidence for the next commitment
We give a scoped technical conclusion on whether the evidence supports your milestone, release or acceptance, against criteria agreed up front. A named senior architect brings in specialist validation where needed and states which criteria are met, the remaining risks and the conditions.
Technical conclusion · evidence coverage · risks · conditions
Explore AssureExample · Assure
The portal integration at handover, with conditions
A supplier hands over a new customer portal's integration with the order system. The report maps the evidence to the agreed acceptance criterion and states a conclusion with its conditions.
Inspect the Assure example
- Supported
- Criterion: the portal reaches order data only through the API. Verified: customer details, order status and new orders use the API, and each call returns only the signed-in customer's data.
- Exception / gap
- Order history still uses the temporary database account agreed for launch; it is recorded as an exception. Still open: performance at launch volume, because the load-test results were not available.
- Conclusion
- The evidence supports accepting the integration on two conditions: the temporary account is removed in the next release, and, before launch, the supplier provides load-test results that pass at launch volume.
- Owner / reliance
- We own the scoped conclusion; you decide whether to accept. The report goes to you and the supplier, and only you may rely on it. It states any earlier work we did on this integration.
Common starting points
Have a specific decision
in mind?
Two fixed-fee assessments within Assess: one checks a single architecture decision; the other checks a working product before its next stage.
Existing product · next stage
Production Readiness Assessment
Is your working product ready for what comes next? A short risk report or a scoped readiness report, with a fixed fee for each depth.
Explore Production ReadinessChoose by purpose
Understanding, design,
authority or a defined gate?
Each area stands alone. One engagement can draw on related areas while keeping one clear purpose.
Assess and Assure
Assess finds out what is there, diagnoses the problems and recommends a response. Assure checks the evidence against agreed criteria at a gate, or again after fixes.
Architect and Govern
Architect defines the direction, target design and transition. Govern challenges decisions within agreed responsibilities while your teams or partners build.
Not sure where to start?
Tell us what's changing, and we'll point you to the right starting point.
Book a 25-minute callWorking as a delivery partner?
The same four areas work directly or through a partner, with roles agreed up front.
How we work with partnersAll services
Every service,
by area.
The services at the top of each list are the usual starting points.
Assess
- Architecture Peer Review
- Production Readiness Assessment
- Technical Discovery & System Understanding
- Modernisation Assessment
- Software & AI Technical Due Diligence
- AI Project Rescue Assessment
- Architecture Diagnostic
- Architecture Decision Sprint
- Principal Architecture Advisory Session
- Legacy & Portfolio Understanding
- AI Opportunity Assessment
Start with the decision.
Tell us what's changing. 25 minutes on Teams, no preparation needed. If we're not the right fit, we'll say so.