Introduction

With more business relying on data, we DBAs seem to have a more promising

future. But a question naturally comes out, "Where is the next career stop for a

DBA in terms of challenges and self-value realization?" In this article, I'd

explore one possible career transition path for DBAs, i.e. from a database

administrator (DBA) to a database administration architect (DBAA), and I will

try to address the following questions: what is a DBAA, the major work and

responsibility of a DBAA, the values of a DBAA. and how to be a DBAA.

What is a DBAA?

A DBAA is a professional who is responsible for designing a solution framework

that maximizes the efficiency of the resources dedicated to the data system

administration to meet the business challenges, such as cost, performance,

security and regulatory compliance requirements etc.

The main responsibility of a DBAA is to achieve the highest possible ROI with

the available resource in the context of the various business requirements. The

details of this responsibility may include

Define the administration scope in terms of targets and risks / costs

Build up an optimized processes model which can maximize the ROI for the current

resources

Pioneer in evaluating / choosing the right mix of technology

Explore / create innovative methodology to adapt to business environment.

Act as a facilitator / advisor for the stakeholders to best use the data system

/ asset.

The values of a DBAA

A DBAA's values lie in three fronts:

First to the business: a DBAA focuses more on business instead of servers, which

means a DBAA is to take care of the business needs from database administration

perspective. This can range from designing processes to meet special business

needs (e.g. auditing purpose), ensuring database system performance / security

quality, to facilitating other system architects for better business projects

etc.

Second to the team: a mentor for valuable advice; a resource for in-depth

technical discussion (have you ever had the feeling that it is tough to find

someone knowledgeable enough to discuss your "exciting" technical ideas?); a

hero who may help the team out of the hot water from time to time.

Third to the management: an assistant to the management success, a manager

succeeds only when his/her team members succeed. With a DBAA providing robust

and innovative solutions to manage the business core asset, i.e. data, it will

be easier for the manager to demonstrate the value of his/her team to the

company.

Professional traits of a DBAA

A DBAA should basically have the following three fundamental traits:

1. An imagination dreamer: a DBAA's capability is only limited by his

imagination. Most of the time, it is not difficult to solve a known problem, but

it is hard to foresee a potential problem, which, if solved, may bring huge

value to the business.

2. An innovation explorer: with all "dreams" at hand, a DBAA needs to explore

all the possibilities to realize the dreams. For example, to do a full backup,

you can use T-SQL, but you can also use DMO / SMO with VBScript or PowerShell,

and you may even use SQL Writer with VB.Net. Which method to use? The famous

answer is "It depends".

3. An implementation practitioner: Once a solution is chosen, the capability to

implement the solution is critical. A good example here is you may have exact

ideas of how to decorate your house, but to implement the decoration is totally

different from the pure decoration ideas. To do decoration yourself, you may

need to know how to do hardwood flooring, how to do drywalls, how to do

painting, where to purchase the best affordable materials etc, etc.

The path to be a DBAA

There is no existing way to be a DBAA, but a road is always created by pioneers'

footprints.

A DBAA should first establish his/her working philosophy and then proceed

his/her work with this philosophy.

To me, a DBAA's work domain can be summarized as dealing with a simple formula.

Expected Goals = Methodology (Resources, Constraints)

Assuming Methodology is the function, Resources and Constraints are the inputs

for the function, and Expected Goals is the result of the function. ("Resources"

and "constraints" can be considered as the same depending which side you are

on.)

Expected Goals = the sum of known business requirements + Visions of future

Resources (Constraints) = Current human capital + Time + Budget + Current system

environment + Corporate policy

Both "Expected Goals" and "Resources" are constrained by boundary factors, such

as availability, deadline and policy.

So in essence, a DBAA needs to work out a customized formula to maximize the

returns (i.e. "Expected Goals") out of the input.

However, it is important to realize that in real life, any solution is a

compromise among the various stakeholders with different interests.

Some potential research fields for a DBAA

I think the following areas may be very worthwhile for a DBAA to explore because

the researches are significant to build an applicable methodology , which is the

primary work for a DBAA.

Database administration quality model: How to evaluate an existing

administration practices? How is the current practice benchmarked against

various best practices?

Database administration patterns: Can you find out the proven and repeatable way

to solve some common issue? For example, trouble-shooting performance, database

system deployment or auditing configuration change?

Database administration operation management: research on the highest

value-adding activities / resources distribution in database administration work

Database administration maturity model: a model against which we use to evaluate

the general quality of the database administration?

Difference between DBA and DBAA

The difference between a DBA and a DBAA lies in the pattern of thought each role

may have and the way each will adopt to approach an issue.

A DBA tackles on day-to-day problems while a DBAA strives for long-lasting

methodologies.

A DBA is a solution provider while a DBAA is a process inventor.

A DBA is more of a practitioner with theory while a DBAA is more of a theorist

with practices.

In essence, a DBA creates values by providing solutions to tactical issue while

a DBAA creates values by architecting a healthy and high quality database

administration eco-system,

Summary

A DBAA is the governor of the data administration kingdom. To better manage the

kingdom, s/he needs to define "laws" for his/her jurisdiction. With these

"laws", it is expected to build a healthy and efficient database management

environment together with a culture that will last beyond the scope of the

DBAA's regular responsibility and may be merged with the corporate culture.

After these "laws" have been tested and proved to be fair and efficient in the

database administration world, as a "law-maker",

the person can be considered as successfully transitioning from a DBA to a DBAA

role

Post-Note

In the last PASS conference (Nov, 2006 in Seattle, WA), I was

fortunate to be chosen to attend a SIG meeting organized by Microsoft to discuss

about future high-level SQL Server professional certification, unfortunately I

was unable to attend due to my company's urgent business. I promised the

organizer from MS, to submit an article on SSC detailing my thoughts about the

next level of certification for SQL Server professionals.

So in this article, I discussed what we as DBAs can aim for in our next career

step, details about DBAA (what it is, its value and how to achieve it) are

discussed.

In short words, a DBAA is a leader that can inspire a team and cultivate a

administration culture suitable for the corresponding business environment; a

DBAA is a CFO who ensures the best ROI out of his/her resources in database

administration, a DBAA is a theorist who pursues the practical methodology that

can be applied to real-life world, and finally a DBAA is a practitioner who is

capable to see his/her agenda to decision and to final implementation.