In a perfect world, people who develop systems and software for companies would define data elements in a standard and consistent manner, particularly key primary elements such as "Customer Number" and "Product Number," and calculated items like "Net Pay," and "Gross Sales." Unfortunately, this is not always the case. For example, I had a systems manager in a western state government agency tell me he conservatively estimated that "Employee Number" was defined over 150 different ways in his agency alone. Standardization of Data Definitions (DD) provides the means to reuse such items over and over again thereby saving time during development and providing the means to integrate systems and software. Without DD uniformity though data redundancy and erroneous calculations are not only possible it is highly likely thereby causing maintenance headaches as well as incurring skepticism in the integrity of the resulting information (aka, "dirty" information), thereby triggering additional rework of programs and business processes. Reusability simplifies maintenance and enhancements, expedites development efforts and promotes the concept of a true data base environment to integrate all of a company's systems and software. The benefits far outweigh the negatives which is nothing more than to simply take the time to properly document a data element. When it is done though, it is done and can be reused by everyone, not just one person.
There is an abundance of tools and techniques to assist in data definition. In fact, such devices have been around since the early 1970's, most notably data dictionaries and data taxonomies. Yet, such tools have fallen into neglect by most programmers who tend to view them as impediments to getting the job done. Data Base Management Systems (DBMS) are certainly not new and have been around since the 1960's. Yet this is a technology that is still abused by developers who treat it as nothing more than an elegant access method, thereby thwarting the intent of the DBMS which is to share and reuse data, not to mention integrate systems and software.
Since most "agile" developers are in a rush they tend to avoid defining and reusing data elements preferring instead to define data within the confines of their own single program, usually with cryptic programming labels thereby preventing others from understanding the program and causing a rewrite when the programmer has moved along to another job. There is little or no consideration for how the data may be used in other programs or processes, just their own.
I'm not sure why programmers tend to resist the standardization of data other than it requires a type of organization and discipline that is still the exception as opposed to the rule in most development organizations today.
The point is, development can be greatly expedited simply by standardizing and reusing data definitions, not to mention implementing changes and integrating systems thereby producing "clean" information. It just requires a conscious effort to manage data like any other resource, such as managing and reusing the parts in a manufacturing facility. Unfortunately, the reality is that we live in an imperfect world where common sense in not very common.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com
For Tim's columns, see:
http://www.phmainstreet.com/timbryce.htm
Like the article? TELL A FRIEND.
Tune into Tim's THE BRYCE IS RIGHT! podcast Mondays-Fridays, 11:30am (Eastern).
Copyright © 2011 by Tim Bryce. All rights reserved.
No comments:
Post a Comment