Alexander Arvidsson

I’m heading to Barcelona for FabCon Europe, and this year I’m attending without a session of my own. That changes the rhythm of the trip. More time to follow conversations with product teams, listen to other speakers, and work out which Fabric developments actually deserve attention. I’ll be gathering material for Knee-Deep in Tech Topics and exploring what the announcements really mean for practitioners. Also: finally visiting Barcelona, which is a substantial bonus. If you’re there, come say hello.

Democracy asks us to form opinions we can explain and take responsibility for our choices. That requires doing the uncomfortable work of thinking things through. But we’re increasingly outsourcing that work to AI, and I’m concerned about the cognitive debt building up. When a chatbot tailors an explanation to your uncertainty, the opportunity to influence sits inside the answer you came looking for. No conspiracy required. Just habits we’re not examining closely enough, at precisely the wrong time.

Most organizations have a risk acceptance process on paper. What they actually have is hallway conversations and comment threads that vanish when projects close. When something breaks, everyone reconstructs who knew what from memory, under pressure, with lawyers involved. Aviation solved this problem decades ago with the MEL. The framework forces explicit conditions, named owners, and real expiry dates. Security work has similar machinery. We just let it collect dust while risks drift between teams unowned.

Back in 2015, I was debugging a SQL Server cluster that worked perfectly. Except when it didn’t. Connections timed out randomly, failovers failed silently, and nothing made sense. I was sure it was DNS. It was DNS. But that wasn’t the real problem. The real problem was me, seeing exactly what I expected to see instead of what was actually there. Turns out, pilots and DBAs have something important in common: expectation bias can really mess you up.

You did the hard work. Found the buried metric, rebuilt the report, put the lever in the top-left tile. The meeting went beautifully. Everyone nodded. Then nothing changed. Here’s what I keep relearning: a lever is not a mechanism. It’s a person with a calendar, a bonus structure, and reasons to leave things exactly as they are. Most reports die in the gap between who requested them and who has to work differently on Monday.

Every student pilot learns this the hard way: staring at the altimeter won’t fix your altitude. It’s a readout, not a control. Your dashboards have the same problem. Most of the metrics sitting at top left are gauges, things people can only watch. The actual levers, the numbers someone could move on Monday morning, are buried three clicks deep rendered in grey font. Three questions tell you which is which. The answer is usually uncomfortable.

Software versioning is solved. Ontology versioning isn’t. When you change what counts as an ‘active customer,’ that’s not a schema migration with a clear notion of correctness. It’s a contested definition where reasonable people can land in different places. Fabric IQ gives you the artifact, but it doesn’t ship the governance workflow. That part you build yourself. This post digs into what running layered ontologies actually takes, and why the organizational problem matters more than the technical one.

A sharp LinkedIn critique argues declared ontologies are broken by design. Model your business formally, and by the time you’re done, it’s already changed underneath you. The proposed fix: let structure emerge from data instead of declaring it upfront. It’s a compelling pitch, but I think it misdiagnoses the problem. Ontology drift isn’t evidence that formalization failed. It’s evidence we failed to separate what should be stable from what shouldn’t. The real answer might be simpler than either camp admits.