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?
I would be interested to see the article update to include your opinion on the Total Cost of Ownership (TCO) and Time To Value (T2V) impacts. Applying the ‘have it your way’ (Burger King) principle is fine and dandy for companies with very deep pockets but in today’s climate of having to stretch those project dollars further I can’t help but wonder if this has tipped the balance on this question. Customization is perfect for a T&M Consultant, but is it really in the best interests of the Client?
The TCO and T2V for fully custom LIMS which are started from scratch without using a commercial LIMS starting point is very high to the point of being untenable, in my opinion. I would, however, say that several commercial LIMS systems available today offer a starting point but a completely customizable environment. Utilizing these systems as your “toolkit” the TCO is higher than implementing a configuration only solution but it is still viable. How can I say this? Well several of the leading LIMS vendors do offer customizable systems and they are very popular and successful. The T2Z would be longer if a fully customized system but with a well planned phased approach this can be managed.
I think it is all well and good to say NO customization but I think that LIMS customization and a fully custom LIMS are viable and being implemented on a regular basis.
By the way, most custom LIMS or LIMS customization that I have run in to were developed by a customer’s IT team, not necessarily a T&M consultant.
Apologies for coming in late, from an oblique angle, and not up to date.
Customisations are very popular in Open Source Software naturally geared for it to facilitate distributed coders already working on the system. Successful professional Open Source LIMS use documented conventions, proven infrastructure, tech manual, test and upgrade regimes.
These projects change the TCO landscape a lot. Costs start from a low baseline, the software is free and can be used by unlimited users.
Open Source Companies offer professional customisation services and are complimented by dynamic user and developer communities. , Many are subject matter experts, and T2V will be the same if not faster given the assistance available.
TCO nevertheless and as always, depends on how much customisation will be required for the best match to requirements for the different LIMS on offer, easily resolved in a spreadsheet;-)
The tension between the benefits of a LIMS that has no custom code and the benefits of a customized LIMS is the reason that Autoscribe designed its Matrix Gemini LIMS with such robust configurability. Our Configuration Tools mean that we can accomplish a completely customized fit without altering the core code of our software. Once people see the extent of this capability is what sets Autoscribe apart from other LIMS vendors.
Unlike the article, we do not find that this ability requires much stronger IT and larger funding. As the article mentions, it does require a clear understanding of their workflows and processes, which is part of the underpinning of any successful LIMS implementation.
I have to take issue with you on the definitions that you have used in your article and some of the sweeping statements you have made. It may be true that for many of our competitors the way you describe configuration is completely right. However, you do make a sweeping statement that is completely incorrect when applied to the Autoscribe Matrix LIMS family.
We regard setting up user access, quoting your example, as a typical task for a system administrator using the functionality provided within Matrix LIMS. This is similar to the setting up of test records, product records etc. and has nothing whatsoever to do with configuration in our terminology.
Autoscribe has developed its well established configuration tools for the purpose of defining the workflows, screens, menus and the interactions that follow for each individual user company. In short the user experience can be defined using the configuration tools without using custom code. We call this genuine configuration. Let me quote our examples – it means the design of workflows with one or multiple paths, the complete design of each screen as necessary (in truth this applies very much to screens needed before result entry as from that point on many customers have similar requirements), the terminology including language changes and much much more. Matrix LIMS is configured to meet the requirements of our users on an individual basis.
What benefits does genuine LIMS configuration offer?
There are many but here are some examples:
1. Configuration tools are supplied as standard with Matrix Gemini thus allowing authorised users to further configure the system as business needs develop. This means that the system keeps pace with changing business requirements resulting in a longer system life and lower cost of ownership.
2. Also leads to less reliance on Autoscribe although we provide a service to those customers not wanting to do their own configuration.
3. Programmers are not needed for genuine configuration work.
4. Configuration tools provide a dynamic view of the screens being worked on unlike a coding approach.
5. All customer created configurations are supported by Autoscribe at no extra cost on the support agreement.
6. Initial training on the configuration tools involves a 3-day course.
7. Configuration is faster than coding and leads to lower system cost..
8. Simplifies the validation process particularly when changes are made. Only one screen needs to be tested, for example, if a change is made on this screen.
9. All screens are version controlled allowing easy reversion to earlier examples of a screen.
10. Matrix Gemini comes as standard with a development database environment so that all on-going configuration work can be conducted and tested before transfer to the live database.
11. Autoscribe has one core coded system to support and upgrade.
12. Configuration files are stored in the database and survive any upgrade process.
I sometimes hear that even our genuine configuration approach cannot be as powerful as custom coding but we have configured, as an example, a lottery management system without writing one line of code – all done with configuration which explains why we can supply systems to a very wide range of market sectors and applications in the scientific laboratory area.
Our configured Matrix solution do EXACTLY meet the needs and requirements of the lab organisation. With Matrix LIMS there is no need to change laboratory processes and workflows. No need to adapt to the way the LIMS does things. Matrix LIMS will work just as you want it to.
Your statements “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.” are completely incorrect when applied to Matrix LIMS.
I should be happy to arrange a web demonstration of Matrix Gemini so that you can appreciate the power of what we have developed.
I participate in the implementation team of a LIMS for company in the mining sector and some cases it became necessary to customize some points so that the software had a better grip to the business, was very good. however, one should keep a very great care in planning any customization for it to actually be effective and must be kept updated documentation of historical changes so that when performing any update LIMS customizations are also current and past again for a battery of tests to make sure no errors are applied in the production base.