Week 4: Designing the Target Architecture — Before Choosing Any Technology

“Good architecture removes complexity from the business, not hides complexity in technology.”

Where we are in the journey

We’ve deliberately taken our time.

Not because we’re avoiding technology.

Because we’re avoiding expensive assumptions.

So far we’ve answered three questions.

✅ Week 1

What problem are we trying to solve?

✅ Week 2

How does the organisation operate today?

✅ Week 3

What decisions need to improve?

This week we answer a fourth question.

What principles should guide the architecture?

Notice that we’re still not selecting Microsoft Fabric components.

That’s intentional.

Don’t design a platform. Design a way of working.

When people hear the word architecture, they often imagine diagrams. Boxes. Arrows. Cloud icons. But that’s only the visible part. The real architecture exists long before anyone opens Visio.

It’s the thinking that explains why every design decision exists. If two architects produce completely different technical designs that both satisfy the same business principles, either solution could be valid. The technology isn’t the architecture. The reasoning is.

Imagine building a new hospital

Imagine an NHS Trust decides to build a new hospital.

Nobody begins by choosing the colour of the walls.

Or the type of flooring.

The first questions are much more fundamental.

• How many patients will we serve?

• Which services will be provided?

• How should patients move through the building?

• How do we keep patients safe?

• How do staff work efficiently together?

Only after answering those questions do the architects begin drawing the building. Designing a data platform is no different.

From business principles to architecture principles

Last week we agreed that our objective wasn’t to build dashboards. It was to improve operational decisions. Now we translate that into architectural principles. For our NHS Patient Flow case study, those principles might look something like this.

Principle 1 — One version of the truth

If different teams produce different answers for the same question, confidence disappears.

Our architecture should provide trusted definitions that everyone understands.

Not multiple interpretations of the same metric.

Principle 2 — Data should move once

One pattern I still see in many organisations is the same dataset being copied again and again.

One extract becomes three.

Three become ten.

Eventually nobody knows which one is correct.

Where possible, data should be managed centrally and reused rather than continually duplicated.

Less movement usually means fewer opportunities for inconsistency.

Principle 3 — Information should arrive when decisions are made

Not every process needs real-time data. Equally, some operational teams cannot wait until tomorrow morning. The architecture should reflect the rhythm of the business.

Technology should adapt to operational needs — not the other way around.

Principle 4 — Trust is more valuable than speed

An operational meeting delayed by five minutes is inconvenient. Making the wrong decision because people don’t trust the data is far more expensive. Reliable information almost always delivers more value than faster information.

Principle 5 — Design for change

Healthcare never stands still. Services merge. Policies change. New systems are introduced.

If every organisational change requires rebuilding the platform, the architecture wasn’t designed to evolve. Good architecture expects change.

What are we actually designing?

This is where many projects become too technology-focused. Instead of asking:

“What should our Fabric architecture look like?”

Ask:

“What capabilities does the organisation need?”

For example:

The organisation needs to:

• understand patient flow

• monitor bed availability

• identify discharge delays

• measure operational performance

• provide trusted reporting

• protect sensitive patient information

• support future AI initiatives

Those are capabilities.

Technology exists to enable them.

Let’s return to our discharge delay scenario. During discovery, we found that ward teams maintain their own discharge trackers because they don’t trust the central report.

A purely technical response might be:

“Replace the spreadsheet.”

A better architectural response is to ask:

Why don’t they trust the central report?

Perhaps different systems define Medically Fit for Discharge differently.

Perhaps timestamps are captured inconsistently.

Perhaps updates from community services arrive hours later.

Replacing the spreadsheet doesn’t solve any of those issues.

Improving the underlying information does.

That’s the difference between solving symptoms and solving causes.

Good architecture creates fewer decisions, not more

This might sound counterintuitive. But one of the goals of architecture is reducing the number of decisions users have to make.

For example, should an operational manager need to decide:

• Which report is correct?

• Which spreadsheet is the latest?

• Which patient identifier should they use?

• Which department owns this data?

Of course not.

Those decisions should already have been made by the architecture.

The platform should simplify the work of the business, not increase its cognitive load.

Designing for people, not platforms

One lesson I’ve learned is that successful platforms are rarely remembered because of the technology they use.

They’re remembered because people stop talking about the technology altogether.

Instead, conversations become:

“I can finally see where delays are happening.”

“We all work from the same numbers now.”

“The morning meeting takes fifteen minutes instead of an hour.”

Those aren’t technology outcomes.

They’re business outcomes.

And that’s what architecture should ultimately enable.

Architecture artefact

By the end of Week Four, we should have produced a Target Architecture Principles Document, including:

• Business principles.

• Architecture principles.

• Core organisational capabilities.

• Non-functional requirements such as security, governance, scalability and resilience.

• Assumptions and design constraints.

• Principles that every future Microsoft Fabric design decision must satisfy.

Notice what isn’t included.

No Lakehouse.

No Warehouse.

No Data Factory.

No Semantic Models.

Not yet.

Because we’re still defining what good looks like before deciding how to build it.

Looking ahead

We’ve now established four strong foundations.

Week 1

Understand the problem.

Week 2

Understand today’s business.

Week 3

Understand the decisions that need to improve.

Week 4

Define the principles that will guide the solution.

Next week, something interesting happens. For the first time, we’ll begin evaluating Microsoft Fabric. Not because we’ve reached a predetermined conclusion. But because we’ve now gathered enough evidence to assess whether its capabilities align with the architecture we’ve designed. Technology finally enters the conversation. And when it does, every choice will have a clear purpose.

Key takeaways

• Architecture is a collection of decisions — not a collection of technologies.

• Business principles should shape architecture principles.

• Good architecture removes complexity from the business rather than hiding complexity inside technology.

• If users create spreadsheets to compensate for missing information, the architecture hasn’t yet solved the real problem.

• Technology should implement architecture — not define it.

  
  

A personal reflection

Over the years, I’ve realised that the best architecture reviews rarely begin with a technical debate.

They begin with simple questions.

Why are we doing this?

Who benefits?

What decision becomes easier?

If nobody can answer those questions, the discussion usually drifts towards products, features and diagrams.

That’s often a sign that we’ve skipped the most important stage of the journey. For me, architecture has never been about drawing the most impressive diagram. It’s about making sure every box on that diagram has earned its place.

When you approach architecture that way, technology becomes much easier to choose — because the business has already told you what it needs.

References

The ideas in this article are informed by established architecture and healthcare guidance, while the Decision-First Architecture approach presented here is an original framework developed for this series.

• Microsoft Learn — Microsoft Fabric: https://learn.microsoft.com/fabric/ (architecture, OneLake, data engineering, warehousing, governance, security and analytics).

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

• The Open Group TOGAF® Standard: https://www.opengroup.org/togaf (architecture principles, stakeholder alignment and capability-based planning).

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

• NHS England — Data Model and Dictionary: https://www.datadictionary.nhs.uk/ (standard NHS data definitions and information consistency).