Enterprise Architecture and Agile/DevOps: Adaptive Enterprise Cornerstones

Jul 13, 2018
Written by
Marc Lankhorst
Marc Lankhorst

Enterprise Architecture and Agile/DevOps: Adaptive Enterprise Cornerstones

Marc Lankhorst, Fabian Aulkemeier 

Enterprise architecture, agile software development, and DevOps are sometimes seen as being at odds. We think they can fruitfully collaborate and interface, but how do you do that? How can you align the concepts and processes from these worlds and bridge the cultural gap? 

In previous blog posts, we and our colleagues have written about the need to approach business transformation in a lean and agile way, the way enterprise architecture and agile development processes can work together, and how you can map agile concepts to the ArchiMate modeling language to support this cooperation.  

In this blog, we want to discuss several use cases that highlight the collaboration between enterprise architecture, agile development, and DevOps. I will also discuss how BiZZdesign’s software can work together with agile and DevOps tools to streamline the flow of value in the change processes of your organization, helping you become an adaptive enterprise. 

Why relate EA and agile/DevOps?

Agile approaches are a great help in improving responsiveness to change. However, they are not the only approach you’ll need and, when applied incorrectly, they can even harm the overall adaptivity of your enterprise. 

In general, the larger an organization and the more interconnections and dependencies there are between its parts (capabilities, resources, processes, systems), the more important enterprise architecture becomes in improving adaptivity and aligning parts with overall strategic direction.  

In smaller organizations, a few agile/DevOps teams can coordinate change amongst themselves, and the lines to management are short enough that strategic direction can be conveyed to teams directly. In large organizations, however, there may be hundreds of agile teams, each working on a part of the big ‘enterprise machine,’ and more coordination is needed. If you have agile teams building agile silos that disregard their environment, you will still not have an adaptive and flexible end result. In addition, future change may become even more difficult, which is why good architecture is essential. 

Approaches such as LeSS and the Scaled Agile Framework (SAFe) have been created to deal with coordinating teams in these circumstances. The figure below shows a simplified version of SAFe, highlighting some of the significant terms and feedback loops. 

Simplified version of SAFe
Simplified version of SAFe


 Their approach to architecture is focused on the needs of software development and, as a result, looks at the enterprise mainly from a software and solutions angle. There is more to an enterprise than software, though. This is where the ‘big picture’ view offered by EA adds value, as it also encompasses other stakeholders than software users and includes desired (and unwanted!) business outcomes, capabilities to be developed or improved, resources required, business processes, IT and physical infrastructure to be realized, and more.  

Use cases for EA & agile

The combination of enterprise architecture and agile development is invaluable in many cases. For example, this collaboration is crucial when: 

  • Prioritizing business value. Based on an analysis of your enterprise architecture, you can see how different epics and features are related to business processes, capabilities, business goals, and associated stakeholders. Tracing through your architecture models, you can find out which business goals and which stakeholder a feature is contributed to, and whether is that is more important than other features. Objective information like this may help a product owner put a stop to ‘decibel-driven’ prioritization, where the users with the loudest voices get their wishes granted. 
  • Planning work in coherence. The dependencies from your architecture can be used in planning agile activities: If Feature A depends on Feature B, build B first. This is all the more important in what SAFe calls ‘enablers’: aspects of the solution that do not provide functionality directly to users, but support this functionality indirectly and enable long-term quality and evolution. Its ‘Architectural Runway’ concept is an example of this, where you lay down the technical foundation for new features just in time. This concept can be extended beyond software, though. Investing in staff skills, for example, may provide a foundation for many future developments and improvements. 
  • Tracking progress. If some feature or enabler is delayed, for example by an agile team wanting to push it to the next sprint, the impact on the overall solution needs to be factored into that decision. There may be good reasons for this team to prioritize something else, but often they do not have enough information to understand the consequences. Being able to trace back to the overall goal will demonstrate how a decision will affect a release, project completion date, etc. It also helps teams ask questions like, “How does this impact the organization’s business goals? Which customer groups will be affected? Can we mitigate these effects by prioritizing other features, possibly of other teams?” That is where architecture models are a great help, especially for enablers. Since enablers do not provide end-user functionality, few people will complain when you postpone them. However, they are often important for many different features and for the solution’s long-term viability, so keeping track of these dependencies is key. 
  • Updating the architecture with new insights. In an agile context, an enterprise architecture is not some static description of a long-term future state. Rather, it is a shared instrument to provide vision, give direction, and ensure coherence across the enterprise, based on both top-down and bottom-up inputs. Business strategy, goals, and desired outcomes provide the top-down direction, whereas local innovation and improvement offer bottom-up change. Thus, various groups in the enterprise work together on the architecture from their own perspectives.   

Use cases for EA & DevOps

When we extend agile development with DevOps, there are other use cases for architecture that can be added to the above list. Operations management, in general, is not always aware of the benefits of architecture. But in the rapid change cycle of agile/DevOps, and with a ‘fail forward’ approach to resolving issues, architecture for DevOps becomes even more valuable. For example, architecture models can be used for: 

  • Event correlation. Architecture models allow you to see events across your enterprise in an integrated way. For example, if hackers are trying to compromise your security with different attack vectors at the same time (e.g. social engineering, phishing, viruses, and physical intrusion), architecture models may help you correlate these to understand what their actual goal may be.   
  • Root cause analysis. Often, a whole chain of systems has to be traced to find the cause of a fault or problem. Architecture models are a great help in this, since they provide operations management with the various interconnections and dependencies that may need to be investigated.  
  • Risk analysis. Before implementing a change, you will want to know which parts of your enterprise may be affected.Low-risk changes can be implemented rapidly, but high-risk changes will require more thorough analysis and mitigating measures.  

In the next installment in this series, we will look at the use of models and tool support for integrating agile development and architecture in Enterprise Studio and HoriZZon. Stay tuned!