The document discusses the use of problem domain models to provide stability and coherence in the face of changing user requirements, particularly in ICT infrastructure design. It emphasizes the importance of accurately reflecting the reality of the problem domain to exploit its inherent stability while illustrating this through examples like road maps in navigation systems. Additionally, it highlights the underutilization of problem domain models and the challenges organizations face in delivering functionality quickly, often compromising the models' advantages.

1. Problem domain models
Design for the unexpected
How to implement it in practice – 1
Paul Valckenaers

2. Objective
• Introduce problem domain models as
a source of stability and invariance,
especially when the unexpected happens
• Prepare the audience for the next presentation:
Problem domain models as a source of coherence
and consistency

3. Problem domain stability
It takes time, effort, resources, … (¿miracles?) to change reality
Hence, when designing/implementing ICT infrastructure/systems,
the problem domain is unlikely to change often, profoundly or fast.
• E.g. in the human resource management (HRM) domain
• Personnel will be hired
• Personnel will be promoted
• Personnel will retire, resign or be fired
• …
Today, tomorrow, next year, in the next decade…

4. User requirements’ instability
• User requirements are uncertain and prone to change:
• When customers start to use a system, they immediately
see what should be different, what can be improved, …
• When the fulfilling of user requirements affects competitiveness,
these requirements become a moving target.
• The (wo)man-invented world around us changes all the time (e.g. regulations).
• For instance:
• The human resources department (HR) may change its
reporting requirements every week, based on what
matter needs to be addressed (urgently).
• When the organization will be audited, tries to qualify for
some certification, needs to comply with new requirements
from a major customer, … the IT systems need adjustments.

5. Problem domain models
The inherent stability of the problem domain can be exploited by
the use of a problem domain model within the overall IT system.
To inherit the stability, the problem domain model must not include
properties, features, functionalities, limitations, etc. that are absent
in the corresponding reality. This can be tricky/subtle.
The use of a problem domain model as a separate and explicit part
of the overall IT system is feasible and economical almost everywhere.
Exceptions are niches (e.g. space, high-speed telecom) that need to
pre-process/compile/… domain-related information for computational
efficiency reasons (i.e. extremely high speed or low energy consumption).

6. The earliest problem domain models
Road maps in navigation systems
By Dr. Blofeld - Maps for Free (OpenStreetMap), CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=15284212

7. With problem domain models
Example: the use of road maps in navigation systems.
When confronted with a new “A > B” user request, the map
based design may need to expand the map (to cover more roads),
to enhance the map (to include topological data for cyclists), etc.
Importantly, this never explodes the size of the model and
it is trivial to keep it unperceivable to the existing user base.
When confronted with a blocked road (e.g. by an annual fair), a
map based design simply generates a new route when informed
through the problem domain model.

8. Without problem domain models
Alternative design without an explicit problem domain model:
a route descriptions database replaces the road maps.
When confronted with a new A > B user request, it needs to be
added to the database (will explode!). When generating routes by
combining existing routes, inefficiencies are likely (unless primitive
route descriptions become so small, the database becomes a map).
When a road is closed indefinitely, blocked temporarily, or becomes
one-way, route descriptions become invalid (they break).
When an application wants to look for parking space, … the
database is ill-suited to contribute, etc.

9. Without problem domain models
When Carnaval parades block a road segment, route descriptions fail.
By Marco Verch - Schilderwald am Neumarkt, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=38580171

10. Discussion
Why is the potential of explicit problem domain models
so unknown and underutilized except for road maps, … ?
• It is not easy to withstand the pressure from the user
to deliver the required functionality ASAP.
• It is easy to introduce limitations in the problem domain
model that annihilate its benefits.
• …
The forthcoming presentations will cover this extensively,
shedding light on what it takes to design problem domain
models that preserve its stability benefit and (much) more.