Data isn't complicated. We made it that way.

Every fabricated layer of complexity in a BI environment is a single point of failure with a person’s name on it. We have learned to call that “seniority.” If you ask me, it is closer to a risk we manufactured upstream and then re-labelled as expertise downstream, and “you need an engineer for this” is the sentence we use in the room so we do not have to look at it.

I’ll plant a flag on this. Most of what gets called “the complexity of data” in a Power BI engagement is not the data. It is a choice someone made on a Tuesday afternoon that nobody felt safe revisiting. The dirty secret of our profession is that the work to fix it is usually one or two unsexy decisions, not a more senior hire.

The load-bearing shortcut

A wide flat table, sixty columns, no relationships, built once for convenience. By the time I am called in, five dashboards and a leadership routine sit on top of it, and the original author is two jobs away. Touching that table now means touching everything that depends on it, which is everything that runs in the morning, which is nothing anyone wants to be responsible for breaking. So nobody does. So it stays.

Microsoft’s own guidance for Power BI is unambiguous on this. Star schema is the recommended model, and reproducing the source schema in the semantic layer is named, in their documentation, as an anti-pattern. SQLBI has been writing the same answer for years: a proper star schema is the single biggest lever for both performance and accuracy of results. Neither of those is a secret, and both predate every version of Power BI in active use today. The complexity people now call “the data” is the missing star schema, still load-bearing, still feared, and the next consultant gets called “senior” for keeping the lights on instead of fixing it.

The undecided word

“Revenue” computed three different ways across three reports. The complexity is not the SQL. The complexity is that nobody decided what the word meant, and three report writers each made a defensible choice. Then every leadership meeting starts with thirty minutes of “which number is right?”, and the answer is always “all of them, depending on how you define it.”

That is not a data problem. That is an alignment problem we re-labelled as a data problem so we did not have to host the conversation. The same shape shows up everywhere: “active customer”, “open ticket”, “qualified lead”, “new client”. Each one is a definition somebody postponed, and the postponement is what shows up downstream as inconsistency. The reports are accurate to their own definitions. The organisation is the thing that disagrees with itself, and we routinely choose the year-long ambiguity over the half-hour decision.

The hedging dashboard

Fourteen KPIs, three filter panels, six pages, built because the brief was never specified and the analyst hedged by including everything. The complexity is in the question, not the data. This one is the most invisible, because it does not break. It does not produce the wrong number, it does not crash. It simply does not get opened, and the dashboard becomes part of a ritual instead of a decision. The cost is borne by every analyst hour spent maintaining a thing nobody depends on, and by every meeting where the report exists and is therefore “covered”, and no actual decision is hosted.

Real complexity exists

Fred Brooks called this essential versus accidental complexity, back in 1986, and the distinction still holds. Regulatory data is essential. Multi-currency consolidation is essential. Large-scale time-series and healthcare claims are essential, and the people who can hold those in their head are worth every euro. The day-rate is a fair trade for what they actually carry.

The argument is not against expertise. The argument is against the reflex that treats accidental complexity, the kind we added, as if it were essential, and then bills the maintenance of it at the same rate. That is the slip the industry has been making, and it has been making it long enough that “the data is hard” has become a sentence we say with a straight face about systems we built ourselves last summer.

The price of calling it seniority

Calling fabricated complexity “expertise” has a price. It locks knowledge in one head, turns every hand-over into a six-month re-learning project, justifies dashboards nobody uses, and teaches the next generation of data professionals that being indispensable means being the only one who can read your own work. It deflates the day-rate of every honest practitioner who fixes problems instead of curating them.

None of the fixes are sexy. All of them are repeatable. Decide the schema. Decide the word. Decide the question. None of those need a more senior hire. They need somebody in the room with the authority and the patience to host one uncomfortable conversation, and the willingness to put the answer in writing afterwards.

If you are the data professional, you have more authority over this than you think. You can refuse to build on top of the wide flat table without naming the trade-off, refuse to ship the dashboard before the brief lands, refuse to compute “revenue” three different ways without flagging that the word is undecided. The reflex sentence “you need an engineer for this” is the sentence we collectively use to skip those refusals. You do not have to skip them.

Happy to think this through with you.