Designing a System for Remote or Offline Working

March 1, 2002

As a supplier of computer solutions to the legal market, one of the more difficult questions that a potential customer can ask is, ‘I would like to work from home or at court, what do I need to do this?’ It seems an innocuous question but it is one that is guaranteed to cause your supplier to groan inwardly. Why should this be?

The honest answer is that providers haven’t really had a very satisfactory solution to the problem – until now. From the moment that the first firm of solicitors implemented a computer system, there has been a requirement to be able to work as effectively out of the office as in it. Despite all of the improvements and changes that have occurred in the IT industry, the fundamental methods of remote working have not changed since the first bakelite telephone was placed into the first acoustic coupler.

What We Have and What We Want

The current methods of using case management systems whilst out of the office usually involve using a telephone connection along with some form of terminal server product such as Citrix, Terminal Server or PC Anywhere. Although this solution works well, it suffers from three fundamental restrictions which limit the effectiveness of the approach. Firstly, a solicitor may well be trying to work in a location where a telephone line is not available or it is not practical (or even legal) to use one. Secondly, setting up the infrastructure for such a solution may be very expensive. Lastly, using a telephone line will usually involve a lengthy and expensive telephone call, in the situation where this is the only telephone line available it may well cause inconvenience to others.

What we really want is the ability to use case management systems, post time, request cheques and other financial postings, view financial and time ledgers, draft bills, and run reports, all from the comfort of our own laptops without the need to be forever connecting to the office. We can synchronise Microsoft Outlook e-mail, contacts, and diaries and then use them without being online. We can even keep documents in offline folders and update them without being online. Is it really too much to ask to do this with our case management (CMS) and practice management systems (PMS) as well?

Problems and Cornerstones

Let’s consider why using CMS and PMS offline is so difficult to achieve. There are many issues to bear in mind if you want to work offline, and then subsequently merge your data into central system, but they all come down to one thing – data integrity. Data integrity is the prime, possibly the only, consideration that should drive all of the designer’s thought processes. Making data integrity the Holy Grail means that you have to answer some fundamental questions, such as:

  • what happens if two people create a client with the same name?
  • what happens when two or more people post time to the same time ledger?
  • how do you deal with one person requesting a payment out of office and another doing the same thing?
  • how can the system deal with two individuals working on the same step in case management?

Having understood all of the problems associated with data integrity, you have to design your way around them BUT, and you’ll notice that this is a big but, you have to remember that this is not an intellectual exercise. You are trying to develop real systems for real people to use. Complex solutions are unlikely to be appropriate for the peripatetic lawyer. This brings us on to the second consideration for the design of an offline system – usability. It is important that the application behaves in fundamentally the same way as the office-based application it is designed to support. Ideally it should be the same product, as this significantly reduces the cost of implementation and therefore the cost of ownership and administration. If your users can work in exactly the same way in the office as they can out of it, you have moved most of the way to finding an adequate solution to the problem.

No article about remote working would be complete without considering the security issues. In the case of offline working they fall into two categories. In addition to the usual one of unauthorised access to your networks, there is a new concern. For offline working to ‘work’, the offline users will have to have data on which to work. The more data they have, the greater the damage done in the event of a laptop or notebook being lost or stolen. It is vital therefore that a system is designed to allow users to take only a subset of data from the main system, this means that the loss of a remote computer has a lower impact.

Finally, consideration has to be given to the manner in which a modern law firm works, especially those dealing with large and complex cases. It is not unusual to have several individuals working on a single case. If these are all office-based then there is no problem but, if some or all of the case workers are working remotely, any offline solution has to be flexible enough to deal with their differing demands.

In short, a successful offline solution for PMS and CMS must be designed with the following cornerstones, Data Integrity, Usability, Security and Flexibility. All of this must be achieved without loss or compromise on functionality.

Building from the Cornerstones

All of these issues share a single concern. To make the system usable and flexible, enough data has to be available to the offline user; however, this must be tempered by the need for security and integrity considerations. If we assume that an offline user wants to work fully on a particular case, the following information may be required to support the work: all client and matter information relating to the case, all time and financial postings relating to the matter, and all documents, forms, and other steps related to the case. While this does not seem too onerous, care must also be taken to ensure that any supporting data is also available, such as narratives, time rates, activity types, case codes, as well as any user-defined data required.

There are four types of database table that are required for offline working, and it is necessary to understand into which category each one of your own database tables falls. They are as follows.

1. The entire table is required without filtering, for example narratives and time rates.

2. All of the columns in the table are required, but the data should be filtered to reduce the amount stored offline (one example of such a table may be time postings).

3. The table and the data contained in it are not required (eg purchase ledger transactions). Clearly if, in your offline model, you want the purchase ledger to be accessible offline, you will want to include the table.

4. Tables are required to support the offline operation, but are not required online or to be synchronised with the data held online. There is a potential problem with re-building the database in the event of a failure using these types of table. As a preference we have not used this type of table in our offline model.

It is important to think long and hard about exactly what functionality you require for your offline model and, as a result, which tables are required.

Having decided on your offline database requirements you then need to consider how you are going to put data in and then, more importantly, how you are going to synchronise this data with the main system and how often. The ‘how often’ is simply a matter of individual choice, although you may want to insist that your offline users synchronise at least once a week to ensure that time and billing records are up to date. It is important to be able to enforce these business rules wherever possible.

How you are going to do it is a much more challenging process and forms one of the most fundamental parts of an offline data model. Get it right and your new system will be a joy to use, get it wrong and it will probably fall into disuse as it will have failed in the second of our design criteria.

The Conflict Problem

The central problem is one of conflict. If anybody tries to do the same thing at the same time in any computer system there is likely to be a conflict of some description. In an ‘online’ situation however, these conflicts, which will occur all the time, are likely to be solved by the database simply queuing changes up and then re-trying them until there is a success. As this process can occur hundreds of times a second, there are rarely any problems – providing the underlying database has been properly designed.

To help illustrate this point let’s take a very simple example of a time posting which, when made, inserts a time posting into a time posting table and updates a balance on a table of matter details. If we imagine two people posting time to the same record we can see that in an ‘online’ database there may well be a conflict caused by two people updating the same matter balance at the same time. Inserting new time postings does not in itself cause a conflict provided that the primary key, the unique set of data that identifies the records, is unique irrespective of who generated it. When a database is ‘offline’ we cannot rely on the databases doing this for us. An offline user may update a balance which is then not synchronised for a week, and it is only then that a user will discover the conflict. Although it is vitally important that your system tells you about any conflict, you need to try and design your whole database so that the chance of there being a conflict in the first place is reduced to the extent of being almost impossible. This is such a fundamental point that it may be impossible for your current database structure to be adjusted to deal with an offline model.

Documents and Forms

Once you have designed your database to work offline, you then need to consider what will happen to documents and forms. If you are going to work on a case offline you are going to need a copy of all of the master or template precedents at your disposal and quite possibly all or some (depending on volume) of the documents and forms that make up the case historically. It will need to be possible to download these whenever you synchronise your data. In fact, for a fully secure solution, it would be useful if all documents were synchronised whenever you synchronise the database. This means that your only exposure in the event of a laptop being lost, stolen or damaged is data up to the last synchronisation. Whilst this does not remove the need for a proper back-up policy, most people I speak to cannot remember the last time they backed up a notebook!


In summary then, successfully meeting these challenges means that it will now be possible to work offline on a CMS and PMS provided your database has been specifically designed to deal with this method of working, and your procedure has been amended to recognise that users will be away from the office and can deal with the extra challenges that this presents. Within the next three months we intend that there will be several solicitors working in exactly this way. After years of striving to provide up-to-the-minute information for the wired world, maybe it’s about time we began to recognise that it might be at least as important to use the information we have as it is to have information (which we cannot use).

At last I can look forward to questions about getting out of the office. You never know – it might catch on.

Mark Garnish is the Technical Director of TFB PLC and has spent the last 18 years designing and implementing IT applications for solicitors throughout the UK. TFB PLC have recently released what they believe to be the first completely offline Case and Practice Management System.