If you have been active in the LIMS world for some time or are just getting your feet wet with lab information management, you will inevitably encounter people, organizations, or institutions that will adamantly avow “All LIMS are the same”!
It’s like someone saying “All refrigerators are the same; they all keep things cold.” But it is known that the way each refrigerator establishes and maintains temperature differs by manufacturer and product. Similarly, while it can appear from a macro point of view that all LIMS are the same, real differences come to light once you start examining the inner workings of different LIMS solutions.
By the way, you will also hear two ancillary statements associated with the main assertion, which are: 1) “So it doesn’t really matter which LIMS we select” and 2) “The implementation of the LIMS is what really matters”. The first statement will likely come from people or organizations that do not want to expend the effort to do a proper LIMS selection while the latter will come from LIMS consultants that are just seeking to maximize their revenue.
The truth is all LIMS are not the same. This can be seen in a myriad of ways but let’s explore a couple of these now.
Commercial LIMS available today offer a variety of architectures, each of which has pros and cons. Traditional architectures include client/server (thin and thick client) and web-based (zero and “small” footprint). Which architecture is best for your organization will be dependent on many factors, most of which will be dictated by your IT group and the IT standards they have established.
While that’s all well and good, you may be asking yourself why the LIMS architecture matters when determining whether or not all LIMS are the same. One reason is the amount of resources and effort required to install and/or upgrade the client in a thick client/server LIMS on all the desktops, laptops, and mobile devices will be much larger compared to doing so for a web-based LIMS.
The architecture of the LIMS can also have a huge effect on how and where configuration and customizations are accomplished. In a thick client/server environment, it is common that the LIMS forms will be configured and customized at the thick client presentation layer, while the same tasks might be done at the application layer in a web-based LIMS. So what’s the difference? When it comes time to upgrade, depending on the architecture of your LIMS, you will be looking at different amounts of time and resources needed to accomplish the project, with the thick client/server solution requiring more.
A common claim of the “All LIMS are the same” camp is that all modern LIMS have pretty much the same functionality and capabilities available. Again, at the macro level, this statement appears to be true. However, LIMS solutions differ greatly as to how all the functionalities and capabilities are provided. Are they standard, “Out-of-Box” (OOB) functions and features that are ready to be used when you install the system? Or are they “possible features” that would be available once they have been developed using the LIMS tools provided with the system, aka a Toolkit-style LIMS? In other words, is the LIMS offering all these features and capabilities standard or will you first have to “program” everything?
In this case, the big difference is not what the LIMS can do but how one goes about implementing the capabilities. Surprisingly, OOB, feature rich LIMS are not always preferred over toolkit style LIMS. Organizations that have truly unique needs, requiring extensive customization of any LIMS as well as those with large, well established IT departments, will often prefer a toolkit style LIMS. In these environments flexibility and control are deemed more important than standardized, vendor supplied and supported features, and of course, a toolkit LIMS is a good source of job security for the LIMS IT folks.
Do you believe that all LIMS are the same?