Article: “Enterprise engineering and management at the crossroads”
Published in: Computers in Industry
Available online: 12 August 2015. In Press

Authors

Peter Bernus ^a, Ted Goranson ^b, John Gøtze ^c, Anders Jensen-Waud ^d, Hadi Kandjani ^e,s, Arturo Molina ^f, Ovidiu Noran ^a, Ricardo J. Rabelo ^g, David Romero ^f,a, Pallab Saha ^h, Pat Turner ^i,a

a IIIS Centre for Enterprise Architecture Research and Management, Griffith University, Australia
b Sirius-Beta, Norfolk, VA, United States
c IT University of Copenhagen, Denmark
d Strategy& (formerly Booz & Company), Sydney, Australia
e Department of IT Management, Shahid Beheshti University, Tehran, Iran
f Tecnológico de Monterrey, Mexico
g Department of Automation and Systems Engineering, Federal University of Santa Catarina, Florianopolis, Brazil
h Wipro Academy of Enterprise Architecture, Wipro Ltd., Bangalore, India
i ASPL Pty Ltd, Australia

---

Keywords

• Enterprise Information Systems;
• Enterprise Architecture;
• Complexity management;
• Sustainability;
• Viability;
• Situation theory

---

1. Introduction: Enterprise Architecture and Enterprise Information Systems

The past forty years have seen the emergence of the field of Enterprise Architecture (EA), originating in the management, engineering and information systems disciplines, due to the need to create enterprise integration, whereupon the enterprise is considered an information and material processing system (or system of systems to be precise) interacting with its environment, through a permeable boundary. The meaning of the enterprise’s activities arises from its interactions in an economic, political, and social context, together providing a complete picture of the enterprise in question.

In manufacturing engineering circles the idea that the information and material flow of the enterprise as a whole should be engineered surfaced, and the term ‘enterprise engineering’ was coined [1] and [2]. According to Kosanke et al. [3] enterprise engineering is “an enterprise life-cycle oriented discipline for [the] identification, design, and implementation of enterprises and their continuous evolution”: supported by enterprise modelling, the enterprise should have all information necessary to design and redesign itself, and create/maintain an integrated information and material flow.

At the same time in information systems (IS) circles Spewak and Zachman introduced the term Enterprise Architecture [4], arguing that a coherent multi-aspect model of the enterprise is necessary, and by today this second term subsumed the first.

The analogy to engineering (e.g., software and systems engineering) and architecture has limitations because the enterprise and its environment include humans, other living entities, and technology (natural and artificial systems). The enterprise is a complex socio-technical-ecological system of systems, and to model the enterprise from any one of these aspects is useful/necessary for answering particular stakeholder concerns at a given point in time, but with the understanding that modelling described only a partial or limited view of the interactions within the enterprise, and with its environment.

The Information System (IS) is a view of the enterprise that sees it as an information processing system that includes humans and various information processing and communication technologies. This view is typically built using multiple models, representing the information, related information processing functions and processes, and the resources involved, e.g., models of the system in time and on various abstraction levels of its life-cycle.

Enterprise Integration intends to establish an IS which ensures that information is available in the right place at the right time, in the right quality and quantity, for the right consumers, so that the enterprise as a system can perform its functions. The technology-implemented part of the IS of the enterprise is what literature calls the Enterprise Information System (EIS). The term normally refers to integrated systems that support the entire enterprise, and include ERP modules, decision support (business intelligence, data mining, etc.), integrated databases, business process integration, supply chain management and customer relationship management. The various software modules of an EIS must support the interoperability among various functional areas within the enterprise as well as inter-enterprise integration throughout the supply chain [5].

The definition of the information system does not assume that the IS was in its entirety designed at any one time or by anyone: a system may appear to have a deliberately designed IS when viewed by an external observer, but there is no presumption that this is actually the case. While this statement may sound false to information and communication technology (ICT) practitioners, typically a large part of the IS is human-implemented, and the enterprise as a whole is not necessarily completely or even partially aware of its IS, so management cannot always rely on reasoned decisions.

The intended scope of Enterprise Architecture (EA) and of the Information System (IS) of the enterprise is this broad and complete view of the organisation. However, as EA evolved in the commercial setting, this original objective of a complete or broad view of the enterprise has typically been limited to include only the Enterprise ICT Systems Architecture (or EIS Architecture), i.e., the technical components of the IS, although often the consideration of capabilities, business processes and workflows are also included in practical EA projects under the name of ‘Business Architecture’. Consequently the current arsenal of tools and methodologies for EA are developed more for the creation of the EIS.

These considerations are important because, somewhere along the way, the original aim to complete and produce a comprehensive holistic view of the enterprise in all of its complexity and inter-relationships seems to have been lost, partly because the industry’s resistance to include enterprise architecture practice in dealing with real business problems or priorities.

This paper attempts to describe the apparent gap between such a holistic view and the current practitioners’ views, theories, models and methods, and to propose a research agenda response that identifies and restores the original lost elements of the intended scope of EA, and where (as opposed to the prevalent terminology) the EIS would be called EIS because it is the IS of the enterprise (including human implemented parts).

In the remainder of this article the terms ‘enterprise architecture’, ‘enterprise model’, enterprise modelling tool’, ‘enterprise engineering methodology’, ‘life cycle’, ‘life history’, ‘modelling framework’, ‘meta-model’, etc. follow the terminology of ISO15704[6] and [7]/GERAM [8], [9] and [10] and ISO42010 [11].

2. Grand challenges

2.1. The challenge of scope

As it was pointed out in Section 1, there is a gap between the originally intended scope and present day scope of EA practice. The scope of EA is not necessarily one single enterprise, but any socio-technical system. For example, EA practice has been successfully applied to design networks of enterprises, virtual organisations, government transformation, etc., and the same can be applied to entire industries, or government.

Even though EA can be considered the systems science of enterprise, it is necessary to demonstrate how EA’s systems thinking approach can be applied in a multi-disciplinary setting. To achieve this, EA frameworks need to be populated with relevant business-, economic-, social- and ecological viewpoints so as to be able to represent respective concerns of stakeholders, which is a pre-requisite for being able to analyse cross-disciplinary effects in large scale systems, to facilitate problem solving and decision making.

In a systemic perspective, the ability to synthesise seemingly divergent perspectives into a coherent whole is an imperative. This is why efforts have been made to propose an agenda for EA to (a) harmonise decision making across management levels and roles called ‘alignment’ [12] and [13], and (b) apply systems thinking to understand and make use of the systemic effects that make the enterprise a system of systems [14] and [15].

A crucial aspect of the discipline’s future is the discipline’s own viability. In order to remain relevant and adequately respond to challenges of the area, the EA discipline must evolve[16], and possibly undergo a radical development: over the past decade, the disciplinary scope of EA has indeed widened significantly [17].

When a large number of the dilemmas that enterprises face can be formulated in the relationship of the enterprise as an economic entity to social systems and to the environment, it is clear that EA as a systems science of the enterprise must evolve to be able to represent, analyse and provide decision support for strategy making, planning, design and orchestration of changes to this multi-layered reality.

In 2012, the US Federal Government defined enterprise architecture as “the management best practice which can provide a consistent view across all program and service areas to support planning and decision making” [18].

In addition to strategic planning and environmental positioning, which links EA to its macro and micro environment, EA also needs to build a systemic picture of the internal structures and mechanisms inside the enterprise. These are required in order to strategize effectively and model the required business capabilities. Those internal structures and mechanisms are dictated by organisational socio-politics and by communication styles [19].

The underlying framework for socio-politics and communications adds an entirely different dimension to enterprise modelling. Whereas traditional capability models [20]build binary models (capabilities in business domains modelled as boxes within boxes), communication and socio-politics rely on rhizomatic [21] complexity models, which are constantly changing, shifting, and transforming. Essentially rhizomatic models of the enterprise represent complex reality as a rich and continuously renewing network of (non-hierarchical) connections and influences, that are a source of emerging properties and the evolution of the complex entity itself. Accordingly, in building a comprehensive, holistic systemic model of the enterprise one needs to add a whole new layer of analysis, using the most appropriate enterprise models.

As pointed out in the Introduction, many EA programs and practices in the past were limited in scope to EIS, but it is now timely for the EA community to return to the origins, and complete the original intended scope that was always at the heart of the search for a holistic view of the enterprise [6] and [7]. This quest for a fully integrated holistic view is by its very definition at the core, and is fundamental to the purpose of the EA discipline, and critical if our successful EA practice model is to gain acceptance as relevant and valuable in the boardroom. A recent white paper of the Federation of EA Professional Organisations is also supporting this view [22]; and a similar conclusion was drawn by Bernus et al. [23], outlining the origins of EA and its recent development.

Explicit and holistic modelling is needed to support the understanding of system-wide interactions among subsystems in the enterprise as a system of systems, because many relevant properties and behaviours are emergent on the system-as-a-whole level. Thus in enterprise modelling we need to maintain the completeness of the models in terms of scope, without being limited to a component of the enterprise as a system of interest, while the level of detail and the viewpoint of modelling may change according to stakeholder concerns.

It is often very difficult to create explicit models that reflect the true state of the enterprise, because the enterprise as a system is in constant change. There are several options to overcome this difficulty: (1) maintaining live models (like in the newly emerging adaptive flight control systems [24]), (2) ‘design-out’ the need for decision support models that depend on too fast changing system parameters, (3) create a hierarchical control structure redefining what is the ‘system of interest’ for each decision maker, or (4) heterarchical control [25], where decision making is based on local systems purposefully forming relationships with other systems, and there is no need for an explicit system of systems level control. In these latter systems the burden is on the designer of the rules of interaction to prove that desirable system of systems level behaviours will emerge.

An agenda for the extension or adjustment of the scope of Enterprise Modelling is further discussed in Section 3.

2.2. The challenge of scale and complexity

The need to create integrated EIS steadily grew from the control of small scale systems (equipment, factory floor, retail shop) to having to address the management of complete, dynamic supply chains, and more recently the needs of large multinational corporations, governments, international alliances and global geopolitical processes. There were two interrelated needs: (1) the need for management to understand the system (its structure, its behaviour) and to create shared understanding among stakeholders, and (2) the need for being able to manage and control such complex systems. Today’s challenge is that the system scale to be understood not only includes large geographical areas, but the scope extends beyond the economic environment to related social and ecological systems, with which enterprises interact.

The increase in scale (scope, size, space and time) brings about a need for paradigm change, because the theories, models, tools, and the expectations of what they can deliver will necessarily change. The reasons for this change can be characterised by looking at the assumptions that are typically true of smaller scale systems, but no longer hold on the larger scale.

Traditionally the management and control of ‘smaller scale’ systems has been the area of control engineering, systems engineering, industrial engineering, operations research, and associated real time or operational management & control (henceforth we shall sometimes use ‘control’ as an abbreviation of these two). At the same time, the larger scale system perspective has been studied by management science, political science, economics, systems science and cybernetics, and complexity management by enterprise architecture [14].

For the management of smaller scale systems it is customary to assume that there exists a controller, and that this controller uses either continuous or discrete models of the system for decision making, with the view of achieving some control objective.

Traditional feedback control systems do not contain an explicitly identifiable model aspart of the controller; the explicit model of the system is only used by the designer of the controller. However, for the control of complex systems, the use of Model Predictive Control (MPC) has steadily grown in popularity, and is a very active research area [26],[27] and [28]: in MPC the controller contains an explicit model of the system.

When looking at the control hierarchy of real-time, operational, tactical and strategic horizons [29], [30] and [31], one can see a gradual transition from ‘control’ to ‘management’. Whether for control systems design, or as a control system component, management and control engineering and related fields have been using increasingly sophisticated models and algorithms to solve the control problem – with the practical application (in plant control, traffic management, economic and, environmental management, etc.) relying on the availability of digital computers.

All of the above approaches require that the model used by the controller should be sufficient for making predictions about what the system’s output will be, given the state of the system (often including the system’s history), and the interaction with the environment in which the system is situated (i.e., the inputs from the environment and from the controller). The objective of control may vary, from trying to achieve an optimal system state, to producing a desired output, or stabilising the system’s state.

Below is a list of assumptions that do not scale with system size, with the length of the time horizon of control, and with system scope:

• The system can be completely described by a model (e.g., in form of continuous nonlinear differential equations, or in form of discrete, deterministic or stochastic difference equations, or as discrete event system), so as to explain and predict system behaviour. This assumption does not hold in the case of complex non-linear systems, where usually only partial or inexact information is available about the system and its environment, and the assumption practically never holds on horizons longer than operational control.
• The system can be described using one type of model. For ‘systems of systems’, this is usually not valid, because of the heterogeneous nature of the involved systems. In such cases management and control needs to use and integrate the predictions of multiple types of models. A typical occurrence of this situation can be found in environmental management [32] and [33], whereupon multiple models must be created to describe the relevant behaviour of the interconnected systems (e.g., difference equations for population dynamics of fish, differential equations for hydrodynamic models of river and ground water flow, neural networks for rainfall modelling, and Bayesian models for predicting the outcomes of decisions for fisheries management).
• The system is identifiable: i.e., the model’s underlying parameters (even though not directly accessible for measurement) can be determined based on observed values of measurable variables. In large scale systems this condition must be relaxed, even though under certain circumstances the control objective is still achievable. E.g., robust control takes into account that the estimated nominal model parameters may be slightly different from their real values; adaptive control can observe the time dependence of system parameters and adjust the control algorithms accordingly, etc.
• The system is observable. In case the system state cannot be obtained by direct measurements, it is still possible to distinguish between any two (relevant) states using measurements by applying stimuli and observing outputs of the system.
• The system is controllable, i.e., based on observations of (or experimentation with) the system one can build a model (either for controller design, or for use by the controller) that allows the system to be controlled so as to assume a desired state and/or produce a desired output (state controllability and/or output controllability). An example of output controllability is when only aggregate system states matter for the control objective, i.e., the controller may be unable to manage invisible internal states of the system (or to control internal system dynamics), but it can still achieve a desired system output. Many variations to this partial controllability exist in control theory, and accordingly a wide range of control algorithms [34]. However, it is a well-known fact [35] that large scale non-linear systems are capable of chaotic behaviour in certain regions of their state space, and in the vicinity of these subspaces it is not possible to make reliable predictions about the system’s exact future trajectory, thus the system may not be fully controllable.

Complex large scale systems have been studied in several disciplines (management science, AI, systems science, cybernetics, and economics), and a number of theories were developed, attempting to describe the evolution of complex systems – whether this evolution is fully or partially managed, or is emergent. Some disciplines may use different terminology, but have analogous concepts, and discovered the same limitations as control theory and/or cybernetics did [36].

Partial unpredictability and uncertainty of knowledge about the system has even been used to phenomenologically define the concept of a complex system [37] and [38]. Conversely, several complexity measures are defined in the literature; some of these can be calculated and be used to indicate system unpredictability and uncertainty. Lloyd [39]categorised these as measures characterising the difficulty to (i) completely describe the function or behaviour of the system, (ii) describe the system’s architecture (how structure implements function), and (iii) create the system (this interpretation of Lloyd’s categories is due to [40]).

The grand challenge in this context is how to develop an interdisciplinary theory of managing complex systems, with specific theories of control engineering, management science, cybernetics, AI, etc. being special cases of this general theory. Such theory could be used to create new application-specific methods, tools, techniques and models that scale with scope, time horizon and system size, while also identifying theoretical limitations to management and control objectives. Regardless of the form of this theory, a satisfactory solution to this challenge must demonstrate (i) how to understand and live with complexity, and/or (ii) how to reduce system complexity or otherwise resolve the issues created by it.

2.2.1. Live with complexity

One solution is to develop theories, computational techniques, algorithms, sensors, and modelling tools that improve the predictive powers of the controller in the sub-space of the environment in which the system operates.

Alternatively, one could aim at designing reference architectures (new architectural solutions and methods to design and build systems) that require less knowledge of the system by the controller, e.g., the control objectives may be achieved by the system through a combination of deliberate and emergent control.

If neither of the above is feasible, and the system is not controllable to the extent stakeholders wish, then one must re-think the control objective. This requires a change of attitude: we give up the goal to achieve an exactly defined outcome (a defined system state or system output); instead, the goal could be to ensure that all eventual outcomes are acceptable according to some criteria. For example, there can be several scenarios to save the solvency of a business, and many actions can be taken to achieve this. However, some actions will only possibly, but necessarily, achieve the goal. Given an action, it would be impossible to predict all possible future states of the business, but forsome actions we might be able to predict that all possible future resulting states share the fact that the business is solvent: therefore the desired situation is achieved, even though many other facts about the future of the business (the future state) remain unpredictable.

This change is fundamental, because it requires a change to the value system of the system’s stakeholders: they may have to give up previously held economic or social values and agree on new ones. The variants of this change in objectives is linked to Sustainability and Viability (as the only way to achieve a sustainable future might be to change currently implicit values that make us chase unrealistic economic or social outcomes). Threats to the world economy, global and local ecology, and the social system might only be averted if we find solutions to this challenge, a solution with social, political and technical dimensions, as exemplified by the ecological decision making debate around climate change adaptation [41].

An interesting aspect of the above is that the associated change process can itself be abstracted into a change system (of systems), performing a coordinated, managed and controlled set of transformation activities. This system may be emergent (self-evolve), or be deliberately created, as an economic, political, social, and technological transformational programme, with local and global, short-, medium- and long term projects. We must try to find a minimal set of actions that foster the self-evolution of such a change system, because the complexity of deliberately creating this system may be beyond our capability and capacity.

Based on this recursive view, the change system itself is a complex system, with the same problems as described above. Accordingly, an interdisciplinary theory of change systems is needed, enabling management and control methods that accommodate the partial unpredictability of the change system.

While trying to develop new techniques for better control of complex systems, we should consider the other option: to reduce complexity by design.

2.2.2. Reduce complexity by design

Complexity will never be completely eliminated, but a number of design methods exist to avoid unnecessary system complexity. Methods can be based on the use of tried and tested partial models, reference architectures, or design patterns, known to have qualities so that systems designed based on these models in a modular way tend to naturally have minimal (or quasi-minimal) complexity. Other design methods are codified as application-specific design principles (e.g., for software design, manufacturing systems design, etc.), or as generic design principles expressed as axioms, such as in Axiomatic Design [37].

When we talk about reducing complexity, we differentiate between the complexity of a system that an external observer must see to completely explain the behaviour of the system on any level of detail, and the apparent complexity that any one agent (a controller/manager within the system) must see (by way of model views in a hierarchy of models) in order to carry their role. Apparent complexity is the complexity of the view of the system used by the agent to be able to satisfy control objectives. For example, in hierarchical control no controlling agent needs to possess a model of the entire system: each lower level area controller has private control objectives (and coordination with the overall system-wide objective) [42], and in distributed control a central controller may not even exist.

The co-ordination among levels of control assumes that details of lower level system dynamics can be hidden by some mechanism: e.g., only aggregate states of the system’s state space have to be observed by a higher level controller. The concept is analogous to macro-states in statistical physics, or those discussed in Cognitive Science [43],[44] and [45].

This discussion clarifies the requirement originally formulated by Ashby [46] as the ‘Law of Requisite Variety’ stating that the controller must have a model of the system that has at least as much variety as the system has states; this is true, but to clarify we specify: ‘… as the system has relevant states’. This is similar to the relativity of entropy, namely that a system’s entropy also depends on the set of macrovariables we care to observe ( [47], p. 26).

Given that system complexity is relative to the control objectives, what matters is the system’s apparent complexity, not an intrinsic complexity measure, assuming that a system of systems has mechanisms to coordinate the control objectives among multiple levels (possibly without a central authority, where intentionality is an emergent property resulting from subsystem interactions).

The challenge is to find architectural solutions to this problem: e.g., holonic systems [48], fractal structures [49], and the Viable System Model [50] and [51] describe the desired abstract structural properties of such systems, but we have little experience in building them on a large scale.

2.3. The challenge of maintaining sustainability and viability

The escalation of the scope of what we call ‘enterprise’, and of the corresponding IS, has reached a point where ‘enterprise’ is considered to be all forms of human undertaking, situated in the social, economic and ecological environment. In addition to the problems of system complexity, this situation poses macro-level constraints on the management and control of socio-technical systems, due to the limited resources of the world.

Sustainability may be defined as the way for humans (economy and society) to co-exist with Nature [52]. However, the concept can be used in the general as the ability to keep on performing some activity, or to maintain some desired characteristics of a system of systems.

Viability is a closely related concept, and looks at how the continued life of a system of systems can be assured, allowing the system to maintain some form of homeostasis in a volatile environment. The concept was investigated in detail by researchers of cybernetics – Stafford Beer even coined the term ‘management cybernetics’, as cited by Rosenhead [53].

In our definition viability is not the same as sustainability: a system may be viable, without having to sustain any of its current activities. It is precisely because the ability to redefine itself, a firm may decide, in order to remain viable, to only sustain some of its current operations, abandon some, and introduce others (e.g., change from a manufacturer to a service provider). The economic activity (profit making) is sustained, but the concrete activities may change. This dynamic capability of firms is at the heart of viability [54].

A sustainable and viable system must either be aware of its own destiny (deliberately direct its future), or appear to be doing so. The ultimate challenge is the creation ofconsciousness in large scale systems, and through this to create the aware socio-technical system.

Beer’s Brain of the Firm (1972) explained the need for a viable system to have twofeedback loops: one that is stabilising the system in its present environment, and one that is ensuring that this will also be possible in the future.

We do have well understood reference models for building systems that are sustainable and viable: the Viable System Model (VSM) by Beer [55], and the alternative and equivalent reference model, the GRAI Grid [30] and [31]. However, there is a significant missing component: the main building block of the management of viable systems is the model of the system and of its environment, to be used to make predictions regarding changes in the environment and changes in the system itself. Therefore, whilst VSM is a useful reference model, the mechanisms to implement and maintain such models pose a challenge. It is expected, for example, that for each type of system and level of control a potentially different kind of model and control strategy will be necessary.

For systems such as large chemical plants, for example, it is possible to collect large amount of information so that one can use techniques, such as developed by control theory for system identification, resulting in adequate model parameter estimation [26],[56] and [57]. As system scale grows, information gathering opportunities decrease, and information about the system and its environment becomes sparse, consequently the validation of the model used for control decision making is running into difficulties.

This is a typical situation in environmental modelling and management: the most successful environmental models used for decision making are limiting themselves to local management issues on smaller system scales, and global environmental modelling is still grappling with the problem of validation [58].

If we are unable to live with the complexity of the system (e.g., our inability to solve the control problem poses a significant risk), and complexity reduction does not work either (because we need a complex structure in order to achieve the desired system function), then a third possibility is to try to find an architectural change that makes the system controllable. This is the task of the so called ‘system 4 and system <!– no-mfc –>5’<!–/no-mfc –> in the VSM, (the strategic level decision centres in the GRAI Grid). For example, an architectural proposal to address the unsustainability of the current industrial system is described as the ‘Green Virtual Enterprise’ [59], [60] and [61].

2.4. The challenge of finding survival modes

A ‘survival mode’ is defined here as the set of beliefs (values and principles) that express what and why needs to survive? Perhaps these beliefs need to be re-thought before trying to find solutions that are consistent with our current set of beliefs.

For example, one set of beliefs may stipulate that a given industry should survive in a geographical area. This is consistent with some companies of that industry being created, others becoming merged, being acquired, or ceasing to exist, as long as the production of the type of goods of that industry survives in the geographic area.

A different set of beliefs may stipulate that the area must remain at the forefront of knowledge creation, and use knowledge assets to competitively produce value. The survival of companies or given particular industry is not a necessity according to these beliefs, but the ability to create knowledge and use it for producing value survives.

The idea that enterprises need to survive indefinitely runs against all historical trends, and is contrary to the mode of survival that we observe in nature: one must consider alternatives that do not contradict this long term experience.

An enterprise has a state space that it can occupy in the environment, and this space is determined by the architecture of the enterprise as a system (the term ‘architecture’ here means the way the structure of interacting elements of the system implements the system’s function). Part of the architecture is static (always present), but part of it is dynamically created as needed, so as the system can respond to the environment’s requests. Most non-trivial systems have such dynamically created temporary structures (sometimes called ‘configurations’) necessary to perform the system’s function.

The dynamic structure may be brought about by deliberate management and control, or may be emergent, and the structure can be decommissioned, thus when the enterprise is in homeostasis, internally it consists of dynamically changing components (created, modified, and eventually destroyed) – in the same way General Systems Theory [62]described complex biological systems.

The static architecture of a system (theoretically speaking) determines the set of structures (dynamic configurations) that the system is capable of assuming, and through that the set of states the system can reach.

In large scale systems the calculation of all possible future system states would be computationally challenging (or impossible due to model uncertainty), but this does not have to preclude us from reasoning about the characteristics of such future states.

To achieve this we must develop theories and methods, allowing us to build EIS that can help management reason about system trajectories and states by relying on partial information about the system and its environment. The promise of such results is that they could bridge the disconnect between micro level management (of individual enterprises) and macro level management (of industries, economies, etc.).

Another important question for long term strategy making is: what are the architectures that maximise the set of all possible reachable states? After all, the larger this set, the less the enterprise is likely to be experiencing turbulence in the environment, and be able to survive longer. Dynamically created organisational structures have been researched for decades: Virtual Organisations [63], Enterprise Networks [64], and Virtual Breeding Environments [65], and several successful implemented examples exist [66]. The conditions to successfully manage dynamic enterprise structures are non-trivial, opening up challenges for Enterprise Information Systems, in terms of the development of feasible reference models, enterprise engineering tools, and optimisation methods. Enterprises have multi-level structures, and certain behaviours are impossible to understand in the evolution of complex systems if the linkages between these levels are not perceived correctly [67].

A possibly fruitful research area would be to design and experiment with various business reference models in which the enterprise is an evolving system in dynamic equilibrium, like an organism that survives, although its constituents have shorter life cycles. Such models would explain the enterprise as a dynamic entity and make the necessary mechanisms explicit, such as ‘periodic restart’ or ‘periodic re-creation’ of constituents with the aim of shedding excess complexity.

The theory and practice of dynamic networks and virtual organisations (VOs) is an underutilised area of EA, and has great potential for a number of industries. Networks can be the mediators between the stable and the ephemeral, creating VOs on demand, reducing the need for long term maintenance of organisations, and reducing the path dependency [68] constraints on organisational development.

As a consequence (as detailed below), EISs must be extended to support dynamic enterprise engineering and business optimisation. In the past, enterprise engineering tools and operational tools were separated, but in the future, the two must be closely integrated: enterprise engineering/enterprise modelling tools should be part of the EIS.

In modern EA projects, important enablers of building a dynamic IT architecture include Cloud Computing, Service Orientation and Business Process Management Systems. Grounded on the Service Oriented Computing principle (and associated reference models or architectural ‘blueprints’), software and ICT infrastructures started to be made available as a remotely accessed service paid-per-use, instead of being locally acquired under the classical software acquisition model, deployed and owned as monolithic large packages of software operated and managed by the corporate data centre [69].

In businesses that have a mature EA environment the organisation of software modules as loosely coupled services goes hand in hand with the use of business processes management systems (BPMS). BPMS have increasingly been used to support business processes design, analysis, execution and monitoring. In such an environment business process evolution, and in general process improvement, can be informed by various tools, e.g., process monitoring and process mining [70].

Another advancement in architecture dynamics can be observed in the history of development of SOA (Service Oriented Architecture). SOA has gradually been adopted as an approach to interface IT applications (the IT layer) to business processes (the business layer) [71].

The traditional use of SOA connects business processes to services of internal or external resources (mostly implemented as web services) in a static way, whereupon the connection is decided (bound) at design time. As opposed to this, in state-of-the-art environments, service-binding can be carried out dynamically. In this scenario, services are discovered, selected and bound in a dynamic fashion (using defined policies and principles, and criteria, like costs, SLA (Service Level Agreement), functional and non-functional requirements, service quality, provider reputation, etc.).

This means that business processes are bound to the most suitable services for any given execution based on the context of the given process instance [72]. This implies that such services may best be provided by an ecosystems of disparate software providers, with services dynamically and seamlessly be plugged-into and plugged-out of the corporate’s IT architecture, and all this while business processes are executed [73]. This can impact on the relationship between technology providers and technology users, and is against the tendency of providers to create user lock-in. Due to this architectural dynamics new challenges arise, in terms of interoperability, security, systems performance, resilience, SLA management, taxation models, provider-management, and IT architecture management [74].

We now have technical ability to serve the needs of dynamic supply chains, networks, and virtual organisations, but this is not sufficient, because a consequential issue arises on the level of governance. In these application domains enterprises operate on diverse levels of partnerships, in which they share a range of assets and information, as well as execute intra- and inter-organisational business processes. In these cases the actors are independent enterprises and have their own business strategies, which situation creates a complex and intrinsically conflicting management environment. Therefore, it is of extreme importance to develop and adopt appropriate governance principles, rules, processes and organisational forms that can operate in a way that minimises conflicts among partners and mitigates the risks of unsuccessful business process execution.

Governance in networked enterprises is “the specification of rules, criteria for decision-making, responsibilities, and boundaries of actions and autonomy for the involved actors”[75], created by the involved organisations to regulate their partnership: “the fundamental role of governance is not managing, but to delimit the management instead. Actors can use their knowledge within the defined governance framework in a way to help organisations to best reach their common goals” [75]. The rationale is that the market and power of partners influence directly the way a network should execute and manage its processes and all related information, and hence on how the network should be internally organised to respond correctly and efficiently.

This means that the involved enterprises have different roles throughout the business processes’ life cycles and associated decision making processes, and that every business requires a particular governance model [76]. From the EIS point of view, the access (by any partner) to information related to any single process’s transaction should respect the governance model, which was defined for the joint business in which the partner enterprises are currently involved. This again demands from the system’s architecture a very high level of flexibility and efficiency to support the dynamics of the enterprise’s relations, information integration and information exchange ability.

In enterprises that have high EA capability and maturity there is no separate ‘EA strategy’ and ‘EIS strategy’: there is a management strategy that EA principles inform, and EA practice executes it in a coordinated and coherent way, orchestrating the transformation of the IT-, human organisational- and other subsystems, ensuring uniform application of transformational and design principles.

Structuring a system of systems to maintain coherency needs adherence to design principles understood, accepted and enforced on the highest levels. For example, simply implementing an enterprise service bus and business process management modules has no guarantee that the EIS built using SOA technologies will create a flexible, adaptable or agile enterprise. For these benefits to be realised one must use design principles and techniques that clean the functional profiles of IT subsystems, clean the underlying data definitions, and aggregate the right functions with the right data, to form reusable services isolated from the rest of the IT system, only communicating via ‘trunk routes’ established for that purpose.

The metaphor of urbanisation [77] has been used to develop practical EA methods for this purpose: just as in town planning there are essential principles and rules to enforce, appropriate approvals are to be obtained, the same is true of EISs. This includes the acceptance of certain standards (such as functional and information models shared across entire industries), ensuring interoperability of systems on essential interfaces, rationalisation and reusability, low coupling among modules, and high internal cohesion within.

2.5. Summary of challenges

Enterprise Information Systems are the technological implementations of the integrated information system of enterprises, and of socio-technical systems far beyond single organisations. The article discussed major dilemmas, fundamentally changing the manoeuvring space and aspirational opportunities for management, be it the leaders of enterprises, industries or governments: the problems originate from outside of the EIS, and pose new requirements on a new generation supporting EISs.

The challenge of scope is a result of the changed goals that the enterprise architect, and within that the information systems architect, and further the EIS architect must support. The scale and complexity of socio-technical systems of systems poses limitations, which ‘trickle down’ form the business to EA, from EA to IS, and from IS to EIS, and any long term EIS solution must be set in this context.

One particular concern of leaders is to maintain the viability of economies (and the embedding social and ecological environment) in a sustainable manner. This will inevitably result in changes in current business models, and the architectural setup of companies, social institutions, financial systems, communications systems, etc., with ensuing need for new types of EISs. The challenge was framed in this Section as the quest for finding reference models of sustainable and viable systems: it is then the task of architects to devise ways to implement the technology support for these.

Finally, we expressed a socio-economic, political (including geopolitical) and ethical dilemma, questioning the meaning of survival (what needs to be viable, what must be sustained). There seems to exist a slow trend to redefine the value system of society, and new models of survival will no doubt emerge in the long term. We question, although have no answers, as to what will be the socio-technical systems of the future? – the information revolution will play central part in this and open yet unknown doors for the use of computer based information systems, into the ‘bionic society’, such a creating higher level consciousness. This might only happen in hundreds of years, but the intellectual challenge is there.

3. State of the art

In this section we overview developments that contribute, or have potential to contribute, to the solution of the challenges described in Section 2. Fig. 1 summarises these relationships; as it can be seen this relationship is N:M, not 1:1, namely to address the challenges, multiple developments are necessary on several fronts. E.g., to solve the challenges of scale and complexity, both the systems science approach, including modern soft systems theories and methods (Section 3.4), and hard computational results would likely be necessary (Section 3.6).

 

3.1. Discipline development

EA as a discipline can be considered a fusion of engineering (control engineering, industrial engineering, systems engineering, software engineering, ICT, information systems, manufacturing technology, etc.), and management. However, as most of these disciplines address some aspects of enterprise change/evolution, they may view EA as part of them. EA has to be an interdisciplinary study of the enterprise as a complex socio-technical system, covering all aspects (human and technical), and all types of evolution (deliberate and emerging), therefore EA intends to unify all knowledge necessary for deliberate and emergent change in the enterprise [16].

To fulfil this mandate, the two major tasks for the evolving discipline of EA are to:

(1)

Help harmonise and integrate the knowledge of contributing disciplines, and

(2)

Disseminate this understanding.

3.2. Frameworks

The evolution of EA has produced several concepts and theories, codified in standards and frameworks, terminology, meta-models and ontologies, reference models, and methodologies (and some are incorporated in enterprise modelling tools as well).

Framework development is an important part of achieving task 1 (above), because the interpretation in a common language of the contributions of underlying disciplines relies on the existence of such language. This ‘language development’ is a never ending task, as underlying disciplines evolve, therefore it is expected to continue as the underlying disciplines necessitate.

EA has not been entirely successful in translating back its interdisciplinary results into the language of the contributing disciplines (task 2). This translation is vital, or these disciplines will bypass EA’s results and create very independent outcomes, and miss out on EA’s harmonising effect.

EA researchers have important duties to (a) monitor and discover problems of practice and how individual disciplines address these, (b) translate the results into a common language, and (c) be actively involved in creating solutions. The aim is to transfer knowledge across discipline boundaries, providing opportunities for the development of interdisciplinary theories.

A further important task of EA is to help manage the complexity of the enterprise’s evolution. However, while attempting to address this problem, the EA body of knowledge itself is becoming increasingly complex. The call for ‘light weight EA frameworks’ is a testimony of this feeling in the EA community [15]. It is time for EA to address this issue by applying its own complexity reduction and management techniques to the EA body of knowledge itself, otherwise the discipline’s results can become too complicated for them to be used by practitioners [16] and [78].

There is limited understanding in the EIS community of available EA frameworks and of their capabilities. This leads to an unnecessary proliferation of seemingly ‘new’ (but not necessarily better) frameworks. The academic and commercial interests of players are in conflict here.

Relevant ISO Standards exist: i.e., ISO15704 and ISO42010 (maintained and updated from time to time), and in addition there is a list of industry/government frameworks (TOGAF, Defence frameworks, proprietary frameworks of multiple consulting companies, government frameworks), and in addition, major organisations and governments adopt their own. Presumably one reason for such proliferation is that framework adoption is a form of constructivist organisational learning.

Some developments seem to be driven by commercial interest or power positions, where gains can be had through institutionalising a selected EA framework through governance. We believe that this is an unhealthy situation, management through enforcement rather than through leadership, and we call for an education-based approach.

A challenge to the EA community is to consider more carefully whether there really is a need to develop newer and newer frameworks (with the presumed novelty factor producing short term commercial gain), or to pay more attention to the evaluation of existing frameworks against standards, the harmonisation of these, incremental development, and to produce truly new framework-agnostic results instead, thereby focusing on a common set of agreed and understood outcomes (artefacts) rather than producing ever more specialised and diverse tool-sets and exotic but un-aligned non-standardised outputs.

We believe that the efforts to map existing frameworks and to evaluate them against the above standards should be renewed. This should make it clear what is actually new in framework development, and what is only a new veneer on an essentially unchanged underlying framework. Such mapping is also of use for keeping terminological clarity of the area.

Even partial results are of use: e.g., there exist current efforts underway to harmonise defence frameworks in use across NATO, and as part of this project to extend the way these treat the human/organisational element [79].

An important related question that comes from the definition of the scope of EA: who in the enterprise needs to have EA competency? Clearly, the skills and knowledge of EA as an integrating discipline should be an add-on for management on all levels. At the time of this writing, in practical applications, EA’s results are mostly being used in IT solution development, and only in some areas of business (networked enterprises). We believe that the EA and business management communities must break out of this artificially restricted scope.

The only way out of the restricted disciplinary scope seems to be to introduce EA knowledge and skills development across multiple disciplines through higher education and in professional development. Acquiring EA knowledge purely through ‘professional training’ is mostly specific to some chosen framework and can contribute to the division: it is desirable to learn EA in a framework-agnostic way. Once a base level of competency has been reached against a standardised agreed curriculum, practitioners can start to apply their own creativity and expression to improve and mature the discipline as a whole. This process of evolution within a defined scientific discipline or ‘paradigm shift’ is well documented in other scientific communities [16] and [80] but appears to be missing within the EA community at present.

When it comes to building an EA practice it is important to note that it should not necessarily be framework-centric, it is more the philosophy of EA as a systems science of socio-technical systems that needs to be shared across the enterprise.

3.3. Enterprise modelling

Enterprise Modelling has been for quite some time accepted as an important part of EA practice [81] and [82], and has been the central technique for integrated enterprise information systems design. The current practice of Enterprise Modelling is varied – today it mainly concentrates on process- and information modelling in industry, and usually there is not much modelling of the organisation.

Let us take the example of process modelling. One can observe an initial enthusiasm (business process reengineering) and an ensuing almost twenty years long push to create and implement explicit process models (and automate them as ‘workflows’). Unfortunately the area has not recognised its own limitations and is starting to create damage rather than business value [83].

The problem has to do with the (natural) desire of management to stay in control. What easier way could one find for control than treating humans as machines who merely process individual activities in a well-defined workflow?

The trouble is that workflows are procedures (like a computer program), and only a very small percentage of business processes are actually procedures ([84], p. 29). Most procedural processes can be found on the real time and operational level, and having well defined procedures, guarded by automated means, achieves consistency simply because there is no other way to perform the process. However, at the moment management starts expanding this controlled execution of processes to realms where the processes are non-procedural, thereby loosing efficiency, and sometimes effectiveness as well.

There are at least two major challenges: (a) forcing a procedure on humans may remove the creative input of the human and stop evolution and innovation, (b) workflows make the process always explicit, but they do so in form of a procedure, and thereby hinder the ability of the human to perform the process using tacit knowledge, which can introduce and institutionalise inefficiency (we know that efficient processes are performed in a tacit way, not by procedure-following). For example, in a high process-maturity organisation designers do not necessarily follow procedures: it is only for the external observer that they would seem to be doing so, and explicit procedure-based models may only serve the purposes of training, for example.

Using process models that are non-procedural can alleviate many of the problems caused by the restricted procedural interpretation of what a process is, provided appropriate modelling tools and process management systems support such a move.

Furthermore, procedures are only of help if most (or all) process instances can be abstracted into a single process model, thus the level of granularity and amount of procedural content are important qualities of process models. On a high level of granularity the process may be procedural, but on the low level non-procedural (or a mix of the above).

So where does this fairly damning view leave us regarding enterprise modelling in the process domain? The simple answer is that while we do have process modelling tools and languages (in everyday use by industrial engineers), so-called EA tools do not include these, and as a consequence a large percentage of EA projects do not even know them (IT engineers only use BPMN and workflow modelling languages, both being inadequate for analysing important properties of processes that business cares about, such as resource usage, development of queues, speed, cost, resource-sensitivity, various statistical properties of the process, etc.).

Methodology-wise practitioners do not normally have enough expertise [85] to know how to institutionalise processes on the right level of granularity and match these to the human capabilities at hand (or even better, do his adaptively, according to the variation of expertise and experience of the humans in the process).

There is a similar challenge in the area of information modelling as well. Early enterprise integration projects assumed that the more information is modelled and codified, the better. However, this ignored that (a) the information we use evolves, therefore if we need a model then that model also has to evolve together with the system – out-dated externalised models and poorly formalised models can do actual damage; (b) enterprises not only use structured information, therefore information that is available in a formalised manner must be able to be related to information that is not: in fact this is more and more appreciated due to the emergence of technologies that allow us to analyse and interpret written natural language.

The consequence of the above is that EA practitioners should adopt the models and viewpoints of systems engineering and industrial engineering, which is a very rich set of possible models, adjusted to the needs of the stakeholders.

When we look at the life cycle of an enterprise, (e.g., as defined in ISO 15704:2000), and the life cycle of any entity for that matter, we have to notice that enterprise modelling has really only been implemented thoroughly from the requirements level down (in fact only starting from requirements specification). The identification and concept levels of the life cycle have only been lightly addressed by the EA community [86], while models that belong to these levels, and are routinely used by management, are often not well integrated into the modelling frameworks used by EA practitioners (at best only a small subset is available).

A heritage of the so-called waterfall view of life cycle is that models that populate a modelling framework are often seen as being connected through a unidirectional process, from abstract to concrete. However, the relationship between life cycle activities is much better described a set of mutual constraints. Thus discovery and design decision making is an iterative problem solving activity, not a procedure, and this view should be supported by enterprise modelling tools.

Furthermore, an important aspect of enterprise models is that they can be used for communication among stakeholders and collaborative action, therefore meta-information about the role and status of each model in the design process (and the life history of the enterprise) is of crucial importance – an aspect of enterprise modelling that will need further development.

There is a comparatively poor coverage by enterprise modelling practice and associated tools of the identification and concept life cycle activities (basically the business viewpoints), and this could be an important reason why EA has had such a difficulty to get understood by senior level management, whose focus is on these two abstraction levels[87].

The last ten years have seen EA tools trying to incorporate models that are relevant to higher level management decision making, but often there are serious limitations. One has to consider that management has been using a very long list of models, and the tools, with the addition of a handful of models, only scratch the surface.

While there exist a natural desire to have all possible management models incorporated into tools, one must realise that this is an impossible task! Well – it is certainly impossible if we imagine the desirable outcome as the product of some small tool development ‘project’.

Traditional EA tools concentrated on models typically used for the development of the IT architecture and digitised processes (with some strategic modelling to provide the backdrop), and the rest of the architectural design were usually not well integrated into the meta-models underlying the EA workbenches. However, the EA tool market is becoming more and more competitive, and the tools are gradually embracing more and more enterprise management areas. Some well-known high-end tools on the market are IBM System Architect, MEGA Suite, ARIS, QualiWare, Troux, and some lightweight or ‘lighter weight’ tools like Sparx Enterprise Architect.

Enterprise integration through the construction of integrated EISs has many possible goals, and the scope and detail of modelling must be adjusted to the context: therefore the set of meta-models supported by an enterprise modelling tool should reflect the needs of typical scenarios. For example, ISO19440 [88] defines a set of modelling constructs (in fact a family of languages), organised by the modelling framework of [89]specifically designed for model based control, such as may be used in discrete part manufacturing.

The difficulty with the development of enterprise modelling tools is that their adoption requires a long learning curve, and a high EA maturity. However, if we think of modelling tools as technology that is an extension to managers, architects, controllers, etc., then the problem can be reformulated in the life history domain as a question of learning. In this way the problem becomes as stated thus: “How do we ensure that a socio-technical system of systems continually evolves and learns all relevant models of itself and other relevant associated systems via concerted constant use and iteration?” In other words enterprise modelling needs to move from the enterprise engineering mindset (‘create models to design change’) to the enterprise awareness mindset (‘use models to gain insight and to create a shared and explicit understanding of reality’).

EA Tools must figuratively and literally open up their interfaces so that the EA community could contribute and share additions and extensions, much in the same way as application development is done for mobile devices. Of course, for tool developers this would mean adopting a new business model, and there would be winners and losers.

EA has not done enough to credibly address the economic viewpoint of the organisation. For example, ISO15704:2005 does have an economic viewpoint, but EA practitioners do not use it, presumably because:

(a)

EA is currently mostly practiced on the CIO level,

(b)

economists have a much longer list of models that are relevant for decision making, and

(c)

to make the connection between the economic viewpoint’s models and other enterprise models one would have to substantially extend the meta-models underlying the tools.

It is clear that the future is not in EA reinventing the complete gamut of management models, but it is in providing a unifying platform through which the multiple models used in the various life cycle phases and in the various stages of the enterprise’s life history can be combined.

The combination needs a new paradigm though, as current EA methodologies struggle with the reality of complex relationships among models present at different abstraction levels. In essence, guided evolution of the enterprise requires that enterprise modelling not be seen as a top-down or bottom up process, but as a powerful problem finding and problem solving tool that supports transformational activities both on the strategic and operational levels [90]. In facing ‘wicked problems’, enterprise architects must focus more on problem-finding than problem-solving; true craftsmen look at situations in a problem-finding manner, rather than blindly applying the same method and tool every time to what may be a new and interesting challenge [91].

Enterprise architecture practice must be collaborative [92], and enterprise architects should be cooperative in character, able to engage in many kinds of communication and collaboration. Enterprise architects must have (1) dialectic skills and competencies in resolving conflicts, creating consensus, synthesis and common understanding, detecting what might establish that common ground, and the skill of seeking the intent rather than just reading the face value of the words, and (2) dialogic skills including listening well, behaving tactfully, finding points of agreement, managing disagreement, and avoiding frustration in a difficult discussion [93].

3.4. Coherency management and EA as a systems science

In management terms, Doucet et al. [12] suggest that EA is really all about coherency management: the craft of making the enterprise coherent whenever and wherever it matters (enterprise modelling plays a key role here). A coherent enterprise is an enterprise that successfully deals with (1) enterprise alignment, (2) enterprise agility, and (3) enterprise assurance. Alignment is the ability to operate as one by working towards a common shared vision supported by a well-orchestrated set of strategies and actions. Agility is the ability to respond to and manage unanticipated change. Assurance is the ability to establish and institutionalise (internalise) practices that ensure the fulfilment of organisational goals and achievement of outcomes.

To understand the coherency of an enterprise, one must view the enterprise as a whole. Whole entities exhibit properties meaningful only when attributed to the whole, not to its parts [94]. The essence of a system is togetherness, the drawing together of parts and their relationships that produce a new whole [95].

Management increasingly request enterprise modelling tools that can forecast and visualise system-wide, cross-boundary interactions. However, in addition to tools, the redistribution of EA knowledge among various management roles is of great importance, because the above systems view must be able to be created, communicated and interpreted correctly. Therefore EA knowledge must be distributed across the organisation.

Constrained relationships or dependencies exist among the views of the models as seen by various stakeholders. Therefore decision makers and enterprise planners need support to understand (through models) the system-wide interactions that cut across levels of decision making and various parts of a system of systems. These relationships and constraints do not necessarily respect the traditional boundaries between decision-maker roles and levels, or areas of enterprise activity.

When we think about EA as a systems science of the enterprise, it transpires that current frameworks are quite complex. Part of this complexity is necessary, but we believe that some of the complexity is due to a prescriptive attitude: the desire to have ‘recipe’ change methodologies. This situation must change, because it can be an impediment to innovative change.

EA must become holistic and non-reductionist in its conception and framing of organisational realities. EA must encompass both soft and hard systems problems, model complex systems behaviour through self-design, and add the human interpretive behaviour and cognition to organisations as living systems.

We must enrich EA’s view of communication processes in organisations both as self-organising and inherently rhizomatic/networked, dynamic, and concurrent processes, which cannot be modelled using traditional binary and linear enterprise models [15]. A number of systems theories are feasible candidates for extending and enriching EA in order to achieve exactly that effect.

Firstly, soft systems theory [96] established an important distinction between hard and soft systems problems. The former is characterised by engineering problems, which have formal, calculated solutions such as a computer program or a manufacturing process improvement. The latter refers to complex social, political, and organisational problems, which can only be accommodated for – not entirely solved.

Examples of typical soft systems problems include cultural changes, organisational restructures, or competitive responses, which are more often than not based on incomplete knowledge of a highly dynamic, fluid, and systemic context and are thereby inherently ‘messy’. Soft systems problems require experimentation, learning, and feedback cycles in order to reach a desired outcome. To that end, EA must expand its conception of complex organisational problems, solutions, and accommodations and adopt a broad view of soft systems problems as inherent to organisational reality and transformation.

Communication is a second key challenge for EA. Many approaches to change management and transformation assume that organisational communication is a relatively simple issue, which can be solved by building out a deliberate communication plan through RACI charts and corporate communication broadcasts [15]. However, communication in enterprise transformations has immensely complex and systemic aspects [97].

Luhmann’s theory of second order cybernetics provides a fruitful and productive frame for understanding these complexities [97]. It provides a theoretical framework for analysing and modelling the relationships between social (organisations) and psychological (individuals) systems based on the notion that these systems are self-referential (autopoietic) in order to tackle and manage environmental complexity.

The interpretation of communication (e.g. understanding the outcomes of an EA program) always happens with respect to the internal structure of the receiving system. This means that with the adoption of concepts for transforming an organisation (EA), frameworks and practitioners have to allow for organisational systems to absorb, interpret, and reconstruct their own realities around new communicated concepts before it becomes a success.

Sometimes even misunderstanding critical concepts due to their ambiguity (such as the value proposition of investing in architecture, be it for business, operational, or technology reasons) is productive in order successfully transform the enterprise [15]. The meaning of EA has to be understood, shaped and reshaped in order for organisations to justify investment in EA programs and benefit from its value.

EA transformation understood through the lens of ‘productive misunderstandings’ and socio-communication is a fruitful perspective, since it caters to the importance of action, language, and meaning as first class citizens in the process, which is particularly useful for highlighting the complexity and outcomes of human communication processes across the organisation.

The crux of ill-defined, messy organisational problems in soft systems and the socio-communicative context come together in the third challenge: how social, psychological, technical, and political systems interact within the larger environment. Given the fact that EA faces a vast array of soft systems problems in any organisation undergoing transformation, it is paramount that EA provide the analytical capability to frame, model, and improve these systems and their interactions.

Mapping the communications, discourses, and subsystems in an organisation undergoing transformation is valuable as it traces the meaning, values, and relationships between important stakeholders. The use of the word ‘trace’ here is deliberate: Luhmann[97] stresses that once a system’s structure and purpose have been traced and understood, its structure has already transformed as part of the process.

A system trace is temporary and fragile due to the underlying fragility of communication itself. In practical terms, the architect taking deliberate actions and communication perturbates the system, which in turn may change, for example the beliefs and motivations of the involved humans may change purely due to this interaction. Deleuze and Guattari [21] call this trace a rhizome, a horizontal stem of plant, which – unlike well-organised binary tree structures – is inherently complex and is constantly altering itself. It has no ultimate beginning or ends.

A rhizomatic structure, rather, is a multiplicity of its own unity; the structure forms a unity of possible system structures, which transform over time. Tracing a system means changing the rhizomatic structure.

Rhizome theory provides a useful way of framing the communicative, systemic nature of changing organisations: the challenges, political agendas, and accommodations of organisational change are intertwined in a constantly shifting network of relationships between people. It is inherently a multiplicity, in which multiple stakeholders participate non-hierarchically in several discourses at the same time.

Discourses change over time in line with politics, culture, trends, and leadership. In that sense, organisational change enabled by enterprise architecture forms a complex rhizomatic ecosystem, which can never be mapped and understood in its entirety (also due to the fact that it comprises both soft and hard systems problems).

The word ecosystem is particularly important as it emphasises its de-layered, non-hierarchical nature: communicating systems participate in an emergent network of complexity and change, which enterprise architecture must comprehend and incorporate into its repository of enterprise models and artefacts – otherwise EA will not be able to truly model and inform organisational change at the board level.

Ecosystems comprise soft, emergent, co-dependent systems, as opposed to clearly delineated, hard systems with scope, purpose, and boundary. Rhizome theory provides a comprehensive analytical framework for modelling these ecosystems, which must be incorporated into contemporary EA methodologies, tools, and frameworks in order for EA to truly inform the agenda of complex organisational change outside the domain of information technology.

At this level, appropriate socio-communicative models of organisational change of ecosystems are required in order to build enterprise architectures to improve complex, ambiguous realities where, most often decisions have to be made at the juncture of human values, beliefs, and in light of incomplete information.

With all this complexity, we believe that as the field matures, and unifying theories are developed, a more light-weight EA toolset/framework will be sufficient, and with the help of a general underlying theory practitioners (managers and architects) will be able to use the ingredients of the underlying disciplines in combination, and innovate as necessary.

3.5. EA knowledge and complexity management – EA cybernetics and information technology

It is the task of EA to reinterpret and express in a common format the theories and models of the contributing disciplines, thereby allowing system-wide interactions, relationships and constraints to be made explicit. Such understanding is a first step towards finding optimal points of intervention for transformational activities. This is in contrast with the current situation, whereupon both in the private sector and in government the large number of policies, legislation, and principles are becoming more and more complex, and changing or extending them often leads to unpredictable outcomes, because many system-wide interactions, relationships and constraints remain invisible [14]. This necessitates the need to take an ecosystem view of the enterprise.

A business ecosystem is a system of organisations that co-evolve their capabilities and roles, and align their investments to create additional value, greater effectiveness and higher agility. Some ecosystems evolve through coincidence and self-organisation. However, a “lead agent” can catalyse the emergence and subsequent development of this system. This leading entity needs to establish an overall architecture, to structure the key interfaces and incentives, and co-opt a small number of strategic partners, but then to rely on self-organisation within the network or these organisations.

Business ecosystems almost guarantee disruptive results (e.g. Apple, Amazon, Google, Facebook are successful because they have been able to architect their respective business ecosystems), and at times may lead to mergers and acquisitions.

Successful ecosystems are also harder to replicate, given their inherent complexity, thus giving enterprises sustained competitive edge. Surrender of hierarchy, vertical integration and direct control are consequences that organisations have to learn to live with.

There are several technology trends that try to extend the ability of management and control to those areas where the challenge of scale and complexity has previously curtailed the ability of management and control to use models in the traditional way. Two major trends of research are apparent, which can change the ability of management to make better predictions on the future states of the enterprise.

The recently popularised term ‘big data’ is the description of a movement that intends to use orders of magnitude larger amounts of data than stored in traditional (internal) data warehouses; the ‘big data’ come from multiple sources especially the environment of the enterprise, with the potential to identify/discover new relationships that are relevant for decision making.

An important source of the identification of this problem comes from the military in the early 1990s, wishing to exploit the technical capabilities of the rapidly developing high resolution imagery and various other sensor systems, so as to establish ‘dominant battlefield awareness’, recognising that the command and control system must be equipped with superior intelligence, surveillance, and reconnaissance capability[98] and [99].

Two decades ago, an important strategic analysis took place on the impacts of the information revolution [100], which correctly predicted ensuing social-, economic-, military- and geopolitical changes, including the drawn-out nature of this revolution.

The ability to process large amounts of information was (in the civilian sphere) initially exploited by the now traditional data warehousing and business intelligence tools for decision support. The methodology has been to identify the sources of data that are known to be relevant, build systems that can access these data, and algorithms that can extract, analyse and present reports for use by decision makers. However, this approach has serious limitations too due to the challenges of scope and complexity (as discussed in Section 1).

The recently popularised technologies of data mining, big data and predictive analytics use a fundamentally different approach. We do not assume to know exactly what data will be relevant, and may not even have a complete list of well-formed questions. In a sense, we are trying to partly automate the discovery and analysis function of the business analyst, or of a scientist (depending on the application area).The potential benefits of using ‘big data’ in predictive analytics are profound.

• Business can find patterns that explain the sources of certain customer behaviour, customer sentiment and preferences, exploiting this for better marketing, product development, and customer relationship building.
• Public health can discover factors behind high cost management of chronic diseases and address these.
• Medical and drugs research can use data mining, pattern recognition and identification to develop new treatments or drugs, and personalised medicine.
• Aged care can use personally collected data for timely and effective preventative intervention.
• Agricultural production management can use weather prediction, pest identification, and disease early warning for crop management.
• Environmental management can find causes of unwanted events or processes, using this for successful intervention.
• Management of crime, terrorism and military action promise to prevent, instead of dealing with consequences.

All of the above depend on research to give guidance regarding who should collect (keep, access or use) and what data, when, and why, with significant resource investment, social, political, legal and economic implications.

Even if there is an absence of predefined formal conceptual structures and domain theories, techniques that can be used for decision support include machine learning, pattern recognition and statistical algorithms, and various forms of text analytics to identify/discover correlations or patterns of relevance for questions that have only been informally defined.

Through discovering new relationships, management could create models with better predictive power, at least in the case where the system remains in the state space region previously explored and historical data are available. This is a very active research area today, because algorithms must be adjusted to the application area and practical gains can be significant, therefore EA must be well informed about the potentials of these new tools, and technology trends, for designing better EIS support for management.

It is not possible to completely overcome some of the limitations that complex systems pose, therefore to use evolving technologies for decision making, new theory development is also needed (into new organisational forms, and models of decision making based on partial information). However, if management and control objectives are adjusted accordingly, then new opportunities can be opened.

As mentioned, we see a continuum of controllability. In the simplest case, the system is completely controllable along a trajectory from the known current sate to a desired state. As assumptions get relaxed, the controller may still move the system from its initial state to a desired state, with some intermediate states along the trajectory, but these states only known to a margin of error. Thus the controller must know that this error does not affect the robustness of the control. This is the basic idea behind tube based Model Predictive Control (MPC) of nonlinear systems [28]: the trajectory moves along in a safe ‘tube’ or bundle, with variations in distributed control (cooperative, non-cooperative or hierarchical control), resulting in different performance attributes based on game theoretic considerations.

3.6. Exploring future states and situations

Robust control as described above is able to handle small parameter variations or larger variations over smaller parameter sets. Current methods can handle ‘weak’ uncertainty where the variations are bounded, but for the more practical, valuable case (of large parameters, variations and uncertainty) we need drastically expanded methods.

From the perspective of mathematical logic, the problem is one of reasoning over the open set. What makes this difficult is the set theoretic foundation of the logic universally employed in computing and control. This has been a long recognised challenge, with the most promising solution being modern situation theory [101].

Practical employment of situation theory requires so-called two-sorted logic where one logic is that of the modelling and control system and the second is based on category theory. But categorical reasoning over open sets is notoriously hard to implement.

However, recent developments in using a second-sorted, categoric reasoning system to model quantum systems provide new tools for the general case [102]. When extracted from specific physical behaviour, quantum systems represent the general case [103], which is based on a general observation by von Neumann [104].

A foundation for implementing such a categorical logic for enterprise-like domains was laid by Barwise and Seligman [105]. The mathematical mechanism described therein to represent changed points of view is channel logic. It allows reasoning in a given situation, and the complete reasoning associated with it (as well as constraints) to be moved along information channels. Channels exist among situation types, thus the logic promises the ability to reason about a multitude of future system states all at once. This result was extended by Goranson and Cardier [106] to apply to practical systems in an engineering environment.

This theoretical basis can define a research area creating a different model of control, replacing the notion of state with the notion of situation. A situation can be described as belonging to a type in the category of situations, whereupon every situation that belongs to a type supports some (positive or negative) information, a conjunct of ‘infons’. Infons are the normalised form for representing facts in this system [107].

The information about the situation the system is in may leave many state attributes (or aggregate properties) undefined, thus the system may be in one of many states and still the system can be characterised as being in a situation belonging to a situation type.

Similarly, the desired state of the system is replaced by the notion of the desired situation. Typical information that may be the basis of desired situations of a given type may include statements that are true (or false) about some state variables or combinations thereof, but also statements about aggregate or macro states (in management ‘key performance indicators’ would be examples of these).

In categorical reasoning one could argue: if the present situation is in category A then given a series of actions that constrain system evolution to safe trajectories, prove that all future situations will be in category B and provide a process chain to effect the transformation.

An unrelated but relevant futuristic scenario is the promise offered by the quantum metaphor to be able to reason about practically innumerable future states. Suppose one represents the future state of a system on n Q-bits, then the 2ⁿ states are simultaneously represented.

Provided we can create a suitably chosen model, such that when represented in the above way, the desirable system properties show up as periodicities in this model, it will be possible to apply the elementary FFT (Fast Fourier Transformation) quantum computing gate to this representation, and prove (or disprove) the presence of desired properties shared by an extremely large number of future states – without ever having to enumerate them.

Although quantum computation displays as probabilistic, a few repetitions could provide extremely accurate predictions. Conversely, if the desired properties of the future cannot be proven, we would have an experimental facility to try out the effects of proposed structural changes aimed at (re-)establishing desired permanent systemic properties.

4. Conclusions and future research directions

According to the definition of EIS given in the introduction of this paper, the evolution of EIS is in fact a view of the evolution of the architecture of the enterprise. Therefore it is not possible to overcome current limitations in isolation unless the solutions are embedded in the Enterprise Architecture discipline. As a consequence, EIS evolution and EA evolution are intrinsically connected.

In summary then, a scoping statement for a future proposed research agenda for next generation Enterprise Information Systems (EIS) and of the embedding enterprise architecture (EA) would include the following key elements:

• EA needs to embrace full or broad views of the enterprise as per the original vision of the discipline’s mission that originated in manufacturing (e.g. computer integrated manufacturing systems), and the parallel developments in information systems and software development. This division between information systems, system science, and manufacturing and industrial engineering needs to be resolved as it is still felt today and hampers the discipline of EA as a whole. Any credible development of the discipline must equally cover and explain deliberate change and evolutionary change in a system of socio-technical systems, the production and service to the customer, and the management and control of the enterprise, the technical resources (logistics, manufacturing machinery, communication systems, computer systems), human resources, financial resources, and assets of all other kind (knowledge and information assets, buildings and grounds, and various intangibles).
• As EA is moving up the hierarchy from technical to management levels, the language and skill set of its practitioners has to change to better reflect the specific needs and language of the management community. This needs to be reflective in terms of not only language, but also culture. The focus must be on views of the organisation that management science is interested in (People, Capability, Place, Role, Relationships and Trust, Risk, Finance, Brand Strategy, Knowledge Management) rather than detailed, possibly local technical views of the organisation.
• A central concern in EA is the development of the information system that implements a coherent, aware behaviour of the enterprise on any scale. It is acceptable (even desirable) that the implementation of these properties should not have a single locus, so that the system should display these properties without a single subsystem or system component being responsible for them. If awareness and coherency are emergent properties of the enterprise, it is likely that the enterprise (and its information system) would be more resilient in terms of being able to maintain these systemic properties.
• Revolution or re-booting of EA tool-sets has been discussed at length in this paper and elsewhere, and should be the subject of further detailed analysis, but clearly the current generation of tools and the models of the enterprise are limited in scope relative to the needs of the management community that EA serves.
• As the new vision matures, new EA will both promulgate through and improve training and certification for professionals. We would also expect the maturation of credentials of the EA Body of Knowledge (EABOK) as the field in general evolves.

Collectively, these developments will transform enterprise architecture as the ongoing process of building the ability to manage complexity, with the pivotal goal of creating and sustaining coherent and future-ready enterprises.

References

[1]  Ch.J. Petrie Jr. (Ed.), Preface. Enterprise Integration Modeling. Proceedings 1st ICEMT, MIT Press, Cambridge (1992)

[2] K. Kosanke, J.G. Nell (Eds.), Enterprise Engineering and Integration: Building International Consensus, Proc. ICEIMT’97 Int. Conf. on Enterprise Integration and Modelling Technology, Springer, Berlin (1997)

[3] K. Kosanke, F. Vernadat, M. Zelm. CIMOSA: enterprise engineering and integration. Comput. Ind., 40 (2–3) (1999), pp. 83–97

[4] S. Spewak. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology (with Foreword from J. Zachman). Wiley, Hoboken (1992)

[5] A. Boza, L. Cuenca, R. Poler, Z. Michaelides. The interoperability force in the ERP field. Enterp. Inf. Syst., 9 (3) (2015), pp. 257–278

[6] ISO 15704. Industrial Automation Systems – Requirements for Enterprise-reference Architectures and Methodologies. ISO, Geneva (2000)

[7] ISO 15704. Industrial Automation Systems – Requirements for Enterprise-reference Architectures and Methodologies: Additional Views for User Concerns. ISO, Geneva (2000/Amd1:2005)

[8] IITF. GERAM: Generalised enterprise reference architecture and methodology (GERAM EA Framework v.1.6.3). IFIP-IFAC Task Force (1999) Also published in Bernus, P., Nemes, L., Schmidt, G. (Eds.) (2003). Handbook on Enterprise Architecture. Berlin: Springer. pp. 22–63, and as Annex A to ISO 15704:2000 http://www.ict.griffith.edu.au/∼bernus/

[9] P. Bernus, L. Nemes. A framework to define a generic enterprise reference architecture and methodology. Proc. ICARV’94 4th Int. Conf. on Control, Automation, Robotics and Vision, vol. 3/3, Nanyang Technological University, Singapore (1994), pp. 88–92

[10] D. Chen, G. Doumeingts, F. Vernadat. Architectures for enterprise integration and interoperability: past, present and future. Comput. Ind., 59 (7) (2008), pp. 647–659

[11] ISO/IEC/IEEE 42010. Systems and Software Engineering – Architecture Description. ISO, Geneva (2011)

[12] G. Doucet, J. Gøtze, P. Saha, S. Bernard (Eds.), Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance, AuthorHouse, Bloomington, IL (2009)

[13] L. Cuenca, A. Boza, A.A. Ortiz. An enterprise engineering approach for the alignment of business and information technology strategy. Int. J. Comput. Integr. Manuf., 24 (11) (2011), pp. 974–992

[14] P. Saha (Ed.), A Systemic Perspective to Managing Complexity with Enterprise Architecture, IGI Global, Hershey, PA (2014)

[15] J. Gøtze, A. Jensen-Waud (Eds.), Beyond Alignment: Applying Systems Thinking in Architecting Enterprises (Systems), College Publications, London (2013)

[16] H. Kandjani, P. Bernus. The enterprise architecture body of knowledge as an evolving discipline. J. Cordeiro (Ed.), et al., LNBIP 141, Springer, Berlin, Heidelberg (2013), pp. 452–471

[17] S.A. Bernard. An Introduction to Enterprise Architecture (3rd ed.) AuthorHouse (2012)

[18] OMB: Office of Management Budget. The Common Approach to Federal Enterprise Architecture. Executive Office of the President of the United States (2012)

[19] A.Ø. Jensen-Waud, J. Gøtze. A systemic-discursive framework for enterprise architecture. J. Enterp. Architect., 8 (3) (2012), pp. 35–44

[20] T. Barroero, G. Motta, G. Pignatelli. Business capabilities centric enterprise architecture. P. Bernus, G. Doumeingts, M. Fox (Eds.), Enterprise Architecture, Integration and Interoperability: Proc. IFIP TC5 Int. Conf. EAI2N 2010, Springer, Berlin (2010), pp. 32–44

[21] G. Deleuze, F. Guattari. A Thousand Plateaus: Capitalism and Schizophrenia. Athlone Press, London (1988)

[22] FEAPO. A Common Perspective on Enterprise Architecture Developed and Endorsed by The Federation of Enterprise Architecture Professional Organizations. (2013) http://feapo.org/wp-content/uploads/2013/11/Common-Perspectives-on-Enterprise-Architecture-v15.pdf

[23] P. Bernus, O. Noran, A. Molina. Enterprise architecture: twenty years of the GERAM framework. Proc 19th IFAC WCC. IFAC Papers Online (2014), pp. 3300–3308

[24] H. Nguyen, K. Krishnakumar, J. Kaneshige, P. Nespeca. Dynamics and adaptive control for stability recovery of damaged asymmetric aircraft. AIAA Guidance, Navigation, and Control Conf. and Exhibit., PCG, Boston (2006), pp. 1–24http://dx.doi.org/10.2514/6.2006-6049

[25] N.A. Duffie. Heterarchical control of highly distributed manufacturing systems. Int. J. Comput. Integr. Manuf., 9 (4) (1996), pp. 270–281

[26] C.E. García, D.M. Prett, M. Morari. Model predictive control: theory and practice a survey. Automatica, 25 (3) (1989), pp. 335–348

[27] E.F. Camacho, C.B. Alba. Model Predictive Control. Springer, London (2007)

[28] J.B. Rawlings, Q.M. Mayne. Model Predictive Control: Theory and Design. Nob Hill Pub. Co., Madison, WI (2013)

[29] M.D. Mesarović, D. Macko, Y. Takahara, R. Drenick. Theory of hierarchical multilevel systems. Oper. Res., 19 (1) (1971), pp. 250–252

[30] G. Doumeingts. Méthode GRAI: méthode de conception des systèmes en productique. (Thèse d’état: Automatique) Université de Bordeaux I (1984), p. 519 pp

[31] G. Doumeingts, B. Vallespir, D. Chen. GRAI grid decisional modelling. P. Bernus, K. Mertins, G. Schmidt (Eds.), Handbook on Architectures of Information Systems, Springer, Heidelberg (1998), pp. 313–339

[32]  J. Liu, T. Dietz, S.R. Carpenter, M. Alberti, C. Folke, E. Moran, A.N. Pell, P. Deadman, T. Kratz, J. Lubcheno, E. Ostrom, Z. Ouyang, W. Provencher, C.L. Redman, S.H. Schneider, W.W. Taylor.  Complexity of coupled human and natural systems. Science, 317 (2008), pp. 1513–1516

[33] G.F. Laniak, G. Olchin, J. Goodall, A. Voinov, M. Hill, P. Glynn, G. Whelan, G. Geller, N. Quinn, M. Blind, S. Peckham, S. Reaney, N. Gaber, R. Kennedy, A. Hughes. Integrated environmental modeling: a vision and roadmap for the future. Environ. Model. Softw., 39 (2013), pp. 3–23

[34] D. Qiu, Q. Wang, Y. Zhoul. Steady-state output controllability and output controllability of linear systems. Computational Intelligence and Industrial Applications, IEEE Xplore (2009), pp. 147–150

[35] R. Bishop. Chaos. E.N. Zalta (Ed.), The Stanford Encyclopaedia of Philosophy (2009) http://plato.stanford.edu/archives/fall2009/entries/chaos/

[36] K. Kanelo, I. Tsudaa. Complex Systems – Chaos and Beyond: A Constructive Approach with Applications in Life Sciences. Springer, Berlin (2001)

[37] N. Suh. Axiomatic Design: Advances and Applications. Oxford Univ. Press, New York (2001)

[38] N. Suh. Complexity: Theory and Applications. Oxford University Press, New York (2005)

[39] S. Lloyd. Measures of complexity: a nonexhaustive list. IEEE Control Syst., 21 (4) (2001), pp. 7–8

[40] H. Kandjani, M. Tavana, P. Bernus, S. Nielsen. Co-Evolution Path Model (CePM): sustaining enterprises as complex systems on the edge of chaos. Cybern. Syst. Int. J., 45 (2014), pp. 547–567

[41] R.M. Wise, I. Fazey, M. Stafford Smith, S.E. Park, H.C. Eakin, E.R.M. Archer Van Garderen, B. Campbell. Reconceptualising adaptation to climate change as part of pathways of change and response.  Glob. Environ. Change, 28 (2014), pp. 325–336

[42] J. Lu. Bridging the Gap Between Planning and Control: A Multiscale MPC Cascade Approach. IFAC Plenary Lecture. (2014) Retrieved from: http://www.ifac2014.org/assets/pdf/plenary/Lu.pdf

[43] J.F. Kolen, J.B. Pollack. The observer’s paradox: apparent computational complexity in physical systems. J. Exp. Theor. Artif. Intell., 7 (1995), pp. 253–277

[44] C.R. Shalizi, C. Moore. What is a macrostate? Subjective observations and objective dynamics. (2003, rev 2008) http://arxiv.org/pdf/cond-mat/0303625.pdf

[45] R. Dale, D.W. Vinson. The observer’s observer’s paradox. J. Exp. Theor. Artif. Intell., 25 (3) (2013), pp. 303–322 http://dx.doi.org/10.1080/0952813X.2013.782987

[46] W.R. Ashby. Requisite variety and its implications for the control of complex systems. Cybernetica, 1 (2) (1958), pp. 83–99

[47] F.A. Bais, J.D. Farmer. Physics of Information. SFI Working Paper 2007-08-029.  Santafe Institute, Santa Fe, NM (2007)

[48] S. Rodriguez, N. Gaud, V. Hillaire, S. Galland, A. Koukam. An analysis and design concept for self-organization in holonic multi-agent systems. S. Brueckner, S. Hassas, M. Jelasity, D. Yaminds (Eds.), 4th International Workshop, ESOA 2006, Hakodate, Japan, May 9, 2006, Revised and Invited Papers, Springer-Verlag, Berlin (2007), pp. 15–27

[49] W. Sihn. Re-engineering through fractal structures. J. Browne, D. O’Sullivan (Eds.), Re-engineering the Enterprise: Proceedings of the IFIP TC5/WG5.7 Working Conference on Re-engineering the Enterprise, Galway, Ireland, Springer, Berlin (1995), p. 10

[50] S. Beer. Brain of the Firm. Penguin Press, London (1972)

[51] Hoverstadt. The Fractal Organization: Creating sustainable organizations with the Viable System Model. Chichester, Wiley (2008)

[52] W.C. Clark. Sustainability science: a room of its own. Proc. Natl. Acad. Sci. U. S. A., 104 (2007), pp. 1737–1738

[53] J. Rosenhead. IFORS’s operational research hall of fame Stafford Beer. Int. Trans. Oper. Res., 13 (6) (2006), pp. 577–578

[54] C.A. O’Reilly, M.L. Tushmanb. Ambidexterity as a dynamic capability: resolving the innovator’s dilemma. Res. Organ. Behav., 28 (2008), pp. 185–206

[55] S. Beer. The viable system model: its provenance, development, methodology and pathology. J. Oper. Res. Soc., 35 (1) (1984), pp. 7–25

[56] Y.F. Chu, Z.Y. Huang, J. Hahn. Improving prediction capabilities of complex dynamic models via parameter selection and estimation. Chem. Eng. Sci., 64 (2009), pp. 4178–4185

[57] P.C. Young. Gauss, Kalman and advances in recursive parameter estimation. T.C. Mills, R.S. Tsay, P.C. Young (Eds.), J. Forecast., 30 (1) (2011), pp. 104–146http://dx.doi.org/10.1002/for.1187 (Special issue)

[58] J.E. Doherty, R.J. Hunt, M.J. Tonkin. Approaches to highly parameterized inversion: a guide to using PEST for model-parameter and predictive-uncertainty analysis. U.S. Geological Survey Scientific Investigations Report 2010-5211. (2010) 71 pp. Available from USGS at: http://pubs.usgs.gov/sir/2010/5211/pdf/uncpest_sir2010-5211.pdf

[59] D. Romero, A. Molina. Green virtual enterprise breeding environment reference framework, adaptation and value creating collaborative networks. L.M. Camarinha-Matos (Ed.), et al., International Federation for Information Processing, AICT 362, Springer (2011), pp. 545–555

[60] D. Romero, A. Molina. Forward – green virtual enterprises and their breeding environments: sustainable manufacturing, logistics & consumption. Proc PRO-VE’14, Springer, Berlin (2014), pp. 336–346

[61] D. Romero, O. Noran. Green virtual enterprises and their breeding environments: engineering their sustainability as systems of systems for the circular economy. Prepr. IFAC Symposium on Information Control in Manufacturing (INCOM) (2015), pp. 2326–2333

[62] L. von Bertalanffy. General System theory: Foundations, Development, Applications. George Braziller, New York (1968)

[63] H.T. Goranson. The Agile Virtual Enterprise: Cases, Metrics, Tools. Quorum Books, Westport, CT (1999)

[64] M. Tølle, P. Bernus. Reference models supporting enterprise networks and virtual enterprises. Int. J. Netw. Virtual Organ., 2 (1) (2003), pp. 2–15

[65] L. Camarinha-Matos, H. Afsarmanesh, A. Ortiz (Eds.), Collaborative Networks and Their Breeding Environments, Springer, Berlin (2005)

[66] F. Baldo, R.J. Rabelo. A structured approach for implementing virtual organization breeding environments in the mold and die sector – a Brazilian case study. L.M. Camarinha-Matos, X. Boucher, H. Afsarmanesh (Eds.), Collaborative Networks for a Sustainable World, IFIP AICT, vol. 336 (2010), pp. 197–203

[67] K. Dopfer, J. Foster, J. Potts. Micro–meso–macro. J. Evol. Econ., 14 (3) (2004), pp. 263–279

[68] S.A. Page. Path dependence. Q. J. Polit. Sci., 1 (2006), pp. 87–115

[69] M.P. Papazoglou. Web Services & SOA, Principles and Technology. Pearson Education (2012)

[70] W.P. van der Aalst, m. Netjes, H.A. Reijers. Supporting the full BPM life-cycle using process mining and intelligent redesign. K. Siau (Ed.), Contemporary Issues in Database Design and Information Systems Development, IGI Global (2007), pp. 100–132

[71] M. Fiammante. Dynamic SOA and BPM – Best Practices for Business Process Management and SOA Agility. IBM Press, Portland, OR (2010)

[72] K. Elgazzar, A.E. Hassan, P. Martin. Clustering WSDL documents to bootstrap the discovery of web services. International Conference on Web Services (2010), pp. 147–154

[73] A. Perin-Souza, R.J. Rabelo. An approach for a more agile BPM&SOA integration supported by dynamic service discovery. Enterprise Distributed Object Computing Conference Workshops (2010), pp. 186–195

[74] R.J. Rabelo. Advanced Collaborative Business ICT Infrastructures. Methods and Tools for Collaborative Networked Organizations. Springer (2008), pp. 337–370

[75] A.L. Roth, D. Wegner, A.D. Padula. Differences and inter-relations of governance concepts and horizontal networked enterprises management. J. Admin., 47 (1) (2012), pp. 112–123

[76] R.J. Rabelo, S.N. Costa, D. Romero. A governance reference model for virtual enterprises. Proc. 15th IFIP Working Conf. on Virtual Enterprises, Berlin, Springer (2014), pp. 60–70

[77] J. Sassoon. Urbanisation of Information Systems [Urbanisation des systèmes d’information]. Hermès, Paris (1998)

[78] H. Kandjani, P. Bernus, S. Nielsen. Enterprise architecture cybernetics and the edge of chaos: sustaining enterprises as complex systems in complex business environments. R.H. Sprague Jr. (Ed.), Proc. Hawaii Int. Conf. on Systems Science HICSS2013, IEEE Xplore, Washington (2013), pp. 3858–3867

[79] C. Coates, A. Stewart, M. Perlin. Human Centric Architecture Framework: Human Views in DNDAF – Interim Report. Defence R&D Canada and Ottawa: Esterline-CMC Electronic, Toronto (2012)

[80] T.S. Kuhn. The Structure of Scientific Revolutions. University of Chicago Press, Chicago (1962)

[81] F. Vernadat. Enterprise Modeling and Integration: Principles and Applications. Chapman & Hall, London (1996)

[82] A.-W. Scheer. ARIS – Business Process Modeling. Springer, Berlin (2000)

[83] K. Tarkkanen. Business process modeling for non-uniform work. LNBIP, vol. 19, Springer, Berlin (2009), pp. 188–200

[84] F. Vernadat. Enterprise modelling and integration. K. Kosanke, J. Roland, J.G. Nell, A. Ortiz (Eds.), Inter- and Intra Organizational Integration – Building International Consensus, Kluwer, London (2003), pp. 25–33

[85] S. Searle, M. Cantara. Fifteen Skills Critical to Success With Business Process Management. Gartner (2014) http://www.gartner.com/doc/2614420

[86] O. Noran. A mapping of individual architecture frameworks (GRAI, PERA, C4ISR, CIMOSA, Zachman, ARIS) onto GERAM. P. Bernus, L. Nemes, G. Schmidt (Eds.), Handbook on Enterprise Architecture, Springer, Berlin (2003), pp. 65–210

[87] P. Turner, J. Gøtze, P. Bernus. Architecting the firm – coherency and consistency in managing the enterprise. R. Meersman, P. Herrero, T. Dillon (Eds.), OTM 2009 Workshops, LNCS5872, Springer, Berlin (2009), pp. 162–171

[88] ISO19440. Enterprise Integration – Constructs for Enterprise Modelling. ISO, Geneva (2007)

[89] ISO 19439. Enterprise Integration – Framework for Enterprise Modelling. ISO, Geneva (2006)

[90] J. Gøtze. The changing role of the enterprise architect. Proceedings of the 2013 17th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW 2013), 9–13 September 2013, Vancouver, British Columbia, Canada (2013)

[91] R. Sennett. The Craftsman. Allen Lane (2008)

[92] S. Bente, U. Bombosch, S. Langade. Collaborative Enterprise Architecture. Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Morgan Kaufmann, Boston (2012)

[93] R. Sennett. Together: The Rituals, Pleasures and Politics of Cooperation. Yale University Press (2011)

[94] P. Checkland. Systems Thinking, Systems Practice – Includes a 30 year Retrospective. John Wiley, Chichester, UK (1999)

[95] J. Boardman, B. Sauser. Systems Thinking – Coping with 21st Century Problems. CRC Press, Boca Raton, FL (2008)

[96]  P. Checkland. From optimizing to learning: a development of systems thinking for the 1990s. J. Oper. Res. Soc., 36 (9) (1985), pp. 757–767

[97] N. Luhmann. Social Systems. Stanford University Press, Stanford CA (1995)

[98] M.C. Libicki, S.E. Johnson (Eds.), Dominant Battlespace Knowledge, NDU Press Book (1995)

[99] M.T. Fennell, R.P. Wishner. Battlefield awareness via synergistic SAR and MTI exploitation. IEEE AES Mag., 13 (2) (1998), pp. 39–43 http://dx.doi.org/10.1109/62.656334

[100] B. Nichiporuk, C.H. Builder. Information Technologies and the Future of Land Warfare. Rand, Arroyo Center, Santa Monica (1995)

[101] K. Devlin. Logic and Information. Cambridge University Press (1995)

[102] S. Abramsky, B. Coecke. Categorical Quantum Mechanics in Handbook of Quantum Logic and Quantum Structures: Quantum Logic. Elsevier (2008), pp. 261–324

[103] P. Bruza, K. Kitto, D. Nelsen, C. McElvoy. Is there something quantum-like about the human mental lexicon? J. Math. Psychol., 53 (5) (2009), pp. 362–377

[104] J. von Neumann. The role of high and extremely high complication. Theory of Self-reproducing AutomataUniversity of Illinois Press (1966), pp. 64–87

[105] J. Barwise, J. Seligman. Information Flow, the Logic of Distributed Systems Cambridge Tracts in Theoretical Science. Cambridge University Press (2008)

[106] H.T. Goranson, B. Cardier. A two-sorted logic for structurally modeling systems. Prog. Biophys. Mol. Biol., 113 (1) (2013), pp. 141–178

[107] K. Devlin. Modeling real reasoning. Formal Theories of Information, Lecture Notes in Computer Science, vol. 5363Springer, Berlin (2009), pp. 234–252

Copyright © 2015 Elsevier B.V. All rights reserved.