Implementing Technology, Part II: The Technology Infrastructure

In Part I of this article, published in the December 1996 Monitor, we introduced the concept that successful implementation of information technology goes far beyond the choice of a particular software program. In that article, we discussed the importance of understanding your business, analyzing and documenting your workflow, understanding the costs of your processes, coping with politics, and the need for leadership and vision. In this issue we look at another critical success factor: building the right technology infrastructure.

Companies often approach a software application project in a vacuum, without considering in full the technical environment in which the software will be used and must be supported. Sometimes when applications such as electronic data collection seem to fail are in fact failing because the project team or department did not consider the issues of hardware deployment and support, computer networking, and home office technical support.

Technology infrastructure includes: people & their skills, hardware, the local and wide-area network(s) & their overall architecture, and interdepartmental support & procedures.

It is crucial to the project that you understand what skill set you will need to support the software after it is implemented, even if you will rely on outsiders to support it. For instance, Lotus Notes¢ç is a powerful and widely useful application development environment, but requires a well-trained system administrator with ample time in his/her schedule to support the application. This is also true for Internet browser or Java¢ç based applications, where you also must ensure that the person(s) assigned to ongoing support have the skill and opportunity to stay current with rapidly changing technologies.

Hardware requirements can vary greatly depending on the application being implemented. Multi-site or worldwide implementations have special hardware challenges, even in the simple shipment or import of equipment across borders. The good news of course is that hardware costs per capacity and functionality is rapidly declining; unfortunately most applications’ requirements are expanding to overfill the hardware capacity almost simultaneously! You need to also plan carefully to ensure that a mission-critical application can safely share hardware with non-strategic desktop applications.

The clinical research industry seems particularly prone to overlooking networking capacity and architecture issues until an implementation project is well underway. This can cause serious obstacles and unnecessary interdepartmental tension. Different designs of the same basic application will have very different impact on your local-area and wide-area network requirements. This takes us back to the business requirements we discussed in Part I: how critical is it, and how often do you need, to share data among users? How easy is it for your users to gain secure, uninterrupted network access? How much data would they be exchanging during network connections? How much remote expertise is required to keep the network connections available and convenient? Can simpler approaches serve adequately at acceptable cost?

The availability of the Internet (which can be thought of simply as a more widely available, publicly accessible, version of what large companies have long had built for themselves) has heightened the awareness of wide-area networking’s advantages while perhaps misleading expectations. Clinical research groups need to take a close look at whether they should continue building dedicated WAN/LANs; use Internet service utilities to build an “intranet” instead; or actually rely on the public Internet.

Recent changes in software development environments prompted by widespread Internet interest have raised an importing computing architecture question: should you continue your move to intelligent client/server systems (which the pharmaceutical industry is mostly still in the midst of transitioning to), or skip to what can be termed “recentralization”? Recentralization is the implication of the use of “thin” hardware with limited local capacity or flexibility, controlled by powerful servers offering rapidly available applications and data. The perceived efficiency and rapid responsiveness of recentralization must be balanced against what we have come to accept as a useful business structure: the empowerment and independence of individual users from connectivity.

Clinical research planners should look closely at the skill set of all their trial participants, the true network performance and availability they can count on at all locations in their trial and business, and the knowledge of their supporting staffs, before relying on the very latest technologies which prompt such a significant architecture shift.

The last aspect of technology infrastructure returns us to people and politics always the most important aspect of work. Certainly in large companies, but even in small ones, when you start to explore the infrastructure for your particular operation’s application, you will undoubtedly need to rely on those outside of the clinical research function for support. In most organizations, hardware and networks are handled by information systems departments or managers, and there may be important policies and procedures in place which are incompatible with your plans. You will need to involve these colleagues very early in your implementation planning to ensure they can anticipate and cooperate with your needs.

In Part III, we will look at how to prototype your technology solution, and consider some cost-saving strategies for exploring and implementing technology in clinical research.