Joe Reis came back from Big Data London with a familiar complaint. The industry is selling context layers and context graphs, while data teams are still struggling with unclear definitions and ownership. The tools have improved. The organizational work remains.
That is a useful warning for anyone evaluating the next platform. A better system can make data easier to use, but the people responsible for the business still have to decide what it means in a particular decision. Those choices need to be part of the project, with someone authorized to make them.
Which definition applies here?
Reis uses the example of a customer. Sales, Finance and Support can each have a legitimate definition because they deal with different parts of the relationship. The trouble starts when a decision crosses those boundaries and nobody has established which definition applies.
Trying to settle that by choosing one universal definition can create another problem. A signed account and a customer generating recognized revenue are different things. The business may need both. What it needs to agree on is how they relate, when each should be used, and who can resolve a disagreement about the result.
This is where ownership has to reach the process that produces the data. The person administering the platform may be able to change a calculation without having the authority to decide what counts as revenue. Naming that person as the data owner does not give them the missing business authority. It leaves them responsible for implementing a decision they cannot make.
For example, suppose a report is being used to decide where to assign account managers. Before choosing a customer count, someone needs to establish which relationships the team is expected to serve. A count designed for that purpose might reasonably differ from the one Finance uses. The useful agreement explains the difference so the next analyst does not have to reconstruct it from two conflicting dashboards.
What the purchase needs to include
There can still be a good reason to replace or consolidate tools. In his argument for a more integrated data stack, David Jayatillake points to the cost of accumulating BI products without retiring the old ones. He also describes the appeal of managing metrics within the platform. That case deserves consideration on its own terms; an unresolved definition does not make software consolidation pointless.
But consolidation needs a decision about what will carry over. If two dashboards calculate the same metric differently, moving them both into one product preserves the disagreement. Standardizing the calculation without involving the people who use it risks choosing a meaning that does not fit their work.
Take one of those disputed metrics into the platform evaluation. Describe the business decision it supports, involve the people responsible for the underlying process, and establish who has the authority to settle its use. Then test whether the proposed platform can express that agreement and make it understandable to the next person using the data.
The agreement will also need attention after launch. A change in how the business sells or serves customers can change what a metric should include. Someone needs to recognize that change and take responsibility for its effect on the people using the report. That responsibility should be explicit before the project team moves on.
If nobody can authorize the definition, the sponsor has a decision to make before the team standardizes it. Otherwise the implementation team will make the choice indirectly, through whichever calculation it happens to carry forward.
Sources
- This Year's Better Mousetrap: New Tech, Same Old Problems, and The Semantic Swamp, Joe Reis (Data Engineering)
- The Final Data Stack, David Jayatillake