Every time the subject of a customized LIMS or the customization of a LIMS comes up, the guardians and pundits of Industry Best Practices come out of the woodwork to chime in on the topic. Heads are shaken and fingers are pointed. Dark clouds start to gather overhead and horror stories are made ready. The pronouncement that a customized LIMS or even LIMS customization is bad and is not an industry best practice is made in deep, all knowing tones. The evil person who dared to bring up the topic slinks off in disgrace, never to be seen or heard from again for the duration of the LIMS project. But is this really the case? Is a customized LIMS or LIMS customization really all that terrible?
Before delving deeper into this topic let’s get some terminology established. There is often a great deal of confusion as to the definition of configuration versus customization when it comes to LIMS. LIMS configuration is commonly defined as changes made to the LIMS through internal LIMS system tools that do not require any programming. LIMS customization, on the other hand, is changes made to the LIMS through internal LIMS tools or external tools that requires programming to accomplish. An example of configuration is therefore, setting up the user access privileges by clicking a series of boxes or radio buttons. Whereas, an example of customization is creating a new LIMS function in a programming language like C+ or even the proprietary programming language of the LIMS itself.
Back in the early days, virtually all LIMS were custom built by the organizations that implemented them. In those days there were very few, if any, viable commercially available LIMS. The resulting LIMS were often exactly what the implementing company needed but the cost and effort to create and maintain them was found to be very high. Systems were generally “hard coded” which made them inflexible and any changes or improvements that users requested took tremendous effort if the IT resources were even available to address them. Eventually the organization would update their IT infrastructure (operating systems, databases, programming languages, applications) and the customized LIMS would stop functioning and the labs would be in turmoil.
Later, as commercially developed and supported LIMS became available they became a better choice for many organizations. Since these LIMS needed to support many different customers and their needs, they were designed to be more flexible and configurable. However, customization of the LIMS still occurred and depending on the particular LIMS product, those customizations may or may not have been developed and implemented in a supportable way. It was not unusual that the customization was done in the core or source code of the LIMS. So again, if the IT infrastructure was updated or the LIMS vendor came out with a new version and the customer upgraded, the customizations and the LIMS would break and the labs would be in turmoil.
This then, is the genesis of why customized LIMS and LIMS customization in general is thought to be bad and why they are the black sheep of the LIMS world.
In the pursuit of lionizing customized LIMS it is easy to overlook a critical fact – they EXACTLY meet the needs and requirements of the lab organization. With a custom LIMS there is no need to change your laboratory processes and workflows. No need to adapt to the way the LIMS does things. A custom LIMS will be, and will work, just as you want it to. Further, it is virtually impossible to have a LIMS support all your needs and requirements with “out-of-the box” capabilities and functionality that are only implemented via configuration. Unless, of course, you are willing to subsume your needs and change your lab processes to only those supported by the base LIMS, and very few if any lab organizations are will to do so.
In essence, a customized LIMS and LIMS customization is not bad. It is how the customization is accomplished that can be bad. And as time went by, the LIMS vendors recognized this and began offering Application Programming Interfaces (APIs) that enabled customizations to be created and implemented outside the core product. Additionally, they started providing constructs within their products where the customizations could reside such as specific user database tables. In this way it became possible to customize the LIMS in a supportable and sustainable fashion. When upgrades to the LIMS product were made, the customizations would not break.
In fact, several commercially available and very popular LIMS come with very extensive Software Development Kits and are designed to be customized by each organization that chooses to implement them. The appeal of having a supportable and sustainable LIMS exactly meet the current and future needs of the lab organization without the need to compromise or change is very strong. Of course, it is imperative that organizations that elect to utilize LIMS architected in this way have a very strong IT department and internal funding to implement, enhance, and maintain their LIMS. It is also critical that these organizations have or have access to subject matter experts from the lab that can work with the IT staff to ensure that what is delivered meets the lab’s needs.
Tell us if your LIMS is configuration only, configuration and customization or a pure customized system. If you have customized your LIMS or have a completely custom LIMS, have you experienced the “bad” or the “good? If you were to implement a new LIMS today would you consider a customized LIMS?