Gap Analysis in Practice: How Much Detail Is Enough?
Every architecture effort eventually has to answer the same blunt question: what has to change to get from here to there? The answer is called a gap analysis, and it sounds more technical than it is. Done well, it fits on a page and drives real decisions. Done badly, it becomes a spreadsheet nobody opens. The difference lies in knowing how much detail is enough.
What a gap analysis actually is
You describe where the organisation is today, describe where it intends to be, and compare the two. The differences are your gaps. Some gaps are missing capabilities, some are systems that must change, some are skills, and some are agreements between teams that do not yet exist. Listing them gives sponsors something concrete to fund and plan.
Begin with the target, not the present
It is tempting to start by documenting everything that currently exists. That path leads to months of cataloguing. Instead, sketch the target first in broad strokes, based on the outcomes leadership has asked for. Then describe only the parts of today’s situation that bear on those outcomes. If a system does not affect the target, leave it alone for now.
This keeps the work proportionate. You are not building an encyclopedia; you are answering a question.
Pick a level of detail and stay there
Mixed levels are the most common mistake. One row says “customer data” and the next says “field 14 of the billing table.” Choose a level, such as business capabilities, and compare like with like. Work at the next level down only where a gap looks risky or expensive.
Get Oliver Selmon’s stories in your inbox
Join Medium for free to get updates from this writer.
A good test is whether a sponsor could make a decision from the row. If the row is too vague to act on, add detail. If it is so detailed that nobody can see the pattern, lift it up.
Rate each gap simply
Resist elaborate scoring models. Three ratings usually suffice: size of the gap, importance to the target, and difficulty of closing it. A small gap on an important item beats a large gap on a trivial one. Say why in one sentence, so that the reader can challenge your reasoning.
Be willing to say “we do not know yet.” An honest unknown with a plan to find out is worth more than a confident guess.
Turn gaps into a short list of moves
Group related gaps into a handful of initiatives and sequence them. Look for dependencies: what must be true before something else can start? Highlight the first two moves that are small enough to try within a quarter. Early progress builds trust and exposes mistaken assumptions while they are cheap to fix. That is the spirit of succeed fast: test the plan on something small and let the evidence guide the rest.
Keep it alive
A gap analysis is a snapshot. The organisation changes, priorities shift and some gaps close by themselves. Review it every few months, remove what is done and add what is new. Keep the page short enough that updating it takes an hour, not a week, or it will quietly die.
Learn it by doing
Few skills are as easy to explain and as hard to do well. The judgment about how much detail is enough comes from repetition and feedback. Framework courses, TOGAF among them, describe the steps clearly, and that foundation is valuable. Practice sessions add the experience of deciding what to leave out while someone challenges your choices.
That practice-first approach is what the Enterprise Architecture Center of Excellence builds its teaching around, using realistic cases led by working practitioners. If you would like to rehearse this skill with coaching, consider one of the hands-on architecture workshops and see how it compares with other options.
Try it this week. Take one initiative you know, sketch its target on a single page, and list the five biggest gaps. You will learn more from that hour than from another chapter of theory.
Originally published at http://enterprisearchitecturehub.wordpress.com on October 27, 2026.
