(This is the English translation of my article from 24.03.2019)

The most viewed post in my blog so far is by far my text about cloudbased law firm software. In my opinion, this continuing interest in „classic“ organizational software alongside the „new“ „LegalTech” topics such as „Document Analysis with AI“, „Workflow Automation“ and „Document Assembly Solutions“ is mainly due to the dissatisfaction of law firms with the solutions currently in use in the area of „law firm organization“-processes. This dissatisfaction results after my discussions and professional experiences above all from the following circumstances:

1. Unsatisfactory remote and mobile usage capabilities

Many applications in the area of case management, contact management, service recording and billing have been around since the 1990s and have now become technologically „outdated“.

As already described in detail in my blog entry on cloudbased law firm software, the dominant organizational solutions at law firms in Germany and Europe were conceived and developed long before the Internet and therefore far before the now possible system architectures (e.g. microservices, serverless architecture).

The former “state-of-the-art” technology of desktop applications with connection of locally installed applications to centrally hosted databases (so-called „client-server architecture“) unfortunately now „prevents“ a simple technical implementation of these kind of applications on mobile devices or a general browser-supported use.

2. Lack of possibilities for connecting third-party applications outside the law firm organization area

More and more law firms are also discovering that, when introducing new applications for process optimization (e.g. when implementing legal project management methods in case processing or when introducing methods for the rapid creation of standard documents), the organizational software used so far often becomes a bottleneck on the technical level or even leads to the failure of the project.

Why is this so?

A „characteristic“ feature of many solutions currently used in law firms in the area of mandate/corporate organization is the implementation of the concept „One (software solution) for everything (application areas)„.

Based on this concept, the providers developed applications that bundle all organizational topics (contact management, case data organization, document management, service recording and invoicing, accounting, controlling and reporting) of a law firm in one application.

They therefore designed their programs as „monolithic blocks“ and invested little to no resources in technical possibilities for connecting solutions from other manufacturers via interfaces (APIs).

However, this lack of connectivity now leads to numerous serious problems in the introduction of new software applications in law firms.

In order to describe this problem more concretely, a small example is given below:

A LPMS (Legal Project Management Software) is to be introduced in the handling of matters using Legal Project Management principles. An important programmatic component of  LPMS is the assignment of tasks to persons involved in the mandate / project by the responsible project manager. In order to enable this project manager to determine -before assignment- whether the „potential“ assignee has enough time at all to carry out the desired activities on time, the LPMS should be able to access information from the office organization software regarding existing deadlines and periods of the „envisaged“ agent and make this available to the user within the application. If such a connection is not possible, because there are no corresponding interfaces in the office organization software, the project manager would always have to manually switch to the office organization software (as a workaround) before creating and assigning a task, then „manually“ search for the required information in order to decide whether the “planned processor” of the task still has sufficient free resources at all and then finally switch back to the LPM software and make the corresponding entries there.

Sounds tedious? It is. And in the case of many tasks to be assigned, the „death“ of any sensible project management.

This small example illustrates (hopefully) a little how important a reasonable API on the part of the organization software is for a successful implementation of new software solutions.

3. Lack of flexibility in adapting functionalities in the field of law firm organization itself

However, not only the introduction of software outside the actual scope of case management solutions, but also the use of existing organizational software itself is increasingly becoming a technological obstacle to successful business models in legal consulting.

Digitalization and the associated changes in the expectations of existing and potential new clients („more for less„) mean that law firms have to adapt their business models. Possible differentiation potentials within the market could arise, for example, with the payment models offered or with the involvement of clients in the case processing.

The aforementioned changes in legal advisory services will also lead to a further increase in diversity in the organizational structures and working methods of law firms.

This inevitably requires a corresponding reflection in the organizational software used. A practical implementation in the corresponding applications is therefore an essential success factor for future, changed business models.

The above-mentioned application approach „One fits all“ of the providers of previous law firm organizational software „prevents“ the necessary reorganization with the actual case management software due to a lack of interface connection and open program structures, either by replacing individual modules (e.g. accounting, service recording and reporting) with more suitable solutions from third-party providers, or by extending existing functionalities with (law firm’s) own programming solutions.

A necessary deactivation/modification of individual function blocks for this purpose is (currently) not supported by any of the previous providers, and it can also unfortunately be doubted that it will be possible at all to upgrade current solutions accordingly.

This lack of adaptability is/will therefore be a real „blocker“ in the necessary adaptations of law firms to their business models.

4. Possible Solutions

Since the existing solutions are becoming increasingly „problematic“, how could a sustainable organizational software be outlined?

For the reasons given above, case management software for law firms (and also legal departments) should be implemented as far as possible using an open platform architecture. Such an architecture would have, among other things, two major advantages

• Efficient and standardized interfaces (APIs)
• Modularity and separation of individual modules
• Central provision of cross-module functionalities

Even if it is not immediately obvious for the manufacturers of former “old style” solutions, such an architecture model would have important advantages for them

• On the one hand, the attractiveness of the platform solution would be high, since the law firms would now (finally) have a solution at hand to be able to implement their special requirements without having to develop a complete system themselves.
• The maintainability of the solution is also increased and simplified for the manufacturers themselves (modularity).
• In addition, a uniform user management, which is provided by the platform solution for all interfaces/modules, combined with an adaptable interface container, could simplify and accelerate the development of modules (time to market is also becoming increasingly important here).

Doesn’t this approach sound good?

I think so and so – true to the motto „make instead of talk“ – I have already started to think about the conception of an appropriate solution (hacking is just fun).

As soon as first useful results are available, I will report about it here in my blog.

Of course, I would be very happy to receive any comments, suggestions etc. on this subject.

This post is also available in: English (Englisch)