Will your LIMS survive a meteor?

Sure it is important to meet your current needs, but what should you look for from a vendor to ensure your evolving business needs will continue to be met?

Most sophisticated laboratory information management systems (LIMS) purchasers have a well-developed methodology for evaluating which system best meets their needs. Current needs are carefully documented, weighted and compared to the functionality provided by the solutions on the market today. However, given the level of investment made in LIMS and their mission-critical nature, the long-term viability of the vendor must also be a consideration. This goes beyond a simple analysis of the vendor's fiscal health; it is becoming increasingly important to look at how well the vendor is positioned to meet your future needs. Unfortunately, evaluating whether a vendor can continue to meet your business needs over time and 'future-proof' your investment is a less precise science.

Crossroads for LIMS and software

Since its early days, development of complex software has been a struggle. The term 'Software Crisis', used to sum up these struggles, has been around almost as long as the term 'Software Engineering'. Over the years, software developers have adopted varying methodologies, ranging from basic Waterfall to Extreme Programming (XP), to address these failings. While many of these processes have helped to improve initial software quality, they often fell short in addressing the issues of changing complex software. Today's software crisis primarily refers to the software developer's struggle to keep up with the rate of change of business.

Historically, from a software perspective, LIMS have simply been highly-configurable data storage systems. To meet the market demands of the time, which called for the systems to meet each customer's individual processes, LIMS vendors developed little in their core product and left much of the functionality to customisations that were needed to meet individual requirements. While this approach met the current need, it had significant drawbacks. Perhaps most significant was the difficulty upgrading to new versions when the original is highly customised. Due to the pain involved, LIMS customers were very conservative with implementing upgrades. This situation contributed to an understandable stagnation of innovation and a dearth of new technology in the LIMS industry.

However, a disruption in this status quo is already underway. Increasingly, LIMS customers have learned that highly customised software is problematic and are willing to adopt more standardised, commercial-off-the-shelf products. At first blush, this might not seem like such a challenge for vendors since many can simply offer a 'standardised version' of their current offering. However, one of the key outgrowths of standardisation will be that upgrades, and the ability to accept new innovations, will become significantly easier than they are now. Without customisations, new software can simply be installed. Validation times should be significantly reduced as well, since standardised products can yield standardised test scripts. With these shackles released, the LIMS field will become host to a whole new ball game. It will begin to resemble other arenas of information technology, where innovation and change are the norms. Increasingly, LIMS vendors will be evaluated based on their ability to innovate and keep pace with your more rapidly changing needs.

This will challenge the way many traditional LIMS vendors develop software. Their old methods and technology may have been sufficient in a stagnated climate, but that is no assurance they can survive in a more aggressive environment. In an era of innovation and rapid change, vendors will be differentiated by their ability to reliably adapt and modify their products. That ability will be shaped by the decisions they make today. Indeed, standardisation may do to many LIMS vendors what a meteor is theorised to have done to equally prehistoric beasts.

So, how do you weed out the dinosaurs? Well, if they are lumbering, cold-blooded and have a brain the size of a pea - that is a pretty strong indicator. Though they may not be quite that easy to spot, a progressive LIMS developer should already be sowing the seeds to thrive. While this article will by no means provide a comprehensive list of evaluation criteria, it should give you some good talking points with your potential vendors. Your vendor should have already thought of these issues and be able to articulate their approach to each.

A technology plan

It is your vendor's job to worry about the future of information technology so that you do not have to. However, your vendor should be able to clearly articulate (in your language, not 1s and 0s) their plans for adopting new technology, for example, Microsoft's .NET or Sun Microsystems' Java platforms. I am not necessarily advocating one technology over the other in this case, particularly since there is no 'one plan fits all' approach - but your vendor must have some plan for keeping your information technology current. Your vendor's plan should take into account what assets they already have (legacy, or 'cherished code'), where they want to be and have a logical roadmap to get where they want to be. They should also be able to articulate the business benefits to you of their targeted new technology.

The importance of a technology plan links back to keeping pace with the rate of change. While it is true that you can build just about any system with just about any programming platform, each new generation of programming platforms has brought a leap in developer productivity and addressing the struggles of changing complex software. A vendor that stays rooted in older technologies will be increasingly hampered to keep up with those that adopt new technology.

This is not to say that a vendor should jump at every new technology. They should, however, continuously evaluate new technologies. Adopting technologies can be intensive for both the vendor and customer, therefore proper pragmatism must be employed. There should be clear business benefit to the customer to make such a move. When that benefit outweighs the cost of transition, it should become part of the technology plan. Can your vendor articulate why they chose their technology path? Was their decision made on pragmatic analysis or whim? Such insight tells you how smooth or disruptive their future decisions may be for you.

Thinking beyond today's requirements

Good software developers do more than just develop software strictly to the current set of requirements. Recognising that changing complex software has been the bane of the industry, they must anticipate the ways in which the software may change over time and build in that flexibility from the start. Such flexibility is derived not only from the design of the software, but from the very processes used to develop the software as well.

From a design perspective, there are numerous time-tested best practices, such as separation of business logic, user interface and data access code within a system, to the latest thinking in software architectures. Much like with technology, vendors cannot simply adopt every new approach, but they should be monitoring and evaluating the latest trends for infusion into their own practices.

One design trend that your vendor should be aware of is an architectural paradigm called service oriented architecture (SOA). In this approach applications are 'built' by assembling loosely-coupled 'services', each of which provides a unit of business logic. This approach represents the latest in the evolution of distributed computing, which has included technologies such as RPC, CORBA, and DCOM. SOA improves on these earlier approaches due to its stronger emphasis on standards and loose coupling between services. SOA has received strong support from major software vendors, is governed by the W3C and is advocated by both the Sun and Microsoft camps.

SOA not only represents an incremental improvement in the way complex software is built, but could prove to have a profound impact on the way software is delivered and deployed. The promise of SOA is that in the not too distant future vendors will deliver services that can be easily integrated with other services in your enterprises, giving you greater ability to assemble precisely the functionality you want with standardised services. This also opens the way to selectively upgrading portions of your applications to get new features with reduced impact and re-validation on your other services.

Given the scope and widespread adoption of this approach, your vendor should at the very least be able to articulate their view on the subject. Ideally, they already have plans in place to either adopt SOA design practices or at least provide a service-oriented interface to their offerings.

The ends are a product of the means

Perhaps even more important than the specific technology used to develop a product is the software development process that is used. Sadly, innovations in the processes used to develop software are often overlooked by developers in favour of slick new development tools. Much like development tools, though, there has been significant growth in this area and your vendor should be committed to continual process improvement.

While the established, step-wise waterfall approach has its virtues, it is particularly weak at adapting to changing needs. In response, more and more iterative development techniques have surfaced. One of the more promising iterative techniques has been termed 'Agile Development'. In this case, agile refers to manoeuvrability, not necessarily speed, though increased speed is a common by-product. Agile development groups together a set of software development practices that, in general, apply time-boxed iterations, adaptive planning and evolutionary delivery. What sets Agile apart from other iterative techniques is its strong emphasis on continuous integration and unit testing. In the agile world, before you write a unit of code, you first write code to test that unit. While it sounds laborious at first, what this buys you is future manoeuvrability. It allows you to quickly adapt an aspect of your system to changing requirements and immediately determine that change's impact on the rest of the system by exercising all of these unit tests.

As with technology, I am not advocating a 'one process fits all' approach. Your vendor, though, should not be content that their current processes will forever allow them to keep up with the rate of business change. They should be able to articulate latest software trends and have a record that indicates process review and improvement.

Ticket to ride

While it is wonderful to choose a vendor with a bright future, it will not yield much business benefit unless the vendor is providing the means to bring you into that future. This starts with the pain it will take you to upgrade from your current platform. While a vendor may be able to speak of a great vision with bold new functionality, if their current offering requires extensive customisation to meet your needs, it is unlikely you will be able to realise that vision anytime soon.

Seeing the increased demand for standardised LIMS, your vendor should already be moving to provide you with commercial-off-the-shelf (COTS) products that meet your needs without extensive customisations. The less customisation that is required, the easier it will be for you to implement, validate and update your LIMS. This improves your ability to reap the benefits of future product enhancements, giving you the best probability of future-proofing your investment.