If you scan the blogosphere, you will see that there are lots of articles and blog entries predicting and explaining how in the future the role of DBA is going to expand to be more than just someone
who focuses on the technical aspects of managing a database. This is not a new topic and is relevant today and in the future. I am continually being asked questions by non-data folks like:
- What exactly does a DBA do?
- How does a DBA fit into a large complex application development project?
- With so much automation built into the new generation of DBMSs, why do we need a person to manage databases anymore?
- Why do we need one with the onset of the new generation of BI tools, SOA and cloud computing?
The answers to some of these questions are obvious to those who work day to day in our field, but maybe are not quite as obvious to our clients and to project teams as a whole.
Traditional Role
Traditionally, the DBA was responsible for making sure the database environment was aligned with the application or systems as a whole. After implementation and as part of the support duties, he
or she was responsible for the performance and monitoring of that database, the backup and recoverability of the data contained therein, the availability of the data as determined by an implicit or
explicit service level agreement (SLA) and that the data, both existing and new, could be stored and retrieved in a reasonable fashion. In most shops, the DBAs are considered the SQL experts and so
are called upon frequently to write and/or analyze SQL to determine the most efficient access paths. Also, in the distributed arena and sometimes for a host-based application, the DBA might write
scripts not only for the application side but to assist in the automation of multiple DBA-related tasks.
During development of a new application, the DBA usually has to analyze, design, test and implement all the components related to the above-mentioned tasks but also is integral in translating the
logical data model into the most efficient physical implementation of the application database(s) balancing storage and retrieval requirements.
Tuning, monitoring and support of the database environment are the daily mantra of a traditional DBA in a traditional shop. However, on many software development projects today, the role of a DBA can
be pretty fluid based on project needs, client skill shortage and cost constraints so many of us are well on our way to what the future holds.
Future Role
The new architectures and frameworks are all about defining an IT infrastructure that is more nimble and responsive so that business problems can be solved rapidly without artificial constraints
defined by a rigid architecture. It also entails defining an architecture that is open, based on industry standards and where multiple and heterogeneous platforms, data sources and applications can
be integrated in a seamless fashion.
This type of open and collaborative system calls for the decoupling of business processes and enterprise data from its underlying IT applications and allows for reduced data redundancy, enhanced data
integrity, increased data sharing across an enterprise and a proliferation of trusted data sources. Other goals of this initiative are to decouple business applications from the infrastructure and to
establish an environment where new and innovative business processes can be quickly introduced and implemented.
In addition, new DBMS capabilities being rolled out with each release, emerging standards are evolving due to SOA maturity and open systems development and the rapid proliferation of new analytic
platforms are rapidly gaining momentum. Moreover, users are clamoring for the ability to merge data with content in an efficient manner, and new hybrid-relational DBMSs are being implemented that
combine relational data and unstructured data stores in one high performance database engine. A solid traditional DBA with motivation, an open mind and a passion to stay abreast of current and future
technology is in a perfect place to take advantage of the next “wave” of information integration and management.
In this new adaptive environment, DBAs must evolve and become more than providers of the data to become the ultimate source for many of the answers about the data and how to design it for use within
the overall solution. In other words, the DBA must move up from being a simple administrator of data to become what some people are calling an information architect. The information architect not
only provides the data but understands the context of it and ensures that the service is delivered securely, efficiently and successfully.
How To Get There
First and foremost, try to become familiar with the industry you work in. Most of us work with data day to day but can not relate it to how it impacts the business. Don’t get lost in the
minutiae of how a particular system works but get in the “heads” of the business people and find out how the system that you are currently working on will help improve the business. One
simple way to do this is to start networking and talking to your business colleagues in the context of the projects you are working on. Also, subscribing to some of the industry trade magazines goes
a long way to understanding the issues and competition that your company is trying to address.
Second, the need for a deep understanding of data privacy/security, performance, data backup/recovery, data archival/retrieval will never disappear. In addition, really understanding how the DBMS is
architected and being able to optimize designs for that architecture will remain a key skill, and keeping your skills honed in those areas is paramount. Also, learn as much as you can about service
oriented architecture (SOA), master data management (MDM), web services, emerging data standards, structured and unstructured data architectures, information integration concepts and analytic
concepts. It is not enough to know the topics; learn them well enough that you can see if there are opportunities to apply the concepts on the current project you are working on. Even while it might
not be able to be applied on your current project, learning this new knowledge will only help you and your career and make you more marketable in the future.
Finally, develop a mind-set of looking at the solution in its “whole” and not just at the database. Develop your architecture and design skills along with honing your database skills so
that people look at you as being part of the design team – not as just the implementer and maintainer of the database.
Summary
The role of a DBA will not disappear but will instead be changing and expanding from a technologist into an information architect who not only knows how a particular DBMS works but also knows
how to apply the data and define services that can solve business problems in a open and collaborative architecture.
The DBA of tomorrow not only needs to be an “expert” on the DBMS he or she is working on but also needs to know how the data will meet the client’s requirements (business
knowledge), how it fits into the overall system (architectural knowledge) and how to optimize it as it flows through the system (performance/web service knowledge). Ultimately, the DBA of the future
needs to identify, design and apply the data services needed to solve the business problem that integrates nicely into the whole solution and performs optimally.
