One Concept Equals One Data Element: A Rule for Developing Data Elements - High-Performance Web Databases: Design, Development, and Deployment - page 88

cleanup efforts can be accomplished without repositories that can do this,
but they will take longer, cost more, and be more error prone. Few data
repositories exist that can store these complex relationships; most must be
modified in some way.
Unfortunately, the tasks needed to prepare for a data element analysis and
cleanup efforts are often perceived as a delay in the actual work. The tasks
of designing an appropriate repository structure, which requires knowledge
of what problems are likely to be encountered and prediction of what
aspects of those problems need to be documented, are additional pressures.
The end result is often that very little forethought goes into designing the
repository structure to support data element analysis and cleanup.
Data administrators should not standardize data elements for the sake
of reporting growing numbers of standard data elements. The proponents,
agents, users, custodians, and functional sponsors should understand the
value of quality data elements and demand quality data elements. As is
often the case with other information resource management concepts,
data administrators take it on themselves to educate their proponents,
agents, users, custodians, and functional sponsors. After these people see
the light, the data administrator should not hide away with the data
analysts pounding and pummeling melded data chunks into quality data
elements. The information customers must remain involved in the analysis
and creation of their data elements.
Well-designed data elements can provide many benefits to an organiza-
tion. Information customers can confidently share data and discuss
changes to the systems they use with the developers with confidence that
they are speaking about the same things. Developers can forgo the inconve-
nience of inventing data element names or guessing about the meaning of
names concocted by some other developer. However, standard data
elements are not easy to develop. Using sloppy standardization policies
may be worse than not having any standards because the developers and
information customers may conclude that standardization has not helped
them at all if they spent substantial resources complying with a poorly con-
ceived standardization program. Large data element standardization pro-
grams in existence for several years have had varying degrees of success.
Any organization just embarking on establishing a data element standard-
ization program would be wise to thoroughly scrutinize those programs to
identify what works, what does not, and why.