The real choice is how much complexity to own

Data discussions often start with competing nouns: warehouse, lake, lakehouse, integration platform or Model Context Protocol. Each can be useful. None is a strategy.

Every architectural layer creates work. Data needs definitions, permissions, monitoring, retention rules and an owner when systems disagree. Suppliers change. Connections fail. Fields are renamed. A technically elegant design can become an expensive source of confusion if the business lacks the capacity to run it.

The UK Business Data Survey gives this problem some useful context. Among businesses that handled digitised data and used AI, 21% said their AI tools were integrated into existing business systems. Integrated users also reported more intensive data collection and analysis, although the survey shows an association rather than proving that integration caused better practice. Larger businesses were more likely to report integration than smaller ones.

For an established SME, the implication is not “build what a large enterprise has”. It is to be proportionate. Choose an arrangement the business can govern and improve as its needs develop.

Start with the decision, not the destination

Before discussing architecture, define one outcome in plain language. For example:

• produce accurate quotations sooner
• reconcile customer profitability across sales and finance
• give service teams access to approved product knowledge
• identify recurring causes of equipment failure
• reduce the manual work involved in management reporting

Then identify the minimum data required, how current it must be and what level of error the decision can tolerate. A weekly board report has different needs from a service agent answering a customer in real time. A regulated decision has different controls from an internal draft.

This order matters. The OECD’s work on SME AI adoption identifies data, skills, connectivity and finance as enabling conditions, while also showing that smaller firms follow different adoption paths. Architecture should match the use case, digital maturity and resources of the business. It should not be a badge of sophistication.

Four practical data patterns

The following patterns are not a maturity ladder that every company must climb. They solve different problems and can coexist.

Direct connections: focused and current

An application programming interface, or API, lets systems exchange defined information. For AI applications, the Model Context Protocol, or MCP, offers a common standard through which an AI application can connect to approved tools and data sources. The protocol standardises the connection pattern; it does not clean the underlying records or decide who should see them.

Direct connections suit a narrow process involving a manageable number of systems, especially when current information matters. A proposal assistant might retrieve approved product details and live customer records without copying the whole company estate into a new platform.

The trade-off is dependence. As the number of connections grows, so does the effort required to manage permissions, changes and failures. A direct route is a good first move when the problem is contained. It is a poor excuse for leaving critical data undefined.

A data warehouse: consistent management information

A warehouse brings structured information from systems such as customer relationship management, finance and enterprise resource planning into a governed model for reporting and analysis.

Its value is not simply central storage. It is agreement. What counts as an active customer? Which date defines a sale? How is gross margin calculated? Which record wins when two systems differ?

A warehouse becomes useful when leaders receive competing versions of performance, reconciliation consumes too much time or several functions need consistent measures. It also requires business ownership of definitions. Leaving those decisions to a technical supplier merely hides the disagreement inside code.

A data lake: flexible storage for valuable raw material

A lake can hold large volumes of raw and unstructured material such as documents, images, audio, machine readings and logs without forcing everything into a reporting model first.

That flexibility is valuable when unstructured information is central to the commercial problem. A field-service business may need inspection photographs and engineer notes. A manufacturer may need machine telemetry.

It is less useful when the rationale is simply to keep everything for later. Without metadata, ownership, access controls and a credible use, a lake can become a larger digital loft. Storage is not the same as an accessible asset.

A lakehouse: mixed data at greater operating cost

A lakehouse combines features of warehouses and lakes so that structured reporting and more flexible analysis can use a shared environment. It can make sense for a growing, data-rich business with repeated use cases across both structured and unstructured material.

It also increases the operating demand. The business must manage quality, security, metadata and processing across more types of information. It is a credible destination when the portfolio justifies it, not a default starting point for a company with a handful of cloud systems and unreliable customer records.

Six tests for a proportionate decision

Use six questions to compare the options:

1.  Outcome: Which decision, customer experience or process should improve?

2.  Data: What information is required, in what form and at what frequency?

3.  Quality: Which fields and definitions must be reliable before the use case is safe or useful?

4.  Control: Who may access the data, and how will sensitive or unnecessary information be excluded?

5.  Operability: Who will monitor, maintain and improve the arrangement after launch?

6.  Options: Can the business retrieve its data, change supplier and preserve important definitions and history?

The final question is easy to neglect. The government’s Smart Data 2035 strategy aims to support secure, trusted data sharing and greater portability across the economy. As more services interpret and act on company data, leaders need to understand who controls access, how value is shared and what happens when they want to leave.

Let the architecture earn its next layer

A sensible path is usually incremental. Map one valuable decision or workflow. Identify the systems and minimum data involved. Fix the definitions and quality problems that would invalidate the result. Test the least complex workable pattern. Measure the business outcome and the operating effort.

Add another layer only when there is evidence that the current arrangement cannot support an important need. Repeated reconciliation may justify a warehouse. Valuable unstructured material may justify lake capability. A growing mixture of both may eventually justify a lakehouse.

This approach is not under-ambitious. It protects management attention and makes each investment answerable to the business.

A practical next step

Choose one decision that poor or fragmented data makes slower, less reliable or more expensive. Map the minimum information, its owners, its acceptable age and the systems involved. Ask a technical adviser for the simplest governable design that meets those requirements, plus a clear route for expansion and exit.

The AI Centre helps leadership teams connect data and AI choices to commercial outcomes. If you need an independent view before committing to architecture or a supplier, start a conversation with us.

Sources

• UK Business Data Survey 2026: Department for Business, Innovation, Science and Trade and Department for Science, Innovation and Technology
• AI adoption by small and medium-sized enterprises: OECD
• Smart Data Strategy: Department for Business and Trade

Welcome to the Model Context Protocol blog: Model Context Protocol project