Technology and Architecture Advisory: test the plan against the system
We trace how your systems really behave, set the plan against them, and tell you what the architecture can carry, what it cannot, and what to settle before committing.
In brief
Technology and architecture advisory tells you whether your current systems can carry what you plan to do next. We review the system as it runs, not the diagram: we trace real flows and incident history, state what each initiative demands of the architecture, and give options with the cost of undoing each, and a recommendation.
- Who it suits
- A CTO, an architect or a chief executive with a commitment ahead: a platform replacement, an acquisition, a new AI capability, a vendor proposal.
- What you provide
- Read access to configuration and incident history, and time with the engineers who carry the pager.
- What you receive
- Findings with evidence, a fit assessment of each initiative, options with the cost of undoing each, and decision records.
- Where it ends
- At the recommendation. Building or changing the system is a separate written scope.
On this page
Why does the plan keep meeting a system nobody drew?
Plans are written against the architecture people describe, and people describe the intended one. The diagram shows services as designed. It does not show the nightly job that quietly reconciles the customer tables, the field that means one thing in billing and another in support, or the integration whose author left. The running system is the intended one plus everything it has accumulated, and the accumulation is where a schedule goes to die.
Leadership meets the consequence as a slipped date, a change request or a vendor claim that did not hold. By then the money is committed and the question has changed from whether to proceed to who is at fault. A review done before the commitment asks a cheaper question: what does this initiative assume about systems nobody has traced?
How a review runs, from the first access request to the decision record
- 01
Agree questions and access
Leadership names the initiatives ahead. We receive read access to configuration, incident records and contracts.
- 02
Trace real flows
We follow a customer, an order and a payment through the systems as they run.
- 03
Test each initiative
Each plan is set against what the traced system can and cannot do.
- 04
Write the options
A recommendation, the alternatives, and the cost of undoing each.
- 05
Record the decision
Assumptions, owner, and the checkpoint where the review returns.
What does each kind of evidence show, and what does it hide?
We read all of these and weight none above the others. Findings cite the evidence behind them, so a disagreement between your engineers and us becomes a question about the system instead of a contest of authority.
| Evidence | What it shows | What it hides |
|---|---|---|
| Architecture diagrams | The design intent and the names of the parts | Everything added since the diagram was drawn |
| Traced flows of real records | Where a record is created, changed, copied and lost | Rare paths that run only at month end or on failure |
| Configuration and deployment history | What is switched on, what changed lately and who changed it | Why the change was made |
| Incident and on-call history | Where the system has failed and how it was patched | Weaknesses nothing has triggered yet |
| Vendor contracts and service limits | What a supplier will and will not carry | What the supplier's next release will change |
| Conversations with the engineers on call | The workarounds that are written down nowhere | The view of anyone who was not asked |
A pattern we are called into
A telecoms operator signs for a self-service portal
An operator approves a portal that lets customers change plans and see usage. The vendor proposal assumes billing exposes plan changes through a documented interface and returns usage almost at once. The executive sponsor wants to sign before the next planning cycle.
- Trace a plan change end to end. We follow a change from the proposed portal through order management to billing. Billing accepts it only through a nightly batch, and a second system holds the customer's contract terms.
- Read the incident history. Support records show the batch fails often enough that a standing manual correction exists, performed by one team lead.
- Set the portal against the finding. The portal's central promise, an immediate change, conflicts with how billing works today.
- Write the options. Replace the batch first, narrow the portal to read-only functions, or proceed as proposed and accept that customers will see changes late. Each option carries the cost of undoing it.
Where it endsThe sponsor signs a narrower first stage, with the billing interface as a named, owned prerequisite for the rest. The vendor contract is reworded so the dependency is explicit.
The risk in a plan sits in what cannot be undone, so reversibility is the first thing we ask about every option.
When is a review worth commissioning, and when should your engineers simply try it?
Commission a review when
- The commitment is large and hard to reverse, such as a platform replacement or an acquisition
- A plan assumes how systems behave and nobody on the sponsoring team has traced them
- A vendor proposal rests on claims about how your systems work
- Your engineers and your leadership disagree and need a third view that shows its evidence
Let your engineers try it when
- The change is small and reversible, and a trial by your own engineers will teach you more, sooner
- The system is being retired and nothing new will touch it
- The question is a preference between tools, not a fit between plan and system
- Nobody has authority to change the plan whatever the review finds
A review spends your engineers' attention: access requests, interviews, and time explaining history that is rarely written down. It also tends to produce findings the team that built the system would rather not read. We state them plainly, credit what is sound, and say so when the finding is that the plan should not proceed as written.
What is written down at the end?
- Findings from the system as built, each with the evidence it rests on
- A statement of what we could not see and what that leaves uncertain
- A fit assessment of each planned initiative against the current architecture
- The risks, ordered by how expensive they are to discover late
- Options for each decision, with trade-offs, the cost of undoing each and a recommendation
- Decision records that state their assumptions and the point at which to revisit them
What do we need from your engineers, and what do we leave alone?
We need read access to configuration, deployment and incident records, and time with the engineers who run each system. The review covers what we are given access to, and the findings say what we could not see.
We test vendor claims when the written scope names an evaluation. We do not guarantee that a plan will succeed. We say what it depends on. Changing or rebuilding the system is separate delivery work, for example Technology Consulting, and keeping it separate means the people judging the plan have nothing to build.
Where can you check your own architecture first?
The risk assessment and the review checklist hold the starting questions we use, and the technical debt register is where findings are kept afterward. The report on systems and data that stop agreeing sets out the mechanism behind the surprise above.
Questions a CTO asks before commissioning a review
How is this different from Technology Consulting?
Advisory gives you an independent judgment before you commit: what the architecture can carry, and the options. Technology Consulting carries out the integration, modernization or retirement the judgment points to. You can buy either without the other, and keeping them apart keeps the advice free of any work to sell.
Will you read our code?
Where the question needs it, yes, and always beside your engineers. Findings come mainly from tracing real flows and reading configuration and incident history, which show behavior that neither the diagrams nor a sample of code reveals.
What if our engineers disagree with your findings?
We test the disagreement against the system together and record both views. A finding your engineers can show to be wrong is corrected. The ones that stand come with their evidence, so the discussion is about the system and not about us.
Can you review a vendor proposal or an acquisition target's systems?
Yes. We state what the proposal assumes about the systems it will touch, check those assumptions against what we can see, and report the gaps. It is one way to find out what a commitment includes before it is signed.
Related
Is your plan written against the system you actually have?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.