The Transformation Blueprint is how Kilvora designs Microsoft Fabric platforms. Ten architectural decision areas, with major decisions documented through evidence, rationale and expected consequences before implementation begins.
The principle
Almost every failing Fabric estate I am called into is failing for the same reason. Not because the tooling was wrong, and rarely because the engineering was poor. It is failing because nobody decided what was being built before people started building it.
Pipelines end up running under a developer's account. Transformation gets pushed into the raw layer. Workspaces appear without owners. Capacity is selected through a licence conversation rather than workload evidence. These are not simply build mistakes. They are decisions that were never made, and delivery proceeded around the gap.
The asymmetry is what makes the design worth doing properly. Deciding the identity model before the first pipeline runs costs a conversation. Retrofitting it across a live estate with security already in place is expensive rework. The same is true of layer design, governance, capacity and deployment.
So the design comes first, and it is written down. That is the method.
When it applies
The design work is consistent. What changes is how much of the estate already exists, and how much of it should survive the design.
Fabric is agreed, licences may already be bought, and nobody has decided what the platform should look like. The Blueprint establishes the design that implementation is then measured against.
An internal team or delivery partner has started, but coherence is the concern. The method reviews what exists, keeps what is sound, and designs forward from there.
A Readiness Assessment has recommended proceeding. The design phase turns that recommendation into an architecture and reuses the relevant discovery rather than repeating it.
The design standard
Design work is easy to describe and harder to evidence. These are the standards that must be visible in the resulting architecture and working documents.
What gets decided
Every Fabric platform must resolve all ten areas, whether or not anyone notices. The method is to work through them deliberately, in an order that prevents one choice from quietly constraining another.
How the Fabric estate is organised across business domains, environments and shared platform services: workspace boundaries, domain hierarchy, ownership, isolation and promotion paths.
Whether a medallion approach is appropriate, how Lakehouses and layers are structured, what each layer is responsible for, and where raw, standardised and serving data separate.
Direct Lake against Import, model scope and ownership, refresh strategy, certification and the standards that keep the semantic layer maintainable.
The SKU the workload evidence supports, capacity placement across domains and environments, pause and resume, and a modelled cost trajectory rather than a launch price.
Identity model, workspace RBAC, row-level security design, sensitivity labelling, PII handling and how compliance obligations are met.
Named domain and workspace ownership, workspace approval, certification, naming standards, change control and the operating model that holds the platform together.
DEV, TEST and PROD workspace structure, Git branching, deployment pipelines, configuration management and how a failed release is rolled back.
Run logging, failure alerting, data quality visibility, capacity tracking, per-workspace attribution and who is told when something breaks.
The order the platform is built in: domain and workspace foundations first, security before data, governance before self-service, controls before pipelines and pilot before rollout.
How Fabric meets the rest of the estate: source systems, retained Azure services, the existing Power BI estate, identity and ITSM processes, and third-party tooling.
The record
Most architecture documents record what was chosen. Kilvora records the evidence, rationale and consequences behind major decisions so they can be questioned and revisited later. Where a genuine trade-off exists, the material alternatives are also captured.
The SKU in place was selected during a licensing conversation, before any workload existed. Nobody had modelled consumption.
Workload modelling puts peak consumption at 52 CUs during the morning batch window, driven by four ingestion pipelines running concurrently against overlapping sources.
F32, which covers average load at lower cost but throttles during the morning window. That delay pushes the semantic refresh beyond the hour people rely on the reports.
Higher committed spend than F32. Headroom for the second domain without another SKU change. Dev and test pause outside working hours, recovering part of the difference.
Reassess once the second domain is in production, or if the batch window changes.
What exists at the end
Not a slide deck presented once and filed. These are working documents used throughout delivery and updated when a decision changes.
Executive summary, maturity baseline, decision records, target architecture narrative, governance, security and sequencing rationale.
Target state, workspace and domain topology, logical business data flow, security architecture and deployment model, each written for the audience that needs it.
Workspace standards, certification model, naming conventions, change control and ownership, written so it can be adopted operationally.
Workload inventory, peak-load analysis, SKU recommendation with clear rationale, environment configuration and cost trajectory. Material alternatives are compared where they affect cost, risk or performance.
Architectural risks and inter-domain dependencies, each with impact, trigger, owner and mitigation.
Foundation, pilot, validation and expansion, expressed as an architectural sequence rather than a generic project plan.
Current state, target state, the decisions that matter most, governance, cost, roadmap and top risks, written for the people funding the build.
How it runs
Nothing is drafted before discovery is complete. Every decision is traceable to evidence from the estate, not to a preference brought in on day one.
Executive alignment, technical deep dive, domain sessions, security and compliance, BI and platform operations. Evidence from the environment is reviewed alongside what people say.
Each major decision is taken against the evidence, with its rationale and consequences stated. Competing options are compared only where the trade-off materially affects cost, risk, scalability or operations. Capacity and governance models are built from what discovery found, never from a template.
The design is put in front of the people who know the estate and challenged before anything is finalised. Decisions that survive that session are the ones worth building on.
Executive presentation, technical walkthrough and open risks stated plainly. Any departure from the design becomes a decision made consciously and on the record.
Delivery models
The design phase opens the engagement. What follows is the same architectural baseline carried into delivery rather than a separate document handed over and forgotten.
I join your team as the architect and, where appropriate, as the engineer. The design phase runs first, then the platform is built against it as scope evolves.
A bounded piece of platform is delivered to an agreed definition of done. The design phase establishes the scope before price is fixed, which makes the commitment evidence-based rather than optimistic.
Common questions
The Readiness Assessment determines whether Microsoft Fabric is the right direction and which workloads should move. The Transformation Blueprint begins once that decision has been made and defines how the platform should be designed before implementation starts.
If your architecture is documented, agreed across teams and supported by clear technical reasoning, it may not be. If key decisions exist only in people's heads or across disconnected documents, the method creates one defensible baseline for delivery.
The ten decision areas provide the framework. Where an area is genuinely not relevant, that is recorded explicitly as a constraint rather than left undefined or skipped by omission.
The design is a baseline, not a prison. When evidence changes or a new constraint appears, the relevant decision is reopened, the trade-off is documented and the architecture is updated deliberately.
Tell me what you are planning to build, what already exists and where the uncertainty sits. A short conversation establishes which delivery model fits and what needs to be decided first.
Start a conversation