Beyond Incentives and Sanctions - Extending the Portfolio of IS Coordination by Systematic Design of Informal Interventions

Abstract

In times of business-driven digital transformation, increased design autonomy in innovation projects and agile principles, traditional coordination approaches in the IS domain are facing growing acceptance issues and, consequently, value contribution barriers. Since coordination challenges of IS on the enterprise level (e.g., IS complexity) persist or even increase with digitalization and design autonomy, organizations are in search of extending their portfolio beyond formal interventions. This paper integrates various descriptive and design knowledge components into a comprehensive analysis and design approach for informal coordination interventions. We cover a problem-oriented discussion of theoretical and conceptual foundations, a taxonomy of generic informal interventions, a catalogue of derived intervention types, and a process to systematically construct and evaluate situation-specific informal interventions. An Action Design Research project in a large company is summarized to demonstrate our proposal and provide evaluative evidence.

Keywords

• 1 IS management
• enterprise level
• coordination
• complexity intervention
• design knowledge
• method
• nudging

1. Introduction

Over the past decades, we have witnessed an enormous growth of investments in Information Systems (IS) in organizations. On the one hand, increasing investments in IS had a significant impact on most organizations’ performance. On the other hand, these investments resulted in higher complexity [ 1 ]. Most of the IS complexity increase is inevitably caused by growing business complexity and digitalization. An avoidable, often significant portion of that rise, however, can be attributed to redundancies and inconsistencies that result from the allocation of solution design authority to business units and / or innovation projects that focus primarily on their “local” objectives and only partially, if at all, on enterprise-wide goals such as synergies and coherency [ 2 ]. To address this challenge and confine the IS complexity increase to a sustainable extent, scholars and practitioners have developed a range of enterprise-level IS coordination approaches [ 3 ]. As IS integrate human, organizational, and technical components, enterprise-level IS coordination cannot succeed if limited to IT aspects such as IT architecture or IT project portfolio management. Coordinative efforts need not only to cover the entire organization, but also to extend to business architecture, business innovation initiatives, or process and knowledge management, just to name a few aspects, and need to cover multiple solution life cycles rather than the duration of certain projects or initiatives.

Enterprise Architecture Management (EAM) is a well-known example for an enterprise-level IS coordination approach that covers a long planning horizon, extends across the entire enterprise, and covers the full business-to-IT stack from strategy over processes and information flows to capabilities, applications and finally IT solutions [ 4 ]. In line with the primary objective to keep complexity under control and thus maintain the flexibility of the enterprise, EAM aims at aligning locally governed IS design decisions with enterprise-wide coherency and synergy objectives [ 5 ]. Other examples of enterprise-wide IS coordination that focus on different objects of coordination, stakeholders and/or coordination processes, are project portfolio management or the management of large innovation / transformation initiatives. While we will use EAM as running example for enterprise-wide IS coordination in this paper, we will argue at the end of this paper that our problem analysis and design can be projected to other IS coordination approaches as well.

Notwithstanding its wide adoption and many reported success stories that have been generalized to theoretical contributions [e.g., 6], EAM faces some formational challenges. First, although many architects tried to position themselves as a linking-pin ‘between’ corporate management, business/project owners and IT, their backgrounds and competency profiles often kept them close to the corporate IT functions [ 7 ], limiting their credibility on the business side and on the top management level. Second, exercising EAM as a centralized mechanism for enterprise-wide IS coordination is often perceived to be the antagonist of business-driven innovation projects. From local business stakeholders’ perspective (e.g., a particular project, product, or function owner), the promoted enterprise-wide coordination by EAM is often regarded to be a “restriction of design freedom” [ 8 ] and rather detrimental than supportive to their specific goals.

The perception of EAM and, consequently, its ability to keep enterprise-level IS complexity at sustainable levels, may be linked to the form in which EAM intervenes in the organization. In its traditional fashion, EAM implements formal control mechanisms that aim at maintaining transparency, coherency, and ultimately flexibility potentials of the overall IS architecture – including goals and objectives, organizational designs, business processes, information flows, product / service design, static and dynamic capabilities, knowledge management, and finally IT/business alignment. Respective formal mechanisms include, but are not limited to developing, maintaining, and enforcing design principles, conducting compliance checks, designing to-be architectures, and establishing committees or procedures for architectural coordination aimed at influencing decisions made in decentral IS development projects [ 9 ].

As the business side plays a more important role in digitalization, many organizations decided to grant higher design autonomy to decentral innovation projects and to apply agile principles not only for developing IT solutions, but also for the overall design of business innovations. In this changing context, formal coordination mechanisms are facing growing acceptance issues by stakeholders and, consequently, value contribution barriers. A much discussed MIT study shows that, at some point, enterprise-wide coordination like EAM apparently reaches its peak productivity level as a consequence [ 7 ]. At the same time, the higher speed of change and the sheer volume of changes will inevitably increase IS architecture complexity. Hence, fostering compliance of local decision-makers in decentral innovation projects to enterprise-wide objectives becomes a key priority for coordination in order to keep IS complexity at a sustainable level.

Informal coordination interventions have the potential to extend the portfolio of IS coordination mechanisms beyond incentives and sanctions [ 10, 11 ], thereby promising to at least partially overcome stakeholder resistance and improve coordination effectivity. While certain aspects of informal coordination such as justificatory foundations, forms of informal interventions, and general design approaches have been already published, these components have not been integrated into a comprehensive design approach yet. We posit that the missing adoption of informal interventions in practice is at least partially caused by the fragmented nature of available design knowledge. This paper therefore aims at integrating the pieces, answering the research question ‘how can fragmented design knowledge about informal interventions be integrated to provide a comprehensive design support for enterprise-wide IS coordination?’

2. Methodology

Ideally, comprehensive design knowledge should combine (i) justificatory descriptive knowledge, (ii) derived projectable design knowledge on multiple levels of (de)contextualization, and (iii) expository design instances for demonstration and evaluation purposes in a coherent form [ 12 ]. As our conceptual ‘integration template’, we adapt this design knowledge concept to enterprise-wide IS coordination in Section 3. According to the multi-level knowledge structure, we first analyze the portfolio of coordination interventions through the lens of control theory and institutional theory (justificatory descriptive knowledge, Section 4). On that basis, we conceptualize a set of generic informal control interventions in Section 5 (abstract design knowledge). Contextualizing such abstract design knowledge is a multi-stage process. As a first step, Section 6 presents the derivation of a company-specific portfolio of informal interventions for EAM. Section 7 then presents how specific informal EAM interventions (design instances) can be created on that basis. It should be noted that all presented design knowledge components have been elaborated and published before, but isolated and not as an integral component of comprehensive, coherent design knowledge. To demonstrate our proposal, we report results from developing concrete informal coordination interventions in a large company (Section 8) before discussing our proposal in the concluding Section 9.

As our research question is about how to solve a specific class of problems, our research design generally follows the Design Science Research approach [ 13 ]. Sections 3 and 4 summarize conceptual and theoretical foundations, respectively. Sections 5, 6 and 7 present projectable solution components (intervention design approach). Section 8 demonstrates the design by instantiations from actual Action Design Research projects and also refers to evaluative evidence from demonstration cases.

3. The Multi-level Structure of Design Knowledge

Based on their analysis of design knowledge evolution and accumulation, Avdiji and Winter [ 12 ] propose that design knowledge should coherently integrate knowledge components on different conceptual levels. In the following, we adapt their conceptual template to IS coordination interventions: • Descriptive knowledge as justification: Coordination theory provides justificatory predictive statements about which preconditions create which effects (cause-effect relations). Section 4 summarizes relevant findings. • Abstract design knowledge as a basis for contextualization: It has been shown that certain types of informal coordination interventions are effective for reaching specific coordination goals (means-ends relations). Section 5 presents a generic typology of 26 such interventions. • Contextualized design knowledge as a basis for instantiation: Every organization contextualizes generic informal interventions according to their goals, size, context dynamics, and other factors they find relevant. In Section 6, we report how informal EAM interventions are derived, illustrated by the case of a large insurance company which derived 23 types of informal EAM interventions. Such means-end relations are still projectable, but already contextualized to a IS coordination problem sub-class (EAM interventions). • Finally, expository design instances allow to evaluate to which extent implemented coordination interventions actually lead to desired coordination effects (design featuremeasurable effect relations). In Section 7, we report how such an implementation can be done by integrating method components from Action Design Research and Digital Nudging.

4. Coordination Modes and Mechanisms

From a coordination theory perspective, interventions implement different types of control mechanisms [ 14 ]. Table 1 summarizes an adapted compilation of Schilling’s [ 9 ] analysis which modes and mechanisms of control are implemented by exemplary EAM interventions.

Convincing local stakeholders that overall benefits on the enterprise-wide level justify individual sacrifices, remains a difficult undertaking. Illustrative examples of such challenge cannot only be found in enterprises (e.g., centralizing procurement processes), but are also common in public policy (e.g., imposing speed limits around schools, imposing smoking bans in public areas, transforming energy production and consumption).

In order to move beyond the already mentioned effectivity barriers of enterprise-wide coordination, it appears necessary to shift the focus from an enforcement-centric view (i.e., focusing on formal control mechanisms, e.g. by more elaborate governance structures) towards an influence-centric view (i.e., using informal control mechanisms). This implies also a shift of focus from the traditional players (IT unit, architects, enterprise management) to “that other 90% of the enterprise” [ 7 ] who are not directly related to the IT function or enterprise-wide concerns. As these stakeholders (e.g., project, product, or function owners) cannot be sufficiently “controlled” by formal interventions with a reasonable effort, complementary informal interventions need to be designed and implemented. For formal interventions, organizations have developed mature practices to measure compliant behavior (e.g., by systematic assessment of compliance with architectural guidelines in the context of sign-offs), to incentivize desired reactions (e.g., by approving compliant project proposals), and to sanction undesired reactions (e.g., by demanding proposal amendments). For the ‘new world’ of informal interventions, design and management approaches need to be developed that are centered around informing, legitimating, and socializing [ 7 ].

As a design foundation, however, descriptive knowledge about the reaction towards coordination interventions is needed. The model of Weiss et al. [ 26 ] explains individual reactions to EAM interventions and thus can serve as a starting point. According to their study, individual actors 1. need to be convinced that their social status will be rising if they comply with EAM interventions – and vice versa; 2. need to understand that they can be more efficient if they comply with EAM interventions – and vice versa; 3. need to perceive EAM as something that is strategically important for the organization; and 4. need to perceive EAM as transparent, business-oriented and trustworthy.

Generalizing beyond EAM to enterprise-wide coordination, informal interventions require to actively involve local decision-makers and the social system of the organization, to focus on communication and sensemaking, to use lightweight tools without too much ‘IT touch’, and to demonstrate local, tangible coordination benefits.

5. Taxonomy of Derived Informal Control Interventions

Based on a broad structured literature review, Kneubühler [ 27 ] classified coordination interventions according to the underlying psychological base mechanisms, their timing and whether the respective decisions are infrequent or repetitive. If also the level of analysis is considered, the resulting taxonomy differentiates 23 types of informal interventions, three types of formal interventions and three mixed types (see Table 2).

The resulting typology of 26 informal interventions constitutes a ‘menu’ of general (informal) solution components to general coordination problems in organizations. From that ‘menu’, any specific set of informal intervention candidates can be derived by filtering the acceptable or desired base mechanism, the targeted type of decision and the relevant level of application (individual, workgroup, community, or enterprise). Yet the resulting set of candidates is neither specifically tailored to a specific aspect of enterprise-wide IS coordination nor to the specific context of an organization.

The next contextualization steps are therefore (i) to ‘translate’ the general coordination goals into the context of, e.g., EAM and (ii) to consider company-specific context factors such as its organizational setup, its IS management maturity, specific coordination needs and practices, etc. In the following section, we demonstrate how such a contextualization can be achieved.

6. Deriving and Prioritizing a Company-specific Portfolio of Informal EAM

Interventions

Any instantiation of generic design guidance requires a sufficiently detailed analysis of the respective context. In his EAM case study at a large insurance company, Erni [ 28 ] interviewed major stakeholders of enterprise-wide coordination (such as senior management, strategic planning & controlling, project portfolio management, IT project lead, business analyst, product owner, innovation manager) to collect a consolidated characterization of the context. As most important context characteristics, he identified the company’s approach to IT/business alignment, their IS coordination (EAM) maturity, current coordination needs and incentives, current practice of decision making, the magnitude of complexity costs, and the level of the resulting corporate performance impact.

Intervention type

Timing - 0 + 0 - 0 - 0 - 0 0 - 0 - 0 0 + - 0 + - 0 + - 0 +

- 0 +

0 - 0 + - 0 +

Based on the already mentioned study of Weiss et al. [ 26 ] that explains the reaction of non-architects to architectural coordination interventions, Erni specifies the intervention candidates not only regarding means (how they work), desired outcomes and addressees, but also with regard to whether their contribution would increase awareness, understanding, use, legitimacy, effectivity, organizational grounding, or trust of architectural coordination. While understanding, awareness and use result from general IS success models, the latter four factors had been identified by Weiss et al. to explain a large extent of EAM impact.

Although the concrete context certainly varies from organization to organization, the approach to contextualize the pre-selected ‘menu’ of coordination interventions for EAM and for a company context, appear to be projectable to many organizations.

In order to select and prioritize the identified informal EAM intervention candidates for piloting, Erni conducted interviews with senior managers to determine their expected usefulness and expected practicability. Table 3 summarizes the results. For both constructs, 5 is the maximal and 1 is the minimal value.

While informal interventions directed at adapting the EAM operations model or decision support were assessed to be most useful, involving the company’s social system was not regarded as very useful. Regarding practicability, it was not surprising that traditional, known interventions scored highest, along with information provision and new communication channels. The adaptation of EAM’s operating model and decision support, although seen as most useful, were considered also to be most challenging with regard to their practicability.

Although we described so far how desirable informal EAM interventions with certain characteristics can be successively developed based on generic design guidance (decontextualized ‘menu’ and contextualized ‘candidate list’), we still operate at an abstract ‘intervention type’ level. To concretely implement such interventions in practice, additional considerations are needed that are presented in the following section.

7. Implementing Situated Informal EAM Interventions

Once desired intervention types have been identified, the specification of concrete informal EAM interventions can apply not only (i) general guidelines for intervention design in organizations, but as well (ii) specific guidance for influencing individual behavior without coercion and, even more specific, (iii) specific guidance for adoption-friendly informal EAM interventions: i. Since intervention instantiations are highly context-dependent and can only gain acceptance (and thus be used and create value) by the addressed decision-makers if they are sufficiently involved in the design process, we follow the Action Design Research (ADR) approach [ 29 ] as a general design method for intervention design in organizations. Thus, we co-produce the design together with practitioners, using an iterative approach to accompany and bring about the emergence of the artefact(s). ii. For guiding individual level behavior without use of coercion or regulation, nudging has been widely studied since Thaler and Sunstein’s [ 30 ] seminal book. The underlying psychological effects therefore provide a foundational toolbox for constructing contextualized digital nudges [ 31 ]. iii. As even more specific guidance for specifying informal interventions in an EAM context, we apply Weiss et al.’s guidelines for adoption-friendly EAM interventions [ 26 ].

The procedure we use is both informed by the four stages of ADR (problem formulation, building/intervention/evaluation, reflection/learning, and formalization of learning [ 29 ]) and the fourstage digital nudge design method by Mirsch et al. [ 31 ]. Cahenzli [ 32 ] consolidated these two methods into six phases:

Phase 1 – Understanding the general problem: As part of the problem formulation of the ADR method and the steps related to understanding the context of the intervention, the first step is to understand the underlying problem.

Phase 2 – Formulation of problems from the stakeholders’ perspective: Next, the problem is being described in statements from the perspective of the addressees whose behavior should be guided. Thereby, psychological effects are to be identified. This step is still part of the problem formulation in the ADR method, whereas it is overlapping phase 1 and 2 of the digital nudge design method.

Phase 3 – Forward, Backward, and Sidestep Mapping: The researchers and a work group consisting of relevant stakeholders within the case organization map the problem to existing and proven nudges and vice-versa (forward and backward mapping). This is part of the stage 2 of the ADR method and phase 2 of the digital nudge method. To increase the creativity of both researchers and practitioners, we additionally map the problem to psychological effects (and from there, to nudges that have been used to overcome said effects) as well as a suite of effects to possible nudges that may be leveraged to overcome existing psychological effects (sidestep mapping).

Phase 4 – Formulation and implementation of a solution: Once phase 3 is completed, the suite of nudge ideas is used as the baseline for the creation of an intervention that addresses not only a problem instance, but the entire problem class. This step is the most complicated as the solution is not only a nudge, but an abstracted construction that addresses not the individual problem aspects (e.g. identified inhibiting effects), but the institutionalization process as a whole. Therefore, the design guidance of Weiss et al. becomes important in this phase. As a consequence of their explanatory model of stakeholder reaction to EAM interventions, Weiss et al. suggest the following design principles [ 26 ]: 1. The interventions need to create transparent conditions about who is compliant with EAM guidelines and who is not – so that compliance can be associated with personal social status in the organization; 2. The interventions need to clearly demonstrate their positive value contribution also to ‘local’ objectives or goals – as well as the damage of ignoring or compromising the intervention to both local and global objectives / goals; 3. The interventions need to position EAM leaders on senior ‘decider’ levels in the organizational hierarchy – rather than ‘ivory tower’ experts or ‘architectural police’; 4. The interventions need to ensure that architects and architectural artifacts are not only understandable for business stakeholders, but also are able to credibly demonstrate their value contribution. For instance, the use of coherency-oriented, high complexity models should be avoided. Instead, when interacting with local business stakeholders, the focus of architects should be on lightweight artifacts, local business concerns and tangible benefits.

Only if as many as possible of these principles are followed, respective informal coordination interventions promise to effectively influence autonomous, local decision-makers on the business side towards increasing their acceptance of EAM guidelines and, ultimately, lead to an institutionalization of Architectural Thinking [ 33 ].

Once a version of an intervention is created, even if it is still at an early stage, it is being tested and learnings from this cycle are being fed back into the design process, until a large-scale implementation of the solution can be implemented. This testing and learning can be understood as stage 3 in the ADR method.

Phase 5 – Evaluation: As opposed to the iterative testing and thus formative evaluation in phase 4, this phase represents a summative evaluation of the design endeavor. At this point, the goals from phase 1 are used as a baseline to evaluate the artefact.

Phase 6 – Formalization of Learnings: As our intention is not primarily to solve the situated problem in a specific organization, the last phase tries to generalize the findings, addressing the general (decontextualized) problem. Therewith the ADR project may conceptually contribute to a better understanding of the problem, the solution, and finally, the creation of general design principles [ 29 ].

8. Demonstration

Following the ADR approach, we actively participated in actual development projects that implemented (and partially deployed) informal coordination intervention instantiations in large organizations – aiming to institutionalize enterprise-wide coordination in a context where local decision-makers have very high autonomy. In the following, we summarize how the proposed six phases were conducted in one of these projects. Details of the project(s) and evaluative evidence are presented in Schilling et al. [ 34 ].

Phase 1: The case company is a very large, multinational organization in the engineering industry. Traditionally, the case organization has been operating in a diversification mode and, hence, had a relatively low level of business process and information system integration and standardization. In 2016, the organization started to intensify its EAM activities. As an initial step, senior management appointed an EAM team with enterprise-wide scope and objectives. These objectives included measures to increase business processes and user productivity, to enable end-to-end processes and reporting, to reduce IS operating costs, and to enhance security and compliance.

To achieve these objectives, the EAM team implemented a considerable number of formal control mechanisms: The case organization defined architecture principles and plans for a target architecture, and established a formalized approval process for all changes that affect the enterprise architecture. Furthermore, the team trained more than 430 employees (mostly project managers and business process owners) on EAM topics.

With regard to the four architecture maturity stages outlined by Ross et al. [ 5 ], the case organization is close to reach stage 3, where “companies move from a local view of data and applications to an enterprise view” [5, p. 76] and where “standardizing shared data and core business processes involves taking control over business process design from local business unit leaders” [5, p. 77]. On this maturity level, the core governance issue is to find the means to align project priorities (i.e., local perspectives) with EAM objectives (i.e., enterprise-wide perspective).

Phase 2: Despite having both implemented a wide range of architectural governance processes (with formal control mechanisms) and trained a considerable number of employees on EAM, the EAM team did not fully achieve its objectives. More precisely, the EAM team was confronted with the fact that a larger and relevant group of employees were still reluctant to adopt enterprise-wide concerns when taking design decisions affecting the enterprise architecture. According to control theory, informal control was missing, as the shared norms and values did not yet emphasize the value of an enterprisewide perspective sufficiently.

This reluctance was, for instance, manifested in project owners who still had a clear local (product, process, project) perspective, and did not sufficiently consider the side effects, or the use of synergies. Also, the costs created for later integration, operation, and decommissioning were not sufficiently taken into consideration when making design choices. As a result, the case organization was confronted with the negative consequences of operating a complex EA, such as high operating costs (75%+ of all IS costs), lacking global visibility of applications, and, as a consequence, redundancies (among the 5,000 applications), heterogeneity in technology infrastructure, and difficulties in reflecting business processes end-to-end in the IS landscape.

The observation of the EAM team is thereby congruent with the perception of other members of the organization. As an internal survey in the case company has shown, only approximately half of the participants (52%) were familiar with architectural guidelines and the organization’s target architecture. At the same time, only 15% of the participants believed that the IT application landscape met the requirements defined by the EAM team. As a consequence, the aim of the intervention design is to influence the decision-making process of local entities, so that these opt for design alternatives that are in line with enterprise-wide concerns.

Phase 3: As the company had already deployed many formal coordinative EAM interventions with unsatisfactory effects, the idea was to try a non-mainstream alternative: a pioneering informal intervention that involves the company’s social system. Among the social interventions, the mixed company-researcher workgroup decided to create an enterprise-level assessment instrument for important decisions in innovation projects – and make results available throughout the company. Due to the existing experience with labels in other domains of institutionalization, it was decided to cocreate and roll out an “Enterprise Architecture Label” (EAL). The EAL shall provide information on the contribution of local entities to the overall state of the enterprise architecture. It should then nudge local entities to consider enterprise-wide concerns when making their local, IS-related design choices. 31% 66% 9 years 7352 USD

3.73 Controlling

26.04.2018

The EAL was designed in three iterations. The first iteration encompassed all design activities with regard to the measurement system, i.e., the collection of measurement items to assess the degree to which local entities follow an enterprise-wide perspective. The second one focused on the aggregation process, i.e., the procedure to transform the results of the individual measurement items into an overall label rating. The third iteration was dedicated to the presentation, i.e., the actual design of the label. In all iterations, it was important to incorporate as many company architects, senior IT managers and business managers as possible to ensure that the EAL’s message was understood, its data was credible and it could be expected that its company-public presentation (intranet) would have the aspired compliance effect. This phase’s result, the EAL, is illustrated in Figure 2.

Phase 4: As the objective of ADR is to create (projectable) design knowledge [35] rather than just contextualized problem solutions, firstly several design revisions were done in the workgroup for the country unit were the label was intended to be rolled out, and secondly an additional, second country unit with slightly different contextual factors was chosen to triangulate not only EAL’s usefulness evaluation, but also to contribute to the projectability of the design at least within the case organization.

Phase 5: As opposed to the iterative testing and thus formative evaluations in phase 4, this phase represents a summative evaluation of the design endeavor. At this point, the requirements from phase 1 were used as a baseline to evaluate the artefact [ 31 ]. Evaluative evidence was collected • from users by asking whether they understood the label’s message, found the presented information credible and believed it would influence their decision-making and • from IT management by analyzing whether autonomous decisions in fact complied better with enterprise-wide objectives after the roll-out of the intervention.

While the former results were encouraging, the evaluation of effects was made difficult by the fact that, in the engineering company, a significant portion of their business (and supporting IT applications) were carved out during the observation period and, in the bank, the pandemic and internal strategic decisions caused the new interventions to be rolled out with delay and as part of a larger system update.

Phase 6: The conceptual foundations of control theory, institutionalization theory, informal intervention typology, candidate portfolio derivation, ADR, digital nudge method and pilots in several business units provided a good foundation for learnings that go beyond situated design experiences. Conference papers allowed to present and discuss nascent design principles that are intended to ultimately lead to a design theory for informal coordination interventions.

9. Discussion and conclusions

This paper aims at integrating the relevant knowledge components for informal interventions as a complementary approach for enterprise-wide IS coordination. Exhibiting all essential characteristics of enterprise-wide IS coordination (coverage of multiple solution life cycles, coverage of the complete business-to-IT stack of aspects, covering all fundamental items of interest), having been extensively covered in academic discourses and having been widely adopted in practice, EAM was chosen as a “running example” of enterprise-wide IS coordination. For EAM, but projectable to other IS coordination problem sub-classes, important aspects of traditional as well as alternative coordination interventions were discussed, and comprehensive design knowledge was consolidated.

Referring to the adaption of the general design knowledge concept to enterprise-wide IS coordination in Section 3 (see Figure 1), this study presented the following knowledge components as a coherent whole: • Descriptive knowledge (cause-effect statements, Section 4): Potential justificatory knowledge is derived from coordination and institutionalization theory. It covers a taxonomy of control interventions and explanations in which ways solution designers react to architectural coordination. • Projectable design knowledge (means-ends statements, Sections 5 and 6): We presented a generic typology of 26 informal coordination interventions and reported how 23 types of contextualized interventions can be derived by considering a specific IS coordination perspective (EAM) and a specific company context (large insurance company). • Instantiation knowledge (design feature – design effect statements, Sections 7 and 8): We presented a method that implements contextualized EAM interventions using insights from Action Design Research and Digital Nudging. As exemplary outcome, the application context and design process of the EAL in a very large global engineering company was summarized.

Figure 3 instantiates the generic model of Figure 1 for the design objective (manage complexity), problem class (effective intervention design), context (EAM, insurance company) and instantiation (EA label) of this study. Although the discussion of design knowledge aimed at a high level of projectability, additional studies and case reviews may very well extend the design foundations and allow to identify additional relevant characteristics, additional intervention types and more elaborate design methods. Being designed artifacts, taxonomies and methods are intended to be useful for a specific purpose – so that different objectives and contexts may require changes and / or extensions.

IS managers and senior management may appreciate this research as a valuable source of inspiration when extending their portfolio of coordination mechanisms. They may either be inspired by or adapt the context-free intervention typology, adapt the EAM intervention catalogue to other coordination tasks and to their company context, or even the presented nudge instantiation to their particular needs – or they may be encouraged to identify and try out new, innovative informal control mechanisms based on the discussed general concepts. Ultimately, we hope to contribute to an avenue that hopefully allows IS coordination to overcome empirically observed productivity barriers and continues to constitute an effective approach for enterprise-wide coordination also in times of increased decentralization and decision autonomy.

We believe that the interplay of descriptive (explanatory) IS knowledge, projectable IS design knowledge derived from that foundation, and utility evidence from Action Research to address major challenges of IS in organizations (complexity, local-global coordination) is also of value for IS researchers. The “comprehensive design knowledge” model that underlies this study is a nice example not only for the integration of behavioral (acceptance, nudging), organizational (local-global coordination) and technical (IS harmonization, IS architecture) aspects, but also for the integration of descriptive, design and action research. 10.References [35] J. vom Brocke, R. Winter, A. R. Hevner, and A. Maedche, "Accumulation and Evolution of Design Knowledge in Design Science Research – A Journey Through Time and Space", Journal of The Association for Information Systems, vol. 21, no. 3, 2020, pp. 520-544.

References

[1] J. Beese , S. Aier , K. Haki , and P. Aleatrati Khosroshahi , "Drivers and Effects of Information Systems Architecture Complexity: A Mixed-Methods Study," in 24th European Conference on Information Systems (ECIS) , Istanbul, 2016

[2] M. Brosius , S. Aier , M. K. Haki , and R. Winter , "The institutional logic of harmonization: local versus global perspectives," in Enterprise Engineering Working Conference, 2018 : Springer, pp. 3 - 17 .

[3] M. Brosius , Mohammad K. Haki , and S. Aier , "Themes of Coordination in IS Reference Theories," in European Conference on Information Systems (ECIS) , Istanbul, 2016 .

[4] R. Winter and R. Fischer , "Essential Layers, Artifacts, and Dependencies of Enterprise Architecture" , Journal of Enterprise Architecture , vol. 3 , no. 2 , 2007 , pp. 7 - 18 .

[5] J. W. Ross , P. Weill , and D. C. Robertson , Enterprise Architecture as Strategy. Creating a Foundation for Business Execution , Harvard Business School Press, Boston, MA, 2006 .

[6] G. Shanks , M. Gloet , I. Asadi Someh , K. Frampton , and T. Tamm , "Achieving Benefits with Enterprise Architecture" , Journal of Strategic Information Systems , vol. 27 , 2018 , pp. 139 - 156 .

[7] J. W. Ross and A. Quaadgras , "Enterprise Architecture Is Not Just for Architects," Center for Information Systems Research , Sloan School of Management, MIT, Cambridge, MA, 2012 .

[8] J. L. G. Dietz , Architecture. Building strategy into design , Academic Service, The Hague, 2008 .

[9] R. D. Schilling , "Enterprise Architecture Complexity: Implications for the Portfolio of Control Mechanisms," PhD Dissertation #4964, University of St. Gallen, 2020 .

[10] A. Tiwana , "Systems Development Ambidexterity: Explaining the Complementary and Substitutive Roles of Formal and Informal Controls" , Journal of Management Information Systems , vol. 27 , no. 2 , 2010 , pp. 87 - 126 .

[11] A. Susilo , J. Heales , and F. Rohde , "Project Management Effectiveness: The Choice-Formal or Informal Controls" , Australasian Journal of Information Systems , vol. 15 , no. 1 , 2007 , pp. 153 - 167 .

[12] H. Avdiji and R. Winter , "Knowledge Gaps in Design Science Research," Proceedings of the 40th International Conference on Information Systems , Munich, Germany, 2019 .

[13] K. Peffers , T. Tuunanen , M. Rothenberger , and S. Chatterjee , "A Design Science Research Methodology for Information Systems Research" , Journal of Management Information Systems , vol. 24 , no. 3 , 2007 , pp. 45 - 77 .

[14] W. A. Cram , M. K. Brohman , and B. R. Gallupe , "Addressing the Control Challenges of the Enterprise Architecture Process" , Journal of Information Systems , vol. 29 , no. 2 , 2015 , pp. 161 - 182 .

[15] S. Aier , B. Gleichauf , and R. Winter , "Understanding Enterprise Architecture Management Design - An Empirical Analysis," in Proceedings of the 10th International Conference on Wirtschaftsinformatik (WI 2011 ), 2011 .

[16] W. F. Boh and D. Yellin , "Using Enterprise Architecture Standards in Managing Information Technology" , Journal of Management Information Systems , vol. 23 , no. 3 , 2006 , pp. 163 - 207 .

[17] G. L. Richardson , B. M. Jackson , and G. W. Dickson , "A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise" , MIS Quarterly , vol. 14 , no. 4 , 1990 , pp. 385 - 403 .

[18] The Open Group, The Open Group Architecture Framework (TOGAF) Version 9 .2, Van Haren Publishing , Zaltbommel, 2018 .

[19] J. A. Zachman , "A Framework for Information Systems Architecture" , IBM Systems Journal , vol. 26 , no. 3 , 1987 , pp. 276 - 292 .

[20] J. W. Ross . Enterprise Architecture: Driving Business Benefits from IT . MIT Sloan Research Paper, 2006 . http://web.mit.edu/cisr/working%20papers/cisrwp359.pdf

[21] M. Lankhorst , Enterprise Architecture at Work: Modelling, Communication and Analysis , 2 ed., Springer, Berlin, Heidelberg, 2009 .

[22] C. Schmidt and P. Buxmann , "Outcomes and Success Factors of Enterprise IT Architecture Management: Empirical Insight from the International Financial Services Industry" , European Journal of Information Systems , vol. 20 , no. 2 , 2011 , pp. 168 - 185 .

[23] M. Lange , J. Mendling , and J. Recker , "An Empirical Analysis of the Factors and Measures of Enterprise Architecture Management Success" , European Journal of Information Systems , vol. 25 , no. 5 , 2016 , pp. 411 - 431 .

[24] Ö. Uludağ , S. Nägele , and M. Hauder , "Establishing Architecture Guidelines in Large-Scale Agile Development Through Institutional Pressures," in Twenty-fifth Americas Conference on Information Systems (AMCIS 2019 ), Cancun, Mexico, 2019 .

[25] R. Winter , "Architectural Thinking" , Business & Information Systems Engineering , vol. 6 , no. 6 , 2014 , pp. 361 - 364 .

[26] S. Weiss , S. Aier , and R. Winter , "Institutionalization and the Effectiveness of Enterprise Architecture Management," in 34th International Conference on Information Systems (ICIS 2013 ), Milano, Italy, 2013 .

[27] L. Kneubühler , "Interventionen für einflussbasiertes Unternehmensarchitekturmanagement," Master Thesis , Universität St.Gallen, 2019 .

[28] D. Erni , "Entwicklung von Massnahmen zur Förderung von Architectural Thinking in der CSS Versicherung," Diplomarbeit, Institut für Wirtschaftsinformatik, Universität St . Gallen, 2020 .

[29] M. K. Sein , O. Henfridsson , S. Purao , M. Rossi , and R. Lindgren , "Action Design Research" , MIS Quarterly , vol. 35 , no. 1 , 2011 , pp. 37 - 56 .

[30] R. H. Thaler and C. R. Sunstein , Nudge. Improving Decisions About Health, Wealth and Happiness , Penguin, London, UK, 2008 .

[31] T. Mirsch , C. Lehrer , and R. Jung , "Making Digital Nudging Applicable: The Digital Nudge Design Method," in 39th International Conference on Information Systems (ICIS 2018 ), San Francisco, USA, 2018 .

[32] M. Cahenzli . Guiding the Institutionalization of Behaviour: Designing a Nudging-inspired Solution , Working Paper, Institute of Information Management, University of St.Gallen, 2020 .

[33] J. W. Meyer and B. Rowan , "Institutionalized Organizations: Formal Structure as Myth and Ceremony" , American Journal of Sociology , vol. 83 , no. 2 , 1977 , pp. 340 - 363 .

[34] R. D. Schilling , S. Aier , and R. Winter , "Designing an Artifact for Informal Control in Enterprise Architecture Management," Proceedings of the 40th International Conference on Information Systems (ICIS 2019 ), Munich, Germany, 2019 .