Blogger: Lyn Robison
Some assets are fungible, and some are not. Fungible means that the asset can be freely exchanged or replaced with another of like nature or kind. Oil is fungible. One barrel of oil is considered identical to, and can therefore be replaced by, another. Other assets, such as grain, lumber, and ¼” sheet metal screws are fungible assets. There is no need to keep track of instances of these assets, just their quantity.
American dollar bills are fungible. One paper dollar is just as good as another. Dollar bills do have serial numbers, so you can go to Where’s George and see where a particular dollar bill has been. And the Treasury Department probably uses the serial numbers somehow. But in the business world (even though it seems like a dollar isn’t worth a half-a-buck) one dollar bill is just as good as another.
Used cars, OTOH, are not fungible. One 1987 Ford Taurus is not just as good as another. Automobiles have vehicle identification numbers, because it is important to identify each individual vehicle, because they all have different options, different histories, etc. Therefore, used cars are non-fungible assets.
When we, as IT professionals, build a database to hold important business assets – such as, say, a customer database, it is tempting to think of that data as fungible. It is tempting to think of filling up that database with data the way that we might think of filling up a barrel with oil. Sure, inside the boundaries of that system, we realize that we need to give each customer record a primary key, but it is tempting to use some auto-increment field to automatically generate that pk for each customer record, and then fill ‘er up!
The problem is that customers are not fungible: one customer is not just as good as another. It is vital, therefore, to identify each customer, and to do so beyond the boundaries of any individual IT system. This is in essence the data silo problem: the inability to identify non-fungible assets across data silos.
I know of a large non-profit organization (a church, actually) that owns thousands of buildings all around the world. I say “thousands” because they don’t know how many buildings they actually own. Multiple IT systems contain information about buildings: construction systems, maintenance systems, financial systems. Each of these systems uses its own pk to identify each building, and there is no way to reconcile these individual, non-fungible assets across the data silos. How do they manage these buildings if they don’t even know how many they own? The answer is, not as well as they ought to.
This is the problem that Burton Group’s MODS (the Methodology for Overcoming Data Silos) is designed to address. It gives you a methodology for identifying non-fungible assets across data silos.
Think this isn’t a big deal? Think about a large enterprise that could finally identify all of the vendors/suppliers from which the enterprise buys good and services. They could begin consolidating purchases with each supplier to get better prices and payment terms and save hundreds of thousands, if not millions of dollars. And this is just a small example of the value of tracking non-fungible assets across silos. Every dollar spent on CRM systems is a dollar spent (and often squandered) trying to solve the data silo problem.
Now think of the ability to reconcile non-fungible assets across data silos with regard to structured and non-structured data. If you could identify non-fungible assets beyond individual system boundaries, you could combine data about that asset from every system in the enterprise, including structured as well as non-structured data. This is another concept behind MODS.
We have published some guidance on MODS here. We will talk more about it at Catalyst. And you can look forward to additional guidance on MODS in the near future.
