Content uploaded by Ömer Uludag
Author content
All content in this area was uploaded by Ömer Uludag on May 02, 2019
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
Enterprise Architects
Agile Teams
acts as a role model and
supports lower belt teams
requests assistance from higher belt teams
provide feedback
on applied guidelines
guides and supports the
implementation of guidelines
collaborate to achieve
a higher belt
Security Experts IT Governance Experts
Data Protection
Experts
Data Security
Experts
Normative and Mimetic Pressures
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. 81–90.
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. 3–17.
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. 147–160.
Dingsøyr, T., and Moe, N. B. 2014. “Towards Principles of Large-Scale Agile Development,” in International
Conference on Agile Software Development, pp. 1–8.
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. 57–64.
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. 75–105.
Kettunen, P. 2007. “Extending Software Project Agility with New Product Development Enterprise Agility,”
Software Process: Improvement and Practice (12:6), Wiley Online Library, pp. 541–548.
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. 311–341.
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. 76–85.
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.
Op’t Land, M., and Proper, E. 2007. “Impact of Principles on Enterprise Engineering.,” in European
Conference on Information Systems, pp. 1965–1976.
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. 233–247.
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. 120–131.
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.
1556–1577.
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. 445–460.
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. 123–132.
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 Thinking’ in Organizations,” in The Practice of Enterprise
Modeling, J. Horkoff, M. A. Jeusfeld, and A. Persson (eds.), Cham: Springer International Publishing,
pp. 3–8.