Blog: Dan E. Linstedt

« Appliances and EDW Integration, a second look | Main | RFID for Data? Watermark for Data? »

Data Administration - What IS It?

Well, an interesting question. I just gave a presentation at Informatica World 2006 on Data Administration, the roles, responsibilities, and possibilities that the DA must undertake and manage. If you're in a DA role today, I'd be very curious to hear some of the types of "dirty jobs" that you've had to do in this role. Coming from a government background, the DA I had on the team had an interesting time in life. In this entry I'll try to describe my impressions of the DA role, and how it's expanded today - and what they should be thinking about.

Data Administration is really a role with responsibilities. It may be seen as a job title for some, but in many of the data integration projects I've worked on, it includes bits and pieces of the following additional roles: Business Process Engineer, Data Manager, Data Steward, Data Quality Metrics Manager, Logical Data Modeler, Data Flow Designer, and so on.

The DA roles I've been involved with had to dig deep, they had to address the Data Flow portions of the business processes (there's another entry coming on defining business processes as they relate to Business Intelligence and data integration), they had to map these data flows in the business to the logical models, help define the metadata for the elements, ensure the business requirements would be met by the models and processes that were to be built underneath. They also had to work as a data steward (in some cases where a specific data steward role had not been defined) which means they interfaced with the business users, managed the master data, definitions, master metadata, and business process metrics (KPA/KPI's).

Eric Rawlins in 1995 defined DA role this way:
Originally Published by: Database Research Group, Inc
http://www.well.com/user/woodman/organic.html

What do we mean by that in the case of data administration? We mean that DA must get out of the design review committee mentality and substitute something more value-added and flexible. It must recognize that systems tend to grow organically, and be a part of that process, rather than an instiller of order upon it.

A big part of the DA role includes (today) Compliance, auditability, and managing metadata initiatives. Below is what I additionally define as a part of the DA role:
* Data administration and management are key roles in today's enterprise projects
* Data administration is a part of data management; the two should be utilized together
* Compliance, accountability, and governance provide a foundationally strong and tenable architecture, and must be a part of the DAs working knowledge

The DA must be capable of adding in compliance, governance, and accountability to the systems. After all, the Data that they are responsible for must be accurate; the processes that they define (as an interface between business and IT) require checking, managing, and proper accountability. Below are the top 10 problems within the DA role:

http://www.educause.edu/ir/library/text/CEM9047.txt

1. Inadequate or missing master metadata
2. Ineffective master data management
3. Incomplete logical models
4. Undefined business process models
5. Missing process control and metrics measurements
6. Non-defined user access matrices
7. Ineffective change management
8. Missing element classification system
9. Lack of user-training material
10. Mismatched data performance SLAs with DBA objectives

I'll blog more on this subject as we move forward, but for now - here are some of the things that are happening in the commercial organizations around the world:
The DA role is being cut and slashed, often to the detriment of the business - these folks know and understand the business, and are more critical TODAY than they ever have been, particularly with governance, compliance, and metadata initiatives. The DA role takes a special breed of individual, someone with business acumen, and IT background - someone who can cross the lines (which their really shouldn't be any lines anyway), and someone who can understand the data set and model the information according to the business.

Somewhere along the way, responsibility of data modeling became an IT only specification when it really belongs in a cross-functional role, dotted line report to business, with a direct report to IT data management staff. Until the business begins re-defining or re-instituting the proper Data Administration groups, data modeling and Data Integration, along with the processing of that data will continue to split further apart due to differing goals and objectives.

Thoughts? Comments?
Dan L
Daniel.Linstedt@MyersHolum.com

Share: