Article Excerpt Featuring Dave Dorsett, Astrix Principal Software Engineer

Cloud capabilities

Cloud computing helps to facilitate migration to new software platforms and supports real-time data access, writes Sophia Ktori.

While integration remains one of the most obvious issues when migrating a LIMS into the cloud or when making a new web-based LIMS installation, this inherent need to connect and enable communication between disparate platforms also brings with it the requirement – on the vendor’s side – to ensure safety, commented Dave Dorsett, principal software architect at information technology consultancy Astrix.

Consider an organisation that’s looking to implement a cloud-based LIMS infrastructure, for example. “It’s likely that the vendor will be running a multi-tenant architecture,” Dorsett explained. “From the vendor’s side, there will be a defined service level agreement and a warranty of security, and this will impose fairly severe restrictions on the accessibility of that cloud-based infrastructure by equipment that is ‘on prem’ at the client’s site.”

Effectively, when the equipment that the client wants to integrate with the cloud-hosted LIMS remains physically in the client’s laboratory and is not in the vendor space or in the vendor cloud, then there is a security risk to the cloud network. The constraints that this can impose may even require the client to rethink their integration model in order to achieve what Dorsett calls the ‘balance spot,’ where the vendor is comfortable that they can meet their responsibilities under the SLA while still protecting against threats. “It’s a significant integration challenge,” Dorsett noted.

“Trust is a major issue – in fact, we operate now from a zero trust perspective – and our networks have had to become increasingly sophisticated at managing that trust. When you then put a chunk of a piece of software under the management of an external vendor, the same issues apply. So as an external vendor with, say, five customers, not only do I have to be on the lookout for any threat that might transfer to me from those companies, their network people will have a zero-trust starting point with respect to my network as a vendor. Meanwhile, I also have to manage intercompany threats to make sure that threats cannot move between clients.”

One approach to improving security is network segmentation, so keeping lab networks and other enterprise networks separate, for example. This is a model that has been adopted by the manufacturing industry and is increasingly being implemented in R&D labs, Dorsett continued. “The simple way to do things is to put everything into one big network segment so that every computer and system can see every other computer and system. But from a threat perspective, there’s then no effective way to seal any systems off, so if a virus or other malware reaches that environment, it can then access all the entire hardware and software network. Merck is just an example of a major organisation that has in the past experienced a major virus problem in its manufacturing environment that’s required it to sustain major losses in output.”

These sorts of events raised the profile of network security in a very relatable way, Dorsett stated. “People started to think that it may not be the best idea to let everything talk to everything else, but to take a segmented approach to building networks so that systems can be isolated if necessary. This is particularly relevant for some industries, for example, petroleum refining or chemicals, where there are very real safety issues. Here it may be that hardware and software on the plant floor can talk to each other in order to get the job done, but this plant floor IT environment is cordoned off from the enterprise network for safety.”

Communication is thus governed by rules and firewalls, along with reporting and tracking requirements, to ensure safety, Dorsett noted. “Negotiating these safety layers can be daunting. The concept of data transfer then becomes a matter of negotiating safety layers. You have to take data from an instrument that lives in a network segment buried in a customer’s environment through a connection to the on-site network, move into the internet, and then into a cloud provider version of a piece of software hosted by the vendor. This can be hugely complicated to do seamlessly.” Layered on top of the need to integrate the laboratory scientific equipment, and software, a cloud LIMS may also need to integrate with asset and inventory management, and other on-prem hardware and software architecture.

Software customisation is another significant obstacle to migration or implementation of LIMS in the cloud, Dorsett pointed out. “If you have an existing on-prem LIMS system, it’s likely to be highly customised. The industry has talked for decades about the need to configure, rather than customise, but the reality is that people do customise the heck out of their systems. They naturally write external code as workarounds. However, for a vendor-hosted model and SLA there will be severe boundaries with respect to the degree of customizations that is feasible.” These restrictions can make migration of an existing, heavily customised system into the cloud unfeasible. “At the end of the day migrating existing customizations can come up against a huge brick wall and tremendous costs, and it may be worth considering not so much a migration as a completely new implementation, and so the cost-benefits of migration versus new implementation will have to be calculated,” and with that organisations then have to negotiate the minefields of functionality, features and change management, Dorsett suggested.

Whichever route is taken – migration or starting afresh – organisations and users will have to expect that the resulting cloud-based LIMS platform will not be identical to their original system in every respect of functionality. “Even if you take the same vendor software and you move it from in-house to a hosted model, it’s going to be a radically different system.”

The problem here is that there is still a tremendous reluctance within the life science community to accept change, Dorsett said. “People want their blue icons and buttons to remain blue.” And this reluctance to change – even if the changes are positive or result in equivalence in function and operational ability – filters up from the operators, scientists, end users, and lab managers, to other stakeholders within the enterprise.

Accept change will happen, whether to migrate or to start afresh, and cost analysis then becomes a particularly tough issue, Dorsett stated. “People still by and large don’t really understand the true cost of ownership when comparing cloud options to their existing on-prem system.” And this is for a variety of reasons, he suggested. When comparing an existing LIMS infrastructure to one that is moved into the cloud, it can be hard to objectively list and calculate the true cost of all the internal resources, including the physical assets like servers and machines, and also the ‘soft costs,’ including the people that run them. “So, when you attempt to figure out how much your on-prem system is really costing it be really tough to get to get actual numbers.” And if an organisation moves the LIMS up into the cloud, outside of their environment and direct control, then making these comparative cost analyses can be very cumbersome, “so cost-benefit analysis also becomes tricky and the benefits, in terms of feature function, operational, all those types of things, may get vetoed by the hard financials.”

Particularly in today’s economic climate, there is intense pressure to dampen capital expenditure while operational budgets are being squeezed. Cloud hosting may be perceived to have the edge as it is paid for on a timed basis, with upgrades and service built in, Dorsett acknowledged. “However, there is a lot that’s hard to quantify, particularly in the LIMS space where systems must be validated, and there are additional costs of maintaining validation on top of that. In many instances, people are just not upgrading their systems because the costs of validations are so very high.”

FDA is changing its approach, however, he continued. “The agency’s intent is to move away from this document-oriented validation model to one that is more risk centred, which will encourage people to upgrade their systems and stay up to date.”

So, is it always best to migrate into the cloud? Not necessarily, Dorsett concluded. “It is not a given ‘better.’ There are evident benefits, such as agility, regular upgrades, and service-level support, for example. And for many organisations those benefits will overshadow the initial upheaval. But not all those benefits will necessarily be important to all users of a particular type of system, especially in the LIMS space.” The technical hurdles, expectation to fine-tune and customise functionality and features, coupled with the requirement to negotiate change management and issues of validation, as well as the cost of implementation, may all sway the cost-benefits back to retaining an on-prem system.

Read the full article here: Scientific Computing World, Feature Article, 14 January 2023.

About Astrix

Astrix is the unrivaled market leader in creating & delivering innovative strategies, solutions, and people to the life science community. Through world-class people, process, and technology, we work with clients to fundamentally improve business & scientific outcomes and the quality of life everywhere. Founded by scientists to solve the unique challenges of the life science community, Astrix offers a growing array of strategic, technical, and staffing services designed to deliver value to clients across their organizations. To learn the latest about how Astrix is transforming the way science-based businesses succeed today, visit www.astrixinc.com.