In the world of Agile, the role of architects is often misunderstood. A point of conjecture spotlighted by a well known principle from the Agile manifesto:

The best architectures, requirements, and designs emerge from self-organizing teams.

SAFe does its best to describe the theory and intent behind Agile architecture, however, the architects at Marlo understand that Agile skills and experience in architectural design thinking are needed in order to successfully navigate the challenges of Agile solution delivery. Our wealth of experience across diverse industries has helped us evolve and improve the way we architect in an Agile environment.

In this article, we will discuss the role of solution architects in an Agile delivery setting, looking at some of the skills required and benefits to be gained from adopting an Agile approach. This article uses SAFe terminology, however, the concepts apply equally to other Agile delivery methods.

A Complex Problem

There was a time before Agile when being a solution architect meant working on one large monolithic project for months or years on end, with the hope of one day being part of a successful go-live event. Unfortunately, many projects failed due to scope, time, budget or other unforeseen circumstances, meaning go-live was never a certainty and more often than not the architect had long since moved on to other things.

With Agile came a new way of working, with a focus on rapid delivery of incremental value to the business in a collaborative environment. This immediately disrupted the role of architects, who under a waterfall method, were used to working at their own pace, often in isolation for long periods with limited collaboration.

Marlo was recently engaged with a client on a project using SAFe as the delivery framework. The client was about 12 months into the process of adopting SAFe and transitioning away from a waterfall delivery method.

The project had documented a reasonably simple business brief to deliver a new customer benefits platform with the goal of expanding their customer base. There was little to no documentation of anything related to technology.

It was apparent from the outset that the project’s timelines were very aggressive and the following challenges only added to the complexity:

• The project had little understanding of technology impacts before committing to cost and timing estimations

• The iteration manager didn’t start until half-way through the project

• The project also lost a very knowledgeable product owner half-way through the project

• There were nine specialised delivery streams spread across six different timezones

• Delivery streams were ready to begin prior to much of the architecture being defined

• There was no Enterprise / Domain Architect with knowledge of the technology strategy

• Multiple product owners were impacted by the project and had conflicting needs

• There were several major scope changes throughout, adding pressure, disruption and rework

• The project had committed to highly optimistic deadlines from the outset, with the major deadline brought forward in response to business request

Tools and Techniques

It was clear from the outset that there was insufficient time for a traditional Big Design Up Front (BDUF) approach. However, an intentional design (just enough upfront architecture) was needed rather than relying purely on emergent design (architecture is discovered and extended as part of each increment) to minimise the technical debt and rework that would otherwise eventuate.

Marlo’s first order of business was to agree a way forward by defining an Architecture Runway. The Architecture Runway identified the near-term architecture enablers and their relationship (dependencies) to planned features in the project backlog (this is distinct from a Technology Roadmap which provides the long-term strategic architecture view). Our Architecture Runway included: a new customer identity platform, a new customer preferences platform, data migration approach, integration approach for consumers, support solution for contact centre teams, non-prod environments, and non-functional requirements.

Effective engagement and communication was critical from the outset. Marlo led the way in establishing the meeting and communication cadence for the Squads, including Chapters for functional areas and Guilds for non-functional aspects. We established a stakeholder communication matrix to identify important stakeholders and ensured they were engaged at the appropriate times. This included reporting up to the business and project steering committees as well as the architecture review board.

Establishing clear roles and responsibilities is always important, and never more so than in an Agile delivery setting where emergent decision-making behavior can occur without full appreciation of the consequences. We drew the lines of demarcation between solution architecture, application architecture and technical design responsibilities so all team members understood their role. We also made it clear that collaboration was key and no decisions would be made in isolation or without consultation.

We established a design authority to formalise the collaboration process, supported by a central decisions register to transparently communicate all decisions and their rationale. As the architects, it was important that we demonstrate leadership and competence and influence key decisions rather than dictate the outcome. We made ourselves available and responsive at all times through corporate messaging, email, phone and face-to-face meetings to ensure we didn’t become an obstacle to be avoided. All of the architecture documentation was openly accessible on a Wiki.

One of the challenges we had was ensuring the architecture stayed just ahead of the upcoming features. Even though the Architecture Runway was unlikely to change, we did not have the luxury to plan too far ahead. This was due to the number of near-term architecture decisions required, particularly given we had large development teams already starting to code and new features being added by the day. We used architecture spikes to assess the impact to the Runway when a new feature was added, which allowed us to update the Runway and stay just ahead.

One of the most important roles we played was in our day to day discussions within the Agile squads influencing the emergent design. From these discussions we were able to catch and correct-course on a number of decisions that might otherwise have been missed:

• Passwords being sent unencrypted in clear text

• Data extracts being duplicated

• Applications that were planning to pull data directly from production (risking performance)

• An opportunity to create a reusable interface adapter that was immediately leveraged by another project

Our technical thought leadership identified risks early, minimised technical debt, exploited opportunities for reuse, fostered alignment with the broader technology direction and improved understanding of cost implications.

Benefits

The engagement presented many challenges which would have added significant time and cost to the project in a traditional setting (using a traditional mindset). However, Marlo was able to bring its Agile skills, experience and mindset to overcome these challenges and deliver the following additional benefits:

• Avoiding Big Design Up Front (BDUF) allowed faster start time for Agile delivery teams and quicker incremental benefits to the business, providing more rapid return on investment

• A focus on just-in-time architecture meant minimal wastage of architecture effort (no longer spending months working in isolation) and minimal rework for the Agile teams

• Decisions were made faster (days not weeks or months), documented in a consistent format and available for all to see

• Architects provided technical thought leadership to the Agile teams, ensuring clear technology ownership, early risk mitigation, minimisation of technical debt, architecture reuse, alignment with the broader technology direction and an informed understanding of cost implications

• Although the project went slightly over the original budget, it delivered on time and created reusable technology assets that benefited other projects. A traditional waterfall project would have taken many months longer and would have struggled to manage the changing scope without cost blowouts

Beware

Our experience has shown that going Agile is not all sunshine and rainbows. There are many pitfalls to be aware of:

• Architecture falling behind delivery teams, leading to a high degree of technical debt and rework

• Decisions not made in a timely manner, leading to re-planning, workarounds and delays

• Architecture not appropriately addressing or anticipating the needs of important technology stakeholders such as the Architecture Review Board and Change Advisory Board

• Architecture concerns deprioritised in favour of delivering business features, leading to increased technology operating risks (e.g. security vulnerability, no backup solution, lack of customer support)

• Inability for architects to identify red flags during dynamic discussions

• Inability for architects to balance and trade-off compromises appropriately

The Agile Architect

Agile Architects require a broad range of skills. In addition to traditional architecture skills, an Agile architect must:

• Be highly organised in terms of planning their own work

• Be always thinking a few steps ahead

• Be flexible to change

• Be available when needed

• Collaborate and be inclusive from the start

• Be transparent in terms of knowledge sharing, decision making and documentation

• Be able to shape and influence dynamic discussions

Agile Architects need to move beyond the old ways of working and adopt an Agile mindset in order to add value to the project.

Marlo has the skills and experience to establish an Agile Architecture practice and help clients navigate the challenges of Agile solution delivery. Get in touch today if you would like to learn more about how Marlo can help with your next project.