How enterprise agility will redefine architecture

Newsflash: the world is going Agile, and for organisational leaders the question is no longer will Agility impact me, but how will it impact me? The Deloitte 2018 predictions for Agility in Australia highlighted that Agile has grown from IT-shop to enterprise scale and is now infiltrating non-technology domains[13].

With this comes faster cycle-times (Flicker was doing 10+ deployments a day, 10 years ago[14]), distributed decision-making and automation of everything. Traditional Architecture functions, steeped in manual reviews, centralised governance and lengthy architectural development cycles appear at odds with this future [1][3]. So if you’re an architect, how do you stay relevant?

Figure 1- Definitions

Despite the apparent threat, Enterprise Agility does not spell the end of Architecture but in fact can be a catalyst for change and disruption. Whether a company is Waterfall, Agile or Hybrid, architects will always be required to support technology decisions and align IT to business strategy[2][5]. These outcomes remain as critical as ever, but how they are reached will be vastly different. In this blog we will discuss four ways Enterprise Agility will redefine Architecture. Get ready.

1. Architects will be less involved with delivering things but more involved with ensuring the right things are delivered

There is a misconception that architects spend all of their time ‘doing’ architecture and producing complex diagrams[4]. It’s the organisational decision-making process that the architect must drive before an artefact is delivered, however, that really matters. Reaching consensus on complex decisions involving diverse stakeholders with competing views is where the architect is irreplaceable[12]. Be it navigating emerging technologies, legacy system replacement, or completing post M&A consolidation roadmaps; as Agility scales, the need to make these architectural decisions in a timely manner goes up. The need for Architects to support this goes up.

This doesn’t mean architects won’t produce any diagrams, but enabling the best technology decisions to be made is where the value of architecture will be realised in an Agile Enterprise[3][4]

2. Architects will spend less time defining ‘intentional’ architecture

Intentional architecture is the traditional up-front, plan based architecture that most of us are familiar with. The Architecture is designed and handed over to development teams to build. The more detailed the architecture the more ‘intentional’ it becomes.

There is little doubt that in a fixed-price contract world, having as much detail as possible up front is a necessity. And in general, updates are avoided at all cost for fear of the change request. But in an Agile Enterprise, procurement functions will evolve along with the Architecture function. And through a combination of incentive-based or time and materials contracting[21][22][23], this evolution will permit Product Owners to inspect and adapt.

So for the architect, as agility scales, a degree of up front planning remains essential. But defining detailed architectures across large time horizons is no longer required. Architectural work will be decomposed into smaller packages and managed in a ‘just in time’ fashion[11][12][13]. The Scaled Agile Framework (SAFe) provides an example of this with its Architectural Runway that is used to ensure technical dependencies are always delivered at least one sprint before the application functionality that needs it[10][11][17]

          Figure 2 - Architecture will revolve around team based decision making
3. Architectures will ‘emerge’ as accountability for design is distributed to cross-functional teams

Enterprise Architects will enable Scrum teams to rapidly develop their own product/solution architectures by spending more time understanding business strategy and defining supporting architectural principles[3]. Not to be confused with up front definition of intentional architectures, these principles define the ‘rules of the game’ that Scrum teams must exist within, without mandating specific implementations. Combined with transparent logging of architectural decision-making by Scrum teams[3], this principle definition reduces the need for architecture governance to act in a command and control manner.

To support distributed decision-making, Enterprise Architects will also need to embrace DevOps and configuration management tools. Instead of centralised forums and manual review, EA teams will partner with Engineering Centres of Excellence to script hardware, network and security standards (to name a few) to provide a platform for innovation[16]. (For more on this, see the Deloitte Article: Reengineering technology: Building new IT delivery models from the top down and bottom up[9])

4. Solution Architects will become Technical Scrum Masters and act to remove technical blockers

In the same way traditional Project Manager accountabilities are dispersed amongst Scrum teams, traditional solution design authority -normally the bastion of a Solutions Architect- will become a Scrum team accountability[8]. The Solutions Architect will no longer be deployed to a given project but will operate across multiple Scrum teams acting as a technical servant-leader accountable for removing technical blockers[3]. For example:

  • If a Scrum team has a dependency on an enterprise authentication service, it will become the role of this ‘Technical’ Scrum Master to solve this
  • If a Scrum team wants to make a significant Architectural change that may impact other teams, the Technical Scrum Master needs to analyse the impact and facilitate a resolution.

Architectural Principles and automation of standards will allow teams to work almost independently, the Technical Scrum Master is needed to help with the exception scenarios and ensure alignment with Enterprise Architecture.

The bottom line

Architects help develop architecture – and this won’t change. But as Enterprise Agility moves from the blue sky to the here and now, Architects must adopt new ways of working. At both enterprise and solution level, Architects must define adaptive architecture development methods and embrace servant leadership. Like all transformations this won’t happen overnight, and in true Agile fashion the redefinition of the Architecture Function will require adaptation as companies inspect and learn.

But what we know now, is that the time to start getting ready, was yesterday.

Want assistance with Architecture in an Agile Enterprise? Contact Us!
Want to know more about our Technology Strategy and Architecture Practice? Check us out!

Supporting footnotes

[1] Blosch M, Osmond N, Norton D, 2016, “Enterprise Architects Combine Design Thinking, Lean Startup and Agile to Drive Digital Innovation”, Gartner

[2] Blosch M, Santos J, 2017, “Use EA to Ensure Your Agile Development Succeeds”, Gatner

[3] Barnett G, 2018, “Make Enterprise Architecture Key to Digital Transformation”, Forrester

[4] Erder M, 2016, “’Continuous Architecture’: Sustainable Architecture in an Agile and Cloud-Centric World”, Books24x7

[5] Mann KJ, 2017, “Find Your True Meaning of ‘Architecture’ to Succeed with Agile”, Gartner

[6] Cullen A, 2018, “Defining The EA Service Catalog”, Forrester

[7] Corless et al, 2018, Reegineering IT Transformation, Deloitte

[8] Scaled Agile Framework, 2017, “Agile Architecture”,

[9] Deloitte, 2018, Tech Trends 2018

[10] Leffingwell D, SAFe® Foundations 4.0 with Dean Leffingwell (V4.0.6), Scaled Agile Framework

[11] Crips Agile Academy, 2017, Agile Architecture with SAFe

[12] Barnett G, 2018, “Develop an Enterprise Architecture Strategy Aligned with Business Challenges, Forrester

[13] Muir M, Oliver T, Venkatachalam, 2018, The time is now – our 2018 predictions in becoming an Agile Australia, Deloitte

[14] O’Reilly, 2009, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

[15], 2018, Scrum Glossary

[16] Minness S, 2017, How can DevOps enable your agile transformation? Insights from the State of DevOps 2017

[17] Scaled Agile Framework, 2018, The Architectural Runway

[18] Muir M, Oliver T, 2017, Defining Enterprise Agility

[19] ISO/IEC 42010, 2007, “Systems and Software Engineering – recommended practice for architectural description of software-intensive systems”

[20] The Open Group, 2018, “The Open Group Architecture Framework Version 9.2”

[21] Berstein A, 2015, How to write supplier contracts for agile development, Computer Weekly

[22] Overby S, 2016, How to contract for outsourcing agile development,

[23]“Agile Contracting: How to ensure speedy development and accountability”, TechTarget

Want to stay up-to-date?

Stay on trend and in the know when you sign up for our latest content