Integrating Agile Practices with Architecture: Five Practical Recommendations

Your Primary Deliverable Is Your Decision

One common criticism of architecture in the agile community stems from the misconception that an architect must deliver a static "architecture document," whereas the Agile Manifesto values working software over documentation. In reality, an architect identifies high‑risk or high‑cost concerns, evaluates options, and makes context‑driven decisions, delivering a decision flow rather than a document.

Maintain a Backlog of Architectural Concerns

In agile environments, architects lack a pre‑approved, fixed specification set. Instead, they use a product backlog to capture and continuously reprioritize architectural concerns, allowing flexibility to address new business needs and insights.

Let Economic Impact Drive Your Focus

Prioritizing backlog items based on economic impact—risk and cost—helps determine which concerns are most important. Assessing the potential financial effect of a concern provides a clear indicator of its architectural significance.

Figure 1 – The architect’s daily work: an "architectural micro‑cycle" where the architect observes concerns, enumerates options, and decides the best action based on context.

Keep Architecture Small

Large architectures are hard to change; excessive decisions become a burden when conditions shift, limiting team design space.

Understanding the entire architecture is necessary to guard its conceptual integrity; too many details obscure the big picture.

In plan‑driven projects, architecture milestones mark code integration points, and the amount of upfront design depends on scale, importance, and volatility. Larger, more complex solutions require more upfront design, while highly changeable environments benefit from less.

Deliver Sufficient Expectations

Architects decide the appropriate scope of architecture by delivering enough expectations before solution development. Tools such as dependency analysis, technical debt control, and economic evaluation (e.g., Net Present Value) help determine the right amount of foresight.

Use dependency analysis to identify required architectural components for upcoming user stories.

Control technical debt to avoid structural degradation that hampers agility.

Consider economic factors to justify timing of architectural decisions, involving product managers and operations staff.

Scaled Agile Framework (SAFe) uses the runway metaphor: the runway expands to accommodate new “aircraft” (features) based on dependency analysis, while temporary materials represent technical debt that must be repaid. All decisions—when to expand or repave—are grounded in sound economic reasoning.

These five recommendations can be applied in Scrum and other agile methods, as well as in plan‑driven contexts, ensuring architects address the most critical concerns and use risk‑ and cost‑driven prioritization to maintain a minimal yet sufficient architecture.

References

J. Tyree and A. Akerman, “Architecture Decisions: Demystifying Architecture,” IEEE Software, vol. 22, no. 2, 2005, pp. 19–27.

M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 6, 2003, pp. 11–13.

B. Boehm, “Architecting: How Much and When?,” in Making Software: What Really Works, and Why We Believe It, A. Oram & G. Wilson (eds.), O’Reilly Media, 2010, pp. 141–186.

N. Brown, R.L. Nord, and I. Ozkaya, “Enabling Agility Through Architecture,” CrossTalk, vol. 23, no. 6, 2010, pp. 12–17.