Architecture Before Technology Building an NHS Patient Flow Analytics Solution with Microsoft Fabric

Architectural process for any Data Project.

Week 1: Before You Build Anything, Understand the Problem

Why successful data platforms don’t start with technology

Spend enough time around data projects and you’ll notice a familiar pattern.

• Someone asks for a dashboard.

• The data team starts building pipelines.

• A Lakehouse is created.

• Reports appear.

• New technologies are introduced.

Months later, people are still exporting data to Excel because they don’t trust what they’re seeing. The technology worked exactly as designed. The business problem didn’t.

This is the first article in a weekly series where we’ll design an NHS Patient Flow analytics solution using Microsoft Fabric. But before we touch Fabric, create a workspace, or ingest a single row of data, we’re going to do what every good architect should do first: Understand the problem.

Why an NHS patient flow case study?

Although this series uses NHS Patient Flow as its running example, the principles we’ll discuss are not unique to healthcare.

Whether you’re working in retail, manufacturing, financial services, logistics, higher education, or the public sector, successful data and analytics projects follow the same thought process:

• Start with the business problem.

• Understand the decisions people need to make.

• Assess the current landscape.

• Design the architecture around those needs.

• Then choose the technology that best fits the solution.

The NHS simply provides a relatable, real-world scenario where the impact of good — or poor — data is easy to see. Delayed decisions can affect patient care, operational efficiency, staff workload, and ultimately the experience of patients.

As the series progresses, you’ll notice that while the examples are healthcare-focused, the approach can be applied to almost any organisation looking to build a modern data platform.

A familiar Monday morning

Imagine you’re the Lead Data Architect at an NHS Trust. It’s Monday morning, and the weekly operational meeting is underway.

The Chief Operating Officer asks a straightforward question:

“Why are patients who are medically fit for discharge still spending days in hospital?”

The room goes quiet. The bed management team has one set of figures. The discharge team has another. The Emergency Department reports something different again.

Everyone has data. Nobody has confidence that they’re looking at the same picture.

At first glance, it looks like a reporting issue. In reality, it’s something much bigger.

It’s a decision-making problem. The temptation to jump straight into technology

For many of us working with Microsoft Fabric, the natural instinct is to start thinking about solutions.

• Should we build a Lakehouse?

• Would a Warehouse be better?

• Do we need Data Factory pipelines?

• Should we stream the data in real time?

These are all valid questions. They’re just not the first questions.

Starting with technology is a bit like deciding on the treatment before you’ve diagnosed the patient. You might eventually arrive at the right answer, but you’ll probably take a longer route than necessary — and risk solving the wrong problem altogether.

Listen carefully to the question

Notice what the COO actually asked.

They didn’t ask for another dashboard.

They didn’t ask for Power BI.

They certainly didn’t ask for Microsoft Fabric.

They asked why patients are waiting longer than they should.

That small difference changes everything.

Instead of thinking about reports, we start thinking about patient flow.

Instead of discussing data pipelines, we begin looking at how patients move through the hospital and where delays occur.

The technology conversation can wait.

Patient flow is a people process before it’s a data process

When people hear “patient flow”, it’s easy to imagine a single process. It isn’t.

A patient might arrive through the Emergency Department, move to an assessment unit, spend time on a ward, undergo diagnostic tests, wait for pharmacy, require input from therapists, and finally be discharged with support from community services.

Each stage involves different teams. Different systems. Different priorities.

And, more often than we’d like, different versions of the truth.

If we don’t understand how the service operates, we have very little chance of designing data that genuinely supports it.

The questions worth answering first

At this stage, I’m not interested in what technology we’re going to use. I’m far more interested in understanding the business and it's problems. Some of the first conversations I’d want to have would include questions like these.

What decision are we trying to improve?

Not what report needs building.

Not which KPI should appear on a dashboard.

What decision is someone struggling to make today because they don’t have the right information?

Every successful analytics solution exists to help someone make a better decision.

What does success actually look like?

Everyone says they want to improve patient flow.

But what does that mean?

• Reducing discharge delays?

• Improving bed availability?

• Reducing ambulance handover times?

• Creating a trusted source of operational information?

Until success is clearly defined, it’s impossible to know whether the solution has achieved anything meaningful.

Who owns the problem?

This isn’t an IT project.

It isn’t even a data project.

It’s an operational improvement initiative.

The people who feel the pain every day are usually the people best placed to explain it.

• Bed managers

• Discharge coordinators

• Operational managers

• Clinical teams

Technology should support their decisions, not dictate how they work.

Where does the data already exist?

One assumption I often hear is that organisations don’t have enough data.

In reality, most NHS organisations have plenty of data.

It’s just spread across different systems.

• Electronic Patient Record (EPR)

• Patient Administration System (PAS)

• Bed management software

• Community systems

• Existing data warehouses

• Spreadsheets maintained by operational teams

The challenge usually isn’t collecting more data.

It’s bringing existing data together in a way that people trust.

How quickly do people need the information?

This sounds like a technical question, but it’s actually an operational one.

If discharge planning happens once every morning, an overnight refresh may be perfectly adequate.

If bed managers are making decisions throughout the day, then more frequent updates — or even near real-time data — might be necessary.

Understanding how the service operates should influence the architecture, not the other way around.

We still haven’t chosen any Microsoft Fabric components

That’s deliberate. One of the biggest misconceptions in modern data platforms is that architecture begins with technology. It doesn’t. Architecture begins with understanding.

Only once we know the problem we’re trying to solve can we start asking questions like:

• Do we actually need a Lakehouse?

• Would a Warehouse be more appropriate?

• Is streaming necessary, or is batch processing sufficient?

• Which Fabric capabilities genuinely add value?

The technology should be a response to the problem — not the starting point.

The thought process we’ll follow

Throughout this series, we’ll use a simple progression that applies well beyond healthcare.

Architecture before technology

Operational problem: What is actually happening?

Discovery: Who is affected and how does the process work?

Business questions : What decisions need better information?

Data questions: Where is the data and can it be trusted?

Architecture options: What design could support those decisions?

Technology selection: Which Microsoft Fabric capabilities are the best fit?

Notice that technology selection comes last.

What should we have by the end of Week One?

If we’ve done this properly, we won’t have written any pipelines or built any dashboards.

Instead, we’ll have something much more valuable.

A shared understanding of the problem.

We’ll know:

• what we’re trying to improve

• who makes the decisions

• how patient flow works today

• where the data comes from

• what success should look like

Everything else we build over the coming weeks will be based on these foundations.

Assumptions for this case study

To keep the example realistic, we’ll assume:

• A medium-to-large NHS Acute Trust

• An Electronic Patient Record (EPR)

• A Patient Administration System (PAS)

• Bed management and community systems

• Existing reports and spreadsheets

• Inconsistent operational metrics between teams

• Microsoft Fabric is being evaluated as the analytics platform

  
  

These assumptions help keep the discussion practical, but the same approach could be applied in many other industries.

A useful critique

One of the easiest mistakes in any data project is assuming that the chosen technology is automatically the right answer.

A good architect should be prepared to conclude that:

• the existing platform only needs improvement

• Fabric is only needed for analytics

• another system should remain the source of truth

• some workloads belong outside Fabric entirely

That’s not a failure. It’s good architecture. The goal is not to use the most technology.

The goal is to solve the problem in the simplest, most effective way.

Looking ahead

Now that we’ve agreed on the problem, the next step is understanding the current state.

In Week Two, we’ll map the patient journey from admission through to discharge, identify where delays occur, examine the systems involved, and uncover why different teams often report different numbers for the same patients.

Only then will we be ready to start designing the architecture. And when we eventually choose Microsoft Fabric components, every decision will have a clear reason behind it.

Key takeaways

• Technology should never be the starting point.

• A dashboard is not the problem you’re solving.

• Every architectural decision should be traceable to a business need.

• Good data architecture begins with understanding operational workflows.

• The same thought process can be applied in any industry.

• Microsoft Fabric is valuable when it is chosen for the right reason.

Final thoughts

Although we’ve used NHS patient flow as our example, the lesson extends far beyond healthcare.

Every organisation has its own version of the same challenge.

• In retail, it might be improving stock availability.

• In manufacturing, reducing production downtime.

• In financial services, identifying fraud earlier.

• In logistics, improving delivery performance.

The business problem changes, but the approach doesn’t.

• Understand the problem.

• Understand the people making decisions.

• Design the architecture around those decisions.

• Only then decide whether Microsoft Fabric — or any other technology — is the right tool for the job.

That’s the mindset we’ll carry through the rest of this series. We’ll spend less time asking:

“What can Microsoft Fabric do?” And more time asking:

“What does the organisation need, and why is this the right architectural decision?”

I believe that’s a far more valuable conversation.

References

This article is aligned with established guidance from:

• Microsoft Learn — Microsoft Fabric architecture, data engineering, data warehousing, semantic models, governance, and analytics design patterns.

• Microsoft Cloud Adoption Framework — architecture decision-making, governance, and operating model guidance.

• NHS England — patient flow, urgent and emergency care, discharge improvement, and operational performance.

• NHS England Data Model and Dictionary — standard NHS data definitions.

• HL7 FHIR — healthcare interoperability standards.

  
  

Next week: Understanding the current state — mapping the patient journey, identifying delays, and discovering where the data really lives.