#begin

Learning Unit (LU) 5 focuses on embedding EA in the project life cycle and EA-compliant project execution and business challenges that occur in the process of realizing a planned EA using a set of architecture-aware projects. I think this LU was one of the most interesting of the entire course. It dives into how to align EA, which is a long-term process, with agile methodologies. I remember thinking, EA sounds great but it seems to be aimed at more traditional methodologies, during the first lecture.

This time, we needed to read three articles instead of four so I guess this blog will be a bit shorter than the previous ones. Let’s discuss:

Integrating Agile Software Development and Enterprise Architecture Management

This article mainly explores how TOGAF can be integrated with agile software development, mainly Scrum. I think it’s pretty funny that the authors specifically target Scrum. I’ve written a couple of blogs about Scrum and I think Scrum has been taken hostage by management and is no longer a technical practice (most of the times). Many Scrum practitioners don’t know anything about the technical practices, just the “people” or business oriented practices. You can search on my blog if you are interested at what I think about scrum.

Nonetheless, this article was an interesting read. It aims at answering two research questions: “Whether and how agile methods such as Scrum can be used to create architecture deliverables and how enterprise architects can collaborate with agile software teams.”

The article starts with some short background information about EA, EAM and TOGAF. They note that the core of TOGAF is something called the Architecture Development Method (AMD). It’s a holistic step-by-step approach to develop and EA on different levels of detail. Next, they talk about agile and Scrum but I’m going to spare you the boring details since you probably already know what they are :).

Then they focus on the problem, namely: EAM is focused on long-term value and AMD is most likely used on the project level. Contrast that with agile, which is aimed at short-term value. The AMD needs some feedback from EAM when dealing with complex issues. But how do you do that since agile and EA differ that much?

Well, the authors suggest that integrating TOGAF and Scrum should enable the definition of long-term goals for development while keeping an eye on the business strategy and overall goals of the enterprise. At the same time it should also facilitate the EA to the changing requirements.

Agile teams need to respect the limitations set by EA, and now comes the greatest quote I read in all the papers of this course:

“Programmers should be seen as experts and not as assembly-line workers”

Each architectural decision and deliverable must be send back to the EA team and incorporated into the overall architecture, a complete and up-to-date picture of the EA is created incrementally.

Next, the authors show a couple of visuals to clarify what they are talking about and provide you with some hands-on information. I encourage you to read this yourself because it is far to much information to summarize. (Pages in the reader are almost fully highlighted)

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

This paper investigates how architecture principles can be created and applied in large-scale agile development. The authors pose that: “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.”

Agile teams cannot be controlled in a reasonable way by traditional EAM since EAM is a long-term initiative, and thus EAM needs to focus not only on enforcement, but also on influence through informing, legitimating and socializing.  This paper sets out to answer two research questions:

1) How can agile teams (ATS) and enterprise architects (EAs) collaboratively establish and manage architecture principles and guidelines in large-scale agile development?

2) How can the collaborative approach for establishing architecture principles and guidelines be supported by a software application?

To answer these questions the authors first establish a couple of architectural 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.”
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 principles statements”.
3. Specify and Classify: Define KPI as fulfillment criteria for guidelines and transform a principles into one or more specific guidelines if necessary.
4. Vote and accept: High-quality principles and guidelines require a solid validation process. The authors specifically state that the community should be responsible for the final decision on the adoption. Also, principles and guidelines driven by legal requirements should not be voted on!
5. Apply principles and guidelines: Agile teams must apply the principles and guidelines that are accepted by the architecture community.
6. Manage compliance: The approach presented in this paper aims to allow agile teams to follow architecture decisions, but also to neglect them if they document this nicely. Still, if it does not pass a vote in a later stage of development, they must revert to accepted measures.
7. Handle changes: Adjust principles and guidelines based on insights originating from specific situations.

Key findings after implementing this practice were that an agile EAM governance approach can support large-scale agile development endeavors to align all relevant stakeholders towards EAM governance efforts. The approach influenced ATs by emphasizing informative legitimizing, and socializing aspects. This bottom-up perspective raised the acceptance of ATs towards EAM governance efforts and increases the relevance and applicability of principles and guidelines. They also found that ATs do not necessarily insist on full autonomy as long as they have a say in decision making. EAs must facilitate and moderate inter-team architecture exchange and monitor the adherence of ATs to principles and guidelines, and avoid “ivory tower” issues by working together with them.

Dynamic Capability Building in the LEGO Group – Prospective Activities vs. Reflective Learning in Preparation for a Turbulent Digital Future

This third paper I used for the last individual assignment, there is a nice visual in here that I used for different stages throughout my video. Yes, we need to make a video; record a pitch about you (an EA consultant) trying to “sell” EA to a CIO when implementing some emergent technology. But back to the paper: It’s about how LEGO used EA to bolster their dynamic capabilities. The authors say that little is known about dynamic capabilities in academic literature. Some consensus exists in the research community that dynamic capabilities are nonimitable and cannot be bought from outside the organization, i.e. they have to be built internally. They are enterprise specific and require “intimate knowledge of both, the enterprise and the ecosystem in which the enterprise cooperates and competes”.

To me, dynamic capabilities are simply the flexibility of a company to adapt to changes in the market, competition, technology or other things that cause a shift in the ecosystem. Like the entire COVID situation. Companies with good dynamic capabilities have taken the opportunity to grow the business or maybe pivot a bit. Contrast that with companies that did not have good dynamic capabilities, they are struggling or maybe even went under. I know it’s probably far more complex than this, but it’s a simple example.

Next the paper describes the EA practices used in 2017 and 2018 at LEGO. I thought these pieces were very nicely presented. You can definitely notice that 2017 was about stabilization and 2018 was about how to properly implement agile in a large-scale organization.

In 2017 there were 8 overarching focus areas for EA: 1) strategic priority review, 2) Consulting to BP activities, 3) Strategic direction and implementation plan for cloud and data integration, 4) mapping of platform risk and technology driven business opportunities, 5) define roadmap and road mapping approach, 6) documentation of system landscape, 7) implementation of new ways of working with architecture in the LEGO group and 8) definition of platform principles to guide architectural work.

In 2018 they tried to become more agile as a whole. I can imagine this is a major task for an organization as large as LEGO. They talk about how they replaced the ERP system used in the majority of the organization. Damn, I bet that was a monstrosity not easily slain and its tentacles were deeply embedded in many parts of the enterprise. ERP systems bring a lot of value, but once you start to work against them, or break some general rules it becomes a mess very very quickly. They also went towards a platform architecture.

Based on all this the authors make three propositions:

1.  “The technical fitness of a dynamic capability increases through capability use, resultant experience accumulation, and reflective learning activities”.
2. “The technical fitness of a dynamic capability increases through prospective capability building activities that do not contribute to the immediate delivery of its value”.
3. “The strategic creation of a dynamic capability comprises an inherent tension between prospective capability building activities of value through capability use”.

To find out what these mean exactly I encourage you to read the paper. 🙂

Conclusion

Thus LU presented some interesting literature. I think article one and three were the  most interesting. I found it pretty nice to read about EA and agile. Especially the last paper went into detail how EA and EAM can be applied in a large organization to move towards an agile workflow. As I said, it really was the first question I came up with in the first virtual lecture we had.

Let’s move on to LU6!

#end

01010010 01110101 01100010 01100101 01101110.

References:

Article 1: https://www.researchgate.net/publication/283774861_Integrating_Agile_Software_Development_and_Enterprise_Architecture_Management

Article 2: https://www.researchgate.net/publication/332800885_Establishing_Architecture_Guidelines_in_Large-Scale_Agile_Development_Through_Institutional_Pressures

Article 3:  https://aisel.aisnet.org/ecis2019_rp/136/