Normally you will get contacted by a case team member if a user has deleted a folder from the case database. By then you will already know the name of the case, database, folder and user who deleted the folder. If the name of the user is not known, it is still possible to find out who deleted the iConect folder (from the front end) and when the folder was deleted.

What actions should be taken to restore the deleted folder?

Follow these steps precisely to recover the deleted folder. Incomplete &/or missteps will inadvertently lead to complications. Immediately contact your administrator if you have made a mistake.

STEP-1:
RDP to the iConect database server and locate the Folder Log Processor application (it will be an .exe file). Typically the location of this file is: G:\iconectnxt\iLETs\Tools\FolderLogProcessor\FolderLogProcessor.exe where
G:\ drive can be replaced by the relevant drive letter in your iConect environment.

STEP-2: Double click the Folder Log Processor
application and fill out the details as shown in the picture below. (Read STEP-3 & 4 to better understand how to provide details for FLP Application.)

STEP-3: Always make copies of the FBL files to your analysis folder.

• FBL files are typically located in G:\iconectnxt\datafiles\logfiles\FolderLogs\ directory.
• They are named by date, for example: 2011-05-11.fbl and 2011-05-11-Backup.fbl , etc…
• If you already know the date range when the folder was deleted, it becomes easier for you to select and copy those .fbl files that fall under the date range of folder deletion.
• Make sure that when you copy the .fbl file(s), you must always copy its corresponding backup files.
• As a precaution, never work on the original .fbl file. Always make a copy. Not making a copy may lead to altering the original .fbl file which will not be appropriate for future traceability.

STEP-4: Fill the details for the folder logging application.

• Click on source and point to the folder where you have made a copy of the .fbl files.
• Select the date range of the folder deletion activity.
• Select the destination folder where you want the output CSV file to be generated.
• Select the name of the database where the folder deletion took place.
• Finally, click the Convert Now button.
• An output CSV file is generated in the destination folder.

STEP-5: Analyze the output CSV file.

• The CSV file will look somewhat like this:
  “Folder”,”User”,”Record”,”DB”,”DateTime”,”Operation”,”Checked”
  “Unknown folder id: 400 in database: 221″,”mpeera”,”0″,”Doc Review DB”,”05/11/2011 07:52:47 PM”,”4″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”1″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”151″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”153″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”294″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”303″,”Doc Review DB”,”05/11/2011 07:53:43 PM”,”2″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”106722″,”Doc Review DB”,”05/11/2011 07:53:55 PM”,”8″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”106721″,”Doc Review DB”,”05/11/2011 07:54:01 PM”,”8″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”106720″,”Doc Review DB”,”05/11/2011 07:54:05 PM”,”8″,”1″
  “Unknown folder id: 400 in database: 221″,”mpeera”,”0″,”Doc Review DB”,”05/11/2011 07:54:22 PM”,”7″,”0″
  
• To understand how to interpret the CSV, lets define and describe each header field:
  • Folder: the ID of the folder and the ID of the database where the activity took place. When the value is specifically “Unknown folder id:……” it means that the folder was eventually deleted. In our example “Unknown folder id: 400 in database: 221″ means, the folder id 400 which eventually got deleted from database id 221.
  • NOTE:
    In order to find out the id of the database use the troubleshooting tab on the nxtManager.
  • User: username who took action on that folder.
  • Record: Oracle Record Number of the document that got added to that folder in the database. In our example it is folderid = 400 and database id = 221. Zero as a record number signifies that the folder was created but no documents were added to it.
  • DB: The name of the DB where the activity took place.
  • DateTime: Time Stamp of the activity.
  • Operation: Specific activity that was performed on the folder.
  • Checked: This field signifies whether document(s) were added or removed from the folder(s).
  • Refer the table below to better interpret various actions based on the Operation and Checked fields.

STEP-6: Prepare an overlay reference file.

• Once you have identified which folder got deleted, who deleted it and when it was deleted, the next imperative step is to restore the folder in the correct case database.
• You will have to manually recreate the folder under the correct tab and hierarchy.
• Prepare a reference file which lists the OracleIDs of the documents that got deleted from the identified folder.
• Note:  Do not confuse OracleID with Rec#. They are different. See the picture below.

   
  Note:
  In some cases when the database has no deleted records, the Rec# and OracleID will always be the same. Always double check to see the last record. If all 3 numbers are the same then you can consider that the Rec# = OracleID.
  

What actions should be taken to correlate all the appropriate documents in the restored folder?

• In cases where the Rec# and OracleID are the same, you can create a new field, match and mask a “Y” in that new field and search for all documents that have a Y in the new field that you created. After the search returns the results, mass folder those document back to the restored folder.
• In cases where the Rec# and OracleID are not the same, manually add the documents to the resorted folder.

Typically when data is discovered, the documents are renamed with their appropriate control numbers. On rare occasions clients require us to retain the original document name and this can have pitfalls. One issue that we encountered was something that could not be easily resolved during our quality control process and I wanted to share my experiences with you, such that you are able to easily determine in case you experience something similar in the future.

CLIENT REQUEST

We were given several thousand office documents in folders and sub folders and the request was to print those documents to ADOBE PDF format and provide back to the client retaining the output folder structure exactly same as the original input folder structure. This was a seemingly mundane and easy request to cater to, however, we were asked to retain the original document names. Padding those document names with some sort of control number was not an option that we were allowed to use.

 WHAT TRANSPIRED?

After the process of printing all the documents in the input set to PDF was complete we found a few documents missing. The total number of documents in the input folder was more than total number of documents in the output folder. There was no error in processing and no log which indicated this reduction in the number of documents.

HOW WE WENT ABOUT TROUBLE SHOOTING THE ISSUE

We wrote a script which would return as output, path information of each folder along with the corresponding number of documents in them. We ran the same script on the Input folders as well. The comparison between the document quantities in input folders versus output folders allowed us to isolate all the sub folders where there was a difference in document count. On deeper analysis of all the documents in the troublesome sub folders got us the answer to what had occurred.

EXPLANATION OF THE ISSUE

We found documents with the same name which had different file extensions. For example: ABC.doc and ABC.xls when converted to PDF format retaining the same folder structure would both become ABC.pdf and overwrite the previous document there by reducing the document count by one. This had occurred several times in many sub folders where the documents had the same name but different extensions.

PRECAUTION & CONCLUSION

Retaining the same document name during discovery can have issues as explained in this article. In order to avoid such situations you can run an inventory on all folders and isolate the file extension from file name to evaluate whether there exists documents with the same name but different extensions. If they do exist then renaming such documents with their extension as suffix may be a solution that you may want to apply. For Example: ABC.doc and ABC.xls when found in the same folder could be renamed as ABC_doc.doc and ABC_xls.xls to avoid overwriting documents during the image conversion process. Padding document names with some sort of control number while retaining the document names in the image conversion process may be an alternative option.

Often there is an element of mystery when search filtering v/s searching is brought up in an electronic discovery project meeting. I hope this blog serves to eliminate this confusion and helps you design effective work-flows taking into consideration your better understanding of both these techniques.

WHAT IS SEARCHING AND WHEN DO YOU USE THIS TECHNIQUE?

Searching by definition means “finding something” and in an electronic discovery environment means finding data (i.e. documents or content) that you are looking for to take further action. Further actions can be classified in numerous ways depending on your given situation. In simple terms, once you find what you are looking for, you will do something with the data you found. Maybe you will classify what you found in a particular way reminding you of what it is all about. May be you will take necessary steps such as folder, export and produce the data to complete the ediscovery lifecycle or may be segregate the data based on its relevancy for future action, and so on….

WHAT IS SEARCH FILTERING AND HOW IS IT DIFFERENT FROM SEARCHING?

Search filtering by its very name is a search technique used to subset the data once you have finished searching. This subset could be either included or excluded from your future actions. Searching allows you to find what you are looking for and take several different actions on your data set. Search filtering on the other hand only allows you to create a subset which is in essence a focus set. Meaning, once a search filter is applied, from that point onwards only that focus data set will be acted upon for further action and this brings about the major difference between both these techniques. The universe of data never shrinks (or in eDiscovery terms never gets culled) to a subset when searching, but does so when search filtering.

WHEN SHOULD YOU PREFER SEARCH FILTERING OVER SEARCHING?

If the volume of collected data is very large; more than your data processing infrastructure can handle and if you know all of the inclusive search terms or search phrases and most importantly if you are 100% sure that these search terms are not going to change in the future, then and only then you may consider search based filtering techniques. However, if you have the slightest doubt about any kind of changes to the search terms provided then I recommend you prefer searching over search filtering. Project managers and electronic discovery consultants must always ask relevant questions up-front to their clients before designing work-flows around search filtering.

WHAT ARE INCLUSIVE AND EXCLUSIVE SEARCH FILTERING TECHNIQUES?

There are two methods by which you can perform search based filtering. They are:

Inclusive Search Filtering is one where data that comes up as a hit to the search terms should be considered for further action. This method of filtering is more popular and often used.

Exclusive Search Filtering is one where all other data apart from the data that came up as a hit to the search terms must be considered for further action. This method is rarely used because it can cause many complications.

WHAT PRECAUTIONS ONE MUST TAKE WHILE RUNNING EXCLUSIVE FILTERS?

Data that contains exclusive search terms may also contain non exclusive (i.e. inclusive) search terms. When such a situation arises then inclusivity should always get preference over exclusivity. Consider the diagram below:

 A is data from inclusive search hits and B is the data from exclusive search hits. Say Y is the inclusive set and Z is the exclusive set.

In this diagram X is the data set which falls under inclusive hits as well as exclusive hits. Then while eliminating the data from the subset after search filtering you must always eliminate B – X.  This will help you take into account the false positives and provide a subset which is most appropriate for you to take further action.

The Legal Services market has 6 potential players which drive the business lifecycle. They are as follows:

Government Bodies: With stricter regulations across the board, government regulatory agencies like FTC, SEC and DOJ have become or will become more demanding with corporations to comply with regulations. What this means for small to mid-size corporations are that the probability for them to get litigated due to non-conformation to ever tightening regulations is certainly going to be higher.

Corporations: Corporations who get litigated on a regular basis are going to bring or have already brought functions like records management, preservation, electronic discovery processes and review in-house. For those corporations who haven’t yet or have no plans in the near future are demanding of law firms to work on fixed pricing models for the entire lifecycle of litigation services.

LAW Firms: Up until now, law firms had no control on electronic discovery costs and were at a loss managing the entire discovery process because of a lack of understanding of management of data from raw to review to trial. This led to a boom period for legal service providers with a higher price per GB model and higher hourly charges. Today as more and more law firms bring discovery management in-house to control the cost of services they provide to corporations, the landscape for small to mid-tier legal services providers has changed towards the negative.

Software Companies: With more cutting edge software making in-roads into the electronic discovery market, the irreversible commoditization in the legal services space has already begun. This rise in technological advances has lowered the threshold to become a legal service provider and anybody with reasonable amount of money and with a limited understanding of the bigger picture can enter this space very easily. Software giants such as Microsoft and IBM are also introducing products that address information management and this makes it even tougher electronic discovery service providers.

Consulting Companies have a different angle to their approach to providing electronic discovery as a service. Organizations like FTI, Navigant, KPMG, Ernst & Young, Huron and PWC mostly sell legal services as an off-chute to the primary consulting services they offer. These services would range from financial, human resources to other business process management services. Their high price points are justified by the value proposition they are able to sell to corporations. But they too in today’s highly competitive market feel the ever increasing demand in lowering their costs. Their diversification in different industry verticals, various business processes and technology solutions makes them virtually invincible.

EDD Service(s) Providers: So what is in it for electronic discovery service providers? What is their differentiating factor? Why should anybody use their services except for trivial low cost EDD solutions? More and more EDD service providers are finding themselves in a situation where they have to reinvent themselves because if they don’t they are going to wither away. Many find a niche by handling specific data types, many claim to be technology agnostic by integrating various software and providing a customized solution, many have started to diversify. I have known a service provider who had to resort to selling eDiscovery T-Shirts. Funny, but not quite for them.

WHAT SHOULD YOUR BUSINESS DO / NOT DO

Given the factors as they stand today, there are various ways in which you can mitigate your business risk, increase the valuation of your business and be prepared for the future.

1. Diversify, Diversify in the right direction, Diversify to mitigate your risks.
2. Focus on what you are good at and do it well.
3. Partner with Technology companies. Not one, but many.
4. Effectively manage you partnerships through appropriate contractual agreements and technical know-how.
5. Convince your partners to allow you to rebrand their product as if it were yours.
6. Hire a technical client services team to service those product lines.
7. Do not just offer software but instead listen carefully to your client’s requirements and offer solutions. A solution could comprise of multiple different products, procedures, protocols, etc…
8. Do not impose your own software or solution to all projects.
9. Become your client’s problem solver.

HOW TO CHANGE (Food for Thought)

1.      Revolutionary ideas

• Build Electronic Discovery Kiosks and install them at Law firms. Use credit card processing methodology so that you get paid automatically. When your overheads are low, you can offer low cost service. Lit Support teams can plug-in their hard drives, select wizard driven processing options and get their data discovered in front of them. This idea is absolutely achievable.

2.      Traditional ideas

• Strengthen your internal business processes around technologies such as sharepoint, joomla, drupal, etc… Use this opportunity to learn these technologies and offer this solution to other vendors there by expanding your client base to not only law firms and corporations but also to vendors and software companies. Associating with such technologies allows you to latch on to business process management across the EDD space and increase the chances of getting large projects.
• Build niche applications like discovery of difficult data-types such as Bloomberg, Lotus Notes, Groupwise, etc… to demonstrate the ability to handle niche data-types and show value.
• As an EDD Vendor, partner with other vendors and build on each others strengths.

CONCLUSION

To survive in this ever shifting landscape you must change. Not changing is not an option. By offering reasonable priced services and diversifying along the lines of technology will allow you greater reach and better valuation of your company. Bring in new talent. People who can work effectively with different kinds of tools and procedures to provide superlative, value added services. Elevate your company from being looked upon as a vendor to being addressed as a partner. Make a decision and make it now!

Streaming marries something old to something new. Also popularly known as Live – Live or Webcasting, streaming is real-time and on demand transmission of content, delivered by streaming server applications which are read and rendered by client applications. Content is received from the server as is, leaving behind no residual copy on client machines.

In order to stream, a text based tag markup format is used, popularly known as Synchronized Multimedia Integration Language (SMIL). Although progressive download is a pseudo-streaming technique, true streaming is much more advantageous in certain scenarios. Streaming files cannot be saved to HDD and streaming allows users to browse through and jump back and forth in the content as oppose to progressive download which requires viewing from beginning to end.

True streaming requires a specialized media servers or content management servers. Streaming content and media files are usually encoded in several versions and optimized for different data rates. Streaming media also facilitates integration of interactive capabilities such as chapterization of segment, clickable hotspots and URL flips.

Webserver streaming also called as HTTP streaming is a flavor of progressive download. HTTP streaming creates a local cached copy of the media file, so there is no way to prevent end-users from copying the file into a designated directory on their hard drive. One major advantage over true streaming is that, HTTP streaming enables files to get transferred across firewalls. One of the disadvantageous of true streaming is that, data that is lost or damaged is gone forever or at least as far as that stream is concerned, resulting in imperfect, sometimes even indecipherable, playback.

Streaming is not a reliable way to transfer “normal” data. Data that must be complete and uncorrupted to be acceptably reproduced on the receiving end. So streaming is not used to transfer text files, databases, intricate graphics, and other types of unforgiving information. Streams are sent from a streaming media server to a client using a protocol known as RTP (Real-time Transport Protocol). RTP is similar to HTTP and to FTP protocols used by Web servers but there are some essential differences.

Unicast Streaming: A unicast is a one-to-one “narrowcast,” in which each end-user gets a separate stream, even if they are experiencing the same media simultaneously. Because they each get their own stream, end-users can be given options for controlling the media, such as the ability to pause the stream, replay portions, or to jump to a different part of the program. This type of control is, however, only possible with pre-recorded content made available on-demand, and this flexibility comes at the expense of both server capacity and bandwidth every end-user must be served and sent a discrete stream.

Multicast Streaming: Multicasting, or “IP multicasting,” is also considered a narrowcast strategy, and it is designed to conserve both server processing capacity and bandwidth. The server transmits only one stream, which is replicated by special routers throughout the network, to be distributed to groups of multiple end-users. Multicasting does not allow the same flexibility for the end-user as does unicasting, every end-user must experience the same content concurrently.

The Bloomberg Messaging System – which includes both email and instant messaging (IM) – is a commonly used application in the financial industry. Unlike conventional email systems such as Microsoft Exchange or Lotus Notes, these services are not run from a server on the User’s premises. Instead, each user’s workstation accesses a central server farm managed by Bloomberg. Emails and IM messages are stored on the Bloomberg servers and are viewed through Bloomberg’s proprietary terminals. In order to comply with regulations and enable companies to archive, however, Bloomberg does allow its clients to access messages for archival purposes through daily FTP downloads. It is also possible to request a download of messages stored on the Bloomberg servers; by User, Customer or Firm. Both emails and IM messages are archived on Bloomberg’s servers in raw ASCII text form. To reduce the size of the archive message dump, it is possible to request messages for a specific date range.

HOW TO DISCOVER BLOOMBERG MESSAGES

The archive files made available through Bloomberg’s FTP site are simply text dumps and a single archive text file may comprise hundreds of thousands of individual messages. In order to search or review Bloomberg messages in an electronic discovery review platform such as Concordance, Summation, Ringtail, iConect it is necessary to:

1. Break up an archive file into individual records
2. Identify a unique message number for an extracted record
3. Extract the metadata (such as To, From, Subject) from the records by parsing the text.
4. Extract text from the records
5. Generate a load file in one of the electronic discovery standard load file formats.

COMPARING BLOOMBERG METADATA WITH OUTLOOK MESSAGE METADATA

One major difference between Bloomberg messages and messages produced by MS OUTLOOK is that in Bloomberg messages there may be multiple occurrences of the same metadata field whereas in Outlook PST, the additional metadata field values are simply concatenated into the same field. For example: whereas the TO field in an Outlook msg file might contain several recipient names (e.g. TO: susan@acme.com; bill@acme.com; kevin@acme.com), in a Bloomberg message, each recipient would be listed separately (e.g. TO susan@acme.com; TO bill@acme.com; TO kevin@acme.com). This is part of the reason why Bloomberg files cannot be readily loaded into Microsoft Outlook without prior parsing or conversion.

OUR SOLUTION

At LEX we created a processing system to handle archived bloomberg messages. Our processing system can unitize and number the individual messages, parse out metadata fields with their values, extract the text and enable a load file to be produced from the resulting data. LEX’s Bloomberg Message Normalizer can handle: Email sent between Bloomberg users, email sent between Bloomberg users and senders/recipients with external email addresses and Bloomberg Instant Messaging. In addition, the application is able to identify any attachments, extract the metadata associated with these attachments (e.g. file name), and associate these with the parent email / IM Message (assuming the individual attachment files are available). It is able to do this whether there is one attachment in a message or many.

PRESENTING INFORMATION

We also provide customers with a range of value-added reports including:

1. Senders and Recipients (by person & organization)
2. Organizations (by Firm & Customer)
3. Subject Analysis
4. Subject Keywords
5. Attachment Analysis

All metadata information (including the Body of the message) is held in a SQL database and can be searched and/or additional reports produced, as required.

IBM’s Lotus Notes was designed as a collaborative work environment and messaging platform on which applications that require the communication and sharing of information can be developed. It is often used as an email system but this is not its primary function and consequently it behaves and is architected differently from applications built around emailing (e.g. Microsoft Outlook).

At the core of Notes is a database which can store many types of data including forms, user interface controls, database views, rules etc. and an almost unlimited set of metadata fields. Indeed there are no standard metadata fields associated with Lotus Notes documents: they are whatever the application creator found useful to employ. Last but not least, being a database means that as well as conventional foldering for organizing documents, Lotus also support views; which are virtual, dynamic collections created when a database query is executed. All these features make lotus notes very different from a traditional emailing system.

Identifying which NSF documents are emails is not by any means straightforward. Lotus Notes comes with a number of predefined templates which are used to create and display messages. The default template for email messages is known as R6. However, users of Lotus can modify this template or use other custom templates to send email messages. This means that there are likely to be more email messages than documents based on the R6 template. Indeed studies show that fewer than 30% of messages or responses to messages will be based on R6. Unfortunately most processing systems only look for the R6 template when identifying emails. Consequently, many messages may be missed.

CONVERTING LOTUS NOTES TO PST IS RISKY BUSINESS

Lotus Notes (aka NSF) files are a well known challenge when processing it for electronic data discovery purposes. Many electronic discovery service providers simply turn them into PST files—thereby losing significant information, generating images which may be cut-off and running a high risk of producing a flawed deliverable. Even if the processing platform handles Notes email stores natively, it may miss both documents and data by treating an NSF as an email store instead of what it really is —a database and an application platform that also happens to be used for messaging. Moreover, almost no one has a good method for processing Lotus Notes applications and yet an application such as a Sales Order management system may be responsive and contain information pertinent to a case.

ALL DOCUMENTS FOLDER MAY NOT CONTAIN ALL THE DOCUMENTS

One of the biggest challenges when processing NSF files is ensuring that all documents are processed. Many users believe that processing the ALL Documents folder will produce everything in the database but it may not, as users can change the query that creates the folder to exclude particular document types or metadata. Since Lotus Notes folders are database queries and views rather than containers, there may well be documents in the Notes database that are not in any folder. The only way to produce all documents reliably and accurately is to make use of the records in the NSF database.

 Sample report after LEX Deep Extraction of Lotus Notes showing:

1. 2967 unique documents in the NSF database
2. 841 documents in the ‘All Documents’ folder and
3. the query behind the ‘All Documents’ folder showing the modifications made to exclude certain document types such as Appointments and Notices.

A NEW TECHNIQUE TO DISCOVER LOTUS NOTES – DEEP EXTRACTION

We pioneered a new approach to discover data from lotus notes. The term given to this technique is called Deep Extraction. For each type of object found within lotus notes we have developed methods to extract all the metadata, not just a limited, so-called “standard” subset, and to represent it in a database where it can be queried and reported on.

We did not normalize metadata fields across object types but instead leveraged the different information available in each. By extracting from the database directly, we were also able to mine every piece of metadata, no matter how nonstandard or customized, and in this way, provide a complete view of the data set. For example, most conventional processing systems miss the organizational and location (country and company) information associated with Notes messages, but we were able to simply extract everything and populate it in a database.

THE SOLUTION WE BUILT

LEX Notes Monster is an application for processing Lotus Notes emails and databases natively based on LEX’s Deep Extraction methodology. It extracts all metadata from the NSF and records it in a SQL database from which metadata information can be selected as required and used when processing and to create the final deliverable. In addition, Notes Monster is able to produce both PDF and text renderings of Notes messages and database views without the need for Lotus to be available on the desk top. Unlike the HTML views, the PDF images retain the look-and-feel of the Notes document. Notes Monster reports include detailed listings and summary reports of the metadata and in themselves provide a useful analysis and overview of the data set.

As the volume of data grows every second, corporations are faced with the challenge of taking data and turning it into something useful. This underlying principle is the driver for business intelligence. On the other hand, as the law firms get savvier and more involved with the nitty-gritty’s of electronic discovery, they want more control by wanting to know at each stage, what is happening to their data, at what stage in the workflow or process is the project with respect to their data, what was discovered and how the data universe looks like. This information is required to forecast and form effective strategies to win their cases.

Internally too, Project managers require constant status updates to provide feedback to their clients which in our case are law firms as well as corporations. Project Managers take ownership of the projects allocated to them and to a certain degree are responsible for influencing client decision, next steps and strategy. Operators have to normalize and streamline file types and understand what discovery techniques to apply to them in order to maintain appropriate chain of custody. Production managers want to control the discovery process, by understanding the data universe, mentally visualize and troubleshoot any issues in the discovery process that may arise due to external factors, develop custom methods to handle specific file types.

 PAIN, PAIN BUT NO GAIN

I had observed and experienced the challenges faced by teams at every level within our business environment. Conveying timely status updates at every stage, troubleshooting process and data issues, framing effective discovery techniques for a data mix of widely varying file types, assimilating project strategies and fostering positive client communication was becoming painful, time consuming and something that was less enjoyable. The question I kept asking myself was how does one meet these challenges without disrupting people’s productivities? How can a mechanism be put in place to satisfy all of the above? Technologically there are several ways of successfully fulfilling these requirements, but which one should I pursue and why?

 A GRATIFYING SOLUTION

In the interest of time to produce results and show value quickly, I leaned towards a solution which would internally face less resistance, be easy to adapt to, seamlessly integrate with our existing in-house systems and application infrastructure and be of tremendous value without spending a lot on implementation. Lex’s infrastructure is built using Microsoft technologies at its core and SQL Server being the corner stone across various products and service offerings made my decision easy to arrive at. We used SQL Reporting Services and SQL Cubes on our existing SQL back-bone and line of service SQL Servers to develop statistical methods to forecast, visualize data, mine data and improve the overall quality and productivity of our engagement and our communications at all levels.

 A POSITIVE OUTCOME

We revisited and thoroughly studied all our applications that worked on a SQL foundation, conducted a feasibility analysis of what was possible, to gain a solid understanding of how to model the data-warehouse. Once the data warehouse was ready and populated with the initial data, I got an application developer to write a .Net application which could be used to trigger repopulation of the ware house. Alternatively we also scheduled this application to run automatically at a time when the strain on the systems was at its minimum. After creating templates for approximately 30 to 35 default reports we exposed it over a SQL Reports Interface as well as MS Excel. The pivot tables feature of excel was exploited to create data visualizations and share it appropriately with our clients. The results started to show. These reports not only became a source of business intelligence but also fostered positive and transparent communication at all levels. The productivity almost tripled and the positive impact on business was evident.

AN EXAMPLE OF BUSINESS INTELLIGENCE IMPROVIZATION: STORAGE FOR GENERATING REVENUE

One of the challenges faced without adequate reports was to identify, track and trace where and how much unwanted and old data was occupying space on our servers, where was that data and what effective strategies should be devised to maximize and leverage its presence. The answer was easy to find, but tricky to implement.

We wrote scripts and scheduled them to run once every month, generating reports across clients, their cases and projects providing us valuable information about the age of the data on our servers. We then pulled information from our sales order and invoicing systems to find out who the sales person was, who the client contact was and who the project manager was.

I was able to convince the management that any data older than 100 days lying dormant on our production servers must be subjected for review by the sales person with their client(s) and arrive at a decision to either archive the data, destroy the data or follow up for generating more projects. If the client was unable to commit to any of the above mentioned actions, then Lex would charge the client five dollar per gigabyte per month.

 This concept was well accepted by the management as it was a fair call and would either reduce the liability of Lex to hold unwanted dormant data or generate more projects/revenue by forcing the clients to take appropriate action.

 Assuming the storage capacity at being 100 TB (terabytes) and 30% being in static dormant state, the potential to earn every month at five dollar per GB per month is $153,600 or 1,843,200 per annum.

In 2007, our electronic discovery processing and production infrastructure was designed to suit a specific off-the-shelf product. There were more than 25 worker stations and 1 worker management server console. This pool of worker stations were all connected to a NAS pool for storage. To begin with there were 3 NAS’s as part of the pool. The worker management server application, controlled requests to and from the worker stations, SQL Server and the NAS’s using a FIFO based queue system. All tasks allocated to the worker machines were monitored and controlled by the worker management server application. Every time the production team started running out of storage space while processing data, a new NAS had to be commissioned in the pool of existing NAS’s.

CHALLENGES FACED BY LEX

Given this situation, Lex faced significant challenges. Every data processing job had to be handled through this queue based application. What this meant was; if a client sent a quick turn around processing job, either an existing job had to be paused or the job had to wait until the existing one completed. In the electronic data discovery business where deadlines for producing evidence in the court of law can be very critical to the case, a FIFO based application was certainly not the answer. As the processing orders grew, so did the unhappiness of many clients. Prioritizing projects across client cases became very challenging. The system architecture and design was also vulnerable to the fact that if the worker management console had to be restarted or any maintenance/upgrades had to be carried out, it would bring the entire processing infrastructure to a grinding halt. This also meant that somebody had to constantly monitor the system which was humanly infeasible. An improvement in or replacement of the existing system was certainly necessary.

MY FIRST HAND EXPERIENCE

As soon as I joined Lex in Feb 2007, my involvement with such a processing and production infrastructure signified to me that a radical change was absolutely necessary to keep up to an ever changing business landscape and growing competition. We not only had to redesign the system architecture which would allow us flexibility and scalability in our ability to process but it was also important to find an off-the-shelf application which would process raw data at faster speeds. One other important criterion was: the off-the-shelf software application had to be configurable within new system design parameters.

A NEW APPROACH

We termed our new design as TBPS (Track Based Processing System) or in short TRACKS. Each track had between 5 to 10 worker machines which were connected to a database server and a NAS via a gigabit switch. The software application that was deployed was such that each worker could manage itself independently and directly interact with the database server. Hence the queue based processing limitation was resolved. Since each track was an independent entity, simultaneous processing of jobs was now a reality. Projects where data processing volumes were large, we would very easily commission additional worker machines to a track borrowing from other tracks. Obviously, small projects required lesser number of workers. As our business grew, it was very easy to commission more tracks. For very large engagements, clients were given dedicated tracks. Each track now became a business unit with dedicated staff and a project manager maintaining it and running projects. It was very easy to measure profitability for the investment made on a track. Most importantly, Lex was now capable of extenuating its risk by building redundancy in its system infrastructure.

EVERY DESIGN HAS BOUNDARIES

The new system architecture design and software application selection was developed to address Lex’s immediate vulnerabilities as well as grow the business through our on demand service offerings. The decision was taken under the assumption that business will grow if our services improve through zero downtime and on-demand service. Although the services considerably improved, our hardware infrastructure grew as business grew and with it grew our IT department. This brought about new challenges. The cost of securing, managing, maintaining and advancing our data center increased tremendously. If this continued, we would no longer be able to compete on price. It was time to go back to the drawing board.

FRAMING NEW & EFFECTIVE STRATEGIES

In this rapidly changing business environment, technological improvisation is imperative to sustain a highly price sensitive market place. Once again a new strategy has to be devised for LEX to cut costs, reduce overheads, provide near zero downtime, mitigate infrastructure risk, compete in a price sensitive market place and provide exceptional service in order to create repeat business and add value to our client’s experience with our company. How can another layer of complexity be extracted from the organization and a strong focus is achieved on providing higher levels of service?

IS CLOUD THE FUTURE?

Following the trends in other industries, I plan to begin evaluating whether the cloud based model is the right answer. However, there are trade offs. Where as cloud computing increases efficiency, scalability and flexibility of hardware deployment, one must fully understand the risks involved. With a pay-as-you-go type structure, users are only charged for the amount of traffic, bandwidth, and memory used. Businesses like ours become more efficient by only utilizing the storage and space needed, while also being assured capacity for any usage increases. The cloud based business model carries inherent risks as personal identifiable information can be distorted, the specific location of data is unknown, and any issues are especially difficult to investigate as customers share their hosting space. As we are constantly dealing with critical data which can comprise of personal information, business processes documents, trade secrets and evidence that can be presented in court; it becomes mission critical to ensure data security. A hybrid approach between cloud computing and owning physical infrastructure at the data center may be the answer. At this point I continue to explore and weigh pros v/s cons of a hybrid approach, what methods must be employed for this approach to be successful and what kind of challenges will this bring about in the future.