A Scaled Agile Approach to Enterprise Architecture

May 22, 2015

A-Scaled-Agile-Approach-to-Enterprise-Architecture-336x336 A Scaled Agile Approach to Enterprise Architecture agile Several recent articles by Jason Bloomberg on Forbes have put the spotlight on the division between enterprise architects and the Agile movement, and have highlighted the necessity of bringing these two sides together. Towards the end of his article titled Scaling Agile Software Development for Digital Transformation, Jason urges digital transformation professionals to choose their tools with care. The following article is for those enterprise architects that wish to go Agile and become Agile Enterprise Architects (Agile EA) and practice a new type of architecture: Agile architecture.

One of the biggest causes of aggravation between enterprise architects and software development teams is caused by the legacy of other, older software development models where the design is always up front vs the design as you go of Agile development. This typical idea of enterprise architecture would provide the enterprise architect a command and control position, a incompatible role within an Agile development team, and therefore a role that must alter radically to become part of an Agile team (will come back to this at later).

For Agile developers reading this, let’s be clear: you can’t scale Agile effectively without an enterprise architect; your business needs one. Many of you might be wondering why not consider the various frameworks for scaling Agile such as the Scaled Agile Framework, designed for scaling Agile with developers working in SAFe® teams? this provides your business with architecture, right? Wrong!

The Scaled Agile Framework provides a framework that enterprise architects can use to scale Agile in your organization. It is for this reason we advocate having an ownership position for the enterprise architect.

What exactly does an Agile EA do and how does it differ from the traditional enterprise architecture?

In the context of an enterprise software development project, the purpose of the enterprise architect is to determine how to best utilize the resources allocated to the project to meet the current and future objectives of that project and draw up the blueprint for the project teams to follow.

The whole point of carrying out architectural modeling is to:

  • Provide credibility for the initial plan.
  • Mitigate the potential risk of individual team members working to different visions of the same project
  • Make sure the system works and ensure that performance requirements are met

The ongoing task is ensuring that everyone involved is working to the same project vision. To use music as an analogy, consider an orchestra playing to the same piece of music as opposed to an orchestra playing from memory (not errors just different versions with no harmony).

To become an Agile Enterprise Architect you must leave the idea of “fixed” or “finalized”. You must open up your UML modelling  for scrutiny, signing up for inclusion into a process of constant feedback from your Agile development colleagues. Just as with Agile development, strategy changes with changing requirements. Your Agile modelling must change to meet the new order of things. The end goal of Agile architecture is, as ex-Netflix Adrian Cockcroft suggests, to promote emergent behaviour within and between development teams, and alter management style to accommodate and manage the productive chaos without restricting the the creative process. From a business perspective, the Agile Enterprise Architect’s role is to assist with business transformation.

Agile Architecture should be integrated throughout the Application Development Lifecycle

The right tool for enterprise architects is Intland Software’s codeBeamer ALM. With our Enterprise Architect plugin, we provide a bidirectional and completely traceable development process by integrating your EA modelling tool and codeBeamer ALM.  Intland’s EA plugin lets you import diagrams and work items into codeBeamer. Syncing also works the other way around: requirements, tests, and other work items may be exported from your ALM solution & imported to Enterprise Architect.

codeBeamer ALM, an Enterprise Architect-friendly ALM Software Solution

For a better understanding of our Enterprise Architect plugin and the benefits of UML-ALM integration, check out our webinar recording below, as well as the integration demonstration provided by Architect Group Inc.

facebook A Scaled Agile Approach to Enterprise Architecture agile twitter A Scaled Agile Approach to Enterprise Architecture agile google A Scaled Agile Approach to Enterprise Architecture agile linkedin A Scaled Agile Approach to Enterprise Architecture agile

Related E-Book

Agile-Waterfall Hybrid Template

First Name

Last Name

Email Address


Phone Number


Eva Johnson

Written by

Eva is an Economist (MSc) and also holds an MBA in Marketing Communications. She has over 10 years of experience in journalism, digital media communication and project management working with several multinational companies and governmental institutions. You will find her blogs posts on a variety of subjects from Agile-Waterfall Hybrid, Scrum to DevOps.

Eva Johnson has written 132 posts for Intland Software.

2 Comments. Leave new

You need an enterprise architect not (just) to keep the team from going off in all directions, but to make sure the system actually works, especially in meeting performance SLAs. In fact worse than that, in order that the a plan has any credibility in the first place.

It was brought home to me very clearly on a recent project, that architectural judgment and skills are not required for most developers. We had a plan where the “tasks” varied enormously in scale and scope and ended up broken into a dozen or more, to the shock and surprise of the scrum master and management. Frankly several were impossible for the kind of staff they had there. But even just the performance issues were beyond the technical level of the staff, even those with “architect” in their titles – also for those with “manager” in their titles.

The problem is they all thought the very concept of architecture was obsoleted by Agile. They were very wrong, and over $20m in development was trashed and the team of 50 fired – and to this day, I don’t think the management has a clear idea of what happened.


Sorry to hear about it! It is always a big problem if the management do not know the teams, the skills and the methodologies (how to use a system). Sure, you are right, you also need an enterprise architect to make sure the system actually works.


Leave a Reply

Your email address will not be published. Required fields are marked *