Relax. There's no conflict between architecture and agile.
It's not always obvious how architecture fits in with self-organising agile development teams. Architecture has become associated with "big design up front" and large-scale abstract thinking in “ivory towers”. This is at odds with the iterative agile approach that delivers value in small chunks.
There needn't be a conflict here. An agile team still needs to make architectural decisions. They need to agree on the standards, protocols and technologies that the system will use. They need to decide what components to build and how they will collaborate. They also need to consider areas such as availability, security, scalability and performance.
These considerations do not go away when you organise development into agile teams. The question is more whether they are shared among developers in a team or invested in one person to provide a single point of responsibility.
Handling complexity
There is a perception that agile teams are self-contained groups of generalists who should be left alone to self-organise and build software. This seems to be advocated by the agile manifesto's principle that “the best architectures… emerge from self-organising teams.”
This is true, but there does come a point at which problems are too big for any one self-organising team to solve.
As Len Bass et. al. argued in "Software Architecture in Practice" (p.277):
We believe that the creators of the agile principles got it wrong. The best teams may be self-organizing, but the best architectures still require much more than this – technical skill, deep experience and deep knowledge.A story-based approach to requirements can encourage every feature to be individually designed and implemented. This can make it difficult to manage dependencies between features and identify any common concerns between different teams.
In larger systems this emphasis on delivering features early can lead to significant coordination problems. Too much agility can lead to chaos as problems get bigger and start to require the cooperation of many different teams. There need to be some design coordination to maintain a broad overview across all the features so they can be placed into the right context.
There's nothing in Scrum to handle this kind of cross-team complexity. Agile and Lean advocates talk about emergent design and delaying decisions until the "last responsible moment" but this is not a sufficient response to the complexity of large-scale development.
The Scaled Agile Framework recognises this and talks in terms of the need for “intentional architecture”. This is described as a set of planned initiatives led by architects to enhance system design and provide guidance for implementation. It's the balance between emergent design from teams and intentional design provided by architects that ensures system integrity over time.
How the architecture role changes in agile
A successful architecture is resilient and loosely coupled. It is composed of well-reasoned design decisions that provide sufficient “wriggle room” to allow change. This does not happen by accident. It needs to be driven by somebody who has the determination to ensure a certain level of design quality.
Architects can help to define the “rules of the road” that help to bind the teams together. There is a difference between software design and architecture as the latter is more about holistic design and considering how the systems work together as a whole. On a practical level this means defining the boundaries within which software design takes place.
It's important to note that architecture is not an elevated role. Agile organisations should not create a hierarchy that places architects at the top of the tree. It is a specialism that supports and enhances development.
An architect should be accustomed to winning support for their strategies through persuasion and natural authority. In the absence of any design committees soft skills become more important as architects do not have any direct control over teams. It becomes more of a "hands-on" role as writing code as part of a development team can help to build empathy and understanding.
How much architecture do we need?
Given that every agile project involves architectural decisions, how many architectural decisions need to be made up-front?
If you are building a very large and complex system with well understood requirements then more work can be done in advance. On the other end of the spectrum are smaller, more isolated single-team projects that need very little guidance. Most agile projects that involve architects fall somewhere between these two extremes.
It's important to note that an agile architect should be providing practical solutions for teams to build on rather than documents and diagrams. Scaled Agile talks in terms of an "architectural runway" that provides enough infrastructure to support high-priority features. Alistair Cockburn described a similar idea based on the "walking skeleton", which is just enough of a solution to demonstrate end-to-end functionality for a single vertical slice of the system.
There is no conflict between agile and architecture. The issue is more how best to blend the two. The focus should be on providing "just enough" architecture rather than "big design up front" and practical solutions over large-scale abstract thinking.