Keywords

1 Introduction

Modern day enterprises, be they businesses, government departments or organizations, are constantly in motion. Socio-economic challenges, such as the financial crisis, mergers, acquisitions, innovations, novel technologies, new business models, servitisation of the economy, reduced protectionism, de-monopolisation of markets, deregulation of international trade, privatisation of state owned companies, increased global competition, etc., provide key drivers for change. These challenges are fuelled even more by advances in technology, in particular the development of information technologies. As a result, enterprises need be continuously “on the move” to find the right balance between these many, sometimes contradicting, change drivers. The resulting changes can materialise in different forms. They might, for example, take shape as top-down and premeditated efforts, but might also occur as numerous small changes that emerge bottom-up in a seemingly spontaneous fashion.

Organizations increasingly turn to enterprise architecture as a means to steer the direction of the changes that occur in an enterprise [12, 22, 31, 33, 42, 60]. Over the past decades, the domain of enterprise architecture has seen a tremendous growth, both in terms of its use and development in practise and as a subject of scientific research. The roots of the field of enterprise architecture can actually be traced back as far as the mid 1980s [46].

In this position paper, we aim to investigate the potential role of enterprise architecture as a means to support senior management in dealing with challenges brought forward by the continuous motion of modern day enterprises. In doing so, we aim to develop a fundamental understanding of the systemic playing field in which enterprise architecture is to play a role. We will therefore start by exploring what it means for an enterprise to be “in motion” (Sect. 2). We then turn to the control paradigm from management science [34, 35], to reflect on ways to steer this motion (Sect. 3). This will also lead to the introduction of the notion of second order information systems being information systems that are not targeted at supporting the operational processes of an enterprise, but rather at supporting the change processes of an enterprise. Second order informations systems enable the enterprise, and senior management in particular, to steer the motion of an enterprise. Using this understanding we then zoom in on the potential role of enterprise architecture in steering an enterprise’s motion (Sect. 4). In doing so, we also discuss what we regard as being the core ingredients of enterprise architecture.

2 Enterprises in Motion

In line with [17], we consider an enterprise to primarily be a social system, in particular a social system with a purpose. The social individuals, i.e. humans, making up the enterprise will typically use different technological artefacts to (better) achieve their purpose. As a result, enterprises are generally regarded as being socio-technical systems. In using the term enterprise we will therefore also refer to the used technological artefacts.

2.1 Challenges to Enterprises

In [23, 42, 46], we discussed several challenges facing an enterprise. Each of these challenges potentially drive an enterprise to change. Below we briefly summarize three of these challenges.

Keep Up or Perish. Enterprises face many changes, such as mergers, acquisitions, innovations, novel technologies, new business models, reduced protectionism, deregulation of international trade, privatisation of state owned companies, increased global competition, etc. These factors all contribute towards an increasingly dynamic environment in which enterprises want to thrive.

Shifting Powers in the Value Chain. Clients of enterprises have become more demanding. A shift of power in the value chain is occurring. Clients have grown more powerful and demand customized, integrated and full life-cycle products and services. Rather than asking for a “printer”, they require a guaranteed “printing service”. A shift from basic products to full services. Even more, websites and social media, where consumers can share pricing information, experiences, ratings, etc., creates a transparency on the market that provides even more control to the consumers.

The creation and delivery of such complex products and services requires additional capabilities which may not be readily available within a single (pre-existing) enterprise. In this pursuit they increasingly engage in complex product-offerings involving other parties, leading to cross selling and co-branding. To ensure the quality of such products and services, a high level of integration and orchestration between the processes involved in delivering them is required.

Comply or Bust. In the networked economy, governance of enterprises becomes increasingly complex. One sees a shift in governance from individual departments within an organization, to the entire organization, and lately to the organization’s value web. Management does not only have to worry about the reputation of their own organization, but also about the other organizations in their value web.

How daunting the latter might be can be illustrated by real life examples, such as a large shoe manufacturer who outsourced the production of shoes to another company, to only discover at a later stage that the latter made use of child labour. Although the latter company was not part of the shoemaker’s own organization, their reputation was still damaged, threatening their survival on the market-place.

Governance is not only an issue to an organization on its own, but also a major concern to society as a whole. As a result of undesired and uncontrollable effects of the increased socio-economical complexity and interdependency of organizations, services, products and financial instruments. Examples of such side-effects are the well-known Enron scandal, as well as the sub-prime mortgage crises. To control and/or prevent such effects, new legislation has been put in place to better regulate enterprise practises.

Excel or Outsource. Increasingly enterprises outsource business processes. Outsourcing of business processes requires organizations to precisely understand and describe what needs to be outsourced, as well as the implementation of measures to ensure the quality of the outsourced processes. In deciding on what to outsource and how to safeguard its quality, management needs insight into the extent to which processes can be outsourced, the risks that may need to be managed when doing so, as well as the interdependencies within the outsourced processes and between the outsourced processes and the retained organization.

Conversely, organizations with a strong tradition in a certain business process may decide to become industry leader for such processes. For example, processing of payments, management of IT infrastructure, and logistics.

IT as the Business Differentiator. In most enterprises, the role of IT started with the ‘automation of administrative work’. While there continues to be a clear role for IT to automate administrative information processing, the actual use of IT has moved far beyond this. In numerous situations, IT has given rise to new social structures, and business models. Consider, for example, the development of social media, the (acclaimed) role of twitter in time of social unrest, the emergence of on-line music stores, app-stores, music streaming services, etc. The advent of ‘big data’ [27] is expected to drive such developments even further by allowing IT based systems to use statistical data to tune their behaviour to observed and learned trends.

At the same time, IT has become firmly embedded in existing technological artefacts. The cars in which we drive may contain more lines of code than typical banking applications do. The next generation of cars will even be able to (partially) do the driving for us. The so-called smart (power) grid, is likely to lead to the ‘smartening’ of household appliances. The military use of all sorts of drones also spearheads more peaceful applications of such self-reliant devices that can e.g. perform tasks on behalf of us in hostile or unpleasant environments.

The evolution of information technology brings an abundance of new opportunities to enterprises. Technology becomes part of almost everything and most processes have become IT reliant, if not fully automated. The technological evolutions confront enterprises with the question of which technologies are relevant to the enterprise? Which technology should be replaced and which technology could be of use for developing new products (or services) of to enter new markets [2]?

2.2 Continuous Motion as a Primary Business Process

As a result of a.o. the above discussed socio-economical and technical challenges, enterprises need to change continuously. Different kinds of, and views on, change in enterprise exist. Some examples include:

  1. 1.

    Large scale technology migrations [45] concerned with large scale migration of IT platforms.

  2. 2.

    Enterprise transformation [23, 53], concerned with pre-meditated and fundamental changes to an enterprise’s relationships with one or more key constituencies, e.g., customers, employees, suppliers, and investors.

  3. 3.

    Business innovation [18], dealing with continuous innovation of the business, its products and/or services.

  4. 4.

    Continuous process improvement and other forms of business process reengineering [14, 50].

  5. 5.

    Mergers & acquisitions of new parts of an enterprise [1].

  6. 6.

    Organisational splitting, the “inverse” of mergers & acquisitions [41].

  7. 7.

    Organisational drift, dealing with gradual misalignment between an enterprise’s original intent (strategy, business model, operating model, etc.), and the actual operational activities [36]Footnote 1.

  8. 8.

    Self-organisation by self-steering teams [5, 44].

  9. 9.

    Bricolage & emergence may, as argued by Ciborra [13], provide enterprises with strategic advantages in terms of the bottom-up evolution of socio-technical systems that will lead to outcomes that are deeply rooted in an enterprise’s organizational culture, and hence much more difficult to imitate by others.

We suggest to generalize these different flavours of change in enterprises to “enterprises in motion”, where the word motion refers to “an act, process, or instance of changing place” [38].

It is important to note that enterprises do not just change by means of pre-meditated change programs. We even go as far as to argue that small changes actually make up the bulk of an enterprise’s motion. As such, these seemingly small changes should be taken into due consideration as well (e.g. to identify organizational drift). For example, it is quite common that business processes are not executed as designed. People working in an enterprise are likely to make changes to the design of business processes just ‘to make it work’. Either to make it work for the individual worker, or because the designers did not realize all the variety and complexity one has to deal with in the day to day operations of the enterprise. One might even argue that business processes only work, because people will make them work, even if they are not designed well enough. Should senior management be aware of such changes? We take the stance that, in view of challenges such as the ‘Comply or bust’ challenge, the answer is: potentially yes.

Another example would be the use of technologies such as social media (LinkedIn, Facebook, etc.), cloud storage (Dropbox, Google Drive, etc.), and privately owned mobile devices (Tablets, smart phones, etc.). The use of such technologies leads to several bottom up changes of the IT used in support of business processes. Co-workers may start sharing work files within, or beyond, the enterprise using cloud storage services, they may also start using their own mobile devices (BYODFootnote 2) in the office, etc. Once ‘detected’, enterprises may respond to such changes in different ways. It usually leads to a pre-meditated response, where one e.g. forbids the use of some forms of new technology, provides more controlled alternatives, or even fully embraces the developments. Underlying all of this, one can usually see a struggle between ease-of-use, and security and risk considerations. This trade-off, once again, illustrates the need for senior management to ultimately be aware (to a level relevant to them) of such developments.

Given the needs of modern day enterprises to be constantly in motion to meet ever changing challenges, we also argue that the continuous motion of an enterprise is actually one of its primary business processes, next to the ‘normal’ operational business processes. As such, the business process for continuous motion deserves careful design and management.

2.3 Motioning the Running Enterprise

Based on the view that enterprises are continuously in motion, we suggest to make a distinction between two aspect systems of an enterprise: the running aspect system and the motioning aspect system. Where the motioning aspect concerns the actions involved in changing the enterprise, the running aspect concerns its regular operational activities. This situation is illustrated in Fig. 1. Note that the motioning system can motion both aspect systems. In other words, the motioning system can change itself as well.

Fig. 1.
figure 1

Motioning and running aspect systems.

Full size image

Being aspect systems, the actual social (and technological) actors in an enterprise can play roles (simultaneously) in both aspect systems. We argue that this is actually quite normal for us as human beings. While doing our day-to-day activities we also tend to reflect, depending on our personal goals, on how to make these activities more efficient, effective, pleasurable, etc., while consequently making the necessary changes. In the case of e.g. changes by self-steering teams, there is likely to be a larger overlap between the actors playing roles in both aspect systems, while in the case of pre-meditated and large scale change, this overlap will be less (but still essential and existent).

The authors of [4] suggest to distinguish between multiple levels of motioning: improvement to deal with minor optimizations, transformation to deal with structural changes, and improvisation covering ‘out of bound’ situations (e.g. when competitors introduce a game-changing product/technology, or unexpected socio-economical developments).

3 Steering the Motion of Enterprises

Given the potential impact which the challenges as discussed in Sect. 2 may have on an enterprise, and that as a consequence enterprise are continuously in motion, we argue that there is a need to steer this motion. It needs to be ensured that the motion is in line with the overall purpose and strategy of the enterprise, while also staying within the bounds of e.g. external regulations.

3.1 Steering

In terms of Fig. 1, this leads to the introduction of two additional aspects systems: the producing and steering aspect systems. This distinction runs orthogonal to the distinction between the running and motioning systems. The resulting situation is depicted in Fig. 2. The production aspect is concerned with the actual performance of activities of e.g. the motioning system (i.e. making changes) or the running system (e.g. producing products or delivering services). The steering aspect is concerned with the overall steering of the activities of the production system, such as ensuring their mutual alignment, efficiency and contribution to the overall goals (e.g. the purpose of the enterprise), as well as compliance to external regulations. According to the dictionary [38], to steer specifically means:

Fig. 2.
figure 2

Producing and steering aspect systems.

Full size image
  1. 1.

    to control the direction in which something (such as a ship, car, or airplane) moves;

  2. 2.

    to be moved or guided in a particular direction or along a particular course.

We consider this to be applicable to the motion of an enterprise as well.

Note again that Fig. 2 concerns aspect systems, so actual (human or technological) actors in the enterprise may play roles in all four aspect systems as identified in Fig. 2.

Depending on the enterprise, its purposes, context, and concerns, the steering system can use different styles of steering. For example, a restrictive top-down style of control approach, or a more laissez-faire based care-taking/stewarding approach. It may also apply different rhythms towards steering the activities in the producing system. For example, a regular planning-based approach or a more evolutionary/agile approach in line with e.g. the Deming cycle [15].

3.2 Control Paradigm

The role of the steering system can be illustrated more specifically in terms of the control paradigm (see Fig. 3) from management science [34, 35]. The essence of the control paradigm is that during the execution of a process there is some kind of interaction with the environment (input and output), and that this process is controlled by some authority which monitors, and if necessary adjusts, the process to make sure the intended objectives are reached. For the controlling system to operate effectively, it needs awareness of:

Fig. 3.
figure 3

The control paradigm, taken from [34, 35].

Full size image
  1. 1.

    the current & anticipated steering goals, concerns and constraints,

  2. 2.

    the state & motion of the object’s environment,

  3. 3.

    the state & motion of the object itself,

  4. 4.

    the impact of earlier interventions.

In addition, it requires the abilities to:

  1. 1.

    perform a SWOT analysis of the motion of the object and its environment, in relation to the coordinative goals and constraints, as well as earlier intervention actions,

  2. 2.

    formulate (when needed/desired) an intervention plan to influence the object and/or its environment,

  3. 3.

    perform an intervention plan.

3.3 The Sense-Think-Act Paradigm

From a theoretical point of view, the control paradigm is based on the more general notions of cybernetics [6] and feedback systems [7]. The field of robotics has developed a variation of the control paradigm in the form of the Sense-Think-Act paradigm [25, 55]. In terms of Fig. 3, sensing corresponds to the two arrows leading into the control system, while thinking is internal to the control system, and acting corresponds to the two outgoing arrows. As a consequence of its origins in robotics, sensing, thinking and acting is inherently intended as a continuous process involving rapid revolutions of a Deming [15] alike cycle.

In terms of the requirements on a controlling system, we would have the following correspondence:

  1. 1.

    Sense: (1) the current & anticipated coordinative goals and constraints, (2) the state & motion of the object’s environment, (3) the state & motion of the object itself and (4) the impact of earlier coordinative interventions.

  2. 2.

    Think: (1) perform a SWOT analysis of the motion of the object and its environment, in relation to the coordinative goals and constraints, as well as earlier intervention actions, and (2) formulate (when needed/desired) an intervention plan to influence the object and/or its environment.

  3. 3.

    Act: perform an intervention plan.

We argue that sensing, thinking and acting are actually more specific aspect systems of the steering system from Fig. 2. For enterprises in motion, this leads to the situation as shown in Fig. 4. The sensing aspect system observes the environment, the performing of motioning system, as well as the running system as a whole. It acts by influencing the performance part of the motioning system.

Fig. 4.
figure 4

Sense, Think and Act aspect systems added.

Full size image
Fig. 5.
figure 5

Role of a way-of-thinking.

Full size image

It should be noted that the sense-think-act paradigm, and associated aspect systems, can be applied to all four quadrants of Fig. 2. The steering aspect system only refers to the overall steering of activities, of both the motioning and running systems. In other words, the producing system certainly involves its own (local) steering/control systems, e.g. human actors planning/steering their own work activities. In Sect. 4.2 we will return to this issue.

3.4 Role of the Way-of-Thinking

In the context of designing and engineering of information systems and enterprises, several frameworks have been developed. These include, for example, Zachman [67], SEAM [65], and DEMO [51]. In [54], Seligmann et al. argue that system design and development methodologies are based on a way of thinking that verbalises the assumptions and viewpoints of the method on the kinds of problem domains, solutions and designs that can be developed. This notion is also referred to as die Weltanschauung [56], underlying perspective [37] and philosophy [8].

We argue that in the context of enterprises in motion, it is necessary to take the way of thinking explicitly into account. This is illustrated in Fig. 5. The way of thinking influences the sensing in the sense that it implicitly biases that what is sense-able, i.e. that what can be observed. Similarly, it influences/biases that what is considered to be think-able, and ultimately act-able. More specifically, it means e.g. that the used design and engineering framework, e.g. the above mentioned Zachman [67], SEAM [65], or DEMO [51] frameworks, influences what is sense-able, think-able and act-able upon by the steering system.

3.5 Second Order Information Systems

The motion-steering system can be regarded as a second order information system [26]. As such, it is actually to be regarded an information system in the broad sense, as it involves both human and computerised actors. Needless to say, that IT can play an important role in this information system [47].

In this vein, techniques such as process mining [3], software cartography [57, 58] and enterprise cartography [58] are examples of IT based techniques that can support the sensing activities of the motion-steering system. Similarly, IT based techniques can be used to support the thinking and acting activities.

4 The Role of Enterprise Architecture

We now turn to the role of enterprise architecture in the context of the motion-steering aspect system of an enterprise.

4.1 Enterprise Architecture

In line with the definition provided in [22] we regard architecture as essentially being about: “Those properties of an artefact that are necessary and sufficient to meet its essential requirements”. The focus on the properties that matter, is also what distinguishes it from design. Consequently, an enterprise architecture focuses on those properties of an enterprise that are necessary and sufficient to meet its essential requirements. This includes, in principle, all aspects of Fig. 2, in particular the running, motioning, producing, and steering aspect systems.

The reference to properties that are necessary and sufficient to meet its essential requirements introduces subjectivity to the scoping of architecture: Who determines what the essential requirements are? What is indeed to be regarded as essential, or not, is in the eyes of the beholder. It strongly depends on the purposes, goals and associated concerns, of the individual stakeholders. This, in particular, means that the essential requirements can be linked directly to the enterprise’s (past/current) strategy, next to other core concerns of the key stakeholders [22]. As such, we argue that enterprise architecture should first and foremost be about essential sense-making in that it should primarily:

  1. 1.

    make sense of the past and future of the enterprise with regards to the way it has/will meet its essential requirements as put forward by its core stakeholders and captured in its strategy;

  2. 2.

    provide clear motivations/rationalisation, in terms of the above essential requirements, as well as e.g. constraints, of the trade-offs that underly the presence of the elements (e.g. building blocks or architecture principles) included in the architecture.

This will enable enterprise architects and senior management to take informed decisions about an enterprise’s motion. In line with this, we argue that:

  1. 1.

    the purpose of an enterprise architecture is (i) to understand the current motion of the enterprise, including its past and its likely future motion and (ii) formulate, as well as motivate/rationalize, the desired future motion and the interventions needed to achieve this;

  2. 2.

    its meaning is that it expresses, in relation to the (current) essential requirements: (i) the understanding how the enterprise has evolved so-far, (ii) what the expected natural motion of the enterprise is and (iii) the desired future motion of the enterprise and actions needed to change/strengthen the current motion;

  3. 3.

    its elements should focus on the fundamental properties that have played a role in its past motion, as well as its expected/desired future motion.

It is important to note that while an enterprise is in motion, it is likely that the understanding of what the essential requirements are, will change. This means that the boundary between what was included in the architecture and what is considered design may also shift over time.

4.2 Levels of Steering

Given the fact that an enterprise architecture forms a bridge between strategy and design [16, 42], it follows that the motion-steering system actually involves (at least) three levels of steering. These are illustrated in Fig. 6.

Fig. 6.
figure 6

Levels of steering.

Full size image

At the top level we find the steering of strategically relevant issues. This concerns the definition and evolution of the enterprise’s strategy. Depending on the goals and concerns that are involved in the strategic thinking level, the border between the strategic level and the architectural level would need to be adjusted. Needless to say, that this border cannot be fixed a priori. It will depend on the situations and concerns as they evolve.

At the next level, we find the architectural level. There the same applies. Depending on the essential requirements that follow from the strategic level, as well as the goals and concerns of the stakeholders, the border between the architectural level and design level can be adjusted. Again, this border cannot be fixed a priori as well. For example, a shifting societal focus towards e.g. the carbon footprint of the production of services and goods, may all of a suden trigger the architectural need to study the carbon impact of the enterprise’s business processes. This would entail the need to, at an architectural level, now consider and design business processes at a finer level of detail then before.

As suggested in TOGAF [60], the architectural level might be subdivided into additional levels, e.g. a strategic, a segment, and a capability architecture level.

The last level of the steering system involves the design level. This design level is filled in by e.g. system development projects and/or decisions by self-steering teams on how they plan/organize their work.

Note that, Fig. 6 does not suggest that the decision makers involved in one level of thinking cannot be involved in another level. On the contrary. We argue that the decision makers at the strategic level (i.e. senior management) should also be involved in (some of) the decisions taken at the architectural level, and similarly, decision makers from the architectural level (i.e. architects) should be involved in decision making at the design level.

The circles on the four thinking boxes are a reminder of the fact that each of these levels of thinking has (its own) way of thinking (see Fig. 5) that influences/biases its sensing, thinking and acting abilities.

The left hand side of Fig. 6 shows the input, i.e. the abstraction (typically in terms of models) of the sensing activities, to the thinking activities. To stress the fact that this should not just involve the current state, but rather a historical perspective and current trends of the entire enterprise, we refer to this input as the current & past affairs Footnote 3. The dotted arrows on the left side of Fig. 6 illustrate that the lower levels can take the higher levels of information as (contextual) input.

The right hand side of Fig. 6, represents the results of the thinking activities. In other words, the intentions/plans for action. The dotted arrows illustrated the fact that the lower levels need to be compliant to the higher levels. As such, the (higher level) intentions are also a part of the input for the at the lower level. This is signified by the fat arrow running across the top of the diagram.

It should be noted that, as also argued in [11, 23], there is a potential correspondence between the different levels of steering and the Beer’s viable systems model [9]Footnote 4. For more details, refer to e.g. [11, 23]

4.3 Ingredients of Architecture

Given our current understanding of the role of architecture, and the related activities, we will now list what we regard as being the key ingredients of architecture. We have grouped these into five frameworks concerned with: stakeholder engagement, design motivation, structuring the design thinking, communication of architectures, and the architectural process, respectively.

Engagement Framework. Architectural decision making is not only the work of architects. It should involve several stakeholders within, and possibly beyond, the enterprise. Architecture methods/approaches such as SEAM [65], GEA [64] and CAEDA [39] focus on the involvement of stakeholders.

A distinction can be made between the identification of the groups of stakeholders that needs to be involved, e.g. in terms of GEA’s dashboard [63], on one hand, and strategies to deal with their actual involvement in gathering requirements, designing and decision making as provided in SEAM [65] and CAEDA [39] on the other hand. Together, they provide a framework for stakeholder engagement, clearly identifying which stakeholder groups to involve, when to involve them, what their interests/purposes are, and how to involve them in the architectural thinking process.

Which stakeholders groups to involve depends highly on the strategy and focus of an enterprise, as well as its internal and external social-political constellation. Traditional approaches and frameworks, such as the Zachman [59] framework, provides a pre-defined grouping of stakeholders. As argued in [63], this grouping should be more organization and situational specific.

Motivation Framework. As argued in [49], several lines of reasoning can be used in architectural thinking, a very important one being the design motivation dimension. It bridges between needs and solutions. Building on the work reported in [61], we suggest to distinguish three levels:

  1. 1.

    Why – Needs of the stakeholders towards different elements of the enterprise. In the case of architecture, the focus will be on the essential goals and needs of the stakeholders.

    The needs are to be formulated in terms of goals and activities of the stakeholders. For example, in terms of the affordance [21] (a property of an object, or an environment, which allows an individual to perform an action) towards the activities of the stakeholder, or the positive/negative value it may bring to the stakeholder in general. A linkage to the goal-oriented requirements engineering [32] is apparent.

  2. 2.

    What – Requirements towards the solution design space. Where the stakeholder needs are formulated in terms of the experience, value, or usage space of stakeholders, the requirements are formulated towards the actual design space of the enterprise and its constituting elements. At an architecture level, these requirements may take the form of so-called architecture principles [22].

  3. 3.

    How – Designs concerned with the composition/selection of actual building blocks of the enterprise. At an architecture level, this typically takes the form of e.g. models in terms of ArchiMate [33], BPMN [40] or DEMO [51] models.

The above three levels suggest a motivational flow from the needs of stakeholders, via requirements limiting the design space, to the actual design itself. The missing link, however, are the actual design motivations. The selection of design elements must be motivated in terms of requirements, while requirements must be motivated in terms of actual needs. The desire to bridge this gap, fuels work on the rationalisation of architectural design decisions [19, 43].

Design Framework. Where the stakeholder engagement framework identifies the groups of stakeholders to involve in the architectural thinking processes, a design framework is needed to structure the actual architectural thinking. It embodies, and structures, the way of thinking about the enterprise as a designable artefact.

This is where existing frameworks/approaches for the architecting, design, or engineering, of enterprises, such as DEMO [51], Zachman [59], TOGAF’s content framework [60], IAF [66], GERAM [29] or ArchiMate’s [28, 33] core framework, can play their main role. They provide (parts of) the way of thinking that can be used to structure the actual architectural thinking. Where necessary, existing frameworks and approaches can be combined. For example, combining the ontological focus of DEMO with the more implementation oriented focus of ArchiMate [30, 52].

Depending on the concerns of stakeholders, more specific extensions of the design framework may be necessary. For example, extensions dealing with security and access control [20].

Both the design and motivation frameworks should have an underlying modelling landscape that integrates the different aspects of the enterprise that are considered relevant from the perspective of the design framework [10]. Standards such as ArchiMate [28] provide a good starting point. However, as argued in [10], more flexibility is needed to cater for organization/context specific language use and/or refinements. Furthermore, the design and motivation frameworks should be used as the way of thinking (see Fig. 5) towards the sensing, thinking and acting activities at the architectural steering level.

Communication Framework. Where the engagement framework provides a view on who to communicate with, and the motivation and design frameworks set the level and topics about what to communicate about, the communication framework should define how to communicate.

In [48] a detailed discussion is provided on how to create different communication strategies for architectures. This involves a tuning between the audience involved in the communication, the purpose of communication (e.g. informing or decision making), the characteristics of the information to be communicated, and the strategy used.

Process Framework. The final ingredient concerns the processes involved in ‘doing architecture’. In other words, architecture process frameworks including e.g. TOGAF’s ADM [60], GERAM’s process framework [29] and DYA [62], while GEA [64] also provides explicit processes to include the identified stakeholder groups.

We argue that the chosen/composed processes framework should always involve activities pertaining to the continuous (e.g. PDCA [15] alike) sensing, thinking and acting, while using the engagement framework to engage the right stakeholder groups, and using the design framework to structure the architectural thinking. We find that existing architecture approaches tend to put a strong emphasis on the thinking aspect, quite often even without the use of an effective engagement framework.

5 Conclusions

In this position paper, we investigated the potential role of enterprise architecture as a means to support senior management in steering enterprises in motion. We presented our fundamental understanding of the playing field, in which enterprise architecture is to play a role, based on a.o. the control paradigm.

We also argued that the motion-steering system of an enterprise is essentially a second order information system, yielding several future challenges for the field of information systems [47].

Based on this, we also identified different levels of steering enterprises in motion, positioning architectural steering (and thinking) in between strategic level steering and design level steering. Finally, we suggested the key ingredients of enterprise architecture as being: an engagement framework, a motivation framework, a design framework, a communication framework, and a process framework.