Tinker, Tailor, Developer, DBA

Tinker, Tailor, Developer, DBA is not intended as a pitch on a slightly less harrowing book or movie than the John Le Carre classic.   Rather, it is a consideration of the career progressions of those working in and around SQL Server and how that progression and interaction has evolved in the past ten to fifteen years.

The phrase comes from the English children’s counting rhyme that originated who knows when,

Tinker, Tailor, Soldier, Sailor, Rich Man, Poor Man, Beggar Man, Thief…

The idea was to recite the rhyme while counting some objects and your fate was determined by where you landed with no objects remaining.   The variations and evolution of the simple rhyme are interesting but my point is that many careers are similarly determined in the world of SQL Server.  As chance takes us from one position to another, filling one void or another for a particular posting, the industry itself is also changing as the interaction between DBA and Developer has evolved.

For context, the reason I am exploring the subject of SQL Server career evolution and how people in various stages may interact with those in other stages (some coming full circle once or twice) comes from previous blog postings:

• DBAs and Dinosaurs – an exploration of whether DBAs are becoming obsolete, and why I believe they are not and never will be despite multiple predictions of the demise of the profession
• Accidental, Unintentional, Reluctant, Conscripted – an exploration of how many DBAs fall into the profession with the initial step often being by chance or at least someone else’s choice. Spoiler Alert: the initial steps in many careers are caused when management comes to grips with the fact that an actual DBA is needed after all. (Maybe management bought into the myth of the self-managing database or the supposed demise of the DBA role mentioned above, until some crisis or cumulative complaints made the need obvious.)
• DBA Team Collaboration – an exploration of how DBAs interact with other DBAs or with other stakeholders in the applications, systems, storage, and networks that are part of the greater IT ecosystem that the database supports

That IT ecosystem I reference inevitably seems to involve developers of some sort.   And, not coincidentally, in the SQL Server space at least the DBA to Developer interaction has increased with each passing year as has the number of people moving between these two disciplines over the course of a career.

Over 69 percent of you responded in our Accidental DBA survey that you either currently considered yourself in that category or started like that but now considered yourself and experienced DBA.  That number rises to over 75 percent if we add those who took the same career path but sought it out purposely.  And the majority of those reporting seem to have come from some sort of development background.

Back in the Day

Feel free to skip ahead if tales of technology yore grow tiresome to you, but I wanted to explain why this evolution of both the career progression and the accompanying internal team interactions interested me.

DBA to Production DBA

There was a time when all DBAs were effectively “Production DBAs” to the point that no one felt the need for a different term for “production DBA.”  This time largely predated the emergence of SQL Server as a viable enterprise database, so many of you may not relate.  Oracle, Informix, and Sybase ruled the open systems RDBMS world and DBAs largely managed things in the same ways the IBM DB2 DBAs had managed mainframe databases.   Everyone respected the arcane rituals of backups, artful storage allocation for performance, index allocation, and statistic maintenance practiced by these specialists and no one would think of implementing a database without an experienced DBA to maintain it.

There was little direct interaction between the developers and DBAs of this time and DBAs were charged with tuning databases for maximum performance for the applications that life dealt them.  The separation of duties and IT organizational structure somewhat dictated this reality.  But the DBA controlled most of the database related environment directly including storage and servers.

But some either suggested tuning the application for better use of the database or bridged the gap and established themselves as “Development DBAs” to help developers write more efficient code for database access.

DBA Specialization

As time progressed and SQL Server gradually pushed its way into the enterprise application world with each new release, so did the specialization of DBAs in large organizations.  There were Application DBAs who either helped developers tune code or tuned application performance in consideration of how the database engine actually worked.  But the specialization meant someone else, the Operations DBA, needed to make sure the housekeeping was maintained, backups were ready, instances were up, patches were maintained, etc.  And hybrid Developer-DBA or DBA-Developers were cultivated to avoid the need for the Production DBAs to suggest changes to SQL statements or other load tuning advice.

But while the DBA expertise spread itself into different parts of the IT organization, these parts were still somewhat isolated in many cases and sometimes at odds with each other internally.  (Sometimes I felt like a confessor listening to different parts of customer organization vent to me about each other.)

Losing Control

The unifying factor for some of these DBA specializations was the gradual loss of control of their environment.  Storage virtualization, then system virtualization emerged as threats that took control of things DBAs were used to controlling and using to manage database performance. The DBA still had responsibility for database performance but less control over things that impacted that performance.

Vendors sold tools that purported to “eliminate finger pointing” when in reality they were being used to “optimize finger pointing” by monitoring what they controlled ( “it is not my fault”)and preferably those things around them as well that were out of their control (“it must be his fault”).

Back to Modern Times (Rise of DevOps)

About 7 to 8 years ago, we began to hear hype around a buzzword called DevOps which purported to move from a world of isolation and separation between production and development to one of continuous interaction and improvement.  My personal experience at the time was that the idea was as mythical as a unicorn because the hype did not match the reality among my customers.  I am sure someone somewhere was implementing these ideas, but none of them seemed to be in large enterprise level organizations.

SQL Server and the Reality of DevOps

The unique thing about the SQL Server platform compared to the other RDBMS competition during all these changes was Microsoft seemed to embrace the changes other platforms resisted.  Virtualized databases are one example of such a move.  While databases as a whole seemed to be the last thing to go virtual, the first databases to go virtual were always SQL Server.   And now it seems to be the rule more than the exception.

In like fashion, probably because of the number of SQL Server DBAs being either explicitly or “accidentally” being recruited from the ranks of developers, SQL Server seems to be at the forefront of DevOps even by companies that are not trying to implement DevOps.

And Now to the Point!

Just as SQL Server DBAs are being minted on purpose or by accident from being thrust from developers into DBA responsibility, many are being called to increase interaction with developers to improve database and, by extension, application performance.

That means we encounter more people every day who have been working in various capacities around databases, in particular SQL Server databases, through a career.   And the line between these roles is blurring.

Developers morph into DBAs while expected to continue to help development, but become overloaded with production responsibility.  Production DBA specialists are brought in to help bring a sense of consistency and order, but are expected to provide continuous performance feedback to application developers to suggest performance improvements.  Developers or other IT administrators are forced into temporary “DBA duty” to cover for DBAs on leave or overworked in general.

All these hypothetical career situations are not really hypothetical at all.  I am encountering these tales with increasing frequency and have come to the conclusion it is all a good thing.  As DBAs are forced by career or responsibility to expand beyond the old specialist silos, communications and understanding is increasing for all.

How Idera Can Help

These observations may be more or less interesting to you based on your personal experience.  But as your career progresses you may yet find yourself in one of these situations, moving to or from a development role or being required to more efficiently collaborate with developers or application performance specialists.

A few things Idera offers or is developing can help you navigate the changing career waters of the SQL Server DBA.

• Free Tools to get you started.   If management is slow to recognize the need for a dedicated DBA then they will be slower to recognize the need to purchase tools to help that DBA.   The newer you are and the more challenging your environment, the more you will need to purchase tools for certain tasks.   While you build the case, get started with free tools from Idera.
• Community to learn. Idera supports the SQL Server community, user groups, and SQL Saturday events to help you help yourself.   If you keep us in mind when you start choosing tool vendors then that helps us help you.
• Tools to Automate. Some of the biggest proponents of automation tools I know are experienced DBAs who have tried to develop and maintain their own tools in the form of scripts.   It is a good thing to learn how to write and use scripts to manage your environment; it is a bad thing to be required to do so.   We all had to learn math to get through school, but most of us d not turn up our nose at purchase of a calculator.
• Embedded Best Practice.   Need to know what things you need to monitor for performance, or security, or backup, or how to do it?   Our tools get you started with best practice defaults that you adjust to your needs and environment.
• Common Perspective for Collaboration – Our tools have embedded capability to facilitate collaboration across and within teams with features such as Newsfeed.   But it also helps to short-circuit the finger-pointing game if you have a common perspective. Our tools integrate with other monitoring products, including SCOM, so everyone can start on the same page.