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 [5,11,12].
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:
1. On the theory of sensemaking, designing and architecturing:
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? 3. On situationally managing an enterprise and governing change:
-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 difference between rationalism and empiricism [15], I found references leading me to an interesting position as described by the philosopher Kant. His three distinctions: a priori versus a posteriori, analytic versus synthetic, and nouminal versus phenomenal, lead Kant to a new compromise. His epistemology can be summarised as "The idea is not that our minds literally create the world, but that our minds organise experience, so we perceive it as recognisable objects".
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 [10]. (See Fig. 1) -Design Cycle (main) -iterating the activities of building and evaluating the design artefacts and processes of the research. -Relevance Cycle -bridging context with the main Design Science Research activities. Contributing requirements and testing of the application of the artefact. -Rigor Cycle -bridging scientific foundations, experience, and expertise to inform the main cycle. Contributing grounding and additions to the knowledge base [10].
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" [18]. Peffers describes a process sequence that we will use to restructure a next version of this paper.
The remainder of this paper elaborates my first research question RQ 1.:
(RQ 1.) What to add to the τ -theory to guide architects on how to navigate sensemaking, designing and architecturing?
Because the strict distinction between rationalism and empiricism can impede rather than advance our understanding [15], and because the Design Science Research method explicitly integrates an empirical way of working in the relevance cycle and the evaluation, this combination with the emergent designing and the Rigor cycle should enforce a better balance between the two. 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 [19]. Foundational publications have been created by authors such as Dietz, Mulder and Hoogervorst [1,5,11,12]. Multiple researchers have dedicated their energy on adding to the body of knowledge as recorded in the series "Advances in Enterprise Engineering". A growing number of classes are taught, more and more students and practitioners are exposed to the Enterprise Ontology (EO) way of thinking and the Design and Engineering Methodology for Organizations (DEMO) way of working.
A concept hard to grasp for these students and practitioners is the fundamental difference 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 [14]. According to Lapalme, the school of "Enterprise Integrating" architecture is grounded in systems thinking and needs to approach enterprise design holistically or systemically, rejecting reductionism and embracing complexity and dynamics. The school of "Enterprise Ecological Adaptation" includes the bidirectional relationship of an enterprise to its environment, increasing the complexity again. Referring to the architect being a nurturer, facilitating a learning organisation, and requiring "a great deal of sensemaking -a collaborative process by which people give meaning to experience" [14].
In my opinion, the way to navigate between purpose, affordance and property, and their respective perspectives, is not shown sufficiently 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.
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 [2,5]. It shows three elements: Teleology -Affordance -Ontology. Hence its name TAO. (see figure 2) Teleology is the subjective perspective, explaining why something is, the cause of its existence as experienced by the subject. Ontology is the objective perspective, using its properties to describe what something is. Affordance is originally described as what the environment offers 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 affordance 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 [5] suggest to use the term "business" when referring to the function perspective and decomposition, and "organisation" when referring to the construction perspective and decomposition.
As Hoogervorst explains, the teleological language expresses goals and purposes [12]. From the teleological perspective, these point to the relationship with a human, being formed by the meaning of the purpose and goals. The ontological language is used to express a description how things and phenomena are. These teleological and ontological languages have no common concepts and words to reason from a concept in one language to the other. The languages are incommensurable. There is no formal procedure to derive a realisation from purpose and goals. The only possible route is to employ a creative human agent that iteratively synthesises a solution. The Function-Behaviour-Structure ontology is based on the work of John S. Gero [7] and conceptualizes design objects in three ontological categories: function (F), the teleology of the artefact ('what the artefact is for'), behaviour (B), the artefact's attributes that can be derived from its structure ('what the artefact does'), and structure (S), its components and their relationships ('what the artefact consists of'). [7, p. 265].
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. ] 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 [5]. More recent visualisations of the process include the architecture element, relating it to the functional and constructional principles that are used in the function and construction design process steps.
The Basic Enterprise Engineering Map (BEEM) as developed by van Dipten [6], gives insight into the coherence of activities and results in the field of IT. The map iterates a GSDP process in the dimension of the realisation axis of the Enterprise Engineering Framework (EEF). Hence, my earlier remark that this map should be named BERM [17, p. 35]. As an alternative, using the engineering axis, I created another map to show the iterative relation between function and construction [17, par. 7.2]. Emphasising the embedding of the classical architecture layers and visualised with Archimate. (See Fig. 5)
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. -Matter -( `ύλη, h úlē ) 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υν, kinoũn ) the efficient 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.
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 causes1 . It uses terms like "for whom", "value", "requirement", "need", "black box", and "affecting". It answers the what it does and for who questions.
The vertical dimension in the proposed visualisation depicts the difference 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 [12]. Bridging the gap between these perspectives is an iterative and creative process. It is related to the verbs: designing and engineering.
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. -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.
At this time I have developed three initial evaluations. These have to be elaborated.
The goal of this first evaluation 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 [16,13,3] and various Wikipedia lemmas. Unfortunately, there are many ambiguous explanations of these labels.
Mission, Vision and Values I see as the current situation. The Goals and Strategy are geared towards the desired situation. (See fig. 7) Fig. 7. two perspectives on enterprise (strategy) development, including labels -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 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?
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) fit-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)
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"?
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 different explanation of the meaning of one of the statements.
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
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.
In 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 different 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.