Do you provide training or consulting around TOGAF, Agile, or Scrum? Then you’ve probably gotten questions like
is enterprise architecture still relevant when we do Agile? and
what is the role of an enterprise architect in an Agile organization?. Let me show you how you can blend various frameworks to increase your business and offer better services to your clients. Let’s go!
Can You Blend Agile and Enterprise Architecture?
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.
What Is Enterprise Architecture?
Let’s first summarize what enterprise architecture is about. The essence of enterprise architecture is that it provides insight into how various aspects of 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. TOGAF and ArchiMate are important standards with respect to enterprise architecture.
What Is Agile?
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.
Scrum the simplest structure possible to instantiate Agile.
Insight #1 – Enterprise Architecture is a necessary pre-condition
The first important insight is that enterprise architecture does not attempt to prescribe things that conflict with the autonomy of an Agile team. On 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. (Read an earlier blog post of mine on Architecting the Family: TOGAF & Major IT Frameworks.)
Insight #2 – Agile needs other mechanisms to scale
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 program 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.
Insight #3 – An overall architecture role remains relevant for Agile projects
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 the 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 who coordinates work on high-level architectural issues that cut across multiple systems. The chief architect also reviews the 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.
Insight #4 – Enterprise architects should also maximize The Work Not Done
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’).
Insight #5 – Agile & Scrum are (very successful) reference architectures
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 taking it seriously but at the same time not being afraid to adapt it if it does not fit your situation (that is what the people at Spotify have done with Scrum).
So in conclusion 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 multidisciplinary 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 holds especially true for solution architects) is now the responsibility of Agile teams.
So what is the impact of this from a training and consulting perspective? The first thing is that both enterprise architecture and Agile remain relevant and people and organizations will require training and consulting in both. There is a broad range of relevant training, including those on the important frameworks: TOGAF, ArchiMate, and Scrum. All architects should understand how Agile impacts their own work, and this certainly requires additional training.
About the author
An experienced consultant with strong analytical and communication skills, operating at strategic and tactical levels. Danny has experience in various roles ranging from IT consultant, data management consultant to enterprise architect. His focus is on information architecture, data quality and the link to the business and processes, but he is also knowledgeable on technology architecture and developments. Danny has twenty-five years of IT experience, especially in the financial services and public sectors. He regularly publishes on IT related topics in popular magazines and is also active in the architecture community. Danny is chairman of the governing board of “Via Nova Architectura”; an e-magazine on digital architecture. He is also chairman of the architecture section of the Dutch Computing Association (KNVI). He is the main author of the book “Architecture Principles – The Cornerstones of Enterprise Architecture” and co-author of the book “Ruimte voor mens en organisatie – visie en aanpak voor de digitale samenleving”.