Plug and play LIMS – did it become a reality? Even though more things can connect to more other things, plug-and-play still isn’t reality.
In the Last Week-and-a-Half
Just in the last week, this is a partial list of a few of the tools I’ve had to download and/or use. It doesn’t even include the LIMS products and their proprietary tools:
- TypeScript
- Node.js
- Python
- Chrome Browser
- Safari Browser
- Firefox Browser
- WordPress
- AEM (Adobe Experience Manager)
- SSMS (SQL Server Management Studio)
- LINQPad
- MS Excel
- Google Sheets
- MS Word
- Google Docs
- Lighthouse
- Chocolatey
- MS Azure
- AWS (Amazon Web Services)
- Slack
- JIRA
- Asana
- A wiki
- Git
- GitHub
- BitBucket
Does your life look like this? I hope not. And if you’re wondering how many different logins I now have for everything, just don’t ask…
Have Things Changed? Not That Much
In the old days, many things did not work together. To get anything to work with anything else took programming.
Ummm…it sounds just like right now, doesn’t it?
So, every LIMS-to-SAP or LIMS-to-MES or any other something-to-something interface is a lot of programming, for starters.
Plug and Play LIMS – a Turnkey System
Just like the concept of the “turnkey” system, which still is just something sales people talk about and none of us actually have, a plug and play LIMS doesn’t seem to be a reality, either.
There are always more tools. Professional-level tools tend to need some work to get them to work with other tools. Here in 2020, anyone who believes these marketing terms really hasn’t been paying attention to the world around them.
Back to Plug and Play LIMS
In any case, as I go from project-to-project, people are using a wide variety of different tools. Today, while more tools can be used with more different situations, they don’t necessarily entirely integrate.
Even as the most simple example, with many LIMS, we tend to create database queries that we can run from inside the LIMS but that are in the native query language. One traditional example is that, with something like the LabWare LIMS / ELN, we often write the more complex queries using SQL. Most people think of SQL (Structured Query Language) as something so standard that we can port it from machine-to-machine. However, anyone who has ported their LabWare LIMS / ELN to their desktop to use with a database besides the one they are using at a network level might find that their queries won’t necessarily run. That is because there are slight differences between different databases. A command that works in SQL Server might not work in Oracle and vice versa.
So, even within something we think to be pretty standard, such as SQL, it doesn’t just port from one database to another.
Here’s another example – if you’ve worked with any mobile applications, you’ll see that screens render differently between different models of what is the same brand and type of device. Programming for mobile devices has gotten more standardized but there are still individual program blocks that have to be created specifically for various devices.
A Note on Interfaces
For all the LIMS-to-ERP, LIMS-to-MES, LIMS-to-etcetera interfaces we’ve created, each one has slightly different issues. Granted, each time there is a new combination, a new set of people are assigned as if it’s a 100% brand new concept, to do everything as if it has never before been done. While I find that ridiculous and frustrating that few services companies know how to leverage the experience that’s out there, I’ll admit that there is always some aspect that is different. Each customer does have their own custom tables and fields, for example. That is NOT the same as being 100% brand new – I just want to stress this point! However, let’s admit these are never plug-and-play, either.
Finally
No matter how time marches on and how much things change, in some sense, they remain the same. We still have a multitude of different tools. Things don’t “just work” together. Thus, there is always a lot of money to be made in any tasks that pull data out of the system. That’s true whether that data is pulled out for something like knowledge management or to interface with other systems.
Unfortunately, this means that many companies will remain without as many interfaces as they’d like. There’s limited money to make all this happen and that’s just the bottom line. Companies might dream of more automation but, in the end, are limited by their budgets for these types of projects.
With that said, it’s as if they all got together and made a secret plan to purposely use all entirely different tools. Yes, it’s a LIMS conspiracy and I’m a LIMS conspiracy-theorist! 😉
If someone reads this and has a company or department depending on ELM/LIMS data, I have the same feeling: the Vendors and Integrators form a conspiracy against you. Possessing the lock and key to your sciebtific data, the foundation of truth where the company depends on, they got you by your balls. Industry 4.0 is all about data, your company IS data. Be careful that the data of potentially new products and compliance of everything that is produced, went to stock or sold, is standardized and always available to you – independent from vendor or integrator.
David, I want to add yet another thought to what you just said for readers to think about. First of all, I do understand that data is proprietary. But while processes are also proprietary, many processes within an industry share a lot of elements. More companies need to do more collaboration on finding ways to meet the greatest number of their needs with a basic work process. This could become the model for the initial RFPs. This could be the model that they can build upon as they interface. They could share some struggles with implementation. While it doesn’t mean they all use the same software, it will hopefully give everyone a common element to start with. It could be an initial basis for the implementation and interfaces. With that said, the next thing someone would do is try to use this all for the entire RFP and effort beyond that. That won’t work. It’s still just a starting point.