A variety of different architectures are now available for modern LIMS, and these different architectures determine the way LIMS are installed, managed and utilized. Key factors to consider when selecting a LIMS is the type of architecture that is best aligned with your business goals, as well as the standards your organization’s IT group has established for IT architecture.

Until fairly recently, most LIMS software was licensed from the vendor and installed directly in the lab server/computers in what is known as an on-premise deployment. In recent years, several vendors have begun to offer LIMS deployment compatible with external hosting, offering full application functionality accessed through a device’s web browser and hosted at a third-party data center. In addition, there are now fully external “LIMS-as-a-service” offerings.

Each of the different architectures supported by commercial LIMS today has its own benefits and drawbacks. In this blog, we will present a few of the most common LIMS architectures that are utilized and discuss some of the benefits and drawbacks of each.

On-premise Deployment

Traditionally, LIMS software has been purchased from a vendor and the server and database installed (either with a physical CD/DVD or downloading through a web link) directly on internally owned and deployed computers with a fixed licensing fee. An annual maintenance fee is usually included in the initial purchase as well. This on-premise deployment architecture can be used with a thick client, where the user interface is also installed directly on an internally owned computer. Many modern LIMS leverage web services to render the user interface in a web browser, requiring no installation of LIMS software directly on user computers. This architecture is called a thin client.

Once installed, on-premise LIMS software, including database, server, and client installations, requires ongoing monitoring and maintenance from the company’s IT department. This type of architecture is useful for large companies or government agencies that require strict internal control of the systems because of high data security or other reasons and hence prefer to keep data behind the company firewall. With this architecture, however, skilled IT teams are necessary to operate, administer, maintain, and upgrade the system and infrastructure over its full lifetime.

Advantages:

• Functionality – thick client LIMS sometimes offer richer functionality compared to thin clients, and on-premise installed LIMS typically can offer higher performance.
• Data Security – on-premise installation allows for higher level of data security with tighter control over all the system components.
• Customization – on-premise installation can allow for higher degrees of customization and integration.

Disadvantages:

• IT Resources – requires a skilled IT team for system administration, maintenance, implementation, upgrades, patches, data backup, disaster recovery, etc. Implementation and upgrade processes can be complex and the ongoing expense of system patch management for security is required.
• Capital expense – typically larger initial capital expense for infrastructure requirements, license(s) and labor for implementation.

Managed Hosting Deployment

In this deployment architecture, the customer generally purchases the software from the LIMS hosting vendor in the same manner as with an on-premise deployment (license, annual maintenance fee, etc.), but the system is installed at a third-party hosting/data center. The customer stills owns and configures, and can customize, the software. The hosting vendor generally treats each customer separately and provides system-level support of the machines necessary for the database and application servers.

This deployment architecture can be used with either thick or thin clients, although successful use with thick client installations on the customer systems is very dependent on the network connectivity between the customer and the external data center. A variation of this is to use a remote desktop solution such as Citrix to support the installation of the thick client on servers managed by the external data center. In this variation, all the systems required to run the system are managed by the external data center.

Advantages:

• Functionality – offers the same functionality as the on-premise deployment.
• Fewer IT Resources – using the external data center resources reduces the customer IT resource requirements and the external data center can offer more sophisticated system management capabilities that might provide for deeper levels of system monitoring and improved backup and disaster recovery abilities. Customer IT resources are still required for system administration, installation, configuration and user support.
• Lower Capital Investment – the external data center operator bears the cost of the systems and infrastructure required to run the system.

Disadvantages:

• Data Security – the system’s data is under control of the external data center and their processes for backup and security must be carefully reviewed and managed.
• Network Dependency – you lose access to the system if your office loses the network connection to the external data center, and performance of the system will be dependent on this connection as well.
• System Integrations – integrating your LIMS with other enterprise or laboratory systems is potentially more difficult, dependent on the network architecture of the external data center.

Cloud Hosted Fully Managed Deployment (SaaS)

While in an on-premise and managed hosting system the customer owns the software, a SaaS (software as a service) LIMS hosting is typically licensed based on the demand (e.g., the number of users) on a monthly or annual basis. Typically, the SaaS model allows customers to flex the licensing based on only the use of software they require, as opposed to the more fixed traditional set license fees, although discounts are also generally offered based on customer commitments to users and/or time.

With a SaaS LIMS hosting , the management of the software application and infrastructure is the responsibility of the SaaS vendor. Typically, many different users (customers) run on a single instance of the software and database in what is called a multi-tenant mode. Some SaaS vendors make their systems licensable in a single-tenant mode, where the customer has dedicated infrastructure for the application and/or the database. The single-tenant SaaS model offers additional data security, but usually at a substantially increased cost. In either SaaS model, the user does not have to maintain either the physical servers used or the cloud-based application, and the customer accesses the software application via a web browser.

Advantages:

• Pay-as-you-go – you only pay for what you use. On demand licensing enables LIMS to become a variable expense, rather than a large fixed cost at the time of purchase. This will also generally translate into a lower cost of entry.
• Least Required IT Resources – All of the administration and support of the underlying application infrastructure is the responsibility of the vendor. Customer IT resources may be required for application administration and/or configuration, but installation, system administration, backup, disaster recovery, etc. are all the responsibility of the SaaS vendor.
• Scalability – the elasticity and resource pooling aspects of the cloud allows for more rapid and flexible scalability with increased use.
• Reduced Deployment Time – since the application has been implemented in the cloud, your organization can be up and running on an SaaS LIMS very quickly.
• Reliability – The SaaS vendor is typically contractually responsible for system availability and communication of scheduled downtimes. Most SaaS vendors employ redundancy in their infrastructure and high-availability architectures to meet the contractual requirements.

Disadvantages:

• Integration– it can be difficult to integrate on-premise systems with a cloud-based application. Both the LIMS hosting vendor and customer will need to work together to make this happen.
• Customization – Most SaaS systems have very limited or no ability to be customized. Because the vendors business model is based on distributing the use of costly infrastructure across multiple customers, the software is generally only able to be configured in very specific ways. This may result in less functionality compared to the other options that provide you with more complete control over the system functionality.
• Cost – monthly fees can add up over time and end up being more than an on-premise solution. Also, there is no permanent access to the system in the same way as what you get with a perpetual license to on-premise installed software.
• Data Security– with a SaaS system, data travels and is stored outside your organization’s firewall. This means you are relying on the service provider for data security. Also, ultimate ownership of data in terms of future system migration and/or archival need to be explicitly structured and negotiated.
• Complexity of Validation – System validation is a potentially more complex activity, requiring both the SaaS vendor and the customer to closely cooperate. Upgrades may be more challenging in a multi-tenant environment if the vendor forces upgrade timelines.
• Limited Options – There are fewer LIMS systems on the market that are capable of being delivered as SaaS, offering less choice of vendors.
• Network Dependency – As with managed hosting, you lose access to the system if your office loses the network connection to the external data center, and performance of the system will be dependent on this connection as well.

Conclusion

A key factor to consider when choosing a LIMS is the deployment architecture. There are three fundamental options supported by commercial LIMS today: on-premise, managed hosting, and SaaS. Each has benefits and drawbacks, and in order to achieve an integrated laboratory environment providing a high level of business value for your organization, it is important to consider how these advantages and disadvantages align with your business goals and requirements.

Astrix is a laboratory informatics consulting firm that has been serving the scientific community since 1995. Our experienced professionals help implement innovative solutions that allow organizations to turn data into knowledge, increase organizational efficiency, improve quality and facilitate regulatory compliance.

The post Factors to Consider When Choosing Between an On-Premise, Managed Hosting, or SaaS LIMS appeared first on Astrix.

While LabWare’s ELP offers both functionality and business benefits significantly beyond what is provided by a conventional LIMS or ELN, there are important considerations to take into account when implementing or upgrading the LabWare solution in order to realize its full potential to transform your laboratory operations. In this blog, we’ll discuss key best practice recommendations to follow during your LabWare implementation or upgrade that will help to ensure your project is successful in optimizing compliance, improving quality, reducing costs, and increasing productivity and innovation in your laboratory environment.

Tips for Optimizing LabWare Implementations or Upgrades

Some important considerations to take into account when implementing or upgrading LabWare’s Enterprise Laboratory Platform (ELP) include:

Make Good Architecture Decisions. When designing your LabWare system architecture, it is wise to use as much of the standard configuration as possible, which means getting the best Templates that will suit your business, and trying to use as many of the available modules as possible to avoid a lot of customizations. There are a number of reasons for this:

• Using LIMS Basic (LabWare programming language used for customizations) instead of standard functionalities means that LabWare will need to compile your customizations in real-time, resulting in a loss of performance.
• The more customizations you have, the more complex future upgrades will be.
• The more customizations you have, the more difficult it will be for your IT support to solve an issue when problems arise.

Iterate Your Implementation. The LabWare platform is extremely flexible and can be configured and customized to automate virtually any laboratory operation. However, just because you can do something does not mean it is cost or time effective to do so. It is prudent to implement LabWare in stages, with the first iteration being the minimum viable solution to go into production with. Once this minimum solution is operational, users can provide feedback as to the pain points that they are experiencing, and then decisions can be made as to whether it makes sense from a financial and time perspective to customize the system to provide further automation.

Have a Master Data Management Strategy. Having a data management strategy is often an afterthought in an informatics project. Data management for any informatics implementation almost always turns out to be a much bigger task than one might have imagined, especially for those projects that involve replacing a legacy system. As much of LabWare’s functionality is data and template driven, neglecting to formulate a Master Data Management Strategy at the beginning of the project can lead to significant time and cost overruns as the project proceeds. As such, it is important to make sure that you do the work necessary to understand and plan for your static data requirements at the beginning of your LabWare project. Questions to ask include: How are we going to get data out of the legacy system and into LabWare? How are we going to harmonize data across multiple sites?

Understand User Roles and Security Permissions. LabWare has a multi-layered security framework built into the system. To fully utilize this feature, it is important to fully detail the desired user roles and the permissions associated with each role before you build the system. As with managing the static data aspects of the project, designing and implementing user permission layers can be a bigger task than expected. Waiting until the end of the project to implement a security framework is a recipe for cost and time overruns.

Don’t Go Overboard With Instrument Integration. LabWare offers several different ways to integrate instruments into the system.

• Configuring Labware to monitor and process database tables created by an external instrument.
• Web services
• XML data mapped to specific fields in Labware, or to an XSD provided by external applications. LabWare now supports the AniML XML standard for analytical chemistry data, allowing LabWare to more easily bring in data from various sources.
• Direct connection via RS-232 ports.
• Modules that support various complex laboratory instrument systems like Empower CDS.

With all these integration options, it is certainly possible to get bogged down in trying to integrate too much too soon. Some instrument integrations can be challenging and cause project delays. It is important to have a master plan that details what instruments are to be integrated and when.

Have a System Map That Details All the Templates and Modules in Use. Modules in LabWare are enhancements that are incorporated into the main application using its core language (Small Talk). These modules can be downloaded from the LabWare website and installed with the main application to achieve a new feature. It is quite common for complex LabWare implementations to have a large number of modules installed. When a customer downloads a new module that has been developed by the Labware team, it may cause some problems in other modules that they are using. This issue usually occurs in a new implementation, when adding new features into an existing implementation or when upgrading the core system version. Its therefore important to have a map of all the modules installed in your server and clients, as well as the industry template being used, so that the support team will have all the information they need to recreate the customer’s installation in a sandbox where they will try to reproduce the error.

Only People with the Correct Skills Should Program Customizations. Anyone who has taken the LIMS Basic (LabWare programing language for customization) training can start developing their codes to customize LabWare. However, there are some risks when you do not have the right people doing the work. In the past, many common mistakes made in LIMS Basic programing (e.g. not using quotation marks with a string definition) were skipped by the compiler and fixed during execution time. The compiler is in constant development by LabWare, however. LabWare 7 removed much of these automatic fixing to increase the performance of the system, resulting in a big problem for many companies when trying to upgrade.

Astrix provides a complete solution for LabWare Implementation and  Platform Upgrades.

Conclusion

LabWare’s ELP, which combines the functionality of LIMS and Electronic Laboratory Notebook into a single integrated solution, is unique in the informatics industry. This system offers the ability to automate virtually any laboratory workflow. While the potential for this system to help increase productivity and innovation in your laboratory environment is great, it is important to work with a quality laboratory informatics consultant who has the necessary experience with LabWare in order to realize its full potential.

About Astrix

Astrix  is an informatics consulting, professional services and staffing company dedicated to servicing the scientific community for over 20 years.  We shape our clients’ future, combining deep scientific insight with the understanding of how technology and people will impact the scientific industries. Our focus on issues related to value engineered solutions, on demand resource and domain requirements, flexible and scalable operating and business models helps our clients find future value and growth in scientific domains. Whether focused on strategies for Laboratories, IT or Staffing, Astrix has the people, skills and experience to effectively shape client value. We offer highly objective points of view on Enterprise Informatics, Laboratory Operations, Healthcare IT and Scientific Staffing with an emphasis on business and technology, leveraging our deep industry experience.

The post Six Tips to Optimize Your LabWare Implementation and Upgrades appeared first on Astrix.