Modular Development - Object Oriented Programming For Legal Extranets

It is critically important when building your legal extranet to write modules rather than an entire system. What do we mean by this? We mean that you want to be able to "plug in" or "unplug" different modules which different clients might want to use. Some clients might want only case management. Other might want a simple trial calendar. Others might want a document depository. And, some will want an entire suite of all these capabilities (and perhaps more).

If one properly writes a legal extranet system in modules, one can quickly and easily add them or remove them from various implementations, thus providing clients with a customized version of the functionality they need without a complicated interface or additional costs or extensive amounts of time to deliver the functionality.

The modular approach should apply both to the ability to add and remove modules from a specific client implementation, but also to the menu interface so that the manner in which the modules are provided to users also is flexible and can be modified to meet the requirements of specific clients.

This modular approach to functionality can even help to turn your product into something totally different, yet useful, for your clients. For example, with the proper amount of flexibility provided by object oriented development concepts, one can, with relative ease, transform a litigation case management product into a portal for purposes such as a "business development" portal where a practice group can post articles and case law of interest within a similar extranet framework (same system and code, but different entities storing the data thus creating a seemingly totally different product using the same application code).

Another additional benefit to modular development is in the reduction of lines of code within a system and in the amount of QA / testing one needs to do to properly prepare a system for a client. Obviously, if modules can be reused, a set of code previously fully unit and integration tested does not require the same, deep level of testing when deployed to other clients.

Of course, there are other factors one also needs to consider when constructing a mechanism to deliver a customized extranet (security levels, the ability to quickly and easily change the user interface, the ability to post up client specific graphics, the ability to alter login screen text) but the adaptation of a modular programming strategy focusing on building program objects which can be placed into client implementations with relative ease (both in terms of implementation as well as in terms of minimizing the amount of system testing required to prepare the new system for client use from a quality control standpoint) is a practice those application development organizations serving the legal community should embrace.