Software as a service (SaaS) is a term that is not only in vogue now, but every indication is that SaaS applications are here to stay. It wasn’t that long ago that a SaaS application model was met with a high degree of skepticism, and rightly so. A few decades ago, network reliability was at best questionable and companies demanding fast and high-availability of data on distant servers were few and far between.
Laboratory information management systems (LIMS) have been around in one form or another since the 1980s, but only relatively recently have these mission critical applications been available in a SaaS model.
Historically, and still the most prevalent case today, LIMS are on-premises applications meaning that a company owns and maintains the server associated with the LIMS. Once, all LIMS existed as client-server applications where the software was installed on a server at the site where it was being used, and users accessed the application via dumb terminals. Certain interesting limits existed in terms of data integrity and usability along RS232 serial cables. Along came highly reliable networks spanning vast distances—even international boundaries. LIMS vendors started offering access to their LIMS using terminal emulation software such as Citrix.
The next logical step in the technological continuum was to change the way applications were constructed, and somewhere in the mid-2000s, LIMS suppliers started to embrace a new wave of technology design allowing LIMS to be centrally-served and browser-accessed. This shook up the LIMS industry as the limitations of Citrix-served LIMS became obvious when contrasted against true browser-based LIMS. On-premises LIMS pushed beyond the comfortable, halon-enrobed, physical boundaries of the customers’ IT computer center to allow anyone in the company access to the LIMS whether the server was 10 meters from the lab or 10,000 kilometers. As companies started to get more comfortable with the concept of great distances between their LIMS users and the server housing it, the next avenue available appeared as what we are today calling a hosted environment, also referred to as an application service provider (ASP). Somewhere along the line, corporate accountants put pen to paper and started considering that if someone else took over the care and feeding of the LIMS server, savings were to be had.
Think of all the costs associated with owning a server. There is the matter of software and OS upgrades, backups, and all things attendant to the privilege of strictly controlling the holistic environment, not to mention the salary and benefits of IT staff. ASP providers saw the potential of amortizing the cost of maintaining vast server farms, and such providers mushroomed all over the world. Today, almost all modern-day LIMS evaluations include questions about ASP models. But a LIMS running in a server farm is not necessarily a cloud application. Hosted environments have sometimes acquired the name “rent-a-box” because applications, in this case LIMS, are installed much like they are in on-premises environments, but the computer is in a secure environment often replete with backups, failover, uptime guarantees, and everything good about passing the buck to professionals specializing in such architectures.
So, what then are cloud applications? They must be hosted applications, right?
First, a key difference between cloud and the ASP model has to do with elasticity in terms of on-demand resource allocations and consumption. Consider Wile E. Coyote Biotechnology, Inc., a fictional company of 5,000 employees producing a host of cutting-edge products requiring round-the-clock quality control testing. The company is located across all the time zones of the continental United States. The busy beavers in the QC labs who are heavy users of LIMS first start using the system in the early morning in the Eastern time zone while employees in the Central and Mountain time zones are just having breakfast, and those in the Pacific time zone are dead asleep. The computational needs of LIMS is minimal in the early morning. But as the day goes on, other employees flood into the locations across the country, and by the mid-afternoon, hundreds of lab personnel are beating the heck out of the system—demanding computer processing cycles and bigger blocks of memory to perform all the magic LIMS provide. In a pure on-premises or ASP rent-a-box environment, you would need to build a large enough system to account for the peak usage times even though in the early morning hours on the east coast, only a few dozen people would be using the LIMS.
Such a scenario is not the case in a cloud environment where technology allows for on-demand expansion or contraction of resources. This means that fewer computational resources are used in those early morning hours on the east coast for Wile E. Coyote Biotechnology, Inc., but as more and more users come aboard, the resource allocations seamlessly expand to make certain that users at peak times of the day are afforded the same computational power as anyone else in the company. Late in the day, demand decreases as the east coast operations cease, and those allocations are returned to the pool. Wile E. Coyote Biotechnology, Inc. pays for only the resources they consume.
Many people believe that cloud environments are always hosted on distant servers whose location is a mystery. That is the case with public cloud environments, however, nowadays, this information is often published. Wait, what is the advantage of a public cloud versus just an on-premises server? Again, it’s that resource balancing magic, for one thing. A standalone server doesn’t have it, a public cloud does.
Is SaaS LIMS right for your company?
What must be understood is that a SaaS LIMS has limitations and those limitations may range from “no problem” to “deal-breaker.” SaaS LIMS by definition are a public cloud application, and are also multi-tenant.
What is multi-tenant? Multi-tenant applications are shared by, well, two or more tenants—and quite probably hundreds or thousands—none of whom are aware of each other. Each of those users is paying a subscription fee, but all those bells and whistles of OS upgrades, system backups, disaster recovery, and so forth are the headaches of the provider and not the tenants.
Therein lies one primary issue: If many users are sharing an application, then the fundamental workflow of that application is the same for everyone. So, is that a problem?
The answer lies in the application. Many testing operations are remarkably similar across the industry. Analytical, environmental, food and beverage, and cannabis testing laboratories have consistent test methods and workflow. A SaaS application might be a perfect fit for budget-conscious laboratories who would welcome the offloading of those thankless IT requirements.
So, how do you decide?
Know your workflow
It may be a no-brainer for small labs with repetitive and modest testing needs. In such cases, it is conceivable that a few SaaS LIMS could be analyzed with online demos. But for the large swath of gray-area laboratory operations, defining the current state workflow of the company and contrasting it against the workflow of a SaaS LIMS might give a potential customer a good idea of the gaps between the current needs and the capacity of the SaaS LIMS to accommodate them.
We’ve discussed data security, but let’s look into the issue a bit more extensively. When Microsoft, Verizon, Amazon, and Google all started climbing aboard the cloud initiative, they quickly discovered that concerns regarding data security were chief among the reasons potential customers were resistant.
Taking Microsoft as an example, just a handful of years back, they announced the two most critical initiatives within the company were Windows 10, and Microsoft Azure, their cloud offering. With Microsoft betting their future on two initiatives, and the fact that customers weren’t breaking down the door to purchase Azure, technical and marketing teams scrambled to provide some assurance of data security that would satisfy.
One such level of assurance came from the US Department of Defense when Microsoft Azure was deemed compliant with DoD Impact Level 6 (IL6) and Director of National Intelligence (DNI) Intelligence Community Directive (ICD 503).
Almost everyone has used Google. What do you think would happen if a rogue asteroid crashed into one of Google’s server farms? Why, nothing. Nothing at all. Mirrored servers and airtight failover technology means that while the news services would be displaying aerial photos of the crater that was once the Google server farm, you would not so much as notice a blip in your access to Google. Should cloud customers expect less? Uptime and high availability are all in the Terms & Conditions of negotiated cloud deals in one form or another.
SaaS LIMS providers love so-called “sticky revenue”. Once your company grows to depend on a SaaS LIMS, service providers expect that most customers will be reluctant to leave. But one of the first questions customers have for a SaaS LIMS provider is: What happens if we choose to go another direction? What if our new CIO decides he/she wants all data in-house? What then? Most cloud agreements have some sort of verbiage guaranteeing that if there is a friendly divorce, your data will not be held hostage.
Not impossible in the SaaS LIMS world, but the complexity may be challenging. On-premises, hosted, and private cloud LIMS handle instrument interfacing in a somewhat similar manner.
It gets a little more complicated when using a SaaS which by definition considers the needs of the whole rather than the needs of the individual. It is imperative to understand the SaaS LIMS provider’s philosophy, ability, and track record when it comes to instrument interfacing.
So, is SaaS LIMS right for your laboratory? There is no clear-cut answer, but at least now you have the questions to allow you to make an informed decision.