Technology Consulting: systems that agree with each other
We map where data and decisions actually flow, then integrate, modernize or retire systems until the numbers match everywhere they are read.
In brief
Technology Consulting advises on technology choices, system design and delivery, and carries the work through. Systems stop agreeing when changes pass through integrations nobody owns, so we map where data and decisions actually flow, name one source of truth for each record, and integrate, modernize or retire until the numbers match.
On this page
Who asks for this, and what are they usually deciding?
A CTO or head of engineering whose estate grew through acquisition, urgency and vendor choice, and who is asked for faster delivery and cleaner numbers from the same systems. An architect after a merger who has to say which system keeps which record. A finance or operations leader who has stopped trusting a report and wants to know why, in terms an engineer can act on.
We work beside your engineers and your vendors, not in place of them. The written scope says who owns what, and the people who will run the result take part in building it.
Why does a job that reports success leave a record missing?
Every integration copies data, on a timer or when something happens, and it is written for the ordinary case. Later it meets the awkward ones: a record that breaks a validation rule, a record that points at something not there yet, a receiving system that is down when the job runs, a sender that changes its format. In each, the job's status says whether the job ran. It says nothing about whether the records arrived.
Someone notices a figure is wrong and corrects it by hand in a report. The correction becomes a rule that only that person knows. Every later change has to be checked against rules nobody wrote down, so each takes longer, needs another meeting, and shakes confidence in the numbers a little more.
The visible cost is leaders reconciling figures before a review. The hidden cost is an engineering group that can no longer say what a change will touch.
A job that reports success has told you it ran. It has not told you the records arrived.
Integrate, modernize, replace or retire: how do we choose, system by system?
The decision is made per system, against the records and flows the map shows are critical, and never for the whole estate at once. For each route we set out what it costs to undo, because that is the question executives forget to ask.
| Route | It fits when | What you give up | What it costs to undo |
|---|---|---|---|
| Integrate with a checked interface | The system holds its records well and others only need to read them | Another dependency to own and monitor | Little. Remove the interface and the system still stands |
| Modernize in place | The logic of the system is right and its platform is failing | A long stretch of work on a live system | Hard once the data model has changed, so the old version runs until the new one is proven |
| Replace | The system cannot hold the record it is meant to own | The largest outlay of money, attention and risk, and a migration with its own defects | Rarely possible after cutover |
| Retire | Systems that duplicate each other's job, or an output nobody reads | A habit for some users, and a new source for some reports | Little, if the data is archived and read access is kept |
| Leave alone and watch | It works and nothing planned depends on it | A known risk, carried on purpose | Nothing, until a plan changes |
What do we read first, and what do we fix first?
We start from the records that matter, customer, order and product in a typical business, and follow each from where it begins to where it is reported. Every hand-off, transformation and owner goes on the map, manual ones included. Then we compare both sides of each hand-off record by record, because that is the only way to find a gap the job itself does not report.
For each record one system answers for its correct state and every other system reads from it or labels its own value as a copy. The definition is written once, in plain terms, and approved by the people who rely on it. A finance partner signs off what counts as an active customer; an engineer does not decide it by default.
We fix in order of damage. Hand-offs that fail silently go first, then integrate, modernize or retire in the order the map justifies. Each fix ships with a reconciliation check that compares both sides and alerts a named person when they diverge. Last, we change the delivery habits: a release that touches a definition updates the definition and its check together, so the estate stops drifting.
What do your engineers hold when we leave?
- A map of the flows for each record that matters, with an owner against every hand-off
- A written definition of each of those records, and the system that answers for it
- Reconciliation checks that alert a named person when systems disagree
- A register of the interfaces on each record, with the reason each one exists
- A decision record for every route taken, with what would make you reverse it
- A change process in which definitions and their checks move with the release
A pattern we are called into
The subscriber who moved, and the engineer who went to the old address
A telecoms operator keeps a subscriber's service address in billing, in support and in provisioning. An address changed in support reaches billing by an overnight job. Provisioning sees it only when someone raises an order. A technician is sent to the old address, and the complaint lands with the head of field operations, who has never owned a system.
- Trace the record. We follow one address from the moment it is typed to the schedule a technician reads, noting each copy and each person who edits one.
- Name the source. The order system is where a service address is created and changed. Support and billing are told to read from it or to show that they hold a copy.
- Compare both sides. A direct comparison finds records the overnight job skipped because they failed a validation rule. The job had reported success every night.
- Make the failure loud. The check runs after each job and alerts a named person in field operations when the sides differ.
- Change the habit. A later change to the address format ships with its updated definition and check, in the same release.
Where it endsA change of address reaches every reader through one path. When it does not, a person is told the same day, and the engineers know which definition to read before they touch it.
Is this the right engagement, or a different one?
It fits when
- Nobody can say which system holds which record, and leaders reconcile figures by hand before reviews
- A platform decision is coming and the records need settling before it
- Your engineers will work with us and keep the checks running
- You want the work carried through, not only a report on it
Look elsewhere when
- You need an independent review of a plan before you commit money, which is Technology and Architecture Advisory
- You need a product built, which is digital product engineering
- You want a platform chosen from a vendor demonstration alone
- Nobody on your side can own a definition once it is written
Delivery slows at first. Engineers spend time on checks and definitions that produce no feature, and a leader has to protect that time until the first reconciliation catches something real.
What do we need from you, and what do we not promise?
We need read access to the systems involved and time with the engineers who run them. Replacing a core platform is a separate decision, which we advise on and scope on its own.
We do not promise a delivery speed. We agree the checks that show the estate is converging, and we report what we find as we go, so scope can follow the evidence.
How can you look at your own estate before we talk?
The assessment scores the risks in your architecture. The checklist is the one we use when we review one. The research explains each mechanism above in more detail, from the same silent copy to the record that exists in one system and not in the other.
What do engineering leaders ask before they start?
Do you replace our systems or work with them?
Mostly we work with them. The map shows which systems earn their place, which need integration and which should be retired. We recommend a replacement only when the evidence shows a system cannot hold the record it is meant to own.
How do you find integrations that fail silently?
We compare both sides of every hand-off directly, record by record, instead of trusting the job's own status. Gaps show up as records present in one system and absent in the other, and each gap is traced back to its cause.
How is this different from an architecture review?
A review tests a plan against the system and ends in a recommendation. This work starts from the records that disagree, makes the changes with your engineers and leaves checks running. A review can come first, and we work from its findings.
Who owns the definitions once you have gone?
A named owner for each record, who approves any change to its definition. The definitions live with the change process, so an engineer making a release meets them before the change ships.
Related
Do your systems tell the same story?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.