My first experience with the science-IT relationship issue occurred when the analytical chemistry lab I worked in wanted to buy a computer for chromatography work. The Management Information Services (MIS) department (management as in “upper management,” not “management of,” and the forerunner of modern IT departments) couldn’t understand why we couldn’t use their computer (an IBM 360 that could only run one program at a time), since there were times when it wasn’t busy. After trying to explain the situation to MIS, which needed to approve all computer purchases, the lab director agreed to use their machine on one condition: we needed only one percent of the computer’s time, but we needed it every millisecond—something that wasn’t possible with that system. Suffice it to say, the lab got its own computer.

It is comparatively easy for IT departments to support office applications. IT departments use those applications too, and they are educated to work with database systems, networks, and other technologies that are covered in traditional computer science programs. Labs are a different story and different world. Aside from some references on television programs like the CSI or NCIS series, lab applications are something IT departments are not familiar with.

The issues come down to these:

• Your lab depends on computer systems to function.

• The IT group that is responsible for supporting lab computer systems may not understand how they are being used.

• The IT department may have policies concerning systems support that don’t work in lab environments.

Developing good working relations with the IT department is in your lab’s best interest—they have access to technologies and skills you need. Do you have a computer system running an application that is there just to gain access to historical data but isn’t otherwise in active service? When people are being trained to use a database system, a LIMS for example, is there concern that their activities may put erroneous information into the system, or would you like to have each user train on his or her own copy of the application? When you are upgrading a system, would it be useful to have access to both the old and new versions during the transition?

There is a software technology called “virtualization” that allows a computer system to support those kinds of issues. It can make copies of computers—operating systems, programs, and applications—and store them as “virtual” computers, allowing users to work with them as though they were separate physical computers. In most cases you won’t be able to do data acquisition, but you can analyze and access data and work with database systems. In training situations, each user can bring up his or her own copy of a program, work with it, experiment, and work through mistakes without affecting anyone else. When they are done, that copy and all the mistakes go away. Ask your IT people about it.

IT people can also advise you on the ramifications of different system implementations such as client-server systems for instrumental data analysis or whether cloud implementations for electronic lab notebooks or LIMS make sense in your situation. We do have to be careful of one point: the choice of products and implementation must be driven by the lab’s requirements, not the convenience of IT support. That means that lab managers and staff have to be active in determining requirements and evaluating potential product candidates and not transfer that role to the IT department. It should be a partnership.

Making that partnership work

There is no magic solution to creating a working partnership. How you approach it depends on the size and type of organization that the lab operates in; one method will work well for large science-focused groups such as a research facility, another is needed for lab and IT groups where the lab is important but not the site’s central purpose—a QC lab in a manufacturing facility, for example. A lot depends on how many departments are asking for support as well as on office politics—it is a factor and one reason senior management has to set priorities. We have to remember that the bottom line is simple: the labs have a job to do, and computer systems are one of the tools; those systems need to work or the lab doesn’t.

One approach is to find someone in the lab who has a knack for working with computers and have that person do the support. This could work in a small lab that operates in an organization that has no formal IT group—an independent lab or startup company, for example. This can be effective, particularly if there is an outside IT support group that can provide technical assistance once things move beyond the capabilities of that person. Once a formal IT function is established, this approach will run into problems.

Your lab person with dual responsibilities will find that he or she isn’t really part of the lab or the IT group; each group will see him or her as “one of them, but not really part of us.” You can provide a partial remedy by elevating the position within the company so that the person’s role is formally recognized as separate from both, an internal consulting/liaison position. The only problem with this strategy is that there is no career growth path unless the responsibilities grow as the company matures. This individual has to be adept at interpersonal relationships and office politics—the technical work will sometimes take a backseat to solving people issues.

Should the organization be large enough to support it, a specialized lab-IT function within the IT group would be useful. Whether the lab orientation is a minor one (they also support other departments) or a primary focus (laboratory automation engineers1), those individuals should be educated in the laboratory environment and the tools scientists use in their work. The goal of that education isn’t to turn them into scientists, but to make them comfortable with lab work and equipment that otherwise might be unfamiliar to them. That education will make a critical difference in their ability to do their jobs successfully in the eyes of lab staff and the IT organization, as well as their own. It’s the difference between walking into a lab and seeing the computers only as isolated units that are addressed independently of everything else and seeing them as what they really are: part of a working system, a system that works only when all the components work together.

Between those roles and situations, there are a lot of possible variations as you look at research labs, independent contract labs, and quality control in different industries and as those labs and companies grow. Outside consultants and advisors can play a useful role when the combination of science and IT skills isn’t available within the organization. Finding people with the combination of IT skills and an understanding of lab work, along with the interpersonal and political skills to resolve conflicts, can be a challenge.

Management’s role

Senior management plays a significant role in this partnership by setting the priorities for working relationships. In order to minimize support costs, IT organizations may set requirements that only particular types of computers, operating systems, database systems, etc., can be used and that all of them have to be maintained at the latest revision levels. They may also put limits on access to outside Internet-accessible services. That may work well in an administrative working group, but labs are different.

In lab work, the lab’s requirements for a product may limit the possible candidates to a small list and the vendors determine the characteristics of the underlying components. Product choice should be based primarily on its ability to do the work needed, which can force the choice of machine/operating system/database. A forced compromise may result in product selections that no one is happy with. In some cases, in particular highly specialized lab work, you may have only one or two choices, and they may not be based on the latest version of the OS. It is the application software that is key, not the underlying structure, because it is the application that determines whether needed work gets done.

Senior management has to set the policies about how priorities are addressed; they have the authority and can resolve issues of allocation of resources, both people and funding. They can resolve trade-offs between the work that gets done and cost and, in doing so, avoid conflicts.

Making product selections

A lab-IT partnership means that the needs of both the lab and IT groups have to be understood when product selections are made. While both have different points of view, both have something to contribute. The lab has requirements, and if those requirements aren’t met, the purchase will fail to support the lab’s work. The IT group can provide perspectives on software issues and implementation concerns. What are the ramifications of on-site vs. remoteaccess (cloud) implementations in your specific need? Does one have an advantage over the other, not just in general, but in your specific application? For example, remote access puts a load on communications services; can your ISP support it (it may not be an issue for a large company, but might be for a startup)? The IT specialist may also provide some insight into product quality and the vendor’s ability to provide support, or give the IT group the information they need to do their job.

Informatics and computer-controlled systems are going to play an increasingly important role in lab work, and those tools are going to become more powerful, capable, and complex. For those tools to work properly, the underlying pieces need to function; and that, in part, is a role that IT groups provide. The smart choice is to develop an effective partnership that is mutually beneficial and synergistic. That requires planning and thought.

Part of the work of the Institute for Laboratory Automation (a nonprofit organization) is to build a membership community—that includes lab and IT support professionals—with a goal of advancing the practice of laboratory automation and technology management.

Joe Liscouski, executive director of the Institute for Laboratory Automation, can be reached at liscouski@InstituteLabAuto.org or by phone at 978-732-5122. For more information, visit www.InstituteLabAuto.org.