Conference PaperPDF Available

Establishing Architecture Guidelines in Large-Scale Agile Development Through Institutional Pressures

Authors:

Abstract and Figures

In today's business environments, organizations are confronted with rapid technological advancements, regulatory uncertainties, and time-to-market pressures. The ability to detect relevant changes and to react timely and effectively becomes an important determinant for business survival. As a result, companies are striving to adopt agile methods on a larger scale to meet these requirements. The adoption of agile methods at scale poses new challenges such as inter-team coordination and communication, balancing intentional and emergent architecture or coordinating various development activities to produce desirable enterprise-wide effects. The latter can be addressed by applying architecture principles and guidelines. However, there is a lack of academic research on how architecture principles can be created and applied in large-scale agile development. Based on a mixed methods research design, this paper proposes a tool supported collaborative approach for establishing architecture principles and guidelines in an agile fashion.
Content may be subject to copyright.
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
1
Establishing Architecture Guidelines in
Large-Scale Agile Development Through
Institutional Pressures
Completed Research
Ömer Uludağ
Technische Universität München
oemer.uludag@tum.de
Sascha Nägele
Technische Universität München
sascha.naegele@tum.de
Matheus Hauder
Allianz Deutschland AG
mattheus.hauder@allianz.de
Abstract
In today’s business environments, organizations are confronted with rapid technological advancements,
regulatory uncertainties, and time-to-market pressures. The ability to detect relevant changes and to react
timely and effectively becomes an important determinant for business survival. As a result, companies are
striving to adopt agile methods on a larger scale to meet these requirements. The adoption of agile methods
at scale poses new challenges such as inter-team coordination and communication, balancing intentional
and emergent architecture or coordinating various development activities to produce desirable enterprise-
wide effects. The latter can be addressed by applying architecture principles and guidelines. However, there
is a lack of academic research on how architecture principles can be created and applied in large-scale agile
development. Based on a mixed methods research design, this paper proposes a tool supported
collaborative approach for establishing architecture principles and guidelines in an agile fashion.
Keywords
Architecture guidelines, enterprise architecture management, large-scale agile development
Introduction
Nowadays, enterprises struggle to cope with unpredictable competitive environments due to rapidly
changing customer demands, regulatory changes, and technological advances (Sherehiy et al. 2007; Weill
and Woerner 2015). The ability to detect relevant changes and to react fast and effectively becomes a
significant competitive advantage (Overby et al. 2006). Software development projects in such
environments are constantly confronted with changes. The agile movement that emerged in the 1990s led
to the development of the Agile Manifesto (Beck et al. 2001) and many agile software development methods,
including eXtreme Programming (XP) and Scrum, to meet these challenges (Kettunen 2007). With these
agile methods, small, self-organizing teams work closely with customers in a single-project context,
maximizing customer value and quality of delivered software product through rapid iterations and frequent
feedback loops (Kettunen 2007). The success of agile methods has inspired organizations to increasingly
apply them to large-scale endeavors (Dingsøyr and Moe 2014). However, the adoption at larger scale entails
new challenges such as inter-team coordination and communication, balancing intentional and emergent
architecture or the effective coordination and alignment of multiple agile teams and development activities
(Dikert et al. 2016; Ovaska et al. 2003; Uludağ et al. 2017).
In the past few years, enterprise architecture management (EAM) established itself as a valuable
governance mechanism to steer and align transformations of organizations by connecting strategic
considerations to the execution of large-scale agile projects (Greefhorst and Proper 2011; Hauder et al.
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
2
2013). It covers business, application, information, and infrastructure dimensions of a company and
promotes the alignment of business and IT (Weill and Ross 2009).
Hitherto, EAM initiatives created and enforced top-down architecture principles to steer enterprise
transformations (Greefhorst and Proper 2011; Winter 2016). This enforcement-centric view does not fit
well into increasingly widespread agile environments as it is typically ineffective and restricts the design
freedom of agile teams (Marks 2014; Winter 2016). As agile teams cannot be controlled by traditional EAM
measures with a reasonable effort, EAM initiatives need to focus not only on enforcement, but also on
influence through informing, legitimating, and socializing (Winter 2016). Hence, there is a need to
complement the enforcement-centric view of EAM by an influence-centric view (Winter 2016) that
delegates decision-making power to agile teams and thus counteracts acceptance issues of agile teams
towards EAM governance efforts (Marks 2014). Although the number of companies using agile methods is
increasing, there is a lack of academic research on how architecture principles can be established in an agile
fashion (Greefhorst and Proper 2011). We aim to fill this gap by raising the following research questions:
RQ 1: How can agile teams (ATs) and enterprise architects (EAs) collaboratively establish and manage
architecture principles and guidelines in large-scale agile development?
RQ 2: How can the collaborative approach for establishing architecture principles and guidelines be
supported by a software application?
Background and Related Work
Agile methods such as Scrum or XP rely mainly on emergent design practices, meaning that architecture
emerges from the system and is not imposed by some direct structuring force (Babar 2009). The practice
of emergent design is effective at the team level but insufficient when applying agile methods on a larger
scale. For large-scale agile development, some amount of architectural planning and governance becomes
even more important (Leffingwell et al. 2008) as they ensure the alignment of multiple ATs to produce
desirable organization-wide effects (Ovaska et al. 2003) and provide a common target vision (Greefhorst
and Proper 2011). Alike Greefhorst and Proper (2011), we take the view that the mutual alignment and
coordination of large-scale agile transformations can be achieved by using architecture principles. The
general intend of architecture principles is to set a constraint on the design space and decisions (cf. (Haki
and Legner 2013; Op’t Land and Proper 2007)). Based on a structured literature review on architecture
principles, Stelzer (2010) defines (enterprise) architecture principles as fundamental propositions that
guide the description, construction, and evaluation of (enterprise) architectures”.
Like other governance mechanisms, EAM initiatives have traditionally created and enforced top-down
architecture principles that are sometimes ignored by ATs because they usually prefer independence and
self-responsible decisions (Dikert et al. 2016; Greefhorst and Proper 2011; Winter 2016). To counter
acceptance issues, Winter (2016) proposes to complement the enforcement-centric view of traditional EAM
by an influence-centric view. This view aims to communicate the strategic importance of EAM for the
organization, demonstrating benefits, and involving ATs in the decision-making process (Winter 2016). The
influence-centric view can be exerted by normative and mimetic pressures. Normative pressures cater an
obligatory dimension into social life by shared values, norms, standards, and social obligations. Mimetic
pressures result from similar responses to uncertainty and refer to the imitation of an organization that is
seen by another as more legitimate or successful, according to the logic of perceived benefits (DiMaggio and
Powell 1983). Applied to EAM, normative pressures influence local project decisions, e.g., by organizing
architecture events or issuing architecture awards. Mimetic pressures also influence local project decision,
e.g., by making architecture success stories visible (Brosius et al. 2019).
The problem we aim to address with this study is three-fold: First, while earlier works (cf. (Brosius et al.
2019; Winter 2016)) claim that the enforcement-centric view of EAM can be complemented by an influence-
centric view, there is no other work that illustrates how this can be achieved using a concrete EAM artifact
such as architecture principles. Second, EAM literature still focuses mainly on the definition and
characterization of architecture principles (cf. (Op’t Land and Proper 2007; Stelzer 2010). However, there
is a lack of academic research on how principles can be used to coordinate large-scale agile endeavors.
Third, with a few exceptions (cf. (Greefhorst and Proper 2011), extant literature disregards how principles
can be enforced without encountering the resistance of agile teams.
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
3
In the light of these problems, we propose a solution based on the following three pillars:
We propose the usage of architecture principles and guidelines to coordinate large-scale agile
development endeavors.
We recommend extending traditional EAM by taking an influence-centric view on the
establishment of architecture principles and guidelines. This means that ATs affected by
government efforts are enabled to participate and influence the governance processes.
We use the analogy of belts from martial arts to award ATs that comply with architecture principles
and guidelines (normative pressure) and make their success stories transparent to other teams
(mimetic pressure). The term "belt" is a metaphorical reference to the different ranks in martial
arts. Instead of having tests as in most martial arts, teams rank up by fulfilling guidelines.
Research Methodology
To propose a tool supported collaborative approach for establishing architecture principles and guidelines,
we chose a mixed methods research design (Tashakkori and Teddlie 2010), and combined case study and
design science in the research process. This approach helped us to perform in-depth empirical investigation
and to develop design artifacts.
Our research process has two steps. First, we conducted an exploratory single-case study (Runeson and
Höst 2008) to investigate how architecture principles and guidelines are formulated and used to steer large-
scale agile transformations. We chose to study a large insurance company because of its long history in
traditional EAM governance approaches, the adoption of agile methods on a large scale, and the regulatory
pressure in the financial sector. We focused primarily on first- and third-degree data collection techniques
(Lethbridge et al. 2005). We used first-degree methods to get in direct contact with the subject and to collect
data in real time. To this end, we participated in governance and large-scale agile meetings and conducted
two types of interviews. First, we used unstructured interviews to further investigate and understand the
problem domain, as well as to refine the requirements used for artifact development. We also conducted
semi-structured interviews with five key stakeholders to develop an understanding of goals and drivers for
defining principles and guidelines, identify new stakeholders, and analyze compliance mechanisms and
related challenges. All questions within the semi-structured interviews contained a combination of open
and closed questions (Runeson and Höst 2008). The interviewees were two EAs, two agile developers
(ADs), and one lead scrum master. We supplemented our interview findings by third-degree data collection
techniques, which allowed us to get an independent analysis of work artifacts where we used already
available data. Here, the case organization's wiki pages provided us with detailed information about its EAM
initiative, architecture principles and guidelines. We used open coding for analyzing the wikis, protocols,
and interviews (Miles et al. 2014). After creating preliminary codes, we refined and consolidated our codes
by merging related ones and removing duplicates. Then, we examined groups of code phrases and merged
them into concepts that were incorporated into our design artifacts.
Second, we applied design science research (Hevner et al. 2004; Peffers et al. 2007) which centers around
creating and evaluating new artifacts within a problem domain, intending to solve identified organizational
problems (Hevner et al. 2004). In this paper, it lays the groundwork for systematically developing a tool-
supported, collaborative approach for establishing principles and guidelines in large-scale agile endeavors.
The two resulting design artifacts are (1) a concept for a collaborative approach for establishing architecture
principles and guidelines, and (2) a prototypical web application to the collaborative approach. We have
incorporated the case study findings into the development of both design artifacts. At the end of the second
step, we conducted fifteen semi-structured interviews to evaluate our design artifacts.
Case Description
The case under investigation is one of the largest insurance companies in the world having more than
140.000 employees and represented in more than 70 countries. To keep pace with rising customer
expectations and rapidly changing environments, the company decided in 2016 to introduce agile methods
on a larger scale. In the course of the large-scale agile transformation, the insurance company began to
build co-located agile units in dedicated locations detached from traditional development endeavors. Based
on their success stories, the case company decided to initiate the second wave of the transformation, by
applying agile methods across the enterprise. The insurance company is running ten large scale-agile
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
4
development programs with more than 5,000 employees. The EA team of the insurance company is tasked
with the mutual alignment of the running large-scale agile development programs, particularly with regard
to the technologies and standards used. In addition, the EA team supports and collaborates closely with
ATs on a regular basis to guide them through business and technical roadmaps and help them to build
potentially reusable assets. A particularly important task of the EA team is to support ATs by making
appropriate governance decisions and providing common guidance through standards and architecture
guidelines. However, the case company faces several challenges with regard to the development and use of
architecture principles and guidelines. First, these artifacts were enforced by central architecture
committees (enforcement-centric view of EAM) based on a command and control mentality that led to
significant resistance by ATs. Second, although there is already a well-defined process for creating new
principles and guidelines, there is a lack of guidance for applying principles and managing their compliance,
which severely impacts the overall awareness and compliance with those principles and guidelines. The lack
of transparency and consequences for non-compliance further aggravates this challenge.
Establishing Architecture Principles and Guidelines
Our approach aims to complement the top-down enforcement of architecture principles and guidelines with
an influence-centric view that exerts normative and mimetic pressures. Our understanding of an agile EAM
initiative is that it revolves around a liberal stance on governance, placing more trust and responsibility in
ATs. Because both benefit from close collaboration (Canat et al. 2018), we propose a community of EAs and
ATs to collaboratively conduct a process of establishing principles and guidelines (see Figure 1). Particularly
in large-scale agile development, expertise can be spread across multiple locations and teams, making
communities very critical for networking and knowledge-sharing (Moe et al. 2014). Such a community
should not only focus on principles and guidelines but also discuss architectural topics in general. This
process extends the generic architecture principle process of (Greefhorst and Proper 2011) by taking the
additional perspective of the ATs into account. Other than Greefhorst and Proper (2011), we suggest a vote
and accept phase to emphasize community-driven decisions. The community involves EAs with the aim of
achieving global, company-wide optimum and ATs with a bottom-up perspective. Each team should select
one representative to join the respective community to keep the decision-making ability efficient. The same
applies to architects. The community should be open to all interested parties and not force participation.
Figure 1. Overview of the collaborative approach to establish principles and guidelines
(1) Derive drivers: EAs determine drivers by analyzing relevant sources and collecting suitable input for
deriving architecture principles, e.g., organization-wide goals and objectives, values defined as part of the
IT strategy or legal constraints (Greefhorst and Proper 2011). ATs can use their implementation experience,
actual implementation issues, team-specific agreements, and technical innovations as a basis for deriving
principles and guidelines. This bottom-up perspective provides valuable input by considering practical
experience showing how governance activities impact actual implementation.
Guideline
Set B
Agile Teams
Top-down, strategical perspective
( “global optimum”)
Bottom-up, operational perspective
( “local optimum”)
Enterprise Architects
Determine principles and
guidelines
Determine principles
and guidelines
Specify and classify
Apply principles and guidelines
Determine drivers
Goals and objectives
Values
(Legal) constraints
Potential risks and rewards
Determine drivers
Implementation experience
Issues
Team-specific agreements
Technical innovation
team representatives
architect representative(s)
Handle changes
Vote and accept
Guideline
Set A
use identified
drivers to GuidelineGuideline
KPI
KPI
Principle
KPI
KPI
1
1..n
1..n
Guideline
Set C
suggest
candidates
11
2 2
3
45
7
use identified
drivers to
suggest
candidates
validate and propose
new principles or
guidelines
give feedback
6Manage compliance
document usage (& integrate automated tests)
Assist with applying principles
5
6Manage compliance
collect feedback
monitor usage
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
5
(2) Determine principles and guidelines: EAs use identified drivers to derive architecture principles.
Following this, they generate a list of possible principles, select relevant principles, and formulate actual
principle statements (Greefhorst and Proper 2011). This step is also performed by ATs.
(3) Specify and classify: Unlike Greefhorst and Proper (2011), we combine the specification and
classification of principles in one step. The reason for this is that a principle or guideline should be specified
in a way that the result is most useful for the intended target group. Greefhorst and Proper (2011) also
recognize the importance of the specificity of principles since their fulfillment need to be assessable. Our
approach ensures this specificity by differentiating between principles and guidelines. We propose to define
KPI as fulfillment criteria for guidelines and to transform a principle into one or more specific guidelines,
if necessary. This need arises when the principle is too abstract or unspecific so that it cannot guide the
actual implementation or when its fulfillment criteria cannot be defined.
(4) Vote and accept: High-quality principles and guidelines require a solid validation process. Greefhorst
and Proper (2011) point out that the validation process can be highly standardized and include specific
roles. We believe that the community should be responsible for the final decision on the adoption. They
should discuss and vote on the adoption, refinement or rejection of a principle or guideline. We
acknowledge that ATs and EAs will require an increased effort and commitment to present proposals
convincingly. In our opinion, a democratic vote, i.e., every representative of the ATs has the same right to
vote as any EA within the community, requires a certain degree of organizational maturity. We believe that
principles or guidelines driven by legal requirements should not be voted on.
(5) Apply principles and guidelines: ATs apply architecture principles and guidelines that are accepted by
the architecture community. EAs assist ATs by ATs during their realization. In turn, ATs provide feedback
on applied guidelines. Figure 2 illustrates how normative and mimetic pressures can be exerted on ATs.
First, by complying with principles and guidelines, teams can rank up from the white to the black belt. This
analogy was adapted from martial arts to issue architecture awards to ATs, thus influencing them through
normative pressures. By making the respective belts of the ATs transparent, ATs are influenced by mimetic
pressures. The advantages are two-fold: First, the success stories of ATs are indicated by the belt color and
made visible to others. Second, ATs with higher ranks act as a role model and support lower belt teams,
which in turn can request assistance from higher belt teams.
Figure 2. Facilitating the use of guidelines by exerting normative and mimetic pressures
(6) Manage compliance: Our approach aims to solve acceptance issues by providing ATs both the
responsibility to adhere and the freedom to neglect a particular guideline. In both cases, they must
document these decisions as the community needs an overview of guidelines with a low level of compliance.
Low compliance can indicate implementation or specification issues. Our web application supports ATs and
EAs by providing an overview of which guidelines are applied by which teams. The manual compliance with
all guidelines can be effortful which can be reduced by automated testing.
(7) Handle changes: Our approach encourages EAs to collect feedback from involved stakeholders that have
a genuine impression on the actual consequences of governance activities (Bente et al. 2012). Greefhorst
and Proper (2011) suggest adjusting principles based on insights originating from specific situations. Our
approach incorporates the experience of ATs by involving them in the change process and provides a
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
6
feedback mechanism where people can comment on principles, request changes, or discuss with peers on
specific experiences. Based on consolidated feedback, the community alters principles or guidelines which
require minor changes, while bigger changes lead to new ones.
Prototypical Implementation
We developed a web application to support the collaborative establishment of principles and guidelines.
Currently, the prototype focuses on supporting the application and management of compliance with
principles and guidelines. The core feature of the application is the guideline overview for each team (see
Figure 3). It provides the user a quick overview of guidelines relevant to his team and the compliance status.
Each tile represents a single guideline assigned to the current team. A green border indicates that the
currently selected team has set the guideline status to "fulfilled", a red border indicates that the team has
not met the guideline yet. The icons below the description indicate which teams already comply with the
guideline. Teams can use this information to contact other teams and ask for assistance. The information
icon button in the top right corner leads to the guideline detail screen.
Figure 3. Team-specific guideline overview
The team-specific dashboard displays the current belt of the selected team and the percentage of the
progress to reach the next belt level (see Figure 4). The activity feed on the right side displays cross-team
information. The area below shows other teams working on the same belt and their progress. This feature
aims to motivate and identify teams facing related challenges in a similar state of maturity.
Figure 4. Team-specific dashboard
Evaluation
We conducted semi-structured interviews with fifteen experts to evaluate the approach and prototype. The
interviewees were seven EAs (EA1 - EA7), one solution architect (SA1), and seven agile developers (AD1 -
AD7). The goal is to assess the acceptance by stakeholders and users regarding the artifacts and to identify
additional refinements. During the interviews, we presented our results and design artifacts and asked the
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
7
interviewees whether they (dis)agree with a statement and why. Figure 5 shows an overview of all questions
and answers from both stakeholder groups.
Figure 5. Evaluation results of the proposed collaborative approach
The collaboration between ATs and EAs was rated as very valuable for ATs. Some of the main advantages
mentioned were creating a shared understanding of the architecture (AD4, AD5), better understanding of
guidelines (AD3), and better access to information and guidance (EA1). Other benefits mentioned included
shorter feedback cycles and regular exchanges leading to continuous improvement of existing guidelines
(AD3, AD5, EA3). EA4 mentioned better awareness of principles and guidelines. Teams can also benefit
from the experience of others and avoid mistakes (AD7, EA6, EA7). "Dissolving the ivory tower, more
direct contact with the teams, being closer to the results and how principles and guidelines affect the
results" reflect the provided value add (EA4). Our approach helps EAs to understand that "one architect
can't know everything, people who implement it might come up with better or more pragmatic solutions"
(EA5). Close contact with the teams helps EAs to understand the concerns of developers (AD5, SA1, EA6,
EA7). Traditional committees often lack feedback on the impact of their decisions (EA6, EA7). The value of
the approach is reflected in the ability to get faster and better feedback from ATs (EA2), and direct feedback
on guideline proposals so that adjustments can be discussed together immediately (AD6). Interviewees
agreed with the statement that involving ATs as the main stakeholders increases acceptance and motivation.
EA4 notes that "principles and guidelines are mainly created by EAs, but the involvement of agile teams
is extremely important for the acceptance and compliance". The involvement also helps to validate the
impact of governance efforts and to avoid overspending time on theoretical concepts (AD7, SA1).
Implementation issues are regarded as essential because often only a few of them can be identified in
advance (EA1). In addition, developer often do not have overall business goals in mind because they focus
on technical aspects and implementation (AD3, EA6). Teams tend to focus on solving a single problem that
may be subpar from an enterprise perspective (EA1). The question regarding the voting mechanism
received mixed feedback. The most related positive argument was the higher acceptance of decisions (EA1,
EA2, EA4, EA6). AD4 supported the vote because of the belief in the "wisdom of the many" leading to better
decisions. Two participants claimed that such a voting mechanism could be challenging to implement (AD5,
EA4). AD2 agreed with the general idea but mentioned that there should be someone, in the end, taking
responsibility and exercising a veto right. This proposal was strongly supported by both groups. The
developers explained that EAs should not only introduce general guidelines but also ensure that teams can
apply them (AD3, AD5). They considered the knowledge and experience transfer as relevant (AD1, AD4).
The EAs had a similar view and argued that they might have additional helpful knowledge and skills (EA4).
This statement was controversially discussed. AD1 stated that there are better chances for teams to ask
themselves "what is the right thing to do?" (AD1). EA6 took a similar perspective and said, "if you are
responsible for something, you take better care of it". However, most participants stated that external
stakeholders should monitor and verify compliance with guidelines (AD7).
Figure 6 shows the evaluation results of the tool support where we asked participants to evaluate six
statements. The results show that the web application improves the current situation. Participants rated
the overview of existing guidelines, the transparency of guideline compliance, and the selection of
guidelines for a particular use case as significantly enhanced by the tool support.
Agile Teams Architects/PMs
Question 3: It is important that development teams do not just get architecture principles and guidelines
dictated by other stakeholders, but that they are the main stakeholder themselves [...] I strongly agree I strongly disagree
Question 4: Agile teams can provide valuable input for creating and refining common architecture
principles and guidelines drivers [...] I strongly agree I strongly disagree
Question 5: The input of enterprise architects to principles and guidelines is still important [...] I strongly agree I strongly disagree
I strongly agree I strongly disagree
I strongly agree I strongly disagree
I strongly agree I strongly disagree
Question 6: It makes sense to let the group of developers and enterprise architects vote if a new guideline
should be accepted in the pool or if a certain change should be made [...]
Question 7: It is important that enterprise architects support agile teams in applying architecture
principles and guidelines
Question 2: [...] In your opinion, how valuable is such a collaboration for the enterprise architects? Very val uab le Not valuable at all
Very val uab le Not valuable at allQuestion 1: [...] In your opinion, how valuable is such a collaboration for agile teams?
Question 8: Team s s h ou ld be se lf -respon sible for ma naging their compliance to guidelin es and not be
controlled by team-external stakeholders (e.g., enterprise architects)
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
8
Figure 6. Evaluation results of the tool support
Discussion
Key Findings
Four key findings emerge from this study: First, our results indicate that an agile EAM governance approach
can support large-scale agile development endeavors to align all relevant stakeholders towards EAM
governance efforts. Our findings are consonant with those of Winter (2016) who states that local
stakeholders’, i.e., ATs, acceptance of restricted design freedom can be improved by convincing them that
their social status will be raising and that they will be more efficient if they comply with architecture
guidelines (influence-centric view). Our proposed approach influences ATs by emphasizing informative,
legitimizing, and socializing aspects. This bottom-up perspective raises the acceptance of ATs towards EAM
governance efforts and increases the relevance and applicability of principles and guidelines. Based on the
analogy of belts from martial arts, we extend the work of Winter (2016) and give an example of how the
influence of EAM on local stakeholders can be improved. Second, alike Winter (2016), we recognize that
EAs need to focus not only on enforcement but also on influence by exerting normative and mimetic
pressures (Brosius et al. 2019). Our approach considers both by motivating ATs to participate in
architecture communities, awarding their achievements (normative), and making their success stories
visible (mimetic). Although many agile development contributions (cf. (Moe et al. 2008)) advocate
autonomy for ATs, we found that ATs do not necessarily insist on full autonomy as long as they have a say
in decision-making. However, they believe that some external stakeholders such as EAs are important in
evaluating their adherence to principles and guidelines so they can save time and focus on developing
software products. Third, similar to Drews et al. (2017), our findings reveal that EAs take a more supportive
and consulting role for ATs. EAs facilitate and moderate inter-team architecture exchange. Our proposed
approach and prototype enable EAs to monitor the adherence of ATs to principles and guidelines and to
avoid the ivory tower by working closely with them. However, unlike Drews et al. (2017), we believe that
EAs need to maintain an enterprise-wide focus to steer several large-scale agile efforts. ATs benefit from
this perspective as they can build a more conclusive understanding of the global architecture. Fourth, we
agree with Paasivaara and Lassenius (2014) that communities of practices (CoPs) can be vital for adopting
lean and agile methods in large organizations. Our approach proposes regular community meetings where
participants discuss architectural issues. Paasivaara and Lassenius (2014) describe several success factors
of CoPs, some of which are considered in our approach. We extend the research of Paasivaara and Lassenius
(2014) by providing a concrete example of a collaborative decision-making process within CoPs on
governance and architectural issues.
Limitations
Since we applied a mixed methods research design, comprising case study and design science research, we
will discuss the limitations of both research methods accordingly.
As the case study is exploratory and does not seek to establish causal relationships, internal validity is not
a concern. Construct validity refers to what extent the operational measures studied represent what the
researcher has in mind. As a countermeasure, we interviewed multiple persons with different backgrounds
and roles. Furthermore, one key informant reviewed a draft of our study report. External validity reflects
1
1, 5
2
2, 5
3
3, 5
4
4, 5
5
Question 1 Question 2 Question 3 Question 4 Question 5 Question 6
Without Tool-Support With Tool-Support
Strongly
agree
Strongly
disagree
Question 1: Agile teams and enterprise architects have a good
overview on which guidelines agile teams must or should adhere to.
Question 2: It is easy for agile teams and enterprise architects to
give feedback on guidelines.
Question 3: It is alot of effort to identify which guidelines a specific
agile team is fulfilling and which ones it is not fulfilling.
Question 4: It is easy for agile teams to look through existing
guidelines and select the guidelines that fit their use cases.
Question 5: It is simple to get an overview of which agile teams are
compliant to which guidelines.
Question 6: It is clear why an agile team decided against using a
specific guideline.
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
9
to what extent it is possible to generalize the findings and to what extent the findings are of interest to other
people outside the investigated case. To counter this, we included existing literature and related work into
the creation of our design artifacts. In addition, we presented and discussed the study results with our
industry partners. The discussion confirmed the relevance of our findings for other companies and that they
are interested in applying both artifacts. Reliability concerns to what extent data and analysis are
dependent on the specific researcher. We ensure the reliability of our results by collecting data from
different sources and by creating a case study database.
From a design science research perspective, the presented approach and web application were evaluated by
a limited number of ATs and EAs of the case company. Furthermore, since we created both design artifacts
based on our observations from one company, they may not be directly applicable without further
modification. Third, the web application may not yet be ready for productive use since it is a prototype.
Conclusion and Future Work
Traditionally, EAM initiatives enforced architecture principles to coordinate transformations by connecting
strategic considerations to the execution of large-scale agile projects (Greefhorst and Proper 2011; Winter
2016). The sole top-down enforcement of principles is not effective (Winter 2016), as it restricts the design
freedom of ATs and encounters their resistance (Marks 2014). Thus, there is a need to shift decision-making
authorities to ATs and to complement the enforcement of principles by an influence-centric view (Winter
2016). Our research is motivated by the lack of empirical studies on the establishment of architecture
principles and guidelines in an agile fashion. Accordingly, we conducted an exploratory case-study and
proposed a tool supported collaborative approach that uses the analogy of belts from martial arts for
establishing principles and guidelines. Evaluation results indicate that our approach takes the bottom-up
perspective of ATs into account and contributes to higher applicability of principles and guidelines by
exerting normative and mimetic pressures. Our approach allows communities to participate in the creation
of principles and guidelines, making the results of EAM governance efforts more transparent. Our tool
support provides a simple mean to get an overview of existing and applied guidelines and to give feedback.
In future work, we aim to apply and evaluate the proposed approach and web application in other
companies that are pursuing large-scale endeavors. In the current state of the prototype, ATs and EAs can
only manually maintain the current fulfillment status for the different guidelines. We will extend the
prototype by an integration service that collects data from various sources which are relevant to the
guideline fulfillment such as Xray or SonarQube. We also aim to implement a service that performs
automated testing based on the collected data to determine the level of compliance with guidelines.
References
Babar, M. A. 2009. An Exploratory Study of Architectural Practices and Challenges in Using Agile Software
Development Approaches,in 3rd European Conference on Software Architecture, pp. 8190.
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,
Highsmith, J., Hunt, A., Jeffries, R., and others. 2001. Manifesto for Agile Software Development.
Bente, S., Bombosch, U., and Langade, S. 2012. Collaborative Enterprise Architecture,Collaborative
Enterprise Architecture, Burlington: Morgan Kaufmann.
Brosius, M., Aier, S., Haki, M. K., and Winter, R. 2019. The Institutional Logic of Harmonization: Local
Versus Global Perspectives,in Advances in Enterprise Engineering XII, D. Aveiro, G. Guizzardi, S.
Guerreiro, and W. Guédria (eds.), Cham: Springer International Publishing, pp. 317.
Canat, M., Català, N. P., Jourkovski, A., Petrov, S., Wellme, M., and Lagerström, R. 2018. Enterprise
Architecture and Agile Development - Friends or Foes?, in 22nd International Enterprise
Distributed Object Computing Workshop.
Dikert, K., Paasivaara, M., and Lassenius, C. 2016. Challenges and Success Factors for Large-Scale Agile
Transformations: A Systematic Literature Review,Journal of Systems and Software (119), pp. 87
108.
DiMaggio, P. J., and Powell, W. W. 1983. The Iron Cage Revisited: Institutional Isomorphism and
Collective Rationality in Organizational Fields,American Sociological Review (48:2), pp. 147160.
Dingsøyr, T., and Moe, N. B. 2014. Towards Principles of Large-Scale Agile Development,in International
Conference on Agile Software Development, pp. 18.
Establishing Architecture Guidelines in Large-Scale Agile Development
Twenty-fifth Americas Conference on Information Systems, Cancun, 2019
10
Drews, P., Schirmer, I., Horlach, B., and Tekaat, C. 2017. Bimodal Enterprise Architecture Management:
The Emergence of a New EAM Function for a BizDevOps-Based Fast IT,in 21st International
Enterprise Distributed Object Computing Workshop, pp. 5764.
Greefhorst, D., and Proper, E. 2011. Architecture Principles: The Cornerstones of Enterprise Architecture,
Berlin: Springer.
Haki, M. K., and Legner, C. 2013. Enterprise Architecture Principles in Research and Practice: Insights
from an Exploratory Analysis,in 21st European Conference on Information Systems.
Hauder, M., Roth, S., and Matthes, F. 2013. An Examination of Organizational Factors Influencing
Enterprise Architecture Management Challenges,in 21st European Conference on Information
Systems.
Hevner, A. R., March, S. T., and Park, J. 2004. Design Science Research in Information Systems Research,
MIS Quarterly (28:1), pp. 75105.
Kettunen, P. 2007. Extending Software Project Agility with New Product Development Enterprise Agility,
Software Process: Improvement and Practice (12:6), Wiley Online Library, pp. 541548.
Leffingwell, D., Martens, R., and Zamora, M. 2008. Principles of Agile Architecture,Leffingwell, LLC. &
Rally Software Development Corp.
Lethbridge, T. C., Sim, S. E., and Singer, J. 2005. Studying Software Engineers: Data Collection Techniques
for Software Field Studies,Empirical Software Engineering (10:3), pp. 311341.
Marks, E. 2014. Governing Enterprise Agile Development Without Slowing It Down: Achieving Friction-
Free Scaled Agile Governance via Event- Driven Governance.
Miles, M., Hubermann, M., and Saldana, J. 2014. Qualitative Data Analysis: A Methods Sourcebook,
Thousand Oaks: Sage Publications.
Moe, N. B., Dingsøyr, T., and Dybå, T. 2008. Understanding Self-Organizing Teams in Agile Software
Development,in 19th Australian Conference on Software Engineering (Aswec 2008), pp. 7685.
Moe, N. B., Šmite, D., Šablis, A., Börjesson, A.-L., and Andréasson, P. 2014. Networking in a Large-Scale
Distributed Agile Project,in 8th International Symposium on Empirical Software Engineering and
Measurement, p. 12.
Opt Land, M., and Proper, E. 2007. Impact of Principles on Enterprise Engineering.,in European
Conference on Information Systems, pp. 19651976.
Ovaska, P., Rossi, M., and Marttiin, P. 2003. Architecture as a Coordination Tool in Multi-Site Software
Development,Software Process: Improvement and Practice (8:4), pp. 233247.
Overby, E., Bharadwaj, A., and Sambamurthy, V. 2006. Enterprise Agility and the Enabling Role of
Information Technology,European Journal of Information Systems (15:2), Springer, pp. 120131.
Paasivaara, M., and Lassenius, C. 2014. Communities of Practice in a Large Distributed Agile Software
Development Organization Case Ericsson,Information and Software Technology (56:12), pp.
15561577.
Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chatterjee, S. 2007. A Design Science Research
Methodology for Information Systems Research,Journal of Management Information Systems.
Runeson, P., and Höst, M. 2008. Guidelines for Conducting and Reporting Case Study Research in
Software Engineering,Empirical Software Engineering (14:2), p. 131.
Sherehiy, B., Karwowski, W., and Layer, J. 2007. A Review of Enterprise Agility: Concepts, Frameworks,
and Attributes,International Journal of Industrial Ergonomics (37:5), Elsevier, pp. 445460.
Stelzer, D. 2010. Enterprise Architecture Principles: Literature Review and Research Directions,in
International Conference on Service-Oriented Computing.
Tashakkori, A., and Teddlie, C. 2010. Sage Handbook of Mixed Methods in Social & Behavioral Research,
Thousand Oaks: Sage Publications.
Uludağ, Ö., Kleehaus, M., Xu, X., and Matthes, F. 2017. Investigating the Role of Architects in Scaling Agile
Frameworks, in 21st International Conference on Enterprise Distributed Object Computing
Conference, pp. 123132.
Weill, P., and Ross, J. W. 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain,
Harvard Business Press.
Weill, P., and Woerner, S. L. 2015. Thriving in an Increasingly Digital Ecosystem, MIT Sloan
Management Review (56:4), p. 27.
Winter, R. 2016. Establishing Architectural Thinkingin Organizations, in The Practice of Enterprise
Modeling, J. Horkoff, M. A. Jeusfeld, and A. Persson (eds.), Cham: Springer International Publishing,
pp. 38.
... However, the empirical evidence that supports the above claims is scarce. 28,29 Hence, the primary goal of this research is to address this gap by While Alzoubi and Gill's work 24 investigated this influence through a survey, our study takes a distinct approach by conducting a comprehensive case study of a prominent GDAD organization with a prolonged history of practicing agile enterprise architecture. This approach yields valuable insights into practical experiences that have not been thoroughly explored previously. ...
... These findings complement prior research (e.g., Refs. [29,64]). ...
... This finding is consistent with Uludag et al. 29 finding, which recommends that the GDAD firms should enable the technical teams to participate in the development of agile enterprise architecture concepts to ensure project success and team commitment. Therefore, GDAD firms are urged to be more liberal when developing the agile enterprise architecture view by involving both technical and business members. ...
Article
Full-text available
Geographically distributed agile development may experience a high failure rate due to communication issues, which has a negative influence on project performance. One suggested solution in the literature is to enhance both communication and project performance by implementing agile enterprise architecture. However, the empirical evidence that supports this claim is still scarce. To address this gap, this study empirically explores the role of agile enterprise architecture as an artifact in distributed agile development. The findings of an in-depth qualitative case study from a dispersed agile development organization that involves teams distributed over three locations are used in this work. Over 2 months, data was gathered by interviewing 12 key members of the team and watching three Sprint sessions of agile software development. Text analysis qualitative approach was used to analyze the data. The findings imply that agile enterprise architecture has a positive effect on distributed agile software development communication, quality, and functionality. Agile enterprise architecture may also support on-time completion, but a trade-off with on-budget may be necessary. These findings provide valuable insights, frameworks, and best practices that support organizations in achieving greater agility, collaboration, and success in their distributed software development initiatives. As this is one of the first studies to look at the influence of agile enterprise architecture on distributed agile software development communication and performance, further research is needed to confirm and expand on the conclusions of this study.
... Most of the previous studies about AEA have investigated the possibility of implementing AEA in agile development (e.g., Canat et al., 2018; due to the conflicts between agile development business teams and technical teams (Hanschke et al., 2015). While the business team appreciates the value and role of AEA, technical teams assume that AEA contradicts the soul of agile development which is a team-and communicationoriented rather than a heavy documentation-oriented approach (Uludag et al., 2019a(Uludag et al., , 2019b. However, unlike traditional enterprise architecture that follows the top-down approach and focuses on long-term objectives, AEA principles and artifacts should follow the spirit of the agile development and be created based on the all-team sharing concept in order to achieve the commitment and expected value, especially from distributed technical teams (Gill et al., 2018;Hanschke et al., 2015). ...
... Enterprise architecture activities should not just focus on enforcement, but also on influencing people by educating, legitimizing, and socializing them (Gill, 2015). As a result, an influencecentric perspective of enterprise architecture is required to complement the enforcement-centric approach, which transfers decision-making power to agile teams and therefore mitigates agile teams' resistance to enterprise architecture governance initiatives (Uludag et al., 2019a(Uludag et al., , 2019b. Even though the number of firms employing agile techniques is growing, there is a scarcity of academic study on how to build architecture principles in an agile way. ...
... Even though the number of firms employing agile techniques is growing, there is a scarcity of academic study on how to build architecture principles in an agile way. Accordingly, empirical studies about the successful implementation of AEA in GDAD are scarce (Uludag et al., 2019a(Uludag et al., , 2019b. Therefore, the present study fills the gap and empirically investigates how a successful GDAD organization creates the AEA principles collaboratively between all stakeholders, implement AEA, and use it among GDAD teams. ...
Article
A potential solution to the high failure rate in distributed agile development and enhance the success of projects is through implementing agile enterprise architecture, though the success is still to be established. The present paper empirically investigates the gap, by defining the role and commitment of implementing agile enterprise architecture on distributed agile development. The data were collected by interviewing 12 key team members and observing four team meetings over 2 months and analyzing using thematic analysis. The present study suggests that implementing agile enterprise architecture is possible in distributed agile development and may have a positive impact on project success. However, many questions demand further investigation.
... A study recommends using architecture principles and guidelines to coordinate largescale agile development efforts and extending traditional enterprise architecture management (EAM) by taking an influence-centric approach to the establishment of architecture principles and guidelines. The EAM governance method can help large-scale agile development projects by bringing together all essential parties [22]. Figure 10 shows the challenges of agile adoption for uncertainty domain evaluated by expert review. ...
Article
Full-text available
The drawback of agile is struggled to function in large businesses like banks, insurance companies, and government agencies, which are frequently associated with cumbersome processes. Traditional software development techniques were cumbersome and pay more attention to standardization and industry, this leads to high costs and prolonged costs. The insurance company does not embrace change and agility may find themselves distracted and lose customers to agile competitors who are more relevant and customer-centric. Thus, to investigate the challenges and to recognize the prospect of agile adoption in insurance industry, a systematic literature review (SLR) in this study was organized and validated by expert review from professional with expertise in agile. The project performance domain from project management body of knowledge (PMBOK) was applied to align the challenges and the solution. Academicians and practitioners can acquire the perception and knowledge in having exceeded understanding about the challenge and solution of agile adoption from the results.
... A study recommends using architecture principles and guidelines to coordinate largescale agile development efforts and extending traditional enterprise architecture management (EAM) by taking an influence-centric approach to the establishment of architecture principles and guidelines. The EAM governance method can help large-scale agile development projects by bringing together all essential parties [22]. Figure 10 shows the challenges of agile adoption for uncertainty domain evaluated by expert review. ...
Article
Full-text available
The drawback of agile is struggled to function in large businesses like banks, insurance companies, and government agencies, which are frequently associated with cumbersome processes. Traditional software development techniques were cumbersome and pay more attention to standardization and industry, this leads to high costs and prolonged costs. The insurance company does not embrace change and agility may find themselves distracted and lose customers to agile competitors who are more relevant and customer-centric. Thus, to investigate the challenges and to recognize the prospect of agile adoption in insurance industry, a systematic literature review (SLR) in this study was organized and validated by expert review from professional with expertise in agile. The project performance domain from project management body of knowledge (PMBOK) was applied to align the challenges and the solution. Academicians and practitioners can acquire the perception and knowledge in having exceeded understanding about the challenge and solution of agile adoption from the results.
... Control through the definition of -goals by individuals -individual's voluntary improvement/learning activities Team-specific EA guidelines/ challenges [24] Clan control ...
Conference Paper
Full-text available
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.
... The group helps with all team-wide concerns from architectural design to quality assurance (QA) activities (Kalenda et al. 2018). Second is the practice of introducing an architecture committee, a group of people who meets regularly and makes relevant architectural decisions, much like a specialized community of practice (Uludağ, Nägele, et al. 2019;Uludağ, Proper, et al. 2019). The difference between the two practices is that undone departments are more flexible, while architecture committees hold regular meetings to discuss architectural topics. ...
Conference Paper
Full-text available
Agile methodologies have long been successfully applied to smaller software development projects with limited team sizes. In recent years, some firms have started to transfer agile methodologies to the whole organization. However, large-scale agile transformations are challenging and require a comprehensive view of cultural, operational, and strategic aspects. This paper systematically reviews available large-scale agile practices from the literature and provides a holistic overview of different large-scale agile practices. In total, four practice categories, 11 practices, and 19 example concepts were found. The categories are organized in a framework and serve as a possible entry point for researchers and managers to approach the topic of large-scale agile development more efficiently and economically.
... Case 1 is about one of the largest insurance companies in the world [20]. The company introduced agile methods on a larger scale in 2016, ran ten large-scale agile development programs with more than 5,000 employees, and decided to initiate the second wave of the [21] describes a case of leveraging advanced EA Management (EAM) tools to implement the EU's General Data Protection Regulation (GDPR). ...
Chapter
Alignment is one of the most important benefits that Enterprise Architecture (EA) could bring to organizations. However, it is still unclear what mechanism EA uses to help organizations achieve alignment. Related research is very scattered, making it difficult to accumulate relevant knowledge and experiences, and thus, the more successful EA application is hindered. To address this issue, the present research examines essential requirements of alignment and mechanisms with which underlying EA deliverable models impact organizations. By doing so, we proposed a conceptual framework explaining how EA modeling activities contribute to organizational alignment. We demonstrated the use of this framework with three use cases. The results show that EA could help organizations achieve alignment in quite different ways, and our proposed framework helped us examine and understand the mechanisms. We expect this research could establish an essential common understanding of how EA enables organizational alignment, thereby facilitating academia to move forward in this field.
Article
Full-text available
Context Success with agile methods in the small scale has led to an increasing adoption also in large development undertakings and organizations. Recent years have also seen an increasing amount of primary research on the topic, as well as a number of systematic literature reviews. However, there is no systematic overview of the whole research field. Objective This work identifies, classifies, and evaluates the state of the art of research in large-scale agile development. Methods We conducted a systematic mapping study and rigorously selected 136 studies. We designed a classification framework and extracted key information from the studies. We synthesized the obtained data and created an overview of the state of the art. Results This work contributes with (i) a description of large-scale agile endeavors reported in the industry, (ii) a systematic map of existing research in the field, (iii) an overview of influential studies, (iv) an overview of the central research themes, and (v) a research agenda for future research. Conclusion This study portrays the state of the art in large-scale agile development and offers researchers and practitioners a reflection of the past thirteen years of research and practice on the large-scale application of agile methods.
Article
Full-text available
Many organizations have embraced agile methods. Studies show a trend of large-scale application of agile frameworks company-wide. Emergent architecture design as part of an agile approach is effective at the project level but causes issues when services need to interact seamlessly at the enterprise level. Enterprise architecture (EA) can provide such coherence. Combining the scaling agile methods with EA is challenging. However, such a combination could benefit from the flexibility that agile approaches offer and provide the consistency and long-term focus that EA pursues. This article uses the longitudinal case study research to explore how organizations can effectively govern Agile and EA in large-scale agile transformations. Our case analysis shows that methods for scaling Agile do not provide sufficient guidance to properly handle the transformation from existing EA practices to an Agile EA combination company-wide. We propose how EA can be applied effectively in large-scale agile transformations despite the two seemingly conflicting approaches of Agile and EA. Based on our findings, we propose a conceptual model for future research that incorporates factors that take EA into account in the governance of agile-scaling frameworks. Our findings extend current literature on coordination mechanisms between architects and agile teams in large-scale agile transformations, thereby balancing emergent and intentional architectures.
Conference Paper
Full-text available
Over the past two decades, agile software development methods have been adopted by an increasing number of organizations to improve their software development processes. In contrast to traditional methods, agile methods place more emphasis on flexible processes than on detailed upfront plans and heavy documentations. Since agile methods have proved to be successful at the team level, large organizations are now aiming to scale agile methods to the enterprise level by adopting so-called scaling agile frameworks. Scaling agile methods at the enterprise level with some amount of architectural planning prevents excessive redesign efforts and functional redundancy in application architectures. An effective evolution of application architectures requires the right trade-off between emergent and intentional architectural design and a close collaboration between agile and architecture teams. Although there is a growing body of literature on scaling agile frameworks, literature documenting the deployment of architect roles in scaling agile frameworks is still scarce. This study describes the roles of architects in scaling agile frameworks with the help of a structured literature review. We aim to provide a primary analysis of 20 identified scaling agile frameworks. Subsequently, we thoroughly describe three popular scaling agile frameworks: Scaled Agile Framework, Large Scale Scrum, and Disciplined Agile 2.0. After specifying the main concepts of scaling agile frameworks, we characterize roles of enterprise, software, solution, and information architects, as identified in four scaling agile frameworks. Finally, we provide a discussion of generalizable findings on the role of architects in scaling agile frameworks.
Article
Full-text available
Agile methods have become an appealing alternative for companies striving to improve their performance, but the methods were originally designed for small and individual teams. This creates unique challenges when introducing agile at scale, when development teams must synchronize their activities, and there might be a need to interface with other organizational units. In this paper we present a systematic literature review on how agile methods and lean software development has been adopted at scale, focusing on reported challenges and success factors. We conducted a systematic literature review of industrial large-scale agile transformations. Our keyword search found 1875 papers. We included 52 publications describing 42 industrial cases presenting the process of taking large-scale agile development into use. 90% of the included papers were experience reports, indicating a lack of sound academic research on the topic. We identified 35 reported challenges grouped into nine categories, and 29 success factors, grouped into eleven categories. The most salient success factor categories were management support, choosing and customizing the agile model, training and coaching, and mindset and alignment.
Article
Full-text available
The paper motivates, presents, demonstrates in use, and evaluates a methodology for conducting design science (DS) research in information systems (IS). DS is of importance in a discipline oriented to the creation of successful artifacts. Several researchers have pioneered DS research in IS, yet over the past 15 years, little DS research has been done within the discipline. The lack of a methodology to serve as a commonly accepted framework for DS research and of a template for its presentation may have contributed to its slow adoption. The design science research methodology (DSRM) presented here incorporates principles, practices, and procedures required to carry out such research and meets three objectives: it is consistent with prior literature, it provides a nominal process model for doing DS research, and it provides a mental model for presenting and evaluating DS research in IS. The DS process includes six steps: problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication. We demonstrate and evaluate the methodology by presenting four case studies in terms of the DSRM, including cases that present the design of a database to support health assessment methods, a software reuse measure, an Internet video telephony application, and an IS planning method. The designed methodology effectively satisfies the three objectives and has the potential to help aid the acceptance of DS research in the IS discipline.
Conference Paper
Perspectives in organizations differ to which extent information sys-tems (IS) should be tailored towards local (e.g., business unit) needs or toward organization-wide, global goals (e.g., synergies, integration). For contributing to overall IS performance success, the harmonization of different perspectives be-comes essential. While many scholars have highlighted the role of IS manage-ment approaches, institutional studies argue that harmonization is not solely the result of managerial action, but a consequence of institutional pressures that guide organizational decision-making. In the paper at hand, we follow the call for adopting institutional theory on the intra-organizational level of analysis and study the logic of attaining harmonization along institutional pressures. By means of a revelatory case study, we find harmonization attained in a dynamic interplay between different institutional pressures. Mimetic pressures influence normative pressures, which in turn influence coercive pressures. Our findings as well as our implications for enterprise engineering guide prospective research in studying the attainment of harmonization through an institutional lens.
Conference Paper
During the last years, many companies established fast IT or digital IT units dedicated to build and operate digital customer-facing services. These units adopted agile methods, new tool chains as well as new organizational settings like BizDevOps teams. BizDevOps teams are responsible for continuously (re-)defining business functionality of certain (micro-)services, (re-)developing and running them. In these new fast IT environments, the role of enterprise architecture management changes dramatically. BizDevOps teams have a high degree of autonomy in designing both, the functionality and the architecture of their (micro-)services and thus contribute to business-IT-alignment in a new way. Nevertheless, a central enterprise architecture management (EAM) function is still required for supporting the teams regarding cross-team and cross-service issues. Furthermore, as many companies still run the traditional IT function side-by-side with the new IT function, the EAM functions of both parts have to cooperate. Based on a single case study, we discuss the emergence of a new EAM function (“fast IT EAM”), changing tasks and processes, implications for EA models and challenges for the integration of the traditional EAM and the fast IT EAM functions.
Conference Paper
After having harvested ‘low hanging fruits’ in early stages of Enterprise Architecture Management (EAM), it becomes increasingly difficult to keep up with large benefit realizations in later stages. The focus on the traditional EAM players (IT unit, architects, enterprise management) should be widened to ‘that other 90 % of the enterprise’ that are not directly related to the IT function. In order to create impact beyond IT, it appears necessary to complement the enforcement-centric view (i.e., enhancing EAM governance) by an influence-centric view (i.e., improving the EAM influence on local stakeholder decisions). Our research has shown that local stakeholders’ acceptance of restricted design freedom depends on certain preconditions: (1) Actors need to be convinced that their social status will be raising if they comply with EAM measures – and vice versa. (2) Actors need to understand that they can be more efficient if they comply with EAM measures – and vice versa. (3) Actors need to perceive EAM as something that is strategically important for the organization. (4) Actors need to perceive EAM deployment as transparent, useful, and professional. In this talk, we will elaborate on the necessity, justificatory foundations, and supporting artifacts to create supportive conditions for ‘Architectural Thinking’, the influence-based complement of governance-based EAM.
Article
Ever-changing business needs have prompted large companies to rethink their enterprise IT. Today, businesses must allow interaction with their customers, partners, and employees at more touch points and at a depth never thought previously. At the same time, rapid advances in information technologies, like business digitization, cloud computing, and Web 2.0, demand fundamental changes in the enterprises' management practices. These changes have a drastic effect not only on IT and business, but also on policies, processes, and people. Many companies therefore embark on enterprise-wide transformation initiatives. The role of Enterprise Architecture (EA) is to architect and supervise this transformational journey. Unfortunately, today's EA is often a ponderous and detached exercise, with most of the EA initiatives failing to create visible impact. The enterprises need an EA that is agile and responsive to business dynamics. Collaborative Enterprise Architecture provides the innovative solutions today's enterprises require, informed by real-world experiences and experts' insights. This book, in its first part, provides a systematic compendium of the current best practices in EA, analyzes current ways of doing EA, and identifies its constraints and shortcomings. In the second part, it leaves the beaten tracks of EA by introducing Lean, Agile, and Enterprise 2.0 concepts to the traditional EA methods. This blended approach to EA focuses on practical aspects, with recommendations derived from real-world experiences. A truly thought provoking and pragmatic guide to manage EA, Collaborative Enterprise Architecture effectively merges the long-term oriented top-down approach with pragmatic bottom-up thinking, and that way offers real solutions to businesses undergoing enterprise-wide change. Covers the latest emerging technologies affecting business practice, including digitization, cloud computing, agile software development, and Web 2.0 Focuses on the practical implementation of EAM rather than theory, with recommendations based on real-world case studies Addresses changing business demands and practices, including Enterprise 2.0, open source, global sourcing, and more Takes an innovative approach to EAM, merging standard top-down and pragmatic, bottom-up strategies, offering real solutions to businesses undergoing enterprise-wide changes.