is the future of eDiscovery<\/strong><\/a>. I cannot say how long it will take for cloud to take over on-prem, but I have no doubt that this will happen. It\u2019s only a question of when, not if. Cloud computing is simply too attractive and too cost-effective to be relegated to the sidelines for long.<\/p>\n\n\n\nSecond, I see two major hurdles that eDiscovery functions will have to overcome to make cloud computing a reality: perceived security concerns and the IPE problem<\/strong>. In another thought piece, I\u2019ll talk about how the cloud can be made as secure, or nearly as secure, as on-prem operations. But I do think that as long as some clients perceive the cloud to be less secure than on-prem, this will be a driver in cloud adoption. For now, I see this as a secondary problem in cloud adoption, not the primary problem.<\/p>\n\n\n\nThird, the IPE problem is THE major problem confronting eDiscovery functions<\/strong>. Until this problem is solved, I don\u2019t believe that cloud will ever achieve the level of adoption that pundits have talked about. In my experience, only the most select and sensitive clients will insist that their data not be put into the cloud. This means that most organizations are open to or ambivalent about whether or not their data is reviewed in the cloud. That makes IPE the true blockade to cloud adoption in eDiscovery<\/strong>.<\/p>\n\n\n\nGiven this significance, I think it\u2019s wise to understand how IPE actually impacts eDiscovery functions. To help us in this area, I\u2019d like to offer a clear definition of IPE:<\/p>\n\n\n\n
Once data sets exceed a certain threshold, usually 150-200 gigs, for every gigabyte of data that gets added to a matter, reviewer speed degrades by an equal measure.<\/em><\/strong><\/p>\n\n\n\nI think of this as a tipping point. Once you cross a certain threshold, reviewer speed begins to slow. As more data gets added, performance continues to degrade until it becomes nearly untenable for actually getting work done. Here are the tell-tale signs of IPE:<\/p>\n\n\n\n
\n- Document to document navigation speed slows down dramatically<\/strong>. This degrades reviewer productivity because they cannot quickly jump from one document to the next.<\/li>\n\n\n\n
- Coding saves and issue designations become very hesitant and halted<\/strong>. This often happens when a hot-doc becomes unresponsive. What should be a nearly instantaneous task can completely lock up the application.<\/li>\n\n\n\n
- Search speeds become very inconsistent<\/strong>. Sometimes queries are returned quickly and other times the reviewer cannot tell if the search is actually happening because the system does not seem to be doing anything.<\/li>\n\n\n\n
- Reviewers encounter the spinning wheel of death<\/strong>. This seems to happen at the most inopportune times and for reasons no one seems to understand.<\/li>\n\n\n\n
- Reviewers groan<\/strong>. This is literally what you can hear when IPE rears its ugly head. Reviewers become so frustrated that they verbalize it in quite colorful language.<\/li>\n<\/ul>\n\n\n\n
Four Ideas To Improve Reviewer Performance In The Cloud<\/strong><\/p>\n\n\n\nYour organization may not yet have encountered the debilitating effects of IPE, especially if you have not deployed a cloud-based solution for eDiscovery yet. So if you are considering cloud computing for eDiscovery, these ideas can benefit you by helping you avoid IPE before it even becomes a problem<\/strong>. If you\u2019ve already deployed a cloud solution for eDiscovery and have not yet encountered IPE, it\u2019s probably only a matter of time. If you have deployed the cloud and have encountered IPE, these ideas could benefit you right away:<\/p>\n\n\n\n\n- Document how much IPE is impacting your reviewers and costing your organization.<\/li>\n\n\n\n
- View your eDiscovery environment as a discrete set of technology tiers.<\/li>\n\n\n\n
- Segment the Processing, Data and SQL tiers from the web application tier.<\/li>\n\n\n\n
- Run a pilot program to ensure the performance is viable to your requirements.<\/li>\n<\/ol>\n\n\n\n
Document How Much IPE Is Impacting Your Reviewers And Costing Your Organization<\/strong><\/p>\n\n\n\nMy recommendation is that you begin by documenting how much IPE is actually impacting reviewers and, therefore, likely costing you as an organization. In my experience, there are two types of IPE impact: non-quantifiable and quantifiable. The non-quantifiable impact can often have greater negative consequences than the quantifiable impacts<\/strong>. Let me explain.<\/p>\n\n\n\nThe non-quantifiable impacts of IPE are usually about the frustration and anxiety of your reviewers<\/strong>. Most reviewers are graded on productivity metrics that determine their standing within an organization. When reviewers achieve or exceed productivity goals, they usually don\u2019t worry about job security. But when their productivity dips, their anxiety levels jump.<\/p>\n\n\n\nWhen reviewers cannot meet their productivity goals because the system is too slow (because of IPE), you have a significant problem. Morale goes down. Reviewers get nervous and start asking themselves if they should be looking for another job. In the age of the big quit, IPE could be a contributor to losing talent you want to retain<\/strong>. This is why I say the non-quantifiable impacts may be more negative than the quantifiable impacts.<\/p>\n\n\n\nYou might find it acceptable to experience degraded performance and financial outcomes as data-sets increase. You probably won\u2019t find it acceptable to lose talent because of IPE. One way to address this is to run employee satisfaction surveys that include questions related to system performance enabling job performance<\/strong>. If this metric consistently indicates trouble, it is quite likely that IPE will begin costing you employees.<\/p>\n\n\n\nNow let\u2019s discuss how to document the quantifiable impacts of IPE. To help with this, I\u2019d like to draw upon a mock organization I\u2019ll call ABC Legal. To make this example simple, I\u2019ll make the math simple too. Just to be clear, this math may or may not be similar to what your firm experiences. But the economies of scale will likely be quite similar, especially if your firm, like ABC Legal, is 100% cloud-based:<\/p>\n\n\n\n
\n- Last year, ABC legal handled 100 matters. 65 of those matters had fewer than 100 gigs of data. 20 matters had 100-200 gigs of data. 15 matters had more than 200 gigs of data.<\/li>\n\n\n\n
- ABC Legal has 7 reviewers and they are paid, on average, $1,000 per day per person.<\/li>\n\n\n\n
- ABC Legal established a productivity goal for reviewers of 1,000 documents per day.<\/li>\n\n\n\n
- On every matter with fewer than 100 gigs of data, the 1,000 documents per day target was realized. On matters with 100-200 gigs, productivity dropped to 750 documents per day. On matters with more than 200 gigs, productivity dropped to 500 documents per day.<\/li>\n\n\n\n
- As you can see, the IPE impact is essentially a doubling of the cost-per-reviewer-per-day<\/strong>. ABC Legal pays $1,000 to have 1,000 documents reviewed when data sets are less than 100 gigs. But when data sets exceed 200 gigs, ABC Legal pays $1,000 to have 500 documents reviewed. This is a very common financial scenario I see in play today.<\/li>\n<\/ul>\n\n\n\n
If your organization has already adopted the cloud, I would wager that an analysis like this will probably uncover similar financial results. IPE begins to cost you in real dollars as soon as data sets exceed 150 gigs or thereabouts<\/strong>.<\/p>\n\n\n\nView Your eDiscovery Environment As A Discrete Set Of Tiers<\/strong><\/p>\n\n\n\nMost people think of eDiscovery as an application. While the application is important, eDiscovery is also an ecosystem of interconnected devices. Even though there is a lot of complexity to the ecosystem, I tend to think of it as four discrete tiers:<\/p>\n\n\n\n
\n- Web server tier<\/strong> where application access happens and where application agents are applied to handle a variety of tasks.<\/li>\n\n\n\n
- Processing tier<\/strong> comprised of dedicated servers to handle data processing, analytics processing and compute intensive tasks. For example, data processing and data productions are both compute intensive tasks.<\/li>\n\n\n\n
- Data tier<\/strong> includes data storage systems and storage management tools.<\/li>\n\n\n\n
- SQL<\/strong> tier<\/strong> comprised of SQL databases running on discrete servers.<\/li>\n<\/ul>\n\n\n\n
I didn\u2019t include disaster recovery (DR) and offsite backups in these tiers because most organizations handle DR as an offshoot of their data tier. In some instances, a DR site is simply a hot backup of the current data sets on storage systems in an eDiscovery ecosystem. Other times, DR is a cold copy of recent data sets that can be made operational within a defined time window, anywhere from a few hours to a few days. Underneath this ecosystem is a secure network that connects all of the devices and applications for seamless interoperability.<\/p>\n\n\n\n
For at least two decades now, the assumption has been that all of these tiers need to be physically close to each other<\/strong>\u2014either in the Cloud or on-premise. But I\u2019m not convinced of that at all.<\/p>\n\n\n\nSegment The Processing, Data And SQL Tiers From The Web Application Tier<\/strong><\/p>\n\n\n\nWhat I\u2019m about to suggest is primarily an architectural consideration<\/strong>, not a technology consideration. In other words, you may not need to buy a lot of new technology to make this approach work. Here are my ideas for how to segment these tiers:<\/p>\n\n\n\n\n- Web server tier<\/strong>. This gets placed in a public Cloud so users can access the application seamlessly and securely. Public cloud environments can be made highly secure. This tier lends well to burstable on-demand resources that cloud providers are exceptional at.<\/li>\n\n\n\n
- Processing tier<\/strong>. This could get placed in a public Cloud. Or it could be in a private Cloud or a secure on-premise location, depending on the application requirements. This would fall under a mixed-use category. Certain aspects of processing lend well to the scalability and burstability of clouds, while analytics may quickly become cost prohibitive.<\/li>\n\n\n\n
- Data tier<\/strong>. This gets placed either in a private Cloud or in a secure on-premise location. The distance between the web server tier and the data tier generally should be within the same metro area to prevent response latency.<\/li>\n\n\n\n
- SQL tier<\/strong>. This gets placed in the same location as the data tier, in most instances. This is the single greatest dependency for an all-around performant eDiscovery environment.<\/li>\n<\/ul>\n\n\n\n
The goal here is to uncouple the web tier from the processing, data and SQL tiers. Those three tiers tend to operate best when they are tightly coupled. But they don\u2019t need to be on the same premise as the web application tier. Why should you consider this?<\/p>\n\n\n\n
In our experience, after having conducted audits on hundreds of eDiscovery environments, the root causes of IPE can be addressed simply by segmenting the web tier from the processing, data and SQL tiers and then joining them with a very high-speed and secure internet connection<\/strong>. This solution works. It allows for exceptionally fast read-write activity to the database while also allowing users to log-in to the system from anywhere.<\/p>\n\n\n\nRun A Pilot Program<\/strong><\/p>\n\n\n\nIf you\u2019d like to experiment with this approach at your organization, here are some suggestions for doing so. I recommend both quantitative and qualitative pilot programs.<\/p>\n\n\n\n
Quantitative:<\/p>\n\n\n\n