Towards Next Generation Process Execution

A considerable part of my professional time is spent on advising people on discovering, redesigning, and — if possible and feasible — automating their business processes. Often, trivial, cumbersome, and predictable processes can be formalised and executed using a process engine (also known as BPMS, Business Process Management Suites). Process execution is usually combined with an enterprise service bus (ESB) or middleware layer, which supplies data sources and exposes business transactions to the process layer in an open, reusable, and interoperable fashion.

BPMS is by no means a new concept. Most contemporary BPMS platforms began as workflow engines and CASE (Computer-Aided Software Engineering) tools, which subsequently found valuable use in the rising Java EE and enterprise application integration (EAI) markets of the 90’s and onwards. This, combined with an increasing interest in information management and enterprise integration, spawned today’s plethora of repository based modelling tools, sophisticated middleware technology, and process execution platforms.  

Looking into the crystal ball of process automation, what automation technologies can enterprises expect to see in the years to come? Now, here, any average IT analyst would probably come up with three all-too-often-adopted shrinkwrapped concepts:
  1. Cloud computing
  2. X-as-a-service
  3. Agile
In order to actually coming up with something original or different, I have deliberately omitted these three words in this blog entry. That is not to say that these trends aren’t influential or important, but they have already been stated elsewhere in thousands of blog posts, whitepapers, and academic papers. In the following sections I will present my stance towards aspects of next generation process automation.
Closed-Loop Roundtrip Engineering
Several toolchains support the so-called ‘roundtrip’ between repository-based enterprise modelling tools and implementation level process development tools. Too often this is a one-way exercise in which business processes are modelled by the business analyst, approved by the process owner and then exported to execution by the solution architect. However, once the process model hits the implementation floor, governance, roundtrip, and traceability are cut off. The process model is now materialised as source code rather than a visual model.

An improved, closed-loop roundtrip approach would most likely solve this bridge by making the process integration point both ways. This calls for an improved bridging strategy between the two worlds so they ultimately merge into one. That is not to say that the designed process model must equal the executable process model — the enterprise repository should still provide different, role-based views onto the same processes. The tipping point that I am arguing is that full traceability from model to execution demands to-way traceability and unified single-interface version control of all artefacts.
Light-weight Executable Process Models
Modelling standards such as BPMN 2.0 (Business Process Modelling Notation) claim to provide single, uniform language for modelling manual, semi-automated, and fully automated business processes. However, as several process practitioners have already emphasised, the notation is still far too rich and complex for non-technical professionals and businesspeople to fully comprehend. It is as if the notation, indulging in its own ambitions and adoption, has widened its gap too far and suddenly struggles to articulate all possible aspect of a process.

SOA practitioners struggled with the same complexity problems in the early 2000’s. Everywhere, new and half-baked service standards emerged, and some “standards” even offered duplicate functionality. For SOAP, what was meant to be a simple protocol for exchanging messages had now morphed into a wilderness of WS-* standards, policy documents, and pseudo recommendations. As a counter effect, REST (Representational State Transfer) was adopted as a viable, lightweight, and easy-to-implement alternative to the WS-* conglomerate. REST’s elegance was its simplicity, very similar to how the simplicity of the TCP and IP network protocols defeated complex, proprietary network protocols such as DECNET and Tymnet. Useful, open standards are easy to simple and easy to understand and communicate. WS-* was by no means a lightweight stack, just as BPMN 2.0 is too rich to be truly elegant.

What BPMS needs is a process modelling notation that is just as elegant as REST and TCP. The simpler notation, the easier it is for business analysts to pick up the notation and understand a particular model. Fewer moving parts and modelling exceptions also implies that the designed process is easier to execute. Consider the source code necessary for parsing a WSDL schema with surrounding WS-Security artefacts compared to lines of code necessary to retrieve and parse a JSON data structure across a TLS-encrypted wire. For execution, a light-weight process model format with different role-based process architecture views are necessary accommodate for easy-to-communicate and easy-to-execute processes models. 

Process Variations
My third idea is the notion of modelling and execution of process variants. Several enterprise modelling tools (such as ARIS) support the idea of variant artefacts, which allows for a configuration item to be traced back to its reference artefact. This is particularly useful when mapping a process model or architectural layer against a set of reference architectures, which in turn allows for quick discovery and gap analysis of compliance requirements.

However, for some reason this idea has yet not made its way to process execution land. The majority of BPMS platforms treat process models as isolated, transactional entities. References are done by related events or drilling into sub process models. Process layering and variation are completely unknown concepts in the world of execution, despite its inherent adoption in enterprise modelling. Many enterprises struggle with the need for selecting and executing a particular process variant depending on a set of pre-conditions, whilst still being able to reflect that the instance belongs to a particular group of variants. An executable billing process might vary slightly depending on the type of the client currently being billed, but the process is still the billing process. Integrating process variations in BPMS theory adds depth and context to the executable process models, as opposed to pure, isolated workflows.

Process Regulation and Self-Reference 
The research field of control theory and cybernetics has for long explored the properties of self-organising systems, which respond in a meaningful way to outside stimuli. Examples of cybernetic systems are everything from simple thermometers to complex jet fighter engines, which monitor and regulate their current state depending on the environment (such as temperature or altitude). Similarly, researchers in business process management (BPM) and process engineering have explored the idea of self-regulating processes: business processes that monitor, adjust, and control their own state, activity, and performance based on the general condition of the overall enterprise. In manufacturing this would be a process, which adjusts its production throughput automatically based on recent market trends received from the business intelligence system. Sales processes adjust their current inventory data based on market forecasts triggered by an external supplier. Car manufacturing robots do just-in-time adjustment of assembly line activity after observing a major slump in the stock market five minutes ago. The modern enterprise is event-driven, interconnected, and immediately responsive. However, in order for business processes to exploit this opportunity they need to become self-regulating or “self-aware.” Executable processes must be able to adjust their own complex states based on listeners and triggers from external events. This technology demands sophisticated complex event processing and a meta-process environment, which allows for easy and dynamic reconfiguration of process model layout, design, and performance based on external data. The change in state should not be limited to a pre-configured set of process patterns. Process models and metadata should automatically infer new possible process designs and subsequently select the most plausible design based on previous design choices, feedback, and execution data. 


To Be Continued
These considerations are only a small part of the ideas I have been collecting for next generation process automation, which could very well evolve into a general research programme on the future of BPMS. It is my opinion that we have reached a solid state of enterprise integration tools and middleware platforms. However, BPMS theory and practice is still in a state of flux: shiny new tools emerge every day, but fact is that we have very little experience with designing, deploying, and maintaining complex, large-scale process applications. Granted the general principles of software engineering and IS development theory still apply: effectively, most process applications involve enterprise systems in the large with a vast amount of moving parts and integration points. However, in order to successfully respond to the increasingly rapid markets and requirements change, we need faster, simpler, context-aware, and interconnected BPMS platforms driven by self-regulation and complex event processing. In my upcoming blog posts I will write more on this topic.

Towards Next Generation Process Execution

A considerable part of my professional time is spent on advising people on discovering, redesigning, and — if possible and feasible — automating their business processes. Often, trivial, cumbersome, and predictable processes can be formalised and executed using a process engine (also known as BPMS, Business Process Management Suites). Process execution is usually combined with an enterprise service bus (ESB) or middleware layer, which supplies data sources and exposes business transactions to the process layer in an open, reusable, and interoperable fashion.

BPMS is by no means a new concept. Most contemporary BPMS platforms began as workflow engines and CASE (Computer-Aided Software Engineering) tools, which subsequently found valuable use in the rising Java EE and enterprise application integration (EAI) markets of the 90’s and onwards. This, combined with an increasing interest in information management and enterprise integration, spawned today’s plethora of repository based modelling tools, sophisticated middleware technology, and process execution platforms.  

Looking into the crystal ball of process automation, what automation technologies can enterprises expect to see in the years to come? Now, here, any average IT analyst would probably come up with three all-too-often-adopted shrinkwrapped concepts:
  1. Cloud computing
  2. X-as-a-service
  3. Agile
In order to actually coming up with something original or different, I have deliberately omitted these three words in this blog entry. That is not to say that these trends aren’t influential or important, but they have already been stated elsewhere in thousands of blog posts, whitepapers, and academic papers. In the following sections I will present my stance towards aspects of next generation process automation.
Closed-Loop Roundtrip Engineering
Several toolchains support the so-called ‘roundtrip’ between repository-based enterprise modelling tools and implementation level process development tools. Too often this is a one-way exercise in which business processes are modelled by the business analyst, approved by the process owner and then exported to execution by the solution architect. However, once the process model hits the implementation floor, governance, roundtrip, and traceability are cut off. The process model is now materialised as source code rather than a visual model.

An improved, closed-loop roundtrip approach would most likely solve this bridge by making the process integration point both ways. This calls for an improved bridging strategy between the two worlds so they ultimately merge into one. That is not to say that the designed process model must equal the executable process model — the enterprise repository should still provide different, role-based views onto the same processes. The tipping point that I am arguing is that full traceability from model to execution demands to-way traceability and unified single-interface version control of all artefacts.
Light-weight Executable Process Models
Modelling standards such as BPMN 2.0 (Business Process Modelling Notation) claim to provide single, uniform language for modelling manual, semi-automated, and fully automated business processes. However, as several process practitioners have already emphasised, the notation is still far too rich and complex for non-technical professionals and businesspeople to fully comprehend. It is as if the notation, indulging in its own ambitions and adoption, has widened its gap too far and suddenly struggles to articulate all possible aspect of a process.

SOA practitioners struggled with the same complexity problems in the early 2000’s. Everywhere, new and half-baked service standards emerged, and some “standards” even offered duplicate functionality. For SOAP, what was meant to be a simple protocol for exchanging messages had now morphed into a wilderness of WS-* standards, policy documents, and pseudo recommendations. As a counter effect, REST (Representational State Transfer) was adopted as a viable, lightweight, and easy-to-implement alternative to the WS-* conglomerate. REST’s elegance was its simplicity, very similar to how the simplicity of the TCP and IP network protocols defeated complex, proprietary network protocols such as DECNET and Tymnet. Useful, open standards are easy to simple and easy to understand and communicate. WS-* was by no means a lightweight stack, just as BPMN 2.0 is too rich to be truly elegant.

What BPMS needs is a process modelling notation that is just as elegant as REST and TCP. The simpler notation, the easier it is for business analysts to pick up the notation and understand a particular model. Fewer moving parts and modelling exceptions also implies that the designed process is easier to execute. Consider the source code necessary for parsing a WSDL schema with surrounding WS-Security artefacts compared to lines of code necessary to retrieve and parse a JSON data structure across a TLS-encrypted wire. For execution, a light-weight process model format with different role-based process architecture views are necessary accommodate for easy-to-communicate and easy-to-execute processes models. 

Process Variations
My third idea is the notion of modelling and execution of process variants. Several enterprise modelling tools (such as ARIS) support the idea of variant artefacts, which allows for a configuration item to be traced back to its reference artefact. This is particularly useful when mapping a process model or architectural layer against a set of reference architectures, which in turn allows for quick discovery and gap analysis of compliance requirements.

However, for some reason this idea has yet not made its way to process execution land. The majority of BPMS platforms treat process models as isolated, transactional entities. References are done by related events or drilling into sub process models. Process layering and variation are completely unknown concepts in the world of execution, despite its inherent adoption in enterprise modelling. Many enterprises struggle with the need for selecting and executing a particular process variant depending on a set of pre-conditions, whilst still being able to reflect that the instance belongs to a particular group of variants. An executable billing process might vary slightly depending on the type of the client currently being billed, but the process is still the billing process. Integrating process variations in BPMS theory adds depth and context to the executable process models, as opposed to pure, isolated workflows.

Process Regulation and Self-Reference 
The research field of control theory and cybernetics has for long explored the properties of self-organising systems, which respond in a meaningful way to outside stimuli. Examples of cybernetic systems are everything from simple thermometers to complex jet fighter engines, which monitor and regulate their current state depending on the environment (such as temperature or altitude). Similarly, researchers in business process management (BPM) and process engineering have explored the idea of self-regulating processes: business processes that monitor, adjust, and control their own state, activity, and performance based on the general condition of the overall enterprise. In manufacturing this would be a process, which adjusts its production throughput automatically based on recent market trends received from the business intelligence system. Sales processes adjust their current inventory data based on market forecasts triggered by an external supplier. Car manufacturing robots do just-in-time adjustment of assembly line activity after observing a major slump in the stock market five minutes ago. The modern enterprise is event-driven, interconnected, and immediately responsive. However, in order for business processes to exploit this opportunity they need to become self-regulating or “self-aware.” Executable processes must be able to adjust their own complex states based on listeners and triggers from external events. This technology demands sophisticated complex event processing and a meta-process environment, which allows for easy and dynamic reconfiguration of process model layout, design, and performance based on external data. The change in state should not be limited to a pre-configured set of process patterns. Process models and metadata should automatically infer new possible process designs and subsequently select the most plausible design based on previous design choices, feedback, and execution data. 


To Be Continued
These considerations are only a small part of the ideas I have been collecting for next generation process automation, which could very well evolve into a general research programme on the future of BPMS. It is my opinion that we have reached a solid state of enterprise integration tools and middleware platforms. However, BPMS theory and practice is still in a state of flux: shiny new tools emerge every day, but fact is that we have very little experience with designing, deploying, and maintaining complex, large-scale process applications. Granted the general principles of software engineering and IS development theory still apply: effectively, most process applications involve enterprise systems in the large with a vast amount of moving parts and integration points. However, in order to successfully respond to the increasingly rapid markets and requirements change, we need faster, simpler, context-aware, and interconnected BPMS platforms driven by self-regulation and complex event processing. In my upcoming blog posts I will write more on this topic.

Announcing Upcoming Book: Systems Thinking in Enterprise Architecture

Dr. John Gøtze and I have announced the forthcoming publication of a new book titled: Systems Thinking in Enterprise Architecture. The book, which targets the intersection of practitioners and academics, explores the important, notional relationship between Enterprise Architecture (EA), systems thinking, and cybernetics. A wide array of authors have been invited to contribute to the book resulting in a total of 20 chapters on the topic. 

Systems Thinking in Enterprise Architecture is still the working title of the book and it expected to change once all chapters have been reconciled. The book will be published in the Systems Thinking and Systems Engineering Series by College Publications, thus marking the successor to the remarkable volume 1: A Journey Through the Systems Landscape by Harold “Bud” Lawson, who is also one of the joint contributors to our book.
In order to read more about the book, please refer to the ITU Enterprise web site for deadlines, list of contributors, and publication guidelines. If you are interested in contributing, please do not hesitate to send us a draft manuscript!

Announcing Upcoming Book: Systems Thinking in Enterprise Architecture

Dr. John Gøtze and I have announced the forthcoming publication of a new book titled: Systems Thinking in Enterprise Architecture. The book, which targets the intersection of practitioners and academics, explores the important, notional relationship between Enterprise Architecture (EA), systems thinking, and cybernetics. A wide array of authors have been invited to contribute to the book resulting in a total of 20 chapters on the topic. 

Systems Thinking in Enterprise Architecture is still the working title of the book and it expected to change once all chapters have been reconciled. The book will be published in the Systems Thinking and Systems Engineering Series by College Publications, thus marking the successor to the remarkable volume 1: A Journey Through the Systems Landscape by Harold “Bud” Lawson, who is also one of the joint contributors to our book.
In order to read more about the book, please refer to the ITU Enterprise web site for deadlines, list of contributors, and publication guidelines. If you are interested in contributing, please do not hesitate to send us a draft manuscript!

Rhizome: On Dilemmas in Enterprise Architecture Planning

In the field of IS and management we often put forward a certain conception of the organisation, the social. In contemporary business consulting and management academia, the organisation is often conceptualised as a hierarchical open system with a certain body of knowledge supplying the management system with rational decision making. Other alternative, academic approaches are influenced by literature studies and Gadamer’s hermeneutics (Gadamer, 1975), promoting the need for understanding and context, the particular, rather than the universal and manageable. Emerging from these two spectra, each fighting for their own conception of subjectivity and objectivity, Anglo-Saxon and continental philosophy, each defining the criteria for truth and meaning, one uncovers systems theory and cybernetics which proposes a model for generalising structures and properties between different phenomena in the world: Bertalanffy (Bertalanffy, 1969) suggests a unified cybernetic model for living, mechanic, and social systems, whereas von Foerster (Von Foerster, 2003) and Luhmann (Luhmann, 1995) suggest a second order model based on constructed observation and interpretation. In organisation studies, first and second order systems theory each postulate their own conception or construction of social reality: Parsons defines the social as actions or events referring to each other within a structural organising of social functions, whereas Luhmann flips the tin can with a functional organisation of social structures based on communication, reproducing and sustaining itself through Maturana and Varela’s concept of autopoiesis (Maturana & Varela, 1980).

Amidst IS management’s–and thus EA’s–attempt to establish a common, trans-disciplinary foundation for research, there appears to be an ontological schism of what the social is and organisations really are. Is it a collective intelligence or logic of rational decision making? Is it a reactive, intersubjective collective attempting to make sense of the world in hindsight through history and culture? Or is it a system or a construction of a system that organises, structures, or communicates through constant adaption and recursive reproduction only by reference to its own recursion and reproductivity? The latter approach dissolves the former two boundaries by creating a boundary of distinction even more important than the understanding subject itself at the edge of every possible system. It is the distinction between system and environment that generates or fabricates meaning and truth, but it comes at the cost of reducing our very own processes of cognition and sensemaking to a set of vibrating antennas or satellites mounted at the fragile surface of every human system.  

An ontology of the social is thus far from complete. Enterprise Architecture (EA) seeks to address this by building layers of abstraction and control, thereby assuming that static systems models of socio-technical relations yield manageability and transparency. Accountability is achieved by linking formal role descriptions to process models and system landscapes, often positioned in a well-defined hierarchy and stored in a database repository for later reference and reuse. In order to reuse ‘best practices’ and assure a certain level of maturity in framework and methodology, enterprises often implement their architecture practice against existing reference frameworks and enterprise meta models. Frameworks such as FEAF even include a CMMI-like maturity model for EA, which assesses the success of architecture program by measures such as completeness and integration. OMB, the US Federal Office of Management and Budget, has furthermore published a set of measures of architectural completeness for evaluating US Federal Agencies. The highest achievement, level 5, is the architectural utopia in which the organisation practicing EA corrects its own business failures by architectural inspection. Architecture is here synonymous with optimising an organisation.


Given the above reflections on what the social really is, is it really philosophically reasonable to suggest that a stable, decomposable, hierarchical model, which most enterprise meta-models really are, is capable of building a comprehensive model of the social? Is it really meaningful to stretch virtually any organisation, be it government or private, along a five-level diagram and measure it by how well-described architectural elements are? And what happens when the Federal agency hits the ceiling after 5? Those are clever and important questions that information and organisation science ought to ask. Unfortunately, that is seldom the case. Maturity models, in the classic form of a five-step ladder, are an inherent part of any contemporary management/IS theory: process maturity, architecture maturity, service maturity, integration maturity. The five-step Capability Maturity Model (Paulk, 1995) has its roots in systems engineering carried out by engineers building space shuttles for NASA. As universal as it may be, the problems, issues, and solutions faced by modern organisations are far more muddy, messy, an ill-defined than those originally faced by defence contractors and DoD bureaucrats. Such fast-paced, deep problems are also characterised as wicked problems (Rittel & Webber, 1973):
  1. Wicked problems have no definitive formulation. One can infer that the problem exists, but will never be able to fully document the problem.
  2. The solution to a wicked problem is “good or bad” not “true or false”.
  3. Every possible solution is a one-shut operation as every solution attempt will leave a trace which cannot be undone.
  4. Each wicked problem is unique and may eventually be the symptom of another, underlying wicked problem.
Through my previous research, I have suggested a systems theoretical approach towards understanding and explaining EA. Systems theory is helpful towards describing the messy complexity of social and communicative structures. Second order systems theory adds a rich, dynamic theory for understanding communication in- and outside organisation by describing the exchange of utterances between human actors in search of meaning (Jensen, 2010). I believe, however, that these two key conceptions of enterprise planning and governance can furthermore be extended into a general theory of EA by including Deleuze’s theory of the rhizome.

Deleuze (Deleuze & Guattari, 1988) describes the rhizome structure (Deleuze & Guattari, 1976) as a meaningful alternative to uncovering complex structures, be they social or biological. Western society, Deleuze explains, has built its historicity and philosophy on the basis of binary structures: true-false, yes-no, top-bottom, maturity-immaturity. Contemporary EA frameworks are, in fact, highly binary: layers separated by clear boundaries, processes with a start and end, structured organisation charts and capability maps with a top and bottom. The rhizome is a viable alternative since it assumes an inherent complexity of what it is intended to describe. The rhizome is constantly transforming and morphing itself, making it virtually impossible to map out its structure completely at any point in time. This is exactly how wicked problems occur. Wicked, messy problems could, in fact, be described as rhizomatic structures. The rhizome structure applies well to the socio-technical nature of organisations as well, as the dissipative relationships between humans, technology, and organisation structures form a complex, dynamic, and transforming entity with no clear, formal, or necessarily logical order. This rhizomatic relationship is probably best explained in the field of technology adoption and diffusion in private enterprises where traditional positivist approaches to management and innovation struggle to explain how and why technology trends emerge and behave. This reflection on Deleuze leads to the following important claim:

Organisations are complex, dissipative structures constantly transforming complex, human knowledge and social relationships. A rhizomatic systems model satisfies such conception of organisational reality. Hence, Enterprise Architecture, in its search for whole-of-enterprise views, should adopt rhizomatic theory for uncovering and understanding the true messiness of organisations as socio-political habitats.


Understanding Enterprise Architecture as a rhizomatic systems practice, however, must come at the cost of killing certain darlings. The first darling is the idea of organisations as stable structures operating on explicit, verifiable knowledge, which in turn can be divided into clear architectural layers and segments. The second darling is the conception of a universal maturity model explaining the natural progression towards “EA nirvana”. There is no such one.
  1. Layers, segments, and hierarchical models depart from a Westernised, binary view of the world. Layering suggests decomposability and abstraction of organisational complexity. A rhizome does not have such properties. The messy, social facets of organisational life cannot be decomposed or functionally abstracted. The social does not have a single function and thus cannot be functional. Wicked problems, as they emerge from social interactions and organisational problems, are rhizomatic and cannot be explained fully through rationalist models.
  2. Maturity models are inherently binary. They suggest a natural progression towards the optimal stage 5 somewhat similar to a tree as it stretches its branches towards the rising sun. The rhizome is the exact opposite of a tree structure as its roots and shoots grow and form in any direction, shrouding and shifting its original structure. Social structures, apart from the general statistical patterns uncovered by social psychology, do not follow universal laws of transformation or branching—and hence it is impossible and meaningless to suggest a generic, universalistic maturity model of social behaviour in EA adoption and planning. There is no such nirvana of Enterprise Architecture—and if there ever were, it would be constantly shifting and transforming depending on the current managerial climate, problems of planning, and struggle for control inside the organisation. Exactly this relationship of management, planning, and control is rhizomatic as well.

For Enterprise Architecture to fully explain these sacrifices, it must adopt a view of the enterprise as a non-linear, interconnected multiplicity, for which structures can only be meaningfully traced and described in hindsight. Traces always remain interpretations. Enterprise modelling involves tracing organisation structures, but as these structures are traced and interpreted, they suddenly shift and transform into a different multiplicity. Enterprise Architecture is thus a semiotic practice of tracing and interpreting organisations as complex signs. The output, the long-term plans, roadmaps, and meta-models, are merely simplified pictures of these dissipative signs. Only by accepting these aspects of enterprise reality, can Enterprise Architecture truly characterise the challenges and solutions in strategic planning and enterprise management.  

References:
Bertalanffy, L. v. (1969). General System Theory; Foundations, Development, Applications. New York,: G. Braziller.
Deleuze, G., & Guattari, F. (1976). Rhizome : Introduction. Paris: Éditions de Minuit.
Deleuze, G., & Guattari, F. (1988). A Thousand Plateaus : Capitalism and Schizophrenia. London: Athlone Press.
Gadamer, H.-G. (1975). Truth and method. London: Sheed & Ward.
Jensen, A. O. (2010) Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation. Copenhagen Business School.
Luhmann, N. (1995). Social Systems. Stanford, Calif.: Stanford University Press.
Maturana, H. R., & Varela, F. J. (1980). Autopoiesis and Cognition : the Realization of the Living. Dordrecht, Holland ; Boston: D. Reidel Pub. Co.
Paulk, M. C. (1995). The Capability Maturity Model : Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley Pub. Co.
Rittel, H. & Webber, M. (1973), `Dilemmas in a General Theory of Planning’, Policy Sciences 4.
Von Foerster, H. (2003). Understanding Understanding : Essays on Cybernetics and Cognition. New York: Springer.

Rhizome: On Dilemmas in Enterprise Architecture Planning

In the field of IS and management we often put forward a certain conception of the organisation, the social. In contemporary business consulting and management academia, the organisation is often conceptualised as a hierarchical open system with a certain body of knowledge supplying the management system with rational decision making. Other alternative, academic approaches are influenced by literature studies and Gadamer’s hermeneutics (Gadamer, 1975), promoting the need for understanding and context, the particular, rather than the universal and manageable. Emerging from these two spectra, each fighting for their own conception of subjectivity and objectivity, Anglo-Saxon and continental philosophy, each defining the criteria for truth and meaning, one uncovers systems theory and cybernetics which proposes a model for generalising structures and properties between different phenomena in the world: Bertalanffy (Bertalanffy, 1969) suggests a unified cybernetic model for living, mechanic, and social systems, whereas von Foerster (Von Foerster, 2003) and Luhmann (Luhmann, 1995) suggest a second order model based on constructed observation and interpretation. In organisation studies, first and second order systems theory each postulate their own conception or construction of social reality: Parsons defines the social as actions or events referring to each other within a structural organising of social functions, whereas Luhmann flips the tin can with a functional organisation of social structures based on communication, reproducing and sustaining itself through Maturana and Varela’s concept of autopoiesis (Maturana & Varela, 1980).

Amidst IS management’s–and thus EA’s–attempt to establish a common, trans-disciplinary foundation for research, there appears to be an ontological schism of what the social is and organisations really are. Is it a collective intelligence or logic of rational decision making? Is it a reactive, intersubjective collective attempting to make sense of the world in hindsight through history and culture? Or is it a system or a construction of a system that organises, structures, or communicates through constant adaption and recursive reproduction only by reference to its own recursion and reproductivity? The latter approach dissolves the former two boundaries by creating a boundary of distinction even more important than the understanding subject itself at the edge of every possible system. It is the distinction between system and environment that generates or fabricates meaning and truth, but it comes at the cost of reducing our very own processes of cognition and sensemaking to a set of vibrating antennas or satellites mounted at the fragile surface of every human system.  

An ontology of the social is thus far from complete. Enterprise Architecture (EA) seeks to address this by building layers of abstraction and control, thereby assuming that static systems models of socio-technical relations yield manageability and transparency. Accountability is achieved by linking formal role descriptions to process models and system landscapes, often positioned in a well-defined hierarchy and stored in a database repository for later reference and reuse. In order to reuse ‘best practices’ and assure a certain level of maturity in framework and methodology, enterprises often implement their architecture practice against existing reference frameworks and enterprise meta models. Frameworks such as FEAF even include a CMMI-like maturity model for EA, which assesses the success of architecture program by measures such as completeness and integration. OMB, the US Federal Office of Management and Budget, has furthermore published a set of measures of architectural completeness for evaluating US Federal Agencies. The highest achievement, level 5, is the architectural utopia in which the organisation practicing EA corrects its own business failures by architectural inspection. Architecture is here synonymous with optimising an organisation.


Given the above reflections on what the social really is, is it really philosophically reasonable to suggest that a stable, decomposable, hierarchical model, which most enterprise meta-models really are, is capable of building a comprehensive model of the social? Is it really meaningful to stretch virtually any organisation, be it government or private, along a five-level diagram and measure it by how well-described architectural elements are? And what happens when the Federal agency hits the ceiling after 5? Those are clever and important questions that information and organisation science ought to ask. Unfortunately, that is seldom the case. Maturity models, in the classic form of a five-step ladder, are an inherent part of any contemporary management/IS theory: process maturity, architecture maturity, service maturity, integration maturity. The five-step Capability Maturity Model (Paulk, 1995) has its roots in systems engineering carried out by engineers building space shuttles for NASA. As universal as it may be, the problems, issues, and solutions faced by modern organisations are far more muddy, messy, an ill-defined than those originally faced by defence contractors and DoD bureaucrats. Such fast-paced, deep problems are also characterised as wicked problems (Rittel & Webber, 1973):
  1. Wicked problems have no definitive formulation. One can infer that the problem exists, but will never be able to fully document the problem.
  2. The solution to a wicked problem is “good or bad” not “true or false”.
  3. Every possible solution is a one-shut operation as every solution attempt will leave a trace which cannot be undone.
  4. Each wicked problem is unique and may eventually be the symptom of another, underlying wicked problem.
Through my previous research, I have suggested a systems theoretical approach towards understanding and explaining EA. Systems theory is helpful towards describing the messy complexity of social and communicative structures. Second order systems theory adds a rich, dynamic theory for understanding communication in- and outside organisation by describing the exchange of utterances between human actors in search of meaning (Jensen, 2010). I believe, however, that these two key conceptions of enterprise planning and governance can furthermore be extended into a general theory of EA by including Deleuze’s theory of the rhizome.

Deleuze (Deleuze & Guattari, 1988) describes the rhizome structure (Deleuze & Guattari, 1976) as a meaningful alternative to uncovering complex structures, be they social or biological. Western society, Deleuze explains, has built its historicity and philosophy on the basis of binary structures: true-false, yes-no, top-bottom, maturity-immaturity. Contemporary EA frameworks are, in fact, highly binary: layers separated by clear boundaries, processes with a start and end, structured organisation charts and capability maps with a top and bottom. The rhizome is a viable alternative since it assumes an inherent complexity of what it is intended to describe. The rhizome is constantly transforming and morphing itself, making it virtually impossible to map out its structure completely at any point in time. This is exactly how wicked problems occur. Wicked, messy problems could, in fact, be described as rhizomatic structures. The rhizome structure applies well to the socio-technical nature of organisations as well, as the dissipative relationships between humans, technology, and organisation structures form a complex, dynamic, and transforming entity with no clear, formal, or necessarily logical order. This rhizomatic relationship is probably best explained in the field of technology adoption and diffusion in private enterprises where traditional positivist approaches to management and innovation struggle to explain how and why technology trends emerge and behave. This reflection on Deleuze leads to the following important claim:

Organisations are complex, dissipative structures constantly transforming complex, human knowledge and social relationships. A rhizomatic systems model satisfies such conception of organisational reality. Hence, Enterprise Architecture, in its search for whole-of-enterprise views, should adopt rhizomatic theory for uncovering and understanding the true messiness of organisations as socio-political habitats.


Understanding Enterprise Architecture as a rhizomatic systems practice, however, must come at the cost of killing certain darlings. The first darling is the idea of organisations as stable structures operating on explicit, verifiable knowledge, which in turn can be divided into clear architectural layers and segments. The second darling is the conception of a universal maturity model explaining the natural progression towards “EA nirvana”. There is no such one.
  1. Layers, segments, and hierarchical models depart from a Westernised, binary view of the world. Layering suggests decomposability and abstraction of organisational complexity. A rhizome does not have such properties. The messy, social facets of organisational life cannot be decomposed or functionally abstracted. The social does not have a single function and thus cannot be functional. Wicked problems, as they emerge from social interactions and organisational problems, are rhizomatic and cannot be explained fully through rationalist models.
  2. Maturity models are inherently binary. They suggest a natural progression towards the optimal stage 5 somewhat similar to a tree as it stretches its branches towards the rising sun. The rhizome is the exact opposite of a tree structure as its roots and shoots grow and form in any direction, shrouding and shifting its original structure. Social structures, apart from the general statistical patterns uncovered by social psychology, do not follow universal laws of transformation or branching—and hence it is impossible and meaningless to suggest a generic, universalistic maturity model of social behaviour in EA adoption and planning. There is no such nirvana of Enterprise Architecture—and if there ever were, it would be constantly shifting and transforming depending on the current managerial climate, problems of planning, and struggle for control inside the organisation. Exactly this relationship of management, planning, and control is rhizomatic as well.

For Enterprise Architecture to fully explain these sacrifices, it must adopt a view of the enterprise as a non-linear, interconnected multiplicity, for which structures can only be meaningfully traced and described in hindsight. Traces always remain interpretations. Enterprise modelling involves tracing organisation structures, but as these structures are traced and interpreted, they suddenly shift and transform into a different multiplicity. Enterprise Architecture is thus a semiotic practice of tracing and interpreting organisations as complex signs. The output, the long-term plans, roadmaps, and meta-models, are merely simplified pictures of these dissipative signs. Only by accepting these aspects of enterprise reality, can Enterprise Architecture truly characterise the challenges and solutions in strategic planning and enterprise management.  

References:
Bertalanffy, L. v. (1969). General System Theory; Foundations, Development, Applications. New York,: G. Braziller.
Deleuze, G., & Guattari, F. (1976). Rhizome : Introduction. Paris: Éditions de Minuit.
Deleuze, G., & Guattari, F. (1988). A Thousand Plateaus : Capitalism and Schizophrenia. London: Athlone Press.
Gadamer, H.-G. (1975). Truth and method. London: Sheed & Ward.
Jensen, A. O. (2010) Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation. Copenhagen Business School.
Luhmann, N. (1995). Social Systems. Stanford, Calif.: Stanford University Press.
Maturana, H. R., & Varela, F. J. (1980). Autopoiesis and Cognition : the Realization of the Living. Dordrecht, Holland ; Boston: D. Reidel Pub. Co.
Paulk, M. C. (1995). The Capability Maturity Model : Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley Pub. Co.
Rittel, H. & Webber, M. (1973), `Dilemmas in a General Theory of Planning’, Policy Sciences 4.
Von Foerster, H. (2003). Understanding Understanding : Essays on Cybernetics and Cognition. New York: Springer.

On the Brink of Structure and Chaos: Framework Prescription and Real-World Flexibility

An often returning discussion with my clients is the practical applicability, boundaries, and presumptions of enterprise architecture (EA) frameworks. Following a recent debate on LinkedIn, some EA practitioners suggest that dynamic systems models, such as Stafford Beer’s Viable Systems Model (VSM) (Beer, 1994) , should actually replace existing prescriptive framework practices. In my own thesis (Jensen, 2010), I furthermore discuss the options of integrating cybernetic and second order systemic models in enterprise architecture planning and management on the basis of a thorough analysis of Australian government EA and SOA practice.

However, in this debate, it is important not to frame systems thinking as the silver bullet, which can magically and immediately fix all problems of management practice, be it process management or government architecture planning. Systemic thinking in itself may, actually, be overly prescriptive through reductionist assertions of how organisations function, e.g. through the claim: “organisations are systems” as opposed to “organisations behave as systems in particular situations.” Assuming that the world consists of systems as an ontological pre-given only paves the way for yet another prescriptive theory.

I usually tell my clients that there are two key observations around healthy framework and methodology practice. This basically boils down to admitting the following two claims:
  1. Best practice frameworks and reference models provide a great starting point and rational structure for beginning an architecture endeavour. Obviously, you don’t need to reinvent the wheel, and the frameworks provide a common language and conceptual platform for sharing ideas and implementing projects. Any good framework provides the tools, templates, and management structure for relatively quickly deploying the skeleton of an architecture practice. Prescription gives guidance, direction, and shared understanding of EA purpose and planning.
  2. However, prescription may also heavily limit the creativity and flexibility of rapid transformation projects. EA is often put in place in order to rapidly change the organisation for the better — or what Hjort-Madsen (2008) calls architecting for better outcomes. If the method is too inflexible or does not allow people to make shortcuts and rapid improvements for the better, it is a sign of too heavy prescription. Architecture turns into a handicap as opposed to providing a viable management reporting function. Architecture has transformed into a heavy-weight documentation exercise producing massive stacks of documents that nobody will ever return to again.
Good framework practice comes from finding the right balance between structure and flexibility. The framework must guide, direct, and support the architects at work so they can share and reuse where possible. On the other hand, the framework should promote and highlight the appropriate degree of managerial buffer in order to easily overcome problems and churn out creative solutions as opposed to locking down framework users by applying layers of managerial review and approval bureaucracy for the sake of (often unnecessary) traceability. As my thesis research indicates, an Australian state government agency chose to temporarily ignore their EA modelling and documentation framework whilst transitioning from current to future state.  Technological, political, and managerial changes occurred so often that the existing reference framework was simply too prescriptive. After reaching a point of reasonable stability in terms of business requirements and change in demand, it was then feasible to return to the structural stability and rigour of the framework.

My key message is therefore: be careful when implementing your architecture practice in your organisation. Your people need structure and guidance but also flexibility and buffer for overcoming changes rapidly in an elegant fashion.

Beer, S. (1994). Brain of the Firm (Classic Beer Series). Wiley.

Hjort-Madsen, K. (2009), Architecting Government: Understanding Enterprise Architecture

Adoption in the Public Sector, Phd doctorate.