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

Week 3: Defining Success — Designing for Better Decisions, Not Better Dashboards

"A dashboard doesn't improve patient flow. Better decisions do."

Where we are in the journey

Every architecture project should reduce uncertainty before introducing technology.

Our journey so far has been deliberately slow—and that's by design.

✅ Week 1 – Define the Problem

We asked why patients were experiencing delays. Not what dashboard needed building.

✅ Week 2 – Understand the Current State

We mapped the patient journey, identified operational bottlenecks and discovered where information really lived.

This week

▶ Week 3 – Define Success

Before we design a single component in Microsoft Fabric, we need to answer one question:

What decisions are we trying to improve?

The biggest mistake in analytics projects

One sentence has quietly undermined more analytics projects than almost any other.

It usually sounds like this:

"The business needs a dashboard."

Do they?

Or do they need to make a better decision?

Those are not the same thing.

A dashboard is only one possible way of presenting information.

If the information doesn't help someone act differently, the dashboard has delivered activity—not value. That distinction matters.

Because organisations don't invest in analytics to own more reports. They invest to make better, faster and more confident decisions.

Start with the outcome, not the metric

When stakeholders talk about improving patient flow, they often jump straight to metrics.

Average Length of Stay.

Bed Occupancy.

Delayed Discharges.

Emergency Department Waiting Times.

These measures are important.

But they're outcomes.

They don't tell us which decisions need to change to improve them.

Instead, ask:

"If this metric improves, what decision will people be making differently?"

That question shifts the conversation from reporting to operational improvement.

A different way to think about architecture

Here's the framework I'll use throughout the rest of this series:

Decision First - Architecture Model

Notice where technology appears. At the bottom. Not the top.

This is what I call the Decision-First Architecture Model.

It's a simple reminder that technology should always support a decision—not become the objective.

Whether you're working in healthcare, banking, retail or manufacturing, the principle is the same.

Turning outcomes into decisions

Let's return to our patient flow example. The business outcome might be:

Reduce delays in discharging patients who are medically fit to leave hospital.

That sounds clear. But it's still too broad to design a data platform.

So we ask another question.

Which operational decisions influence that outcome?

For example:

• Which patients should be prioritised for discharge today?

• Which wards are approaching capacity?

• Which patients are waiting for pharmacy, transport or community care?

• Where are delays increasing compared with last week?

• Which teams need to intervene first?

Now we're getting somewhere. These are decisions. And decisions can be supported by information.

Information before data

This is another distinction that often gets overlooked. People ask for data.

What they really need is information.

Data might tell us that a patient has been in hospital for seven days.

Information explains that the patient has been medically fit for discharge for three of those days and is waiting for a community care package.

That's the insight that supports action. Good architecture doesn't simply connect systems. It connects information to decisions.

Not every question deserves real-time data

Modern platforms make it tempting to stream everything.

But should we?

Let's challenge that assumption.

If a discharge planning meeting takes place every morning at 9:00, does that team really need updates every 30 seconds? Probably not.

On the other hand, a site operations team managing hospital capacity throughout the day may benefit from near real-time visibility into admissions, transfers and discharges.

This is where architecture becomes a balancing act.

More data isn't always better. Faster isn't always more valuable. The right level of information depends on the decision being made.

Defining meaningful success

Success shouldn't be measured by how many reports are published or how many users log into Power BI.

Those are adoption metrics.

They don't necessarily tell us whether the organisation is performing better.

Instead, success might include:

• Fewer delayed discharges.

• Earlier identification of patients at risk of delayed discharge.

• Reduced time spent preparing operational reports.

• Greater confidence in a single version of the truth.

• Faster decision-making during bed management meetings.

Notice something. None of these success measures mention Microsoft Fabric.

That's intentional. Technology enables success. It doesn't define it.

Challenging our own assumptions

A good architect doesn't just validate requirements.

They challenge them.

For example:

"We need a real-time dashboard."

Do you?

Or do you need better information before the morning operational meeting?

"We need AI."

Perhaps.

Or perhaps clearer operational ownership would solve the problem more effectively.

"We need to replace all the spreadsheets."

Maybe.

Or perhaps those spreadsheets highlight valuable information that existing systems don't provide.

Architecture isn't about accepting every request at face value. It's about understanding the need behind the request.

Architecture artefact

By the end of Week Three, we should have produced a Business Outcomes and Decision Framework, including:

• The desired business outcomes.

• The operational decisions that influence those outcomes.

• The information required to support those decisions.

• Success measures linked to operational improvement.

• Assumptions to validate during solution design.

This becomes the bridge between discovery and architecture.

Looking ahead

We've now built three important foundations.

Week 1

What problem are we solving?

Week 2

How does the organisation operate today?

Week 3

What decisions need to improve?

Next week, we'll begin designing the target architecture. Not by selecting Microsoft Fabric features, but by defining the principles that our architecture must satisfy. Only then will we evaluate which Fabric capabilities best support those principles.

Key takeaways

·         People don't need more dashboards. They need better decisions.

·         Every metric should be linked to an operational decision.

·         Information is more valuable than raw data because it enables action.

·         Real-time data is only valuable when the decision requires it.

·         Technology should always be the final response to a well-understood business need.

References

The principles discussed in this article are supported by established guidance on enterprise architecture, decision-making, and healthcare improvement:

• Microsoft Learn – Microsoft Fabric documentation: https://learn.microsoft.com/fabric/ (architecture, analytics engineering, semantic models, governance and workload design).

• Microsoft Cloud Adoption Framework: https://learn.microsoft.com/azure/cloud-adoption-framework/ (strategy, governance, architecture and design principles).

• NHS England – Improvement Hub: https://www.england.nhs.uk/improvement-hub/ (operational improvement, patient flow and transformation).

• NHS England – Data Model and Dictionary: https://www.datadictionary.nhs.uk/ (consistent data definitions across NHS organisations).

• HL7 FHIR: https://www.hl7.org/fhir/ (interoperability standards for exchanging healthcare information).

• The Open Group Architecture Framework (TOGAF®): https://www.opengroup.org/togaf (architecture driven by business capabilities, stakeholder concerns and business outcomes).