A Platform in the Cloud

Technology Focus
Issue 31 October 2014
A Platform
in the Cloud
As clinical trials grow in scope and size, life science organisations are following in
the footsteps of other industries in using cloud computing to automate and simplify
complex research processes. John Anstey, enterprise systems architect at Medidata
Solutions, discusses how the life science sector can successfully exploit the cloud
s the volume of clinical
data required for regulatory
submissions expands,
every life science software
vendor needs to develop
systems that are scalable,
flexible and robust. High
performance is a given, a necessity.
The sheer range of devices that now
quickly produce vast amounts of source
clinical data is staggering, including
everything from smart phones to
clothing, patches and bracelets. Add
those to the pre-existing clinic-based
diagnostic sources, and we face a virtual
data tsunami.
In the past, many software providers built
individual, stand-alone products, each
processing data separately from specific
areas, such as labs, case reports, CT
admin, drug randomisation and so on.
However, if our industry is to succeed in
the new ‘Internet of Things’ and harness
this vast nascent data panacea, a more
holistic solution is required – a platform
in the cloud perhaps?
Currently, many software-as-a-service
solutions consist of domain-specific
products, which have been formed
heterogeneously over a number of years.
Some tools are purchased and others
built in-house using the most suitable
technologies at the time.
many companies, including Audi, Seat and
Skoda, each producing cars of all shapes,
but what do they have in common? They
are based on the VW Golf’s MQB platform.
It is a ‘matrix’ of components which
introduces rationality across the range.
This would present any organisation with a
dilemma. How can a software-as-a-service
provider get diverse products to behave
as a single logical unit to successfully
handle the oncoming tidal wave of complex
data without tearing everything down and
starting again?
Take a look at how a company, in a
completely different industry, solved
a similar problem of cost, effectively
supplying many hugely varying
complicated products quickly, reliably
and with massive volumes.
Volkswagen is one of the biggest
automobile manufacturers and owns
Using this shared modular platform for
transverse engine, front wheel drive cars,
VW can produce a wide variety of vehicles
that sell quickly and reliably on a scale
that satisfies its market but does not
lead to waste via over-production in
anticipation of demand.
Drawing a comparison, how can we
develop a software platform that delivers
the same benefits? We can’t create
one from scratch as that would be too
expensive. But neither did VW. Their
route to a platform was evolutionary,
with gradual shared component
adoption over time.
Medidata is adopting this approach using
service orientated architecture (SOA). At
Medidata, we want all of our products to
behave in concert with one another, as a
platform, but to still retain each product’s
unique value-add characteristics and
intrinsic technology stack, for example
Java, .Net, Ruby and so on.
This can be achieved by adding services
into the existing product mix so they
can handle the activities that individual
products share, such as authentication,
feature authorisation, workflow
management, alerts and notifications.
By separating out the common product
functionality and delegating it into
services, we’ve reduced complexity,
standardised interchange-ability and
increased product utility.
However, developing services, or standard
components, to take on the tasks already
handled by innate product functionality
only gets you so far. What you need to do
next is add a new dimension so that the
whole is greater than the sum of its parts.
Each new service has to out-perform its
original in-product role. This is achieved by
the adoption of new cloud methodologies.
The first of these new cloud methodologies
is that each service has to be compliant
with the twelve-factor methodology for
building software-as-a-service apps and
involves scalability. A service should be
built so each constituent process can
be duplicated across to another cloud
server to take on more work should the
load increase. This allows the application
to ‘scale horizontally’ and increase
performance to match the level of
processing required by the users.
It is one thing to spawn another process
to carry an ever increasing user load, but
it’s quite another to control it. The second
approach concerns ‘auto-scaling’, which
allows a client’s service to automatically
scale up when certain pre-defined
conditions are met, and to scale down and
stop paying for the extra nodes when the
user load drops off.
The third involves making services more
reliable by improving the way they are
built, tested and produced by having each
one as self-contained as possible. That
way, when a bug does arise, it can be
easily traced and rectified.
The fourth approach concerns the adoption
of hypermedia. We want our application
programming interfaces (APIs) to behave
like web-pages, where a developer can
navigate to, and visualise, data more
easily. This should allow them to write
better quality integrations.
The fifth and final method concerns a
unified reporting strategy. Using SOA, we
can combine the audit trails from all of our
component modules and create a stateless,
homogenised service-driven data feed that
we can use for comprehensive, platformwide reporting and analytics.
In short, to meet the ever-increasing
demands for data from regulatory
authorities, software-as-a-service
providers have to make relatively diverse
products work more closely together.
Adopting a common component approach,
as VW has done, gives us a flexible
platform that is reliable and robust. And
using a cloud-based service orientated
architecture allows us to scale up and
down, helping customers to run complex
clinical trials cost-effectively. •
Technology Focus
iPad magazine: bit.ly/PTFapp
Web version: bit.ly/PTFmag
[email protected] | mdsol.com | +1 866 515 6044