The Architectural Runway – where EA and agile architecture meet

Many defense agencies have chosen agile and DevSecOps as the only way to innovate and have adopted SAFe as the framework to implement this. But agile projects cannot be governed with traditional Enterprise Architecture approaches which we usually see with Defense customers. Because an agile development with its degree of solution-uncertainty at the start would require numerous time-robbing updates of any “big” architecture up front (BAUF). It is better to have only the outlines of the architecture ready at the start of agile projects. This can be described at a level which is just detailed enough for the sprint teams to start working from. In other words: a “Just-Enough-Architecture” or “Minimum Viable Architecture” which can grow incrementally.

Agile projects and agile product or capability development cannot be governed with traditional Enterprise Architecture approaches. Because an agile development with its degree of solution-uncertainty at the start would require numerous time-robbing updates of any “big” architecture up front (BAUF). It is better to have only the outlines of the architecture ready at the start of agile projects. This can be described at a level which is just detailed enough for the sprint teams to start working from. In other words: a “Just-Enough-Architecture” or “Minimum Viable Architecture” which can grow incrementally.

Scaling Agile in a controlled way

When agile working was introduced some 10 years ago the ideas of having architecture as a guidance ranged from “we don’t need architecture” to “as little as possible”.  Especially the developer communities were against any dictating architecture in their quest for creative freedom when designing systems. But that changed overtime and today the benefits of architecture in agile projects is fully recognized. From the “Agile at Scale” survey Capgemini conducted in 2019 on the market adoption of agile we learn that 85% of organizations use SAFe, the Scaled Agile Framework, as a framework. But we also learn that each customer adapted SAFe to fit their culture and the pace of transformation, and mix-and-match several methodologies and concepts. E.g. Capgemini was responsible for implementing SAFe, including training all stakeholders, from developers to senior management with a focus on Architects, at the French Ministry of Defense for the IT Services Infrastructure refoundation program. SAFe was chosen by the ministry in 2018 as the preferred framework for moving to the agility scale.

Landing upcoming releases

In SAFe agile architecture is defined as a set of values and practices that support the evolution of the design and the architecture of a system, concurrent with the implementation of new business functionalities. Which means that architecture must be able to change more rapidly, especially at the physical abstraction level of the architecture. This is in line with the key recommendations for sustaining momentum over the course of the transformation and speeding up agile adoption. The first key recommendation is to modernize IT with DevSecOps and microservices. This is the main driver for the architectural runway, because in order to support agile and SAFe, there must be an IT landscape in place which is capable of  “landing” any upcoming system or software releases. In other words: having a flexible and scalable infrastructure in place which can accommodate the highest priority changes that can be foreseen. Within SAFe this is referred to as the Architectural Runway.

On-the-fly construction

As per the SAFe definition of this concept, the runway consists of the existing code, components, and technical infrastructure necessary to implement near-term features without any excessive redesign and delay. Building on this runway metaphor, system releases can be compared to the airplanes coming in for landing, and the agile architecture is to ensure that the runway is there and suitable (read: long enough) for them to land safely. It is up to the IT infrastructure technology on which the runway is based to deliver features on current and near-term solutions without excessive refactoring. The architectural runway is constructed by so-called enabler features, which are the technical initiatives derived from the architecture epics and which are meant to enable and support the development of business initiatives. The runway can also be adjusted by insights coming from the agile teams. This on-the fly construction of a runway is best supported by cloud technology and its programmatic concepts (Infrastructure as Code) and by a DevSecOps approach supported by automation tooling. Enterprise Architecture helps to guide and govern development activities across the entire scope of the business and establishing principles and standards to be followed by agile projects. But cloud technology and tools can also support and enable the agile architecture and change process by providing tools and techniques that can help build a short runway. By using cloud-based tools like to combine continuous integration, continuous delivery, security, monitoring and SIEM with the process of constantly and consistently testing and building the system, deploying to production, automatically updating documentation and ensuring compliance with Policy as code. This combines to provide a just enough architecture approach with runway that continuously adapts to the needs.

Chicken and Egg

Building the Architecture Runway is a bit of chicken and egg problem: to form the agile teams to build the application or system there should be an enabling architecture defined before any substantial development and deployment of teams can take place. In other words: there cannot be teams without any architecture, and there cannot be architecture without a team. Architects must take a lead role in both the evolutionary and the intentional aspects of the Architectural Runway. But this role needs to be as an architect who enables its design and not to govern it. The Architectural Runway is collectively owned and constructed at the lowest scaling level: by the agile teams.

The architect’s role

The architect’s role is to support these teams in designing and building better solutions that leverage the components, infrastructure and conventions that together make up the Architectural Runway. In a situation where innovation and digital transformation is either fully or to a large extend outsourced to a strategic partner there is also an important role for the latter regarding the Architectural Runway. In a Service Integration type of partnership, the Service Integrator must be able to manage the necessary processes for maintaining the runway. Service Integration has an impact at all scaling levels, and cross-links portfolio, program and team level. This can cover activities like establishing and guarding the rules for collaboration services in terms of the protocols and conventions for the agile teams, and the integration and management of the services that build the large-scale shared infrastructure such as API gateways, message brokers or shared database platforms. Typical processes supporting this are E2E requirements management, architecture change management, capacity management and change & release management.

To conclude it is fair to state that although some would argue that working agile in outsourcing and service integration add complexity to the decision-making process, the benefits of adding relevant and efficient service management processes add robustness to the development process. Which is especially important with customers in the public security and defense sector.

Get your copy of the Agile at Scale report here:   https://www.capgemini.com/research/agile-at-scale/

About the authors