Craig S. Mullins

Return to Home Page

March 2006

 

 

 

                                           



The DBA Corner
by Craig S. Mullins

 

On Data And Database Administration

 

It seems to me that there is a pendulum swinging back and forth over data administration and database administration. At times, the two roles seem to be gradually getting closer together. Then the pendulum swings the other way and the two roles become more distinct again.

I think that this phenomenon is a trend that may be coming to an end, but let’s not get too far ahead of ourselves. First, let’s examine the roles.

There are similarities between the DA (data administrator or data architect) and DBA (database administrator) functions: they both tend to data and share some similar skills. For example, both should be able to create data models though the DA will be more adept at it. So, DBAs and DAs need to cross-train. The DBA should understand more about the business in order to more effectively administer the databases under his control. And the DA should understand more about the technology. Cross-training enables both to do a better job because the DBA will know why he is creating and maintaining the database – and the DA will know what is possible given current technology and why some things may need to change in order to be physically implemented.

Yet, when the DA and DBA roles converge it is an unfortunate trend because it is usually happens for all the wrong reasons. Convergence typically occurs when companies are looking to cut back on expenses: one place that seems to get cut more often than not is the DA. Therefore, the DBA is tasked with picking up the DA’s role now that the DA has been let go. So the DBA does the bare minimum. Heck, he already has a more than full-time job and can’t possibly pick up another full-time job. So the DBA models as best he can, but other more important DA functions drop by the wayside - repository maintenance, proper data usage, metadata definition, stewardship programs, etc. all just kind of grind to a halt – and over time, the practices die. Sure, the CEO or CIO still says “We treat data as a corporate asset” but they don’t really.

In a large IT shop, where data is truly treated as a corporate asset, both DA and DBA roles are vital. And there needs to be a demarcation between the roles of the DBA, DA and other data-related job functions.

Data administration separates the business aspects of data resource management from the technology used to manage data. When the DA function exists in an organization it is more closely aligned with the actual business users of data. The DA group is responsible for understanding the business lexicon and translating it into a logical data model. The DA is involved more in the requirements gathering, analysis, and design phases; DBA in the design, development, testing, and operational phases.

Another differentiating factor between DA and DBA is the focus of their effort. The DA is responsible for issues such as identifying and cataloging the data required by business users, production of conceptual and logical data models to accurately depict the relationship among data elements for business processes, production of an enterprise data model that incorporates all of the data used by all of the organization’s business processes, setting data policies for the organization, identifying data owners and stewards, and setting standards for control and usage of data.  In short, the DA can be thought of as the Chief Data Officer of the corporation. The DA position has nothing specifically to do with technology, though.

The larger the organization, the more likely that a DA function exists. However, when the DA role is undefined in the organization, the DBA often assumes the mantle of data planner and modeler for the organization. The DBA usually will not be able to assume all of the functions and responsibility of DA because the DBA has many other technical duties to perform that will consume most of his time, the manager of the DBA group typically does not have an executive position enabling him to dictate policy, the DBA generally does not have the skills to communicate effectively with business users and build consensus, and frankly, most DBAs are happier dealing with technical issues and technicians, than with business issues and non-technicians

When DA and DBA functions exist within the organization, the two groups must work very closely with one another. It is not necessary that both have the same manager, though it could make it easier to facilitate cooperation between DA and DBA. At any rate, it is imperative that there be some degree of cross-pollination of skills between the two groups. The DA will never understand the physical database like a DBA, and the DBA will never understand the business issues of data like a DA, but each job function would be more effective with some knowledge about the other.

The general point of this piece is that DA is required and must not be treated as an after thought: the DBA is more technically focused, the DA more business focused. Both roles are required in order to effectively manage business data.

 

 

 


 
 

 

 

 

From Database Trends and Applications, March 2006.

© 2006 Craig S. Mullins,  All rights reserved.

Home.