practices in agile architecture governance: multiple case

Chair of Software Engineering for Business Information Systems (sebis)

Faculty of Informatics

Technische Universität München

wwwmatthes.in.tum.de

Practices in Agile Architecture Governance: Multiple Case

Studies in Large OrganizationsNiklas Reiter, Master‘s Thesis – Final Presentation, 7th of December 2018

Outline

© sebisNiklas Reiter - Master's Thesis: Final Presentation 2

Motivation

Research Methodology

Case study

Key Findings and Recommendations of Action

Summary & Outlook

Niklas Reiter - Master's Thesis: Final Presentation © sebis 3

Agile Architecture Governance

Agile methods were originally designed

for working at team level

Do not provide sufficient guidance on program and

portfolio level, especially in terms of governance

Find balance between agile development and

architectural governance

To coordinate work and to develop reliable and scalable

systems companies need to have a suitable governance

and the right architectural planning

Source: image: https://www.agil8.com/consulting/safe-scaled-agile-framework/; Nord et al.: “Agile in

Distress: Architecture to the Rescue” ; Hanschke et al. Integrating; Integrating agile software development

and enterprise architecture management; Roth et al. Enterprise architecture visualization tool survey

Agile Methods and EAM are in Conflict

© sebis 4

Bottom-up

Short-term orientation: Small units and time-

limited implementation

Focus on principles and idealized goals

Local and project-specific optimum

Agile Methods

Top-down

Long-term planning and value orientation

Danger of fixation on formalities

Global and company-wide optimum

EAM

Source: Hauder, Roth, Schulz, & Matthes, 2014; Hanschke, Ernsting, & Kuchen, 2015, S. 4101;

Bente, Bombosch, & Langade, 2012, S. 159, 162 f.; Hanschke et al., 2015, S. 4101

;

Niklas Reiter - Master's Thesis: Final Presentation

Outline


Motivation


Case study


Summary & Outlook

Research Questions

© sebis 6Niklas Reiter - Master's Thesis: Final Presentation

• Which tasks, responsibilities, problems, and solutions does the EA team

have in an agile environment and what is needed for an agile EAM to be

successful?

• What kind of architectural decisions are made in an agile environment

and how are they categorized, documented and communicated through

the entire organization?

RQ1 Case Study

RQ2

RQ3

RQ4

• How effective is the enterprise architecture team and what are the expectations

of ATs regarding collaboration and artifacts / models provided by the EAs and

what approaches exist to measure the value contribution of EAM?

• What is the motivation behind the definition of architectural principles, which

architecture principles are suitable for an agile environment and who is responsible

for their definition and compliance?

Case Study

Case Study

Case Study

Research Methodology – Embedded Multiple Case Study


Source: Yin (2008); Runeson and Höst (2009); Cruzes, D. S., & Dyba, T. (2011)

*P= Principles; B=Boards; R= Role EAM; V= Value

Contribution EAM

3. DATA COLLECTION

Deliverable: Data collected in 64 semi-structured individual and group interviews, two workshops, and documents

4. DATA ANALYSIS

Deliverable: Findings on the collaboration between EAs and ATs and the usage of architecture principles and circles

1. CASE STUDY DESIGN

Deliverable: Embedded multiple-case study of agile architecture governance

2. CASE STUDY PREPARATION

Deliverable: Interview guides for architecture principles and communities, role and value contribution of EAM

Outline


Motivation


Case study


Summary & Outlook


Case Study Partners


Stakeholder

Group

Number of

Persons

Number of

InterviewsTopics

Duration

(hh:mm:ss)

C1*

Agile Team 3 8Principles, Boards, Role of EA,

Role of EAM01:57:36

Enterprise

Architect4 8

Principles, Boards, Role of EA,

Role of EAM03:14:56

Manager 1 4Principles, Boards, Role of EA,

Role of EAM01:51:00

C2


Role of EAM00:46:20

Enterprise

Architect3 4


Role of EAM04:07:04

Manager 0 0 - -

C3


Role of EAM3:21:40

Enterprise

Architect2 8


Role of EAM3:51:57


Role of EAM1:36:36

C4


Role of EAM2:00:04

Enterprise

Architect2 8


Role of EAM5:13:17


Role of EAM2:17:45

Case Study

*C1= Company 1

64

Interviews

412

Pages

31

Hours

21

Interviewees

Research Methodology – Embedded Multiple Case Study


Source: Yin (2008); Runeson and Höst (2009); Cruzes, D. S., & Dyba, T. (2011)

Outline


Motivation


Case study


Summary & Outlook

© sebis 13

2

3

45

6

7

▪ Added value of EAM not yet arrived in agile teams

7

2

▪ Lack of capacity restricts EA's time availability

▪ Feedback cycles are missing

▪ No regular feedback appointments

▪ Top-down instead of bottom-up

6▪ Lack of technical know-how of EAs

→Lack of technical support

5▪ Partly missing or very late integration

4

3

▪ EAs prefer communication via solution architects

and CoPs

▪ Quality of architectural models is insufficient1

1

1

2

3

4

5

6

7

8

9

10

Meeting expectations of agileteams on architectural

models

Availability of EAs forsupporting agile teams

Communication between EAsand agile teams

Involvement of agile teams inarchitectural processes

Satisfaction with supportingagile teams

Opportunity togive feedback to EA

Would recommend EAs toother agile teams

Enterprise Architect Agile Team Manager

Gaps between self-perception and external perception of enterprise

architects

Niklas Reiter - Master's Thesis: Final Presentation

NPS Recommendation Rate EA

1 2 3 4 5 6 7 8 9

PromotersDetractors Passives

0

90,91%

NPSEAs

100%

NPSManagers

-28,57%

NPSAgile Teams

Net Promoter ScoreTotal

Net Promoter Score % Promoters % Detractors 52,38%

00 01 20 22 950

Niklas Reiter - Master's Thesis: Final Presentation © sebis 14

10

Key Findings


1. The majority of architecture principles are defined on the IT portfolio level.

2. There is no explicit control mechanism for the verification of compliance with architecture principles.

3. Creation and definition of solution space is an important architectural decision in an agile environment.

4. EAs' responsibility has shifted from directing and controlling towards supporting and enabling of ATs in an agile

environment. This is why, the required characteristics, capabilities and working methodology of EAs have changed.

5. New requirements for the role of EA cause several issues in the execution of tasks and responsibilities.

6. There is no formal mechanism for ATs to provide feedback to EAs.

7. Value contribution of EA and the gap between self-perception and external perception differs significantly across all

stakeholder groups.

Recommendations of Action (1/2)


1. Architecture principles should be defined on IT portfolio level to establish common cross-team architectural

standards.

2. In order to ensure that ATs adhere to architecture standards, explicit control mechanisms must be established. This

problem can be solved with the help of automated and standardized code reviews inside of a delivery pipeline.

3. The definition of a solution space in advance ensures compliance with the architecture of relevant standards,

guidelines and objectives and helps not to restrict the freedom of the ATs and thus the agility.

4. Due to the shift from direct and control to support and enable:

1. EA needs to have deep technical know-how in order to be able to code for short demonstration, be

methodically trained and must have social skills such as sensitivity and personal skills to be able to work with

and motivate different stakeholders.

2. Role of supporting architect needs to be established to increase the intrinsic motivation of ATs to adhere to

architecture principles.

Recommendations of Action (2/2)


5. Indirect communication leads to loss of information. Direct communication between AT and EA should be mainly used.

Therefore, companies need to have enough capacity and provide appropriate coordination arenas.

6. Formal feedback mechanisms should be established. For example, SoS (with representatives from the teams) as

reactive feedback mechanisms and optional one-on-one meetings to support more direct communication between

ATs and EAs and thus improve collaboration. Furthermore, CoPAs should be implemented.

7. Value contribution of EAM

1. A reflection and stronger communication to establish awareness of the value contribution of EAs and close the

gap between self-perception and external perception. PDCA described in the to-be EAM model, this problem can

be solved.

2. Value contribution of the EAM should be measured by combining specific KPIs, such as budget, correctness,

customer satisfaction, feedback from ATs and products, number of adjustments, speed of decision making and time.

PROGRAM LEVEL TEAM LEVEL

ENTERPRISE LEVEL PORTFOLIO LEVEL

• Defining business & IT strategy

• Defining vision and core values

• Analyzing competitive environment

• Identifying business drivers

• Align enterprise strategy with portfolio

• Build product portfolio of IT organization

• Defining solution space and standards

• Coordinate continuous compliance

• Assign decisions to the respective areas of competences

• Discussing solution space and standards

• Establishing community governance

• Specifying high-level and technical architecture principles

• Verifying compliance with delivery pipeline

• Managing technical debts

• Specifying technical architecture principles

• Assisting with applying architecture principles

• Providing situational based architecture support

• Applying scheduled Scrum of Scrums as a feedback

mechanism

buildcommunicate

explain

involve

adapt

assign

prioritize

collect

support

motivate

get feedbackreflect

Enterprisemaps

Architectural standards

Feedback

Product portfolio strategy

Product portfolio

Feedback

Enterprise maps

Solutionmaps


Enterprise architecture

strategy

Executive

BoardCenter of

Excellence

Community

of PracticeScrum of

Scrums

Roles

Enterprise

Executives

Dev TeamCXO

Solution

Architect

Developer

EA Team

Enterprise

Architect

Business

Owners

Enterprisemaps

Feedback

Business & organization constraints

Business and IT

strategy

Referencearchitecture

Technologystack

Architecturespikes

Solutionmap


FeedbackSolution

target architecture

Product vision and

description

Tools


Motivation


Case study


Summary & Outlook

Outline


Summary & Outlook


Summary

1. Collaboration between enterprise architects and

agile teams needs to be closer

2. Role of the enterprise architects is changing

significantly: From direct and control to support and

enablement of agile teams which requires new

skills like technical know how and social skills

3. Lack of capacity of enterprise architects hampers

the support of ATs and is one of the reasons why

currently established control mechanisms for the

verification of architecture principles are either

based on trust, performed either sporadically or do

not exist.

4. Bad communication and the lack of technical know-

how and feedback mechanisms of enterprise

architects leads to superficial artifacts provided to

the ATs, which causes the latter's satisfaction rate

to drop

Outlook

1. Long-term studies on the collaboration between

EAs and ATs

2. Study how our case organizations will solve

contemporary challenges in the future

3. Explore what value EAs can deliver to ATs and

how the value contribution can be measured

4. Conduct quantitative studies which aim, among

others things, to identify recurring challenges and

best practices of EAs and ATs.

5. Study the collaboration between EAs and ATs

from a sociological point of view, e.g. by applying

multi-team systems theory from sociology.

References (1/2)


Abrahamsson, P., Babar, M. A., & Kruchten, P. (2010). Agility and architecture: Can they coexist?. IEEE Software, 27(2).

Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture: enriching EA with lean, agile, and enterprise 2.0

practices. Newnes.

Buckl, S., Matthes, F., Monahov, I., Roth, S., Schulz, C., & Schweda, C. M. (2011, August). Towards an agile design of the enterprise

architecture management function. In Enterprise Distributed Object Computing Conference Workshops (EDOCW), 2011 15th IEEE

International (pp. 322-329). IEEE.

Cruzes, D. S., & Dyba, T. (2011, September). Recommended steps for thematic synthesis in software engineering. In 2011 International

Symposium on Empirical Software Engineering and Measurement (pp. 275-284). IEEE

Greefhorst, D. and Proper, E. (2011): Architecture Principles: The Cornerstones of Enterprise Architecture. Springer-Verlag Berlin

Heidelberg.

Hanschke, S., Ernsting, J., & Kuchen, H. (2015, January). Integrating agile software development and enterprise architecture

management. In System Sciences (HICSS), 2015 48th Hawaii International Conference on (pp. 4099-4108). IEEE.

Hauder, M., Roth, S., Schulz, C., & Matthes, F. (2014). Agile enterprise architecture management: an analysis on the application of agile

principles. In International Symposium on Business Modeling and Software Design BMSD.

References (2/2)


Niemann, K. D. (2010). Enterprise architecture management and its role in IT governance and IT investment planning. In Information

Resources Management: Concepts, Methodologies, Tools and Applications (pp. 996-1026). IGI Global.

Nord, R. L., Ozkaya, I., & Kruchten, P. (2014, May). Agile in distress: architecture to the rescue. In International Conference on Agile

Software Development (pp. 43-57). Springer, Cham.

Rhubart, B. (2010). Agile Enterprise Architecture. Oracle Magazine, 24(6), 32.

Roth, S., Matthes, F. and Zec, M.. Enterprise architecture visualization tool survey 2014. Technical Report, Technische Universität

Munich, 2014

Runeson and Höst (2009): Guidelines for conducting and reporting case study research in software engineering;

Weill, P., & Ross, J. W. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, 2004. Harvard Business

School.

Winter, R.. Architectural thinking. Wirtschaftsinformatik, 56(6):395–398, 2014.

Yin (2008): Case Study Research: Design and Methods (Applied Social Research Methods);


Thank you for your attention!

practices in agile architecture governance: multiple case

Documents