Informatics architectures are as
critical to the drug discovery and development process as the analytical
technologies employed in the lab. One of the major concerns for IT
professionals working in this arena is the delivery of a global
discovery/development framework. The management and technological
challenges of such an endeavor are examined here.
| Mar
31, 2005 |
| By:
Gordon
W. Logan |
| Pharmaceutical
Discovery |
|
Gordon W. Logan
|
The relatively poor productivity of today's pharmaceutical discovery
process is well documented. In fact, there seems to be an entire
conference circuit designed specifically to tell us how difficult things
are and will continue to be in the near future. Discussion topic: is
attendance at such events a productive use of one's time and money?
Hmm...
As it happens, when it comes to discovery information technology
(IT), it's probably no different. We struggle to demonstrate both the
tangible and intangible value of IT delivery. IT applications, be they a
new purchase, a commercial off-the-shelf (COTS) application, an internal
team build, an outsourced job or a system upgrade, often are seen as a
secondary part of the scientific project being undertaken — except by
informaticians, of course.
One of the largest interest areas for IT professionals who work in
discovery and development is the delivery of a global
discovery/development framework. It often is found that a data systems
integration project, offering "seamless access" from various
distinct applications, is conceptualized and delivered after the various
informatics raw databases already are curated and in use. This is no
real surprise given the wide variety of applications used in
laboratories today and their distinct requirements. For example, a
biomarker identification team in North America will have different needs
and expectations than a compound library curation group in Europe,
though both their IT service groups will need to deliver high
performance and high functionality as quickly as possible (here IT must
never be seen as a bottleneck to the process).
Clearly the development of a discovery information and knowledge
management environment requires a great deal of effort to be placed in
collection and collation of raw and user-level specialty data sets. But
we also must recognize the need to ensure that output delivery
environments are equally catered to. In the past two decades, a major
weaknesses of informatics applications has been their poorer feature set
for reporting and data interrogation when compared with input systems.
Symbiotic Integration? Integration
of such systems is not easy. A discovery information and knowledge
management system is a much larger and more eclectic device than a
specific data group's application often needs. Also, these systems that
cascade from the processes used to understand diseases to those used by
the company's hits database and down through the entire pharmaceutical
data value chain are not used in the same way by all teams. For example,
disease investigation uses have a traditional Web-based knowledge-mining
need and a hits-to-leads team often requires a great deal of computing
power to run optimization algorithms; the needs of the user's
informatics workspace is consequently very different. Yet, IT groups
still are expected to integrate and support them in a way that permits
all to gain the best benefit out of the integration investment.
Every pharmaceutical discovery group obviously requires a globally
similar but locally different approach to their informatics planning and
operation; this normally is accomplished by building a bespoke local
integration application (even if it's only local language and support).
I'd point out that many of us purchase a COTS but will deliver to
end-users a highly-configured system that often is unique for a given
local client base (any group who has been part of a 'global roll-out'
will be familiar with this). In addition, simple corporate geo-politics
becomes a major factor in many cases (i.e., do we go for the "big
bang" approach to system deployment or roll out on a site-by-site
basis?). We all have been there, and because the pros and cons lists
often are the same length, executive management edict comes into play
(which has, in turn, its own set of pros and cons).
With a large integration process
within a research/discovery and early development area, the various
layers of the system's maturity must be taken into account. Here, two
factors are managerially crucial: first is the ability to fully
understand where any given contributing application is positioned in
terms of its life cycle in the business. For example, a new application
in the global quantitative structure–activity relationships (QSAR)
group could have very different challenges from those encountered with a
classic migration and usage of a COTS application. Where one is built
with componentized software tools, delivered with the computational
power of a GRID backbone and requires regular functionality upgrades,
the other might simply be used to ensure the quality and management of
the organization's tissue library.
These are macroengineering issues
that have managerial equivalents throughout the IT industry. The same
can be said about the second managerial factor: ensuring value and
productivity for the integration investment in terms of opportunities
for scientific and technological advance and productivity gains within a
global pharmaceutical discovery operation.
Universal Acceptance
Often the biggest benefits that come with access to a global discovery
environment are the opportunities for cross-specialty collaboration and
reduction in training costs and ongoing support. But the price of such a
reward can be measured only by the delivery of performance (i.e., a
faster infusion of potential drug candidates into the pipeline). In many
organizations, the major success factor is a reduction in the number of
"false hits" that turn out to be costly and in unsuccessful
"leads" further down the discovery pipeline.
As researchers, we always are up
against the classic IT deployment — "Think globally–deliver
locally" which requires significant give and take on all sides.
Global discovery strategists are well-qualified to deliver the entire
discovery informatics process, but it works best if the cost benefit is
delivered for a local audience, with these local users as the primary
client — not just the recipients of the system.
In many cases, it pays to consider
a hierarchical approach to delivering such systems and applications. As
an example, for years there has been a very healthy debate about the
point at which a laboratory information management system (LIMS) should
be considered a laboratory information system vs. an enterprise
information system, where lab data can be delivered to any group via a
global integration strategy. Today I would argue that LIMS is as
necessary to a laboratory's function as the utility services, lab
benching and staff coffee area: one should not consider a laboratory
development infrastructure without a LIMS. LIMS technology has matured
to be available for most application and laboratory types (even
microbiology), has become a very good engine for integrating numerous
laboratory and enterprise systems and could be seen as a model for a
"Think globally–deliver locally" approach to discovery data
management systems.
In this respect, a number of
managerially significant pointers have resulted from the LIMS
experience. The overall cost of deploying a LIMS is considerably
affected by the integration needs or desires of local groups. Similarly,
a weakness of most integration projects is the desire to permit users to
"pull" data onto their workspace, and the value of pushing
data back into the integration environment has not matured at the same
rate. This is important because it could dictate that much of the
scientific innovation resulting from a given user's work remains
resident within that individual's or team's workspace and can become
difficult to share appropriately. This is a constant intellectual
property–productivity issue for many organizations that deliver thin
Web portal systems; electronic lab notebooks (ELNs) now are felt to be
helpful in this area.
A global LIMS deployment often is
compared to a large enterprise resource planning (ERP) install, and
certainly in terms of project management it should use the best practice
of the ERP industry segment. However, valuable scientific data movement
within a corporation is not the same as sales order processing or
manufacturing cost analysis; therefore, the measurable benefits are not
comparable. Corporate ERP data are used to improve the measurement of
the tangible value of a business to stakeholders (e.g., sales due to
products launched in the past three years). Accomplishing this through
(commercially-aware) scientific advances, using the deliverables from a
large-scale discovery IT system can be less clear but still measurable
(e.g., the number of leads from discoveries that have been validated in
preclincal development). The ERP measure tells an organization where it
is today — a discovery that IT systems (like LIMS) are used for,
telling shareholders where the company will be in the future.
At a local level the acceptance and
support for LIMS — and other applications of this type — depends
upon the user experience. In most cases, poor LIMS installs result from
poorly specified requirements and an equally poor understanding of needs
by the delivery group. Many take the view that users must be told they
cannot have exactly what they want from a system unless it makes sense
to the corporation as a whole. Similarly, the IT delivery group cannot
roll out a "boiler plate" solution claiming success because it
went in "on time and on budget" if local scientists don't
improve the discovery scientists' performance.
Overall Costs
It clearly takes compromise (i.e., politics not science). Benefits must
be shared along with any demerits.
In essence, the success or failure
of any IT system within a discovery or early development activity
depends upon close cooperation among a number of groups throughout a
considerable period of time. If this statement seems trite, then why do
so many IT projects fail after only a couple of years of the go-live
date? As any application matures through its life cycle, the major cost
of the initial system — namely the selection (or initial build) and
installation of the application — becomes a minor part of the overall
ownership cost, as continued maintenance, upgrade and functionality
enhancements take over. Add this to the large number of new and existing
projects that other groups in a discovery supply chain undertake
annually and we have a major IT industry portfolio. Ensuring confluence
of these systems without a reduction in productivity is normally the
role played by a discovery informatics system executive. Without great
lines of communication to and from clients and managers, the annual task
of pushing the river of laboratory data up the hill of scientific
insight and productivity will only get more difficult.
Gordon W. Logan is managing
director of Labformatics Ltd., in Chesire, England, United Kingdom, and
a member of Pharmaceutical Discovery's editorial advisory board.
He can be reached at gordonlogan@labformatics.com
|
