By Dera J. Nevin
Almost all the work that I do in evaluating, buying and implementing legal technology for use by lawyers is directed at strengthening the practice stack. I distinguish the practice stack from enterprise technology or stand-alone (ad hoc) technology. I define the practice stack as being the technology toolkit containing features and functions unique or tailored to the delivery of legal services. While the ability to apply this definition gets muddy in practice, I find it helpful to focus on the practice stack because it draws attention to how any particular tool under consideration falls into the total enterprise architecture and ecosystem. Considering the part as it relates to the whole helps clarify whether any individual new tool, or tools in the aggregate, place undue pressure on the computing architecture and particularly the desktop.
Let’s dig into what the legal practice technology stack is by first looking at what it is not. The first and biggest distinction I make is between practice technology and enterprise technology. This latter generally divides into two main slices. First there are the back-office and administrative technologies: things needed to manage and run the business that lawyers and fee-earners may or may not touch. Examples include the finance and accounting systems and, because these are law firms, conflict and new business intake related-technologies. But these can also include enterprise content management and record-inventory systems, Human Resources and payroll systems, marketing systems for contact and prospect management, pitch development and management, banks for brand identity and, increasingly, expertise management systems. Increasingly, these systems are becoming more sophisticated, and significant attention is being paid to data flows between these systems. Most of these are server-based and are increasingly customisable (not just configurable) and are commanding greater capital expenditures. Only a limited number of these systems are truly cloud-based.
Second are the enterprise productivity technologies that everyone in the business might use, such as a Microsoft productivity suite or email (or similar communications channel, such as Slack). Because so many lawyers use email, Word (or Excel) to develop work product for clients it can, at first, seem that these are practice technology tools; however, consider that everyone in the firm is using these tools (for different things) and also that usually some other technology or attribute brings the content created by these tools into the practice file. For example, email must be filed into the client file (not all email is client-related) and text-based documents are often manipulated (including through secondary technology) into appropriate formats that are practice-ready (think of the extensive macros and styles needed to turn a Word-created contract into something that links defined terms to key clauses, for example).
Practice stack technology is that which is essential for lawyers and fee-earners to deliver services and outputs unique to law. Most of the legal tech phenomenon is concentrated here, and examples are legion. Legal research systems and eDiscovery technologies may have been among the first unique and fully interoperable examples, but other examples now include applications and systems to manage IP assets (patent and trademark filing and management), due diligence systems, contract management and automation systems. Consumer law applications, such as family law child and support calculators and real estate closing managers are also in this category.
One characteristic I highlight for practice stack technology is that it gets deployed across an applicable practice group. This distinguishes this category from stand-alone (or ad-hoc) deployments which are applications that may be deployed to just one or two users or machines. One example of this might be trial management technology which may only be needed by personnel in hot seat roles. While this is certainly practice stack technology, such applications are in a category by themselves, usually due to their deployment profiles (and sometimes cost).
Practice stack technology remains fragmented, even within a category (like deal support) with many individual applications not “talking” to each other or allowing for easy data-in/out scenarios. Many have features and functions which either don’t play well with enterprise technology (i.e. integrating the app into Word breaks something else) or don’t integrate at all, creating data silos or lakes of data with unique metadata attributes. Generally I find that vendors of these technologies cannot do a “lifecycle of data” journey, leaving it to buyers like me or other users to understand the full downstream impacts of adopting individual applications in context.
Additionally, while most practice stack technology can give you specifications of what infrastructure is required for performance, there’s little communicated about the impact overall on desktop engineering. Increasingly the action in legal technology is happening in these applications, many of which still need to fall behind the firewall, and the likelihood of adoption and sustainment decreases with the number of individual icons confronting any lawyer as they choose to do work. It’s not just your technology, its the drive to create and implement dozens of individual apps requiring launching that are increasing adoption challenges. This reduces the likelihood that firms can adopt true “thin client” strategies (which, for some, might be ideal and further facilitate movement to cloud-based systems).
The reason that attention to the practice stack matters when buying for lawyers is that this is where so much of the specialised, fee-earning works gets done. If there is to be any change to the way lawyers work, in terms of efficiency or business process, it is likely here. Sure, lawyers can learn to use Word and Excel better, but systematic changes to workflow are likely to happen outside productivity applications. The deployment and configuration of practice stack technology also significantly impacts IT and security arrangements: these are among the firm’s most risk-sensitive assets. Finally, in these systems lie significant data assets that could be tapped for value, either as precedents or predictive exemplars. Getting the practice stack right could yield both efficiency (bottom line) and revenue generation (top line) benefits. The practice stack may also offer untapped opportunities for lawyers to bring new net value to clients, and is the place where lawyers may experience the greatest gains in work enjoyment (for example, through productivity or better UX).
I don’t foresee any short-term change in how we generally approach the practice stack, but the impact of dozens of individual applications directed at practitioners may be a significant barrier to widespread re-engineering of service delivery workflow. This could, in its own way, be slowing down greater adoption of technology by lawyers and fee-earners. Certainly, in my first domain of eDiscovery, adoption levels didn’t increase until the technology became integrated; that’s because systems, application and data integration increases ease of use and drives down overall adoption costs. For this reason, while the current explosion of interest in LegalTech is, on balance, a good thing, merely having more applications is not necessarily better if these do not play well together in the practice stack ecosystem and, overall, increase the complexity of navigating the desktop environment.
Dera J Nevin practices Information Governance and eDiscovery at Baker McKenzie LLP and is affiliated with its WhiteSpace Collab Innovation Hub. Opinions expressed in this article are the author’s alone. In this space she proposes to address common questions from readers about the evaluation and implementation of legal technology. You can contact the author at dera.nevin@bakermckenzie.com.