Home > Publications > Newsletters

Revitalizing Data Administration
By Patricia Cupoli, CCP
Consulting Associate

Introduction:

Data Administration (DA) as an organization has seen its share of ups and downs in the 1990s. It tends to be 'downsized' when its value is dubious or not proven, yet it is one of the first functions to be re-established when economic conditions improve. The value of a successful DA group whose role it is to manage data and metadata as sharable, consistent, accurate, and available corporate resources is often perceived and not measured. More important, the impact of this organization is usually not perceived to be as widespread as it actually is when successful. Most 'DA naïve' organizations see the DA role as 'dictionary maintainers', and when an accurate dictionary is non-existent, IS management rekindles the existence of the responsible organization.

For DA organizations to remain viable, the focus must expand to proactively offer services that match each DA customer type. The various DA customer types in an enterprise can include:

• Internal project members (developers, DA, DBA) who are part of:
• Traditional systems development life cycle
• 'Accelerated' short timeframe projects
• External contractors, part of an outsourced effort with internal business program staff
• Those that supply internal/external data
• Those that use/access internal/external data

Revitalized DA Organization:

New customer types demand a revised DA organization. This new organization should contain four major functional areas:

• Data Administration Infrastructure. The objective of this function is provision of the framework that supports the definitions, use, and maintenance of data resources. This framework includes the DA organization, DA plans, and data/metadata policies, standards and procedures for each customer type.
• Data Model Administration. The objective of this function is the provision of an infrastructure to support the creation and maintenance of the enterprise or ‘corporate’ data model and application data models - most likely with the use of a CASE tool. DA needs to actively participate in the modeling sessions to offer guidance and/or review if logical data modeling is a mandatory step in the enterprise's systems development life cycle.
• Repository Administration. The objective of this function is creation and maintenance of the Repository environment that each DA customer type should be encouraged to use. DA must work toward the goal of having the Repository become the centralized location of metadata for both the development and production environments as well as for end-user data access.
• End User Data Access Administration. The objective of this function is creation and maintenance of the data access categories as well as support of the data warehouses. A metadata directory needs to be established and administered for end user data access.

Roles and Responsibilities:

The four major functional areas of this revised DA organization have associated roles and responsibilities. Within each sub-organization will reside DA personnel, not necessarily pure Data Administrators as before. These DA personnel must have knowledge of data modeling. The roles and responsibilities must be documented as internal DA procedures, as well as appropriate standards, policies, and procedures to guide each DA customer type.

The roles and responsibilities are presented by DA functional area:

Data Administration Infrastructure

• Establish and maintain a DA Organizational Short/Long Term Plan. DA needs to be involved in value added projects that provide benefit in the short term while keeping long term goals in mind.
• Establish and maintain the appropriate DA Infrastructure for each DA customer type. This includes establishment of DA roles, responsibilities, external liaison interfaces, and DA/Repository Administration internal procedures.
• Establish and maintain DA Tools and Tool Roles. DA tools can include a CASE tool and its encyclopedia as well as a Repository Infrastructure. Evaluation of tools is conducted with other appropriate organizations. The appropriate data/metadata policies, standards, procedures for each DA customer type needs to be enhanced and/or developed.
• Communicate by giving presentations, training, etc. to each DA customer type regarding DA related topics. A data users group is an example of liaison activity.
• Establish and maintain ‘standard practices’ with regard to data analysis approach, data element identification, deliverables, and tools and techniques. These standard practices apply to all DA customer types.

Data Model Administration

• Create, publish, and maintain the Data Architecture. This includes subject area identification as well as creation and maintenance of the enterprise or corporate data model.
• Provide project support for each DA customer type through the development and/or the review of data models, etc.
• Manage daily check-in / checkout of models and their maintenance, synchronization and versioning with the use of a CASE tool encyclopedia.
• Resolve inter-model conflicts.

Repository Administration

• Establish and maintain the Repository/tools architecture and Repository objects (metamodel).
• Enforce naming standards, keywords, abbreviations and aliases in the CASE and Repository environments of each DA customer type.
• Establish and maintain Repository controls, security profiles, templates, and standard reports.
• Establish and maintain Repository access for each DA customer type.

End User Data Access Administration

• Create and maintain data categories (subject areas) and relationships to entities for each DA customer producing data for end user access.
• Provide data warehouse support in the areas of modeling, source data quality, business rules, end user tools, etc.
• Create and maintain source-to-target data mappings, data warehouse metadata directory, and data access rules.

Conclusion

This DA organization expands beyond many passive DA organizations that offer only data dictionary administration and support. Revitalization of DA calls for providing DA services geared toward individual DA customer types. The revised organization that supports this premise contains four functions with corresponding roles and responsibilities.

If an existing DA organization does not have the means to revise itself currently, then starting small with value-added projects will gain credibility as the organization moves towards this revitalization target. An analysis of the current environment and a migration strategy to this target are good places to initiate the revitalization process.