Collecting Gumballs
by Dennis Kiker, Director of Professional Services, Fios, Inc.
I am fortunate in that I work out of my home, which has decided advantages at times, particularly at this time of year when I can look out my window on the neighborhood and enjoy the autumn colors. In Virginia, as in much of the Southeastern United States, we have a tree we call the “gumball” tree. Properly, it is the American Sweetgum tree, and it is a beautiful hardwood with glossy, deep green foliage in the summer that turns brilliant shades of yellow, red and even purple in the fall. These absolutely gorgeous trees have only one flaw (assuming you have no objection to raking leaves): the tree’s seed pods are hard, spiked balls about an inch or so in diameter that drop by the thousands just about all year long. They drop everywhere: in the lawn and on the bushes; they clutter the street and fill the rain gutters. Once fallen, unless they are collected quickly, the “gumballs” burrow their way into the soil, killing the grass that once lived where they fell. It hurts when you step on them, and they are just heavy enough to defeat most blower/vac machines. As a result, you have to dig most of them out of the ground with your hands. And no matter how much you dig, you will miss a few until the grass around them all dies. When I first moved here, there were about a dozen gumball trees in my yard; now, there are only six or seven left (and, yes, they died an unnatural death), but the gumball count doesn’t seem to have fallen. Indeed, unless I am mistaken, the trees become more fruitful each year.
Where am I going with this? Electronically stored documents are like gumballs. The applications that create them can be amazing tools, and beautiful in their architecture and presentation. Like the trees in my yard, they have a powerful influence on our investment decisions. The spawn of these applications wind up everywhere: on servers, local hard drives, flash drives and home computers. Though we can collect many electronic documents with available tools, it seems invariably there are some that have to be hunted down individually, and even then there are always some that get away.
The fundamental problem with gumballs (for me) and electronically stored documents (for litigators) is that we don’t have any control over where they wind up. It is only after the fact that we get involved, at which point we are stuck trying to locate the gumballs wherever they happen to have fallen, and putting them into a container that makes them manageable. Unlike gumballs, however, there are some emerging technologies that may help with the electronically stored document problem. Most, however, attempt to deal with the problem after-the-fact. What I’d like to see is a technology that works up front. Rather than a better blower/vac, what I want is an intelligent gumball that knows its proper place at the moment of release. Rather than a system that allows (or requires) me to identify where a record will live after I have created it, I want a system that knows what that record is at the moment of creation, its place in the information infrastructure predestined, with no thought on my part beyond the need to create a record.
I am not talking about a document management system that requires me to create a profile of the record as I create it. That is a nice evolutionary step – and one, by the way, that is entirely manageable with proper discipline. I am also not talking about an automated process that tries to categorize my documents after I create or receive them. Again, nice evolutionary progress, but not that effective. Here is what I imagine: Most business operations (or human beings generally) really only create a limited number of record types in the usual course of business. Accountants, for example, are not off creating design drawings or manufacturing reports. There is a finite set of record types that they create in the course of their work. Let’s have a system that allows the user to create a record type in the first instance, rather than starting with the generic (word processing document, spreadsheet, etc.), and then categorizing it after the fact. This is not a template, mind you. A template is a fine thing, but I still need to decide, after creating my record from a template, what it is and where it belongs. Rather, from the moment of initiation, the record should know that it is a balance sheet, or a design drawing, or a warranty returns report. Give me, as a user, the choice to create a record type, and, based on the record type that I choose to create, the system will know where that record belongs, what its retention period should be, whether drafts should be retained, and so on. When I need to find those records later on, I won’t need to wonder where to look because the system will have organized the records in the first instance.
Now, I admit that this solution works only if my neighbor has the same evolved gumball tree that I have. If not, his antiquated gumball tree will still deliver the occasional gumball to my yard, and I’ll have to go out and find it and figure out what to do with it (which will probably be to toss it back in my neighbor’s yard). Still, I think that there is something here, a shift in how we think about record creation, at least for the vast majority of the records that we create. Categorization at the moment of creation based on the fact that, for the most part, we create the same records over and over again. Believe me, I have collected thousands of gumballs over the past twelve years, and they all pretty much look the same.
Filed under Discerning e-Discovery.