Intent
As more and more software ends up in products, evolving them together results in superior products
Motivation
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.
Applicability
Use the pattern when you develop complex products that have hardware and software components.
Structure
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.
Consequences
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
Implementation
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