Topic

Data and Analytics

Data engineering and analytics practice, built around the rule that decides whether any of it is usable: one authoritative number per concept, with its lineage.

How we approach Data and Analytics

One authoritative number per concept

Most reporting problems are definition problems. Revenue means four things across three systems, each defensible, and the argument in the meeting is not about the data but about which definition was used. Publishing one owned definition per concept, with the query behind it, ends more disputes than any dashboard redesign. It is governance, and it is the cheapest governance available.

Quality gates belong in the pipeline, not the dashboard

A quality problem found by a reader has already cost you the credibility of the whole surface. Checks on freshness, row counts, referential integrity and distribution belong where the data is produced, and they should stop publication rather than raise a ticket. A number that is wrong and visible is worse than a number that is late and flagged.

Lineage is what makes a number arguable

When somebody challenges a figure, the useful answer is the path from source to output, not reassurance. Without lineage every challenge escalates to a person, and the analytics team becomes a helpdesk for its own credibility. With it, disagreement moves to where it belongs, which is the definition and the source, and can be settled once.

Every page above is written to be used rather than skimmed, and each links back here and across to the others. Nothing on this page exists only to hold a keyword.

Other topics: Artificial Intelligence, Cloud, Cybersecurity, Enterprise Infrastructure, Oracle.