Time Matters Performance For The Larger Firm
Recently I did some consulting for a large firm with pronounced performance issues with their practice advantage Time Matters ©(TM). Application crashes, hangs, and general sluggishness were so pronounced that they were thinking of scraping the program and switching to custom software. Time Matters often get’s a bad wrap by many technology professionals in the legal arena. Application hang’s, speed issues, and a steep learning curve often cause many to follow the path of least resistance and blame the issues on the software. The sad truth is, more often then not, many of these issues are underscored by an ignorance of the structural components of the software/database relationship that the program is anchored on. I’m not saying that the application is perfect, but lets be honest, 60,000 lawyer nationwide aren’t using the software for nothing.
An initial assessment revealed the network, servers, and switches were set up properly. TM scheduled database maintenance was being run regularly. A closer assessment at Microsoft SQL server© (MSSQL) revealed several pertinent performance metrics that were out of range. As it turned out, the problem was by no means the application -to the dismay of the IT staff-, rather it was an lack of foresight for the infrastructure supporting the application. As I will discuss there are some common reasons why this can happen with TM. After some rounds of tuning on the database server TM was working at top speed.
In this article I’m going to take a in-depth look at the performance issues faced by large law firms using TM and how they can often stem from MSSQL. A deep knowledge of both the architecture of the TM database, along with SQL server, are a crucial component to solving and preventing performance issues of this nature.
How it Works
Business software such as TM works by reading and writing data to a database, the application itself provides productive way’s to input, delete, and manipulate that data. As of version 10 TM exclusively operates on an instance of MSSQL.
MSSQL is formidable application in an of itself. It is actually an operating system within an operating system and there are technology professionals who specialize specifically in the maintenance and tuning of databases. For smaller firms with small databases and minimal workload, getting by on the built in TM database maintenance is possible. On the contrary, larger firms with high workloads are asking for problems if they do not have competent database administration on they’re consulting or IT team.
Background
The Time Matters © database was not designed, nor optimized for Microsoft SQL server© (MSSQL). While this make sense to a certain degree (if Lexis Nexis had decided to drastically alter the schema of the database it could have been a potentially major issue for any user’s performing upgrades) it is an issue that will hopefully be addressed in one of the upcoming releases. The pertinent outcome of this is that the application can exert a tremendous amount of workload on MSSQL. These effects, can translate into application crashes, hangs, a generally slow user experience, and a decrease in productivity, work-flow, and revenues for your firm.
The Fix
If you really understand MSSQL just by looking at the TM database you can anticipate possible performance issues. Adhering to MSSQL best practices and putting measures in place to buffer the MSSQL workload pressure can be the difference between a productive end user experience, and a firm that is crippled by performance issues. In the example I gave above beefing up the MSSQL practices saved the firm an untold amount of time and money over migrating to a new system.
If you are experiencing performance issues with you Time Matters or Billing Matters contact us today, we can help.
David Wetherell
NYC-SOFTWARE SOLUTIONS
consult@nyc-software.com



2 comments
Do you have any additional information on how to fix the database ?
Sure, I would start with learning about performance tuning. The problem with SQL server is that it is that it is very complicated, and its easy to jump to conclusions, being patient and meticulous are the keys to being effective. Look for initial bottlenecks, learn about perfmon, recording metrics, tools likePAL, and Dynamic Management views. I am planning a post coming up regarding some simple things you can look into to speed up a under-performing SQL server environment, stay tuned.