August 21, 2026.

A Fabric implementation can become complicated very quickly.

A few source systems become a collection of pipelines. The pipelines populate a Lakehouse. The Lakehouse gets Bronze, Silver and Gold layers. A Warehouse appears somewhere in the middle. Power BI sits at the end.

The architecture diagram starts to look impressive. But the diagram can be technically correct and still be the wrong architecture for the workload.

Medallion architecture is a useful convention. It is not an architecture by itself. The architecture is the set of decisions about why those layers exist, what they contain, who owns them, how data moves between them, and what consumers are allowed to depend on. Draw the boxes before those decisions have been made and you spend the rest of the programme reverse-engineering justifications for them.

So I prefer to work backwards.

Before deciding whether a workload should use a Lakehouse, Warehouse, data pipeline, Dataflow Gen2, notebook or some combination of them, I want to understand what the workload actually requires. That means classifying the workload first.

Not every organisation needs the same Fabric architecture. Even within the same organisation, different workloads can have very different characteristics.

Start with the workload, not the Fabric item

When I assess a workload, I am trying to answer a fairly simple question:

| What does this workload need the platform to do?

That sounds obvious, but it changes the conversation. Instead of starting with “should we use a Lakehouse?”, the first questions are about the data itself and the constraints around it.

What follows is the order in which I work through those questions. This is not a separate framework from the Transformation Blueprint. It is the practical sequence through which the relevant decisions get resolved, with the Blueprint holding the answers that come out of it.

The order matters as much as the questions, because each answer narrows the next decision. You cannot sensibly choose a transformation pattern until you know how the data arrives. You cannot choose a storage layer until you know what the transformation has to do. You cannot size capacity until you know what all of it will be running.

Each step below also identifies which of Kilvora’s nine delivery domains it belongs to. The domains describe how a platform lives once it exists. This sequence describes how the decisions get made before it does.

---

PART ONE

What the workload needs

1. Understand the source before designing ingestion

Delivery domain 03 · Ingestion & Processing Engineering

Everything downstream depends on this, which is why it comes first.

I do not treat every source as simply “a source system”. A transactional SQL database, an API, a SaaS application and a collection of CSV files can all provide data to Fabric, and their ingestion requirements can be completely different.

For each source I want to understand:

– Volume. How much data exists today, and how quickly is it growing?

– Change pattern. Is the source mostly static, periodically updated, or continuously changing?

– Extraction method. Is incremental extraction possible? Is CDC available? Does the source expose a reliable modification timestamp or watermark?

– Frequency. Does the business need this every five minutes, every hour, overnight, or only when a process runs?

– Source constraints. Can the source tolerate frequent querying? Are there extraction windows? Are there API limits?

These questions matter because ingestion is not only a technical movement problem. It is also a source-system protection problem.

Repeatedly performing full extracts from a large operational database works during development, when the table holds a few million rows. It becomes a different problem when that table holds hundreds of millions of records and the source system is simultaneously supporting live transactions.

I have seen this in production. On one platform I worked on, full datasets were being reprocessed on every pipeline run. The pipelines completed, so nothing appeared broken. Rebuilding them around incremental loading removed reprocessing that was never necessary, and a substantial share of the capacity consumption went with it. An ingestion design of that kind is never wrong in a way that produces an error, only in a way that produces a bill.

The extraction method deserves specific attention, because the answer in Fabric has changed. Where the source supports it, Mirroring gives near real-time replication into OneLake without building an extraction pipeline at all. Copy job handles bulk, incremental and CDC-based movement without assembling the orchestration by hand. Neither is right for every source, but both should be ruled in or out explicitly before anyone writes a watermark query.

---

2. Decide what has to happen to the data

Delivery domain 03 · Ingestion & Processing Engineering

Once the arrival pattern is understood, I look at what needs to happen to the data. This is where I separate ingestion, transformation and orchestration deliberately, because conflating them is how a pipeline ends up doing three jobs badly.

A common mistake is to select a technology first and then make every transformation fit it. I would rather look at the transformation itself.

Is it simple filtering and shaping, or complex business logic? Does it join several relational datasets? Does the volume justify distributed processing? Does it need to be maintainable by a SQL-focused team? Does it need to be reusable across multiple downstream workloads, or does it serve exactly one?

Those answers drive the pattern. Data pipelines for orchestration and movement. Dataflow Gen2 where a low-code transformation is genuinely the right fit and the person maintaining it is comfortable there. SQL where the transformation is relational and the team is a SQL team. Spark where scale or complexity warrants it.

The objective is not to use every Fabric capability. It is to give each workload an execution pattern someone can still maintain in two years.

That distinction matters more than it sounds, because it is the point at which the next decision becomes answerable.

---

3. Decide what the storage and serving layer must achieve

Delivery domain 01 · Architecture & Platform Design

Only now does the Lakehouse versus Warehouse question become meaningful, because only now is it clear what is going to be written into it, by what, and how often.

This is not a question of which technology is better. It is a question of what this workload requires from its storage and serving layer.

A Lakehouse provides open Delta-based storage and flexibility for engineering workloads. It works particularly well where data engineering and analytical processing need to operate close to the underlying data, and where the processing is not naturally expressed in SQL.

A Warehouse provides a relational analytical environment with full T-SQL and multi-table transactional support. It is appropriate where SQL-based modelling and structured analytical serving are central to the workload, and where the team maintaining it is a SQL team.

There are also situations where using both is correct. Because both sit on OneLake, the decision is less irreversible than it once was. It remains a decision about ownership, skills and long-term maintenance, not only about storage format.

Notice what determined the answer. Not a preference for one item over another, but the extraction pattern from step one and the transformation pattern from step two.

---

4. Treat workspace design as an architectural decision

Delivery domain 01 · Architecture & Platform Design

With the storage layer decided, the next question is where it sits and who controls it.

A workspace is not a folder for Fabric items. It creates boundaries around ownership, access, deployment and administration. So I want to know:

– Which business or technical team owns this workload?

– What needs to be isolated, and from what?

– Which environments are required?

– Who develops against it, who administers it, who consumes it?

– Does it need a different deployment lifecycle from anything else?

– Are there capacity or operational reasons to separate it?

Workspaces created as implementation progresses get rationalised afterwards, and the rationalisation is where permission models go wrong. A boundary drawn for convenience in week three becomes the thing preventing a clean separation of duties in month nine.

This is also the point where architecture starts connecting to security, which is the next decision and the one most often deferred.

---

5. Let security determine where the boundaries fall

Delivery domain 02 · Security & Governance

Security is usually discussed after the platform has been designed. I prefer the opposite, because a security requirement can change the architecture rather than sit on top of it.

Before finalising how data is organised, I need to understand who should be able to access it. That includes the obvious questions around workspace roles and Entra groups, but it goes further:

– Does the data contain sensitive or regulated information?

– Are there different access requirements between departments?

– Will row-level, column-level or object-level security be required?

– Should certain datasets be isolated entirely?

– Who is allowed to develop against the data, as opposed to read it?

– Who administers the platform, and who administers the capacity?

And most importantly: where should each control be applied?

The same requirement can be met at the workspace boundary, in the storage layer, in the semantic model, or in the report. Those are not equivalent choices. They differ in how they scale, how they are audited, and how likely they are to be quietly bypassed by the next workload that needs the same data.

This is why security comes before the design is fixed rather than after. An access requirement discovered here can send you back to step four to redraw a workspace boundary. Discovered after implementation, it usually gets solved in the semantic model instead. That works until the second consumer arrives.

---

6. Design backwards from consumption

Delivery domain 04 · Semantic Layer & Reporting Governance

I want to know what is going to consume the data before the layers underneath it are finalised.

Power BI is usually the primary consumer, but rarely the only one. A platform may also serve SQL consumers, operational applications, downstream analytical workloads, and data science or engineering workloads. Each introduces different serving requirements, and a technically elegant platform that serves its consumers poorly is still a poor architecture.

For Power BI specifically, the semantic model is an architectural component, not a reporting detail. Storage mode, refresh strategy, concurrency and where security is enforced all interact with decisions made in the previous five steps, and they interact with capacity, which is why the semantic layer is usually where upstream mistakes first become visible.

The governance question matters as much as the design one. Who owns the model? Who is permitted to build a new one? What stops five semantic models appearing over the same curated tables, each with its own definition of revenue?

That question is not answered by the modelling tool. It is answered by the ownership and workspace decisions made in steps four and five.

---

PART TWO

What happens when it goes wrong

The steps above describe the workload when everything behaves. The next three describe it when something does not. They are architectural decisions rather than operational ones, because retrofitting any of them means changing the design.

7. Design for failure before failure occurs

Delivery domain 05 · Reliability & Recoverability

One of the questions I ask early is:

| What happens when this doesn’t work?

A successful pipeline run is not proof that the data platform succeeded, and a failed one is not necessarily a problem, provided the failure is safe.

So I want to know what happens if an incremental load starts and fails partway through. Whether the workload can be safely restarted. Whether we can identify what was already processed. Whether a rerun produces duplicate data. Whether we can determine which downstream workloads are affected and need to follow.

Restartability, idempotency and reconciliation are not features to bolt onto a pipeline after it has been built. Retrofitting them usually means rewriting the load pattern, which is why the cost of skipping them lands months later and is charged to someone else’s budget.

---

8. Decide how you will know

Delivery domain 06 · Observability & Failure Detection

Reliability is about what the platform does when something goes wrong. Observability is about whether anyone finds out.

The failure mode I see most often is not a broken pipeline. It is a platform where nobody can answer basic questions quickly: what ran last night, what it processed, how long it took, what it cost, and whether that is normal.

So the design has to establish what is logged, where it is logged, who looks at it, and what triggers an alert. Run outcomes and durations. Row counts in and out. Capacity consumption attributable to a workload. Failures routed to someone expected to act, rather than to a mailbox nobody reads.

The test is simple. When a business user asks why yesterday’s number looks wrong, how long does it take to answer, and does answering it require the person who built the platform?

---

9. Decide what “correct” means, and how it is checked

Delivery domain 07 · Data Trust & Quality

This is the failure mode that does the most damage, because nothing alerts on it.

The pipeline succeeds. The refresh completes. The report renders. And the numbers are wrong.

Technical success and correct output are different things, and only one of them is monitored by default. So I want to know what validation exists between the two.

What happens if the source delivers materially fewer records than expected? What happens if it delivers none at all, and does the load treat that as an empty day or as a missing extract? What happens if a transformation completes but produces a result that is out of range? Can the curated figures be reconciled back to the source, and by whom? When a definition changes upstream, what tells anyone downstream?

These checks belong in the design because their absence is invisible. A platform with no data quality controls looks identical to a platform with excellent ones, right up until trust is lost. And trust, once lost, is not recovered by fixing the underlying defect.

---

PART THREE

What it takes to run

10. Treat capacity and performance as architectural decisions

Delivery domain 08 · Cost & Performance Optimisation

Capacity sizing comes near the end deliberately, because it is the sum of every decision above it. Asking “how large a Fabric capacity do we need?” before those decisions exist produces a guess.

Once they do exist, better questions become available. How much processing will occur, and when? How many workloads run concurrently? Are there predictable peaks? How frequently do semantic models refresh? Are engineering workloads competing with analytical ones? Are transformations repeatedly processing data that has not changed?

Increasing the SKU resolves a capacity constraint. It does not resolve an inefficient workload. It pays for that workload at a higher rate.

That is worth stating plainly, because capacity sizing is frequently the first response to a performance complaint. Consider an estate where spend has risen to a level nobody can tie back to a team, a workload or an outcome. Right-sizing the capacity is part of the answer. The larger part is usually correcting the workloads consuming it, and correcting workload placement so that engineering and analytical work stop competing for the same compute.

Scheduling is an architectural lever here too, and an underused one. Moving contention is often cheaper than buying capacity to absorb it. It is also available at design time in a way it is not once forty pipelines are already running at 02:00.

If cost visibility is the problem you are currently facing on a live estate, the Cost & Performance Audit is a focused way to establish where the consumption actually comes from.

---

11. Establish ownership and deployment before production

Delivery domain 09 · Deployment & Operational Readiness

The last question is what happens once the build is done.

How does a change move from development to test and production? How are dependencies managed? How do we know what version is deployed? What happens when a change has to be reversed? Who responds when a pipeline fails at 02:00? Who investigates an unexpected increase in capacity consumption? Who owns the semantic model six months after handover?

These are not purely operational questions, because a platform that cannot be deployed, monitored, supported and recovered in a controlled way is not finished. Manual, ungoverned releases are not a process gap to be tidied up later. They are an architectural weakness that determines how quickly anything can safely be changed.

I want the operating model understood while the architecture is being designed. Not after go-live, and not by whoever happens to be available at the time.

---

IN CLOSING

Bringing the decisions together

By this point the workload is clear: how the data originates and changes, how it needs to arrive, what has to happen to it and where that processing makes sense, what it needs from a Lakehouse or a Warehouse, where its boundaries sit, who needs access and where controls apply, how the result will be consumed, what happens when it fails, whether anyone will notice, whether the output can be trusted, what it will demand from capacity, and who owns it in production.

Those decisions give me the basis for the architecture. Only at that point do I want to draw the final Fabric design.

It may well end up looking like:

Source systems → Ingestion → Raw/landing → Transformation → Curated data → Semantic model → Consumption

But the diagram is not the architecture. The reasoning behind each box is.

Why the order matters

The sequence above is not a checklist, and it is not the same thing as the nine domains it maps onto. The domains describe a platform that exists. The sequence describes how you get one that is worth having.

Each decision constrains the next. Source behaviour constrains the ingestion pattern. The ingestion and transformation patterns constrain the storage choice. Storage and ownership constrain the workspace topology. Workspace topology constrains where security can be enforced. Security constrains data organisation. Data organisation constrains semantic modelling. Semantic modelling drives capacity consumption. Capacity and scheduling shape the operational design. And the operational design determines whether any of it survives contact with a team that did not build it.

Work through them in that order and each answer makes the next one easier. Work through them in the wrong order, or in parallel as isolated technical tasks, and the result is a set of individually sensible decisions that do not fit together.

What the ordering protects is a platform that stays understandable, governable, observable and cost effective as it grows. None of those four qualities can be added once the platform is running. They are settled by the decisions above, long before anyone is in a position to measure them.

The purpose of the architecture is to make those decisions explicit before implementation begins. The implementation then builds what has been decided, rather than allowing the architecture to emerge accidentally from whichever Fabric item happened to be created first.

If the question in front of you is the earlier one, whether Fabric is the right platform at all and what would have to be resolved before committing to it, that is what the Readiness Assessment answers.

Working through this sequence for a specific organisation, and recording the answers as decisions rather than opinions, is what the Transformation Blueprint is for. The questions above are the general form. A Blueprint holds your answers to them, along with the reasoning and the trade-offs, before anyone starts building.

The Fabric components matter. But they come after the decisions.