Scanning your data architecture: what a good scan of your current situation delivers

Translated with AI. This article was translated by an AI model from an article by Twentynext in another language, and the translation was checked automatically against the original. Verify figures and sources before acting on them. See our disclaimer.

The board wants to get started with AI, the controller does not trust the monthly report and the only colleague who knows how the link to the ERP system works is retiring in six months. Three problems that appear unrelated at first glance, but all three are difficult to tackle as long as nobody has an up-to-date picture of how data flows through your organisation.

A scan of your data architecture creates that picture. Below you will read what a good scan examines, who you need for it, what it delivers in practice and where such a scan often goes wrong. And also what you should not expect from it.

What a scan of your data architecture is, and what it is not

A scan as we mean it is a structured survey of the current situation. Which systems are in place, which links run between them, who owns which data and where definitions clash.

Within that definition, it is not a design of the new situation. That comes afterwards, and only once you know where you stand. Nor is it a tool selection. If a scan ends in a recommendation for a specific platform, the question is whether your current situation or the provider’s offering was the starting point.

Nor is it primarily an audit with a score. A score or maturity level can help to make the urgency visible, but the useful part lies in the findings: where the risk is, what is blocking your plans and what you can tackle first.

When a scan makes sense

Not every organisation needs a scan at every moment. In our experience, there are a number of moments when it pays to map the current situation first:

• You want to start an AI or machine learning project and nobody can say with certainty which data is available and reliable for it.
• A migration or system replacement is planned and the links to the current system have never been documented.
• Reports from different departments give different figures on the same subject, and discussions are about the figures rather than the content.
• Knowledge of the data landscape sits with one or two people who will leave in due course.
• Two organisations or departments have been merged and are still working with duplicate systems.

If you recognise one or more of these situations, the question is how much you actually know about the foundation you are building on. An AI project can then get stuck on data quality or missing ownership, and the risk is that you only discover this once a lot of work has already gone into it.

What a good scan examines

A scan that looks only at technology leaves part of the picture out. In practice, you look at four areas that influence each other.

Systems and links

Which applications contain which data, and how does that data get from A to B? Also look out for links that are not in the system documentation: manual exports, macros in spreadsheets, a script on a colleague’s laptop. Such informal links deserve attention as a possible risk: who monitors them, and what happens if their creator leaves?

Definitions and data quality

What exactly does “customer”, “employee” or “completed request” mean, and does it mean the same in every system? Differences in definitions can explain why reports do not match. A scan exposes those clashes and names them specifically.

Ownership and decision-making

Who is allowed to decide on the definition of a field, on access to a source, on cleaning up historical data? If the answer is “we don’t know” or “everyone a little”, you run the risk that technical improvements leak away again. An architecture can map this out but cannot take it over: someone in your organisation has to assign it.

Management and continuity

Who keeps the links running, what happens if an export fails and how do you notice? How heavily does the whole rely on the knowledge of individuals? This area easily receives less attention than the technology, yet it partly determines whether your data provision keeps working in the longer term.

Who you need at the table

The biggest mistake in a scan is talking only to IT. IT can tell you which servers are in place and which licences are running, but does not always have insight into which figures a department corrects manually every week. That knowledge sits with the people who work with the figures.

So make sure you speak to at least one user per key process: the controller, the team leader of customer service, the policy adviser who produces the quarterly figures. They know where the friction is, which systems they work around and which definitions are used differently in practice than on paper.

In addition, you need someone who can take decisions and assign ownership. Without that person you run the risk that the scan ends up as a list of findings that nobody is allowed to act on. Reserve that role in advance, not afterwards.

What a scan delivers in practice

A scan as described here does not deliver tidied-up data or a working architecture. What you do get, if it is done well and within the limits of the agreed scope, the available documentation and the conversations you are able to hold:

A map of your data landscape. All systems, all links including the informal ones, and for each link who is responsible for it. If such a map does not yet exist in your organisation, this is a useful result in itself.

A list of clashing definitions. Specific, with the systems involved and the consequences for reports. This part makes tangible where divergent figures may come from, and is therefore a useful basis for the conversation with management.

A risk picture. Where continuity hangs on one person, which link will break at the next update, which data is retained without anyone knowing why. Where personal data is involved, the purpose of retention, the retention period and who is responsible are points you should have examined further. An architecture scan is not a legal assessment and does not replace that examination.

A prioritisation. Not everything has to happen at once. A good scan names a limited number of items you should tackle first and why, and which ones you can deliberately leave for now.

An honest answer to your original question. Can that AI project start? Sometimes the answer is yes. Sometimes it is: yes, but this first. And sometimes it is no, not yet. That last answer is unwelcome, but it is better to hear it in advance than to discover it yourself halfway through a project.

Where a scan often goes wrong

A number of patterns we regularly encounter in scans that delivered little:

The scan takes too long. A survey that runs for months has become an architecture project. Agree a clear scope and a lead time of a few weeks in advance. How many weeks depends on the size of your landscape and how quickly the right people are available; be critical of offers that promise much shorter and ask what exactly will be examined.

The provider also sells the platform. Then there is a risk that the outcome is coloured by that interest. Have the scan carried out by a party that has no interest in a specific tool, or establish in advance that product advice falls outside the scope.

Only documentation is examined. What is on paper can differ from practice. A scan without conversations with users produces a picture of how it was intended, not of how it works.

The report disappears into a drawer. That risk is greater if there is nobody who is allowed to act on the outcomes. Link the scan in advance to a decision moment: on date X we discuss the findings and decide on the first three actions.

The scan becomes a blame game. Findings about clashing definitions or undocumented links are not a reproach to the people who kept the landscape running for years. Communicate that in advance, otherwise you run the risk that precisely the people with the most knowledge become reticent.

Your first step

You do not have to start with a full scan. Start with a simple question: write down three reports or figures that you do not fully trust, and for each report find out which systems sit behind it and who determines the definition. This is an indicative exercise, not a measurement. If it goes smoothly, that is a first indication that your foundation is reasonably sound. If it takes a lot of effort or you get stuck, that is a signal that a broader survey may be worthwhile.

If you want a quicker first impression, Twentynext has an online self-scan: sixteen questions, seven minutes, and you immediately see a spider chart with your strongest and weakest dimension. You do not need to provide an email address for it. It does not replace a real survey. You can, however, use it as a conversation opener for the next meeting with IT and the process owners.