Content uploaded by Hans Nouwens
Author content
All content in this area was uploaded by Hans Nouwens on Apr 08, 2022
Content may be subject to copyright.
Situational
Architecturing
An integrated governance pattern for
sensemaking architecture.
Authors
Hans Nouwens, hans.nouwens@sogeti.com
Marlies van Steenbergen, marlies.van.steenbergen@sogeti.com
Anton Opperman, anton.opperman@eur.nl
Edzo A. Botjes, ebotjes@xebia.com
Ton Eusterbrock, ton.eusterbrock@sogeti.com
Sogeti Netherlands - Architecture Council Higher Education - Xebia Security
Editors
Lars Cordewener
Situational Architecturing
– a DYA whitepaper by Sogeti –
Hans Nouwens‡, Marlies van Steenbergen‡, Anton Opperman§, Edzo A. Botjes∗, Ton Eusterbrock‡.
‡Sogeti Netherlands §Architecture Council Higher Education ∗Xebia Security
Abstract—This whitepaper describes part of our vision we
call Sensemaking Architecture. A vision that is based on our
understanding as experienced enterprise architects about
sensing and perception, managing complexity, applying
ethical thinking. In this paper we add to this vision a way to
translate the purpose of an organisation to a way of
working for enterprise architects that honours the
challenges of a complex and changing environment. Inspired
by psychology, industrial design, sociology, and systems
theory, we introduce a model with three levels.
On the rst level we are making sense. What purpose does
this organisation have, and what sub-systems are there? We
give some perspectives to help nd these subsystems.
On the second level, for each sub-system we change
situationally. What purpose does this sub-system have, and
what changes are needed? We present a way of identifying
the situation and give a pattern to help govern and guide
changes. This comprises a situational architecture approach
based on combining architectural method fragments.
On the third level we change via a structured way of
working, using best-practices, specialised working-regimes
and standard methods, suited to the circumstances of the
change.
Editor: Lars Cordewener
Contents
I Sensemaking and Situational architecturing 3
I-A About this whitepaper .......... 3
I-B Our two origins: Multi dynamic archi-
tecture and Multi modal governance . 3
I-C Introducing a situational context for
architecturing ............... 4
II Level 1 - Sensemaking 6
II-A Enterprise Sensemaking (ES) ...... 6
II-B Enterprise Architecturing (EA) . . . . . 9
III Level 2 - Situational 11
III-A Sub-system Guiding (SG) ........ 11
III-B Sub-system Architecturing (SA) . . . . . 14
IV Level 3 - Structured 16
V Summary 16
VI Discussion 17
VII Conclusion 17
VIII Theoretical background and inspiration 18
DYA – situational architecting – version 1.1 – February 28, 2022 3
I. Sensemaking and Situational architec-
turing
The environments we work in are becoming increasingly
complicated, sometimes even complex. To ensure giving
the best advice to an organisation and be the best
advise-facilitators, architects will have to get smarter. As
architects, we will have to improve our way of working;
we must adapt our professional products to the
exponentially increasing external variety. We must be able
to deal with this variety without falling into the
reductionistic trap, without killing the much-needed
internal business variety. But how? It is time to take our
sensemaking duty seriously and develop our situational
awareness.
In this paper, we discuss how architects can deal with
complexity by switching between approaches according
to the type of situation.
A. About this whitepaper
This whitepaper expresses a vision that is not validated by
a large number of case descriptions or other relevant
scientic methods. However, it makes use of some
accepted approaches and theories from other elds, such
as psychology, industrial design, sociology, and systems
theory. In the coming years, we intend to deepen this
vision based on our empirical experiences, gratefully using
your feedback.
We start with a brief explanation of our two origins of
the sensemaking architecture vision.
Next, we dive deeper, elaborating sensemaking,
facilitating change situationally, and working in a
structured manner, in three subsequent chapters. This is
the main body of this paper. We nish the paper with a
short summary of the foundations that guide our
understanding, a discussion and references.
B. Our two origins: Multi dynamic architecture and
Multi modal governance
In previous years the authors of this paper were driving
two separate developments: multi dynamic architecture
and multi modal governance. We inspired and helped
each other. For a while we saw the two developments as
overlapping, but both potentially valuable to develop
separately. Today we see them as complementary and
combine them, becoming the situational vision of
sensemaking architecture.
The origin of the rst concept, multi dynamic architecture
(Eusterbrock and van Steenbergen,2016;van
Steenbergen et al.,2016a,b) started with the recognition
that we need dierent architecture approaches for
dierent organisations. Extending that vision, we
recognised that within organisations there are
collaborating environments, multi-disciplinary teams,
ad-hoc and institutionalized, even sub-organisations. All of
which serve dierent purposes, have dierent needs for
adaptivity, have dierent levels of complexity (see page 9
for an example). These dierences should be reected in
dierent architecture styles and architectures that guide
the development of the particular sub-system. Based on
systems theory, attributes were identied to enable the
selection of a tting architecture style.
Summarised: the multi dynamic architecture concept
focusses on enabling dierent dynamics of the
organisation by supporting sub-systems with dierent
architecture styles.
The origin of the second concept, multi modal
governance (Nouwens and Opperman,2017;de Mik et al.,
2019) started with the need to clarify Gartner’s proposed
bimodal strategy. The authors saw their respective
organisations struggle with questions on how to organise
their change initiatives. How to support any change with
sound and practical methods for project management and
architecture? They saw a need for a holistic, more
adaptive, more dynamic way to organise the changing
information and IT landscape. This was the basis for the
introduction of working regimes and the related project
and architecture styles.
Summarised: the multi modal governance concept focuses
on enabling dierent ways of working for executing
change initiatives with dierent architecture styles.
Figure 1: our two overlapping origins
The combination of these two concepts forms a set of
decision-making strategies that allow for a way of
working that is aware of the local situation in its
ever-increasing complex environment. An architecture
style is applied for each identied or recognised
sub-system, reducing the complexity of the whole to
complicated parts and dependencies. In both approaches,
changes are contained within a sub-system. For each
change initiative an architecture guides the governance
regime of the change organisation.
4 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
C. Introducing a situational context for architecturing
How can we as architects increase our ability to grasp the
complexity of organisations without falling into a
reductionistic trap? How can we deliver our value by
facilitating decision making? How can we deliver the
much-needed coherence, the concinnity as referred by
Hoogervorst and Dietz? (Hoogervorst,2009,2017;Dietz
et al.,2013). Hence, how can we guide our organisation
to a skilful and harmonious arrangement of the dierent
sub-systems?
Based on a selection of theoretical inspirations (as
detailed in chapter VIII) for situational awareness, we
conclude that at least we need to
•be a highly socially skilled actor;
•be able to observe and perceive;
•be able to interpret, prioritise, value and remember
the resulting information;
•make use of a developed mental model (domain
knowledge);
•focus on connections instead of the elements;
•have a goal, a purpose.
Based on this situational awareness, we then should
dierentiate our way of working.
A sensemaking architecture way of working creates this
understanding. Understanding how the organisation
exists, survives, and thrives in its environment. We assess
the situation; we identify and dierentiate the several
sub-systems. With this understanding we start to build a
model per sub-system and the interdependencies
between these sub-systems.
As stated by many, architecturing needs to deliver
performance and value by facilitating good decision
making (van den Berg et al.,2019). The architectures we
deliver must enable us to create a sustainable exibility.
We state that the way to do so, is to dierentiate
between contexts and sub-systems and adjust both
content and way of working to the needs of a situation.
We do recognise the critique that not every
organisation is the same size and that in smaller
organisations distinct sub-systems cannot be
identied. The same holds for organisations that
are not concurrently executing many change
initiatives. However, for any architect in any size
of organisation it is good to be sensitive and
aware of the organisation’s context and to be
able to adapt your style of architecture. Be smart
about the amount of architecture time and eort
you put into supporting a project.
1) On the rst level we are making sense.
Take guiding principles from enterprise governance
and many external sources, open your senses, feel
the culture and interpret narratives. Design an
enterprise architecture. The applicable methods in
this complex environment are based on systems
thinking, characterised by being mostly qualitative,
unprecise and based on narratives. This enterprise
architecture is a very high-level model depicting the
sub-systems of the enterprise with their purposes,
their interrelations and relations to the enterprise
ecosystem. Plus, the enterprise architecture
principles, guiding the overall development of the
enterprise.
For each sub-system we can describe why they exist
(their purpose) and how their development should be
governed, as well as prescribe what should be
architectured to develop their purpose.
From this rst level we initiate multiple concurrent
sub-system architectures, which brings us to the
second level environment.
2) On the second level we change situationally.
For each sub-system take the guiding principles of
the sub-system governance and design a sub-system
architecture. The methods in this (now reduced to a)
complicated environment, are based on practices that
have a good track record to solve a known problem.
Each change initiative within each sub-system
potentially has a dierent way of working, specically
for the situation. From the sub-system architecture,
for each change initiative we can describe why a
change exists and how the change should be
managed (working regime), as well as prescribe what
the change should consist of.
From the second level we initiate multiple concurrent
changes1, which brings us to the third level
environment.
3) On the third level we work in a structured
manner.
Taking the guidance from sub-system architecture we
design the change, resulting in a functional design
document describing the change. A specic change
architecture is designed that will guide the solution
design or solution procurement process. The change
is executed, showing what to do and with what tools.
The deliverables are handed over to the operational
management, explaining how to change the way of
working and how to instruct the people executing
the business processes.
All of this will be done concurrently. There will be many
changes being designed, many architectures being
derived, many styles of working being applied etc. In
several sub-systems. All at the same time.
1We use the more generic term change instead of project. This
is to emphasise that it can be managed in any form. For example,
as a prince-II project, any agile variation or DevOps . The situation
of the sub-system will prescribe the way of working.
DYA – situational architecting – version 1.1 – February 28, 2022 5
In the next three chapters, we will explain each of the
three levels of our proposed model and try to give
guidance on how to govern your way of working.
Each level can be regarded from two perspectives and
three dierent languages.
•The subjective perspective, about explaining why we
are and exist, mostly using a teleological2language,
expressing goals and purposes in relation to humans.
In short: why?
•The objective perspective, about the construction of
things, using an ontological3language, expressing
how things and phenomenon are. In short: what?
There is no way to easily bridge these two
perspectives. You will have to use your imagination to
design a solution. What to do, to solve my questions
and goals?
•For bridging the two perspectives we use a functional
language. In short: What does it do for whom?
Figure 2: two perspectives, three languages
2Teleology (a combination of τ´ελoς,télos, end, aim, goal, and
λ´oγ oς,logos, explanation, reason) is a reason or explanation for
something as a function of its end, purpose, or goal, as opposed
to as a function of its cause.
3Ontology (a combination of `´oν,on;`´oν τ oς,ontos, being, or
‘that which is’ and λ´oγ oς,logos, explanation, reason) is the study
of being, that encompasses a representation, formal naming, and
denition of the categories, properties, and relations between the
concepts, data, etcetera.
6 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
II. Level 1 - Sensemaking
On the rst level we are making sense. The two
perspectives we label as
•Enterprise Sensemaking (subjective)
•Enteprise Architecturing (objective)
Figure 3: Level 1 - Enterprise Sensemaking and Enterprise
Architecturing
To read the gure, think like this:
On the corners of the model there are the things we as
architects create. Depending on the perspective, some of
these are as concrete as deliverables in the form of a
model or formal description. Some are as soft as an
awareness of an emotional state.
In between these states there are interactions,
inuencing forces or coordinated processes. For instance:
•an sub-system architecture can be derived from an
enterprise architecture. This is done within the zone
of an ontological language, describing what should
exist on the enterprise level, and what should exist
on the sub-system level;
•a sub-system guidance is guided by the enterprise
architecture description and awareness. Sometimes
this is focussing on value for stakeholders
(subjective), sometimes this is guiding functions for
stakeholders (objective);
•The process to get from a sub-system guidance to a
sub-system architecture is less structured. The
starting point is a functional description. This needs a
creative, probably iterative, design process.
these three together we call Enterprise Architecturing.
For each of the levels we will be presenting the two
perspectives and labels.
A. Enterprise Sensemaking (ES)
First order of business in this sensemaking phase is
literally opening senses. Forget about business for now.
See, listen, smell, taste, and touch. Listen to stories, talk
to many stakeholders. Feel the culture, have lunch and
drink lots of coee together. Find out why this
organisation exists, why people feel connected to its
mission and purpose, why the organisation is in its current
state and why it should change. Discuss your perceptions,
gradually building your interpretation, ordering and
prioritising your interpretations, placing them in context
of the organisation. Enrichening your interpretations with
your personal mental models and visa-versa.
Organisations are social, complex and viable systems.
Hence, in a changing environment, organisations need to
evolve or risk becoming irrelevant and obsolete. They
change form, function, outputs, intention and sometimes
their purpose too. The required form of resilience is
related to the needed amount of evolvability, that is
related to the amount of change of the environment. For
more information on resilience see our whitepaper Design
for Chaos (Botjes et al.,2021).
Every organisation consists of several sub-systems, each
with their own focus and therefore their own change
dynamic, need for speed, quality levels, available
resources, culture, and governance. The nding,
recognising and acknowledging of sub-systems is done by
looking for their purpose, which positively contributes to
the organisation’s mission and strategy. Examples of
purposes are: making and keeping public space attractive,
safe, ecient and liveable for citizens and organisations
(purpose of a spatial planning sub-system in a
municipality), ensuring responsible and eective use of
data throughout the organisation (purpose of a data
sub-system) or ensuring strategy achievement (purpose of
a management sub-system).
Our vision on situational architecturing described in this
paper is strongly based on the concept of (sub)systems. It
is important to realize that, as sub-systems are identied
by their purpose, there is no a priori relation between
organisation sub-systems and the organisational units of
an organisation. Sub-systems are functional
decompositions based on purpose. Hierarchies of
organisation units are constructional decompositions
mainly for attaining control.
With a situational awareness (see our description
referring to Endsley at page 18) at least on the
Comprehension level, we have an initial understanding of
a purpose. Next thing is to store (remember) this
interpretation, make the models explicit and try to
project and model a future state. Going to the situational
awareness level Projection. Be aware of the iterative
nature of this approach. Don’t be afraid to go back, open
your senses again and re-interpret your perceptions.
In the next section we will delve deeper into how to
recognise sub-systems and design an Enterprise
Architecture.
DYA – situational architecting – version 1.1 – February 28, 2022 7
1) Recognizing sub-systems
Sub-systems are not necessarily the same as an
organisation unit, business capability or business function.
There is no dened method for recognising, identifying
and designing sub-systems. The context is complex, the
results are uid and constantly in motion. “The path will
be created by every step”.
However, we found several perspectives that help us as
enterprise architects to cluster and identify elements that
have a common purpose. Iteratively we start to recognise
a coherent set of sub-systems.
Figure 4: recognising an emerging 3D shape by using many
at perspectives.
a) Recognising sub-systems by looking at the dimensions of
purpose
As proposed by van Ingen et al. (2021), the dimensions of
purpose are signicance, aspiration, direction, unication,
and motivation. Using their descriptions, we see the
following recommendations:
•Find some clustering of stakeholders. Make use of an
existing vision statement, nd out what they want to
be. Make use of a goals description, nding out what
they want to do. Then look for the needs and
problems they try to solve.
•Find coherence (if any) in all current and proposed
actions. It is potentially valuable for clustering input
to recognise sub-systems, because these can be
directly translated to changes in the next level.
•Shared understanding and shared meaning are
created by employees. We are very hesitant to re-use
a current business-unit structure to identify
sub-systems. But some inspiration could be found in
the strategic documents of the dierent
departments. How do they describe their
departmental purpose to their employees?
•Some inspiration can be found in various forms of
communication. Are people motivated by a vision, or
is there money to be made by employees in an
incentive programme? Are there examples of
advertisements? What texts are used in recruitment?
Together these give an idea of shared purposes. Are
there some clusters to be found where the purposes
dier? These are potential enterprise sub-systems.
b) Recognising sub-systems by looking at the change dynam-
ics: the Adaptive Cycle of Resilience.
An indication of an enterprise sub-system is the state of
change of a group of business functions on the
lemniscate of the Adaptive Cycle of Resilience (ACoR) as
described by Takács and Abcouwer (2020).
Figure 5: Adaptive Cycle of Resilience (ACoR) (Takács and
Abcouwer,2020)
The position of a business function in one of the ACoR
quadrants is a strong clustering indication for being part
of a sub-system. Intuitively it is very hard to have a
sub-system that would be in a state of challenge and at
the same time being in the equilibrium state. It is hard to
imagine that a sub-system is at the one hand looking for
new ways of doing business, looking for new strategic
opportunities, challenging everything in its way, etcetera.
And on the other hand is making money, everybody
knows what they are doing and things ow smoothly. We
dare to say that such a combination, a single sub-system
in multiple states, is probably unlikely.
c) Recognising sub-systems by looking at the business func-
tion model.
What are the business functions that are part of this
sub-system? A business function is a combination of
operations and business capabilities that
implementation-independently contribute to the mission
of an organisation. They are more stable than the
organisational structure and probably comparable
between organisations in the same sector. Typically, a
business function model can be provided for by a sector
reference architecture. The contributions to the mission
can be an inspiration for recognising a purpose.
Being part of a layer of business functions (primary,
supporting, generic) can strengthen a purpose
description. However, be careful, a sub-system may
include all three layers of business functions.
d) Recognising sub-systems by looking at the Viable System
Model.
The Viable System Model by Beer (1972) is an
organisation construction model consisting of functional
8 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
About the holistic view of an enterprise. In this
paper we propose a number of perspectives to
nd clues to recognise dierent sub-systems
with a goal of governing them interdependently
and situationally. The question is if we can have
a whole view of the enterprise when we have
acknowledged a number of sub-systems? For
this we use and refer to the story about the
blind men and an elephant and the reections
by Luke Craven. There is no objective elephant
that is commonly discovered by the blind men.
We struggle with complexity in our attempt to
make sense of our perceptions, coloured by our
own experiences. We should appreciate and
make use of the dierent perspectives, even if
they might not result in something others call an
elephant. Embrace our limitations of sensemaking,
accept multiple and partial understandings of the
complex whole. “…it is about creating a space in
which we can sit with multiple, potentially incom-
patible perspectives, make connections between
them because of and despite their dierences, and
have conversations about what we can do with
them that we might collectively value.” (Craven,
2021).
sub-systems, each with a distinct purpose. Beer introduces
his model in “Brain of the rm” in 1972. Originally derived
from the architecture of the brain and nervous system,
elaborated in several following publications. The model is
recursive and consists of six classes of sub-systems.
Together the sub-systems are able to handle the
enormous variety from the environment and the internal
variety. It thus honours the law of requisite variety.
Figure 6: The Viable System Model (VSM)
Summarised, the model can be described as:
•The Environment. Parts of anything beyond the
boundaries of the system, delivering and supplying
goods or services and information.
•System 1 – production. This is where the primary
business activities happen. Where products or
services are delivered or retrieved to and from the
environment. Usually there are several instances of
System 1. In itself System 1 is a Viable system, as it is
recursive.
•System 2 – coordination. In this system the
information ows between systems 1 and between 1
and 3 is coordinated.
•System 3 – management. Representing the control,
giving orders and providing resources to Systems 1.
Within this system there are the support functions of
management. Focus on the here and now.
•System 3* – audit. A non-continuous function that
validates the compliancy of the Systems 1.
•System 4 – vision. Focussing on outside and the
future, this function has direct contact with the
environment, proposing the new direction of
management.
•System 5 – ethos. Responsible for overall policies
and keeping a balance between System 3 and System
4.
The recursive nature of Systems 1, and its viability as a
sub-system makes Systems 1 potential candidates for the
class of sub-systems we are looking for. Systems 2, 3, 3*,
4 and 5 are no potential candidates, as they separately
are not viable systems and are not recursive.
e) Recognising sub-systems by looking at the capabilities by
Ross et all.
In their 2019 book Designed for Digital, Ross et al.
describe ve capabilities that organisations “must develop
to succeed at digital”.
1) Shared insights
2) Operational backbone
3) Digital platform
4) Accountability framework
5) External developer platform
The identication of these ve capabilities is an indication
for a sub-system. Some sub-systems could focus on
delivering some of these capabilities for their own
sub-systems. Others, for instance the operational
backbone, could focus on delivering to other sub-systems.
Each having their own architecture regime.
DYA – situational architecting – version 1.1 – February 28, 2022 9
Example: Sub-systems of a municipality.
A municipal organisation has various sub-systems
that dier in culture, strategic focus, manage-
ment, risk of failure, continuity requirements,
quality requirements, changeability, development
method, development speed, and/or innovative
character:
•The spatial planning sub-system aims to make
and keep public space attractive, safe,
ecient and liveable for citizens and
organisations. This subsystem mainly works
on a project basis in close collaboration with
contractors and other partners.
•The social domain sub-system aims to provide
social support to society. This sub-system
works with very privacy-sensitive information
and has to do with national legislation on
social support, youth care and the
participation of citizens and companies. Chain
partners such as the UWV, care oces and
the Social Insurance Bank play an essential
role.
•The client interaction sub-system focuses on
direct interaction with citizens and
organisations through various channels.
Customer experience is what matters here.
•The data sub-system aims to ensure that
everyone within and outside the municipality
has access to the data they need and are
entitled to. This sub-system is spread
throughout the organisation taking care of
data quality, data collection, data distribution,
data privacy and all other aspects related to
safe data use.
•The operational management sub-system is
concerned with supporting the internal
organisation in areas such as nancial
administration, P&O and IT. This is mostly
about reliability and eciency.
Sub-systems of a municipality need not coincide
with organisational units or business functions.
2) Prescribing sub-system guiding
Guiding changes with a situational way of working is done
by a multi-disciplinary team with a helicopter point of
view, and an oversight on the broader connections within
the organisation sub-system, to the other sub-systems
and to the outside of the organisation. In our view this is
not a management responsibility a priori given to
managers, as they are responsible for managing the
current operations, the running part of the business.
Guiding is a dierent responsibility, the changing part of
the organisation. It is not impossible for a manager to
have both responsibilities; however, the distinctive nature
of the responsibilities may also create the need for
dierent personalities and leadership styles.
In this whitepaper we use the term Guiders for the
people that execute the guiding responsibility.
The Guiders advise on which working regimes to apply to
which sub-system. The dierent working regimes that can
be distinguished are discussed at the next level, the
situational level.
Architects assisting the Guiders are typically enterprise
architects. The architects advise on goals, scope,
organisation, and boundaries. They advise the guiders on
how to situationally govern their changes and how to
manage ad hoc change requests. The enterprise
architecture prescriptions are to be translated into a
functional language, relating the proposed roadmaps to
purpose and meaning (from an ontological to a
teleological language model).
Architects assisting the Guiders work in an overviewing
role. These architects’ mindset is: “Together, ensure
business value” and “Discovering principles”.
B. Enterprise Architecturing (EA)
The next step after sensemaking, recognising and
identifying the various sub-systems within the
organisation, is to develop and evolve the enterprise
architecture description. It must slowly become a
prescriptive tool that shows what the dierent
sub-systems are, what their components are, their
interdependencies, what architecture principles guide
their evolution etc.
Enterprise Architecturing is developing and evolving an
enterprise architecture and using it to support
enterprise-wide organisational decision-making. In our rst
level this means to prescribe for each sub-system what its
governance regime should look like and what architecture
principles are dominant in guiding that specic
sub-system. Referring back to the Adaptive Cycle of
Resilience (ACoR on page 7), what is their current state
and their ambition?
As argued for by Proper and Lankhorst (2014, par 3.4) the
enterprise architecture should prescribe and enable a
balance between the two aspects of an organisation: the
operational capability and the transformational capability.
The enterprise architecture should prescribe what
architecture method fragments will be used to develop,
maintain and apply the architectures for each sub-system.
Hence, this interpretation of enterprise architecture
includes a form of architecture management.
We discuss these activities in more detail in the next
three sections.
1) Prescribing what a sub-system is and what change
is needed.
Architects work with product or epic owners, programme
and project leaders of a sub-system. Advising and
explaining to them the chosen working regime they are
in, their preferred way of working, their mindset and their
deliverables.
The resulting architectures at this level are characterised
as limiting design freedom, not an overall enterprise
design. Enterprise architectures should be about
explaining and constraining, not constructing. “[Enterprise
transformations red.] as primarily being an intervention in
the natural evolution of the enterprise, resulting in a
10 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
changed course of its evolution towards a presumably
more desirable direction.” (Proper and Lankhorst,2014,
par 3.3).
In this context, proposing changes is certainly not
exclusive to the architects and their long-term roadmaps.
Any ad hoc suggested changes are to be analysed, put in
context and given appropriate articulation and
consideration. These requests are a valuable source of
demand. It’s these bottom-up changes that may prove
even more valuable. Architects work with (sub-system)
business leaders (and their Guiders) to support decision
making about a portfolio of proposed changes and
provide insights about opportunities, risks, portfolio
cohesion, and provide a long-term vision to ensure the
delivery of business value to the sub-system. They create
high level architectures, continuously delivering and
maintaining roadmaps and future-state architectures.
2) Prescribing an architecture method by combining
method fragments
In his blog, Chris Lockhart discusses the endless
debate about what framework is better or why
we need a new framework that supplants all
others. He pleads for the application of what he
calls frankenframeworks. “We need to do more of
more value and do it more quickly. I submit one
way to achieve that is to put aside the endless
soul-searching over frameworks. Pick one. Pick
ten. Pick two and smoosh them together. Keep
them and reuse them. But above all, use what
works for the problem you have regardless of
what the experts say.” (Lockhart, 2012)
Thinking in terms of sub-systems enables us to apply
architectural approaches that better t the situation. This
implies that we dene more than one architectural
approach and that these dierent approaches are applied
simultaneously, but in dierent sub-systems. To make this
a feasible way of working, we turn to the discipline of
situational method engineering (Brinkkemper,1996).
Brinkkemper (1996) introduces method engineering as a
research framework for information systems development
methods and denes method engineering as: “method
engineering is the engineering discipline to design,
construct and adapt methods, techniques and tools for
the development of information systems”. A method is
dened by Brinkkemper as “an approach to perform a
systems development project, based on a specic way of
thinking, consisting of directions and rules, structured in a
systematic way in development activities with
corresponding development products” (Brinkkemper,
1996, p.275-276). Though meant for information systems
development, we believe that method engineering can
also be applied to methods of working under architecture.
A special form of method engineering is situational
method engineering. Situational method engineering is
about tailoring a method to a specic situation, based on
reusable method fragments. These reusable method
fragments are stored in a so-called method base, a
repository of method fragments.
If we translate situational method engineering to
architecturing, we are talking about architecture method
fragments that can be used to assemble an architectural
approach suited to a specic context, or sub-system. An
architecture method fragment is a part of working under
architecture that can be regarded as a building block that,
together with other building blocks, shapes working
under architecture. In his publication Bengsch et al.
(2019) broadly classies architecture method fragments
into governance (for instance architecture board,
governing by principles, governing by rules), method (for
instance PSA workshops, RCDA4, backlog prioritization),
process (for instance PSA approval process, advisory
process), reference model (for instance SOLL application
landscape, architecture principles) or tool (for instance
repository, ArchiMate, causal loops). In each of these
classes dierent choices will be made depending on the
nature of the sub-system concerned.
4https://www.cginederland.nl/nl/artikelen/rcda-risk- and-cost-dr
iven-architecture
DYA – situational architecting – version 1.1 – February 28, 2022 11
III. Level 2 - Situational
On the second level we are changing situationally. The
two perspectives we label as
•Sub-system Guiding (subjective)
•Sub-system Architecturing (objective)
Figure 7: Level 2 - Sub-system Guiding and Sub-system
Architecture
A. Sub-system Guiding (SG)
Sub-system guiding is executed by the Guiders. Although
the guiders guide within the context of one sub-system,
they are very much aware of the interdependencies of
their sub-system with other sub-systems. This is described
by customised views on the enterprise architecture,
focussing on purpose and meaning of the sub-system.
Not all change activities that are guided, are necessarily
executed in the form of a project or programme. It can
also be a continuously working department or a
temporary committee. What unites them is a goal to
change something. However, we do associate project
style names with the working regimes, especially because
there seems to be so much confusion about the
terminology when it comes to describing a project style.
1) Decoding and articulating change initiatives
Within a sub-system there will be multiple concurrent
changes in various stages of development. Initially a
change request is probably a bit vague. There is some
need, some idea, maybe the goals of the proposed
change are known, often not. These initiatives can be
made by anybody within the enterprise, including the
Guiders running multiple-year roadmaps. By allowing
anybody to suggest an improvement, the enterprise
makes use of the large variety and creativity of all
stakeholders.
It is up to the Guiders to articulate this change initiative
and develop its description in such a way that there can
be a rational decision to allocate resources and start
changing. This process involves many of the roles in the
organisation, such as business analysts, demand
managers, product owners, account managers etc.
To choose an appropriate way of working two aspects of
the circumstances of the change request are investigated:
the amount of certainty of the context of the change
request and the amount of certainty of the proposed
solution or product. The sub-system governance provides
guidance for answering the rst dimension. The second
dimension is to be found in the change initiative, the
change request or project brieng.
Figure 8: Identifying four types of circumstances, based on
certainty and uncertainty of context and solution (Nouwens
and Opperman,2017)
The following questions are to be answered:
1) The amount of certainty or uncertainty about the
context of the change request.
•With what degree of certainty do we know what is
requested or expected?
•With what degree of certainty do the stakeholders
truly know their needs and functional
requirements?
•With what degree of certainty do we know how
the proposed solution will t in the current
situation of the organisation? Does it t in the
current business processes?
2) The amount of certainty or uncertainty about the
proposed solution or product.
•With what degree of certainty do we know the
solution? Is it an existing ready-made, maybe
commercially available and supported product?
•With what degree of certainty are we able to
support and maintain the solution?
•With what degree of certainty do we know the
requested is a product? Are there clear
requirements, is there a complete solution design?
Are we ready to start building? Or are we ready to
send out an RFI and nd a supplier?
The combination of these two aspects leads to four
classications of the circumstances of a change request.
These four classications give guidance to determine a
way of governing the proposed innovation or change. See
Figure 8.
12 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
It is tempting to combine the 2x2 circumstances
matrix with the Cynen model and there are
denitely some relations. Quadrant IV is the
simplest (obvious), best-practices can be applied.
Quadrant II and III can be complicated, sometimes
there are some good practices. Our working
regime approach of quadrant I (act-sense), even
resembles the approach of cynen (act-sens-
respond). However, the primary cause of the
dierentiation of the matrix is dierent. We
investigate (un)certainty, the Cynen model
investigates complexity. Secondly, our goal is
identifying a working regime of a change initiat-
ive, the Cynen model helps to make sense of
people’s behaviour (Snowden and Boone, 2007).
Recognising circumstance I: Change context uncertain, pro-
posed solution uncertain.
It’s not clear what we need or want, there is uncertainty
about the change request, the problem we want to solve.
How will the solution t in the current organisation and
processes, what value will it deliver? We don’t know.
The solution itself is also unknown. We have no readily
available product.
The Guiders goal should be to get at least more clarity
about one of these two uncertain factors, the solution or
the change context.
The Guiders approach should be experimental. Take a
best guess with an existing product or develop a mock-up
or quick-and-dirty solution. Try it and learn how your
stakeholders are able to solve their problems or can
support their business processes.
The label given to the working regime related to this
circumstance is: Pioneers.
Recognising circumstance II: Change context uncertain, pro-
posed solution certain.
In this situation it is (more) clear what solution we need.
Maybe even a product or supplier is known. What is
uncertain is how the product will t in our organisation,
how it will prove its value supporting the processes of our
organisation. Do we need to change our processes? Do
we need dierent people with dierent competences?
The Guiders goal is to seek feedback on the way the
product; the solution is embedded in our processes and
organisation.
The Guiders approach should be incremental, start small
and grow.
The label given to the working regime related to this
circumstance is: Settlers.
Recognising circumstance III: Change context certain, pro-
posed solution uncertain.
In this situation we know more about what we need,
there is certainty about the context. The business context
where the business solution is supposed to deliver its
value is (mostly) known and described. The requirements
of the unknown solutions are (mostly) clear. But the
solution itself is unknown or unavailable.
The Guiders goal is to create or to procure a product.
The Guiders approach should be executing a sourcing
strategy. Is there a ready-made product or service
available? Is the supported business process essential,
maybe unique and distinctive for our organisation? The
sourcing strategy has multiple outcomes: to buy or to
build.
The label given to the working regime related to this
circumstance is: Town builders.
Recognising circumstance IV: Change context certain, pro-
posed solution certain.
In this situation we know what we need and want, and
we know how it ts in our organisation. The requirements
and processes are known. We know what the desired
results are and what value it will result in. The solution or
services are known. Maybe there is an existing supplier
available.
The Guiders goal is to deliver business value as soon as
possible. To deliver a solution eciently.
The Guiders approach should be a predictable, stable
delivery or maintenance process. Within budget, within
time. Predictable, auditable, ecient results.
The label given to the working regime related to this
circumstance is: Town runners.
These four classications give the basis to identify and
dierentiate four change working regimes that we will
describe in the next section.
2) Guiding four dierent working regimes for the iden-
tied circumstances
As described in the previous section, we identify four
working regimes: Pioneers, Settlers, Town builders and
Town runners. For each of these we will explain how they
are related to the four circumstances, what their typical
scope and velocity ought to be, how the level of
governance ought to be (strict or loose), some remarks
about variety, something about the types of workers and
nally our label for a project-style.
Guiding a Pioneers working regime
The Pioneers working regime is related to
Circumstance I: Change context uncertain, proposed
solution uncertain.
The aim of this regime is innovating and experimentation,
nding both a solution and the intended change. This can
be the processes, the IT means, organisation, governance
etcetera. Starting top-down from the sub-system strategic
goals or bottom up, research and test innovative ideas.
The scope should be limited and the velocity should be
high. There is a need for getting an indication about the
feasibility of ideas as soon as possible. Fail fast, fail cheap,
DYA – situational architecting – version 1.1 – February 28, 2022 13
fail often and learn!
The level of governance is low. Variety should be high,
creativity stimulated. From an architecture point of view
there are very little to no requirements. If there are any
requirements at all they should be there to facilitate
innovation. Possibly existing frameworks or platforms are
used, but only if they facilitate speed or increase the
chance of success, not to restrict the solution and guide it
to a solution that can be maintained by the current IT
department.
The execution is done by a small multi-disciplinary (ad
hoc) team.
When we speak of a project style, we call it a
“proof-of-concept project”.
Guiding a Settlers working regime
The Settlers working regime is related to
Circumstance II: Change context uncertain, proposed
solution certain.
The aim of this regime is determining if and how an
existing solution or product can be implemented into our
sub-system.
The scope should initially be small, but it will grow.
Looking at the business function model there is no
obvious relation, it can be applied to any of the layers,
primary to tertiary.
The velocity is based on the absorption power of the
people in the organisation.
The lead time depends on the size of the organisation,
ranging from weeks until several months.
The level of governance is higher than average,
focussing on controlling risk when the impact of the
implementation increases. Variety should increase in time.
As the impact grows, variety will follow, stressing and
preparing the solution for a full implementation. The
architects help guide the step-by-step implementation:
infrastructure and application changes are strictly
managed; process changes are iterative and explorative.
The execution is done by a multi-disciplinary team,
dominantly consisting of business roles such as
product-owners, functional managers and key-users. When
we speak of a project style, we call it a “pilot project”.
Guiding a Town builder work regime
The Town builder work regime is related to
Circumstance III: Change context certain, proposed
solution uncertain.
The aim of this regime is the development or
procurement (sourcing) of an unknown solution.
Previously tested ideas will be converted to a reliable
solution, a product or service that can be implemented.
Looking at the business function model we nd
inspiration on the layers for our sourcing strategy.
Solutions directly related to primary business functions
can be, after careful deliberation, developed internally. A
secondary business function is an indication for a
sector-generic solution. Tertiary business functions are
highly generic, for them one should only look for
standard products or services. Nowadays typically cloud or
SaaS based.
The lead time is strongly dependant on the chosen
sourcing strategy. A simple procurement process can be
quick. But when a European public procurement
procedure is required, the minimum will be 6 – 9 months.
Developing (designing and programming) a solution takes
time, several months at least, but multiple years is no
exception.
The governance is relatively strict. Variety will start high
and be dampened more and more as product options
converge. Guidelines given will be focused on creating or
procuring a solution in an existing business context.
Describing requirements will be one of the deliverables,
especially regarding process and information integration.
The execution will be done by a multi-disciplinary team
consisting of several roles such as architects, product
specialist, designers and developers, functional and
technical managers, contract and procurement managers.
When we speak of a project style, we call it a
“procurement project” or “development project”.
Guiding a Town runner working regime
The Town runner working regime is related to
Circumstance IV: Change context certain, proposed
solution certain.
The aim of this regime is to implement, operate,
maintain and optimise a known combination of the
business context and solution. These maintenance
activities are predominantly executed by a line
organisation. Typically, this is predictable, managed,
budgeted work that can be part of a multi-year roadmap,
part of the operational strategy of a department.
Looking at the business function model we will typically
nd the solutions in the secondary and tertiary layers.
The lead-time is long and activities have a continuous
character. Within this working regime there is a stream of
small changes and xes that will be handled in incident,
problem and change (IPC) processes. Therefore, the
amount of work can highly vary.
The way of working is strictly managed according to
strongly governed maintenance and change procedures
within formal architectural constraints. The focus is on
predictable and ecient results. Making errors leads to
disruptions of continuity, down time and loss of business
value. Integrations into the business ecosystem are to be
optimised, taking into account the complete chain of
business processes, including from (external) partners
outside the business scope. Variety can be seen as a
mitigatable risk.
The execution is done by a maintenance department,
part of the line organisation.
Especially in this working regime the activities are mostly
not organised within projects. However, when change
requests grow, the number of stakeholders and impact
14 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
increases, a classical project way of working is still
advised. There is no need for an agile approach as up
front it is known what is required and to be delivered.
When we speak of a project style, we call it a
“maintenance, replacement or optimisation project”.
3) Guiding a portfolio of concurrent working regimes
Presumably there are many concurrent changes
happening in your organisation sub-system. Thus, there
are multiple, concurrent change activities based on any of
the four working regimes.
Figure 9: Guiding regimes (Nouwens and Opperman,2017)
Just like the structured project management method
Prince-II, the “managing a stage boundary” process is a
point in time in which steering committees are highly
involved. In our way of working, the Guiders are supposed
to be very alert when change teams nish their work.
Figure 9illustrates the Guiders (the team executing the
change governance) steering a change initiative, changing
the way of working to the four working regimes. Each
time a change, working in one of the regimes, steps out
its cycle, it reports back to the Guiders.
We have seen in some organisations that the composition
of a project team, including the steering committee,
remained the same while the goal of the project stage
completely changed. In our vision, for instance the change
from a project with a procurement goal to a project with
an implementation goal, needs a dierent way of working
and dierent specialist and managing roles. In our terms
a completely dierent working regime.
It is tempting to see the working regimes as part of a
production chain from testing an idea, developing,
piloting and maintaining. However, this is not intended as
such. Working regimes can be recommended in any order.
The Guiders evaluate and help to advise on the
appropriate way of working for the next phase.
And remember, stopping after a working regime has
delivered its results, is always a real option.
B. Sub-system Architecturing (SA)
Architects create an architecture for a sub-system, they
prescribe what to do for that particular sub-system. The
traditional way to do this is to create and communicate
some models, and to create and get commitment for a
set of architecture principles that help to support future
decision-making. In this context this is not so dierent,
except for the situational adaptation to the purpose and
goals of the sub-system (e.g. level of architectural detail,
choice of representation formats (viewpoints),
implementation of architectural processes).
1) Dening sub-system architectures
Architects work with the sub-systems Guiders and change
management (epic owners, programme or project
leaders). Advising and explaining what it is and what it
does. What they are changing and how the proposed
changes contribute to the purpose of the sub-system,
contributing value to the overall enterprise. What to
change is based on an impact analysis by experts. Based
on current-state and future-state models. The deliverables
of a change are based on the delta between the two
models.
As usual, several viewpoints will be prescribing the views
that are presented to the stakeholders. For some
stakeholders, an advisable way of recording and
communicating these models is based on the Archimate
standard. Others will prefer to see the architecture
models translated to a less precise format such as in a
Powerpoint presentation. In this level 2, the regular rules
of the road for architects will be applicable.
The architecture principles will be much more suited to
the particular sub-system and needed change, as they
translate part of the purpose and apply it in context. The
level of governance (strict or loose) given by the Guiders
will also be reected in the style and tone of voice in the
principles. They can be anything between specic rules
prescribing how to do things and strategic principles
setting an eect to be achieved rather than the way how
to achieve it (Eusterbrock and van Steenbergen,2016).
2) Prescribing an architecture method by combining
method fragments
When architects support a particular working regime, they
should work structured. To be relevant and eective, they
should adapt their way of working in the context of the
working regime.
Prescribing way of working for architects supporting a
Pioneers working regime
This Pioneers working regime is related to
Circumstance I: Change context uncertain, proposed
solution uncertain. For architects supporting the project
style “proof-of-concept project”.
Architects work in a creative role. Their mindset is:
“Together, looking for business value” and “Discovering
principles”. They work cooperatively and provide existing
architecture products to support and inspire innovation.
No clear boundaries and rules are given, out-of-the-box
solutions are needed. When nalising this working
DYA – situational architecting – version 1.1 – February 28, 2022 15
regime, the architect can apply any new insights to the
architecture baseline of the sub-system. Existing
future-state architectures and roadmaps may be realigned
after well-informed decision making.
Relevant architecture method fragments are patterns,
architecture principles, the bridge, scenarios, value
sketches, causal loop diagrams.
Prescribing way of working for architects supporting a
Settlers working regime
This working regime is related to Circumstance II:
Change context uncertain, proposed solution certain. For
architects supporting the project style “pilot project”.
Architects work in a developing and evaluating role.
Their mindset is: “Realise and evaluate business value”
and “Applying principles”. They work to integrate an
existing product into a business context with a goal to
deliver improved or new services. Their focus is on the
environment, not the product itself.
Existing boundaries and rules are applied, the business
environment (services, processes and information) will be
guided to adapt to the new product. When nalising this
working regime, the architect will have to apply the new
situation to the current state architecture description.
Relevant architecture method fragments are
architecture principles, advising projects, domain models,
stakeholder concerns.
Prescribing way of working for architects supporting a Town
builder work regime
This working regime Town builder is related to
Circumstance III: Change context certain, proposed
solution uncertain. For architects supporting the project
style “procurement project” or “development project”.
Architects work in a creating and support role. Their
mindset is: “Realise products to deliver business value”
and “Dene principles and rules”. They work as specialists
and deliver input about the circumstances (current state
architecture) and the requirements that describe the
product that will be sourced or built. The architect
supports major decision making by delivering a Project
Start Architecture (PSA) or Sourcing Start Architecture
(SSA), a variant of the PSA in the context of a sourcing
project (Nouwens,2015), and will apply sourcing
strategies, advise on sourcing and the product
boundaries. Special attention is needed to prevent
overlap with other developments or current products and
services. The circumstances are known, as are the goals of
the future product.
There are two variations:
1) In the case of building, architects can be specialists in
supporting software development, probably in an
agile context. Working together with product owner
to develop the product back log and prioritise the
user stories for the upcoming sprints. Frameworks
like SAFe5and methods like RCDA6can be applied.
2) In the case of sourcing, architects can be specialists
in procurement procedures, especially when EU
procurement laws are to be applied. They will be able
to advise on what EU procurement procedure (open,
restricted, competitive dialogue, negotiated
procedure) to follow, based on the amount of
needed (design-)interaction during the procurement
procedure (Nouwens,2015).
Existing goal-architectures or roadmaps are not
modied, they are partly realised by the results of
this working regime.
Relevant architecture method fragments are
architectural principles, architectural rules, current state
architecture, reference architecture, project start
architecture, sourcing start architecture, RCDA, SAFe,
stakeholder viewpoints.
Prescribing way of working for architects supporting a Town
runner working regime
This working regime Town runner is related to
Circumstance IV: Change context certain, proposed
solution certain. For architects supporting the project
style “maintenance, replacement or optimisation project”.
Architects work in a controlling and improvement role.
Their mindset is: “Ensure business value, continuity and
compliance” and “Enforce principles and rules”. They work
as a steward to prevent unintended or too risky changes
to the current-state architecture. Strict boundaries and
rules are applied. Their focus is on optimisation of the
current business services while ensuring and maintaining
compliance. The architect knows about the current state
of things and can provide impact analyses of suggested
changes. Existing current-state architectures will be
unchanged.
Relevant architecture method fragments are
architecture rules, approve change request, review
change against architecture, current state architecture.
5https://www.scaledagileframework.com
6https://www.cginederland.nl/nl/artikelen/rcda-risk- and-cost-dr
iven-architecture
16 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
IV. Level 3 - Structured
On the third level we are working in a structured manner.
As described in the previous chapter we propose four
situational working regimes: Pioneers, Settlers, Town
builders and Town runners.
The two perspectives we label as
•Change Designing (subjective)
•Change Architecturing (objective)
Figure 10: Level 3 - Change Designing and Change
Architecturing
Level 3 is not elaborated further. As the context and
environment is, in Cynen terms, clear, we can allow
ourselves to work in a structured manner. It’s make or
buy; taking the guidance from project management styles
we design the change, guiding it with a change
architecture. Or we support the procurement of a system
that implements the required change.
To relate to the changing of the operation, an extension
of a fourth level is added. At this level the change team
(project or some other way of organising the change)
designs and delivers or procures the solution within the
constraints of the change architecture. The change
deliverables such as working instructions, training
etcetera, are handed over to the operational
management.
On the fourth level we are realising and implementing.
The two perspectives we label as
•Solution Designing (make) or Procuring (buy)
(subjective)
•Solution Implementing (objective)
Figure 11: Level 4 - Solution Designing or Procuring and
Solution Implementing
The change is implemented. Finally, the organisation will
start to see the value of the change. For the
best-practices we refer to the plethora of management
books, project management training and general
education on management.
V. Summary
We strive to make the complex manageable by separating
levels of governance and architecture which allows us to
better separate the complex from the complicated and
simple. By doing so we are able to restrict the complex to
the top level, the sensemaking level.
1) On the rst level we are making sense.
What purpose has this organisation and what
sub-systems are there?
From the rst level we initiate multiple concurrent
second levels.
2) On the second level we change situational.
What purpose has this sub-system and what changes
are needed?
From the second level we initiate multiple concurrent
third levels.
3) On the third level we change structured
What goals are there for this change, and what
solutions are to be delivered?
From the third level we initiate multiple concurrent
building and implementations activities.
and we deliver structured
Design or procure a solution, implement the changes.
Manage and operate.
All of this will be done concurrently. There will be many
governance scenarios and changes being designed, many
architectures being derived, many situational styles of
working being applied etc. In several sub-systems. All at
the same time.
DYA – situational architecting – version 1.1 – February 28, 2022 17
VI. Discussion
But... are sensemaking architecturing and situational
architectures dierent from the existing way of working?
How do they compare to “regular” enterprise architecture
and domain architectures?
First of all, sensemaking architecturing diers from
regular enterprise architecture in the way we look at the
context. Not discussed in this chapter, but in sensemaking
architecture we take into account much more aspects
such as the ethical and human-centric (van Steenbergen
et al.,2019,2020). We see an enterprise as a complex
adaptive system, designed, managed, and executed by
human actors. Complex humans, and not cogs and wheels
like in a mechanical clockwork. A proven plan and dened
path do not exist. The path will be created by every step.
In this whitepaper this wide view is reected in the way
we approach the level of sensemaking and the work
regimes, based on a multidisciplinary way of working by
people.
Secondly, a sub-system of an enterprise is identied with
several perspectives, a holistic approach recognising the
limited ability to analyse a complex adaptive system.
Multiple sub-systems potentially overlapping. A domain
architecture is often dened a priori. Sometimes it is seen
as an architecture for a business domain such as HR or
sales. Sometimes it is seen as a geographical related
subset of the organisation. Most of all, it is often
dangerously reductionistic! We recognize that
architectural approaches do not always coincide with
business domain boundaries.
Thirdly, when applying TOGAF7in a recursive way, as
described in their own method, it is still the Architecture
Development Method (ADM) that is used when creating
both the higher-level architecture and the lower
recursions. And it does so in a very procedural, almost
mechanistic way. A situational architecture regime can
have method fragments that are specically adapted to
the context, the current situation.
Situational Architecture products work together as
systems. Interdependent, inuencing each other,
inuencing and inuenced by architectures outside of the
current scope of interest.
Lastly, the concurrency of the dierent levels is hard to
visualise. Remember: each level instantiates multiple and
concurrent activities on next levels. Each instance is
temporary.
7https://www.opengroup.org/togaf
VII. Conclusion
To make sense of what is happening, sensemaking, is an
essential contribution of enterprise architecture.
Architectural views, for instance, have been used to
enable decision-makers to make sense of new
developments in the context of their organisation. They
help them envision possible impacts of various choices
and see the connection between these choices.
Architecture has been doing this for decades. However,
current times ask for new ways of doing so. We must up
our game.
We can start with realising that our organisations are no
longer really their own boss but are part of an ecosystem
with many interdependencies between network
organisations. This increases a new level of
unpredictability and complexity that requires a situational
approach to architecture. We can deal with this
complexity by thinking in terms of sub-systems,
architectural method fragments and working regimes.
Sub-system thinking enables us to turn a complex context
into a complicated context. And architects know how to
deal with complicated contexts. It enables us to choose
the right approach for the right situation working down
to the right working regime for the right change context.
Adding the level of sensemaking to our repertoire keeps
us relevant.
Let’s up our game.
18 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
VIII. Theoretical background and inspira-
tion
For the curious reader we provide the theoretical
backgrounds that we used. These backgrounds are from
the elds of psychology, chaos theory, sensemaking,
situational awareness, systems theory.
Enterprises, systems, and sub-systems
We use the label enterprise as an overall term to identify
a company, organisation, business or a governmental
institution. Social entities of human endeavour, organised
complexities, non-deterministic, with a certain purpose
(Hoogervorst,2017, chapter 2).
“Modern science is characterized by its ever-increasing
specialization, necessitated by the enormous amount of
data, the complexity of techniques and of theoretical
structures within every eld.” Is the rst sentence of the
chapter about General Systems Theory by Ludwig von
Bertalany. This timeless introduction is written in 1968
and is the basis for a dominant way of conceptualising
our world.
Common denitions based on General Systems Theory
are:
•Asystem is a set of interdependent resources of
people, information, and/or technology that must
interact with each other and their environment in
support of a common purpose.
•An environment is the context within which a system
exists. It includes everything that may aect a system
and may be aected by a system at any given time.
•Systems are composed of sub-systems and any
system is embedded in a larger system. Sub-systems
of a system interact in order to attain their own
purposes and the purposes of the system in which
they are embedded.
•POSIWID, A term by Staord Beer referring to The
Purpose Of a System Is What It Does8. What binds the
components of the system is its common purpose.
Based on these denitions, the terms system and
sub-system are interchangeable.
Sensemaking and situational awareness
Our rst inspiration is taken from the eld of psychology.
In 2006, the psychologist Gary Klein9describes the
concept of sensemaking from several perspectives. From
a psychology perspective, sensemaking is a “motivated,
continuous eort to understand connections (which can
be among people, places, and events) in order to
anticipate their trajectories and act eectively.” (Klein
et al.,2006;Klein et al.,2006). From a naturalistic
decision-making perspective10, Klein elaborates
sense-making through several functions such as looking
backwards trying to anticipate the future, to anticipate
future diculties, and to notice problems and realise
concerns. He also argues that sensemaking is a social
8https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does
9https://en.wikipedia.org/wiki/Gary_A._Klein
10https://en.wikipedia.org/wiki/Naturalistic_decision- making
activity. Interestingly, Klein relates (g 12) sensemaking to
situational assessment and situational awareness.
Figure 12: A table attributed to Klein, found on wikipedia.
Our second inspiration refers to cognition and Situational
Awareness. Mica R. Endsley is an industrial design
engineer and a former Chief Scientist of the US Air
Force11. In her paper “Theoretical underpinnings of
situational awareness: A critical review” (Endsley,2000),
she shares her theoretical foundations and several models
on cognitive processes. According to Endsley (1988), the
formal denition of Situational Awareness is “the
perception of the elements in the environment within a
volume of time and space, the comprehension of their
meaning, and the projection of their status in the near
future”. Endsley (2016) describes three separate levels of
situational awareness:
•Situational Awareness level 1: perception of the
elements in the environment — includes two steps.
The rst is sensing, the receiving of physical
stimulation by the sensory receptors (sight, sound,
smell, taste, touch). The second is perception, being
the interpretation of this sensory data. Without a
basic mental model, the person is not able to
perceive the signals.
•Situational Awareness level 2: comprehension of
the current situation — takes the multiple sources
of information (interpreted sensory data). The
information is sorted, given a priority and a value and
then remembered. Finally, it is integrated with the
context. A highly developed mental model (domain
knowledge) plus an explicit goal is required to reach
level 2.
•Situational Awareness level 3: projection of
future status — takes more than just skills. Without
a goal a person is not able to holistically and
correctly comprehend the current situation and is not
able to project future status, and subsequently
decide on any interventions.
Endsley writes “Situation awareness drives decision making
and performance” (Endsley,2016), creating a nuance that
a good awareness, even a good decision, will drive, but
not guarantee, good performance. During execution
things can still go wrong.
The third inspiration we use is based on the works of
Dave Snowden12, the Welsh consultant and researcher in
the eld of complexity science. In 2005 he writes a plea
for a new simplicity in decision making, by a
“Multi-ontology sense making”. In this paper Snowden
describes, based on his extensive experience and case
studies, a Social Complexity domain that has ve distinct
categories of complexity. Referring back to Gary Klein’s
naturalistic decision theory, “decisions are a rst-t
11https://en.wikipedia.org/wiki/Mica_Endsley
12https://en.wikipedia.org/wiki/Dave_Snowden
DYA – situational architecting – version 1.1 – February 28, 2022 19
Figure 13: The phenomenological Cynen framework . How
people perceive and make sense of their environment in
order to make decisions. (Snowden, 2011 via Wikimedia
Commons)
pattern-matching with past experience or extrapolated
possible experience”, Snowden explains and coins the term
“Contextual Complexity”. He argues that humans have the
ability to operate in all quadrants of the model,
concluding that “Multi-ontology sense making then
reects the need to adopt dierent diagnostic
techniques, dierent intervention devices and dierent
forms of measurement depending on the ontological
state. This is contrasted with any single-ontology form of
sense making whether based on order, complexity or
chaos.” (Snowden,2005).
Recent research exploring a conceptual model about
organisational purpose, our fourth inspiration, denes
organisational purpose as “an organization’s reason for
being characterized by signicance, aspiration, direction,
unication, and motivation.” (van Ingen et al.,2021). They
elaborate their denition with:
•Signicance – the degree to which the organization
has a substantial positive contribution to or impact
on the lives or work of people, whether within the
organization or in the external environment outside
the organization, such as local or global society.
•Aspiration – the hope or ambition of achieving the
fulllment of human needs in the future (i.e.,
signicance), strongly desired yet dicult or maybe
impossible to achieve, that one must continually
strive for.
•Direction – the path or course to fullling the
signicant and aspirational aspects of purpose,
thereby guiding decision-making, promoting goal
orientation, and providing order and coherence of
actions.
•Unication – the connecting or binding of people to
the organization and its purpose, through shared
understanding of the signicant, aspirational, and
directional aspects of purpose, thereby fostering
belongingness, relatedness, and connectedness at the
emotional level, and collaboration (inside the
organization) and cooperation (outside the
organization).
•Motivation – the energization of voluntary activities
or behaviors either done for their inherent interest
(i.e., need fulllment) or done for the reason of
fullling the organization’s signicant, aspirational,
directional and unication aspects of purpose (van
Ingen et al.,2021).
Finally, more from a practitioner’s perspective, the Finnish
researcher Jarkko Nurmi13 describes a dualist approach in
his 2021 dissertation called “Enterprise Architecture in
Public Sector Ecosystems; A Systems Perspective” (Nurmi,
2021). He argues that we need two dierent approaches:
infrastructure or systems architectures (complicated) can
be fully modelled using structural decomposition
techniques. Business architectures (complex) are always
modelled incompletely and should be modelled
functionally.
To summarise the interwoven inspirations:
•To be able to make sense from a situation is a highly
social activity, connecting to multiple stakeholders
and their concerns (Klein).
•One must be able to receive and perceive many
signals (Endsley, Klein). Make use of developed
mental models (Endsley), experience (Klein) and
understand connections (Klein) to create a situational
awareness.
•An advanced level of sensemaking that facilitates
decision making, needs interpreted, prioritised, and
remembered information, integrated in a context.
This requires a common goal and personal mastery of
the process (Endsley).
•Multiple forms of complexity require multiple
diagnostic techniques and approaches (Snowden,
Nurmi). An explicit goal being a precondition for the
ability to project a future status (Klein, Endsley) that
enables decision making (Klein).
We use these inspirations and theories from psychology,
industrial design, and the social complexity domain, for
further understanding and elaborating sensemaking
architecture.
In this paper we extended our vision with a way of
working that honours the challenges of a complex and
changing environment: situational architecting.
13https://www.researchgate.net/profile/Jarkko- Nurmi
20 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
References
Beer, S. (1972). Brain of the rm: the managerial
cybernetics of organization. Allen Lane the Penguin
Press, London.
ISBN: 978-0-7139-0219-8.
Bengsch, J., van Steenbergen, M., and Ravesteyn, P.
(2019). Fit for Purpose Enterprise Architecture.
Conference proceedings / 32nd Bled eConference
Humanizing Technology for a Sustainable Society.
https://doi.org/10.18690/978-961-286-280-0.13.
Botjes, E. A., Eusterbrock, T., Nouwens, H., and
Steenbergen, M. (2021). Design for chaos - a DYA white
paper by sogeti. Technical report, Sogeti Nederland.
https://labs.sogeti.com/wp-content/uploads/2021/11/D
esign-for-Chaos-a-DYA-white-paper-by-Sogeti- version-20
211008-v1.pdf.
Brinkkemper, S. (1996). Method engineering: engineering
of information systems development methods and
tools. Information and Software Technology,
38(4):275–280.
http://dx.doi.org/10.1016/0950-5849(95)01059-9.
Craven, L. (2021). #27: There is no elephant.
https:
//pigontracks.substack.com/p/27-there-is-no-elephant.
de Mik, T., Nouwens, H., and Opperman, A. (2019).
whitepaper - werken onder architectuur in een
multi-modal omgeving. SURF.
https://www.surf.nl/whitepaper-werken-onder-architec
tuur-in-een-multi-modal-omgeving.
Dietz, J. L., Hoogervorst, J. A., Albani, A., Aveiro, D.,
Babkin, E., Barjis, J., Caetano, A., Huysmans, P., Iijima, J.,
Kervel, S., Mulder, H., Op ’t Land, M., Proper, H., Sanz,
J., Terlouw, L., Tribolet, J., Verelst, J., and Winter, R.
(2013). The discipline of Enterprise Engineering.
International Journal of Organisational Design and
Engineering, 3:86–114.
https:
//www.alexandria.unisg.ch/224465/1/ATT67978.pdf.
Endsley, M. (2000). Theoretical underpinnings of situation
awareness: A critical review. Situation awareness
analysis and measurement, pages 3–32.
Endsley, M. R. (1988). Design and Evaluation for Situation
Awareness Enhancement. Proceedings of the Human
Factors Society Annual Meeting, 32(2):97–101.
https://doi.org/10.1177/154193128803200221.
Endsley, M. R. (2016). Designing for situation awareness:
an approach to user-centered design, second edition.
CRC Press (Verlag).
ISBN: 978-1-4200-6358-5.
Eusterbrock, T. and van Steenbergen, M. (2016). DYA -
Principle-based approach in Enterprise Architecture
practice; nding the sweet spot.
https://www.sogeti.nl/nieuws/transformational/publicat
ies/principle-based-architectuur-hoe-ver-wil-je-gaan-whi
tepaper.
Hoogervorst, J. A. (2017). Foundations of Enterprise
Governance and Enterprise Engineering - Presenting the
Employee-Centric Theory of organisation. Springer.
https://doi.org/10.1007/978-3-319-72107-1.
Hoogervorst, J. A. P. (2009). Enterprise governance and
enterprise engineering. Springer Berlin Heidelberg,
Berlin, Heidelberg.
https://doi.org/10.1007/978-3-540-92671-9.
Klein, Moon, and Homan (2006). Making sense of
sensemaking 2: a macrocognitive model. IEEE Intelligent
Systems, 21(5):88–92.
http://ieeexplore.ieee.org/document/1705435/.
Klein, G., Moon, B., and Homan, R. (2006). Making sense
of sensemaking 1: alternative perspectives. IEEE
Intelligent Systems, 21(4):70–73.
http://ieeexplore.ieee.org/document/1667957/.
Lockhart, C. (2012). Frankenframeworks.
http://www.chrisonea.com/frankenframeworks/.
Nouwens, H. (2015). Identifying and mitigating root
causes related to the strategic sourcing process within
the context of EU procurement guidelines using
concepts of Enterprise Governance and Enterprise
Engineering. Master’s thesis, Antwerp Management
School, Antwerpen.
https://doi.org/10.5281/zenodo.5213936.
Nouwens, H. and Opperman, A. (2017). whitepaper
multimodale governance aanpak met hora. SURF.
https://www.surf.nl/whitepaper-multimodale-governanc
e-aanpak-met-hora.
Nurmi, J. (2021). Enterprise architecture in public sector
ecosystems: A systems perspective. PhD thesis,
University of Jyväskylä.
http://urn.fi/URN:ISBN:978-951-39-8518-9.
Proper, H. A. and Lankhorst, M. M. (2014). Enterprise
Architecture – Towards essential sensemaking.
Enterprise Modelling and Information Systems
Architectures, 9(1):5–21.
https://www.springerprofessional.de/doi/10.1007/s407
86-014-0002-7.
Ross, J. W., Beath, C. M., and Mocker, M. (2019). Designed
for Digital: How to Architect Your Business for Sustained
Success. MIT Press.
ISBN: 0-262-04288-6.
Snowden, D. (2005). Multi-ontology sense making: a new
simplicity in decision making. Journal of Innovation in
Health Informatics, 13(1):45–53.
http://hijournal.bcs.org/index.php/jhi/article/view/578.
Snowden, D. and Boone, M. E. (2007). A Leader’s
Framework for Decision Making. Harvard Business
Review.
https://hbr.org/2007/11/a-leaders-framework-for-decisi
on-making.
Takács, E. and Abcouwer, T. (2020). Framework for
Adaptive Change: Towards Sustainable Innovation.
International Journal of Innovation in Management,
8(1):17.
https://hdl.handle.net/11245.1/0fe8953e-bf1d-490c-b6
43-122b130d92e8.
van den Berg, M., Slot, R., van Steenbergen, M., Faasse, P.,
and van Vliet, H. (2019). How enterprise architecture
improves the quality of IT investment decisions. Journal
of Systems and Software, 152:134–150.
https://linkinghub.elsevier.com/retrieve/pii/S01641212
19300433.
van Ingen, R., Peters, P., De Ruiter, M., and Robben, H.
(2021). Exploring the Meaning of Organizational
Purpose at a New Dawn: The Development of a
Conceptual Model Through Expert Interviews. Frontiers
in Psychology, 12:675543.
https://doi.org/10.3389/fpsyg.2021.675543.
van Steenbergen, M., Eusterbrock, T., and Bouman, J.
(2016a). AG 2016-05 De wereld is niet eenvormig of
bipolair.pdf. AG Connect, 2016-05:24–25.
van Steenbergen, M., Eusterbrock, T., and Bouman, J.
(2016b). AG-Connect 2016-11 Multidynamische
DYA – situational architecting – version 1.1 – February 28, 2022 21
Architectuur 2.pdf. AG Connect, 2016-11:63–67.
van Steenbergen, M., Eusterbrock, T., Nouwens, H., Botjes,
E. A., Atsma, L., and Draaisma, M. (2020). Value
sensitive architecture – a DYA Whitepaper by Sogeti.
Technical report, Sogeti Nederland.
https://labs.sogeti.com/wp-content/uploads/2020/09/Val
ue-sensitive-architecture-20200902-v2.pdf.
van Steenbergen, M., Eusterbrock, T., Nouwens, H., Botjes,
E. A., Scholtens, W., and Atsma, L. (2019). Architecture
in this new world we live in – a DYA Whitepaper by
Sogeti. Technical report, Sogeti Nederland.
https://labs.sogeti.com/wp-content/uploads/2019/12/A
rchitecture-in-this-new-world-we-live-in-a- DYA-white- p
aper-by-Sogeti-version-20191223-v2.pdf.
von Bertalany, L. (1968). General System Theory:
Foundations, Development, Applications. International
library of systems theory and philosophy. G. Braziller.
https://books.google.nl/books?id=mWZQAAAAMAAJ.
22 Sogeti Netherlands BV, Copyright CC BY-SA 4.0
About the Authors
Marlies van Steenbergen is an
experienced enterprise architect.
She works as an advisor and
coach in the eld of enterprise
architecture and has guided many
organisations from all industry
sectors in the development of an
eective enterprise architecture
practice. In 2017 she became
Professor Digital Smart Services at the university of
Applied Sciences Utrecht. Marlies is co-founder of DYA
(Dynamic Architecture), oering a pragmatic approach to
architecture based on best practices. Nowadays, Marlies
focuses on the link between architecture and innovation
and on Digital Ethics.
LinkedIn |Sogeti Prole
Hans Nouwens is an
experienced enterprise architect
with 20+ years of practical
experience in the eld of ICT,
infused with rigorous academic
learning. He works as an architect
and trusted advisor mainly
for Higher Education institutes.
Enterprise engineering, enterprise
architecture and enterprise governance are his specialities
that come with DEMO and CGEIT certications. Hans has
an academic interest in systems theory and cybernetics.
Hans volunteers as board member for the interest group
architecture of the KNVI and as board member of the
Dutch society of systems thinkers (SCIO-NL). He regularly
gives guest lectures on enterprise architecture and
coaches students teams.
LinkedIn |Sogeti Prole
Edzo A. Botjes is an experienced
all-round (IT) professional
and architect with 25+
years’ experience. He works as an
enterprise, program and solution
architect for companies from
all industry sectors. He does this
by combining various expertise’s
to identify and resolve root-cause
issues in the Enterprise Governance domain and in the
realisation domain of an organisation. Edzo is a creator
and loves sharing his passion via blogs, workshops and
presentations. His focus nowadays is on the evolution of
organisations into antifragile organisations and the role of
communication within the identity of organisations. He is
Antifragility Architect at Xebia Security.
LinkedIn
Anton Opperman is a business
information manager with
35+ years of practical experience
in private and public sector
organisations. Anton has had
his education in civil engineering,
business administration
and information management. He
advises and supports executives
and directors to make their organisations become more
adaptive to the impact of current changes, especially
digitalisation. Anton has been member of the
Architecture council Higher Education since 2013, based
on experience as a practitioner as program and enterprise
architect. Anton volunteers as board member for the
interest group Governance of the KNVI. He regularly gives
guest lectures and contributes to knowledge sharing and
professional team development. As a practitioner he has
always been inspired by academic insights and the
application of those for solving real world issues.
In this article Anton contributes in a personal capacity, as
a member of the working group Multi Modal Governance
of the architecture Council Higher Education. Anton is
working at the CIO Oce of Erasmus University
Rotterdam.
LinkedIn |Erasmus University Rotterdam
Ton Eusterbrock is an
experienced enterprise architect.
He works as an advisor and
coach in the eld of enterprise
architecture and has guided many
organisations from all industry
sectors in the development of an
eective enterprise architecture
practice. Ton is one of the
promoters of DYA (Dynamic Architecture), oering a
pragmatic approach to architecture based on best
practices. He is also a speaker on seminars and lectures at
universities and coaches students teams. Ton’s focus is in
architecture principles and how to organise architecture
governance in modern ways of working.
LinkedIn |Sogeti Prole
DYA – situational architecting – version 1.1 – February 28, 2022 23
About DYA, SogetiLabs and Sogeti
The goal of DYA is to improve
the eectiveness of architecture
within organisations. In
2001 Sogeti introduced Dynamic
Architecture (DYA). DYA was
the start of the focus shift from
blueprint architecture to just
enough, just in time architecture.
The main driver for this shift was
the awareness that architecture
must facilitate the required speed of change. We are now
on the threshold of a new focus shift: instead of focusing
on internal eciency and standardisation of technology,
architecture is to drive innovation by stimulating diversity
and focusing on the interplay of enablers with dierent
rhythms.
DYA (Dutch website)
Sogetilabs is a formal,
networked community bringing
together the distinguished
technology experts and the
promising talents throughout the Sogeti Group. The core
objective of this community is to inspire the members to
contribute innovative ideas, recognize the talented people
in the Sogeti Group & motivate them.
LinkedIn |SogetiLabs
Sogeti is a leading provider
of technology and engineering
services. Sogeti delivers solutions
that enable digital transformation
and oers cutting-edge expertise
in Cloud, Cybersecurity, Quality
Engineering & Testing, and emerging technologies. Sogeti
combines agility and speed of implementation with
strong technology supplier partnerships, world class
methodologies and its global delivery model, Rightshore
®. Sogeti brings together more than 25,000 professionals
in 15 countries, based in over 100 locations in Europe,
USA and India. Sogeti is a wholly-owned subsidiary of
Capgemini SE, listed on the Paris Stock Exchange.
English website |Sogeti (Dutch website)
Xebia explores and creates new
frontiers. Always one step ahead
of what businesses need, we turn
the latest technology trends into
advantages for our customers. As
a mainstream frontrunner, we create new solutions and
build the future with our clients. An international network
of passionate technologists and pioneering craftsmen,
Xebia provides the cutting-edge tools, training and
consulting services that make businesses work better,
smarter, and faster.
Xebia website
About
Sogeti
Part of the Capgemini Group, Sogeti operates in more than 100 locations
globally. Working closely with clients and partners to take full advantage
the opportunities of technology, Sogeti combines agility and speed of
implementation to tailor innovative future-focused solutions in Digital
Assurance and Testing, Cloud and Cybersecurity, all fueled by AI and
automation. With its hands-on ‘value in the making’ approach and passion
for technology, Sogeti helps organizations implement their digital journeys
at speed.
A global leader in consulting, technology services and digital transformation,
the Capgemini Group is at the forefront of innovation to address the
entire breadth of clients’ opportunities in the evolving world of cloud,
digital and platforms. Building on its strong 50-year heritage and deep
industry-specic expertise, Capgemini enables organizations to realize their
business ambitions through an array of services from strategy to operations.
Capgemini is driven by the conviction that the business value of technology
comes from and through people. It is a multicultural company of over 290,000
team members in more than 50 countries. The Group reported 2021 global
revenues of EUR 18 billion. People matter, results count.
Visit us at
www.sogeti.com
Sogeti Netherlands BV, Coyright CC BY-SA 4.0
