Randall Spratt, executive vice president and CIO at McKesson Corp., considers open source an essential part of the company's product development strategy.
McKesson Corp. is a multifaceted healthcare company, a large distributor of pharmaceuticals and a thriving developer of healthcare-related IT systems. Its software and hardware are installed in more than 70% of U.S. hospitals with more than 200 beds, and handle everything from billing and scheduling to capturing MRI-machine images and preventing dangerous drug interactions. For the last five years, the company has used open source technology to deliver products at lower cost and greater speed, says Randall Spratt, executive vice president and CIO. After seeing open source, Spratt considers it an essential part of McKesson's product development strategy.
What role is open source playing in your strategy?In our technology division, our flagship line of software products is called the Horizon suite. The reference architecture for that suite is dependent upon open source components and tools to create and develop them. We don't talk about product names, but we employ open source operating systems, an open source object-model interface, a number of different open source user-interface widgets and libraries, open source middleware and Web servers, and a variety of open source tools that not only provide low-level program libraries but also support the programming process in general.What are the key benefits of open source?The benefits for us came from the requirements of the markets we serve. Healthcare is an extremely low-margin business with constant cost pressures. Frankly, our customers were not able to consume the solutions they needed at the pace they needed because of cost constraints. So, we went to open source primarily as a strategy to reduce the extent of third-party costs -- primarily hardware and operating system costs -- that were in the solutions we sold to customers. We saw those benefits emerge dramatically -- an order-of-magnitude reduction in the expense around hardware, for example -- but we also got unexpected benefits in speeding some aspects of development and higher levels of performance.What were the development benefits?We got access to libraries of capabilities that we would have had to develop on our own -- the ability to take in everything from user-interface widgets to libraries of software routines and schedulers, for example.And how does open source reduce hardware expenses?In two ways. The operating systems make more efficient use of lower-cost hardware than many commercial operating systems, and we architected an environment where the application runs on any number of blades that sit on top of one or more database servers and the load is then automatically distributed. Hospitals can start out with a relatively modest investment and as they add users or applications, scale by adding low-cost blades rather than forklifting out an expensive Unix server and replacing it with a larger server. So, not only do we get the efficiency benefits in the first place, we get a much more scalable environment, where each step in the scale is a modest step upward.Would you say you're at the point where the decision comes down to buy, build or go with open source when you're developing an application?We see open source as typically more of a suboption under "build." We’re going to buy a capability or we're going to build it; and when we build it we typically look at open source as a partial solution to the build. "Build" means it's our product, our intellectual property, we take it out to the market and we sell it. "Buy" means we buy it from somebody else and resell it. We would see open source as kind of a blend of those strategies, but very rarely would we take a pure "buy" option.When you do use open source, is it pure open source or a supported version?It's a mix. For the tools we deliver to our customer base -- operating systems, for example -- it would be a fully supported operating system. For the open source libraries and such, it would run the gamut all the way out to true open source.Who supports the machines you put in hospitals?Ultimately, we do. The first line of support typically is the hospital IT department, but they contract with us for Tier 2 and Tier 3 support, and tiers 1, 2 and 3 support of the application.
What's your experience been with supporting open source operating systems?Like everyone else, it's been a journey. Initially we ran into issues and a number of problems with scalability, but I think today we would say it's a very good experience.How long have you had open source-based products installed in customer locations?Three to three and a half years.Can you talk a bit more about initial problems?We architected a load-balanced solution, and we had some difficulty with lost connections and issues with performance of some components. Operating-system support was generally pretty good; but in a healthcare environment, if you run into a problem, it can literally be a matter of life and death. If we had a downed system and couldn't figure it out ourselves pretty rapidly, we needed Tier 3 support right away. I think we've worked those relationships out. It's just a matter of the companies behind the products maturing in their business models, more than the technology itself.How important was access to the developer community in your decision to deploy open source?I don't think it was real important. It's turned out to be beneficial, especially in the widget libraries and low-level code libraries to have that kind of access.What about in helping you troubleshoot issues, such as the ones you mentioned?Probably not so much. We've got some talented developers of our own. I'm sure there was help offered from the community, and I'm sure we took advantage of that; but I can't say it's a major part of our strategy or a major part of the benefit to us. You have to recognize we're application developers, so we're not cutting-edge with respect to the technologies we deploy. We're consumers of technologies others have built and successfully defended.Are there any projects you've undertaken using open source technologies that couldn't have been implemented any other way -- from either a technical or practical perspective?I don't think there's anything we couldn't have implemented from a technical perspective. But practically -- meaning within the same time or cost of delivery windows -- certainly. Open source has definitely improved our time to market in several key areas, and it's improved the cost of delivery in several key areas. So -- practically, yes; technically, no.Do you have any metrics around what those improvements have been?I've got three case studies we did of hospitals that either adopted some of our open source-based applications or replaced existing applications with the open source versions. There is a fairly good-sized hospital in New Hampshire that reduced its hardware and related licensing capital costs by two-thirds. Overall cost of ownership was reduced 60% in five years for apples-to-apples applications that it replaced with ours. The hospital also cited much easier expansion and upgrade capabilities.
A large hospital of almost 700 beds in Houston went with our solution on bladed open source servers running over Oracle RAC [Real Application Clusters] to deploy a physician portal. It reduced its hardware costs by one-third in a 300-concurrent-user environment -- where users are physicians -- with response times well under one second. A small hospital in Colorado got a 25% reduction in cost, improved response time with reports running twice as fast, and reported an increase in scalability.