Just before Christmas last year I created a survey to ask you what your job title is and additionally, if you wanted, what you actually did in your job. See here for the original post.
Here are the results of the survey:
I think that clearly shows the type of people reading my blog – more than 60% are a DBA of some kind - and I’m not surprised, given what I blog about.
The “Other” values were:
11 x Consultant
7 x Database Engineer
6 x Data Architect
5 x Database Analyst
4 x Database Solution Architect
4 x Subject Matter Expert
2 x Data Analyst
2 x Database Architect
2 x Emerging Technology Expert
1 each for Chief Data Architect, Data Administrator, Database and BI Developer, Database Delivery Architect, Database Systems Coordinator, DBA for Reporting and BI, Default Blame Acceptor, Enterprise Architect, Enterprise Data Architect, Lead DBA, Network Administrator, Operations Engineer, Product Manager, Production DBA, Programmer/Analyst, Project Manager, SAP Admin DBA, Senior DBA, Solution Architect, Solutions Designer, Senior Director, System Analyst, System Engineer, System Engineer for MS Project Server, Virtual World Database Administrator
WOW!! That’s a lot of different titles for people who all need to understand some facets of how SQL Server works, behaves, and can be tuned.
Here are some of the 40 comments that people left on the original post describing what they do (with names where people put their names for all to see, but I didn’t bother with blog/twitter links this time):
David Maxwell: ‘My official title is DBA. (Which is what I voted.) My official duties are mostly production support, a little bit of assistance with stored procs and such, mostly performance related. Oh, that and, “if anyone screws up entering data, fix that too…”‘
Rob Sullivan: ‘My title is DBA. That means anything dealing with databases (performance, design, ha/dr, dev), applications or the network usually ends up at my feet. From troubleshooting firewall issues (so users can get to the db) to helping the AppDevs use their ORM’s correctly (very rarely do they take the time to learn to use them correctly on their own), I need to be on top of it. It is a large hat for sure, but I have a huge head so bring it on.’
Adrian Hills: ‘Developer: Strong focus on backend development (SQL Server & .NET) including database design, development, query optimisation and performance testing. Also work on maintenance-related scripts such as manual archiving/partitioning of data (no Enterprise Edition here!). Heavy focus in my role on the performance/scalability side of things so SQL Profiler/execution plans etc are not things to shy away from – some people feel that’s crossing more into DBA territory but I personally think it’s a very key part of being a developer.’
Gail Shaw: ‘Consultant: Meaning: If it’s even tangentially associated with SQL Server, I’m generally expected to be able to do it.
Seriously, these days it’s mostly a mix of database design, database development, query optimisation and SSIS development with occasional forays into admin (backups and configuration)’
Michael J Swart: ‘My title is “Database Developer.” My company sells enterprise solutions to colleges. Other coworkers take care of the hardware, clustering and security. Here’s an (incomplete) list of what I do.
* I’m an in-house consultant for a number of products.
* I’m responsible for the performance and scalability of the database.
* Day to day, I often audit sql scripts and schema changes.
* DB design.
* Troubleshoot when our support team determines a problem is database-side, but not hardware.
* Give lunch-and-learns for .net developers on best practices and standards.’
Matt Velic: ‘I wrote in “Data Administrator.” While there is an actual DA position, and it has to do with metadata management, my position is far beyond that. When I was given the title, it was explained to me that it was so they could give me any and all data related tasks from SQL Server administration, helping out with reports, to data entry and cleanup. It’s quite the cluster…’
Michelle Ufford: ‘I’m currently a Developer DBA. What that means, at least in my current environment, is that I primarily focus on new database development. And by that, I mean I primarily create new schema and stored procedures, with some SSIS packages when necessary. I’m a Developer DBA and not a Database Developer because I’m also responsible for things like maintenance, ad hocs, query optimization, and troubleshooting. However, backups, security, replication, etc. all fall under a different group’s responsibilities.’
Jonathan Allen: ‘I get to be a Database systems Coordinator. Not “Administrator” as that applies to a role that is lower in the Co. hierarchy than a “Coordinator”. Roles that I fulfill Systems Analysis, Requirements Analysis, Project Management, Application Development (web and .exe), Database Admin (checking backups, security, config etc), Database Development (new databases, changes to existing), Performance Tuning/Code checking other BI users, Capacity Planning and Upgrades (hard/soft ware), Liaison between ICT and MI teams, HA/DR.’
Kelly Martinez: ‘Official title is programmer/analyst. Work takes the analyst part to the max and I find myself doing everything from system administration to database development to web. The key phrase in my job description is “…and additional duties as assigned”.’
Emil Fridriksson: ‘My job title is “Senior virtual world database administrator” and I have a hard time translating it to Icelandic. I’m the senior DBA over the team that manages the massively multiplayer online game EVE Online and other projects CCP Games is working on. My duties are maintenance and monitoring of the production and test database servers for EVE Online, consultation with developers about database issues, hardware scoping for database servers, resolving customer support issues escalated from the customer support department, development of maintenance scripts, maintaining PCI compliance, mentoring the other DBAs in the team, SAN configuration, maintenance and monitoring as well as some operations of the application servers that run Eve Online. All the regular DBA things and a few that would go under developer, SAN admin or IT admin. I’m probably forgetting something.
Robert Miller: ‘Enterprise DBA, Architect, and Developer responsible for Development, QA, and Production environments of a 24×7 Social-Site Aggregator.Responsibilities include:
1) Design and implement an environment able to maintain 100% up-time (2 years and running — ignoring the painful speed-bump called Database Mirroring). This includes propping new hardware, O/S, Clustering, SAN-management, and ongoing maintenance while balancing needs with budgetary constraints.
2) Participate in all database related changes.
3) Participate in application architecture, design and implementation as DBA and Developer (T-SQL and Application code).
4) Responsible for BI-related development and support
5) Responsible for Data-Warehouse activity
6) Involved in all Release Pushes from Development to QA to Production
7) Responsible for performance issues in Production and communicating any needed changes to the development team or implementing them myself.
8) Responsible for providing a recovery mechanism if everything fails — Having valid backups helps.
9) Always on-call. If not able to be near a system, then able to coordinate activity until I am able to be in-front of a system.
10) I am certain I missed something and simply tossing in the anything a DBA, DB-Developer, BI-Developer would do or be responsible for should cover it.
I would like to include a serious jealousy of “Emil Fridriksson’s” job at CCP — See his comment above.’
John Pertell: ‘My title is DBA but like most other commenters here I wear multiple hats. I’m the senior DBA in our company only because I have the most knowledge and I’m responsible for the day-to-day management of 10 servers plus dev and testing. Because of that I’m usually brought in when other servers have issues. I do some database development work and some BI tasks. I’m probably not an Enterprise DBA since most decisions about SQL architecture (server configuration, SAN configuration, HA/DR, etc.) are made by other non-DBA managers.’
This is some really interesting reading – thanks to everyone who shared a comment on the original post.
It’s very clear that a job title in our portion of the IT industry doesn’t always equate to the actual job duties performed, and nearly always does not imply a strict boundary limit of responsibilities. There are just too many facets of the SQL Server environment and data-tier linked application lifecycle to neatly compartmentalize someone’s responsibilities and provide clear boundaries. I know the demarcation lines have been further blurred over the last few years during the general recession where companies have laid off part of the IT staff and the remaining employees have had no choice but to pick up the extra duties their previous colleagues took care of. I know there are lots of over-worked and stressed-out DBAs/whatevers out there because I deal with some of them at clients I work with. Sometimes that’s a sucky situation to be in, sometimes it makes someone thrive.
But I didn’t want this to devolve into a rant about companies over-working people. I wanted to illustrate with the survey and its results that lines are blurred.
For instance, whose responsibility is it to troubleshoot badly performing code on a production SQL Server? The DBA or the developer who wrote the code? I’d say that I hear most of the time that it’s the DBA, but is that right? Shouldn’t the developer who wrote the code have tested it under load and scale to ensure it performed well? I’d say yes. But what if they don’t know what to look for, or how to stress test it? I’d say it’s the DBA’s responsibility to help educate the developer so the developer knows how to properly QA the code before handing it to production.
To take the example a little further, what if the badly performing code is because of a design decision that a business analyst/architect made around table structures. Who’s responsibility is it to fix the code? I’d argue that the business analyst/architect should be aware of the ramifications of design choices on how SQL Server will operate and perform. Which comes down to education again.
Very often I see serious enmity between developers and DBAs because of ill-defined or implied responsibilities – or lack thereof – and people lose site of the fact that they’re playing on the same team – the company they work for.
I could boil all of this down to say that anyone involved in dealing with SQL Server needs some education so they can make informed design choices, perform proper testing, perform efficient troubleshooting, and on and on and on… regardless of your job title.
And there’s really no excuse for ignorance these days, with so much information freely available and easily searchable.
Hope you found this an interesting read!