Is the SQL Server market ready for the idea of “shared DBA services?” No, I’m not talking about traditional consulting, and I’m not talking about traditional remote DBA offerings. I’m talking about a blend of several different ideas and offerings. Later in this article, I’ll add more to the definition of shared DBA services, but for now, think of it as permanent part time. Imagine a large company employing an internal “consulting DBA team” in which each DBA on the team spends 25 percent or so of his or her time working on regular, internal projects. No, the idea isn’t novel. Yes, it’s been done. But the idea isn’t commonly implemented, and I wonder whether it’s a better way for more organizations to think about DBA services?
Here’s why I’ve been thinking about shared DBA services. Lately, I’ve run across numerous customer environments in which, to be blunt, I feel the customer’s state of readiness for handling core data-platform management and development issues puts essential strategic initiatives of the business at risk. I’ve seen this problem with customers I’ve worked with, have heard about it from trusted colleagues, and have heard about it third-hand. I’ve been a consultant for 17 years, so I’m not naive. I know that consultants wouldn’t exist if all customers had the perfect ability to meet all of their needs with internal staff.
However, recently I’ve had the sense that more businesses are being exposed to greater risk because of their lack of readiness, and that the problem is getting worse, not better. Over the years, I’ve had the opportunity to address many aspects of this growing problem. I’ve talked about the role of the data-tier architect and the need for specialization over generalization. And I’ve pointed out that as products get more complex and powerful they help us solve more complex and difficult problems, but at the same time, managing and using the products properly becomes increasingly difficult. It’s an interesting conundrum, and I’m glad that I can just write about it rather than be responsible for solving the problem entirely.
So I find myself wondering whether shared DBA services would address part of the problem, at least for data environments, and I wonder whether similar shared services would work in other technology slices. The essence of the problem, as I see it, is that proper use of certain tools, such as SQL Server, will occasionally require a level of product mastery that’s difficult to obtain, requires constant practice to keep sharp, and, to be blunt, is rarely needed full time in a typical corporate IT environment.
I’m a good example. Most of my billable hours are for delivery of performance-tuning services. The fact is, for many companies, it wouldn’t be cost effective to have a full-time performance expert (or a super high-end DBA of any stripe, since most expert DBAs have good tuning skills). But it would be practical for many of those companies to have one “super-expensive-high-end DBA” whose services would be shared by 3 or 4 projects.
Again, I know this isn’t a brand new idea. Companies have done it in the past, and think it was actually more common a generation ago. However, the initial ease-of-use of client-server databases allowed development groups to cast aside the internal corporate DBA teams in favor of faster, more nimble development. But will the growing complexity of SQL Server, which increasingly requires specialization of skills, coupled with the growing risks associated with of “getting it wrong” make the idea of shared DBA services commonplace again?
Remote DBA services (i.e., DBA services provided under contract and delivered through a VPN or other remote mechanism) add value in certain obvious ways. But although remote database administration might be a good choice for some matters, other matters really require sitting around the table with the development team you support. Consultants add value (at least that’s what I tell my customers), but most consulting relationships are transient in nature; and sometimes permanence is helpful as you sit around the table with the developers you support. Some companies might not have enough projects to support the shared-DBA approach, so perhaps some consulting companies could offer shared DBA services that let you “buy” 25 to 50 percent of a high-end DBA under terms that are closer to long-term employment rates than consulting rates.
What do you think? Are more and more companies, being exposed to more and more risk as products get increasingly complex? Do ‘shared’ IT services make sense? Send your thoughts to me at [email protected].
