Building a Microsoft Fabric Centre of Excellence - What Actually Works

Every organisation that buys Microsoft Fabric eventually has the same conversation. Someone, usually a data leader or a senior architect, says "we need a Centre of Excellence for this." Everyone nods. A document gets written. A small team gets named. Six months later, the COE either has more requests than it can handle, no actual authority to enforce anything, or both.

The Microsoft adoption roadmap has a sensible chapter on what a Centre of Excellence should look like. It is one of the more practical pieces of guidance Microsoft publishes, and it lays out goals, roles, and scope in a useful way. What it does not tell you is which of those things are load-bearing and which are nice-to-have, or what actually fails in the Australian market when you try to build one. That is what this post is about.

What a COE actually is, in practical terms

The Microsoft definition is "an internal team of technical and business experts who actively assist others within the organisation working with data." That is correct but vague.

A more useful working definition is: the COE is the small group of people who own the standards, mentor everyone else, and have enough credibility with both IT and the business to make decisions stick. Standards without credibility produce documents nobody reads. Credibility without standards produces a help desk that scales linearly with usage.

You will hear COE called a competency centre, a capability centre, or a squad. The label does not matter. The question that matters is whether anyone, when they get a tricky Fabric question, knows exactly who to ask and trusts that the answer will be both technically correct and pragmatic about the business context. If yes, you have a COE. If not, you have a wiki.

The goals worth fighting for

The Microsoft roadmap lists seven goals for a COE, ranging from "evangelising a data-driven culture" to "reducing technical debt." If you try to do all seven from day one, you will do none of them well.

The two goals that actually matter in the first year are increasing self-reliance of the user community and reducing inconsistency across solutions. Everything else follows from those two.

Self-reliance matters because it is the only way the COE survives. If every question funnels back to the same three people, those three people will burn out or leave, and the COE will collapse. The first measure of success is not how many tickets the COE solved, it is how many tickets the user community solved without escalation.

Consistency matters because Fabric gives users enormous flexibility, and that flexibility is dangerous without guardrails. We have audited environments where the same business KPI was calculated in seven different ways across seven different reports, and every executive was looking at a different number. That mess does not happen because people are careless. It happens because nobody told them what the right pattern was, or because the right pattern was buried in a Confluence page nobody reads.

The other goals on the Microsoft list - evangelising data culture, coordinating across boundaries, finding the right balance between self-service freedom and risk - all flow from these two. Get self-reliance and consistency right and the others tend to fall into place.

Scope - the thing organisations get wrong

The Microsoft roadmap describes the COE as "a consultancy service" that also does hands-on work. The reality of how organisations interpret this varies wildly, and getting the scope wrong is the most common reason a COE fails.

Three failure patterns we see often:

The COE is "consultancy only" and does no hands-on work. Members provide advice, write standards documents, and answer Teams messages. They never actually build anything. After a year, they have lost touch with what Fabric is actually capable of, the standards they write are too theoretical, and the business teams stop asking for advice because the advice does not survive contact with reality.

The COE is "hands-on only" and does no enablement. Members build everything that needs to be built. They become a bottleneck. The user community never grows. The COE turns into a delivery team with a fancy name.

The COE owns "everything Fabric." Members are expected to do strategy, governance, support, training, build, oversight, and tenant administration. They are spread across so much surface area that none of it gets done well. The team gets exhausted within a year and starts shedding people.

The pattern that actually works is what we call a 70-30 split. Seventy percent of the team's time is on enablement activities - mentoring, training, office hours, best practice reviews, documentation. Thirty percent is on hands-on building, but specifically on the kind of projects that demonstrate or create reusable patterns. The COE should not build the sales team's monthly forecast report. The COE should build the template that the sales team adapts into their forecast report, and then help them through the adaptation.

This is roughly the model we use ourselves when we work with clients on Microsoft Fabric consulting engagements. The deliverable is rarely just the solution, it is the solution plus the pattern plus the people who can build the next one.

Staffing - the realistic version

The Microsoft documentation lists six COE roles - leader, coach, trainer, data analyst, data modeller, report creator, and data engineer. Most Australian organisations cannot realistically staff seven distinct people for a COE in year one, especially mid-sized companies.

What actually happens, in our experience, is closer to this. A typical mid-sized Australian organisation (500 to 2000 staff) starts a COE with two or three people, all of whom wear multiple hats.

The COE leader has to be senior enough to walk into an executive meeting and disagree with a director. If they cannot do that, the COE has no teeth. We have seen well-intentioned COEs led by mid-level analysts who simply did not have the authority to push back when a senior leader wanted something built badly, and the standards got eroded one exception at a time.

The coach role is the most important practical role. This is the person who runs office hours, reviews other people's work, and writes the documentation. They are the connection between the COE and the rest of the business. Pick this person carefully. They need to be technically credible and also patient enough to explain the same thing five different ways to five different audiences.

The trainer role can often be shared with the coach in a small COE, but it works better as a dedicated function if you can afford it. Training material has a long tail of usefulness - good training videos and worksheets keep paying off for years. Bad ones actively cause damage.

The data engineer role is genuinely difficult to hire for in Australia right now. Fabric data engineering skills (Spark, Delta, Direct Lake, deployment pipelines) are scarce, and the people who have them are well-paid contractors. We are honest with clients - if you cannot hire one, partnering with an external firm for the first year while you grow one internally is a sensible pattern. We do that work on plenty of engagements.

The data analyst, data modeller, and report creator roles can often be drawn from the satellite community. The Microsoft roadmap talks about a "champions network", which is essentially the COE's extended family - senior users in each business unit who have been trained up to be the local expert. A good champions network is worth more than two extra hires inside the COE.

What good COE members look like

The Microsoft list of attributes - understanding the vision, deep tool expertise, willingness to share, interest in repeatable processes, comfort with agile, good communicator - is correct and a bit generic.

Two attributes we look for specifically when we help clients hire or recruit internally into a COE.

The first is curiosity about how other teams work. A COE member who only understands one part of the business will only build solutions that work for that part of the business. The best COE coaches we have worked with come out of consulting backgrounds or have rotated through multiple departments, because they instinctively ask the operational questions before the technical ones.

The second is what we call productive disagreement. COE members will spend a lot of their time saying "I would not build it that way" to people who outrank them, often with limited time to make the argument. Someone who folds under that pressure will produce a COE that ratifies bad decisions. Someone who is too combative will produce a COE that nobody listens to. The middle is where the value is.

This is part of the reason we sometimes get hired to act as the COE coach for the first six months while a client recruits an internal one - the external position makes productive disagreement easier, because the consultant does not have to manage internal political relationships forever.

The thing that ties it together

If you take only one thing from the Microsoft roadmap chapter on Centres of Excellence, take this. The COE is most powerful as a learning function for the organisation, not a delivery function. Its highest value is in what it learns from working with business teams and what it can broadcast back across the organisation. That bottom-up flow of knowledge from real usage to organisational standards is what separates a working COE from an expensive help desk.

If you are setting up a Fabric COE, or your existing one is not delivering the value you expected, we have helped a number of Australian organisations through this and would be happy to have a chat. The contact page is the place to start, or if you are after a wider conversation about getting more out of your data and AI investments, the Business AI strategy page covers the broader frame.

Original Microsoft reference: Microsoft Fabric adoption roadmap - Centre of Excellence