It’s that beautiful time of year when everybody watches the colors. No, not the changing browns and reds of the foliage, but the red and black numbers on P&L statements. That’s right – it’s budget time.
In order to build a good database budget, we have to ask our managers a few key questions:
Are we going to archive old data, or keep it online?
Database growth can be controlled by keeping a limited amount of history in the database. As DBAs, though, our job isn’t to limit the business, but to give them options. The business can decide whether keeping more data online is worth the additional expenditure for hard drives.
Example: take a data warehouse with 3 years of history. Near year-end, DBAs may be tasked with pruning this data out, but users often complain that they’ve decided they want the extra data online forever. Budget time is the perfect time to present this question to the end users. If the warehouse needs to go from 3 years to 4 years of storage, that’s an increase of 33%. Take the current storage costs, add 33%, and present that as the cost to keep an additional year of history online. Every year, recalculate storage costs and ask the same question again.
Include backup costs in these calculations, too. A truly savvy DBA will organize their filegroups so that old, historical data lives on read-only filegroups that rarely get backed up, but if we were all that good, we wouldn’t be having this conversation.
How has sales growth changed over the last year?
Database size can sometimes be changed based on business growth. If an e-commerce book store sold 15% more books this year than last year, and if they expect to grow by another 15% next year, then that’s a lot more transactions and customers that have to be stored in the database.
I’ve found that it’s easier to budget by past growth instead of future predicted growth because – well, let’s face it, predictions are hard. It’s much easier for a manager to understand and agree that we’ve already grown by 15% over the last year, and that our infrastructure has to keep pace.
Has our company headcount grown this year, and what’s the projected growth?
If a database application supports 1,000 users, and the company projects a growth of 5% next year, then that’s 5% more users that the application has to support. Granted, most applications are built in a way that scales easily, but big growth happens fast. Changes in headcount give DBAs a clear, concise way to show why their hardware has to be able to support more load.
What pilot applications are being rolled out to more users this year?
In small to midsize companies, database administrators aren’t always brought into meetings early enough during the planning phase of application development. Proof-of-concept applications become pilot applications, which become widely-rolled-out applications. At budget time, survey the landscape to see which small applications are loved by the users, and what kinds of wide adoption their managers expect to see.
This is where being a DBA gets hard: database servers are often shared between multiple applications. Being a good DBA means knowing what percentage of the database server load is being consumed by a particular application. A new application might be a nasty resource hog, and it’s not obvious until the number of users scales up. Now is the time to run profiles and performance logs to get insight into each pilot application. The more a DBA knows about each pilot application, the better job they can do budgeting for the future.
Finally, what more could you do with more time?
Make a list of day-to-day and month-to-month DBA chores that are getting overlooked due to a lack of time. Everybody has them – whether it’s fire-drill test restores, performance tuning, or even plain old career training. Give management a list of things that the department could accomplish with one or more additional head count. The list should be unbiased, matter-of-fact items, not “give me another body or I’m going to die.” The less emotion and the more raw facts the list includes, the easier it is for managers to forward it on to their managers and get approval.
Even if another person isn’t needed, make the list anyway. That way, a year or two from now when the department really does need another DBA, it’s easy to compare last year’s list with this year’s list and see that the company’s needs are changing.
