Software as a Service (SaaS) is the new buzzword in computing. You may have heard of it as "On-Demand Computing" a term that IBM loves to use in its TV ads.
Without getting too technical, the main idea is that software does not need to be purchased, installed and supported in the traditional way but simply "turned on" as a service much the way you now buy cable TV or cell phone service. If you want to learn more about SaaS just Google it.
The concept is very appealing but getting it to work is quite another story. So, what exactly are the hurdles for making it work in Life Sciences?
The Software Vendor Perspective
The plain truth is that software vendors are just not ready. There are a number of reasons here. The most important from the vendor's perspective is pricing. If you are used to selling named user or concurrent user seats plus annual maintenance contracts, how exactly do you make sure that your revenue streams will not be hurt by switching to a "pay as you go" model? This one will get sorted out in time. Just don't expect it tomorrow.
Next, it is simply not enough to take existing software code and make it available in a hosted environment. The software has to be designed or redesigned for the SaaS environment. Phil Wainwright, a contributor to ZDNet, weighed in on this topic on his blog by saying that "If conventional on-premises application vendors want to embrace the on-demand model, they're going to have to do a whole lot more than simply start hosting their existing software in a data center. It's just not as simple and easy as that." Being quite blunt, he says that "Unreconstituted on-premises applications have no future in the on-demand world." The lesson for CIOs and anyone evaluating a software package touted as being SaaS compatible, is not to take such statements at face value but get answers from the vendors that will assure you that SaaS compatibility is really there.
Note that EDC vendors who typically provide hosting of their own software are not necessarily SaaS compatible either. In many cases they are simply hiding the complexity of the hosted application from you using the assumption that you don't really care how it works as long as it does work. This will become critical when you move from a "trial by trial" focus on EDC to an enterprise model. Don't assume that there is no difference between the two.
The Hosting Vendor Perspective
Unless the software vendor is also providing the hosting, you can bet that the level of expertise with each application being hosted is minimal to non-existent at the moment. In such cases, either the client, the software vendor or a systems integrator will still need to provide application and training support. This will also be solved over time. One solution will be the formation of industry specific hosting vendors that can provide expertise on a limited number of applications. For example, a vendor may host a specific set of software for EDC*, CTMS*, CDM* or CDR*, PV*, ECM* and eCTD*. The mix may look like this:
- EDC - Medidata
- CTMS - Perceptive Informatics
- CDM - Oracle Clinical or
- CDR - Waban SCE
- PV - Relsys
- ECM - EMC Documentum
- eCTD - IABG
Another key requirement is the ability to track usage of the systems so that billing can be done easily and accurately. Such a capability can be provided two ways; it is either built into the application software or provided as a layer on top of each application. You can guess that the latter approach makes more sense since in most cases multiple applications will be hosted simultaneously. So, the hosting vendor will be forced to create one-to-one integrations with each application or have a single application that can exchange data with any application. Yes, you guessed it, there is no magic bullet here and certainly no data exchange standards for this type of information. So, this one will also need time to mature.
The Client/Buyer Perspective
The key issue here is data security. Even today, Life Sciences companies are scared to death about this. Fortunately, this one can be solved with currently existing technology. The buyer must be thorough and make sure that a "holistic" view is taken of the problem. A solid service level agreement (SLA) followed up with periodic vendor audits and corrective action measures plus automated monitoring and reporting can assure that no breaches are possible.
Cost, of course, is also an important factor. There is not much sense to go the SaaS route unless two things are true: 1. Service quality is improved and 2. Costs are reduced. This means that clients will need to evaluate every part of the SaaS agreement and make practical compromises that support both objectives. One example of this will be the need to decide on the physical or logical separation of data. Are you are willing to have your data sit on the same storage hardware as your competitor's data? If not, expect to pay more.
Another key consideration is process. Clients should expect that internal and external processes will need to change. You can't just turn on SaaS and not see any impact on day-to-day operations. What will be the transition strategy? What roles will be added, disappear or be redefined? How will the vendor relationship be managed? What performance measures will be put in place? And so on...
At the moment, SaaS remains a buzzword in general and so far has had little effect on our industry. This is bound to change over time as the current pressures continue on improving R&D productivity and reducing cost. As this post has shown, there are many issues that need to be addressed by all parties, including clients, software vendors and hosting vendors. SaaS does need to be taken seriously since it is here to stay and can offer real benefits to our industry. Just don't expect it to be a magic bullet or be ready for prime time overnight.
- EDC - Electronic Data Capture
- CTMS - Clinical Trial Management Systems
- CDM - Clinical Data Management
- CDR - Clinical Data Repository
- PV - Pharmacovigilance
- ECM - Enterprise Content Management
- eCTD - Electronic Common Technical Document