Service catalogues are sometimes seen as an unwieldy way of introducing order with a substantial risk of introducing red tape. That being said, I’m a big fan of them for backup and recovery systems, and not because of some weird fetish for bureaucracy.
Like ITIL, I’m firmly of the opinion that service catalogues get such a bad rap for many IT workers because they’ve experienced a poor implementation at one or two locations they’ve worked. Service catalogues only need to be as formal and/or as complex as the needs of the individual organisation. So that means a small company with say, 50 employees can likely have a radically simpler service catalogue definition than would, say, a multinational with 50,000 employees.
It’s not uncommon to review the backup environment for an organisation only to find there’s no central theme for backup configuration. This server gets full backups every day with backups retained for a month, that server gets full backups weekly, incrementals the rest of the time and backups kept for six weeks. That other server looks to have a good configuration but it hasn’t been added to an active group. And so on…
While service catalogues don’t guarantee avoiding a mixed-up configuration, they do set a certain base level of order in the same way a standard system build or even a document template does. This works in a number of ways, namely:
- It allows backup administrators to have a standard definition of exactly what configuration should be established for any given service catalogue selection
- It allows the business group booking the backup function to clearly understand exactly what level of protection they can expect (and hopefully what SLAs are included as well)
- It can help in capacity planning
- It allows exceptions to be more easily captured
The first item above helps to eliminate human error. Rather than relying on an administrator or operator choosing options at the moment when configuring backups, he or she knows that a particular service catalogue option requires a particular set of configuration items to be put in place.
The second item allows the business to be more confident about what it’s getting. There’s no excuse for believing in platinum-level service when a bronze-level option is chosen, but more importantly, the business unit booking the function can more clearly understand the value of the different levels.
There are two distinct aspects to capacity planning – knowing growth rates, and knowing service requirements. Growth rates are the relatively easy things to capture: a few mminfo reports run regularly, or periodic interrogation of your NMC reports will tell you what your month-on-month growth rates are for backup. What won’t be as immediately visible perhaps is how that growth breaks down between say, production systems and development systems, or high priority systems and low priority systems. Assigning service catalogue units to individual hosts (or applications) will allow a better understanding of the growth rate of the individual sorts of service options you want to provide. Month-on-month you should be able to see how many platinum or production (or whatever names you use) systems you’re adding. Particularly in situations where you’ve got tiered backup targets, this is essential in understanding where you need to add capacity. (In short: knowing your backups are growing at 2TB a month is pointless if you don’t know whether that’s 2TB of backup-to-disk, 2TB of tape, or some mix between the two.)
Finally we get to exceptions – and these are exceptionally important. (Excuse the pun.) Any system that’s designed to be rigorously enforced to the exclusion of any variation at all is just going to be a fount of pain. Key systems might get missed because they’re not compatible with the service catalogue, or just as bad, business units might deploy competing data protection systems to suit their specific needs, drastically increasing operational cost. Therefore, the solution is to have an exceptions system which allows variation to the standard service catalogue items but in such a way these variations are clearly:
- Justified,
- Documented, and
- Costed
Ultimately service catalogues for backup and recovery systems (and data protection more broadly) aren’t about imposing rigid rules, but allowing for faster and more accurate deployment of carefully planned protection models. Any sensible business would only consider this as being a valuable and useful approach to IT/business insurance strategies.