In the agile software development pactices the importance of designing the sofware system architecture is often seen as embedded into other development activities, and not as explcit as it has been in the traditional software engineering discipline (which has been developed taking inspiration from the previous engineering disciplines, especially from civil engineering).

Although the software system architecture can be developed in various ways, there are some implications if this happens incrementaly and is driven by random stream of requirements.

So what's the relationship between architecture and agile methods, if there's any?

If we take the definition of (system) architecture adopted by many standards organizations, which is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI/IEEE/ISO 42010), then we could rest assured, that whatever is the method or way of developing the software system, it will always have an architecture – that is, architecture will emerge when we develop the software system.

From the studies of the different styles of software architecture we can see that software systems, that peform the same function, can have rather different architectures – so why to bother?

The problem is raised, because apart form the function that software system performs, we often are interested of some other properties of the software system (usually specified as non-functional requirements towards the software system), and because software system architecture is the cause of many important properties of the software system, which are usually requested by several stakeholders.

The core of the agile methods is to design and build the software systems piece-wise, but while the functionality of the software system is usually possible to divide into pieces or decompose rather easily, the software system architecture, being a set of global structures, affecting the software system as a whole, does not lend itself to such treatment. Usually some global structures, that define the software system architecture need to be first developed and completely built (at least up to certain level of completeness), to be able to implement the pieces of the functionality (i.e. system functions).

SAFe represents the larger pieces of the system functionality (or system functions) by the capabilities, which themselves can be decomposed into smaller pieces of functionality, called features (see Features and Capabilities in SAFE).

Admitting the insufficiency of the emerging architecture alone and agreeing to the need for the intentional architecture of the software systems, SAFe proposes an Architectural Runay as implementation of software system architecture (i.e. the code and infrastructure needed to implement the features), which can be itself evolved/extended by implementing the Enablers.

So far so good, but to be able to divide the work so that we can build first just a part of the software system architecture, needed for a set of features, we need to be able to map these features onto the software system architecture, for which we need the full architecture designed first.

Therefore, in the best case, we can build the implementation of the software system architecture piece-by-piece, but before that we need to design it as a whole. Another slight complication is the global nature of the software system architecture structures – if for any reason we need to change the software system architecture in such a way that is not supported by the extension mechanisms of the existing architecture of the software system, we need to implement the new software systems architecture an then re-implement/-build all the features that have been built so far (because the system architecture defines how the features are built). All development teams try to avoid later as long as possible, as a very costly exercise.

Another complication arises from the fact that, if the overall software system will be designed and developed incrementally as a response to the stream of requirements stated by the stakeholders, the software system architecture will very much depend on the order in which these requirements arrive.

For example if we build the communication system (e.g. a chat system) and the requirement for high security of personal information and communications is received within the first requirements, this might lead to the selection of an architectural style of independent components, where none of the components has complete knowledge of all the users and communications within the system, but if this requirement is not received early enough, then it would be natural to select the architectural style with central reporsitory for users and communications.

When now the requirement for high security of personal information and communications arrives, there could not be possibility to completely re-implement the system according to different architectural style, and therefore architects might select compensating techniques, adding encryption fo a central datastore, leaving the architecture of the system same (which will not meet the requirements in best possible way).