Newcomers to this blog, and my friends in the IT Service Management community, may not realize the challenges faced by the discipline of data management. In order to effectively manage an enterprise's data, robust control points are required so that the contents of all databases are effectively documented and their structures are built to standards...
Without this, the enterprise starts to suffer from the curse of "disparate data": reports that don't add up, figures that can't be reconciled, and executives showing up at meetings with different versions of the truth. (Not a good thing when you're at the board level and have differences of opinion as to how much the company made last year and what it's worth...)
Unfortunately, the cure for this is too often seen as worse than the disease: analyze the data being stored in the enterprise's databases, reconcile it where required, and establish requirements that all IT projects deliver data that integrates well into the existing environment. There's no mystery how to do this: one establishes a centralized Data Management group with authority over the LOGICAL structures of data, their definitions, relationships, stewardship, and so forth. (This as opposed to a purely physical Database Administration group with authority over the database servers.)
Trouble is, a group like this (to do its job right) needs to be on the critical path of any project attempting to put tables on a database server. The group asks very time-consuming questions such as:
- What is the business definition of this data element you propose?
- Does this data exist anywhere else in the organization?
- If so, who should be the system of record? How will you keep the data synchronized?
and so forth. Experience shows that many organizations that used to have such practices abandon them as the project teams raise protests to their sponsors that the "Data Administrators are slowing us down." This has led to the shuttering of DA groups at various organizations.
However, such an approach is reactive, and ignores the fact that some of the world's largest and most successful corporations (such as Intel, 3M, and Target) continue to require a Data Administration process. How does one succeed in bridging the project versus enterprise divide in this case?
The answer is simple: metrics and process. Instead of reactively closing down your DA team, start to measure them and their effect on projects. Also, start to hold them accountable for data re-use. You can't manage what you can't measure; this is as true of data management as anywhere else. How long does it take them on average to analyze a data model? What are their customer satisfaction indicators? (Customers in this case being the project teams.) What is the ratio of re-used to new data by project?
Tracking such figures is not trivial, in a complex endeavor like building enterprise IT systems - but unless you measure and optimize your internal IT processes along with your core business processes, you'll never get adequate control over your information technology development and operations.
