Should we buy or build? As the leader of an internal software development team at an academic medical center, this is one of the most common questions we face. It is also one of the most difficult to answer, due to the long-term implications of our decision.
I’ll talk a little here about how we approach buy versus build decisions, then discuss some of the key factors for successfully building and supporting internally developed software solutions.
The decision to buy or build.
The most important factor in this decision is the availability, suitability and cost of the products offered commercially. Our decision is made easier when there is a commercially available product that meets our specific needs and is available at a price we consider reasonable, especially when compared to the full life cycle costs of developing an alternative internally.
It’s even better when the product has been developed by one of our main software partners, for example, our existing EHR or ERP vendors. In this situation, we benefit from working with a trusted partner and the solution is likely to integrate seamlessly into our existing workflows.
But many times our decision is not so simple. The more unique our needs are, the more likely it is that a commercial solution will not meet those needs.
For example, for the patient care aspects of our work, there tend to be more commercial products available compared to offerings that could serve our medical school. For situations where there is no commercially available product, the decision comes down to “build or not to build”, where we decide to proceed or not based on evaluating the return on investment of the effort.
In situations where commercially available products exist, we often issue an RFP and evaluate the vendor’s products, their features, and their cost compared to an internally developed option.
Building internally, now what?
We’ve evaluated our options and decided that the best approach is to build and maintain a custom application. Clearly, we have a lot of work to do to develop a custom application, mainly the classic requirements, design, build and test work. But what is often not appreciated is the amount of non-technical work required to create and support a custom application throughout its lifecycle.
When you buy a product from a vendor, you’re buying more than just software. Commercial vendors continually update their products, which involves making decisions about what new features to introduce to improve the product. While customers may not agree with those decisions, that’s work that doesn’t need to be done internally. When developing a solution internally, someone needs to perform the product management function to decide what to build next from what becomes an increasingly long list of “wish list” items from the user community. internal.
These are three of the areas we focus on to ensure success:
-
Product management partnership between operations and the software development team. When we build a custom application, it’s typically because our organization has unique needs that can’t be met with commercial products. So to be successful we need to have an operational or clinical leader who can convey business needs and set priorities for our work. When we have lacked such a partner, our software development efforts have been less successful because it is difficult for a software team to understand the nuts and bolts of what they need operationally. On the development team side, our software product owners can contribute to this process, but there is no substitute for a creative and committed operating partner.
-
Have a team for the entire product life cycle. After the initial delivery of a custom-developed solution, we must engage technical staff to improve the product, fix bugs, and provide technical support to end users. But equally important is the long-term commitment of our operating partner to continue steering the product in the right direction. Without that commitment, our internal products can fail and lose acceptance, because the product is not evolving to meet changing user needs. Ideally, our product management team would include participants from our everyday users and our analytics and training communities.
-
Technological update planning. Some of the apps we create have a short lifecycle of several years, to address a short-term need (for example, in response to the COVID-10 pandemic) or to fill a gap until a suitable commercial product is available. . At the other end we have developed a series of applications that have been in production for more than 20 years. For these long-running applications, we need to set expectations and periodically allocate resources to refactor and modernize our applications so they continue to function correctly.
When commercial software solutions are not available or suitable, custom software can help organizations meet their unique needs. Increase your chances of long-term success by establishing the right team and partnerships from the beginning.
Glenn Fala is associate CIO of software development at Penn Medicine.
