Enterprise architecture and Agile; do they blend?

Agile is a new way of working that has been adopted by a lot of organizations. It seems to provide an answer to a lot of issues that software development has been facing for decades. The role of architecture in the context of Agile has been a subject of debate for a number of years, where Agile proponents position architecture as a “Big Design Up Front” that contradicts with the Agile philosophy. Meanwhile, enterprise architecture has developed itself as an important instrument for translating strategy into operations. Are these two approaches inherently conflicting or can you blend them? That is what this blog provides more insight to.

Let’s first summarize what enterprise architecture is about. The essence of enterprise architecture is that it provides insight into how various aspects in the enterprise are related. It translates strategy into principles, concepts and models that provide a vision and guidance for design and development. Enterprise architecture is different from solution architecture; it only provides overview and direction and considers the systems to be developed as a black box. Solution architecture opens this black box, describing the structure and decisions in the box.

Agile is a philosophy on software development that is founded in the Agile Manifesto. The manifesto states that the focus should be on individuals and interactions, working software, customer collaboration and responding to change. The manifesto is detailed in the form of a set of principles that provide more concrete guidance. One of the principles is “Simplicity --the art of maximizing the amount of work not done -- is essential.”. Scrum is the most popular Agile method and is described by Ken Schwaber as “the simplest structure possible to instantiate Agile”. DevOps applies the Agile principles to IT Operations.

The first important insight is that enterprise architecture does not attempt to prescribe things that conflicts with the autonomy of an Agile team. To the contrary; it is an instrument for determining which Agile projects are valuable. It describes a vision that should be realized, and identifies the applications and projects that are needed to support this vision. Applications are only described as a black box in the enterprise architecture; an Agile project can open this black box. High-level business requirements identified in the enterprise architecture can be refined into epics and user stories by the Agile project. Note that solution architecture does overlap with this, and should therefore somehow be embedded in the Agile project.

Another important insight is that the focus of Agile is on teams, and not on the enterprise as a whole. Dean Leffingwell states that it is designed for small teams, and that it does not scale to the enterprise level. This has led him to describe the Scaled Agile Framework, which is basically a programme and portfolio level on top of Agile teams. Although there has been a lot of debate on this framework, it is interesting to see that the enterprise architect is also positioned within this framework. The responsibilities of the enterprise architect include maintaining the vision, aligning business drivers with technical decisions and facilitating reuse of emergent solutions, knowledge and patterns.

Others have also seen that an overall architecture role remains important. Spotify is a well-known case for Agile that has also scaled it to an enterprise level. They have grown their own terminology, techniques and organizational structures. They see autonomy of the teams as an important pillar, but also acknowledge that other means are necessary for things such as competence building, synchronizing teams and sharing knowledge. They also position a chief architect that coordinates work on high-level architectural issues that cut across multiple systems and reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with the architecture vision. An important note that they make is that the feedback provided by the architect is always just suggestions and input - the decision lies with the team.

There are a lot of misconceptions about enterprise architects (or real world experiences with the wrong enterprise architects). A general misconception (or pitfall) is that enterprise architects spend a lot of time thinking in solitude about things that are not very important. The opposite should hold; enterprise architects should work together with others on “the stuff that matters”. This is very similar to what Agile teams do; working together with the business and maximizing the amount of work not done. Multi-disciplinary teams, focusing on collaboration, co-creation and communication are common best-practices that should be applied everywhere in the organization. Soft skills are becoming more important for everyone. Enterprise architecture should thus be performed in line with the Agile manifesto. Most of the principles in the Agile manifesto apply (if you remove the term “working software”).

The final perspective that I want to provide is that Agile and Scrum can really be seen as enterprise architectures. They are described in the form of principles and concepts/models; core elements of architecture descriptions. Given that they describe processes, roles and products they can be positioned as business architectures (for the business of software development). What does this insight lead to? Well, it could convince Agile proponents that enterprise architecture actually works. It also shows how you should handle an enterprise architecture in an Agile project; the same way in which you handle the Agile principles and Scrum concepts. This basically comes down to; take it seriously, but also do not be afraid to adapt it if it does not fit your situation (that is what the people at Spotify have done with Scrum).

So concluding all this: enterprise architecture and Agile blend perfectly. Enterprise architecture provides an Agile project with a vision in the form of principles and models. Agile provides Enterprise Architecture with a good set of principles, showing that a multi-disciplinary way of working is key. Also, we can learn from the success of Agile and Scrum. If you look at them as architectures, they can even help improve the enterprise architecture profession. Organizations do need to ask themselves whether all architects they currently have will remain relevant. Some of what architects currently do (this especially holds for solution architects) is now the responsibility of Agile teams. 

More information can be found in a presentation I uploaded to slideshare.

Danny Greefhorst (dgreefhorst@archixl.nl) is principal consultant and director at ArchiXL.