Agile Enterprise Architecture: What is it?

Undoubtedly, there is a need for organizations to embrace enterprise architecture (EA). How else would you be able to change and respond to business and IT needs without first of all writing down what you have, want and need? The old adage that anything of any complexity needs to be modelled before it can be changed definitely holds true. The issue is that enterprise architects have tended to model everything down to an excruciating level of detail, often getting lost in the weeds and rarely surfacing for air to see what the rest of the business is doing, and realizing what it needs.

Like it or not, EA has a bad reputation for not providing any business value except for a wall covering of designs. Frameworks and languages such as TOGAF, ArchiMate and DODAF aren’t responsible for this perception. In fact, these standards provide a mechanism for communication and delivery, but its how enterprise architects use them that brings issues.

Goal: To understand the concept and the features of enterprise architecture for business agility

We’ve all heard the terms “just in time”, “just enough” and “agile development and delivery” – but how do these affect EA? What’s missing in EA is the delivery of ‘just in time’ and doing ‘just enough’ architecture to achieve results. It’s time the EA team met the desires of stakeholders by only doing enough of what is required to meet those expectations. Sometimes, a deeper EA initiative is required such as in defense projects or on large complex programs, and ‘just enough’ may not have the rigour or depth that you require.

Just in time Enterprise Architecture

Agile Enterprise Architecture is based on “just in time”. You can see this in many of the agile practices, especially in DevOps. User stories are created when they are needed and not before and releases happen when there is appropriate value in releasing, not before and not after. Additionally, each iteration has a commitment that is met on time by the EA team.

Just enough Enterprise Architecture

EA is missing the answer to the question; what exactly is getting delivered? This is where we introduce the phrase “just enough, just in time” because stakeholders don’t just simply want it in time, they also want just enough of it – regardless of what it is! This is especially important when communicating with non-EA professionals. In the past, enterprise architects have focussed on delivering all of the EA assets to stakeholders and demonstrating the technical wizardry required to build the actual architecture. Does this contribute to the demise of EA in the eyes of the stakeholder?

Let’s look at a few examples of just enough enterprise architecture:

  • Campaigns – create a marketing style campaign to focus on EA initiatives. Focus on gathering and describing only what is required to satisfy the goal of the campaign.

  • Models – at the start of the project it doesn’t make sense to build out a fancy EA that will change anyway. Teams should be striving to build just enough architecture to support the campaigns in the pipeline.

  • Collaboration – agile teams certainly have high levels of collaboration, but that’s because that level is just enough to help them be successful.

  • Planning – at iteration planning we don’t look at things outside the iteration. We do just enough planning to make sure we can accomplish our goal for the iteration. Tasks play a large role in both planning and collaboration.

Consistency vs Just Enough

Doing just enough doesn’t mean that we should do this at the expense of consistency. After all, a big benefit of enterprise architecture is the ability to slice across the architecture for decision making and ‘what if’ analysis. The underlying model should still be consistent and it should be described to a level of detail and consistency that makes it meaningful. This is the skill of the agile enterprise architect.

Useful EA tools

Light sketches are useful to brainstorm before getting into more formal modelling. Although not a formal part of architecture frameworks such as TOGAF or ArchiMate, they can provide a useful communication mechanism.

ArchiMate provides a standard notation and metamodel for EA but we certainly don’t need to do all of it to achieve results from our architecture. However, ArchiMate provides EA with a common language for communication and therefore ensuring consistency across our teams.

Socialization and gamification – involving other experts and communities in the EA effort provides the benefit of ‘buy in’. Leaderboards, likes and rewards are all mechanisms to reward stakeholders for their participation in the EA initiatives.

Tracking work and allowing team members to collaborate is critical, not only for EA teams. The agile community has used Kanban boards for a while now because they can be used to track tasks and issues for the team and also be used to show where facets of the EA are in the workload. Additionally, a kanban can be used to ‘force’ progression of work so that it is completed on time.

Goal-based campaigns

In order to focus EA efforts, campaigns can be used to set a start and end date. Kanbans, along with communities and tasks can all be geared around achieving goals in much the same way that a marketing campaign has end goals, metrics, and deliverables. A marketing campaign is ultimately measured by its success and similarly campaigns in Agile EA can be measured on success rate.


We certainly don’t need “just in case” documentation, but its crazy to think that agile teams can be effective without documentation. We need just enough documentation to make sure the team is successful.

Slide shows

When information and architecture is changing rapidly, then documentation-led enterprise architecture is often at odds with just-in-time and just enough. Dynamic documentation or the ability to present information quickly and without fuss becomes paramount.


An agile approach to enterprise architecture is about enabling business agility, and this can be achieved through a variety of techniques and tools that support building an architecture quickly and efficiently. Targeting a business goal and doing just enough architecture to achieve that goal helps an organization be more agile.

Back to Erwin Expert Blog