In our previous blog post, we outlined why Enterprise Architecture and Agile/DevOps are key in becoming an adaptive enterprise. We also described several use cases where EA can strengthen Agile and DevOps practices. Now, we want to focus on the ways in which you can connect these in practice, using architecture models and appropriate tool support.
For prioritization that is grounded in business value, you can specify strategic themes in your architectural model as a starting point. The goal contribution view in the figure below shows two strategic themes of an insurance firm that have been modeled as goals in ArchiMate (the top part of the figure). Different outcomes (at the bottom of the figure) contribute to these two strategic goals. Outcomes represent produced results and can, in turn, be linked to epics and enablers, which are pivotal elements for agile development.
In this insurance company’s model, two outcomes have a strong positive influence on the goal of improved customer service. They are an online claims form and a mobile application for communication with virtual insurance agents. The latter also contributes to the goal of reducing labor costs. A new algorithm for automation of claims handling contributes to the same goal. A preliminary prioritization of outcomes can be derived from this model. For the insurance company, the virtual agent will produce the highest business value and should be given priority over the other outcomes.
Goal contribution view
To achieve top-down, enterprise-wide prioritization, you have to coordinate to reflect additional factors, such as architectural dependencies within and across outcomes, or the assignment of epics across agile teams that are responsible for individual architectural elements. This is where enterprise architecture excels, as the architectural information at hand is crucial to this big-picture planning.
For this purpose, it is helpful to subdivide outcomes in an architecture-aware fashion. There is no need for a detailed specification of all requirements; the objective is to achieve just enough granularity to outline the organizational and architectural footprint of each outcome. This insight into the architectural footprint of the outcome is the key to identifying conflicts and bottlenecks. This type of information is usually not available in your typical agile management and tracking tools like Jira.
In the insurance example, the virtual mobile agent outcome can be split into two requirements that have a different architectural footprint. The mobile application component is affected, as is as the mobile back-end component, and they are covered by different agile teams (Figure 2). According to the sprint planning of the responsible agile team, the requirements are realized during different sprints. Based on the roadmap of the Agile Release Train (ART), both requirements will be part of the same release. The model illustrates how business value is created over time and how development resources get allocated.
Relationships between goals, outcomes, architecture elements and agile sprints and releases
In BiZZdesign’s Team Platform, you can easily aggregate data from different sources (as also explained in the recent blog post on continuous architecture by our colleagues Bart Molenkamp and Nick Reed), including agile tools such as Jira. This information can be aggregated at various levels and shared on the HoriZZon portal, which is shown in the figure below. On the left, you see outcomes from the first figure in a Kanban view. On the right, you see the attributes for the ‘virtual agent’ outcome as imported from the corresponding epic in the Jira backlog. Drilling down from these epics into the architecture itself will get you to views similar to the ones above.
HoriZZon portal showing data from agile tooling integrated with architecture information
You can also create this linkage at the more detailed level of features, depending on the granularity of the information you want to use in your architecture models. Generally, we would not advise to link this to the level of individual user stories in Jira, as that can become rather messy. This level of detail is often not that architecturally relevant.
Next to such a Kanban view, you can create various color views, roadmaps, and dashboards to inform stakeholders on the progress of changes and the performance of agile teams and release trains. Decisions and transition planning can be based on the available information on progress, prospective availability of new features, and associated business outcomes. You can calculate the effects of delays up-front and evaluate different scenarios when epics or features need to be re-prioritized. In this way, change becomes more predictable and less risky as you focus on the true needs of your business.