There are many techniques that help dealing with today’s increasing product complexity. In the following, we describe the black box paradigm, and 3 ways for applying it. While you hopefully have an overarching strategy for coping with product complexity, individual techniques can be applied quickly for harvesting the low hanging fruit.

Event Alert: We are co-organizing the Systems Engineering Barcamp in Hamburg, Germany, on November 10, 2018. Learn more >>

Black Box Thinking

The concept of a “black box” is not new: You define whatever you want to have by its behavior. Consider a coffee machine: You know that the “box” needs some space on your counter and a power outlet. You need to get water and ground coffee into it somehow, and at some point you extract fresh coffee. Oh, and you somehow have to get rid of the waste products as well. But beyond that, you don’t really care how it performs the magic of transforming the inputs into fresh coffee.

This way of thinking can be applied on every scale. It can be applied to a satellite surveylance system, where you input coordinates and get a high-resolution satelite image back. Or it can be applied to a simple resistor, with two connectors and a behavior based on electrical current.

When you buy off-the shelf components, you are typically concerned about the black box description: Consider the resistor we just mentioned: The buyer typically does not care about the material used, only about the electrical properties.

Black Box Pitfalls

If black box design is so great, why don’t we apply it all the time? There are many reasons, and here are a few common ones:

Defining the Boundary: One reason is that defining the boundary of the system requires discipline, a good understanding of the subject matter and lots of experience. If you buy a component, the component implicitly defines the boundary. But if you decompose your own system, there are many different ways for “cutting” it. And if you pick an inferior cutting point, you may add unnecessary complexity.

Leaky boxes: Another problem occurs if the box is not as opaque as you want it to be. Sometimes the implementation inside the black box “leaks” to the outside, with unintended consequences. Consider light bulbs. While a modern LED may fit into the socket for a traditional light bulb, it may not be able to cope with the light dimmer (unless you used a dimmer-friendly LED).

Design vs. Implementation: The modularity of the design does not necessarily fit the modularity of the implementation. This can create problems if the development process does not take this into account. For instance, the attempt to keep the modelarity intact during the design phase can result in clunky systems that are bigger than they need to be. Also, the modularity of the software is typically hidden in the integrated system (hardware plus software).

3 Ways for Writing Black Box Specifications

Having said all this, here is a list of three specific techniques for appying black-box thinking in the specification phase.

A simple but effective technique is to create one-pagers for each (sub)system. The idea is to capture the essential contract between the producer and consumer of a system. Think of the product description in a catalogue. A one-pager should contain:

• Short description
• Function
• Interfaces
• Physical characteristics

If this does not fit on one page, then you are probably too specific. Note that the purpose of this document is communication. Technical details can be captured elsewhere.

One-pagers work really well as the the “contract” between teams. If you are using an agile approach, e.g. “scrum of scrum”, then the one-pager can be used by the product owners to communicate and agree on changes between the various subsystems of the product.

Many organizations work with modern requirements tools like Jama Connect, that allow you to design a relationship model that shows the various hierarchy levels. For this to be effective, you need a development approach that ensures that you define the various (sub-)systems so that the boundaries are clearly defined. Consider this example:

The System Requirements are the foundation for the various subsystems and are the foundation for communication between system and subsystem teams. The subsystem teams never change the system requirements, but instead request changes (if needed) from the systems team.

The subsystem artefacts (Subsystem Verification and Design Description) represent implementation details and are therefore not of interest (and by default not visible) to the systems team.

Just to be clear: such a data model is not enough, unless it is complemented by an appropriate method (like behavior-driven development, BDD) and processes.

The most sophisticated approach is to build a systems model. For this you need modeling tools (like Enterprise Architect) and pick a modeling language, like SysML. Systems modeling languages like SysML contain all the structures for describing a system as a black box, as well the capabilities to design the inside of the box.

System models are hard to read for non-experts. That’s why it is very important to have a sound development method, proper processes that support the method and training for all stakeholders. While it helps to give all stakeholders training to at least read the models, we recommend to invest in extensive tailoring, both of the tooling, as well as the document generation. A well-designed template that produces readable documents drastically improves the acceptance of systems modelling.

Conclusion

Black box design, if done right, is a great technique for dealing with complexity. As we have shown here, the technique can be applied irrespective of the maturity of the development.

But as important, it is a mindset. Keeping the black-box paradigm in mind can go a long way in designing scalable products.