Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

From DBA to DBAA

By Jeffrey Yao,

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.
 

Total article views: 14440 | Views in the last 30 days: 5
 
Related Articles
FORUM

Resource database ?

Resource database ?

FORUM

Move resource database cluster

Move master database and resource database in a 2005 cluster

FORUM

Be a good Database Administrator?

New Database Administrator (Junior)

FORUM

SQL Server 2005 Resources Management

SQL Server 2005 Resources Management

BLOG

Resource database

Today learned new thing about Resource database, as everybody knows resource database is the system ...

Tags
career    
miscellaneous    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones