Software architecture is the design decisions that are done upfront and that it will be costly to change once the software is being developed. Therefore, it is important to do a detailed requirements elicitation and analysis to identify what are the desired system qualities. How does it fit with an agile approach, where it is emphasized that the structure emerges from a set of implemented cases? Is architecture and refactoring inconsistent? Maybe on paper, but in reality there are several nuances.
First, although agile approaches focus on the added value of increments, e.g. sprints add value to the product, it actually starts from an existing architecture, in XP called a system metaphor. It is naive to think that architects design their architectures from scratch. They already have a considerable knowledge about problems, their solutions, and the existing technologies that support them. Experienced architects can craft an architecture by putting together these technologies and define a system metaphor around them. Afterwards, development is done in the context of the metaphor by filling it with functionality and evolving it by refactoring.
Second, if it is the case that the system qualities are not anymore supported by the metaphor it is necessary to change the architecture which may require a lot of effort. However, the system evolution is driven by requirements that emerge from the shortcomings of the existing architecture. Therefore, the metaphor for the new architecture emerges side-by-side with the new requirements, and, though, it may be necessary to rewrite a large amount code, the system evolution is a consequence of the system success.
When it is not possible to develop a complex and innovative system by successive evolutions the agile approaches may not fit because the design of the architecture must be done in a single step, aiming for the more demanding qualities. However, it may be arguable whether such approach is a winning one.