The "An Introduction and Guide to Successfully Implementing a LIMS (Laboratory Information Management System)" document is full of a lot of what you would expect but very little meaningful information for someone really looking to implement a LIMS or functionality thereof. Like so many others of its kind, this paper is a discourse about vendors and users and is rife with broad and vague statements about tendencies without going into very much depth. Oddly enough the paper begins with, "...LIMSs have been around for over twenty years, but still remain difficult to implement successfully." Perhaps the problem is in the approach to these systems? I mean, in twenty years if laboratories are still having problems implementing systems would you not think it was high time to adopt a different approach toward implementing them? Virtually anything is better than beating the dead horse one more time.
I suppose it is the normal cycle of human learning to first to witness phenomena and become content with snap (quickly made) explanations of why it might be occurring. Then, at a later point, one can submit those concepts to rigorous analysis to see whether the ideas stand or collapse. In LIMS it appears that something (I will not point any fingers) has effectively stunted the analysis of these systems from taking place. Instead we find the endless merry-go-round of introductions and platitudes about these systems without deeply investigating them.
Luckily I elected to break away from this and created my own farm system. The term farm system is borrowed from the baseball system of the same name and has a similar intent. The idea, in baseball, is to build up players until they are ready for the 'major leagues.' Software systems intended for laboratory and scientific use need to be made better as well through active use rather than by lofty theorizing or the proverbial cramming of functionality down the user's throat.
Hopefully this explains my reasons for building Labtools and why there are so many rough edges in there. I started with an infrastructure, working in the flexibility at the lower level rather than trying to met customer demands. Scalability is not a primary concern here as it takes a back seat to extensibility. In other words it is more important for me to completely change direction than it is to serve thousands of users.
But building a LIMS (or functionality for one) is not at all like playing baseball since the teams are not evenly matched. Heck, the opponents are not even human. The opposition in building software for the laboratory consists of time and money and when there is a loss it is always incurred on your side, never theirs. One 'scores' in this game by rounding the bases (producing functionality) and having users accept it and their respective companies pay for it (filling the stands). The inertia of cost constantly pulls against you while you are rounding the bases. Time acts like a referee or umpire in the game who has been well paid off by the opposition. Late releases or promised functionality that fails to materialize (vaporware) acts as a time infraction that causes the stadium of users to suddenly depopulate. This has immediate ramifications upon the cost player because it results in fewer paying users in the stands and thereby allowing cost to exert more force and leverage against you. If you stop rounding the bases or fail to keep those already in the stands happy they will all leave and cost will stop you completely. Game over.
Because we are talking about the dynamics of cost and leverage let me introduce an alternate strategy for playing this game -- open source software. Open source says 'here, use my software -- you can utilize it provided you agree to only some very minor restriction.' The most popular restriction is that you provide everybody else with the same freedom to utilize the software that you enjoy. This means that every user must be given access to the software source code in such a way as to be able to modify it (in most cases it also means they can redistribute it but that isn't always the case). One can obtain the software at a near zero cost so the thinking is that, in the game of LIMS development, use of open source would conquer or bind up the opposition. In fact, it only performs the equivalent of binding the cost player's left hand. In a LIMS implementation the cost of the software itself does not amount to anywhere near the total cost of the implementation. It is the training, customization, upgrading, interfacing, and other aspects that, over time, far exceed the acquisition cost of the software. So in the game a reduction to near zero of some costs has the net effect of making cost's other appendages work harder. You have an advantage, yes, but the other costs will work harder to defeat your initiative.
Building software that you actually expect people to use means working against time and cost while developing and maintaining the interest of users at the same time. The baseball industry learned of the impossibility of doing this with less than spectacular players. I mean, you cannot fill the seats with average Joes from the neighborhood. Nobody will pay premium prices for seating in those cases so the farm system was invented and the less than spectacular players are sent to smaller places around the land to develop their skills. It appears that nothing less than the spirit of competitiveness and reproducing the exact conditions of an actual game in the minor league will do to produce better players.
In the minors you can monitor virtually all aspects of the player's performance and thereby lower the risks associated with bringing them up to the majors. The minor league baseball field is like a laboratory for the majors. When you elevate someone from the farm system you know exactly what you are getting.
And this is the reason I built Labtools and have commenced working on modules for it. The objective is to measure the effectiveness of various strategies against the opponents -- time and cost -- and gauge actual satisfaction. This is best done by actually having real laboratories utilize the software in a production environment. These organizations agree to be monitored, probed, and prodded about the effectiveness of the functionality as well as their likes/dislikes about using it. Concessions need to be made in terms of functionality just as one would expect since this is not the 'major leagues.' It is the farm system and some things will not be there. The game will not be held in a big city; you may have to sit in the bleachers (once you get used to it, it can be fun); but we'll get our measurements. The small town guys will get a game they otherwise wouldn't see and we'll figure out who the next generation's stars are going to be.Go Back
Citation: The Farm System. (2012). Retrieved Sun Apr 30 05:02:46 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1328890573