This third presentation discusses how designers need to humbly acknowledge their inability to imagine, without being embedded in the real-life situation, how complex systems behave and perform. This has implications.

1. Designer humbleness (1)
Design for the unexpected
How to implement it in practice – 3
Paul Valckenaers

2. Objective
• Introduce an insight originating from bounded rationality
• Kursk
• Discuss how this impacts problem domain models and their
position within an overall IT system or infrastructure
• Prepare the audience for the next presentation(s):
Implications for the design and implementation of
domain models
Necessity to adopt the proper not-quite-mainstream
software tools to build suitable models

3. Bounded rationality
• There is an upper bound on the information processing
and communication capacity of the human brain
• Cfr. The Mythical Man-month: adding one more member to the team
has a negative effect. The additional communication, coordination, and
conflict handling negates any contribution from the additional member.
• For complex designs, this team maximum is surprisingly low.
• This presentation is about
• Thrown-ness in the reality of the application (domain).
• The design team cannot imagine what is required, what works,
what does not work, etc. without doing it for real.

4. Kursk
• On 12 August 2000, the submarine vessel Kursk was
participating in a large scale military exercise:
• At 11:29, the crew loaded a practice torpedo
• At 11:29:34 seismic detectors at the Norwegian seismic array
recorded a seismic event of magnitude 1.5 on the Richter scale
• Today, we know that the Kursk was severely damaged
and sank to the sea bottom:
• Two minutes and 14 seconds after the first, a second event, measuring
4.2 on the Richter scale, or 250 times larger than the first,was registered
on seismographs across northern Europe

5. Kursk
• On 19 August at 20:00, the Norwegian ship Normand Pioneer
arrived with the British rescue submarine LR5 on board
• Seven days after the disaster (during which Russian attempts failed)
• On the morning of Monday, 21 August, Norwegian divers succeeded
in entering the vessel, …
• The successful rescue/salvage team (in less than two days):
• Comprised professionals who had experience working
on oil rigs in the North Sea.
• The unsuccessful team (during those seven days):
• Had performed extensive training exercises
• Had not been working under real-world pressure,
comprising bad weather, …

6. Deep submersible rescue vehicle
By DoD photo by: JOC David Fliesen, U.S. Navy - http://www.navy.mil; exact source, Public Domain,
https://commons.wikimedia.org/w/index.php?curid=3158252

7. Kursk > domain model implementations
• The Russian team is not to blame
• Real-world conditions and pressures cannot be replaced by
training exercises
• The British/Norwegian team was successful because their divers
had real-world experience, made possible by the revenue
generated from North Sea oil (i.e. from a much larger budget)
• Society is facing more complex problems by far
• Smart networked manufacturing, smart power grids, mobility,
smart cities, smart integrated health care, etc.
• IT models, components, systems or infrastructure
• Cannot be developed based on a designer’s imagination alone
• Reference implementations/designs needs to be embedded
in a relevant reality, have to be used for real

8. Embedded in reality
• Problem domain model implementations
• Cannot exist outside/without their real-life application.
• Will not provide adequate services when designed on the
basis of imagination (of what is required) alone.
• The embedded model implementation may generate
representations, data, information for various/other
external purposes (e.g. compliance with regulations).
• Generating the embedded domain model from external
sources is unlikely to succeed, likely to suffer from
updating issues, incompleteness, mismatches...
• The embedded implementation must become the reference,
the (single) source of truth.

9. Discussion
Disclaimer: The statements in this presentation are only valid when there is an ambition
to build information systems and infrastructure well beyond the current and forthcoming.
Society has such an ambition (smart cities, smart grids, smart homes, smart factories, etc.).
Nonetheless, much of the resources are dedicated to efforts employing more conventional
approaches. From the perspective of bounded rationality, a much more humble stance is
required to achieve the ambitions of modern societies. Indeed, the over-confidence in the
abilities of conventional approaches is not justified. Complexity is the frontier that needs
to be crossed, and it would be pretentious and even arrogant to believe that a community of
experts is able to imagine up front what these future IT systems and infrastructures need to be.
This presentation introduced a first element of designer humbleness where this human admits
being unable to imagine what is required without being thrown into the real-world situation.

10. Discussion
The interesting implication of this insight goes beyond the obvious such as iterative
software development in the Unified Process (i.e. an object-oriented software
engineering methodology). In fact, it is insufficient to have the developers experience
reality. The domain model itself needs to ‘experience reality’ (as its validation).
The problem domain model implementation needs to be embedded in the real-world
IT system and/or infrastructure. This embedded implementation is the reference and
the origin from which other representations (e.g. required by regulations) are generated.
Thus, the interesting implication concerns the overall architecture of the IT systems
or infrastructure. It positions the domain models within the operational systems.
Note that - in order to be the reference - the numerous instantiations of a domain
model from a given type (e.g. of heat exchangers) ought to be managed and sourced
from a single point/organization. This can be a different organization for each model.
In other words, it is a decentralized design - mirroring a corresponding reality.