From DBA to DBAA

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 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.