The DTA: A Jack-of-All-Trades Hero

In the land of Not So Long Ago, the DBA was the hero of the IT shop. The DBA determined the content, internal structure, and access strategy for the IT shop's database; defined security and integrity rules; and monitored performance. But in the land of Here and Now, the up-and-coming hero is the data-tier architect, or DTA. This valiant character is a senior SQL Server DBA and a strong developer.

I first wrote about our noble DTA hero in October 2000, noting that "as the lines blur between database technologies and the server products you use to build these e-solutions, the lines delineating the professionals who support these technologies also blur, creating a new position I call a data tier architect (DTA)" (see "Birth of the Data Tier Architect" ). Years ago, it was hard to imagine a company without a DBA to manage its relational-database infrastructure. Today, most of my smaller customers and many of my midsize customers don't employ anyone with the DBA title. Only my larger customers (Fortune 500-size) seem to have DBAs in the traditional sense. And yet, those small and midsize companies have big investments in relational-database technology.

In the land of Here and Now, the mighty position of DBA is sometimes relegated to a junior role that's focused on simple backup tasks. The development team or roving architects who might be working on multiple projects at the same time now make the fundamental architectural decisions regarding the database. That's not necessarily a good thing.

Companies can save money--in the short term anyway--by making their development team responsible for the database. But this decision might be significantly more expensive than cutting out DBAs in the long run if someone who doesn't have the experience of an expert DBA makes a very bad database decision. Organizations are also finding that daily database maintenance requirements, for SQL Server in particular, are easier to keep up with than they used to be, thanks to continual improvements that have made the software and administration tools easy to use. Today, setting up a SQL Server and creating a workable database doesn't take long (although you might not get a correctly or optimally implemented database solution).

In general, right now, the sky isn't falling on IT shops that don't have full-time DBAs to manage their important database assets. But I wonder whether we're approaching a point where the lack of full-time, permanent DBAs will begin to create serious problems for organizations. On one hand, SQL Server management tools get easier to use all the time. On the other hand, applications are becoming increasingly complex and easier to build. And as we build more complex applications with easier-to-use tools, it's easy to make serious architectural mistakes.

The core roles performed by DBAs will never go away. But as the tools make it easier to perform basic tasks, such as backing up a database, I expect the traditional DBA role will be less important than the role of a multifaceted DTA is.

I coined the term DTA 4 years ago to describe the role I had been playing for several years. I wasn't a developer, although I could whip up a program if I needed to. And I wasn't a DBA because I had no operational responsibility for doing backups, ensuring fault tolerance, or performing other traditional database-management tasks. What I had was a firm grasp of the multidisciplinary skills required to plan, build, and maintain complex database solutions. A specialized jack-of-all-trades seems an oxymoron, but a DTA is just that: a master of everything to do with database issues. This is a common role at smaller shops that no longer have a full-time DBA. However, many of the folks playing the role of DTA might not be strong enough in advanced areas of database technology, such as performance tuning and disaster recovery, to fully replace the skills a DBA can offer. There are always a couple of developers that everyone looks to for answers to database questions. But is there a way for those developers to nurture their multidisciplinary data-management skills without becoming DBAs and giving up their development background? And, I think that large enterprises will need traditional DBAs for a long time to come. Backing up a handful of small databases might be a task for a junior employee, but designing a backup-and-recovery plan for an enterprise with hundreds of databases encompassing terabytes of data is beyond the reach of a simple wizard.

The role of DTA has gone unrecognized long enough. The DTA has been an important piece of the corporate IT puzzle for years, and organizations would be well served to recognize the DTA as a distinct career path, different than that of a developer or generic software architect. In the coming months, I'll talk more about the DTA's role and how you can leverage this role to build your career as a SQL Server professional. I'll also share my thoughts on how SQL Server 2005 will affect both traditional DBAs as well as the evolving DTA role. But first, I want to hear your thoughts. Does your company have a full-time DBA? If so, how large is your company? Are you a traditional DBA, or did the lines between DBA and developer begin blurring for you long ago? I'll share the most interesting comments and perspectives in upcoming commentaries as I discuss the future of DBAs, DTAs, and SQL Server 2005.