Two weeks ago, I wrote a somewhat ambiguous post. It hinted at how data can be accessible when a dedicated group divides and conquers the problem. It also suggested that it's not all that simple.
Both are infested with ambiguity.
This post puts ambiguity forward again, but in a different way.
The most challenging problem in software is understanding what the customer needs. At least two things are necessary to get it right. The first is a proper understanding of what the customer says. The second is translating what the customers think they need into what makes their lives easier.
Say a customer wants "sales by month." What could be more straightforward and more transparent? Where is the ambiguity in that? Well, it depends on who said it and in what context.
Salespeople need the value of signed contracts because that's what their commission is based on.
Operations people need the invoiced amount because it says how much work was delivered. Finance people need the invoiced amount, including taxes, because it says how much money should be collected. Or, the salespeople may need the invoiced amount, including taxes, because they must report it to the finance people.
Not that bad so far. But wait, it can get much more complicated very quickly. Do the sales include returns? Voids? How about discounts, if you don't mind me asking? All discounts or only a sure thing? The exclusive deals, or just a portion? Always the same amount? Taxes? (Please, don't get me started on taxes.) At least the “month" portion is accessible. Or is it? Is this a regular calendar or a manufacturing calendar? Fiscal numbering? Are we taking the time zone of the contract into effect? Which timezone?
Is it always the same timezone, or does it depend on the wording? Signing date, submission date, activation date, posting date, or approval date?
What makes "doing data" seem deceptively simple is the human ability to deal with ambiguity in language very effectively. Like-minded people use very few words (often ambiguous) to communicate clearly and efficiently. They share a non-trivial everyday context in which the words can be understood.
However, even for like-minded people, the common understanding breaks down regarding data and the level of precision required. People would often assume that they understand what the other person is saying. But more often than not, "revenue by month" means different things, even to long-time co-workers.
At Infostrux, we solve ambiguity by breaking the language into many small, simple details so that even a machine can get it.
It takes work.
