On enterprise coherence governance with GEA: a 15-year co-evolution of practice and theory

Abstract

General Enterprise Architecting (GEA) is an enterprise architecture method which has emerged out of a need in practice, and has been developed and matured over the past 15 years. The GEA method differs from other enterprise architecture approaches in that it has a strong focus on enterprise coherence and the explicit governance thereof. This focus followed from the observed need to move beyond the Business-IT alignment and ‘Business-to-IT’ stack thinking that is embodied in most of the existing enterprise architecture approaches. The main objective of this paper is to report, and reflect on, the development of the GEA method (so-far), which involved a co-evolution between theory and practice. In doing so, we also present core elements of (the current version of) GEA, and illustrate these in terms of a real-world (social housing) case. We will, furthermore, also discuss some of the lessons learned in applying GEA across different organizations.

1 Introduction

The environment in which modern day enterprises (including commercial companies, government agencies, etc.) need to operate, changes constantly. As a result, enterprises transform almost continuously to keep up with these changes. One could even go as far as to say that enterprises need to stay ‘in motion’ [35]. The involved transformations may range from changes in value propositions and business processes, via changes to the information systems used to support the business processes, to changes of the supporting software applications and IT infrastructures. Furthermore, the transformations may be the result of a ‘premeditated’ (strategy driven) desire to change, but they can also be the outcome of numerous ‘spontaneous’ changes as a result of locally needed, or induced, changes.

Enterprise transformations are also likely to touch upon a rich mix of aspects of the enterprise, such as human resourcing, finance, organizational structures, reporting lines, etc.; i.e. not just ‘Business’ and ‘IT’. As a consequence, enterprise transformations typically involve many stakeholders [55] with differing stakes and interests, who (should) influence the direction, or the speed, of the transformation.

To make (premeditated) enterprise transformations feasible and manageable, they are typically managed as a portfolio of transformation programmes, where these programmes are split further into projects. Such a portfolio of programmes and projects, together with the ‘spontaneous’ (bottom-up) changes, all need to be mutually coordinated, while, at the same time, also maintaining a strong cohesion with the enterprise’s strategy. A lack of such coordination will likely lead to ‘local optimizations’ favouring short-term, or local, interests over the overall longer-term interests of the enterprise. The latter ultimately leads to a degradation of the enterprise’s coherence in terms of a logical, consistent, and connected, structure across the enterprise’s strategy, the implementation of its key capabilities as an integrated whole, and its portfolio of products and services [21, 22, 38, 42]. More specifically, Leinwand and Mainardi [21, 22] have shown there to be a positive correlation between an enterprise’s level of coherence and its level of performance.

Project and programme management have, traditionally, been put forward as being responsible to guard, or even improve, such coherence during transformations. However, these approaches focus primarily on the management of typical project parameters such as budgets, resource use, deadlines, etc.; i.e. “on time and within budget”. When being too focused on such project parameters, one runs the risk of conducting only local and or partial improvements at the level of specific projects [38]. For example, when making design decisions that have an impact which transcends a specific project, projects are likely to aim for solutions that provide the best costs/benefits trade-off within the scope of that specific project, while not looking at the overall picture [30, 38]. Regretfully, however, in practice such local optimizations do not just remain a potential risk. More often than not, this risk materializes, resulting in reduced structural coherence of important aspects of the enterprise (such as human resources, services, customers, processes, marketing, finance, physical infrastructures, software applications, IT, etc.). As a result, enterprises often fail to actually realize the desired transformation; even when the involved projects may have finished on time and within budget. In [30], the authors provide a summary of possible causes for failures of strategic initiatives: “The road from strategy formulation to strategy execution, including the use of programmatic steering, is certainly not an easy one to travel. Research shows that less than 60% of the strategic objectives in organizations are reached”.

As an answer to this, enterprise architecture has been positioned as a means to enable the needed coordination [7, 30, 38, 46]. At the same time, however, one has to observe how most existing enterprise architecture approaches,¹ including the Zachman framework [41], DYA [48], TOGAF [44], IAF [66], and ArchiMate [13, 17], follow an ‘engineering oriented’ style towards enterprise transformation embodied in a pre-defined ‘design framework’ identifying different (design) perspectives in terms of which the (architecture of the) enterprise should be designed. In general, these design frameworks follow a ‘Business-to-IT-stack’ [65] style of thinking in identifying the different (design) perspectives. In practice, we have also observed how the traditional notion of Business-IT alignment [9] often results in a de-facto use of a design framework involving only two perspectives: (1) everything pertaining to IT, and (2) everything else. In many organizations, this essentially results in a ‘Business as everything non-IT’ mindset.

What is also important to acknowledge, is the fact that enterprise architecture as a discipline ‘grew’ out of the IT domain [36, 65]. This is illustrated by, for example, the history of TOGAF [44], which started out from the IT focused TAFIM [43], as well as the discussion between enterprise architecture and enterprise-wide IT architecture [36] What is also interesting to note is that the original paper on the Zachman framework [41], claimed by many as being starting point of enterprise architecture, speaks primarily about information systems architecture (as its title suggests), while not referring to ‘enterprise’ at all. In practice we have observed, including organizations involved in GEA’s development$^{2}$, how these ‘IT roots’ strengthen the ‘Business as everything non-IT’ mindset.

While the design frameworks, as proposed by existing enterprise architecture approaches, are useful to structure the actual design effort by providing a clear framework of potentially relevant aspects of the design, they are less suitable to structure the needed coordination among stakeholders and concerns that play a role in a specific enterprise. For instance: the Zachman framework [41] only provides a design framework; IAF [66] provides a design framework and a set of concepts (essentially a meta-model) in terms of which an architecture can be described; DYA [48] provides a design framework as well as an overall process on how to structure a ‘just enough architecture’ based process; ArchiMate [13, 17] provides a design framework and a modelling language to capture enterprise architectures in line with this framework. TOGAF [44] does suggest to initiate an ‘Architecture Board’, which to some extent could play a positive role towards coherence. However, TOGAF does not provide a structural way to identify which concerns and groups of stakeholders should be represented on the ‘Architecture Board’.

To coordinate change, and ultimately ensure enterprise coherence [21, 22], stakeholder interests, formal and informal power structures within enterprises and its context, as well as the associated processes of creating win-win situations and forming coalitions, should be taken as a starting point [23, 47, 55, 62]; i.e. not just as an afterthought in terms of stakeholder specific ‘viewpoints’ [19]. As mentioned before, the work by Leinwand and Mainardi [21, 22] has shown there to be a positive correlation between a level of coherence and a level of performance. The need to take stakeholder interests, formal and informal power structures, etc., as a starting point to improve and/or ensure coherence, can also be motivated in terms of what Conklin [5] refers to as fragmentation in the context of projects and/or programmes: “ Fragmentation suggests a condition in which the people involved see themselves as more separate than united, and in which information and knowledge are chaotic and scattered. The fragmented pieces are, in essence, the perspectives, understandings, and intentions of the collaborators. ”

As we will see in Sect. 2, GEA identifies organization specific enterprise coherence perspectives to coordinate transformations and govern enterprise coherence. GEA cases (see Table 2 on page 17) usually involve around 10 such perspectives. Of these perspectives, a majority of these (enterprise coherence) perspectives involve different aspects across the ‘Business-to-IT stack’. As we will also see in Sect. 2, the existing design frameworks certainly have an important role to play in further structuring the (topics to be involved in the) coordination between the enterprise coherence perspectives.

In 2006, these insights triggered the Dutch consultancy firm Ordina to initiate a multi-client research programme to develop an enterprise architecture method that would indeed focus on enterprise coherence and the need to more explicitly coordinate and govern this coherence during enterprise transformations. By 2007 this resulted in the formal establishment of a multi-party² research and development program.³ This programme has resulted in the development (and ongoing evolution) of the GEA method [42, 46, 50].

Even though the group$^{2}$ of (Netherlands based) organizations participating in the development of the GEA method includes, for example, banks, pension funds, and logistic companies, there is a strong presence of governmental agencies. This may be a natural consequence of three factors. Firstly, the specific branch of Ordina that initiated the development of GEA was Ordina Public, which specifically targets clients in the public sector. Secondly, government-related organizations generally (certainly within the Netherlands) are open to collaborative improvement and maturation of enterprise/digital transformation. Thirdly, such transformations in a public context tend to involve a wider variety of stakeholder across different organizational entities, while at the same time requiring a more consensus based decision making process. With the latter we do not want to imply that this is necessarily different in other sectors (e.g. industry, finance, etc.). However, the combination of these factors did lead to a strong participation from the public sector.

The goal of this paper, which provides an elaboration on [37], is to (1) reflect on the development of GEA as a co-evolution between theory and practice, while also (2) presenting the core of (the current version of) GEA and illustrating this in terms of a real-world (social housing) case, as well as (3) discuss several lessons learned in applying GEA across different organizations. In line with this, the remainder of this paper is structured as follows. We start, in Sect. 2, with a discussion of the core elements of the (current version of) the GEA method, where we will use the real-world case of a Social Housing Foundation (De Key⁴) to illustrate these elements. Section 3 then briefly reports on the research methodological setup of the GEA development programme. We continue in Sect. 4 with a report on the development of the GEA method as a co-evolution of practice and theory, and some of the lessons learned related to this. In doing so, we will also clarify why we prefer to speak about co-evolution, and why we put practice before theory. In Sect. 5, we then reflect on the use of GEA across multiple (large) cases. Finally, in concluding, we will also discuss some further directions in which we plan and expect GEA to (co)evolve further.

2 Main elements of GEA

In this section, we present the main elements of the GEA method [42]. GEA considers enterprise architecture to involve a set of guiding statements, processes, products, people, and means that are used to direct the development of an enterprise, with a focus on coherence. The GEA method aims to contribute to the improvement of the coherence of an enterprise by way of an active participation of enterprise architects in the governance and control processes of an enterprise, while providing senior management with continuous insights into the coherence of relevant aspects of the enterprise and its environment. In doing so, GEA intends to complement existing enterprise architecture approaches, such as Zachman [41], DYA [48], TOGAF [44], IAF [66], and ArchiMate [13, 17].

Below we summarize the key elements of the GEA method, as it currently stands, after 15 years of use in practice and regular improvements [42]. We will start, in Sect. 2.1, with a discussion of enterprise coherence which is the key focal point for the GEA method. For a given enterprise, the generic notion of enterprise coherence is operationalized in terms of its level of purpose and level of design, which are discussed in Sects. 2.2 and 2.3, respectively. This is followed in Sect. 2.4 with the notion of enterprise issue, which captures the main driver for ‘doing’ a GEA iteration. The ‘solution’ of an enterprise issue is captured in terms of an integral solution contour, which will be discussed in Sect. 2.5. Finally, to guide the process of applying GEA to a (new) enterprise issue, the GEA method provides a road-map; which we will summarize in Sect. 2.6.

Fig. 1

The elements of coherence at level of purpose [42]

We will illustrate main elements in terms of a recent case in which GEA was applied, involving a social housing foundation De Key$^{4}$. This case also features as an illustrative case in [37, 42]. In this paper, we only provide a summary of the De Key case. For a more elaborated discussion of this case, please refer to [42, pp. 100–114].

2.1 Enterprise coherence

In [22], Leinwand and Mainardi define coherence, in the context of companies, as: “For a company to be described as coherent, it must be resolutely focused and clear-minded about three critical elements: its market position (its chosen ‘way to play,’ if you will); its most distinctive capabilities, which work together as a system; and its products and services portfolio”. The GEA method subscribes to this definition, but starts out from a more generic vantage point by defining enterprise coherence as “the extent to which all relevant aspects of an enterprise are interconnected, such that these connections facilitate an enterprise in achieving its management’s desired results” [42]. GEA’s “achieving its management’s desired results” is a more generic way of considering the Leinwand and Mainardi’s “market position (its chosen ‘way to play,’ if you will)” and choices regarding which capability are to be considered to be “most distinctive capabilities”. Furthermore, the “the extent to which all relevant aspects of an enterprise are interconnected” in GEA’s definition is a more generalized way to refer to the “which work together as a system” in the context of “most distinctive capabilities, which work together as a system; and its products and services portfolio”.

The operationalization of the (generic) definition of enterprise coherence in the context of a specific enterprise involves the creation of an enterprise specific GEA framework [59, 61]. This framework involves ten kinds of elements of coherence (see Fig. 2, on page 7, for an overview) that, for a given enterprise, operationalize the “relevant aspects of an enterprise” that need to be interconnected. This framework revolves around the notions of level of purpose and level of design, which are discussed in Sects. 2.2 and 2.3, respectively, where, for example, the relevant relationships embody the “the extent to which” from GEA’s definition of enterprise coherence.

2.2 Level of purpose

The level of purpose is the level at which GEA considers the meaning and purpose of an enterprise. At this level, GEA essentially adopts the “Strategic Development Process Model” as proposed by Kaplan & Norton [15], the “Strategy Formulation” approach by Thenmozhi [45] and the notion of endless pursuit of a company’s mission from “Building Your Company’s Vision” by Collins & Porras [4]. These ways of thinking were at use at, or at least know to, the initial members$^{2}$ of the GEA project. As such, it was a pragmatic choice in the development of GEA to use these ways of thinking as a starting point. Based on this, GEA distinguish five key elements to capture the level of purpose: mission, vision, core values, goals and strategy, see Fig. 1.

The mission involves a brief, typically one sentence, statement that defines the fundamental purpose of the organization [15] that is “enduringly pursued but never fulfilled” [4]. It should include what the organization provides to its clients and inform executives and employees about the overall goal they have come together to pursue [15]. The “enduringly pursued but never fulfilled” qualification refers to the fact that the act of achieving a mission is never finished; realizing the fundamental purpose is an ongoing effort.

The vision is a concise statement that operationalizes the mission in terms of the mid to long-term goals of the organization. The vision should be external and market oriented and should express – preferably in aspirational terms—how the organization wants to be perceived by the world [15]. Core value statements prescribe a desired behaviour, character and culture [15] and are required for an enterprise to be, or become, successful within its formulated vision. Goal statements involve a formulation of a desired stage of development for an enterprise working towards achieving the enterprise’s vision [15]. The strategy involves a comprehensive master plan in which it is stated how an enterprise will achieve its goals. It should also maximize the competitive advantages and minimize competitive disadvantages [45].

Table 1 Excerpt of De Key’s Mission-Vision matrix [42]

It is interesting to note that in some organizations there might be some scepticism, or even ‘change fatigue’, towards the formulation and realization of the level of purpose. We would argue that this is often actually an indication of a strong lack of coherence between the level or purpose and the (actually realized) level of design.

2.3 Level of design

The level of design, is concerned with a high level perspective on the design of the enterprise, by which the level of purpose is instantiated. This level concerns perspectives, core concepts, guiding statements, core models, and relevant relationships:

• (Coherence) perspectives concern the vantage points from which one would like to contemplate and to govern the enterprise. The set of perspectives used in a specific enterprise depend very much on its formal and informal power structures. Both internally, and externally. Typical examples are culture, customer, products and services, business processes, information provision, finance, value chain, corporate governance, etc.

• Core concepts define the main vantage points in terms of which one wishes to contemplate and to govern a perspective.

• Guiding statements are internally agreed and published statements which give direction to desirable behaviour. These statements may involve overall policy statements, more specific objectives, as well as principles.

• Core models are models of one or more perspectives, based on, and in line with, the guiding statements of the corresponding perspective(s). Such core models can typically pertain to any aspect of the ‘business-to-IT stack’, from value propositions, via business processes to the supporting software applications and IT infrastructures.

• Relevant relationships are descriptions of the connections between the guiding statements from different perspectives.

As an indication across multiple cases, Table 2 (page 17) provides some indicators of the number of perspectives and guiding statements for typical cases (some of which have also been published).

It should be noted that next to the relevant relationships between the guiding statements (from different perspectives), there are other relationships between the ten different GEA elements that are investigated within the GEA method, to assess and/or improve enterprise coherence. More specifically: (1) mission statement versus vision statements (see, for example, Table 1), (2) mission statement and vision statements versus core values, (3) goals versus mission statement, vision statements, and core values, (4) strategy statements versus goals, (5) goals versus objectives, (6) core values versus principles, (7) strategy statements versus policy statements. This kind of confrontation leads to a number of matrices, such as the one shown in Table 1. The analysis is performed by the core team members. Next to basic cross referential analysis (as is the case for Table 1), this also involves the creation of matrices that express the degree of support. For instance expressing the level at which a mission statement supports the vision statement, or the level at which a goal supports a core value, etc. In the cells of such matrices, the degree of support is expressed in terms of the range from −3 to $+$3. This ranking is discussed with the board with regard to the level of purpose and with the perspective owners at design level. As we will discuss in Sect. 6, this activity can certainly benefit from automated support. Even more, the scoring should ideally also be based on some form of quantifiable evidence.

The resulting structure is exemplified in Fig. 2. The perspectives as shown there are just illustrative. The actual set of relevant perspectives in a specific situation is organization specific. Note that even though Fig. 2 only shows three relevant relationships, the general experience is that there will be about twice as many such relations as there are perspectives. These relationships provide the primary focus of the needed coherence between the different perspectives, in order to achieve and maintain an overall enterprise coherence.

Fig. 2

Elements of the GEA framework, [42]

The design frameworks underlying enterprise architecture approaches$^{1}$ such as: Zachman [41], DYA [48], TOGAF [44], IAF [66], and ArchiMate [13, 17], can be used to further structure, across each of the identified (coherence) perspectives, the scopes of the core concepts, guiding statements, core models and relevant relationships. More specifically, core models can be expressed in modelling languages such as ArchiMate [13, 17], BPMN [29], or UML [28].

2.4 Enterprise issue

The main driver for enterprises to apply GEA is to deal with an enterprise issue, since such issues either trigger (top-down) enterprise transformations, emerge during, or are caused by, ongoing (bottom-up or top-down) transformations. In general, an enterprise issue is defined as a problem, bottleneck, challenge, or alleged solution, which is considered and controlled from the context of different perspectives within an enterprise. An enterprise issue can be a ‘positive’ issue, such as the desire to innovate, move towards new markets, apply new technologies to become more efficient, etc. It can also be a ‘negative’ issue, such as a need to become more efficient, reduce costs, manage/avoid a loss of market share, become GDPR compliant, etc.

Enterprise issues can have both external and internal ‘causes’. Examples of external causes include the need to respond to changes in the environment, such as legislation, technological developments, demographic trends or changing competitive relationships. Examples of internal causes include a need to increase efficiency, cost control, and compliance with (legal) norms and standards. When the existing (base-line) structures of an enterprise has been documented in terms of, for example, (up-to-date) ArchiMate [13, 17] models, then these can be used to support such an analysis.

Enterprise issues may originate from the strategic level, i.e. primarily influenced by and/or influencing the elements at the level of purpose. They may, however, also pertain to more operational issues (more directly linked to the level of design), such as a major security breach (with the need to report this to a national authority), or discovered evidence of GDPR non-compliance.

Fig. 3

Guiding statements per perspective, [42]

2.5 Integral solution contour

As will be discussed in Sect. 2.6, ‘solving’ an enterprise issue involves the development of an integral solution contour at a global level. The integral solution contour is more than the sum of change initiatives, it is about meaningful coherence and the creation of mutually supportive initiatives, while also reinforcing changes within an enterprise to support and improve its performance. Initially, there may be contradictions with other change initiatives, there may be overlap, and change initiatives may clash with guiding statements from other perspectives. All change initiatives, starting with the initiatives with the highest priority must be examined for these problems. Any disagreements must be brought to the attention of the relevant perspective owners who must decide how these matters will be resolved. Once the disagreements have been solved, an integral solution contour can be described and submitted to the board of the enterprise for decision making.

In developing and capturing an integral solution contour, an enterprise architecture modelling framework such as ArchiMate [13, 17] can be used to express the solution contour, while also analysing inter-dependencies between different change initiatives [19]. Where needed, the solution contour can be elaborated further in terms of finer grained models (see [18]) expressed in languages such as BPMN [29] or UML [28].

2.6 Road-map

In solving enterprise issues, the GEA method suggests the use of the road-map as shown in Fig. 4. This road-map defines the steps required to arrive at an integral solution for an enterprise issue. In the case of De Key, for now, only the first four steps of the road-map have been performed (the dark grey elements in Fig. 4).

Fig. 4

The generic GEA road-map [42]; In dark grey the steps performed at De Key so-far

The road-map as shown in Fig. 4 is intended to be a reference model, which will need situational adjustments to a specific enterprise context [42]. As such, the road-map should be seen as a guide and checklist, and not as a ‘cook-book’ that must be strictly adhered to. Furthermore, the tasks within a step do not necessarily have to be carried out sequentially. They can often be done in parallel. The road-map involves different roles (such as enterprise architect, sponsor, stakeholders, perspective owners, issue owner, portfolio manager and programme manager), these are discussed in more detail in [42, page 136 ff.].

It should also be noted that this road-map is part of a broader methodological framework, as provided by GEA [42], for the governance of enterprise coherence. This includes mechanisms to monitor enterprise coherence, while the enterprise is ‘in motion’ [35] (due to bottom-up and/or top-down changes) [42].

The road-map starts with Step 1: initiating. The purpose of this initial step is to achieve clarity about the (change) process in terms of expected results, scope, staffing, everyone’s involvement and the starting documentation. This step involves four tasks:

• 1. Orienting to the situation— Before starting a GEA process, it is necessary to clarify the motivation/driver for doing so, while also assessing if GEA is a suitable tool to apply in the situation at hand.

• 2. Determining the scope of the enterprise— It is important to choose the scope of the enterprise in such a way that the influence of management on the implementation of the change initiatives is expected to be high enough to solve the enterprise issue.

• 3. Identifying interlocutors— Before starting substantive work, it is important to identify relevant interlocutors, who represent (with mandate) the different stakes, interests, and concerns, that need to be taken into consideration in solving (the) enterprise issue(s).

• 4. Assessing initial documentation— Once the enterprise issue and the scope of the enterprise have been determined, the next task is to collect all the relevant vision and policy documents. These include, for example, annual reports, annual plans, strategy notes, etc.

One of the important deliverables of this step is an artefact that identifies potential coherence perspectives and their potential owners (and stakeholders). This artefact serves as an important input to the next step, which aims to analyse the (existing) extent of enterprise coherence, also further refining the artefact.

The overall goal for Step 2: analysing the coherence is to make enterprise coherence explicit (and validated) in terms of a first version of the organization specific GEA framework (in terms of the enterprise’s level of purpose and level of design as discussed in Sects. 2.2 and 2.3, respectively). This step involves three tasks:

• 1. Analysing and categorizing statements, purpose and design level— Selected source documents from the enterprise are analysed and all the statements considered to be relevant are selected for the GEA framework.

• 2. Analysing the coherence— The analysis of the coherence takes place after identifying and categorizing the statements from the previous task, and involves an examination to what extent these statements are consistent and complete. This happens at the level of purpose, the level of design and between the levels of purpose and design (see Sects. 2.2 and 2.3).

• 3. Validating level of purpose and design— It is very important that the right stakeholders approve the explicitly determined levels of coherence found in their enterprise. This must be done to avoid discussions about the correctness and completeness of the guiding GEA framework used to develop a solution contour to an enterprise’s particular issue(s).

Subsequently, the enterprise issue itself is analysed in Step 3: analysing issue, with the aim of obtaining an unambiguous and clear description of the enterprise issue to hand. The overall goal of this step is to provide a good understanding of the enterprise issue for the perspective owners, so that they can achieve an integral solution contour for the enterprise issue at hand. This step involves three tasks:

• 1. Analysing the issue— A substantive analysis of the enterprise issue is performed in a workshop with the owners of the issue. An issue owner is the person responsible within an enterprise for the specific issue and responsible for implementing an effective solution.

• 2. Analysing the GEA guiding framework based on the problem— Based on a description of the issue to hand, it is necessary to test whether the GEA framework is sufficiently complete to use it to perform step 4.

• 3. Adjusting the guiding framework and preparing an integral solution contour workshop— The previous analysis can lead to adjustments of the GEA framework, on the levels of purpose and design. These changes are discussed here with comments on those responsible for them, i.e. board members and/or perspective owners.

The goal of Step 4: developing integral solution contour is to achieve an integral solution contour for the enterprise issue at hand. This step involves three tasks:

• 1. Obtaining change initiatives— An inventory of possible change initiatives for the enterprise issue needs to be created. This is commonly done in the form of a one-day workshop with the issue owner and perspective owners present.

• 2. Compiling an integral solution contour— The identified change initiatives are grouped into the actual integral solution contour.

• 3. Processing the integral solution contour in the GEA framework— When developing the integral solution contour, it is certainly possible that adjustments and/or updates have to be made to the GEA framework. Therefore, in this task, the GEA framework is (optionally) updated and it can be used in solving future enterprise issues.

The development of the integral solution contour does require a prioritization; especially in relation to, for example, the level of purpose, the enterprise issue, goals of change initiatives, principles, etc. In applying GEA in different organizations, it was found to be important to organize workshops with the ‘perspective owners’, involving a mix of group work and plenary sessions. This allows, in a relatively short period of time, for an identification (and commitment for) the most important change initiatives. During such workshops, the prioritization of change initiatives is supported both during the group work and the plenary sessions, and explicitly related to the interrelationships between the change initiatives and the triggers/causes, risks and implications of the issue at hand, as well as the extent to which the change initiatives are supported by existing guiding statements in terms of policy statements, principles and objectives.

The aim of Step 5: creating realization plan (for the) solution contour is to develop a project/programme plan for the realization of the integral solution contour. This step involves three tasks:

• 1. Translating solution contour into planning— Plot the change initiatives over time.

• 2. Estimating required capacity— For an enterprise to be able to accommodate the change initiatives and the associated developments in its portfolio, insight into the required capacity is also required to make the changes.

• 3. Drawing up a realization plan for the solution contour— When the integral solution contour has been set in time and capacity, the core team must draw up the realization plan for the solution contour.

Finally, Step 6: including developments in portfolio involves the (continuous) alignment of the realization of the realization plan with other changes taking place within the enterprise. It involves three tasks:

• 1. Sharing knowledge and background about realization plan— To position all changes from the change plan the right place in an enterprise’s overall change portfolio, it is critical that the managers responsible for the portfolio have a good understanding of the necessary change initiatives to be realized within their enterprise.

• 2. Analysing the relationship between the realization plan and existing portfolio— This involves a more in-depth analysis of how the activities in realization plan relate to the enterprise’s existing portfolio of changes.

3 Research methodological perspective

In this Section, we provide a summary of the research methodological perspective on the development of GEA. A more detailed discussion can be found in [63].

Fig. 5

Adoption of Design Science approach by the GEA programme [10, 11]

3.1 Design Science as the basic approach

In developing GEA, the GEA programme used the Design Science Research (DSR) methodology [11, 24]. More specifically, Fig. 5 shows how DSR has been applied in the GEA programme.

The box on the left-hand side of Fig. 5 represents the problem domain of the research programme, i.e. the environment of enterprise coherence governance consisting of organizations in the public and industrial area with more than 200 employees, a high degree of multiple forms of labour division, the business issues that influence the level of coherence and the people involved in enterprise coherence governance.

The boxes in the middle of Fig. 5 represent the two major phases of the research programme, i.e. the develop/build phase and the evaluation phase of the intended theory and artefacts (i.e. GEA). The box on the right-hand side of shows examples of the theories, frameworks, instruments, constructs, models, techniques, measures and validation criteria that were adopted to develop GEA, so that it supports the execution of enterprise coherence governance. Fig. 5 also shows that the GEA method actually consists of three components: ECA (Enterprise Coherence-governance Assessment) [56, 59], ECF (Enterprise Coherence Framework) [61] and ECG (Enterprise Coherence Governance-approach) [57, 62].

3.2 Adoption of DSR guidelines

Hevner, et al [11] provide seven guidelines for DSR. Below we highlight how the GEA programme has endeavoured to meet these guidelines.

Guideline 1: Design as an artefact— DSR must produce a viable artefact in the form of a construct, a model, a method, or an instantiation [11].

The key artefact resulting from the research programme is the GEA method, consisting of a theory and the core artefacts ECF, ECG and ECA.

Guideline 2: Problem Relevance— The objective of DSR is to develop ‘technology-based solutions’ to important and relevant business problems [11].

As shown in the left part of Fig. 5, the challenge addressed in the GEA research programme was the improvement of enterprise coherence governance.

Guideline 3: Design Evaluation— The utility, quality, and efficacy of a design artefact must be rigorously demonstrated via well-executed evaluation methods. Evaluation of an artefact can be done using empirical and qualitative research methods such as observational, analytical, experimental, testing or descriptive-oriented methods [11].

The lower box in the middle part of Fig. 5 shows the evaluation method used in the programme, being the multiple case study research approach from Yin [67].

Guideline 4: Research Contributions— Effective DSR must provide clear and verifiable contributions in the areas of the design artefact, design foundations, and/or design methodologies [11].

The lower middle part of Fig. 5 shows that the main contribution of the research programme to the knowledge base consist of the GEA method and its associated artefacts ECA, ECF and ECG as well as the publications reporting on its effect in practice.

Guideline 5: Research Rigor— DSR relies upon the application of rigorous methods in both the construction and evaluation of the design artefact. DSR artefacts are created based on existing foundations and methodologies in a knowledge base which include theories, frameworks, instruments, constructs, models, methods, instantiations, experiences, and expertise [11].

The right part of Fig. 5 shows the foundations and methodologies (i.e. existing literature) that we adopted in the development of GEA. The bottom of the left part of Fig. 6 shows that existing literature and experiences was be applied in the design, evaluation, and modifying phases of the research programme.

Fig. 6

Activities conducted to achieve the research objectives

Guideline 6: Design as a Search Process— The search for an effective artefact requires utilizing available means to reach desired ends while satisfying laws in the problem environment [11]. Design involves iterative research activities such as constructing, evaluating, and refining the artefact based on findings [10].

The major design activities that were carried out in the research programme to achieve the research objectives are shown in the right part of Fig. 6. It also shows that all the development activities to conduct in the research programme have been grouped into phase 1, phase 2 and phase 3. The result of phase 1 consist of the first version of GEA and the evaluation phase 2 formed the basis to modify GEA during phase 3 into the final version of GEA. In the left part of Fig. 6 the evaluation methods that were used in the research programme are shown.

While using DSR as the overall research approach, the GEA programme also used:

• The Multiple Case Study Research Approach as suggested by Yin [67] to conduct phase 2.

• The Anatomy of a Design Theory by Gregor et al. [8] was used to evaluate GEA.

• The DSR Methodology for Information System Research by Peffers et al. [32] was used as a ‘template’ for the GEA design process.

• In order to develop the initial versions of several of the GEA artefacts the group decision technique MetaPlan [40] was used.

Guideline 7: Communication of Research— DSR must be presented effectively both to technology-oriented as well as management-oriented audiences. Communication of the research programme was targeted both at academic and industrial audiences, more specifically leading to several scientific and industrial publications.

3.3 Implementation of the GEA programme

The GEA research programme itself was structured in terms of four groups:

• 1. A core team consisting of six to eight people with in-depth knowledge in the field of enterprise architecture.

• 2. A customer reference group representing the twenty major enterprises who co-financed the programme. These representatives involved policy makers, managers of enterprise architecture departments and lead enterprise architects.

• 3. An expert review team involving thirty lead enterprise architects.

• 4. A steering committee with seven leading representatives from science and industry.

To participate in one of these groups, candidate participants had to meet strict criteria:

• 1. For the core team, the participants were required to have in-depth knowledge of the field of enterprise architecture and a willingness to spent a considerable amount of time on the activities of the research programme.

• 2. For the customer reference group, participants were required:

  • to be working in one of the participating client organizations,

  • have a strong affinity with the discipline of enterprise architecture,

  • identify with the triggers and research problem of this research,

  • to be willing to discuss the interim results of this research on a regular basis and

  • to be willing (as an organization) to co-fund the research effort.

• 3. To be part of the expert review team, members were required to have an in-depth knowledge in the field of enterprise architecture and the willingness to thoroughly evaluate the interim results of this research within a relatively short time-span.

• 4. The scientific members of the steering committee were required to be among the leaders in their field. The industrial members of the steering committee were required to be employed/working at the boardroom level. All members of the steering committee were required to have the willingness (and commitment) to discuss the innovation strategy of this research on a regular basis.

The actual involvement (and composition) of these groups depended on the specific phase of the research programme. The results of the research activities, as conducted by the core team, were regularly discussed with (and evaluated by) the customer reference group. The members of the expert review team were charged with the responsibility to guard the quality by thoroughly evaluation the results. The steering committee regularly assessed the progress of the programme and the development strategy followed.

During phase 2 (see Fig. 6), the GEA method (or parts thereof) was applied in multiple organizations with the goal to evaluate the method, and make improvements where needed. In selecting the case studies, the focus was on large organizations involving a broad application of the GEA results. During this phase, the primary case studies included:

• Professionalization in administrative body of a ministry of the Dutch government [62].

• An impact assessment of the introduction of a new law at the Custodial Institutions Agency of the Dutch Ministry of Public Safety and Justice [64].

• Digitization of the document flow at a ministry of the Dutch government [58, 60].

In line with Yin [67], the case studies involved the use of an explicit data collection protocol. Yin suggests to use five levels of questions in collecting data:

• 1. Questions to specific interviewees.

• 2. Questions at the level of an individual case (these are the questions in the case study protocol to be answered by the investigator during a single case, even when the single case is part of a larger, multiple-case study).

• 3. Questions focused on finding patterns across multiple cases.

• 4. Questions at the level of the entire research effort (for example, calling on information beyond the case study evidence and including literature or published data that may have been reviewed).

• 5. Normative questions about policy recommendations and conclusions, going beyond the narrow scope of the study.

The evaluation questions used in the GEA programme are, for each level, listed in appendix A. These questions were validated by the core team.

The data gathering, structuring and analysis resulted in the validation of evaluation criteria such as: degree of acceptance by stakeholders, extend of applicability, achieved level of coherence governance, degree of transferability, balance between interests of different stakeholders, and level of innovation.

4 Lessons learned from GEA’s development

In this Section, we reflect on some of the practical experiences in the development of GEA. We start with a short discussion of the general background, and then structure the remainder of this Section around some of the key lessons learned.

As discussed in the introduction, the initiative to develop the GEA method was taken by the Dutch consultancy firm Ordina in 2006. As a prelude to the actual start of the development, a survey was conducted among the participating organizations to identify the requirements on the desired outcomes. It also validated the need to more explicitly govern enterprise coherence, beyond mere Business-IT alignment. More recent publications [21, 22] provide further (a posterior) support for this motivation.

4.1 Organize the need

From the start out, the ambition of the GEA research programme was to follow a science-driven approach. From a research methodological perspective [63], the development of GEA involved a design science [10] effort, with an important role for cases studies [68] as a way to drive the iterations. It was, therefore, also important to have a good understanding of the needs for/requirements on GEA in practice, and it was necessary to have access to real-world cases. Therefore, the next step was the creation of the multi-client$^{2}$ research program$^{3}$ involving clients (i.e. future ‘users’ of the method) that saw a real need for the method.

4.2 Validation of need by financial commitment

In the initial stages (i.e. the first five years) of the research program, the participating members were also required to provide a financial contribution to the program. This financial contribution was not only meant to cover (some of) the costs of the program. Requiring a substantial financial contribution also implied a (1) validation of the shared understanding of the need to develop GEA, and (2) commitment to the development of GEA (e.g. by way of real-world cases).

Obtaining this financial commitment, also helped mitigating conflicting interests within Ordina. The development of GEA also required an investment on Ordina’s side in terms of hours spent by senior consultants, who would otherwise be able to report ‘billable hours’ with clients. This caused some tension with their respective managers who had to deliver these hours at the expense of their revenue targets. Requiring the participating organizations to also contribute financially (in moderation) to the development of GEA, mitigated this.

4.3 Value for practice before rigor for science

Next to the industrial partners, the research programme also involved an advisory board involved five senior researchers from different Universities, covering management sciences, organizational sciences, and business informatics. This is also where a first interaction between practice and theory took place. The need for the development of GEA was clearly born in practice. However, already at the start, the senior researchers in the advisory board were then able to already provide input regarding relevant existing theories and methods that could be integrated into the design of the GEA method. This resulted in a series of white papers [50, 51, 53] (in Dutch) documenting the need for GEA, its initial design, as well as positioning in relation to existing related instruments (such as the balanced score card [14], and McKinsey’s 7s model [3]).

Soon after the start of the GEA programme it became clear that, for the programme to succeed from the perspective of the industrial partners, it was necessary to first focus on establishing value for practice. In line with this, during the first stages of the GEA programme, the primary focus had to be on doing real-world cases (in real-world circumstances) with the project partners, and then at a later stage leverage these towards scientific reflection and publications. This, nevertheless, did result in a number of white papers (e.g. [49, 52]) providing initial documentation of the first GEA cases (which were also beneficial in attracting additional project partners).

At a later stage, once the programme was well on its way, and the first version of GEA had been documented in terms of a book [46], there was room for more scientific reflection and rigor [47, 54,55,56,57,58,59,60,61,62,63,64].

4.4 Evaluation: data versus realism

Research methodological publications on DSR (and case study research) suggest different ways to conduct evaluations. They typically prescribe ways to (1) identify what data (and with what quality) to collect, (2) how to process the data, and (3) how to interpret the findings, what remains open is the question if the data can be collected at all.

In the case of design artefacts that are developed for a real world context, like the GEA method, the ultimate evaluation is the use of the artefact in real world circumstances they were intended for (e.g. by way of the different cases in which GEA has been applied). At the same time, however, in a such commercial (and political) context there are several constraints that make it hard to actually collect data. For instance, due to budget and time pressures, there may not be time to collect data. Even when the data collecting is done by researchers that are external to the project (and its budget), project managers are likely to frown upon it, as the presence of these ‘observers’ and their questions, will (at least give the perception of) slow(ing) down the project’s progress and/or impact the project’s focus. In addition, there may be political sensitivities about the project that different stakeholders may not want to become exposed. These challengers certainly emerged in some of the GEA cases.

As such, it would be good for DSR to also provide more guidelines on how to conduct evaluations in such critical circumstances. Obtaining ideal evaluation data might not always be possible when aiming to evaluate a design artefact in the actual circumstances it is aimed for. As such, it sees a trade-off needs to be made between the completeness and quality of the data that needs to be gather, and the realism of the actual case.

4.5 Loosely coupled co-evolution of practice & theory

Next to the earlier mentioned lesson learned on value for practice before rigor for science, the ongoing work in the GEA programme also resulted in a series of parallel research activities. These research activities were formally separate from the GEA programme, but partly inspired by the findings within the GEA programme, while some of the findings of these parallel research activities flowed back to the GEA programme.

For instance, an important concept in GEA is the notion of guiding statement, which involves of policy statements, objectives, and principles. The need for a better understanding of these concepts also triggered more explicit work on the concept of architecture principles, which a.o. resulted in [7]. The latter then, in its turn, also enabled the GEA programme to further mature these concepts within the GEA context.

The need for more coordination in enterprise transformation to ensure enterprise coherence, was also one of the triggers for a broader Architectural Coordination of Enterprise Transformation programme [38].⁵ Ph.D. candidates involved in the latter project also interacted with the project members of the GEA programme, to obtain case material for their work. Conversely, different results reported in [38] provide(d) more theoretical underpinning(s) of the GEA method.

The need to involve multiple stakeholders in a collaborative setting, also inspired work towards an approach to use collaboration engineering concepts to structure such interactions [26, 27]. These results are expected to be integrated into future versions of GEA, in particular when developing more explicit tool support for the method (see the discussion on future research in Sect. 6).

Finally, now that the GEA method is well established (and also internationally available [42]) there is a growing need (and ambition) to be able to more explicitly quantify enterprise coherence and its impact on the performance of enterprises. First steps in this direction have already been published [1, 2].

In each of these examples, the needs from GEA-related practices inspired the development of new concepts and theories, while some of the latter then flow(ed) back towards the further development of GEA. As such, we also prefer to speak about co-evolution from practice and theory, consciously putting practice first (rather than the often used order of theory and practice), while using the word ‘co-evolution’ rather than the often used “from practice to theory and back”.

4.6 Controlled initiation; independent growth

As mentioned the GEA programme was initiated by the consultancy firm Ordina. Having one organization in clear control of the development proved valuable in order to organize the need, financial commitments towards the joint development, etc.

However, after the establishment of a first stable version, and making this widely accessible [46] (to a professional audience), enterprise architects working at other consultancy firms also became interested in co-developing the GEA method. This then triggered the transfer of the GEA method to an independent foundation. This foundation⁶ now manages the further development of GEA from a more neutral position.

5 Lessons learned from applying GEA

Over the past 10 to 15 years, GEA has been applied to several cases. This includes several smaller cases, but also a number of larger cases. In the remainder of this Section, we discuss some of the lessons learned.

Applying GEA in each of the (larger and smaller) cases has resulted in several lessons learned. Table 2 shows (partially anonymized) some of the key figures of the larger cases. Case 5 to 7, were conducted at the early stages of the development of GEA. For those stages, no detailed breakdown of the number of guiding statements is available.

5.1 Limits to the applicability

GEA does not claim to be applicable in all situations. In practice, this requires explicit expectation management. This is also why a thorough problem analysis is always carried out beforehand to determine whether: (1) the enterprise is mature enough for a GEA approach, (2) the leadership style is of a sufficiently democratic level and (3) the enterprise issue in question is of a strategic level.

Furthermore, GEA is primarily intended to be used by organizations (or business units) involving a few hundred employees with a relatively high degree of division of labour, a ‘democratic’ leadership style, and already fairly mature management and governance processes in place.

In applying GEA in the context of a given enterprise issue, it is also common to test the suitability of the issue on the basis of the following three key questions:

• 1. Is the time horizon in the context of the issue significantly long?

• 2. Is the relevant investment level significantly high?

• 3. Is the solution to the problem expected to have an impact on a broad range of business segments?

If all three questions are answered in the affirmative, we consider a GEA approach to be useful in addition to meeting the aforementioned organizational characteristics.

Table 2 Overall indicators per project (first time iterations of the GEA road-map)

5.2 Needed involvement

On average the larger cases (see Table 2) require a 5 person-month involvement of external consultants and/or core team members, and on average 0.25 person-month (per perspective) of the perspective owners. Combined, this is an average of $5 + 0.25 \times 10 = 7.5$ person-months in total, per case.

These involvements include, more specifically:

• 1. 3 to 4 members from senior management, to validate the documents reporting on the level of purpose.

• 2. Producing the analysis of an enterprise issue (including the presentation), requires a typical involvement of 1 to 2 ‘owners’ of the enterprise issue at hand.

• 3. The validation of documents reporting on the level of design requires the involvement of (on average) 2 perspective owners (for, on average, 10 perspectives)

• 4. The validation of the solution contour typically involves 3 to 4 members from senior management, including a project/programme portfolio manager.

As mentioned in Sect. 2.3, generally there about twice as many relevant relationships as there are perspectives. These relationships provide the primary focus of the needed coherence between the different perspectives, in order to achieve/maintain enterprise coherence. In gathering these relevant relationships (as part of Step 2 of the road-map), it is suggested to do this in terms of a workshop of half a day, involving the perspective owners. The perspective owners typically are divided in 4 groups of about 5, and are tasked to identify about 5, in their opinion, most relevant relationships. These are then plenary discussed, while removing redundancies and prioritizing. Afterwards, usually around 20 of such relevant relationships remain.

It should be noted that the above mentioned number of 7.5 person-month pertains to the first time iteration of the GEA road-map (Fig. 4). In follow-up iterations of the road-map, steps 1 and 2 require much less (if at all) effort. In these cases, the involvement reduces to 1.4 person-month involvement of external consultants and/+or core team members, and on average 0.1 person-month (per perspective) of the perspective owners. Combined, this is an average of $1.5 + 0.1 \times 10 = 2.5$ person-months in total, per follow-up iteration.

5.3 Benchmark in numbers

Based on the experience across the different cases the following average numbers seem to be relevant benchmarks for larger ($1000+$ employees) enterprises:

• 1. The number of perspectives will be between 9 and 11.

• 2. The average number of key concepts will be 4 to 8 per perspective.

• 3. The number of guiding statements for a large enterprise will be between 200 and 400.

• 4. The distribution of the guiding statements will be approximately 10 to 25% principles, 30 to 45% policy statements and 30 to 45% objectives.

Without assuming these numbers to represent an absolute truth, they provide important indicators of when a strong deviation from the patterns is visible in an enterprise. When strong deviations do occur, it is important to discuss these deviations with those responsible, such as the perspective owners, and to see whether it is necessary to change, to remove or to add elements at the level of design. In the case of De Key, we already saw (in Sect. 2) that there were less than expected principles for the real estate perspective, while there were no objectives formulated for the suppliers perspective. In another case, a GEA survey found that there to be 198 policy statements, 1 principle statement and 1 objective statement. This is a striking example of a not very result-oriented enterprise, which is stuck in policy-making processes.

5.4 Added value of using GEA

It is, of course, an interesting question what the added value of using GEA is in practice. Regretfully, given the size, the complexity, and situatedness, of enterprise transformations in general, a comparative study between transformations that applied GEA and transformations that did not, is difficult.

One overall observation is that, since the presence of a good documented enterprise mission, vision, core values, goals and strategy are prerequisites to determine the level of purpose and level of design, taking the first steps of the GEA road-map (Sect. 2.6) also results in a deeper reflection by senior management regarding the validity and coherence of the level of purpose. Furthermore, the explicit involvement of the different stakeholders (owners of the enterprise issue, the perspective owners, and project/programme portfolio management), also results in a stronger commitment to the chosen direction (as expression in the solution contour) and resulting portfolio of projects. This, in itself, is already an added value when applying GEA.

In addition, across the projects in which GEA was applied, several ‘feats of arms’ can be identified, such as:

• With the help of GEA, the EU-accreditation of a large Dutch government agency, which had gotten completely out of control, was safeguarded within one year.

• At a Dutch ministry, the unnecessary start-up of a large (and costly) project, initially triggered by a change of a law, was prevented [58, 60].

• In the context of a large digitization programme at a ministry, GEA was used to break (within two months) a stalemate in a decision-making process that had been stuck for a year [64].

• With the help of GEA, the financial function of a large housing corporation was brought up to the level required by regulators within 3 months. This pertains to the De Key case as briefly reported on in this paper, while a more detailed description of this case is reported in [42].

• With the help of GEA, the guardianship order put on a large municipality was lifted within one year.

As one could imagine, these cases often involve (politically) sensitive issues. This makes it difficult, if not impossible, to publish openly about such cases. In [42] additional (anonymized) cases are reported on as well.

6 Conclusion & further research

In this paper, we reported on the GEA method for enterprise architecture, and its development as a co-evolution between practice and theory, as well as associated lessons learned. We presented the core elements of (the current version of) GEA, and have illustrated these in terms of a real-world (social housing) case. Finally, we also discussed some of the lessons learned in applying GEA across different organizations.

Towards the future, we see several challenges for the further co-evolution between practice and theory. Here, we see five main clusters of challenges:

• 1. Quantifying and smartening enterprise coherence— There is a clear need to better quantify the notion of enterprise coherence, and for instance also provide evidence underpinning the scores for the matrices used to express the coherence between the different elements (see, for example, the discussion in Sect. 2.3). Initial work in this direction has already been reported in [1, 2], but much more work remains.

  Once the notion of enterprise coherence has been quantified more explicitly, it also becomes possible to find causal relations between (the level of) enterprise coherence and the concept of EBIT(D)A; i.e. an enterprise’s economical performance in terms of earnings before interest, taxes, (depreciation), and amortization.

  As can be inferred from the discussion of the GEA road-map (Sect. 2.6), the creation of an organization specific GEA framework, and further monitoring the level of enterprise coherence, can be time-consuming. Especially as it involves the analysis of many different data sources.

  From a research perspective, also this provides ample opportunities to ‘smarten’ this work using enabling information technologies, including natural language processing, enterprise cartography, process mining, and AI in general.

• 2. Integration with existing approaches— As mentioned in the introduction, with its focus on enterprise coherence, GEA is complementary to existing enterprise architecture approaches. We also identified different ways in which this complementary can be operationalized. For instance, the design frameworks underlying these approaches can be used to provide more structure to the descriptions of the level of design, as well as the elaboration an integral solution contour.

  In practice, we observe there to be a need to define such relations more explicitly. In particular (but not only) to the ArchiMate [13, 17] standard. Furthermore, the purpose of an enterprise is also closely linked to its business model and its position in value networks, making it relevant to explore the relationships to, for example, the Business Model Canvas [31] and Value Modelling [6], respectively.

• 3. Organizational operationalization and institutionalization— As mentioned before, the GEA programme was also linked to the broader Architectural Coordination of Enterprise Transformation (ACET) research programme[38]. The ACET programme already identified the need for further research into the institutionalization of enterprise architecture processes in organizations (see chapter 12 of [38]). Further work regarding the institutionalization of GEA-related processes is certainly called for. As also identified in the ACET programme (chapter 8 of [38]; building on the work by Hofstede [12]) organizational culture can have a profound impact on the success of enterprise architecture-related activities. Since GEA has been applied mainly in the context of Dutch Government Agencies and larger well-established organizations, there is a need to investigate to what extend the GEA method has a ‘cultural bias’ toward such environments.

• 4. Managing organizational complexity— In applying GEA in practice across different organizational contexts, it became clear [42] that strategies are needed to deal with organizational complexity. Based on the experiences so-far, such complexities seem to be due to two main causes:

  • (a) Inherent complexities of the enterprise— For example, enterprises involving multiple management layers, matrix structures, mixes of regional and business-line based structures, etc.

    Enterprises can also be connected to other enterprises in various forms of cooperation, including alliances, chains, and networks.

  • (b) Inherent complexities of the enterprise issue— The enterprise issue that triggers a GEA iteration may have a root cause and/or implications that have an inherent complexity. Examples include: the introduction of new regulations, shifting of the relevant business ecosystem towards cloud-based platforms, or major changes to social/legal obligations (e.g. changes to social security, or pension-related rules).

  In [42] some strategies are suggested to deal with such complexities. However, more theoretical and empirical underpinning is certainly needed.

• 5. Collaborative decision making and capturing— Another result from the interaction between the GEA programme and the ACET programme has been work towards explicit decision making strategies and ways to capture the rationale of such decisions (see chapter 15 of  [38], and [33, 34]). These results can be used to further underpin the (collaborative) decision making activities in the GEA roadmap (especially the activities requiring joint prioritization and committed to decisions; e.g. Step 4 or the GEA road-map). Related to this, we also see opportunities for the integration of existing work regarding collaborative approaches to enterprise modelling[16, 20], enterprise architecture [27] and policy formulation [25].

A Case evaluation questions

1.1 A.1 Level 1:

• At the time of the validation process of the ECF:

  • 1. Are the guiding statements valid and up to date?

  • 2. Do the representatives of the perspectives agree with the identified perspectives, the identified core concepts within it and the related guiding statements?

• At the time of the ECG analysis process of a major business issue:

  • 1. Do the causes, triggers, sub-problems, risks, implications, etc., of the business issue lead to change initiatives?

  • 2. Do the (existing) guiding statements result in additional change initiatives or restrictions (the so called solution space)?

1.2 A.2 Level 2:

• Are the documents at the level of purpose present and accessible?

• Does the definition of the level or purpose result in a clear understanding of the sense of purpose and design of the organization?

• Is one able to identify, and engage, the right representatives for each of the perspectives? This engagement should cover both the identification and validation of the cohesive GEA elements and the analysis processes to solve the business issue.

• Are the representatives of the perspectives able to validate the ECF?

• Are the representatives of the perspectives, using the validated ECF, able to execute the analysis processes to solve major business issues?

• Does the development of the ECF lead to an increase of enterprise coherence?

• Does the use of GEA lead to an integral solution that contributes to the coherence of the organization?

• Is the organization able to, autonomously, specify a business issue that can serve as input to a GEA based analysis?

• Do the owners of the business issue succeed in specifying the business issue in such a way the representatives of the perspectives can perform the complete GEA analysis and develop an integral solution?

1.3 A.3 Level 3:

• Degree of acceptance by stakeholders?

• Extend of applicability?

• Extend of matching required dynamics?

• Extend of compliance with required integrality?

• Degree of accessibility?

• Degree of transferability?

• Extend of balance of interests?

• Degree of innovativeness?

1.4 A.4 Level 4:

• Did the execution of the cases result into detectable performance improvements?

• Does the literature support the answers to the above findings?

1.5 A.5 Level 5:

• What recommendations can be made towards the further development and expansion of the area of enterprise coherence?