Centralization Vs. Decentralization of DBA Teams

As a Technical Account Manager (TAM), I have seen many of our clients adopt a decentralized DBA Team.  In many cases, this is an effort to better align the DBA Team with the Development Teams.  This is an admirable and logical goal.  As often happens, you often trade one set of challenges for another.

Centralized DBA Teams

First, let’s talk about the challenges of a centralized DBA Team.  Here, the DBAs are all on a single team which is likely separated by platform.  So, you often have a MySQL Team, Oracle Team, SQL Server Team, etc.  These teams usually report up to one manager and although they act somewhat independently by platform, there is also some level of standardization in documentation, reporting structure, procedure, etc.  There are a number of benefits to this approach and a few challenges.  One benefit is having standardization across the whole of the company for how a given technology is documented, deployed, managed, etc.  Of course, this can be a limiting factor as well since there is little opportunity for customization.  Everything tends to become “vanilla” in nature and everything looks alike; from a positive perspective, this is consistency.

Consistency can be very useful.  When new members are added to the team, all servers are essentially the same.  It really doesn’t matter what the application is, a new team member can become proficient very quickly across the whole of the infrastructure.  Lessons learned on one set of servers translates very well to another set of servers supporting a completely different application.

As noted above, however, this is also a challenge.  What happens when a particular application needs something different?  Breaking the norm is the antithesis of consistency and resistance is met from team leadership.

Another challenge is that often the DBAs are supporting so many different technologies that they are challenged to fully understand the application and how it works.   There are just too many applications to become intimately aware of each.  In this case, DBAs are often more reactive rather than being proactive and becoming advisers to the development teams.  This is quite common in larger enterprises that have many diverse applications.

Decentralized DBA Teams

To combat this, many enterprises adopted the decentralized model and break the DBA Teams up into smaller teams aligned closely with the development team.  This seems to make much more sense in many ways since the DBAs will be laser-focused on fewer applications and work much more closely with the developers to ensure an improved solution.

So, what is the issue with this approach?  There are always trade-offs with any approach.  If there were one clear winner, everyone would just use it.  One of the largest challenges I have seen as a TAM with decentralization has been the lack of standardization.  Each DBA team acts virtually independently from every other team.  Problems that once were solved once and for all are suddenly being faced in parallel by multiple teams.  As a result, teams are often “re-inventing the wheel” each time they are confronted by a challenge that may have already been resolved by another team.  Without strong internal communication, teams are wasting time looking for solutions that have already been found.

This is one of the most fulfilling aspects of my role as a TAM.  I am in the unique position of often meeting with multiple teams and socializing these solutions across teams.  I am often asked in meetings with my clients whether I have seen this issue with another team or even another client.  If the answer is affirmative, the next question is obviously about how they resolved it.  Experience wins the course here and provides significant improvement in time to resolution of the issue.

Another challenge I see pertains to consistency.  In decentralized teams, DBAs will sometimes move from team to team as demand for resources changes.  In such cases, new team members require significant time to get up to speed on systems as consistency has been compromised due to each team doing things differently.  Installations may be in different directories or folders on the servers, documentation may be better or worse, and so on.  With no centralized oversight of standards, moving to a new team can slow the process of getting the DBA up to speed.

Communication is Key

Whether you decide to keep a centralized DBA Team or to decentralize the team, some level of consistency and communication are critical.  If you chose to decentralize the DBA Team, be sure someone is acting as a centralized resource, such as a TAM, who is looking for patterns of issues and working to find proven solutions.