The Role of the Architect in an Agile World

Agile is mainstream, there are a lot of organisations operating agile teams delivering great business value as they go, let's be honest though there are lots of others who don't do "agile", some never will and that's fine but quite a lot are still looking on in envy with grand plans to change. As these grand plans get implemented the agile focus on delivery places a lot more pressure on the community of people who try to keep on top of the complex enterprise systems that keep these organisations working (Architect's), As an architect I've been involved with quite a few transformations and with the most recent I decided to get much more involved in the agile community. I set out trying to consume as much information as I could but quickly noticed a lack of column inches dedicated to looking after the wider architecture within the agile organisation, so as an architect who has also been a developer I thought I'd be in a good position to make a contribution. (Links at the bottom to the information I did manage to find)

Let me start off by stating that system architecture is a responsibility spread across all technical teams, I've heard and read a few different views on what architecture is, a lot focus more on what would qualify as an architectural decision, and that it is the important "stuff" relating to a system. We need to be careful as the two are separate concerns and you don't want to imply that if you employ an architect they are more "important" than developers. Also, it is important to note that regardless of the size and complexity of the project you are working on if you build a system without employing an architect, you will still end up with architecture.

The reality is when creating software people are constantly making decisions, all of them important, teams need a clear view as to which decisions need to be shared or raised within the team structure in place, for example, coding patterns often sit with technical leads and developers, messaging patterns often have wider implications and should be dealt with by more experienced technical leaders (Who normally have a job title with architect in it) if you don't employ an architect design decisions like this are still made because the entire team are looking after the system architecture, it is just that from time to time different people are taking on the role in order to progress and more importantly they are discussing it and agreeing on the collective way forward.

So with this in mind, if you do employ an architect, or worse you are an architect! What should they/you be doing in an agile environment? Here's my attempt to distil what can be quite a "Jack of all trades" role into some key distinct area's

Consultancy & Early Design

Most agile methodologies have product owners as key players making a call on the scope and priority of work, architects need to be seen as technical counterparts to these product owners and in doing so will become trusted technical consultants within multiple levels of the organisation.

They will start to develop a strong understanding of the roadmap for their respective area's, this is critical in an agile delivery environment as an architect is best placed to spot how much upfront design is going to be needed for each change initiative. They can get involved in conversations early to prepare and consult on important design decisions that will impact the architecture before prioritisation within the delivery teams.

This early insight allows the architect to get an initial view on the straw man design, which areas are likely to need effort and whom to bring into the discovery discussions later on in the process.

These initial designs will need to be the right level to provide direction to the multiple agile teams that may exist but not too detailed to create a bottleneck in the process, more importantly, the best solutions tend to arise when the product owners and developers sit together to discuss the problem, if an architect tries to pre-empt this in isolation, any detailed upfront design usually ends up being re-worked.

Design

When working with the delivery teams, if the change is architecturally significant the architect needs to focus on developing a shared understanding of the end-to-end solution with the team, typically as part of a design or story mapping session the architect will take team members through the upfront design they have already put together handing over responsibility for the next level of detail to the team or teams looking to build the end solution, this will undoubtedly flush out gaps and considerations, the developers are closer to the code and the product owners closer to the problem to be solved, design sessions for large scale changes across a complicated architecture in my experience always benefit from design sessions led by an architect with a strawman solution.

In smaller companies as mentioned earlier, product owners and technical leads would normally take on this role however when you scale to enterprise level they can quickly become overloaded, technical leads won't have time to liaise with business stakeholders while also supporting their team of developers, product owners won't always have the full understanding of a complicated architecture.

Delivery

Architects need to be close to the delivery teams in order to be accessible to people who may need some guidance on the end-to-end solution, typically they aren't permanent members of a delivery team, however, it really depends on skill sets and the type of solutions being developed. You need to be careful during this phase, people should not be looking to an architect to solve every problem when they can just have a conversation with one or more team members, more often than not this is a sign the team members are lacking in experience.

Stand-ups can be a really useful source of information on progress and provide the ability to jump in on area's if needed, however, if there are a lot of teams then it quickly becomes difficult to scale. I guess the important point I'm trying to make here is if you have an architecture team then they should be embedded in the day-to-day delivery process, each company will be different though and there is a balance to be had as they should not become a bottleneck.

Executive feedback during delivery is another area an architect can add value, they often have to communicate with senior stakeholders having to convey very technical concerns in a non-technical language, this very much depends on the strengths of the product owners though but if they are working together closely then they should be calling on each other to help get the right messages back up the organisational structure.

Other Information

I've tried to cover some key tips and areas above, but the main points I see are

• Architect's need to develop strong relationships with stakeholders across the organisation
• They need to be seen as trusted technical leaders so stakeholders can bounce idea's off of them to inform backlogs and roadmaps
• An architect should be focused on developing a shared understanding of the end-to-end solution across the team
• Detailed design needs to be driven by the people who are actually going to build whatever it is you are building

Writing this I've realised that most architects should be doing a lot of this regardless of how things are delivered but I hope I've given it an Agile focus, also I could probably find and replace the word "Architect" with the term "Technical Leader" and I've probably described a role a lot of people perform within their organisations already.

Links / Further Reading

Martin Fowler (Who needs an architect) - I don't quite agree with his definition of architecture but don't take my word for it (He's a bit more experienced than me!) Some good insights in this paper though https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Gregor Hohpe (The Architect Elavator) - A great way to articulate where an architect add's value in a large organisation https://www.enterpriseintegrationpatterns.com/ramblings/79_elevator.html

Jeff Patton (Dual Track Development) - Excellent view on typical discovery/design in a mature sprint cycle, architects need to understand and compliment the type of design activity that should be taking place as idea's mature through to delivery https://jpattonassociates.com/dual-track-development/

Dilbert Cartoon - https://dilbert.com/strip/2017-07-26