How do other other companies, particularly P&C insurance companies, approach the data retention piece of application retirement? Based on some preliminary research and speaking with industry analysts, it seems like there are two major approaches:
1) Copy everything in it's original format, including the application code, in hopes that the app can be recreated if the data are needed (because just relying on data backup is not sufficient to put the needed information together);
2) Extract the data you believe you may need into a browser-readable format (e.g. XML)
Both of these approaches have limitations and/or are cost-prohibitive. Of course, the other alternative is to not retire at all, but cost savings through app retirement may be mandated anyway.
I'm not so concerned about the actual storage part - I assume we'll have tiered storage based on retreival expectations, and will have to revist storage every few years. I'm most concerned with the format and usability of the data.
Any insights would be welcome, but I am mostly interested in hearing about actual implementations of solutions (with pros and cons).
Thanks!
Jay,
Companies have in-fact been retiring application data successfully for decades.A lot today depends on the nature of the application, data, its formats, future retrieval requirements for business usage as well as potential legal discovery subpoenas,etc. But the most common and successful example that you will find in the working world today & in production is found in the financial services industry/broker dealers specifically,within their COLD systems.Yes the systems (Computer Output to Laser Disk) that replaced microfiche, & stored lots of data on optical (there was a need for WORM due to SEC 17a-4 requirements for Books & Records),& finally moving onto spinning disk (once CAS technologies made WORM on spinning disk a reality) to retire the optical platters. An example; have you executed a trade with a broker in the last 10 years? That broker dealers back-office staff can locate that trade and all of it’s details (Cusip, Amt, Date, etc.) with a few clicks of a COLD application. The data is more that likely neatly stored as a 132 column ASCI report (mil or so pages depending on the size of broker dealer) and accessible/readily online for viewing, exporting, etc. Now,this is where your requirements come into play, in my example above the data,the application and any “context” associated with the data is totally separated.Note that the front office trading application that processed that 10 year old trade has long been "retired";the firm has replaced the front office trading applications 2-3 times since.But the data from each application instance remains secure & readily accessible to anyone who needs it, its even available for historical analysis and trending across other pools of similar data,& in some cases firms even use these systems to package and sell “retired” application historical data. So the proof is in the pudding, retiring "data" from applications is well understood. Now,the twist, do you need the application to view the data? Can they be separated? Take a simplistic .wk1 file example,do you need Lotus 123 running on DOS 5? Is there a 3rd party Symphony macro embedded in the .wk1 file that is needed to understand the “context” of the data. These are where you have concerns & need to address the particulars on a case by case basis – [if] they are truly important. I recommend taking a very common sense technology approach,because there are no magic bullets to that .wk1 file example. So first you want to look at that application you are retiring much like the trade executed within a trade entry system, what’s important down stream? Looking up the data associated with a trade (well understood deployable technology today) or do you really need the front office trading system to be online in order to view the data,with its full context? Then a backup and restore approach may be part of your answer. Some companies keep h/w and retired s/w and pay extended maint. for the s/w and OS support-just in case they have to access an old record, & the problem is really with old style app development where everything was so tightly coupled that data and application and context cannot be decoupled. Another sample of “context” could be rich formatting within a document. Rich formatting can completely change the “context” of a document,imagine the text “meet me now” in courier 10, now imagine “meet me now” in 48pt BOLD, Arial Black, Underlined – if you are presenting this data as evidence in a jury trial, the “context” would certainly be important, possibly critical. So, lots to consider,but there are many good useful examples to be found in various industries. SEC 17a-4 for Broker Dealers is probably the most well known for keeping “stuff” around with the “just in case” we (the SEC) asks requirement. And since firms had to keep the data around, the systems built around it not only met the regulatory requirements, but figured out how to re-purpose the data so its useful, and not just sitting in a closet.
Good Luck
Peter
January 2008
