Jason Atchley : Information Technology : Five Software Approaches to Harness the Internet of Things
jason atchley
Five Software Approaches To Harness The Internet Of Things
Comment Now
Follow Comments
Research is evidence-based. But how much information is too much? The life sciences industry is facing an onslaught of digital data, coming from the proliferation of mobile devices and genetic sequencing, to new biomarkers and diagnostics. For the life science industry to make use of all this input – to really succeed in the new “Internet of Things” – technology companies are searching for a holistic approach to harness this vast data.
As the technology industry evolves to meet the needs of life science, software-as-a-service (SaaS) companies – companies that host their software in a cloud infrastructure – add a variety of tools to support research. Some tools are purchased and others built in-house, and this can create a dilemma. How do you get diverse products to behave as a single, logical unit without tearing everything down and starting again?
The manufacturing industry is a far cry from life sciences: it deals with “things,” not people, and its mechanisms, though complicated, are nothing compared to human bodies. Still, there is a lesson to be learned by looking how Volkswagen solved a problem in supplying parts to a large variety of models quickly, reliably and with massive volumes.
Volkswagen is one of the biggest automobile manufacturers in the world and owns companies like Audi, Seat, Skoda, each with many different models. Cars of all shapes and sizes from super-minis to hulking people carriers, but what do they have in common? They are all based on the VW Golf. No matter what size, shape and purpose the cars have, they all share VW Golf’s MQB platform.
The system is a shared modular platform for transverse engine, front-wheel-drive cars. Using the Golf MQB platform, 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 a software platform be developed that delivers the same benefits as the VW’s standardized component platform? Starting from a common platform is obvious, but creating one from scratch would be too expensive. VW’s route to a platform was evolutionary, with gradual adoption over time. That is the approach Medidata is adopting with Service-oriented Architecture (SOA).
At Medidata, our products are being designed to behave in concert with one another, as a platform, but still to retain each product’s unique characteristics and intrinsic technology stack e.g. Java, .Net, Ruby, etc. This can be achieved by adding services into the existing product mix so they can handle the activities that individual products share like authentication, feature authorization, workflow management, alerts and notifications, etc.
By separating out the common product functionality and delegating it into services, we’ve reduced complexity, standardized interchange-ability and increased product utility just as VW did. However, developing services, or standard components, to take on the tasks already handled by innate product functionality only gets you so far.
For the whole to be greater than the sum of its parts, each new service has to outperform its original in-product role. This is achieved by the adoption of new cloud methodologies/approaches:
The 12-factor app: Each service must be compliant with the twelve-factor methodology for building software-as-a-service. One of the tenets of the 12 Factor methodology covers a topic called “process formation.” This means when a developer creates a service, the developer should build it 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. In the pre-cloud days, greater performance meant buying a bigger server, which was both expensive and slow to spin-up.
Auto-scaling and flexibility: It is one thing to spawn another process to carry an ever-increasing user load, but it’s quite another to control it. Auto-scaling allows your service to automatically scale up when certain pre-defined conditions are met and more importantly, to scale down and stop paying for the extra nodes when the user load drops off.
12-factor compliance: Make services more reliable by improving the way they are built, tested and deployed into production by having each one as self-contained as possible. That way, when a bug does arise, it can be easily traced and rectified by a group of developers working in unison.
Hypermedia service adoption: Application programming interfaces (APIs) should behave like web-pages, where a developer can navigate to and visualize data more easily. This should allow them to write better quality integrations.
Unified reporting strategy: Using SOA, you can combine the audit trails from all component modules and create a stateless, homogenized, service-driven data feed that we can use for comprehensive, platform-wide 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 together closely. At Medidata, 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. That helps our customers run complex clinical trials cost-effectively.
[A version of this article appeared as “A Platform In The Cloud” in Pharma Technology Focus.]
Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley
Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley
Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley Jason Atchley