Skip to Content

Archiving: it’s so hot, watch you don’t burn yourself (part 2, or: more fiery debate)

In my last post I talked about how archiving is actually a hot technology right now – delivering very real benefits to SAP customers – even though its powers to improve performance, reduce costs and increase compliance are not always given full recognition.  Here I want to explore why archiving projects are sometimes hard to get off the ground – and provide a little advice on how to get things moving, including building a business case.

Archiving is actually recommended by SAP as a key part of any implementation project, but I believe it suffers because it usually gets left to the end of the project – by which time the business has run out of time, money and inclination.

Then, when the possibility of archiving is raised again, it often becomes an issue of ownership. Usually the IT department will see the benefits – and will be aware of the impending problems of failing to introduce archiving: creeping response times, batch overruns, query timeouts and so on. But IT management has difficulty getting buy-in from the business – because things like performance, storage costs, upgrade timescales and so on are seen as the responsibility of IT, not the business departments.

The fact is that business users do need to ‘buy in’ to archiving at some point because they are the ones who will have to determine what business data can be archived, and when. And ultimately, if the business fails to budget for archiving, it is the business that will suffer. For example if the buildup of data in the live SAP application causes slow response times it will ultimately affect service and productivity. Likewise, if the system is unavailable due to a prolonged restore from backup this could have a disastrous impact on core business functions such as sales and order processing.

Getting started 

Of course you don’t want to wait until a problem strikes before you start, so the best way to move forward is to look for quick wins. A simple Health Check of your database will show you immediately which applications are generating the most data: a good place to focus. For those applications look for single tables to archive and avoid areas that have complex business processes – you can tackle those later. You could also start with technical tables as they have little impact on business users.

If you break archiving into bitesize chunks in this way you can start delivering positive results very quickly, which will help you get the rest of the business on board. This approach also de-risks the project and allows you to build up your skills and knowledge as you go.

Developing a business case

There will always be competing priorities, so no matter how essential your archiving project it still needs a compelling business case in order to propel it to the front of the queue. This should be based on three things:

1) The total volume of data you can take out of the live system and move to cheaper archive storage, both now, and in the future.

For this you need to consider not just the live system but also remember that additional system copies – such as pre-production, test and development systems – can easily triple or quadruple the total volume of data stored. It is also important to think about the age of the data – and how long you really need to keep it available for updating. Remember, archived data is still online and accessible, it just can’t be changed.

2) The storage savings that will be generated, based on the true cost of both purchasing disk and administering it.

It’s easy to overlook all those additional costs – including the people, storage, hardware and so on, which collectively account for more than three quarters of the total cost of owning the disk.

3) The impact of reducing the size of the live database on performance factors such as online and batch response times; length of scheduled downtime (and associated business risks) for upgrades, application of service packs, and so on, and the length of downtime (and associated business risks) for unscheduled events such as recovery from backup in the event of a system failure. 

Performance factors may be harder to quantify in monetary terms but it is really important to take them into account. After all, a looming performance issue could be the important business driver that makes the archiving project finally happen. The easiest way to flag up any potential issues – such as tables reaching their performance limits – is to undertake a Database Health Check. See how Macro 4 runs a Health Check here.

In a follow-up blog I will run through the principles behind my Value Calculator, which helps you to work out your current storage costs and your likely savings once you start archiving.  

Be the first to leave a comment
You must be Logged on to comment or reply to a post.