Yet again, I am faced with a never ending stream of questions about why standards are important. It seems, people are now asking me to prove why they should stick to the standards, rather than getting up off their own rear-ends and doing their own testing to prove why the standards need to be changed. Well, let’s explore this shall we?
First, some questions:
- Would you trust a brain surgeon who had no formal education in the medical profession?
- Would you trust a heart surgeon who said: I don’t operate on patients the way the standards dictate, I do my own thing, I actually remove the heart from the patient in order to operate on it outside the human body, just because I think it’s easier to get at.
- Would you trust a car mechanic on your new Ferrari who was only qualified to work on lawn mowers? Someone who said: I can adapt and change the standards, all engines are basically the same…
- What if your local physician (general practitioner) prescribed hallucinogenics to you because they felt that the “standard drugs” approved by the medical community and taught in school were not appropriate?
My point is this:
I’ve spent 10 years in R&D (between 1990 and 2000) testing, checking, fixing, adapting, modifying and proving the model, the methodology, the architecture, and the entire process of Data Vault. Developing the standards so that IF you follow them, you can avoid the pit-falls, the holes in the road, and all the problems and issues that come with building an Enterprise class data warehouse.
I’ve spent the last 16 years (2000-2016) designing, and proving (over and over again) at many many customer sites that what I teach, as well as implement, works. Again: IF you follow the standards.
I’ve seen solutions where standards have been broken, and customers complain – inevitably because the “patch” the “fix” the “change away from the standards” have fallen apart, force re-engineering, force the customer to say: the “Data Vault” is broken, when in fact, it’s their deviation from the standards that caused the issue to begin with.
I’ve said it before, I’ll say it again:
IF YOU AREN’T FOLLOWING THE STANDARDS OF THE DATA VAULT, THEN PLEASE DON’T CALL IT A DATA VAULT AND — RUN THE RISK OF RE-ENGINEERING DOWN THE ROAD!!!
Where does that leave us?
The “owness” or responsibility, of adapting the standards, making changes does rest on all of us. We should challenge standards in order to discover other holes, and move them forward. Of course it’s where innovation happens. But I say again: the responsibility to prove that the changes to the standards work (in unconditional format – across a multitude of problem spaces) lies with the individual suggesting that the standards be changed.
It is not “bullocks”, or hogwash to propose a change, it is hogwash to assume that the change (without proper testing and vetting) is to be “automatically acceptable” across the board by all customers and all clients. This is where the rubber hits the road. This is where lazy and irresponsible developers either grow up and become valuable contributors to the innovation stream, or they disappear – never to be heard from again.
But to think: “just because person X says it’s good – so therefore it should change the standard in Data Vault” is not the right approach. Not now, not today, not tomorrow, not ever.
If we could accept blanket statements without backing / testing, then we wouldn’t need “development”, “test”, and “production” environments in our daily work-place. We would simply do everything in production all the time.So once again, I implore you (everyone in the community) – do NOT simply follow like lemmings, those who claim that the “standard should change by consensus” – without proper testing, vetting and proof that the changes actually work. I am suggesting, an impact study be done.
Don’t just take my word for it, read something about why standards are important to different facets of live. In my next blog (and hopefully my last one on Standards) I will address “how to change standards, how to innovate” going forward.
Standards are published documents that establish specifications and procedures designed to ensure the reliability of the materials, products, methods, and/or services people use every day. Standards address a range of issues, including but not limited to various protocols that help ensure product functionality and compatibility, facilitate interoperability and support consumer safety and public health.
Why Are They Important?
Standards form the fundamental building blocks for product development by establishing consistent protocols that can be universally understood and adopted. This helps fuel compatibility and interoperability and simplifies product development, and speeds time-to-market. Standards also make it easier to understand and compare competing products. As standards are globally adopted and applied in many markets, they also fuel international trade.
It is only through the use of standards that the requirements of interconnectivity and interoperability can be assured. It is only through the application of standards that the credibility of new products and new markets can be verified. In summary standards fuel the development and implementation of technologies that influence and transform the way we live, work and communicate.
Standards provide people and organizations with a basis for mutual understanding, and are used as tools to facilitate communication, measurement, commerce and manufacturing.
Standards are everywhere and play an important role in the economy, by:
- facilitating business interactio
- enabling companies to comply with relevant laws and regulations
- speeding up the introduction of innovative products to market
- providing interoperability between new and existing products, services and processes.
Standards have been in existence for many years. At one time they were thought of as being the lowest common denominator, restrictive, and of little importance. That has changed. Today, standards are recognized as beingessential to helping companies be innovative, reduce costs, improve quality and maintain competitiveness in an international marketplace.
Thank-you kindly for your understanding,
(C) Copyright 2016-2017, Dan Linstedt, all rights reserved.