You don’t need another challenge when managing your mainframe database data, but eDiscovery is one you need to understand clearly. eDiscovery is the process of making selected Electronically Stored Information (ESI) available to the proper parties involved in litigation matters.
ESI can come in many data types, including social collaboration data (notably emails), files, and databases. System z implementations can deal with social collaboration data such as Lotus Domino, and files through an enterprise content management application. However, here we’ll focus on database information, such as the use of DB2 for z/OS or Oracle on Linux for System z. Note that for legal purposes, database information is considered a “document.” The eDiscovery process can be long and complicated, and it can be expensive going through the steps defined by the Electronic Discovery Reference Model (EDRM).
Many eDiscovery software solutions deal with social collaboration and file data, but none appear to be focused on managing the process for database data. The reason may be that working with databases is inherently more difficult and complex than dealing with emails or files. Challenges of dealing with database data include:
- Size: Millions of records may be involved, such as customer transactions.
- Length of time: Records must be retrieved or collected over a long period of time. Complexity: Information must be assembled from more than one system.
Although we won’t discuss the steps defined by the EDRM here, let’s examine in detail two other challenges—preservation and production.
Preservation is the process of saving information that’s relevant to a contested matter. The data must meet authentication requirements, which is a legal evidentiary standard that ensures the data and its associated metadata haven’t been altered. That requires a chain-of-custody process, which includes system audit logs and access controls to prevent spoliation, which would render the data unusable as evidence due to alteration, mutilation, or destruction.
One problem is that data in an operational database is under the control of an application that may be able to alter or delete relevant information. Although lock-down capabilities on a table, row, and column level may be available from the database vendor, a threat of application performance degradation could exist. Making a full copy of the transaction system (especially if old archived information must be recovered from tapes) is likely to be expensive (including storage space) and could contain information that isn’t relevant to the matter at hand and therefore doesn’t need to be preserved.
Using SQL to generate queries and reports that present information in a meaningful and interpretable manner may be a solution. Output could be frozen. However, more information than necessary may be collected, and it may be difficult to properly delete irrelevant information or add fresh, relevant information over time.
Production is the obligation to provide the other party in a civil litigation matter all the relevant requested information in a useful format. Providing only the relevant information can be a real challenge. Providing it in a format useful by the other side is also critical. In one case, a large company that was being sued by a smaller company made available to that company 120 IBM 3480-tape-cartridge-based backup tapes. The smaller competitor didn’t have a mainframe and couldn’t read the tapes. Its claim that the larger competitor hadn’t acted in good faith in producing the information was upheld and as a result, that company won a sizable award.
Database archiving could be a big help in eDiscovery. Apart from the operational benefits resulting from reducing database bloat, such as on the operation of data management utilities as well as data loads and extracts, dealing with issues, such as preservation and production, is easier when the data isn’t subject to the control of the data-creating application. Moreover, data over a long period of time is easier to retrieve and analyze, since any changes (i.e., changes in metadata) are taken into account.
eDiscovery can be time-consuming and expensive, and it’s imperative that it’s done right the first time. However, database archiving is something you can do now; it has current operational benefits and can also better prepare you if an eDiscovery event occurs.