Six Agile Enterprise Architecture Use Cases

Six Agile EA use-cases identify how to design an EA Team for different conditions. Agile methods for EA, EA supporting agile development and an agile enterprise.

These are a subset of the standard Enterprise Architecture Use Cases. The standard use cases address everything from strategic change to risk mitigation and acquisitions to agile development.

We look for simple framing models to clarify our thinking. Framing models is to help us to explicitly isolate conditions where we need to make configuration choices.

Six Use Cases for Agile EA Agility, Enterprise Architecture and agile software development fit together.

  1. Enterprise Agility
  2. Agile software development & enterprise architecture
  3. Enterprise Architecture using agile methods

Isolating conditions allows you to design your EA Team with confidence. Our EA Capability services use the Navigate EA Capability Reference Architecture. High functioning EA team's are optimally configured.

Agile and Enterprise Architecture fit together wonderfully. Both solve different parts of the problem.

Agile software development excels at building something that we have never had before and do not know how. Enterprise architecture excels before decisions when you do not know what to do.

Put Agile software development & enterprise architecture together to optimize change.

Most architects jump to how enterprise and agile development relate. We've seen many people try to fit two wildly divergent worlds together, usually without stopping to understand either.

We optimize enterprise architecture and agile development by aligning them to their strengths. The shorthand we use is that enterprise architecture excels before decisions when you do not understand what to do. Agile software development excels at building something that we have never had before.

Both methods suffer from chronic misapplication. Despite TOGAF’s inherent concept of iteration, too many architects latch onto the ADM crop circle diagram and see process. It’s so easy to see a waterfall in the ADM diagram. Wrong, but easy. As well, the disorganized leap on the journey of discovery in agile development to hide their disorganization.

The actual world is messy. Unless we are talking about a simple one-trick-pony greenfield, software products must fit into a complex ecosystem. Existing processes, organization, partners, and infrastructure enable the business to serve customers. The new Product must enhance the ecosystem while fitting in.

It’s in  real world complexity that effective agile development and enterprise architecture shine. Play to their strengths. We base strong agile software development practice on resolving an essential tension.

Agile Tension
You know where you’re going. You don’t know how to get there

Enterprise Architect's Guide

Download the Enterprise Architect's Guide a TOGAF Series Guide on developing useful enterprise architecture.

Agile EA Use Case Examples

Use Case 1: Architecting an Agile Enterprise

In this use case the EA purpose is constrained to require acceptable Target architectures to prioritize agility.

Frankly it has nothing to do with any agile methods. Many agile organizations we have worked with don't use agile change methods.

We draw heavily from Supply Chain & Disaster Response as high agility touch-stones. We use 5 attributes for agility (drawn from sports & military research):

  • Alertness
  • Accessibility
  • Decisiveness
  • Swiftness
  • Flexibility

This use case exercises Conexiam's Navigate Agile Enterprise Atlas. It optimizes architecture development for agility through a specialized viewpoint library, stakeholder engagement and concerns.

Bluntly, this use case is dangerous if it does not align with the true preferences of an organization’s powerful stakeholder’s.

In terms of TOGAF, this use case is most focused on the TOGAF ADM Phase G & Phase H value realization activity, where change must be aligned to creation and sustaining an agile enterprise.

Use Case 2: Use EA to Define Agile Approach for Change

Agile and Enterprise Architecture Work Product In this use case the Enterprise Architecture is used to structure how the Enterprise performs change. Products, Sprint team structure, velocity, alignment with all change approaches are performed.

The questions be addressed are what change, what development should follow which approach. In the case of agile methods, questions such as the Product, Sprint team structure, velocity are all answered.

This Use Case is largely exercising the TOGAF ADM Phase F, G & H based upon a Strategic or Portfolio architecture.

Use Case 3: Use EA to Guide Backlog & Sprint Planning

From the perspective of Enterprise Architecture & TOGAF, all implementation, prototyping, pilot, project and agile sprints happen with Phase G. Best-practice EA will produce an enterprise architecture replete with a solution delivery notebook, gap, control, architecture specification and work package. This material needs to be described in terms fit for the backlog: Epic, User Story and Architecture Runway.

The Enterprise architecture will contain a set of gaps, work packages to fill these gaps and limitations on the creativity of implementations teams' freedom to perform the change. It will include traceability to drivers, goals, and priorities outside the purview of the product manager and customer.

In classic agile, the customer-driven Epics and Users stories fill the back-log. The customer provides prioritization criteria. The self-organizing agile team prioritizes work.

This use case uses the enterprise architecture to provide non-customer-based backlog and guide prioritization in sprint planning.

In this use gap Epics and User stories derived from gaps and work packages. External dependency constrains prioritization, acceptance criteria and exit criteria. Overriding priorities may be provided.

This use case mostly exercises the TOGAF ADM Phase G, Implementation Governance: in plain language within Phase G an implementation team is informed of the work they need to perform and external constraints on their freedom to perform the work. How the EA Team communicates is driven by the organization of the implementation team.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

Use Case 4: Use EA to constrain Agile Sprints

This use case largely exercises the TOGAF ADM Phase G, Implementation Governance.

Following best practice EA Governance the essential question is:

Did the agile team reasonably interpret the target architecture’s documented guidance and constraint?

    • If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture
    • If no, develop a recommendation to correct the situation.

This is a key point. Good architecture can have multiple implementation choices, and the agile team is not required to adhere to opinion. If the implementation choice is a reasonable interpretation, it should be judged compliant. If something was left out of the architecture specification, that is not the agile team's problem. It is the EA team's problem, they need a change to the approved architecture.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

The Gaps, Work Package Strategy, Controls and Architecture Specification guide and constrain sprints. They must be written and presented in terms that the agile team can consume. Controls and Architecture Specifications are typically rendered as acceptance criteria and exit criteria.

Use Case 5: Use EA to solve Dependency

In this use case the Enterprise Architecture is used to address dependency & impact across agile teams.

This use case is distinct from Use Case 4, because it changes how the EA team engages. Often where there is dependency, it will be between different change methods (agile & waterfall) and where choices within a sprint can have cascading impacts.

A key role of developing architecture to support Solution Delivery is to identify and address these dependencies before an agile team trips over them.

In Use Case 4, a success measure is ensuring that momentum is not be impaired. In this use case, one team's momentum must be balanced against other agile teams, operational units and teams that use other change methods.

This use case largely exercises the TOGAF ADM Phase G governance & change order activity. Frankly, best practice EA Governance avoids granting exemptions to architecture cross-team dependency. Challenges that were not identified are the most common area of architecture exemptions.

Dependency issues are the EA team's problem. They will need to perform work to dig the organization most effectively out of these holes. Addressing these problems requires careful attention to superior architecture, controls and architecture specifications expressed at Principles.

Use Case 6: Use Agile Methods to develop Enterprise Architecture

In this use case the EA Capability is configured to use agile methods to develop an Enterprise Architecture.

Conexiam Predictable EA is an example of this use case. To help understand that an architecture is used to support decision making, we routinely refer to the useful work product as the “Advice Binder”. This binder is optimized to purpose and problem. It will be consumed in in several different ways.

This use case will largely impact execution of all ADM phases to develop Architecture.  This use case is dependent upon the outcome of Preliminary Phase, and the structure and execution of the EA Capability.

Practitioners who work at the extremes of agile software development and enterprise architecture  will likely never encounter each other. They might not even recognize each other’s work product. The essential tension is in their relationship with each other.

When you stop and consider the alignment of best practice EA and best practice agile software development for basic areas where they interact becomes apparent. Practitioners who work at the extremes of either Enterprise Architecture or agile software development may never know what the other person works for the company they may not see each other’s work product.

An EA practitioner working to support strategy and a tech lead on an agile software team work far apart. The tech lead lives an execution window measured in weeks or months. Release plans or architecture runways are long-term thinking. The strategic EA practitioner could have been working for years beforehand on the roadmap that laid out the development of agile software development capability.

Enterprise Architect's Guide

Download the Enterprise Architect's Guide a TOGAF Series Guide on developing useful enterprise architecture.

Purpose of Enterprise Architecture

Aligning your enterprise architecture team to different agile use cases supports identifying the most applicable Enterprise Architecture use cases.

Join the Enterprise Architecture Kickstart

Free 12-week program to be a better enterprise architect

Scroll to Top