← All services
FabricArchitectureData Platform

Fabric Architecture Review

Are you building in Microsoft Fabric — but unsure whether the architecture will still make sense when the solution grows?

An independent review of your Fabric architecture before reasonable local decisions become expensive platform complexity.

Start with what is actually happening.

  • Lakehouse, Warehouse, Dataflows and Pipelines are all present, but the boundaries are unclear.
  • Teams duplicate data or transformation logic.
  • Nobody agrees where business logic should live.
  • Bronze, Silver and Gold exist in diagrams more clearly than in day-to-day practice.
  • The architecture is growing faster than the operating model around it.

Good work starts with better questions.

01

Are the right Fabric components being used for the right workloads?

02

Where should transformation and business logic live?

03

Is the architecture scalable and maintainable?

04

What complexity can be removed before it becomes normal?

The scope follows the problem.

I do not force every engagement through the same checklist. These are the areas that may matter; the agreed scope determines how deep we go.

OneLake and data-domain structure

Lakehouse and Warehouse responsibilities

Data Factory, Pipelines and Dataflows Gen2

Notebooks and transformation boundaries

Semantic models and serving layer

Medallion patterns where they add value

Environment separation and deployment flow

Ownership and operational responsibilities

Something you can use after the conversation ends.

The output should help you make a decision, change a practice or move the work forward. It should not exist simply to prove that work happened.

01

Architecture Assessment

A concise view of what is working, what is unclear and where risk is accumulating.

02

Risk & Complexity Map

The decisions most likely to create cost, duplication or maintenance problems later.

03

Recommended Target Direction

A practical architecture direction rather than a diagram for its own sake.

04

Decision Rationale

Why one option may fit your context better than another.

05

Architecture Review Session

A working discussion with the people who will own the decisions.

Enough structure to make the work clear. Not so much process that the process becomes the work.

01

Context

We start with a short conversation about what is happening, what matters and what has already been tried.

02

Review

I analyse the relevant parts of the solution or operating model at the depth agreed for the engagement.

03

Prioritise

I organise observations around impact, risk and usefulness — not around how many issues I can find.

04

Walkthrough

We go through the findings together, challenge assumptions and discuss trade-offs.

05

Next step

You decide what happens next: implement internally, continue together or stop because the focused engagement was enough.

I keep the client-side time demand deliberately light. A focused assessment usually needs a kickoff conversation, access or materials, and a final review session. We agree the exact involvement before we start.

This is likely to help if...

  • You are already building in Fabric and want an external architecture check.
  • Different teams are making platform decisions independently.
  • You want to simplify before scaling usage.
  • You need trade-off thinking, not a generic reference architecture.
  • You need a full implementation team to build the platform end to end.
  • You are still deciding whether Fabric is relevant at all; start with Migration Readiness instead.

If the problem is real but the format is wrong, that is useful to know early. I would rather redirect the conversation than force the challenge into the wrong service.

Are you building in Microsoft Fabric — but unsure whether the architecture will still make sense when the solution grows?

Bring me the problem, not a polished brief. A few sentences about what is happening and what you would like to change are enough to start.

Tell me what's happening

Send me a message.

You do not need a polished brief. Whether the topic is Power BI, Fabric, AI, team training, mentoring, coaching or simply a challenge that needs untangling, leave a few details and we can start from there.

SIGNALMESSAGECONVERSATION

AI & TRANSPARENCY

AI supports selected parts of my work — it does not replace my judgement, responsibility or relationship with the client.

I use AI tools for tasks such as research, organising information, structuring content and preparing materials. I treat AI as support for my work — not as an autonomous author or decision-maker. Anything I publish or use professionally remains my responsibility.

In coaching, I do not use AI to automatically assess, diagnose or make decisions about a client. AI does not replace attention, confidentiality or human responsibility for the coaching relationship.

AI may support the process. Human responsibility remains.