One of the main themes of Lean is “Just Enough.” For instance, “Just In Time” work, and “Just-Enough” decision-making (not anticipating too far past the current stage of an effort and what is known, where possible).

Agile architecture is the “Just Enough” of structure, both as a system’s structure relates to the environment outside it (i.e., to the systems interacting with its boundary) and its internal structure. The latter, however, is only addressed by architecture when internal structure will impact overall system capability.

Agile architecture involves:

• Defining a vision for the role the system will play among the systems and environment surrounding it, and making it as easy as practical to place the system into that environment and for it to be effective there
• Providing a way to pursue future opportunities and respond to new needs without having to replace the system or incur crippling technical debt because its structure is ill-suited to the new situation. Maximizing the ability to incorporate learning.
• Heading off whole classes of defects and problems the system could otherwise experience in its environment (e.g., adding “failsafe” structures, or excluding development options known to lead to certain types of errors)

To accomplish these, an architecture can specify structures like interfaces, layers, and information-hiding conventions, as well as constraints on how the system will be implemented such as disallowed design or even very occasionally low-level things like programming constructs.

The key difference between Agile architecture and traditional architecture in all these areas is, in traditional architecture these specifications go overboard and end up working against the goals of architecture listed above. For instance, constraining the system beyond what was absolutely necessary can limit the ability of the system’s implementors to deal with unanticipated future needs.

In Agile architecture, those responsible for the architecture (often an Application Development Manager, or a System Architect) have an additional responsibility beyond those listed above: To limit structural requirements and constraints to the bare minimum needed to maximize the system’s ability to accommodate the legitimate concerns of architecture.

Resources about architecture

Decomposing an MBI into Features (Article)
How Will Architectural Capabilities Be Handled? How Will Architecture Be Prioritize Against Business Needs? (Article)
Program Level (Article)