Blog: Dan E. Linstedt Subscribe to this blog's RSS feed!

Dan Linstedt

Bill Inmon has given me this wonderful opportunity to blog on his behalf. I like to cover everything from DW2.0 to integration to data modeling, including ETL/ELT, SOA, Master Data Management, Unstructured Data, DW and BI. Currently I am working on ways to create dynamic data warehouses, push-button architectures, and automated generation of common data models. You can find me at Denver University where I participate on an academic advisory board for Masters Students in I.T. I can't wait to hear from you in the comments of my blog entries. Thank-you, and all the best; Dan Linstedt,

About the author >

Cofounder of Genesee Academy, RapidACE, and, Daniel Linstedt is an internationally known expert in data warehousing, business intelligence, analytics, very large data warehousing (VLDW), OLTP and performance and tuning. He has been the lead technical architect on enterprise-wide data warehouse projects and refinements for many Fortune 500 companies. Linstedt is an instructor of The Data Warehousing Institute and a featured speaker at industry events. He is a Certified DW2.0 Architect. He has worked with companies including: IBM, Informatica, Ipedo, X-Aware, Netezza, Microsoft, Oracle, Silver Creek Systems, and Teradata.  He is trained in SEI / CMMi Level 5, and is the inventor of The Matrix Methodology, and the Data Vault Data modeling architecture. He has built expert training courses, and trained hundreds of industry professionals, and is the voice of Bill Inmons' Blog on

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

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:

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

Posted May 29, 2006 10:38 AM
Permalink | 1 Comment |

1 Comment

I agree with most of what you said here especially "there really shouldn't be any lines anyway". It is this lack of team work that causes the data silos we find in most organizations. However, I would suggest that data administration report directly to the business and dotted line to IT. Compliance, auditability and data management should all be business accountabilities. When you put this in IT, the business will abdicate accountability to IT. Then it is just another IT failure.

Leave a comment

Search this blog
Categories ›
Archives ›
Recent Entries ›