Where does a KPI live?¶
A recurring architecture question is why two reports can answer the same business question differently. Often the reports are also doing the work of choosing grain, repairing source structures and interpreting process events.
The tempting answer is to define every KPI once inside a reporting tool. That helps a single tool, but other consumers still need the same reasoning. A second temptation is to precompute every KPI in a single wide table; definitions then become difficult to change and reuse.
My current view is to preserve stable, well-grained process facts and conformed meanings upstream, then compose shared measures through a governed semantic capability. Reports can focus on presentation and local exploration. Where a metric is genuinely specific to one use, it need not become an enterprise definition.
The hard questions remain: which facts belong together, who owns a cross-domain measure, and when does a useful shortcut become a permanent semantic dependency?
Join the argument
Agree, challenge or add evidence
Architecture improves when its assumptions are challenged. Say which kind of contribution you're making:
- Challenge I disagree because…
- Evidence We've seen this too…
- Question How would this work when…?
- Alternative Another way to approach this…
- Extension This also implies…
Please keep clients, employers and colleagues unidentifiable. Strong contributions may be quoted and credited on this site. Read the contribution guidelines and the privacy notice.
Comments are provided by giscus and stored on GitHub. Posting requires a GitHub account.