Intelligence Architecture: Uniting Information and Systems Design

In many organisations, “our data” and “our systems” are two separate concerns: separate teams, separate budgets, separate roadmaps. That has worked well enough for a long time. On AI projects the split tends to catch up with everyone involved, and later than anyone would like.

The reason is straightforward: what a model can produce depends on which information it can reach and which system it runs in. Yet those two things are usually decided by different people at different times.

Why the Split Costs More With AI

Conventional software is forgiving. Where a database is unevenly maintained, the application layer can absorb a good deal of it — through validation, defaults, business logic. It takes effort, but it works.

With AI systems that buffer is thinner. A model drawing on data that is patchy, inconsistently labelled or duplicated will give correspondingly inconsistent answers — and the application layer often cannot straighten that out, because it has no way of knowing which of the conflicting entries is the right one. The quality of the information layer shows up in how the system behaves, and users not infrequently notice it before the developers do.

What Belongs Together

What the data means. Not just where it sits, but what it asserts: does “active customer” mean the same thing in every system? Which system takes precedence for which field when two disagree? And can anyone tell where a figure came from and how much weight it carries? A model querying two systems that define the same term differently will give answers that are each right on their own and contradictory together.

How the data reaches the model. As an overnight extract, through an interface in real time, or by looking it up at the moment of the request — that is a decision with consequences for response time, freshness and cost. It can be changed later, though rarely cheaply: rebuilding an architecture designed for monthly reporting to answer queries by the second is usually the expensive route.

Where the boundaries run. Which system owns which decision? What happens to what the AI produces — does it flow back into the source systems, and if so, marked how? And who decides when the AI output and the source system disagree? Leave those open and the AI output quietly becomes the reference people work from, including where it should not be.

What connects the layers. Interfaces and agreed data formats, so that the information layer and the application layer can evolve independently without breaking each other. This is the same discipline good software architecture has always asked for — applied here to how a model takes information in and what it hands back.

Designing Together Means Talking Earlier

Organisations that get lasting value out of AI often treat information architecture and application architecture as one job rather than two consecutive projects. In practice that asks for less than it sounds: the people responsible for data structure and the people building the system look at the same use cases together — before either side commits.

The effort sits at the start and is manageable. What it saves shows up later, which does nothing to help it in day-to-day project life: a meeting whose benefit only becomes visible next year loses out to every urgent one.

What It Buys You

The return rarely shows on the first use case. It shows on the ones after — where the information layer was built so the next case can draw on it rather than build its own.

Whether it pays off for a given organisation is hard to calculate in advance, though not hard to bound: how many AI applications are realistically planned over the next few years? And how much of the data work the first one requires would be needed for the second anyway? If it stays at a single application, shared architecture may well be overbuilding. If several are in view, every separately built data path becomes one that somebody has to maintain later.