Ask a team for a gap analysis and you will usually get a two-column table. On the left, what we have. On the right, what we want. The gap in between is described as a set of things to acquire: a new platform, an integration layer, a data warehouse, a monitoring tool. The table is easy to read and easy to fund, and it is wrong more often than it is right.
It is wrong because most gaps between where an organisation is and where it needs to be are not missing products. They are missing decisions, missing owners, missing rules and missing evidence. A gap analysis that only sees technology will recommend buying technology, and the organisation will spend money closing the one gap it could see while the others carry on causing incidents.
Cedarberg Logistics is fictional, and its systems and figures are illustrative. In Part 1, a three-hour gap in a trailer's temperature log led the Cape Town cold-chain firm to commission a technology health check. One of its outputs was a gap analysis for a single target: every consignment should have a complete temperature record that the customer can see.
Start with a target someone can test
A gap analysis is only as good as the target state it measures against. "Modern, cloud-ready, data-driven cold chain" is not a target. It cannot be tested, so nobody can say how far away it is.
Cedarberg's target fitted in one sentence and could be checked: for every consignment, a temperature reading at least every five minutes from loading to delivery, linked to the consignment, visible to the customer within fifteen minutes, with any missing reading raising an alert to a named person. Each clause can be measured today and measured again after the work is done.
The current state then has to be described with the same discipline. Not "the telematics integration is weak", but "readings arrive in a nightly file, consignment numbers are not in the file, and the link is made by matching vehicle and date in a spreadsheet". That is evidence-based current state: described in terms a second reviewer could confirm. Our guide to turning words into numbers before you design covers the same habit from the requirements side.
Read the gap across six dimensions
The method that works is to read the distance between current and target state across six dimensions rather than one: process, data, systems, people, rules and controls.
Laid out like this, Cedarberg's picture changed. The systems gap was real: a nightly file cannot deliver a fifteen-minute promise. But it was one row of six. The process gap (excursions handled by phone, with no case record) and the controls gap (no check for a probe that goes silent) were both cheaper to close and both more directly responsible for the original dispute. The rules gap was the quiet one: the customer's service level sat in a contract, and nobody had translated it into anything a system could enforce.
A technology-only gap analysis would have recommended replacing the integration and stopped. Cedarberg would then have had faster data with nobody watching it.
Four kinds of gap
The second refinement is to classify each gap, because different kinds need different responses.
- Missing. The capability does not exist. Cedarberg had no missing-data alert at all. This is the only kind of gap where design or procurement is the obvious first response.
- Partial. The capability exists but does not cover every case. The telematics vendor's own dashboard already showed live readings to the control room, but only for the newer trailers; older units uploaded in batches when they reached a depot. The response is to extend and harden what exists, not to start again.
- Conflicting. Two sources disagree about the same fact. The transport system and the telematics platform held different vehicle-to-trailer assignments for 6% of trips. No new tool fixes that; somebody has to decide which system is the record of truth and change the other to follow it.
- Unknown. There is no evidence either way. The review could not establish whether the George depot's backup power covered the trailer charging bays. An unknown gap is a gap in the evidence, and the honest response is to investigate before anyone designs a solution.
The fourth category is the one most gap analyses leave out, because it feels like an admission of failure. It is the opposite. Marking a gap as unknown prevents the commonest gap-analysis error, which is to assume the current state is either fine or broken when nobody has actually looked.
Prioritise by consequence, not by size
Once gaps are visible and classified, the instinct is to rank them by how much work they are. That puts the big systems project first, because it is the biggest, and the cheap control at the bottom, because it is small.
Cedarberg ranked by consequence instead: which gap, left open, would most directly cause the next dispute? The missing-data alert came first. It was configured in the telematics platform within a fortnight, using the vendor's existing rule engine, and it did not depend on the integration being replaced. A named excursion owner per shift came second. The integration rebuild came third, and it was scoped more tightly than it would have been, because the alert and the owner had already removed most of the risk.
From gaps to a sequence
A good gap analysis does not end in a list. It ends in a sequence of states the organisation can actually move through. Each intermediate state should be operable on its own, so that if funding or attention runs out halfway the organisation is still better off than it was. The approach in as-is, bridge states and to-be applies directly. For Cedarberg, the first bridge state was "alerts and ownership in place, data still nightly", which was safer than the starting point and needed no new system.
For each gap, the sequence should record:
| Field | Cedarberg example |
|---|---|
| Gap and dimension | No missing-data alert (controls) |
| Type | Missing |
| Evidence | Alert rule export, 12 August |
| Consequence if left open | Repeat of the disputed consignment |
| Response | Configure rule in existing platform |
| Owner | Head of fleet operations |
| Bridge state it belongs to | Bridge 1 |
The owner column matters as much as any other. A gap without an owner will still be a gap at the next review.
Common ways a gap analysis goes wrong
The target is a product. "Implement a control tower" is a solution. The target should describe an outcome the product might help achieve.
The current state is a memory. Gaps described from what people remember about the system, rather than from evidence, routinely describe a system that existed two years ago.
Every gap is technical. If the six-dimension view shows only the systems row, the analysis has probably not spoken to the people who operate the process.
Unknowns are disguised. A gap written as "integration may need review" is an unknown pretending to be a finding. Label it unknown and assign someone to find out.
There is no decision. The point of a gap analysis is to inform a choice between options. Cedarberg's raised a real one: replace, refactor or extend the integration, a decision covered in reuse, refactor, replace or retire.
The test of a good gap analysis
Give it to someone who was not involved and ask them three questions. Which gap would cause the most harm if it stayed open? What evidence says so? Who owns closing it? If they can answer all three from the document, it is useful. If they come back with a list of products to buy, it is a shopping list wearing a methodology.
Next: Part 3, The architecture repository is a management system, not a diagram folder. All parts are on the series page.
How CloudNala can help
We run architecture gap analyses that start from a testable target, describe the current state from evidence, and read the gap across process, data, systems, people, rules and controls. The output is a classified, owned and sequenced set of gaps with bridge states that are safe to stop at, so the investment decision is about consequence rather than about which project is biggest.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology Health Check or write to us at consult@cloudnala.co.za