I felt like I was back in school, talking with the Guidance Counselor about my future career. The difference was that I was the one giving advice, not getting.
A friend of mine was asking me about a career as a DBA. He has an aptitude for computers, speaks more than one language, and wanted to know where he should focus his time and energy trying to get a job as a DBA.
So I asked a simple question: “What would you rather be: the person who designs a car, the person who manufactures the car, or the mechanic that fixes the car?”
He didn’t have an answer right away, but started to understand what I meant by asking. There is a lot to being a data professional these days. It isn’t just about database administration. There are many, many more pieces and each one is growing (some faster than others) with job opportunities.
So I wanted my friend to take some time and think about in which role he felt he would be happiest. Did he want to be the designer? Did he want to help build the car that someone else designed? Or did he want to fix cars that were designed and built by others?
Let me explain this a bit more.
The Designer
This is the person that gets to build something from scratch. If they are lucky they get enough budget to purchase whatever tools they need to get the job done. They build something that they hope will be usable by anyone, something that will be safe and durable, and something that will result in a pleasurable experience for the driver.
These are the data architects and database designers. They are the ones that have the most impact on database performance because they get to decide all sorts of things like data types, normalization, and (hopefully) indexing. The database designer needs to know and understand things like data quality and data retention policy. Also, data usage, requirements analysis, compliance issues…all of these things must be taken into consideration when designing and developing a database. Once you’ve gotten experience seeing your designs implemented and tested by real production loads, you will get better at balancing design theory and practice.
It sounds like a lot because it is a lot. Many times a lot of these areas are skipped over because there aren’t enough people (or enough time) to get it all done.
If you fancy a job as a designer or architect then look for opportunities to get experience in designing a system from the ground up. It doesn’t have to be anything that formal, either. I know people who got their start as an architect by helping a local church build a website for their members. That experience was enough to get them a full-time job as part of a web team with one company and two years later they were able to get a job doing database design.
The Manufacturer
This is the person that actually builds the car and delivers it to showrooms and dealers around the world. They also need to manufacture spare parts for their cars and provide instructions on how to operate and repair the cars. They rarely have input into the design of the cars but get to decide how best to build the cars and distribute them.
This is the database developer or ETL engineer. They are often told to build a process to extract data from one system and input it into another. A lot of the business intelligence and business analytics roles are found here. They need to know about a variety of databases and datastores, about things like XML and systems integration. They will also need to know how to read a requirements document (hopefully one exists!).
If you feel that you are the type of person suited for this role then you should start learning about how to query data and move it from one place to another. Writing reports is a good way to get started, and then move into more formal ETL processing. Look for opportunities in business intelligence or business analytics and you should be on your way.
The Mechanic
When you take your car to a mechanic you only ask two questions: how long and how much. There is probably some brief discussion around each and then the mechanic goes to work. The mechanic is constrained to work with your car, as is, and cannot simply give you a new car. The mechanic cannot take your car and in less than 48 hours give you back a rocket car that would break all known land speed records. They must work with what they are given and do their best to provide you with a level of service and quality that keeps you up and running.
This is the traditional view of a production DBA. They are often asked to fix something, and are also often constrained as to what changes they can make. Some see this as a welcomed challenge and they relish the idea of being able to take what they are given and figure out a way to make it better. Think about the guys that constructed the air filter for the Apollo 13 astronauts given only the materials available on board. That’s what being a DBA is often like: here you go, fix it to be better than new, and we needed it done an hour ago.
I doubt you treat your mechanic in the same manner as your DBA, but one thing is very clear to me: the best mechanics and DBAs alike are often in high demand due to their technical acumen. Like a good mechanic, a DBA must be versatile in their skills and have some depth of experience in a variety of areas. For a DBA this often means knowing things outside of the database such as storage, networking, and virtualization.
If you think you would enjoy life as a mechanic, er DBA, then you should focus on those areas. Learn how to install and configure an instance of SQL. Understand the different storage options. Get to know how the engine works, how requests are processed. Learn how to troubleshoot performance issues (and how to deal with the pressure of finding answers, quickly).
Getting Started
How does one get started as a data professional? For most of us it is something we all gravitated towards over time. I don’t know anyone that ever said “I want to be a DBA when I grow up” and yet there are tens of thousands of us in the world. How does that happen?
If you want to get started then you need to take the first step: get started.
There are many paths to becoming a data professional. Getting there can be seen as either an impossible journey or as a journey you did not even know was happening. You start by finding opportunities to get yourself the necessary skills. There is a wealth of free training available online these days. There is also plenty of training available for a fee. I would always advise anyone to get as much hands-on experience as possible, in addition to any training offered through books and manuals. And you can always donate your time to local organizations in order to get that hands-on experience.
If you truly want to become a data professional, there are many ways to get there. Some paths may take longer than others, so you need to remain positive and keep visualizing the end result.
I think I’m a designer by day…and a hack mechanic and builder at night (volunteer work, learning, accidental DBA). I’m thinking I need to write a follow up post on these thoughts…
Karen,
A follow-up post sounds great!
This is a good post Tom. I’m pretty much a combination. My job is that of the mechanic, but out of necessity I’ve also been a designer/builder, and the librarian in me is that of a user/researcher. That part means I need to locate things quickly — in minutes or seconds. An effective design helps make that happen. So it’s a matter of work-back. Knowing what you need how quickly you need it you can then design something for the purpose to get the RIGHT and TIMELY information (especially if it’s a moving target).
Gary,
Thanks for the comment. I find that the more skilled admins out there have some experience in each area, like yourself.
Great post Thomas. I am definitely on the designer side, and my frustration is that there seems to be such a lack of good continuing education opportunities for designers. Lots of training and articles available for the manufacturer and mechanic but very little for the designer.
If anyone knows of good resources, please share.
Rob
I agree, Rob. There is a huge gap in the profession for accurate, reliable training in this area. Lots of people saying they can teach design, but what the produce is really the design a mechanic would do. It’s painful to watch that sort of design get implemented.
Rob,
I think I have a few books listed that talk about database design: http://thomaslarock.com/book-reviews/
As for continuing education, I don’t know about that. Perhaps your best bet are some courses at a New Horizons or something similar.
Great post. My goal is to become an awesome mechanic. Although the designer interests me as well, I feel I should focus on mastering one before the other.
Jacob,
I would tell you that in order to master one you need to learn about the others along the way.
What about the data modeler? I’ve worked in several large companies where the data modeler is responsible for identifying the data requirements before the database designer or DBA creates the physical design. Our role as conceptual and logical data modelers requires direct interaction with the business teams in order to identify the data needs which we view as being different from designing its planned implementation. Sometimes we have a nice business requirements document or a set of user stories to start with, but sometimes not. Our data modeling process includes working sessions with the business users to assist them in identifying their business data requirements and applying standards that result in reusable business data concepts. It is very much an iterative process. Previously, various teams would identify the same data concept and call it something different. That wasn’t so bad, but when the name is far from its intended content, that’s a problem. We now have reusable data concepts that can shorten the design time and reduce redundancy when reused. This is all done independently of the DBMS or physical implementation decision. The design DBA can jumpstart his work by using the details defined within the Logical Data Models. They are most receptive when it is a build from scratch effort.
I think in this article the data modeler is included in the designer role. Sure, logical data models aren’t system design artefacts, but they are part of the process. That’s why Tom talked about requirements, data quality, compliance, etc. In fact, he stayed away from the database lingo for the most part in this role. So we’re in there just fine.
I think logical data models deliver the most value when they are traceable to physical data models and database implementations. Not just handed over to the DBA. I work closely with DBAs to ensure that analysis and design objects are traceable to each other. I can’t separate the logical data models from the design process; they are key parts of it. The fact that we require a column is almost always tied to the requirement for that data.
I agree, and like a marriage you have to have two willing parties to make it work. So instead of handing it over the wall, we like to review our models with all parties. It’s still optional for DBAs who want to go directly to design.
I didn’t mention it specifically, but the data modeler would be lumped with the car designer for the most part.
I like the analogy. I would have to say I’m 30% Designer, 30% Manufacturer, 20% Mechanic, and 30% Shop Manager. Yes, I know that’s over 100%, but I like the first 3 roles a lot more than the last role, so I put in the extra hours to make it happen 😉
Looking forward to meeting you at #sqlsat159!