The Firmware Conundrum: Build or Buy

Every development team needs to make the decision as to whether they will design and build their software from scratch or buy software components. In many instances, the decision is not driven so much by a business decision as it is by engineer ego shouting, “I can do it faster and better than they can!”. Even if that is true, launching a successful product requires far more considerations to be taken into account to be successful, efficient and maximize productivity. So how might a team go about deciding whether they should build or buy all or some software components?

Step #1 – Identify available resources

The first step is to identify the resources that are currently available to the project team. Taking stock will give the team an understand for how many engineers are available, the allotted time to complete the project (rarely is there ever enough), overall project budget and perhaps even start-up capital. Teams may even consider identifying the tools that are readily available that could affect the development schedule.

Step #2 – Categorize the components based on complexity

Developing a basic software architecture will provide the development team with a general idea about the device complexity and the major software components that will be required. For example, identifying that a graphical user interface with a touch screen is required would undoubtedly be ranked high on the complexity list due to the need for graphics drivers, communication drivers, image design interfaces and messaging interfaces. Each component required for the system can be ranked with a value from one to ten with ten being the most complex software component. Components with high complexity rankings are candidates for purchasing.

Step #3 – Review the teams’ skillset

Once a component list has been generated with complexity rankings, the available team members’ skills can be evaluated against the components that are required for the system. Each team member can be ranked based on expertise and previous experience developing each component. Ranking skills in this manner allow the team to identify skill gaps in addition to leveraging past experiences to get an accurate read on development time. An example for how one might create such a ranking can be found in Figure 1.

Figure 1 – Component Complexity and Skill Ranking

Step #4 – Calculate the break-even point

Armed with a fundamental system understanding along with the capabilities that exist in the development team, it is now time to calculate the break-even point for building the software versus purchasing it. Calculating the break-even point can be tricky since there are numerous factors that come into play. Typical failure points come from optimistic estimates on development time, firmware maintenance and even component complexity.

The major business trade-off is time-to-market and overall costs. Building a component may wind up being cheaper but take four times as long to develop. Is that an acceptable business trade-off or is getting to market king? To decide the answer, developers need to identify possible vendors for the firmware components, understand their warranties, cost, delivery dates and any potential integration issues that could arise. The component cost to buy can then be compared with the estimated build cost and when compared with time, a break-even point can be determined.

Step #5 – Determine the build vs buy ROI

At the end of the day, the team needs to provide a solution that attempts to optimize the return on investment (ROI) that the company is making in the product. There are many ways that this could be looked at. First, one could look at attempts to minimize costs or secondly, to maximize sales. Over the product life-time, does the license fee associated with the purchased software cost more than building? Maybe the initial build costs are higher than purchasing the software but due to volume or the product roadmap it makes sense to invest in the engineers’ skillset so that the work can be done in house. There are many factors that need to be considered and the while many view ROI as strictly a monetary return, a wider berth may be necessary to make the right decision.

Step #6 – Make the decision

At some point, the development team will need to decide. We’ve discussed a few steps so far that should provide some engineering or scientific thought into the process but sometimes the decision will be made simply on intuition. Other times the decision will be made because it would be cool to write our own RTOS. Attempt to use a controlled decision-making process.

Conclusion

Making the decision to buy versus purchase firmware components can be a difficult decision to make. In many cases, the initial sticker price is a shocker and teams dive in to do it themselves. The result in some circumstances can be delayed deliveries or even increased development costs. Following the steps laid out here can help turn the decision process into a more controlled and thoughtful process by considering the larger picture and not just short-term cash flow.

2 thoughts on “The Firmware Conundrum: Build or Buy”

  1. One factor that is often ignored in the build vs buy decision is how much time will be required to overcome defects in the purchased software. Tracking down bugs in purchased software can be challenging for any team and the time required can be very difficult to predict in advance. The bugs oftentimes do not appear until late in the project when the project is in its most complex state.

    Plus, as new versions of the purchased software become available, the new version has to be integrated and tested each time. Old bugs may disappear and their work arounds removed while new bugs can then appear.

    Furthermore, many libraries and their headers are not MISRA compliant (or compliant with whatever standards your company is using) which further complicates the integration.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.