Cross charging (chargeback or recharge) is not a new concept. For instance, ITIL has always had financial management as a core component. However; only recently have many organisations seriously started examining cross charging for IT services.
Personally, I like the idea of cross charging. Cross charging forces active consideration of the 'value versus risk' proposition. Disk storage is an easy starting point: Charging per gigabyte allocated can increase utilisation by forcing appropriate application sizing. Furthermore, such cross charging raises the question of data value and brings the use of various storage tiers to the forefront.
Similarly, with server utilisation, I've been involved in several data centre transformations where scores (or even hundreds) of servers have been identified as completely unused. As the world moves towards green initiatives and data centre power and space become increasingly expensive, cross charging ensures that the application owners don't leave unutilised or under-utilised equipment on the books and in racks. Asset management becomes increasingly stringent and the overall efficiency of the environment is improved.
While cross charging for server and storage makes the business leaner and more efficient, cross charging for backups is a different story. Poorly designed cross charging for backups may even encourage bad practice. Without any sort of cross charging mechanism, there is a real chance that backup administrators will be instructed to back up everything. Log files, temporary files, operating systems and application binaries all get secured to tape every night, regardless of whether they would be used in the event of disaster. Long retention periods keep data on tape far longer than it could possibly be required. Ubiquitous 'back up everything' policies ensure that backup media are filled with valueless data.
The other end of the spectrum is even less appealing. Application owners with tight budgets could be forced to extend backup windows, decrease retention periods and reduce the volume of data backed up. As it is, in new designs, backup can often be an afterthought. Associate a cost to that and it might even get ignored.
Putting a £ value against a gigabyte backed up isn't appropriate because the underlying architecture changes depending upon your recovery requirements. It will cost far more per gigabyte to back up a 50 GB database if recovery time objectives (RTOs) demand an architecture consisting of mirror copies on high-tier disk or dedicated tape resources, versus a 100 GB database which can be backed up over the network. The design of an efficient backup environment is still more of a technical, and in some ways tactical, task.
A successful costing model needs to look at recovery rather than backup. Business units choose a service level from a service catalogue which has defined RTOs and recovery point objectives (RPOs), and each service level has a price per gigabyte associated to it. In this manner, pricing becomes based upon recovery not backup. This mechanism drives good practice from the business while it also ensures that the responsibility for recovery (rather than simply backup) remains with the backup administrators.
If you are considering introducing cross charging into a backup environment, the design of the solution shouldn't leave any opportunity to drive bad practice. Unlike your disk storage requirements, the 'value versus risk' proposition should not be a deciding factor in the design of a backup solution. Ultimately, you are not pricing a backup -- you are pricing on the ability to meet the recovery objectives in the event of a disaster.
About the author: David Boyd is a senior consultant at Glasshouse Technologies (UK), a global provider of IT infrastructure services, with over seven years experience in backup and storage, with a major focus on designing and implementing backup solutions for blue chip companies.