I've attended the last three IDEAS conferences and, without question, have a learned a great deal at each one. For instance, I learned that no one on earth has a thicker wallet than David Loshin. No one. I've learned that Tony Fisher has a great sense of humor and that Jill Dyché knows how to give a speech.
But, if pressed, I'd say that my all-time favorite moment took place at IDEAS 2010 when panel-mate Jim Harris talked about Amazon's different systems. Specifically, Harris spoke of the Seattle-based behemoth's transactional and analytical applications, each of which served a distinct and essential purpose. At a high level, the company's remarkable effective use of technology and data collectively represent a big reason that it's doing so well. Just look at its stock price.
Think about it. Many organizations struggle to just get their transactional data right. I know because I spent years consulting at these types of organizations. You'd think that by 2012 all large enterprises can keep their product, employee, customer and vendor data clean.
And I'd argue that you'd be wrong more often than not.
Now, let's consider the next level: analytical systems. At many companies, Microsoft Excel still represents the killer app for analysis – this despite Excel's limitations. Far too many enterprises have never implemented formal data warehouses, BI applications, data marts and the like. Some if not most of those organizations struggle to keep the data accurate, maintain master records and synchronize that data throughout the enterprise.
But how many do both (read: what Amazon does)?
Not many, according to my incredibly unscientific Venn Diagram:
I thought a few times of Jim's comments on that panel when I was writing The Age of the Platform. It's evident to me that all organizations need to do what Amazon does: manage not only individual transactional data (sales, returns, orders, etc.), but the aggregation of that data in ways that enable employees to make optimal decisions.
Toss around terms like Data all you like. If you're not getting your little data right, your organization faces serious risk.
What say you?
While master data is typically less volatile than transactional data, entities with attributes that do not change at all typically do not require a master-data solution. For example, rare coins would seem to meet many of the criteria for a master-data treatment. A rare-coin collector would likely have many rare coins. So, cardinality is high. They are valuable. They are also complex. For example, rare coins have a history and description. There are attributes, such as condition of obverse, reverse, legend, inscription, rim, and field. There are other attributes, such as designer initials, edge design, layers, and portrait.