Let’s start by defining data. In his book Programming the Universe: A Quantum Computer Scientist Takes on the Cosmos
Now let’s talk teams. Different companies do it different ways, but generally speaking you’ve got server/storage/system admins, DBAs, developers, and QA. Developers are generally fairly close to the business; through analysts or project managers they take the high level requirements and turn it into applications. As such (and as many DBAs may notice) they have a lot of pull with the business and in some cases are more trusted as technical experts than the DBA team. QA teams are also usually grouped either close to the development team or close to the project manager/business analysts. Behind the scenes you’ve got your DBAs and system administrators; at times stereotypically seen as a crew with big heads and bigger egos, making cowboy changes in between rounds of video games.
Data is one of the most critical corporate assets and is at the forefront of modern technology requirements. Its distribution and management is an integral process for a company as a whole and for nearly every project that comes down the pipe. Yet at many companies (certainly not all), the DBA team is seen at best as a final dumping ground for project requirements and at worst as an obstacle. Either way, the DBA team is a custodian of the data, central to every IT group and the business itself. We manage over environments that are perceived as shadowy and obfuscated, highly complex and prone to failure.
If that is the case for your team, it needs to change. The best way to do that is by taking a close look at the goals of the DBA team.
Know your client and make sure they know you
Many of the non-consulting DBAs I speak with describe their job as a support role to developers. This is a dangerous stance to take. When I think of a ‘support role’ I think of a person sitting in their cubicle incessantly starting up and shutting down databases, taking action only when prodded by the development team or management. Unfortunately, this describes a person who is highly expendable.
As DBA manager your team should of course support the organization, but less like support staff and more like consultants. Your client is the business. When a project comes down the pipe, make sure that it doesn’t land on your desk as requirements. Instead, try to be part of the architectural process. Play a part in making the requirements. Make sure your client, the business, sees your team as a valuable resource, crack specialists who understand their content and their needs. Only with your team’s leadership and help can that data be managed and served in the most efficient manner possible.
Think of it like an Oracle environment. What is a database? Just files on disk, capable of nothing. They store information without description, data without goals. Only by starting an instance and mounting that database does the data begin to flow and take on meaningful purpose. Your team should be the instance. You have the knowledge, the processes, and the experience with the database that your client needs to harness.
Above all, make sure each of the DBAs on the team feel that empowerment. Taking in requirements and passing them down to DBAs leads to rote work and a sense of uselessness. Instead, encourage the DBA team to interface directly with the business as technical leads. Your team will end up owning the issues if a query performs slow or data is lost anyways. So make sure they own the process and productivity required to bring a project to fruition as well. Help them become invaluable to their client.
The problem may not be in the database, but the database is part of the application
If I had a Flainian Pobble Bead for every time I’ve heard a DBA say “It’s not a database problem” I’d be a hyperrich man. These words are generally uttered when a problem escalates to the point where people are scrambling to find an issue with slowness. Other phrases you might hear around the same time are “it worked in QA,” “that code has been there for X years,” and “maybe you should increase the SGA.”
Yes, the problem could very well be rising concurrency or data volume. Yes, queries might be dynamically generated and resolving sub-optimally. And yes, some ad hoc query might be eating up your processes and RAM. Absolutely dig for that root cause and absolutely report on it. But not as a way to shift blame; instead, do it as a way to own the solution.
Look at the problem from the client’s eyes: a query may be written by developers, but it is run against a database. An index might be missing, but it’s missing from the database. The server might be out of resources or encountering slow disk reads, but it’s manifesting through the database. Yes, Virginia, it is a database problem.
While this puts you in a bad position when things go sour, it also gives you an outstanding opportunity to own both the problem and the solution. Even if there is nothing you can do about it, your team can express their mastery over their domain by assisting with diagnosis of the problem and delegating tasks and research questions to the appropriate teams. The DBA team is not at the bottom of the development ladder, but at the center of it. Projecting that image both when times are good and when times are bad is very rewarding to the business and your team.
Focus on solutions
DBAs are a fairly vocal bunch, and at times critical of other groups. Because we are the hub of data management in a company we get to see every bottleneck along the path to production or problem resolution. And, quite frankly, this can make some DBAs a little jaded. And said DBAs might be inclined to discuss it. Publicly. In meetings.
Work with your team to focus on solutions, not problems. Sitting in a meeting discussing the reasons why something happened are not productive, particularly when it is already known where the root cause lies. This one seems very obvious, but I see it happen on a daily basis. Some people just need to complain about their aches and pains. Instead, they should be offering the elixir.
A problem should be described once. A solution should be pored over and evaluated constantly. Work with your team to focus on talking about what can be done, not what happened.
Conclusion
Data is a complex topic, and has made its way to the forefront of the minds behind your business. As the team who architects, maintains, protects, optimizes, and coordinates the flow of data the DBA team has the ability to play a powerful central role in product development and management. If your team has been relegated to a backend support role, asserting your team’s knowledge of business needs surrounding data can be a huge boon to both your position and that of your DBAs.