The field of technology is a fantastic career choice. Technical professionals can choose from almost any industry or organization for work, since everyone uses computers. From hospitals to churches, you can find a position in technology. But just how do you break into a technical job and, specifically, how do you know if database technology is right for you?
In this 2-part article, I'll explore some of the decisions that you're faced with when embarking on a DBA career, and some of the traits, knowledge and experience that you'll need to succeed. This article will focus on career specialization, traits and skills. In Part 2, I'll discuss the knowledge and experience a DBA needs to do an effective job.
Career Specialization
Whenever any industry is in its infancy, it is typical to see professionals in that discipline with a wide array of skills and knowledge. In the early days of technology, most of the people who worked in the technical fields filled many roles. They not only knew about the applications of software on a computer, but they could probably write the code for it and potentially even build the computer it ran on.
As an industry matures, specialization develops. Features begin to "fill out" or grow, and it becomes more difficult for one person to know all parts of the system. Technology has followed this path. At one time it was possible to know a great deal about both hardware and software, but in modern systems specialization is more the norm. And systems are becoming more specialized all the time.
And that brings us to you – or more specifically, what part of technology you should specialize in for your career. You can choose from a wide spectrum of hardware and software disciplines, and within these specializations are administrative and development areas. One of those areas is the Database Administrator, or DBA. The DBA role is attractive because it encompasses so many areas of technology. DBA's write code, design systems, maintain systems, and even work with other technologies such as storage and networking.
There are often fewer DBA's in a company than other technical roles and, because of this, the DBA often has a lot of responsibility, and a lot of authority. They are also well paid and usually one of the last people to be terminated in a layoff situation, especially if they are performing well. This makes the job of the DBA highly desirable. In this article, I'll show you how you can decide if you want to pursue this career, and what strategies you can use to get the position.
Which DBA Do You Want To Be?
It's often difficult to describe a DBA's job, since it depends on what kind of DBA you're talking about. In the purest sense, a database administrator takes care of the maintenance and other administrative tasks on a database server, or set of servers. But the acronym "DBA" can refer to much more than that. The term DBA is also used to describe those that design databases, write programs, or even those who create Business Intelligence (BI) applications.
As the database technology industry has matured, database vendors have added a huge array of features to their products. The various platforms no longer consist of just an engine to store and retrieve data. Most every major vendor has included reporting, business information, analysis and many more features in their offerings. Some vendors (such as Oracle) split these into separate purchases or installations, others (such as Microsoft) include them as part of the overall package. In any case, most of the professionals in these areas start in the basic database engine of the package and then begin to specialize into these other features.
I'll stick with the basic definition of the database administrator in this article, with one exception. You'll often hear the term "Development DBA" used to distinguish a technical professional that specializes in designing databases and writing the SQL code, using either high-level languages such as C# or Java or the dialect of SQL that comes with the platform. I've also heard the term “Development DBA” used for the DBA that takes care of the development systems. In larger shops even the design work on a database and the database programming are split out. These designers are sometimes called "Database Architects". I'll include the design and coding aspects of the role for this discussion, although this task is normally reserved for those with more experience.
That isn't to say that any of these titles are necessarily mutually exclusive. You might find the DBA of a small firm taking care of the server, designing a database and database programs, implementing reporting and business intelligence and more. In larger firms there may be a technical professional strictly dedicated to the security aspects of the database. Not only are there different roles that a DBA fills, the experience required in these areas varies. So perhaps more than just about any other technical role, the skills for a DBA are quite difficult to pin down. Nevertheless, there are certain skills, knowledge and experience that all DBA's share.
Traits and Skills
We all have aptitudes - things we are good at and things we are interested in. As you age, you, and others around you, begin to notice that you're just inherently good at some things. Most of the time, we realize or express these talents in terms of the specific things that we do. "I'm really good at math" we might say, or "I know computers really well. They are easy for me to work with."
Psychologists tell us that we have base characteristics, called traits, which make us comfortable with certain things. The particular skills (good with computers) we have might actually be traits of organization, or control. So what traits are useful to have if you want to be a DBA?
The first trait that is useful in a DBA is a strong sense of responsibility. In many technical roles, loyalty isn't required past doing a great job in the present role. However, the DBA designs, programs and maintains the data that is the lifeblood of the organization. If the design of the data infrastructure is not correct, it can compromise the entire system. A strong sense of responsibility can lead to two things: one of them bad, the other good.
If you take responsibility for absolutely everything and don't learn to work with others and delegate tasks to the proper people, you'll end up stressed beyond what you can handle and "burn out" or sour on a job. Some things are your concern and other things are the responsibility of others. If you develop your sense of responsibility properly, those in charge will realize that you care about the data that runs the business.
Another trait that is useful for the DBA is devotion to detail. It isn't enough to solve the problem at hand, but also to think through multiple permutations of the design. It's often the little things that trip up the technical worker; a close attention to the details can save you from some significant problems.
Another DBA trait is confidence. Many of the restrictions required to secure and protect the database system cause extra work for other technical professionals on the team and sometimes even the business. Once the DBA designs those controls, it is vital that they are able to explain and stand by those decisions, even when they are unpopular.
That isn't to say that the DBA should be so confident that he or she does not work well with other team members. The DBA often has to coordinate not only with the members of the technical staff but the businesspeople in the company or organization. In fact, in many cases the DBA is the voice of one side of the requirements to the other. Working with others and respecting their opinions and expertise should always temper your confidence.
Curiosity is another trait of the DBA. Database platforms are now full of features, from reporting systems to Business Intelligence suites. They store not only structured data but formats from XML to binary objects. A curious DBA often steps outside the bounds of the data storage and manipulation technologies into other areas, finding new ways to add value from their systems.
A very important trait is the ability to learn on your own. You can become a successful DBA by attending classes and learning from others, but in most organizations, there are few other database professionals, sometimes just one or two. You need to be able to pick up a book or magazine and browse a web site or two to learn by reading and experimenting. At some point, you'll be the expert in your shop, and there won't be anyone there for you to ask questions – you'll just have to find the answer yourself. In fact, at some point, the rest of your shop will be asking you how to do things.
Along with these basic traits are various skills that are useful in a DBA. What differentiates a trait from a skill? A trait is something that is part of your personality. A skill is something you are good at, or at least that you are interested in enough to become good at. You can think of traits as something you have, and skills as something you can develop.
Of course the first skill you need is to be extremely adept at technology. You can't learn to play the piano by reading a book, and the same holds true for working with databases. You should create and use databases yourself – for your music catalog, your recipes, anything. You just need something that you create, care for and feed on your own. That means using not just one platform, but several. One day you'll be called on to develop systems, and the more systems you've been exposed to the more ideas you can cull from others to make a truly usable, maintainable system.
Another skill that is useful in a DBA is to be able to think in structures. Databases are all about structured data, so you need to be able to separate groups of things into smaller components. For instance, when you see a list of parts grouped to form a unit, can you break that information into a logical grouping? Is there only one way to do that, or are there others? When would you use each? These are the kinds of questions that face the design DBA every day.
You'll also need to develop the skill of presenting technical detail to the people you meet with. For the development team, you need to be able to speak technical shorthand, complete with TLA's (Three-Letter Acronyms) and other technical terms. When you're presenting the design to the business folks, however, you need to be clear and understandable so that what you think they hear is what they really hear. I've been in countless adversarial meetings that evolved simply because the technical staff felt they were clear when they weren't. As the DBA, I've often had to "translate" between the two.
You'll need to be skillful at setting boundaries for those same reasons. There are times when you'll have to choose between good and good enough, and as painful as that is for a professional to do, you'll need to know what the right choice is. That's a skill that is built up over time, and is useful to help keep your stress level down.
If you're just now deciding on what kind of college courses to take, or what career path to follow, then it's useful to know whether or not you are going to enjoy that career choice. This isn't to say you'll fail at the job or not enjoy it if you aren't a details person – it takes all kinds of personalities to make an effective group. It's just that it might take you a bit more work to be proficient in an area if you aren't predisposed to it.
You can read part 2 of this series.