View Only

Pattern: Evolve Hardware and Software Together

By Michael Jastram posted 03-07-2019 05:54



As more and more software ends up in products, evolving them together results in superior products


Traditionally, either you first have some hardware and then you write the software – or the other way around. This used to work in the past, where a complex hardware (e.g. hydraulic system) had to be driven by software; or where some software required some hardware extensions (e.g. ticket printing machine). But today, customers expect amazing products where hardware and software are seamlessly integrated. This is only possible if they evolve together.

The blog post Why The Demand For System Engineers Is So High also makes a good case for the necessity of this.


Use the pattern when you develop complex products that have hardware and software components.


You need to capture your requirements independently on whether they are realized in hardware or software. This happens on the "Requirement" level in the data model shown below. At that point, you perform a split between hardware (Design Requirement) and software (User Story).

It is not unusual for hardware and software to evolve at different speeds. But key is the common ancestor (requirements). This allows changes to hard- or software to propagate to the overarching requirement, which alerts the other team that they may have to react to the evolution that took place.


The pattern has the following benefits and liabilities:

  • Benefits:
    • Seamless evolution of the product, irrespective on where (HW or SW) a product feature materializes
    • Early communication between teams, which mitigates costly integration issues
  • Liabilities:
    • Hardware teams may not be able to react as quickly to software changes, which can result in tension and unreasonable expectations


Any tool that can deal with a solid data model can support this. It's more important that the teams understand the new mode of work.
Often, hardware and software teams use different tools. Make sure you prevent friction at the tool boundaries (see Define Hand-Over Points).

Related Patterns