A Survivor's Guide to Agile Architecture: Navigating the Spotify Model, SAFe, and Industry Standards

In the realm of software development and Digital solutions, Agile Architecture stands as a beacon of innovation, promising adaptability and resilience in the face of evolving requirements. Yet, embarking on an Agile Architecture project can be akin to navigating uncharted waters, fraught with challenges and uncertainties especially when a mixed model is being used by the organisation where such an initiative is only trialed in some pockets. In this blog, we unveil a short guide based on our experience to not just surviving but thriving in Agile projects, drawing insights from the renowned Spotify model, the Scaled Agile Framework (SAFe), and industry standards such as The Open Group Architecture Framework (TOGAF). We explore the role of traditional Enterprise and Solution Architecture methodologies and how this can be used to deliver a successful outcome.

Embracing the Agile Mindset

At the heart of Agile Architecture lies a fundamental shift in mindset—a departure from traditional, rigid methodologies towards a culture of flexibility and collaboration. The Survivor's Guide begins with embracing this Agile mindset, fostering a culture where change is not just tolerated but welcomed as an opportunity for growth. This includes decentralization of decision making, ability to create several "Transitional" architecture as part of Architecture Runway (https://scaledagileframework.com/architectural-runway/ ).

A key practical guidance in this mindset is to differentiate between "Enabler", "Capability" and "Feature" . An architect's effort goes more in telling the story especially around why we need an enabler that is architecturally significant and how to plan for it.

Understanding the Spotify Model

Inspired by Spotify's innovative approach to scaling Agile, our guide delves into the key principles of the Spotify Model. By organizing teams into autonomous "squads," "tribes," and "guilds," the Spotify Model fosters a culture of innovation and collaboration, empowering teams to iterate rapidly and deliver value continuously.

An architect can play the role of "Product Owner" to define various releases, especially while defining the Architectural Runway and guiding the autonomous "squads", "tribes", "guilds" to the most valuable investments. This is where management of "Product Backlog" becomes a key aspect along with "Architecture Repository" for self-managed /delegated governance practices.

There is also the role of architects as "Chapter Leads" in literature but we did not find much adoption. However, core deliverables and skills remain same for architects in both these approaches.

Leveraging SAFe for Architectural Runway

Incorporating insights from the Scaled Agile Framework (SAFe), our guide explores the concept of the Architectural Runway—a metaphorical runway that enables safe and efficient development by providing the necessary infrastructure, frameworks, and guidelines. By establishing a robust Architectural Runway, Agile projects can ensure that architectural decisions are made incrementally and align with business objectives.

As described above, an Architect can play a role of "Product Owner" , a more internal team facing role rather than a "Product Manager" which is more of external facing role. In the world of Agile Architecture, having just enough runway is crucial. If there's too much, it can slow down the teams and make the solution too complex. But if there's too little, the organization might struggle to keep up with its short-term goals. We used "Product Backlog" and capacity allocation to balance the work between making improvements and delivering to customers, keeping things running smoothly.

A key note is to be-friend the "Product Backlog". A product backlog is not a parking lot but key items that will ensure the product is beautiful, resilient and stands the test of time (or simply both functional and non-functional requirements are met).

Aligning with Industry Standards

Drawing upon industry standards such as The Open Group Architecture Framework (TOGAF), our guide emphasizes the importance of aligning Agile Architecture practices with established frameworks and best practices. By adhering to industry standards, teams can ensure consistency, interoperability, and scalability in their architectural designs.(Reference: https://pubs.opengroup.org/architecture/o-aa-standard-single/fulltoc.html#_open_agile_architecture)

We found useful to think TOGAF Architecture Principles as "Guardrails" in Solution Intents. There are certain things that are fixed e.g. adherence to a legislation, standards such as PCI DSS, etc. , whereas others maybe variable e.g. choice of API testing tools.

Iterative Architecture Design

Central to surviving in Agile Architecture is the concept of Iterative Architecture Design, where architectural decisions are made incrementally and iteratively. By breaking down complex architectures into smaller, manageable components, teams can adapt and evolve their architecture in response to changing requirements and feedback.

We used the term "Transition Architecture" which was palatable to stakeholders (TOGAF terms it as "Continuous Architecture", although we found that not so palatable to stakeholder who are yet to grapple with Product vs Project mindset).

In practical terms, we found creating a "Baseline Architecture" a key aspect in "Continuous or Transition Architecture"

Architecture Repository

In Agile architecture, the Architecture Repository plays a pivotal role in managing baseline and transition architecture. Serving as a centralized hub for architectural artifacts, decisions, risks and documentation, it provides a single source of truth for the evolving architecture landscape. The repository enables teams to store, access, and collaborate on architectural components, ensuring consistency and alignment across projects.

With the Architecture Repository, teams can easily track changes, manage versions, and reference past decisions, manage architecture risks, facilitating seamless transitions between baseline and transition architecture. By harnessing the power of the repository, organizations can streamline the architecture development process, accelerate decision-making, and maintain a clear vision of their architectural direction throughout the Agile journey.

(Reference: Salameh, A., Bass, J.M. An architecture governance approach for Agile development by tailoring the Spotify model. AI & Soc 37, 761–780 (2022). https://doi.org/10.1007/s00146-021-01240-x )

We found solutions such as Orbus Infinity (https://www.orbussoftware.com/orbusinfinity), a top rated Gartner Strategy & EA solution, key in solving some of the nuances and giving us more collaboration and consultation time by automating architecture tasks, a key feature in Agile projects.

Continuous Integration and Deployment

In the Agile world, Continuous Integration and Deployment (CI/CD) are not just buzzwords but essential practices for ensuring rapid and reliable delivery. CI/CD pipelines enable teams to automate testing, integration, and deployment, streamlining the delivery process and reducing time to market.

We used our transition architectures to incorporate reporting of several automated building blocks as part of CI/CD pipelines giving business releases that are more valuable, without losing sight of "Enablers" that provide more resilience to the product.

An example of this in one of our solution was "Disaster Recovery". We ensured that this is maintained in the Product Backlog at the start and as part of our Transition Architecture. Squads capacity was planned for future iteration when the product adoption was more evident. This ensured that agility and resilience concerns were both were met. Providing highly resilient system at the start was low business value when only few users were onboard, but it was important to plan upfront as part of Transition Architecture.

Key takeaway here is that Architecture Repository helps in highlighting these gaps and tells the story in an easy to understand way.

Collaborative Decision-Making

Last but not least, we emphasizes the importance of collaborative decision-making in Agile projects. By fostering open communication and cross-functional collaboration, teams can leverage the collective intelligence of the organization to make informed architectural decisions that drive business value.

One other challenge was to explain to our stakeholders concepts of "Architecture Spikes", a key enabler that may require research, experimentation and simulation. We will explore this further in a separate blog and how utilising good tooling and techniques help in our communication.

Leveraging an Architecture Repository that can use existing solutions such as MS Office 365 can provide transparency, accuracy and accessibility and can speed up decision making in the organisation, again a key element of "Agile Mindset". This is where architects can move to a higher value chain and help lead the organisations deliver outcomes especially constrained environment where limited time and resources are available.

Conclusion

In conclusion, Agile projects present unique challenges, but with the right mindset, methodologies, and adherence to industry standards, they can be incredibly rewarding. By embracing the Agile mindset, leveraging insights from the Spotify Model, SAFe, and industry standards such as TOGAF, and having a suitable Architecture tooling teams can navigate the complexities of Agile Architecture projects with confidence and resilience. Connect with us to know how we can help.

Here's to embracing the Agile journey and thriving in the ever-changing landscape of digital projects and software development!