InformationWeek: Have you done any formal cost analysis?

Meadows: In the case of the discovery model, the cost model is amazing. That's paying off. The nature of that is the key model to use cloud: temporary bursts of compute capacity.

I used to think that extreme affordability benefit was only in that temporary scenario. What we've been doing is evaluating three- to five-year models--whether it's spinning out Windows servers or other compute capacity--not just for temporary use but versus internal cost. At the compute level there's a benefit there as well. What we've not gotten good yet in that modeling is costing the data flow back and forth and how to model that appropriately. But my own view of our analysis says that the cost benefit is not there just for temporary purpose but for ongoing utilization as well.

InformationWeek: You mentioned that you were blessed with an "ideal workload" for this. What is an ideal work set for the cloud?

Heim: That's lots of data, high compute, runs for a long time. Internally, things that would run 800 to 900 CPUs for hours and hours, ... long-running, 850-megabyte data sets running into all that computing, modeling, and then visualization on the back end of that.

Often we want to take data that we have, marry it up with data that's publicly available--could be big genomic data sets--look at all of that collectively, and then extract value from that. So they're very bursty. They really peak. It's a lot of data, and then you're done. And sometimes there's testing hypotheses that are wrong, so you do a lot of work, you learn, but that's not something you want to propagate and move forward or do more with. But on the scientific side, it's a lot of modeling, it's a lot of simulation, and it's very large data sets that you have to do that with. One of the problems is moving that data back and forth, and it's not something we have a simple solution for yet.

InformationWeek: What about lock-in? What are you doing to ensure that you don't get yourself into a situation that you can't get out of?

Heim: [After Meadows addresses technical and strategic aspects of avoiding lock-in.] I think the attractiveness in the model is the time to value.We're always concerned about lock in and exit strategies, but we need to stand on the other side of that and talk about the time to value, and what's the value that's generated by getting in there early and leveraging the model. We don't like lock in, but it's no different than I'm not going to move off of my SAP implementation tomorrow either because I don't like some change that they make. That can be overplayed. I think you can be very conservative in approach, and play a lot of defense. And we're lucky, we're blessed with a good use case on the discovery side, but time to value and leveraging the model, and running fast, and playing offense are equally important.

InformationWeek: Do you have anything you can share where a cloud service enabled Eli Lilly to get something done more quickly?

Heim: I would come back to almost any of these scientific examples that we're generating. We've had cases where it's taken six to eight weeks to get a service up that was really needed when it was requested, and simply by having these capabilities and use cases in place now we've been able to go much more rapidly. Rather than six or eight weeks, we're talking days. Guys can spin these things up in minutes, and the cost is trivial in many cases, for the work that they're doing.

For us, it's pipeline, pipeline, pipeline. Anything we can do to further our knowledge, get products into the pipeline, and develop those more quickly, is crucial to us. It's hard to underestimate the value of letting scientists work at their own pace.