5 categories: A pragmatic guide to classifying development projects

People develop products of all kinds: from gaming apps to operating systems, from hearing aids to MRI scanners, toy drones to rockets, from a single industrial plant to a smartphone in millions, and everything in between. To find the right development approach, we first need to understand our product. In this article, I present a classification system that categorizes them according to five dimensions.

This classification is intended more for teams that only have moderate expertise in product development but want to improve it. However, it can also be useful for companies that have been in the market for a long time and realize that they need to rethink their product and their development processes.

I will discuss this topic in my book planned for next year Product Velocity in detail.

Why classify products?

A major challenge in today's product development is speed. For example, the automotive industry is under enormous pressure from BYD, which now develops vehicles in 18 months, while the rest of the world takes more than twice as long.

One of the ways we achieve speed is by leaving out everything we don't need. For example:

• If a product does not have to fulfill any compliance requirements, then we do not need to carry the corresponding overhead in our development process, such as document generation or fine-grained versioning.
• Depending on the hardware load, it will be essential to invest in simulation environments, possibly also in hardware-in-the-loop. This is extremely costly, but for the SpaceX Raptor development this effort has paid off.
• Formally specifying interfaces is time-consuming, but can drastically increase the speed of development in certain scenarios.

When we manufacture systems such as cars, airplanes or even software, we generally understand what we need. But the majority of products fall into other categories: Industrial data loggers, cash registers, door locking systems, printing systems, sorting systems and much more. In this interview, for example Andreas Willert, how the manufacturer of fire protection systems was able to drastically reduce certification time.

Few Prior Art

I don't want to reinvent the wheel, so I started looking for a suitable classification or taxonomy.

In chapter 5 of the ISO 15288 Systems concepts addresses some aspects that are important for development, but no classification. For example, chapter 5.4.3 mentions that ISO/IEC/IEEE 21841 provides a normalized taxonomy for Systems of Systems (SoS). I would also recommend accessing this. But first we need to be sure that we are developing an SoS.

The SEBok has a chapter on Types of Systemswhich contains useful information that has also been incorporated into this categorization, but is not suitable for one-to-one adoption.

I found further literature, but it was always limited to one product class, such as embedded systems or pure software systems. I could not find a more general classification scheme.

Dear reader: Is there already a classification scheme for products, have I overlooked something? If yes, then please give me a short hint. Thank you very much!

The classification

A single product can be quickly categorized using this scheme. To do this, we go through the five categories and select the appropriate point for each.

1. system structure and complexity

• Stand-alone systems: A single product designed and delivered as an independent unit with clearly defined functions.
• Deterministic integrated systems: Several subsystems work together in a tightly coupled architecture, without emergent behavior.
• Emergent integrated systems: Integrated systems whose behavior is not completely predictable due to adaptive or autonomous decision making.
• Systems of systems: Composed of independent systems that function autonomously but achieve higher goals together.

2. dependence of software on hardware

• Pure software: Runs completely software-based without dependence on special hardware.
• Generic hardware-dependent: Requires standard hardware, but no special hardware.
• Hardware-dependent: Software that interacts specifically with hardware components that are essential for the function.
• Embedded systems: Software is part of the firmware on dedicated hardware, without separation for the end user.

3. degree of compliance and safety criticality

• No or minimal compliance: Products with no or minimal legal requirements, apart from general consumer and commercial law.
• Moderate compliance requirements: Products with specific specifications, standards or certifications, but where errors do not directly endanger health or safety.
• Safety-critical: Products whose failure could cause significant harm to people or the environment.

4. update and lifecycle support model

• Continuous Delivery (Software): Software is updated very frequently, sometimes several times a day, with automated deployment pipelines delivering new versions seamlessly to users. This is usually only possible with server-based software.
• App Store / Marketplace distribution (software): Software is provided via app stores or marketplaces; updates are installed manually or semi-automatically by the user.
• Field-updateable firmware: Embedded software that can be updated after deployment via over-the-air update, USB or service tools.
• Consumables: Physical components that must be replaced regularly by the user or service personnel to ensure operation or quality.
• Physical spare parts: Physical assemblies that need to be replaced during the product life cycle in the event of failure, wear or for upgrades.

5. customization and configurability

• Standard product "off the shelf": A standardized product that is identical for all customers.
• Configurable product: A standard product that can be adapted to different application scenarios using predefined settings, options or hardware variants.
• Platform solution: A core architecture that was deliberately designed as a basis for specialized solutions. Supports configuration and controlled customization by integrators, partners or advanced users.
• Customized per implementation: A product that is customized for each customer through project-specific development or assembly and is based on a common core.
• Fully customized solution: Each implementation is a unique project, designed and built from the ground up for specific customer requirements.

Why these categories in particular?

First of all: The scheme is currently in the review phase and may change further.

The selection of these categories is based on the practical observation that they have a particularly strong influence on the design of the process model, team structures and tools in the majority of development projects. They therefore serve less as a theoretical completeness and more as a pragmatic orientation aid.

They are not completely orthogonal, at least in this form: for example, system structure and configurability are related. In this case, I have split them into two categories, as the first is the developer view, the second the customer view. This can have different effects on the development processes.

I am aware that there are other possible dimensions, such as market or business model aspects or team size. These can certainly be taken into account in an extended model, but they seem rather secondary to me at the moment.

And what happens next?

The exercise of evaluating the product to be developed alone helps to sharpen understanding. Stakeholders are forced to think about the development at an early stage.

However, my aim is to be able to provide recommendations and advice for the choice and configuration of the development process (including tools) based on the classification. This will be the subject of a future article.