Build AND Buy

In my role at CIO at Harvard Medical School and CareGroup, I'm often asked if we build or buy our enterprise applications. The answer is that we build AND buy, a strategy that has worked very well for over 20 years and I anticipate will serve us well for the next 20.

The trend in IT today is outsourcing, offshoring, buying software as a service (SAAS), and retiring home built legacy systems. Since I've just declared that we build software and will continue to do so, have I lost touch with the latest Gartner and Forrester reports?

Several healthcare application vendors are my close partners (I'm writing this at the Elephant Walk in Waltham just before dinner with 3 vendor partners). Vendors can produce full featured software on a regular release schedule and can be very innovative. Buying software means that I do not have manage developers and can leverage product development costs that are spread over many customers. Buying software means that the internal politics of development prioritization can be bypassed by relying on the vendor to adjudicate which features are included in upgrade releases. With reduced management responsibility, shared development costs and relief from institutional politics, what's not to love?

In complex organizations like Harvard and Caregroup, we have hundreds of applications. If we purchased all these applications, it's likely they would have dozens of different user interfaces, many navigation paradigms, several passwords, incomplete data integration and a high training burden. In 1998, my team and our stakeholders made the decision to implement a service oriented architecture (SOA) throughout the enterprise and own the "front end" of our applications. This means that our clinical systems have a single sign on, a single means of navigating the application and appear to have all our clinical data integrated completely, even though there are dozens of applications involved behind the scenes. We've built just about every system that our clinicians touch directly but buy the underlying departmental systems such as laboratory/blood bank, PACS imaging, critical care systems that interface with patient monitors and drug dispensing systems that require FDA approval. When we purchase a system from a vendor we require "Web 2.0" XML exchanges that enable us to link together the data housed in each application with our front end user interfaces. In a sense we've become experts at the plumbing that connects web applications.

This build and buy approach benefits the users with "virtual integration", ease of use and significant reduction in training requirements, but the real power in the strategy is that we can control the pace of innovation. Here's a case in point.

BIDMC was visited by the Joint Commission on July 23, 2007. A major focus of their visit was medication reconciliation, ensuring an accurate medication list at every transition of care. Very few vendor applications provide the tools necessary to do this. In a matter of weeks we built a community wide medication history health information exchange empowering physicians and patients to add, edit, delete and correct medications in every site of care. We brought this application live on July 24, 2007 and passed an audit for 100% utilitization of the software by October 1, 2007. It's highly unlikely this pace of innovation could have been accomplished with vendor software.

When folks ask about my build and buy strategy, I refer to them to the book "Built to Last" by Jim Collins and Jerry Porras, which highlights a concept called the "Tyranny of the OR verses the Genius of the AND". The authors suggest that highly successful companies are not dogmatic in their choices. It's ok to embrace Open Source AND Microsoft technologies. It's ok to embrace Linux, Mac OSX AND Windows. This does not mean that we're indecisive, it means that we use the right tools for the right task.

Hopefully, our broadly communicated strategy that we buy those applications which are mature, highly functional and widely deployed while we build the front end, the data integration and those applications which are cutting edge for which no vendor products are available will be viewed as the "genius of the AND" when the next generation of IT professionals looks back on our work.