Craig Mullins: Data Administration and Database Administration are Both Vital
Craig Mullins is a really smart guy (He's also very nice, I met him at a conference a few years ago). He posts regular articles in "Database Trends and Applications" and I really enjoy his work. His most current article is really a good one, however the DBTA website is really not very user friendly so I've pulled this from that site for your viewing pleasure.
Until next time...Rich
Craig Mullins: From the March 2006 edition of "Database Trends and Applications"
Data Administration and Database Administration are Both Vital
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. This trend may be coming to an end, but first let's examine the roles. Both the DA ( data administrator or data architect) and DBA ( database administrator) functions 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 DBAs should understand more about the business in order to more effectively administer the databases under their control. The DAs should understand more about the technology. Cross¬ training enables both to do a better job. The DBAs will know why they are creating and maintaining the databases. The DAs will know what is possible given current technology and why some things may need to change to be physically implemented.
Yet, when the DA and DBA roles converge, it 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. So the DBAs do the bare minimum, creating models as best they 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. Over time, the practices die. The CEO or CIO still says, ' We treat data as a corporate asset,' but they don't.
In a large IT shop, where data is truly treated as a corporate asset, both DA and DBA roles are vital. 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 is that 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. The DA can be thought of as the Chief Data Officer. The position has nothing specifically to do with technology.
When the DA role is undefined in the organization, the DBA often assumes the mantle of data planner and modeler. The DBA usually will not be able to assume all of the functions and responsibility of the DA. Most managers of the DBA groups typically cannot dictate policy, nor possess the skills to communicate effectively with business users and build consensus. Many DBAs, frankly, are happier dealing with technical issues and technicians.
When DA and DBA functions exist within the organization, the two groups must work very closely with one another and there must 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. A DA is required and must not be treated as an after thought. Both a DA and a DBA are required in order to effectively manage business data.
Craig S. Mullins is a data management strategist and consultant for Mullins Consulting, Inc. He has extensive DBA experience with multiple DBMS products.
Contact him at craig@craigsmullins.com.
Until next time...Rich
Craig Mullins: From the March 2006 edition of "Database Trends and Applications"
Data Administration and Database Administration are Both Vital
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. This trend may be coming to an end, but first let's examine the roles. Both the DA ( data administrator or data architect) and DBA ( database administrator) functions 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 DBAs should understand more about the business in order to more effectively administer the databases under their control. The DAs should understand more about the technology. Cross¬ training enables both to do a better job. The DBAs will know why they are creating and maintaining the databases. The DAs will know what is possible given current technology and why some things may need to change to be physically implemented.
Yet, when the DA and DBA roles converge, it 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. So the DBAs do the bare minimum, creating models as best they 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. Over time, the practices die. The CEO or CIO still says, ' We treat data as a corporate asset,' but they don't.
In a large IT shop, where data is truly treated as a corporate asset, both DA and DBA roles are vital. 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 is that 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. The DA can be thought of as the Chief Data Officer. The position has nothing specifically to do with technology.
When the DA role is undefined in the organization, the DBA often assumes the mantle of data planner and modeler. The DBA usually will not be able to assume all of the functions and responsibility of the DA. Most managers of the DBA groups typically cannot dictate policy, nor possess the skills to communicate effectively with business users and build consensus. Many DBAs, frankly, are happier dealing with technical issues and technicians.
When DA and DBA functions exist within the organization, the two groups must work very closely with one another and there must 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. A DA is required and must not be treated as an after thought. Both a DA and a DBA are required in order to effectively manage business data.
Craig S. Mullins is a data management strategist and consultant for Mullins Consulting, Inc. He has extensive DBA experience with multiple DBMS products.
Contact him at craig@craigsmullins.com.
Comments