=Paper=
{{Paper
|id=Vol-3016/paper13
|storemode=property
|title=Beyond incentives and sanctions – Extending the portfolio of IS coordination by systematic design of informal interventions
|pdfUrl=https://ceur-ws.org/Vol-3016/paper13.pdf
|volume=Vol-3016
|authors=Robert Winter
|dblpUrl=https://dblp.org/rec/conf/stpis/Winter21
}}
==Beyond incentives and sanctions – Extending the portfolio of IS coordination by systematic design of informal interventions==
https://ceur-ws.org/Vol-3016/paper13.pdf
Beyond Incentives and Sanctions – Extending the Portfolio of IS
Coordination by Systematic Design of Informal Interventions
Robert Winter1
1
Institute of Information Management, University of St.Gallen, Müller-Friedberg-Strasse 8, 9000 St. Gallen,
Switzerland
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 management, informal
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
7th International Workshop on Socio-Technical Perspective in IS development (STPIS 2021) 11-12 October 2021, Trento, Italy
EMAIL: robert.winter@unisg.ch (A. 1)
© 2021 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
143
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
144
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 feature-
measurable 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.
Figure 1. Multi-level structure of design knowledge
145
Figure 1 illustrates the way the components of this study correspond to the conceptual structure of
projectable design knowledge. The upper layer represents descriptive knowledge, the middle layer
represents the core projectable design knowledge (which consists of several sub-layers of increasing
contextualization / decreasing projectability), and the lower layer deals with instantiation and presents
expository design instances.
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.
Table 1
Formal and Informal Control Mechanisms in EAM (adapted from [9])
Mode of control Definition Exemplary EAM interventions
Formal Input Control through the allocation of Situational EAM design
control control - human resources methods [15]
- financial resources
- material resources
- organizational arrangements
Behavior Control through the definition of - EAM standards & principles
control - processes to govern the actions of [16, 17]
individuals - EAM frameworks [18, 19]
- mechanisms to observe the behavior of - EAM maturity models [20]
various stakeholders
- rules in guiding actions - reward systems
for compliance
Outcome Control through the definition of - EA modeling methods [4, 21]
control - specifications of desired outcomes - EA(M) outcome measures
- processes to measure and promote [22, 23]
outcomes
Informal Self Control through the definition of Team-specific EA guidelines/
control control - goals by individuals challenges [24]
- individual’s voluntary
improvement/learning activities
Clan Control through values and norms - Architectural thinking [25]
control - shared norms, values, and beliefs - Influence-based approaches
- reflection activities [26]
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,
146
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.
147
Table 2
Types of Interventions (adapted from [27])
Base
Intervention type Level mecha- Timing Decision Type of
nism type control
Social norms I S -0 1n I
Loss aversion / I F + 1n F
negative framing
Positive framing I R - 1n I
Setting standards IOS C 0 1 FI
Priming I C - 1n I
Anchoring I C -0 1 I
Hyperbolic discounting I C -0 1 I
Preventing hyperbolic discounting I A -0 1 I
Simplification ITS A 0 1 I
Salience IT A -0 1n I
Transparency and disclosure ITOS A -0 1n FI
Feedback IT A - n FI
Binding I FR - n I
Persuasive communication I C - 1n I
Sensitivity training ITGO A - 1n I
Cross-functional training TGO ? - 1n I
Networking GO S - 1n I
Stakeholder Involvement TO S 0 1n I
Buildup of social capital IT S - 1n I
Moral contracts IT F - 1n I
Peer review TG F + 1n F
Peer pressure ITG SF -0+ 1n I
Corporate / group culture ITGO SF -0+ 1n I
Norms and values ITGO SF -0+ 1n I
Defining individual norms I FR - 1n I
Creating obligations I ? -0+ 1n I
Checklists IT A 0 1n F
Psychological ownership I ? -0+ 1n I
Psychological binding IT ? -0+ 1n I
Legend:
Level: I=individual; T=team/workgroup; G=guild/community; O=organization; S=society
Base mechanism: S=status/image; F=fear/sanction; R=reward/incentive; C=carelessness;
A=attentiveness
Timing: - =before; 0=during; + = after decision-making
Type of decision: 1=once-only; n=repetitive
Type of control: F=formal; I=informal
148
Based on this context analysis, Erni combined generic interventions from the catalogue presented in
the preceding section to derive 23 informal intervention candidates. A qualitative analysis led to seven
clusters of EAM interventions: [28]
1. “Classical” EAM interventions
2. Decision support
3. Proactive information provision
4. Establishment of new communication channels
5. Enabling of collaboration and engagement
6. Adaptation of the EAM operating model
7. Involving the company’s social system
Table 3
Contextualized catalogue of informal interventions (adapted from [28])
Expected Expected
Cluster Intervention useful- practica-
ness bility
“Classical” Incorporate EAM function early into business/project design decisions 4 2.5
EAM Publish a catalogue of EAM services and analyses 3.5 4.5
interventions Provide (architectural) checklists for certain types of decisions in projects 3 3.5
Decision Provide individualized support for innovation projects 3.5 2
support Strategic dialogue with senior management and steering committees of 4 2.5
important innovation programs
Proactive Publish «success stories» of enterprise-wide coordination 3.5 4
information Publish architecture roadmaps 4 3
provision Publish transparent calculations of IT and complexity costs 3.5 3
Establishment Offer individualized, focused briefings for senior management 2.5 4
of new Inform top management regularly about architectural issues (so that it 2 3.5
communicatio becomes part of their middle management briefings)
n channels Conduct public «architecture talks» with internal and external speakers 3 3
Conduct trainings for specific architecture-relevant topics (e.g., complexity 3.5 3
vs. agility)
Enabling of Recruit and coach «coordination ambassadors» in business units or 2.5 2.5
collaboration important projects
and Establish an architecture board with all important management 3 2.5
engagement stakeholders (and selected specialists)
Involve business stakeholders in architectural decisions (and also publish 4 3
violations of architectural principles/roadmaps)
Invite business/project representatives to develop architectural 3.5 2
principles/roadmaps
Conduct architecture reviews and retrospectives for projects (where it 3.5 3.5
matters)
Adaptation of Lobby for consideration of architectural coordination objectives in 4.5 2.5
the EAM enterprise-level objectives
operating Support major investment decisions by providing architecture-related 3.5 1.5
model decision support
Establish an product/service-centric (rather than a project-centric) EAM 4 1.5
organization
Involving the Create an enterprise-level assessment instrument (e.g., a label) for 3 3
company’s important decisions in innovation projects and publish it
social system Facilitate peer reviews (architectural reviews of decisions by business peers 3 3
rather than by EAM team)
Create «architecture awards» to honor desirable behavior (compliant, 1.5 3
sustainable innovations) of business units or projects
149
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 four-
stage 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.
150
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].
151
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 enterprise-
wide 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 co-
create 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.
152
Controlling
31%
66%
9 years
7352 USD
3.73
Controlling 26.04.2018
Figure 2: Enterprise Architecture Label [34]
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.
153
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: Design Knowledge “Informal Interventions for IS Coordination”
154
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
[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.
155
[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.
156
[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.
157