Left Behind in Agile Transformation: Your Architecture Practice

If you are transforming your organization to agile delivery, you may be overlooking a secret weapon – your architects. This should be a concern for any executive in the midst of such a transformation, as the successful result will be an agile business, not just agile delivery.

Enterprise architects get no respect.

I know, I’ve led architecture teams for over 30 years and experienced the disdain – blamed as ivory tower thinkers (not doers), viewed as a policy-focused governance bottleneck, and accused of introducing confusion by bringing in complex tools.

Fourteen years ago I even developed a workshop to help architects try to get some respect by tracking and publishing metrics. Arrgh – even more complexity!

The slide may be from 2008, but it’s still relevant today!

That reputation is one of several reasons architects are being left out of the transformation to enterprise-level agile methods. There are a few other reasons, too:

  • Enterprise architects too often operate as “Enterprise IT architects,” focusing exclusively on design of technical internals and not part of architecting the business (or separated from business architects who may be doing that work).
  • Agility efforts too often focus on automating software development and operations (Devops), ignoring the agility gains in up-front requirements and business alignment work that typically is the realm of enterprise architects.
  • Operating in organizational / disciplinary silos results in architecture focusing on the only thing they can: gate review checkpoints and other policing activities.

Architect redemption is possible.

Your enterprise architects have the enterprise knowledge, leadership skills, and problem-solving abilities to be champions of your journey to an agile enterprise. If prioritized right, there are activities your enterprise architects can tackle during (and ideally before) your organization launches a formal transformation to agile.

Here are four absolutely necessary architecture activities that will set the stage for your transformation to agile and gain architecture redemption along the way.

1. Get architects involved in strategic planning

First, your architects should be involved in your enterprise strategic planning. That means helping facilitate the creation and documentation of your business motivation – the reason for the enterprise’s existence.

The business motivation includes the enterprise vision, goals, and objectives (the “ends”) as well as the strategic themes, value chains, epics and enablers (the “means”). This work is often referred to as “Business Architecture” and thought of as separate from Enterprise Architecture.

It is not. It is the heart and soul of Enterprise Architecture.

An excellent architecture resource for structuring this critical information is the Object Management Group’s Business Motivation Model (BMM). While it describes an elegant way to connect the big picture enterprise to complex technical systems, those >80 pages of BMM material are not consumable by your business audience. Only a geek interested in creating order from enterprise chaos would be able to make sense of that document. But you probably already have such people in your organization – the enterprise architects!

The BMM should be understood and then used by your enterprise architects as a technique to structure strategic information and connect that strategic information to operational constructs. Your architects can then engage the business to fill out any knowledge gaps. The BMM concepts (elements within the “means” and “ends”) are easily mapped to agile concepts, especially those within the Scaled Agile Framework’s (SAFe) Strategic Themes.

2. Get smart about where to apply agile

Second, involve your EA team in identifying the enterprise level value chains, the high level sequence of activities that make you money (SAFe refers to these as “operational value streams”). Your architects can then identify the value chains benefiting most from a move to agile.

Not all work is suitable for multidisciplinary agile teams. Value chains that include transformation to new products, services, processes, or business models are ideal for agile work. Your architects should be expert at identifying (and reducing) complexity, making them great candidates to help the organization identify the value chains that will benefit from a multi-disciplinary, iterative, exploration.

Your architects should be familiar with, and apply, the Cynefin (pronounced kuh-NEV-in) decision making framework. Complex, complicated and even chaotic value chains are candidates for agile. Leave the obvious ones (financial value chains could be one example) alone, or at least make them the last areas to consider for conversion to agile.

3. Stay in the game

Third, remember that architecture is implicit in agile implementations. The Agile Manifesto’s eleventh principle states “The best architectures, requirements, and designs emerge from self-organizing teams.” On the surface this principle elicits thoughts that architects may not be needed – architecture “just happens”.

Just the opposite is true! Architect skills are needed more than ever.

Until the time that your agile teams are skilled and mature enough to be making architectural decisions AND you have enterprise level architecture in place, agile teams will need more up-front architecture, as well as mentoring in design skills. As the teams gain proficiency at design, your enterprise architects can provide less upfront design and let the architecture “emerge”. 

Even then, you still need enterprise architects to “see” the enterprise and solution level designs, how they interact, and manage the architecture runway.

4. Promote architects as change agents

Fourth, choose at least one architecture leader to be on your initial Lean-Agile change agent team. Agile change has to be tied to the maturity of your existing enterprise architecture practice.

If your EA group is already doing true enterprise architecture – linking business strategy to business process and then to the enabling technology – they will be a key asset in your ability to scale agile.

They may have already completed the first three activities I describe above. If so, they will be key assets in choosing that first agile project.

If your EA team needs to start that key strategic work, then being part of the change agent team provides the chance to educate all leaders as to the prep work needed to get agile off the ground.

Is this, finally, the shot at respect Enterprise Architects have been missing?

As I see it, Enterprise Architects have been providing the key constructs needed to sculpt the enterprise landscape in preparation for Enterprise Agile (at scale). Now is the time for us to stand up and demand our involvement as leaders in the journey to the agile enterprise.

About the author


  • David Baker

    Dave was a partner and Chief Enterprise Architect for PriceWaterhouseCoopers and Diamond Management Consultants. He has decades of experience pioneering the use of business architecture and business capability models to deliver strategies that align business and technology.

From Strategy to Reality®

You May Also Like

Happy Boss

Revenue Enablement is the New Sales Enablement

Successful companies recognize that the role of Sales Enablement needs to extend beyond just enabling the sale, instead continuing to partner with Product, Sales, and Customer Success teams to create more value to the customer… and revenue to the business.

Read More

Sign up for our Insights newsletter

Shopping Basket