In this interview with GRIDtoday, Grant Peterson, vice president of product development for the LexisNexis Litigation Services group, discusses how the company's Applied Discovery application is able to handle twice the number of legal documents in the same timeframe since moving to a grid environment powered by DataSynapse and its application virtualization technology. 

— 

GRIDtoday: To begin, can you explain LexisNexis' Applied Discovery application?

GRANT PETERSON: Applied Discovery is an online service that takes in large quantities — I mean very large quantities, in the terabyte range — of document material, processes it, turns it around, and organizes it for review by legal teams prior to making discovery productions to opposing counsel in active legal matters.

The complexity of our business is that we are dealing with large numbers of electronic and scanned paper documents on short periods of time, needing to organize, index, sanitize, pull the metadata from and present for review that quantity of data. Generally, the expectations are that we take in multiple hundreds of gigabytes, if not terabytes, of data and turn it around in days, so that it can be reviewed and then subsequently produced to opposing counsel. So, the volumes and turnaround times are our major challenges.

Gt: What was your system for handling this process prior to moving to the virtualized DataSynapse platform?

PETERSON: We have, effectively, three systems. Our initial system, the first point of technology application to the problem, is our collection platform. The data collection platform is used to gather the information that needs to be brought into a discovery matter.

We then have a production system, and our production system takes the collected material and essentially uploads it … allows us to organize it into an intelligent review by what we call a “custodian,” which is ultimately where the data came from — some individual, presumably. We upload that quantity of data and pull the metadata off each of those documents — and we have many collection types, like Zip files, PSP mailbox files and LotusNotes NST files. We will pull those apart into individual messages, preserving the metadata on each of them, and store that metadata for what's called “non-spoliation.” You need to be able to review the documents without changing the metadata and then deploy them for review in a searchable index.

Our solution prior to DataSynapse was based on taking a large number of stand-alone applications, or stand-alone instances of our production environment, and we would have a production engineer running maybe five copies of the production environment and monitoring each of them as they uploaded and preserved and indexed incoming files. So, the state-of-the-art for us prior to this was individual people, or human labor, monitoring multiple running applications. Somebody who was really good could perhaps monitor 10, but most people probably could look after five converters at a time. So, what we did was just have a large number of blades and a virtual terminal application, and a production engineer would essentially keep flipping back from one blade to the next, monitoring the conversion status on each blade.

Gt: For how long have you been using GridServer?

PETERSON: We implemented GridServer last year and it is, at this point, fully deployed. What we did was take those individual production consoles and virtualized them into the grid and created a pipeline manager. So now, instead of a production engineer monitoring multiple jobs individually, what they're doing is monitoring a console of the full grid. We have about 350 blades that are active in our production environment, and we can now take about five production engineers and monitor the activity on the entire grid.

Gt: What were your biggest market challenges, and how did the GridServer platform help you overcome them?

PETERSON: For one, we've worked with our customers over the years to essentially come up with what we believe is the best review experience in the industry. That review experience is based on taking every document — all 140- some-odd disparate document types that tend to come in during discovery projects — and coming up with a uniform way to view, review, redact and deliver those documents. We standardized on converting documents to PDFs as a neutral review format. It allows us to preserve the original nature of the document across a very large number of initial document types and make the review experience efficient and consistent.

In order to do that, we have to convert huge numbers of documents to PDF, and there is competitive pressure on us to not add additional cost to our service as a function of making that additional conversion happen; some of our competitors review documents in text rather than in a more natural or native format. In order to convert the documents and not add cost, we had to find an automated way to do it in large volumes that didn't drive up labor. So that's one factor.

The second factor is the volumes of data coming in during discovery are ballooning. They're ballooning, but the turnaround times expected and the cost of doing electronic discovery conversion are really staying a little more level. So, there's pressure to be more efficient and pressure to continue to be as fast as we were in the past. A year ago, we were handling about half as much data on a daily basis, now it's not unusual for us to turn around 6 or 7 million documents a day. It would have been nearly impossible given our prior labor model to do that without having hundreds of people monitoring converters.

By implementing the GridServer, we've been able to keep our conversion labor consistent and double the throughput.

Gt: Have customers noticed your consistency even as document volumes keep rising?

PETERSON: We've always offered a best-in-industry service, but our challenge was expectations of price going down and the necessity, from a business growth perspective, of volumes going up. In order to maintain that excellence of service, something had to give. I think the feedback we've gotten is that we continue to be one of the fastest turnaround time vendors in the industry, and continue to meet customer expectations. Doing that at twice, or more than twice, the expected turnaround is validation in itself. I don't know that we've improved our service, per se, but we've doubled our service and maintained the same levels of excellence.

So, I think it's been transparent to our customers, but I believe that had we not made this shift, our customers would have noticed negative impacts on their expectations. What we've done has been to maintain levels of excellence by innovating in front of what are some difficult pressures in terms of turnaround times and data volume increases.

One other comment I would make is that I consider the production team — we have a large production team that handles the daily service deployment of content and customer projects — as much my customer as external customers, and we have gotten significantly positive feedback from them because the process of monitoring the pipeline against the virtual server is a significantly more accurate and simple procedure than was flipping from screen to screen to screen to locate the status of a running application. So, our internal customers are elated with the simplicity and, effectively, just the capacity that it makes it possible for them to stay in front of.

I also would say that the accuracy of the work they're doing has improved because in virtualizing this network of production systems, we've also done a much better job of managing errors and a much better job of recovering and restarting. In the past, if a production engineer encountered an error in one of these consoles, that blade could be sitting idle for any period of time until they noticed and intervened and made whatever correction was necessary. In the new implementation, the system is self-correcting, and that blade gets put back to work immediately. We're actually getting a lot more capacity out of our hardware resources than we were in the past because we're able to keep the blades running.

Gt: Do you expect your current DataSynapse platform to scale as your demands in terms of data and turnaround time continue to increase?

PETERSON: We don't think we're anywhere near maxing out the solution. The first transformation was being able to efficiently deploy the people resources we had. The second transformation that we've encountered is being able to keep the deployed hardware at a higher level of load, and that's given us a decent amount of headroom in terms of this conversion process. In terms of next steps, to stretch this solution even farther, we've only taken two or three of the critical processes to the virtual grid at this point. We have a large effort underway called the “production control system,” which is taking additional processes — including the import of data, export of data and production-set management — online and putting them also on the virtual system.

So, there's more in our production operation that we can virtualize, and, once we get through that, we can certainly add hardware to take up additional capacity requirements. One of the things about this solution that's wonderful is that it's quite scalable. At this point, I don't have any concern that this won't stretch to cover our business growth. That puts us in a very comfortable situation.

Gt: When will “production control system” be complete?

PETERSON: Project work is underway now; we're kind of in a rolling deployment. I would expect we will be done with the full deployment of our entire production system on the virtual technology in early 2008. We have about 40 tools in our production environment, and we're dropping them at a rate of about two to three per month onto the virtual system.

Gt: Did you look at any other solutions before choosing DataSynapse?

PETERSON: We had four solutions in the arena when we made the evaluation. Unfortunately, I don't have the details on why we didn't select the others, but I know why we did select DataSynapse. Probably the primary reason [for selecting DataSynapse] was that it tested out to be the most mature technology that we evaluated, and it was more flexible in terms of allowing us to create a custom pipeline application than the other solutions that were evaluated. So, the programmability and the integrability in our core technology were the principle selection criteria, as well as just the track record and … [the fact that] the relationship with DataSynapse was the best. There was a strong desire on both sides to work together based on what I'd consider to be good, interpersonal dynamics.

Gt: In a nutshell, can you summarize your overall experience in making the switch to a virtualized grid environment for your production system?

PETERSON: I'll start by saying — and this is unusual — that my expectations have been fully met, and exceeded, in this implementation. We made this implementation out of necessity, and the relationship with DataSynapse has been excellent from the start. The technology has performed as expected and as tested; we really haven't encountered any issues requiring escalation to my level to become resolved. I'm certain there probably were [bumps in the road] in doing the integration, as there always are, to get things working, but it got done on schedule; it got done without escalation; the relationship has remained strong; and there's really little question that there's excellent value in our investment at this point.

I consider the investment not just the cost of acquiring the DataSynapse technology, but also to include the cost that we laid in terms of redeveloping our system to run on the grid. In both cases, we've performed within budget, and it's enabled us to deal with 200 percent the amount of data we've dealt with in the past without having to grow our production organization to handle it. In that regard, I guess I would say it's been invaluable to us. I work with a number of vendors around licensed technology, and this one has been far and away the smoothest.

—–

To read announcement of this partnership, click here.