Introduction to Agile Architecture:

“While we must acknowledge emergence in design and system development, a little planning can avoid much waste.”

—James O. Coplien on Lean Architecture

Agile Architecture, as defined in the © Scaled Agile framework (SAFe), “is defined by a set of values, practices, and collaborations that support the active, evolutionary design and architecture of a system. This approach embraces the DevOps mindset, allowing the architecture of a system to evolve continuously over time, while simultaneously supporting the needs of current users.“

In comparison to the classic Waterfall delivery approach, the Agile delivery approach focus is on delivering value fast, through quick and small iterations that maximise return on investment and increase business agility. When Agile delivery is introduced in an organisation, the maturity level of all business units should be developed including the maturity of the Architecture Team. Agile Architecture is different from the legacy approach for many reasons, some of the most important are:

Agile architects define “just enough” architectural runway (refer to section below for the definition) to support the evolving business needs.
Agile development avoids Big Designs Up-front, reducing the design effort to the minimum necessary to iterate the solution.
The Architecture evolves over time.
Delivery in production is fast as agile avoids overhead and delays associated with phased/gate approaches.
The solution is quickly brought live and kept live to maximise its return on investment.

When approaching Agile Architecture for the first time there are some core aspects an architect should consider.

Less Design equals more Governance

Less design upfront does not mean that Architects cannot control the solution. On the contrary, a solid governance process should be in place to control and successfully deliver an Agile programme. Solution Iterations (programme releases), should be fully documented and the documentation should also follow an iterative approach in line with the programme iteration phases.

There are many types of Roadmaps

There are Portfolio roadmaps, Solution Roadmaps, Release Roadmaps, and Plans. They implement the less to the most granular view of the enterprise, moving from an end to end enterprise-level view to a more granular system-level view. Architects should own roadmaps and be aware of plans in order to secure end to end alignment of strategy and tactic.

Focus on Architectural Runway

Architects should focus on defining a runway for code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Define the Solution at multiple levels in Parallel

Business, Data, Application and Technology Architectural Runways should be defined by the Architecture team. The use of Architectural Runway allows a modular approach where Enterprise and Solution Architects define the Runway at Release Level for future releases, Solution Architect and System Architects define it across systems and for each Application on the current release. This approach allows defining the minimum viable (‘just enough’) architecture to be refined during release work.

Architects should work alongside Programme managers

Architects play a critical role in designing systems that can provide a continuous flow of value to the user. During Increments (release) Planning, architects should support the teams to create their plans.

Be ready to manage complex deliveries

In complex solutions, Architects shall work together to a common solution. The Solution architect works on the whole solutions, where instead system architects focus on delivering specific System Features that enable the solution to support required Capabilities (that are in effect groups of features).

Build incrementally

Architect, design and build the solution incrementally in a series of short timeboxes, resulting in a working system/solution.

Assume Variability

The Architecture must evolve, thanks to Set-Based Design (SBD) or Set-Based Concurrent Engineering (SBCE) where a wider design set is defined initially, considering multiple design choices at the start. Design options are left open for as long as possible to produce more optimal technical and economic outcomes.

Balance Emergent and Intentional Architecture

Emergent design is defined as “the process of discovering and extending the architecture only as necessary to implement and validate the next increment of functionality”. Where instead the “Intentional Architecture defines a set of purposeful, planned architectural strategies and initiatives”. Those two aspects of defining an architecture should be balanced, to enable the organisation to deliver an agile initiative that aligns to the Architecture strategy.

Evolve deployed systems

Architecture team should support the organisation to enable Continuous Delivery Pipelines that allow systems to be released early and evolve. This is also valid when designing systems, as they should be architected to support continuous deployment and release on demand.

Introducing Agile in an organisation should be seen as a journey. When Agile is wrongly implemented it can take a toll on the organisation’s ability to deliver efficiently. Our partner Bruhati are experts in implementing Agile in organisations, leading the Architecture team of organisations undertaking large digital transformation.

For more information and a FREE consultation please visit www.bruhati.com or contact sales@bruhati.com.