Shelly gave some very important points in the previous posts about pre-built data archiving solutions and how they can impact your application retirement plan and you business in general.  I would like to take a few minutes to convince you that there is a very strong technical case against using one of the "turn-key" data archive products.

Algorithms + Data Structures = Programs.  Not only is it the title of a classical tome that should grace every Computer Science nerd's bookshelf, it is a fundamental principle that underlies all of computing.  Data Structures are coherent, structured sets of data.  Like patient records, with names and account numbers and discharge dates all that good stuff.  We all know pretty much what the data structures are for our industry.  Some of the data structures are just common sense: if you want to charge a patient, you ought to know where to send the bill, so we track billing addresses.  Some of the data structures are mandated by our current socio-political situation: we track NPI and SSN, and a host of other seemingly random strings of numbers that the government says are important.  Some of the data structures are included in applications by people who "know what they're doing" (and most of the time they do -- nothing acquaints you with data quite like writing an application to manage that data).

So we have all this data.  Gigabytes.  Terabytes.  The old system is going away and we're going to save a lot of money when it does.  Now it's just a matter of finding somewhere to put the old data, right?  Well, yes and no.  Storing the data is only half of the equation.  After all, we aren't just retiring data, we're retiring a program -- the data and the algorithms that work on the data.  There is no such thing as a one-size-fits-all algorithm, even when it comes to simple data.  Even algorithms that do the same thing, such as sorting a simple array of data, can have very different properties (time complexity, space complexity, stability, etc). If you want to preserve any level of non-trivial functionality, you have to have bring the algorithms along for the ride.  Otherwise we could just write it all to tape and be done with it!

So why doesn't a pre-built "turn-key" application solve the problem?  Well, it's pre-built, for starters.  That means it's done -- it was written before the vendor ever knew your company's name, much less the particular characteristics of your data.  The algorithm is what it is and the way they will make it work is to fit your data into their mold.  They'll tell you that data mapping is different from a conversion.  A first name is a first name, right?  So they just map it over and move on.  But what happens when you have data that doesn't fit the mold?  What if your system keeps track of names and aliases?  How will the Data-Archive know the difference?  Will it let you go automatically from an alias to the actual account number?  What about complex, recursively defined reports that don't fit well into the relational database model?  That's where the "we'll find a home for it" answer just doesn't cut it.  Sure it can be stored, but that isn't a solution.  It used to be queried and viewed in a particular manner, through the filter of the algorithms that performed whatever function the data was intended for, be it a simple search or an intricately detailed patient data summary.  In order for the data to remain useful beyond the life of the application, it must be usable in the same way so it can support the same activities and decision making processes that it used to.

So how is Legacy Data Access different?  I'm glad you asked.  The main difference is that we don't write a line of code until we have your data.  We look at the data and figure out how it needs to be represented and delivered.  In essence your data and your processes dictate what the end result looks like and how it behaves, making it a much better fit for your data.

If I stopped describing our process here you might think the project would take forever.  The truth is that, not only is our solution driven by your needs, we can implement it faster than the competition.  We've been doing the same thing for the last ten years.  When you do something for that long you tend to get good and doing it.  We have a custom, flexible, open-ended application framework designed specifically for creating applications to house retired data.  As a result we can usually get 80% to 90% of the application's functionality finished without writing any custom code.  The other 10% to 20% of the functionality does take a little longer, but not much.  Most of the time we can still leverage our framework to finish the project with minimal modification.  For those parts that don't fit in to the framework, we simply extend the framework to solve the problem, meaning that the next implementation we do that presents a similar problem is handled by the framework as well, minimizing development time.  This is one of the advantages of using Legacy in the context of an enterprise-wide solution: the more we work with your data the better our solutions get.

In short, don't be fooled by someone trying to sell you a solution that doesn't fit your problem.  Your data is valuable and the value it can give your company should not end when the application that houses it is retired.  When all is said and done, it is your data.  You should be the one to determine the best way to access and utilize that data.