Is solution architecture compatible with agile?

Agile software development methods emerged in the 1990s as a reaction to the failure of waterfall which was too slow with too much regulation, planning, micromanagement and documentation. Waterfall, it seemed, moved so slowly that by the time any software was released, the customer needs had moved on - and so had the business environment.

The Agile Manifesto^[1] was produced in 2001 to bring together some of the main principles common amongst Scrum^[2], XP^[3], DSDM^[4], UP^[5] and others by their A-list proponents during a legendary weekend at a ski resort in Utah. The manifesto is typically light on documentation, containing only 68 words and is a statement of belief rather than a methodology in itself. The core is a mere 24 words:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

What about solution architecture though?

In 2001, solution architecture was not a big part of the conversation among many software development practitioners. Architecture frameworks, such as Zachman^[6] and TOGAF^[7], and standards such as ISO 42010^[8] were available but were mainly of interest to industry giants. However, interest among all organisations has grown exponentially in the last 20 years - perhaps, in part, as a reaction to the perceived failings of agile, aka ‘fragile’, to deliver what the business needs in a sustainable way.

Solution architecture, like agile, has traction because of deficiencies in existing methods of solving problems purely with software, predominantly where the focus is too narrow or localised to be fully integrated. This is separate from the heavy vs lightweight battle addressed by agile.

Solution architecture is holistic both in its approach to identifying problems, risks and opportunities and in producing high level, component-based designs that integrate with the business in its current state and flex over the medium term as strategy and environment dictate. Software alone is rarely the solution. Even pure tech companies need people and other aspects of the real world to succeed.

What solution architecture brings to the table is a way to avoid unforeseen side effects and dead-end changes, both of which are unfortunately possible even when using agile.

How well does solution architecture score against the agile manifesto checklist?

Ok, there is a lifecycle with processes, tools and techniques^[9] but these are simply there to facilitate and strengthen interactions between individuals, especially customers.

Documentation is minimal and just-in-time, with nothing being prepared before it is needed and with just enough detail to move forward. Solution architecture does not deliver software but it does produce working designs that act as a blueprint for change and integration.

Contracts are not used in solution architecture; rather, customers have the power to approve and make changes to designs at all stages. Even the final design does not dictate a fixed plan for delivery but rather a roadmap that works with agile (especially Scrum) or any methodology that is deemed appropriate - even waterfall!

Can solution architecture be done in an agile way?

Yes, it is based on an evolutionary cycle that allows for trial and error, with fast failure for designs that don’t work for customers or have too much cost or negative impact.

Where would solution architecture fit in an agile lifecycle?

The main overlap is the roadmap which provides the interface between design and delivery-solution architecture provides the design and agile is the methodology for delivery. Whenever a roadmap is required, solution architecture can be used to build it.

Most agile teams speak about the delivery of a product based on a roadmap which informs the product backlog. The use of the term ‘product’ is being gradually superseded by ‘solution’ which covers products, services and combinations of the two.

An agile roadmap is a ‘schedule of events and milestones, according to SAFe^[10] so the business can see what it is getting and when. In addition to providing a reliable method for producing the roadmap, solution architecture links the deliverables and benefits that the business understands, directly to the solution components that enable them, therefore acting as a fulcrum between business and technical change. Any future changes to the roadmap can be instantly linked to the design and vice-versa, with impacts easily identifiable in both directions.

Is solution architecture always a good fit for agile?

The slightly surprising answer is ‘no’. There are at least two scenarios where agile should go it alone. One is where the situation is simple and the solution obvious. Agile can quickly make a change for the better and there are unlikely to be knock-on effects on the rest of the business.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

At the other end of the scale, the situation may be so complex that a component model can’t get to the bottom of it. This involves much more risk but agile can be used to make small, incremental changes, based on the judgement of business leaders - and then assess the outcome of each change - before deciding how to progress.

The sweet spot for solution architecture with agile is in the 80% of cases where a business needs positively transformative change delivered in the short term, with a progressive roadmap for the medium-to-long term.

What’s the future for solution architecture and agile?

Well of course the future’s always hard to predict but the recent direction of travel has been inexorably towards the business having more control over business and IT change. That could mean strategic tools such as those of solution architecture becoming more widely used, depending on the culture and appetite for risk within the organisation. Frameworks such as SAFe emphasise the need for business solutions to follow strategic themes within an overall portfolio vision, without specifying how this is to be achieved. Solution architecture can be used to capture the business vision and design one or several solutions around it.

Why isn’t solution architecture on the academic curriculum?

There are a few possible reasons such as the general lack of knowledge of the subject within the development community, meaning the demand isn’t there. On the supply side, universities and colleges are quite conservative about introducing new topics into courses, especially at undergraduate level. Then, there is the question of where such a topic would fit in: would it be better as a final year undergraduate module, part of a master’s degree, or fully integrated throughout?

When would be a good time in a career path to learn about solution architecture?

This is a debate that has been going on at BCS relating to the restructuring of the solution development diploma. In the industry, architecture has been seen as an advanced area, with the term being added to job roles to make them a promotion from lower grades. It seems that everyone wants to be an architect these days!

Many think that solution architecture is something you can only do after years of toiling as a developer, tester or other entry level team role. Even if this were true, the design focus of solution architecture is surely something that all team players would benefit from knowing something about. After all, IT undergraduates learn about all roles - from coding to project management.

A more radical and ‘architectural’ way of thinking might put solution architecture at the core of all the other disciplines of solution development. Developers, data designers, business analysts, change managers, security specialists and others are ultimately producing components that must integrate with each other and the operating environment. The components and their interfaces are the stuff that test plans and scrips are made of. This analysis would suggest that solution architecture should be fully integrated into undergraduate degrees with possible future advanced study pathways, rather than as a ‘bolt on’ to existing courses.