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

Week 2: Understanding the Current State — Mapping the Patient Journey Before Designing the Data Platform

"You can't improve what you don't fully understand."

If Week One was about understanding the problem, Week Two is about understanding today's reality.

Last week, we deliberately stayed away from Microsoft Fabric. Instead, we focused on a much more important question.

What problem are we actually trying to solve?

Our fictional NHS Trust wanted to understand why patients who were medically fit for discharge were still spending unnecessary time in hospital.

At first, it sounded like a reporting problem. The more we explored it, the more we realised it was a decision-making problem.

This week, we take the next logical step.

Before we think about architecture, data models or technology, we need to understand how the organisation works today.

Because if we don't understand today's reality, we'll end up designing tomorrow's solution around assumptions.

Good architecture starts with observation

One of the biggest misconceptions about solution architecture is that it begins with diagrams. It doesn't. It begins with listening. Listening to operational teams. Watching how work gets done. Understanding where people struggle.

Learning how decisions are made. Only then do the diagrams start to make sense.

One lesson I've learned over the years is this:

People rarely describe the whole problem in the first meeting.

They describe the symptoms. The real problem usually reveals itself as you spend time understanding the process.

Resist the temptation to design too early

At this stage, it can be tempting to open Visio or Whiteboard and start sketching an architecture.

A Lakehouse here. A Data Warehouse there.

Maybe some Data Factory pipelines connecting everything together. It feels like progress. But without understanding the current state, those diagrams are little more than educated guesses. Good architects earn the right to design by first understanding the environment they're designing for.

Start with the patient, not the technology

One mistake data teams sometimes make is mapping systems before mapping the business process.

Instead of asking,

"What applications do we have?"

Start by asking,

"What journey does the patient take?"

Imagine a patient arriving at the Emergency Department.

Their journey may look something like this:

This isn't a data flow. It's a patient journey. And that's an important distinction.

Technology exists to support this journey—not define it.

Every handover tells a story

As the patient moves through the organisation, responsibility moves too.

Emergency clinicians. Ward teams. Radiology. Pharmacy. Therapists.

Discharge coordinators. Community services.

Each handover introduces another opportunity for delay.

A scan hasn't been reported. Medication isn't ready. Transport hasn't been arranged.

Community care hasn't been confirmed. Sometimes the delay is clinical.

Sometimes it's operational. Sometimes the information exists—but isn't visible to the people making decisions.

These are the moments we're interested in.

Because every operational delay eventually becomes a data question.

Follow the process before following the data

When discovery workshops begin, one of the first questions people often ask is:

"Where is the data?"

It's a reasonable question. But there's usually a better one.

"Where does the process slow down?"

Suppose a patient is medically fit for discharge but remains in hospital for another three days.

The dashboard can tell us that it happened. The process explains why.

Understanding the "why" is far more valuable than simply measuring the outcome.

One patient. Many systems.

By this point, we've been talking entirely about patients and processes.

Now we can begin looking at the systems that support them.

A single patient journey may generate information across multiple applications.

Stage	Typical System
Admission	Patient Administration System (PAS)
Clinical care	Electronic Patient Record (EPR)
Diagnostics	Radiology and Pathology
Medication	Pharmacy
Bed allocation	Bed Management System
Community care	Community Systems
Reporting	Existing Data Warehouse or Power BI

Each system captures a different part of the story.

None of them tells the whole story on its own.

That's why organisations often struggle to answer what appears to be a simple operational question.

Where the data really lives

One of my favourite questions during discovery workshops is:

"Show me how you actually do your job."

The answer is rarely:

"Everything is in the system."

Instead, someone opens:

• an Excel spreadsheet,

• a shared folder,

• an email report,

• a notebook,

• or a whiteboard used during the daily discharge meeting.

At first, these look like problems that need removing.

But I see them differently.

They're clues.

They tell us where existing systems aren't meeting operational needs.

People rarely create manual workarounds for fun.

They create them because they're trying to get the job done.

Don't blame the spreadsheet

It's easy for technical teams to look at spreadsheets and conclude they should disappear.

Sometimes they should.

But not before asking a few simple questions.

Why was it created?

Who maintains it?

What information isn't available elsewhere?

Who depends on it?

More often than not, the spreadsheet is solving a business problem that no existing system has solved.

Replace the spreadsheet without understanding its purpose, and you risk removing the solution before fixing the problem.

Discovery before design

By now, you may have noticed something. We're in Week Two of a Microsoft Fabric series. And we still haven't opened Microsoft Fabric.

That's deliberate.

Because we're not learning a product. We're learning how to think like an architect.

Technology decisions are only as good as the discovery that informs them.

The better we understand today's landscape, the better our architecture decisions will be next week and beyond.

This week's deliverables

By the end of this stage, we should have produced a set of artefacts that describe the current state.

Current State Process Map

How patients move through the organisation today.

Operational Pain Points

Where delays occur and why.

Stakeholder Map

Who owns each part of the process and who makes operational decisions.

Data Source Inventory

Which systems hold the required information.

Reporting Inventory

What reports already exist, who uses them, and where conflicting numbers appear.

Initial Data Observations

Early findings around data quality, ownership, duplication and trust.

Notice that none of these deliverables are technical.

Yet every technical decision we make later will depend on them.

Looking ahead

So far, we've answered two important questions.

Week One

What problem are we trying to solve?

Week Two

How does the organisation work today?

Next week, we'll begin defining the future state.

We'll translate today's operational challenges into measurable business outcomes, identify the decisions the organisation wants to improve, and define what success should look like. Only then will we be ready to design the architecture.

Key takeaways

• Architecture starts with observation, not diagrams.

• Map the patient journey before mapping the systems.

• Operational delays often reveal the most important data problems.

• Spreadsheets and manual processes are clues, not just technical debt.

• Discovery is one of the most valuable phases of any data platform project because it ensures every architectural decision is rooted in real business needs rather than assumptions.

  
  

Final thoughts

Although we've continued using NHS patient flow as our case study, the same principles apply in every industry.

Whether you're improving customer fulfilment in retail, reducing downtime in manufacturing, streamlining claims in insurance, or optimising deliveries in logistics, the discovery process remains remarkably similar.

Understand how work is done today. Observe where people struggle. Learn where information is created, shared, and trusted. Only then should you begin designing the future. Because good architecture isn't about drawing impressive diagrams.

It's about understanding people, processes, and decisions well enough that the technology almost chooses itself