Do You Really Have Data Management Principles?
Looking back on the work we’ve done over the past few years I’ve come across an interesting point: while companies may have mature data management organizations (DMOs), few of these DMOs have a set of principles behind their data management visions. In other words, they’re building data management infrastructures and tools without a clear sense of what they’re ultimately trying to accomplish.
Important Endeavors Should Have Guiding Principles
I’ve recently been listening to an audio book about the American Revolution and it’s led me to an interesting conclusion: Great undertakings have a set of guiding principles. Take the United States, for example, we have a constitution. Our constitution underlies all of our other laws. We’re, of course, not alone. Consider, for example, the Magna Carta and, even, the Ten Commandments.
Data is valuable and building and maintaining an effective data management infrastructure is an important endeavor, at least for you, your company, and the parties relying on you. (To get a better handle on how valuable your data is and what it might be worth see Doug Laney’s work on Infonomics). Thus, as an important endeavor, your data management efforts should have a set of guiding principles.
Once you’ve established guiding principles, you can compare every data management decision to them to ensure that those decisions fit with your overall, long term data strategy. This will help keep your organization from straying toward costly, short-sighted distractions.
What Principles Should You Have?
Some data principles are universal, and apply to all organizations. Others may vary organization by organization. I believe that most organizations should have between 5 and 15 of these principles. Further, I believe they all flow from a ‘master principle’:
Data is a valuable asset and it must be accorded the same care as other valuable, corporate assets
Here are some additional principles I believe apply to most organizations:
- Data Should be Shared: Data captured anywhere in the organization should be available to all who can use it to derive business value. Without sharing, you’ll expend extra effort and your business will miss opportunities to capitalize on the data it’s paying to capture.
- Operational Data Should Not be Duplicated: Data should be captured only once and that version of the data should be available to the people and systems that need it. Duplication provides opportunities for error, user confusion, and technical complexity.
- Data Should be Accessible: Business users and systems should be able to easily get the data they need. The organization can miss out on opportunities and ‘signals’ if it captures data but does not make it available to people and systems that can capitalize on it.
- Data Quality Should be Fit for Purpose and Substantially Reflect Reality: This means that data should be correct enough for its intended uses in operations, decision making and planning. Decisions and actions that users make based on bad data are, of course, potentially flawed. This does not mean that data is perfectly clean, only that it is at least clean enough for your business purposes. For example, do correct middle initials warrant the same level of effort and investment as correct addresses?
- Data Should be Compliant With Applicable Laws and Regulations: This rule, and the reasoning behind it, should be fairly self-explanatory.
- Data Should be Protected From Unauthorized Access: In a time of hackers and spies, this, too, should be self-explanatory. Recent, high-profile security failures (check here and here) have cost millions (billions?) of dollars and led to a loss of customer confidence. Can your organization afford this?
- Data Should be Protected From Inadvertent Destruction: Systems fail. If your data suddenly disappears, can you get it back quickly, with minimal impact to the business?
- Data Should be described by a Common Vocabulary and Definition: To avoid miscommunication and ensure that all data consumers properly interpret the data they receive, the organization should provide tools that both novice and expert data users can use to understand what data is captured by the company, what it means, and other key details about it.
Using the Principles
It’s relatively simple to apply these principles to your systems efforts. Whenever you’re planning new development or major modifications, compare the plan to your list of principles. For example, if you’re implementing a new warranty system, ask, “Will it have its own set of customer addresses or will it share addresses with all of our other, operational systems?” (i.e. Is it shared? Is it not duplicating existing data?) Further, ask, “Are we planning mechanisms for the business to analyze the data?” (i.e. is it accessible?) etc.
If your plans violate any of your core principles, change your plans!
How to Develop Your Own List of Guiding Principles
In my mind, the DMO simply implements the will and desires of the user community. So, when it comes to data management guiding principles, developing the list shouldn’t be just an IT task. Success demands input from your constituents. In fact, your data governance team should develop, and periodically review, the list. The business ultimately owns the data so shouldn’t they also own the rules governing that data?
Perhaps you start with the list provided here. Then, think through your organization and its data situation. Have issues arisen in the past for which a solid principle would have provided needed guidance? If so, consider developing a principle to avert the situation in the future.
Remember, these are high-level, guiding principles. They don’t refer to individual systems or efforts. They should, instead, guide all systems and efforts in the long term.
Do I have a point or have I gotten this terribly wrong? I’d love to hear your thoughts! Just add a comment to the blog. Thanks!
Does Your Organization Need SAS Consultants?
Over the past year a few of our clients have asked us to provide them with SAS experts and the results have been great! We’ve been placing consultants in areas including SAS Enterprise Guide (E.G.), Base SAS, SAS Administration, and SAS/Access to Hadoop. We can usually have highly-vetted SAS experts at your site within three weeks. If anyone in your organization is looking for SAS help, please have them contact me directly at 734.585.3503. Thanks!