In data and analytics the course is rarely set by the big bets. It is set by the quiet accumulation of small choices: the partition picked today, the metric someone decides to measure, how a field gets modelled, how a source gets integrated. Those choices feel automatic at the time, and I have watched them either accelerate a project or complicate it for years. This is where I write about them.
I work on data architecture: how information gets modelled, moved, and made trustworthy enough that people will act on it. Most of the work that matters happens before anything is built — agreeing what a metric actually means, deciding where a boundary belongs, and telling apart the complexity a system genuinely needs from the kind it has merely inherited.
"Done is better than perfect!"
I came to this by building. Shipping applications end to end teaches you what happens downstream when a schema is convenient rather than correct, and that is the perspective I bring to architecture now: designs that survive contact with the people who have to implement them and query them later. I still keep my toolset deliberately compact — fewer technologies understood properly beats a longer list.
Semantic layers are usually sold as a place to put metric definitions. Write revenue once, expose it everywhere, stop arguing in meetings. Then two teams report different revenue anyway, both technically correct, and the …
The question arrives as a technology question. Should this integration be batch or streaming? And it gets answered like one, by comparing engines, latencies and throughput numbers. That framing is the problem. Latency is …
To read more here.
