When it comes time to consider refreshing the hardware in your environment, do you want do do it quickly, or properly?
Because here’s the thing: If you want to do it quickly – if you feel rushed, and want to just get it done ASAP, not seeing the point of actually doing a thorough analysis of your sizing and growth requirements, here’s what you do:
- Guess at the number of clients you’re going to backup.
- Guess at the amount of data you’ll be backing up from first implementation.
- Guess at the growth rate you’ll experience over the X years you want the system to last for.
- Guess at the number of staff you’ll need to manage it.
Then, once you’ve got those numbers down, multiply each one by at least 4.
Then, ask for twice the budget necessary to achieve those numbers – just to be on the safe side.
If you think I’m joking – I’m not; I’m deadly serious. Deciding to skip an architecture phase where you actually review your needs, your growth patterns, your staffing requirements, etc., because you’re in a hurry is a costly and damning mistake to make. So if you’re going to do it, you may as well try to make sure you can survive the budget period.
And if asking for that much budget scares the heck out of you – well, there is an alternative: conduct a proper system architecture phase. Sure, it may take a little longer to get things running, or cost a little more time/money to get the plan done, but once you’ve got that done, it’ll be gold.
I concur with what you’re saying, but I think that cases like this are actually a symptom of a larger problem.
I believe that organizations find themselves in situations like this – designing a recovery system based on WAGs – because a) they are in a situation where they must upgrade/migrate/redesign *right now* because the proper long term planning has not been done and some constraint (hardware or software is at end of life, or has failed, etc) has fallen on them, and b) the data that is needed to design a recovery system has never been collected and/or tracked.
In other words, I don’t think anyone would actually choose to rollout a system based on process described above, though I think it happens a lot. Rather, folks get put into these situations because of inadequate systems management. In fact issue b) is really just a specific example of issue a).
This is one of those situations that highlight the differences between a “Systems Administrator” and a “Systems Engineer”. An engineer is all about collecting and analyzing data, and most of the ones I know (including my wife) never have enough hard data to suit them. I’m not trying to knock the SysAdmin role, there are never enough good SysAdmins around, but the two roles should not be confused. Unfortunately, I think the distinction between the two roles is lost on most upper management types. All too often the design of systems are dropped into the lap of someone whose job focus is on taking care of today’s issues.
Anyone that finds themselves in this situation for *any* of their systems, not just the backup environment, should take a hard look at how the environment as a whole is being managed, as this is an indication of some serious deficiencies.
Hi David,
I couldn’t agree with you more. My point was certainly not to encourage people to take that approach (multiply requirements by four, then budget for said requirements by two), but to encourage people in that situation to step back and see the need for better systems management approaches. I was just being tongue-in-cheek about it 🙂
Cheers,
Preston.