This paper is a request for comments on a research setup for discovering and validating a guide for sensemaking and situational architecturing to design and change enterprises. It includes my philosophical position on research, the initial research questions, a concept research methodology, and a first research artefact with some premature validations. The first research artefact is a conceptualisation and expressions of a new roadmap. An addition to the theoretical arrangement of Teleology - Afordance - Ontology, to guide the way on sensemaking, situational architecturing, designing, and changing of enterprises. Where existing theory depicts a linear relation subject - afordance/function - object, in practice the processes and usage of language of architecturing and designing are much more interwoven. By clarifying these, I strive to improve the quality of the enterprise design processes, positively contributing to enterprise cohesion. Using the design science research methodology, I argue the initial relevance and rigor, and propose a first artefact, a conceptualisation with several visualisations, and present initial evaluations.
As practising enterprise architects, we not only create architectures and support enterprises with their decision-making processes. We also support enterprises by improving their architecture practice, and train students and co-workers on the topic of architecture. In this rich context and mix of application and theory we experience ambiguous interpretations of the foundations that guide our architecture practice. I am convinced that we need more and better architects to guide enterprises, explicitly including the public institutions, in their digital transformation.
As a personal goal, I want to improve the architecture profession by contributing to the theory, translating the theory to educational content, and teaching architects. This paper is part of my first goal: setting up a research project to start contributing to the theory.
Part of this research is understanding the theoretical foundation of designing enterprises in a broad sense. Starting from the subjective perspective of sensemaking, using the objective perspective of enterprise architecturing and enterprise engineering to create one of the preconditions for a changing enterprise.
Part of this theoretical foundation is the distinction between function and
construction, as described by the Enterprise Engineering -theory by authors
such as Dietz, Mulder and Hoogervorst [
I want to improve the theoretical foundation of the way of thinking and the way of working by enterprise architects. Of course, this huge topic should be narrowed down to a set of manageable research questions. The following description is an initial attempt to gather thoughts, formulate the questions and receive feedback.
How to enable enterprise digital transformation by improving the way of thinking and the way of working for enterprise architect in the context of enterprise sensemaking, enterprise architecturing, and enterprise engineering?
This main question may be answered by answering the following groups of sub-questions:
Typically a literature study - To be developed.
When studying the -theory, I observed that it is an ontology, merely describing what kind of way points there are. Although many authors do not agree on the exact meaning, the general accepted translation, according to the philosophical and spiritual tradition of Taoism, of the Chinese word Tao is the way, path, route, or road.
(RQ 1.) What to add to the -theory to guide architects on how to navigate sensemaking, designing and architecturing? What recommendations can we provide for enterprise architects to navigate enterprise digital transformations?
- To be developed.
- To be developed.
I slowly start to recognise my personal disposition and tendency to a rational epistemology where reason is the source and proof of knowledge. I do acknowledge that this conflicts with my starting point as an enterprise architecture practitioner. Artefacts, concepts and methods do not come into their existence almost purely by deduction and intuition. Surely, it must be based on my empirical experiences as a practitioner too.
Reading about the diference between rationalism and empiricism [
Kant’s epistemology explains to me why I am trying to explain a theoretical model that is to be used as a basis for architecturing. Somehow my mind has organised my experiences and formed a pattern that I use to recognize the way design processes are organised. A pattern that is maturing by discussing about it, by describing it, by trying to evaluate its use and applicability. This is what drives my research as in RQ.1, searching for this artefact.
Awareness of this position leads to my preferred research method that
explicitly focus on a hybrid position, the design research methodology. Summarised,
this methodology uses three cycles to design an artefact [
A more recent and appropriate research approach has been suggested. This has
been described in a paper called ”A design science research methodology for
information systems research” [
Because the strict distinction between rationalism and empiricism can impede
rather than advance our understanding[
Hence, the research methodology I will be using is Design Science Research.
The field of Enterprise Engineering (EE) started out as practice, gradually
adding the underlying scientific foundation [
A concept hard to grasp for these students and practitioners is the fundamental diference between the function and the construction of a system. This comprehension is especially important for architects, as their work and responsibilities involve constantly bridging this incommensurable language barrier.
As Enterprise Architecture (EA) practitioners start to broaden their
horizon, their blurred vision of the scope of their own profession, the root of many
misunderstandings, needs clarifying [
In my opinion, the way to navigate between purpose, afordance and property, and their respective perspectives, is not shown suficiently in the several descriptions of the TAO and BETA theories. Practitioners comprehending the incommensurability are not able to translate this in their methods, processes, and deliverables prescriptions. Hence, an attempt to add my insights in this matter by extending the TAO ontology. 3.3
Rigor
3.3.1 TAO Theory The -theory, as part of the philosophical foundations
of the Enterprise Engineering theories, provides the basis for understanding the
notion of systems and models, and clarifies the distinction between function
and construction [
Afordance is originally described as what the environment ofers to the animal [8, p. 120], a passive subject-object relation. This was broadened by Dietz and Mulder in its meaning for enterprises [5, fig. 4.9]. A function is the intended subset of afordance that delivers a need for a stakeholder.
The distinction between the function and the construction is represented in
their respective models: the functional model and the constructional model,
respectively referred to as the black-box model and the white-box model. Dietz
and Mulder [
There is a necessity to derive the exposed behaviour from a designed artefact. This is needed to validate the resulting behaviour (hopefully matching the expressed requirements) that resulted from the goals as expressed by the stakeholder. A goal decomposition in measurable terms should improve the requirements elicitation, and work as an objectification of the matching of a proposed designed artefact.
My view in this matter is a combination of the -theory and appended with the necessary distinction between stakeholders and designer. This view exposes two cycles and allows for identifying issues and improvement suggestions regarding the elicitation of the requirements, such as the aforementioned goal decomposition.
Building from Essence with Technology and Architecture) is an organisational
design theory and is part of the Enterprise Engineering theories. The theory is
about designing artefacts [5, par. 4.4.8] and introduces the General System
Development Process (GSDP) as a framework for understanding the development of
an object system for the benefits of a using system [
The Basic Enterprise Engineering Map (BEEM) as developed by van Dipten
[
The relations between the functional and constructional elements are modelled as Archimate’s ”used by” and ”realizes” relations. The relation with the causes is modelled as realisation of principles and goals. This map was originally intended as a tool to find the right type of requirements for (cloud)sourcing scenario’s. In practice, it worked out as a tool to explain the combination of the containment relations and the recurring function-construction distinction. 3.3.4 Teleology Going back to the 4th century BC, Aristotle is writing about causal explanation. His surviving manuscripts Physics II.3 and Metaphysics V.2 are part of the collective known as the Corpus Aristotelicum. Aristotle’s four answers to the why questions: – Matter - ( , hule ) the material cause of an object. Referring to the materials that causes the object to be. For instance, water being the material cause of an ice cube. However, also including all physical components that together become a new object. – Form - ( "~{ o&, e^{dos ) the formal cause of an object. Referring to the shape of an object. For instance, the roughly cubical shape of an ice cube. – Agent - ( o~ , kinou~n ) the eficient cause of an object. Referring to the agent or actor performing the change that brings an object to existence. However, also the actor’s knowledge and skills to do so. For example, the ice maker plus his or her knowledge of making ice cubes. – End or purpose - ( " o&, télos ) the final cause of an object. Referring to the purpose of an object, separated from human desires. For instance, the purpose of an ice cube is to cool down something. According to Aristotle, objects in the natural world may have a purpose on its self, even if humans would not have created the object. When this abductive reasoning (the best available reason) is confronted with the theory of evolution by Darwin, soon better arguments are to be found. Fortunately, in our context of enterprise engineering this is not a problem, as enterprises are the result of human construction and hopefully not the result of random evolution and survival bias. 3.4
I envision and visualise two perspectives (subjective and objective) next to each other. (See Fig. 6) – The language used in the subjective perspective is the teleological language.
It uses terms like “feel”, “purpose” or “goal”, “for the subject”, and “reason”. It answers the why questions, the purpose, analogue to the final cause by Aristotle. – The language used in the objective perspective is the ontological language.
It uses terms like “it is”, “entities”, “being”, “categories”, “white box”, and “existence”. It answers the what and how questions, the material and form, analogue to the material cause and the formal cause . – The language used on the border of the two perspectives is about functions.
It is the functional language, used to describe the subject-object relation as required by the user / stakeholder and described by the designer. This is analogue to the combination of the final, formal and material causes 1. It uses terms like “for whom”, “value”, “requirement”, “need”, “black box”, and “afecting”. It answers the what it does and for who questions.
The vertical dimension in the proposed visualisation depicts the diference
between the current state on the top side and the future or desired state on
the bottom. This adds the needed path, the way, the Tao to get from one state
to another state2. Note that there is no available language to bridge the gap
between the subjective and objective perspectives as these perspectives are
incommensurable, as explained by Hoogervorst [
For the purpose of a map, the combination of these two triangles should be able to extend to multiple levels by putting side 1-2 of a next level right under side 3-4 of the first level. 3.4.1
States the corners of the map represent four diferent awareness states. 1. Purpose & Current - Awareness: why we are 2. Function & Current - Awareness: what we are, and for who 3. Function & Desired - Awareness: why we want to become, and for who 4. Property & Desired - Awareness: What we want to become 3.4.2 Transitions With these states, I am able to describe the state transitions, a change from one state to another state. For example, from being aware of x to being aware of y.
– The transition 1 ) 3 is an description of purpose to the desired purpose.
The applicable language is and stays teleological, thus state 3 can be derived (analyse, fit-gap, procedural) from 1. – The transition 1 ) 2 is bridging from the teleological language to the ontological language, incommensurable, thus a design process. The goal is awareness of what is. – The transition 2 ) 3 on the subjective side represents guidance of the intended state by providing a value.
The transition 2 ) 3 on the objective side represents the prescription of the intended state by providing an function.
This combination of the subjective and objective perspective, guiding and prescribing, should be expressed in a functional language: what to become, for who and why. – The transition 2 ) 4 is the prescribing the properties and objects. A description What should be done. The applicable language is and stays ontological, thus state 4 can be derived from 2. – The transition 3 ) 4 is bridging the teleological language to the ontological language, incommensurable, thus a design process. The goal is awareness of what to become and how.
An invisible nuance in the visualisation is the iterative and, especially regarding the design processes, the emergent nature of the transitions. 3.5
At this time I have developed three initial evaluations. These have to be elaborated.
uation is to validate the applicability of the conceptualisation and expression in the context of an enterprise and the statements and documents senior management uses to describe and guide it purpose and strategy. Typically, they use labels such as mission, goals, vision, strategy, architecture, value statements etcetera.
I compared three sources from [
Mission, Vision and Values I see as the current situation. The Goals and Strategy are geared towards the desired situation. (See fig. 7) 1. We know: why we are - Label: Mission 2. We know: what we are, and for who - Label: Vision & Values 3. We know: why we want to become, and for who - Label: Goals 4. We know: What we want to become and how - Label: Strategy The r triangle 1-2-3 can be given the label enterprise sensemaking. Describing why we are, what we value, who to create value for, getting to things that are and how they should become. Guiding the goals based on the values. – Mission: Why are we? What is our meaning in our environment or business ecosystem? Why do we exist? The business purpose. – Vision & Values: What are we? What do we contribute to our stakeholders?
What value do we create? – Goals: What do we want to be, and why? What do we want to contribute to our stakeholders? What value do we want to create? How do we measure our success? The 4 triangle 2-3-4 can be given the label enterprise architecturing3 [enterprise engineering?]. On the one hand applying principles, prescribing how to make decisions: how and for whom. On the other hand, the models prescribing what to become.
– Vision & Values (as previous description) – Goals (as previous description) – Strategy: What do we need to become? What means do we need? What steps do we take to reach our goals? 3.5.1.1
In this model, a state has a meaning in the context of enterprises. For example: State 1 is the enterprise being aware of its mission. The transition is: How does it become aware of its vision and goals? This includes the processes to create explicit statements, documents, culture, awareness etcetera.
– The transition 1 ) 3 is getting from a describing of the general purpose to the intended purpose for the enterprise. The applicable language is and stays teleological, thus state 3 can be derived from 1 via a (procedural) ift-gap analysis. – The transition 1 ) 2 is a design process. Bridging the teleological language to the ontological language, incommensurable, thus a design process. The result is a high-level prescription of what the enterprise is, a vision. – The transition 2 ) 3 on the teleological side represents guidance of the intended purpose.
The transition 2 ) 3 on the ontological side represents the prescription of the intended goals.
Together they work as a function, the combination of the subjective and objective. A functional prescription of what to become, for whom and why. – The transition 2 ) 4 is the prescribing the properties and objects. What should be done, the strategy. The applicable language is and stays ontological, thus state 4 can be derived from 2 via a (procedural) fit-gap analysis. – The transition 3 ) 4 is a design process. Bridging the teleological language to the ontological language, incommensurable, thus a design process. The result is a recipe of what the enterprise should to reach its vision and goals.
A strategy.
The route to a strategy can be summarised as: State 1 2 (designing); State 2 , 3 and 1 ) 3 (iteration, deriving); State 2 ) 4 and 3 4 (deriving, designing) 3 Architecting is creating architects, architecturing is creating architectures [4, p. 6].
A survey was set up to verify this mapping. A list of enterprise statements is given: mission, vision, goals, strategy, internal values, external values, enterprise architecture, other-1 and other-2 (two optional labels to be filled by the interviewee). The questions of the survey are: – What questions are answered with the following enterprise statements or documents? and by who? – Are these statements aimed at the past, current, or future situation? – What statements are needed as input for these statements? (a relation matrix) and are there any combinations that are especially complicated or easy, and why? – What language is used? Aimed at explaining the ”why”, aimed at stakeholders, or aimed at answering ”what”? 3.5.1.3
The enterprise labels are very ill-defined, making it susceptible to multiple interpretations. Within this bandwidth it is possible to map the common enterprise labels to the conceptualisation.
The survey setup was tested once. The feedback was mainly on some of the form labels. No fundamental discussion on the questions. It immediately showed a complete diferent explanation of the meaning of one of the statements. 3.5.2 Evaluation 2 - adding a second level The existence and awareness of a strategy is just the start of the path to a changed enterprise. Can we add a second level to the conceptualisation and again add enterprise labels? The states (see figure 8): 5. We know: Why and what to do, and for who - Label: enterprise portfolio 6. We know: What to do - Label: programs / projects / changes 3.5.2.1
A question arises about the two design processes from states 3 ) 4. The first is an engineering properties process from the first level. The result is a recipe of what the enterprise should to reach its vision and goals. A strategy. The second is a transition between the same states, but on the second level. In this subjective perspective it now becomes a process that designs the functions from the goals, to that same strategy. This needs some more deliberation.
their paper, Greefhorst and Proper [9, p. 3] propose a generic process that handles the entire life-cycle of architecture principles. They describe the creation, validation, application and managing changes of the principles.
There could be a relation between the processes and the proposed roadmap. The proposed roadmap addition for a TAO ontology and accompanying visualisation reflect my vision of the complicated relations between teleology, function, and ontology and how the subjective and objective perspectives could/should be used to guide design processes. The distinction between three diferent and incommensurable language types is explicitly visible, recognising that emergent and creative design processes are necessary to bridge between them.
First evaluations of these artefacts are ongoing.
I am (barely) aware of the vast amount of literature on this topic. I invite you, next to comments on the research setup and proposed artefact, to give any recommendations on this topic.