In 2004, I noted the idea of the "Data Map," proactive documentation of IT assets undertaken in the interest of litigation preparedness. With recent changes to the Federal Rules of Civil Procedure, the concept is crossing my radar repeatedly, sometimes termed "IT Map." See here, here, here and here. There is a distinct sense of urgency emanating from the legal community. So... any lawyers (or their IT discovery clients) reading this, please pay attention here.
The idea of the data map has notable and obvious overlaps with the concepts of CMDB and metadata repository, and possibly enterprise architecture repository as well. The same information potentially relevant in discovery is also relevant to operational IT processes such as incident, problem, change, asset, and data management. IT has been historically weak in managing data about itself - hence the subtitle of my book, referencing the "barefoot cobbler's child" proverb. I continue to find this weakness baffling and inexcusable; it is no more acceptable for an IT organization to plead ignorance regarding its data than it would be for an HR organization to not know employee details, or a finance organization to not know accounting details. Yet the sad truth is that this is the state of the profession.
If you are a lawyer and involved in any discussions regarding a "data map" or an "IT map," your first question should be whether the organization has 1) a CMDB (or at least an asset management system) or 2) a metadata repository. If it has either, seek out their managers - they have the keys to your problem. If you do not leverage what they are trying to do, you will be re-inventing a very difficult wheel, and will almost certainly fail. (I've seen the train wrecks).
As Sedor and Wong very correctly note, "Rather than periodic update initiatives, data map maintenance should be tied to existing processes that already deal with change management, such as IT project management processes and financial department purchasing processes." But the repositories back-ending those processes are not called "data maps," they are the architecture tools, the metadata repository, the CMDB, the asset management system, and related systems. See this systems architecture, or my book which goes into much more detail.
I am not saying that the asset, CMDB and metadata folks will solve all of your problems. The general issue of "unstructured" data (email, laptop hard disk contents, etc.) may be more challenging to them, and that issue may in fact loom larger for you. The intersections between metadata management and paper records management are just beginning to be explored in large enterprises. (DAMA conference organizers take note...) But as you move into the core of the enterprise's IT systems, you will find their assistance invaluable, and those core transactional and business intelligence systems are clearly in scope for e-discovery.
Some clarification of the term "metadata" is in order. The legal community seems to be familiar with metadata as a descriptor for unstructured documents, most notoriously Word documents that save sometimes sensitive information such as author and last modified date. This is NOT the sense in which I am using metadata; I am using it in the sense of the enterprise metadata repository. For further information on this, see the DAMA-Wilshire annual conferences, and the works of Adrienne Tannenbaum and David Marco.
The thrust of the e-discovery requirements brings up another favorite topic of mine: the need for metadata and CMDB to converge. Metadata contains information about business semantics: what the data means. As I've noted elsewhere, "You can't secure "Customer" data unless you understand that column CSTR_8XY_R7T_N in table GST_N_DT_TB in database GDB0234 actually contains their Social Security Number." And while metadata systems too often stop at the data dictionary, configuration management systems too often stop at the server, leaving a major gap in business to IT traceability - a gap that may be critical in e-discovery. We need to know what data is on what server, what changes and problems recently happened to it, who has access, and much more. Currently, there is no integrated "map" in most companies that can answer such questions comprehensively - and the value of such a map would far transcend litigation preparedness.
DISCLAIMER: I am not a lawyer. Please consult a legal professional before undertaking any action in these matters. But if your legal professional has no background in or understanding of IT best practices related to configuration management, or metadata management in the data management as well as document sense, they may also be unprepared to assist you in these emerging and highly complex matters.
Charlie
