WHEN IS THE DATA MODEL FINISHED?
WHEN IS THE DATA MODEL FINISHED?
By W H Inmon
Mature IT organizations know they need a data model. How else can the organization keep track of many types of data that enter the organization daily? How else can the organization start to resolve the many differences in the data that inevitably appear? How else can the organization point the data analyst to the many sources of data that are to be found?
So there is no doubt that the mature organization that wants to control its data needs a data model.
And there are lots of places to get a data model – from Len Silverston’s books on generic data models, from the vendor, or the organization can choose to build its own.
Or the organization can use all three sources and create a hybrid data model.
All of these choices are perfectly acceptable.
So, an organization builds or acquires its own data model. And it is simple as that, or is it really that simple?
Consider this.
The data model is a reflection of the business of the organization. The data model is where business meets technology.
And business and the world is constantly changing. Legislation is constantly changing. Economic conditions are constantly changing. Competition is constantly changing. New technologies are constantly appearing, and so forth. In a word, the world just doesn’t sit still. It never has and it never will.
Recommended by LinkedIn
And because the world is constantly changing the data model also needs to constantly change. This means that the data model is NEVER finished. Or stated differently, the data model is finished when the business is finished.
This sounds like really bad news. But is not.
Once the organization achieves its basic data model form, the data model achieves a state of stability. And most of the changes that need to be done to the data model are incremental and marginal.
While most businesses change all the time, they do not change radically. Most businesses just do not undergo radical changes.
Let’s take General Motors as an example. GM makes automobiles and carriages for transportation. It would be ludicrous for GM to suddenly one day decide it was going to produce cheese and milk products. Cheese and milk products and automobiles are radically different.
Instead, GM decides to produce an EV in addition to gasoline powered cars. While there are certainly differences between an EV and a gasoline powered car, there are nevertheless a great deal of similarities.
So the fact that the data model is never complete is not bad news in any way
Bill Inmon lives in Denver with his wife and his two Scotty dogs – Jeb and Lena. It is the first nice warm day of the spring and Jeb and Lena just can’t get enough out of going outside and playing in the yard. Neither can Bill and his wife and the whole neighborhood.
Data Engineer
8moData model is finished when the company shuts down :) as long as business continued the data warehouse is never done
Chief Data Officer @ Xendat Data & Analytics; Executive Consultant Data & Knowledge Management @ Vertex Pharmaceuticals, Inventor, Speaker, Data Evangelist, Entrepreneur
9moAmen! Data models are living representations of business realities, and physical models are just snapshots of those models in time. To stay useful and relevant, physical models must be governed to keep up with them.
Transforming your workforce by developing collaborative leadership increasing performance 'n engagement | 5X LinkedIn Top Voice - Facilitation, Team Facilitation, Team Management, Team Leadership, Team Building
9moNever - should be evolving constantly.
Knowledge • Architecture • Engineering • Cybernetics
9moIndeed. The design of models that intentionally support evolution seems to be a lost art. Seems ironic that the most brittle outcomes tend to be born from contemporary agile practices; not because these practices are inherently wrong -- but that implementers often consider the future to be an unknown and that hardwiring for here-and-now is considered good enough, with the incurred debt to be paid later. I have been told point-blank more than once that architecture and design are anti-agile. My counterpoint is that poor design or its absence altogether is the real enemy. Models designed for efficient change are the ones that remain evergreen.
Area VP Central Europe @ Agile Data Engine - Passionate about data
9moGreat article and reminder. While this should be self-explanatory, people often expect things to be "done". Frustration sets in when they realize that this is not the case. And that's where the issue is - complacency. It's almost like saying to yourself that you are done with learning once you get your uni degree.