Architecture is still critical to successful IT delivery, but must change to suit an Agile world

There’s a plethora of advice you could wade through on how to approach architectural development in an agile way (just Google ‘agile architecture’). But to save you time, we’ve distilled our experience as hands-on developers, architects and Agilists into this set of guiding principle.

Define the Architecture Vision and building blocks up front

Successful Agile deliveries start from a strong foundation that determines key design decisions, sets the technical direction, and aligns to key constraints like scope, budget and timescales, while avoiding ‘Big Design Up Front’.

The architectural vision is the alignment of IT capabilities to longer term business goals and strategic objectives. In Agile architecture, this vision needs to be flexible enough to balance the organisation’s goals with the need to deliver immediate value. This vision is used to create architectural principles that IT projects are evaluated against, letting stakeholders make key design decisions. This can help avoid costly problems, like when a short-term ‘tactical’ solution becomes long-term.

You should start by setting out the key architectural principles for your project. You can then use these to produce concise documents and diagrams that show system boundaries, core components, interfaces and core data relationships.

Socialise the architecture

It’s critical for IT architects to continuously communicate and collaborate within and across teams to ensure a common understanding.

Our experience shows that using a variety of methods is necessary to cater for different audiences and organisational cultures. Ideally, architectural work should be displayed around the office and feedback encouraged. On one project, we created posters and displayed them around the project team area. They were useful in explaining the system to business users, particularly as they linked the business process to the applications.

Develop architecture in thin vertical slices

Start by building a small piece of the system that may not deliver much business value, but proves the end-to-end technology. This is sometimes referred to as a ‘walking skeleton’ and lets you easily and repetitively add layers (called slices) that ‘flesh out’ the solution to deliver its full business value. This helps cut the risk of dependencies between components, and lets business functionality and technical architecture evolve in parallel.

A great example of this is when we developed a complicated application for a large UK retailer. We found the login functionality cut through the majority of the system but was small enough to build and test very quickly, letting us prove the end-to-end technical architecture. This meant the rest of the development could deliver additional functionality to flesh out the technical implementation.

Allow architecture to ‘emerge’, but within agreed boundaries

Agile projects embrace change, so architectures must evolve accordingly, but only within the constraints of the Architecture Vision (principle 1).

This is a balancing act. Letting developers influence architecture is powerful, but we’ve seen teams with no architecture involvement that have hit a wall when they try to go live. This is where the agile architect adds value. As a respected voice in the organisation, they can communicate with all stakeholders to balance the tension of rapid evolution against the architectural constraints.

Architects must work within and across sprint teams

As the ‘technical product owner’, architects must bridge the gap between customer requirements and technology capabilities. This means working closely within sprint teams to ensure quality output, but also looking across them to align with the Architecture Vision (principle 1). Often this means a healthy but heated debate with developers.

This works well at one of our financial services clients where there are ten scrum teams with an architect aligned to each. Their main responsibility is to define the intentional architecture, looking ahead to medium and long term goals for the team, while ensuring designs are coherent across the whole system.

Look ahead, but delay commitment

Accurately predicting the future is notoriously difficult, so avoid making decisions that are difficult to reverse until it’s really necessary.

Options should be identified early, but keep in mind early ideas don’t always develop as expected. That means you’ll need to review iteratively and be prepared to change direction. On a recent project, we were planning to integrate cloud API management software, but a commitment to a particular platform was delayed until the business needed to publish an API to ensure we had the best solution.

Prioritise based on risk

Tackle risky items early where the cost of a wrong decision is high. Where risks are relatively low, experiment, explore and fail fast.

Don't let architecture constrain experiments - teams should use the quickest (and sometimes the dirtiest) solutions to experiment and prove business value. Only limit design after you’ve decided to build. Of course there are many types of risk, so don’t just focus on the technical – business design and data layers can also carry risk.

Prove architecture with code

Implementation often reveals aspects that hadn’t been thought of. Prototypes and proofs of concept are very useful where there’s uncertainty. This is where the architect-as-technical-lead works alongside the developers to produce the build.

By rapidly building prototypes to demonstrate or prove technical capabilities, you can provide real-world proof when selecting vendors or making technology choices that a paper exercise can’t compete with.

Architecture should be driven by the backlog

Avoid scope creep where solutions cater for non-essential or possible future requirements that may never materialise.

One architect used to enjoy using the phrase “while the bonnet is up” to justify trying to address unrelated requirements affecting the same components. Although this was well-intentioned, the project was later canned due to unforeseen overspend.

Write ‘just enough’ documentation, just in time

Too many Agile teams neglect documentation, which becomes increasingly problematic at scale. Document as you go and tailor it to the needs of the audience.

It takes some cultural adjustment, but minimising documentation to exactly what is needed, and only updating it when it ‘hurts’, typically leads to greater collaboration and more focus on end-user value. Some Agilists say you don’t need any documentation and that ‘code should be self-documenting’. Our view is that documentation is there as a communication tool and not everyone can code. For a system to succeed, you need people who value and care about what you’re delivering. The pain point is when your organisation and users, external to the development team, don’t understand what you’re doing or why. Documentation then becomes essential to communicating the value you’re delivering.

In a world of Agile delivery, IT architecture has a huge amount to offer. The key is to innovate and adapt your approach, aligning to business objectives and outcomes to ensure the programme succeeds and creates value.