An Overview of Agile Architecture and the Architecture Runway.

Incremental development methods provide value by providing regular delivery and have been shown to
have project success of over 25% when compared to phased gate approaches [1]. However, architecture
has been a challenge for iterative and incremental delivery methodologies as misalignment in feature
delivery and architecture design can induce high refactoring costs.

IEEE defines software architecture as “Fundamental concepts or properties of a system in its

environment embodied in its elements, relationships, and in the principles of its design and evolution”
[2]. From the book Software Architecture in Practice we get the following definition “The software
architecture of a program or computing system is the structure or structures of the system, which
comprise software elements, the externally visible properties of those elements, and the relationships
among them.” [3]. Traditional software architecture practices involving Big Up Front Design (BUFD)
which cannot be integrated into the Agile practice as increasing the time for architectural development
impacts incremental value delivery and runs counter to Agile principles. However if the architecture is
overly flexible it will lead to rework and over production [4] [5].

SAFe provides the concept of the architectural runway which marries the two concepts of emergent
design and intentional architecture. In this system the architect builds intentional architecture at a high
level whereas teams provide a feedback loop through emergent design. Together they provide value for
iterative delivery, robustness and architectural direction. According to SAFe the following principles
define the approach to Agile architecture [6]:
1. Design emerges. Architecture is a collaboration.
2. The bigger the system, the longer the runway
3. Build the simplest architecture that can possibly work
4. When in doubt, code or model it out
5. They build it, they test it
6. There is no monopoly on innovation
7. Implement architectural flow
The architectural backlog for the runway is developed from the architectural analysis of requirements,
the context and constrains of the system under development, architectural assets and other business
drivers like mission statements and budgets. Building an architectural runway can involve preparation
ahead of the cadenced activities for example the DSDM feasibility process [7] or pre-Sprint story review
[8] . In SAFe this activity is part of the Program Increment (PI) with key activities that include conceptual
and logical architecture to define high-level logical architectural diagrams and outline key system
components and their interfaces. Irrespective of the size of the project the Architectural Runway should
be able to provide agile architecture for the teams to consume as they work on delivery [6]. Dean
Leffingwell recommends the initial design should be done using a component based architecture [9].

Architecture activities across its lifecycle generally include Architectural Analysis, Synthesis, Evaluation,
Implementation and Maintenance and Evolution [10]. In Agile architecture these activities can be
modified to start with an initialization phase followed by an Analysis, Synthesis, Evaluation loop.
Maintenance and evolution can lead to new functionality by using the same loop as described in figure 1
[11] :
Figure 1 A Model of Software Architecture Process

Key design considerations include determining the application type, deployment strategy, appropriate
technologies, quality attributes and crosscutting concerns [12]. The outputs from these activities are a
technology stack, design patterns, quality attributes and documentation that may use views based
approaches e.g. 4+1.These outputs act as communication points between the architecture and
development teams during planning, storyboarding, sprints and integration points.

At the Sprint level the architect can assist the PO and team select appropriate tasks that are aligned with
architectural boundaries based on architectural functions to ensure that the speed of delivery is not
hampered by rework due to complexities arising from the design. The Agile architect also needs to
ensure that key stakeholders like the product owner understand the importance of system design
refactoring and quality attributes to ensure that architectural elements are not given a lower priority.
This can be accomplished by maintaining a separate architecture backlog and regular communication
between the architect and the stakeholders.

Some of the tools to improve the analysis, synthesis and evaluation of architecture design include flow
management, modeling, refactoring and quality attribute assessments. Kanban flow management can
provide visibility into architecture activities. Enforcing re-architecting WIP limits and capturing
significant requirements as acceptance test cases on the Kanban board allows for visibility into design
complexity by allowing greater insight into the costs related with rework [13]. Models also work well
within Agile when they are developed using stories and code. Models allow exploration and refactoring
of code, clarify user needs at separate stages and communicate various aspects of code [14]. Architects
can embrace change by alternating design activities with assessment and refactoring, with refactoring
occurring once per iteration. Refactoring introduces improvements in architecture without major
changes to the intentional design [15].

Assessment methods include Quality Attributes Workshops (QAW) and the Architecture TradeOff
Analysis Method (ATAM). QAW is used to discover quality attributes before the process of design while
ATAM is used to review the architecture to assess the suitability of the design to the business drivers. A
lightweight ATAM [16] allows for assessing quality attributes within a half day and can be incorporated
into the pre-Sprint story review cycle. Lightweight ATAM assists in mitigating architectural complexity by
evaluating quality attributes, which generally fall under the following:

 Prioritized statement of quality attributes

 Mapping of approaches to quality attributes
 Risks.

ATAM generates a catalogue of architectural approaches, analysis of approach vs quality attributes and
tradeoff points. This assessment allows for aligning the architecture with the business needs and
provides insight into the complexity of the design [17].
Architectural processes and methodologies do not necessitate a BUFD. Traditional architecture
approaches and tools can be modified to work within the Agile world. An architectural runway
composed of intentional architecture and emergent design combined with flow management, regular
assessment, modeling and refactoring can provide value within incremental software delivery methods.
References

[1] K. Adams, "Adopt Scrum for Competitive Advantage," 19 OCtober 2015. [Online]. Available:
https://www.scrumalliance.org/community/articles/2015/october/adopt-scrum-for-competitive-
advantage.

[2] ISO/IEC/IEEE/42010, "System and Software Engineering -Architecture Description," ISO and IEEE,
Geneva, 2011.

[3] C. K. Bass, Software Architecture in Practice (2nd edition), Addison-Wesley, 2003.

[4] I. O. R. S. S. Robert L. Nord, "Making Architecture Visible to Improve Flow Management in Lean
Software Development," IEEE Software, pp. 33-39, October 2012.

[5] R. L. N. I. O. Nanette Brown, "Analysis and Management of Architectural Dependencies in Iterative

Release Planning," in Proceedings of the Ninth Working IEEE/IFIP Conference on Software
Architecture (WICSA), Boulder, 2011.

[6] D. Leffingwell, "Agile Architecture Abstract," [Online]. Available:

http://www.scaledagileframework.com/agile-architecture/.

[7] Agile Business Consortium, "The DSDM Agile Project Framework (2014 Onwards)," [Online].
Available: https://www.agilebusiness.org/content/products.

[8] N. Malik, "Placing Architecture Properly into Scrum Processes," Microsoft, 11 June 2013. [Online].
Available: https://blogs.msdn.microsoft.com/nickmalik/2013/06/11/placing-architecture-properly-
into-scrum-processes/.

[9] D. Leffingwell, Scaling Software Agility, Boston: Pearson Education, Inc. , 2007.

[10] K. P. N. R. O. H. R. A. e. a. Hofmeister C, "A general model of software architecture de-sign derived

from five industrial approaches," J Syst Software, vol. 80, pp. 106-126, 2007.

[11] M. A. babar, "Making Software Architecture and Agile Approaches Work Together: Foundations
and Approaches," in Agile Software Architecture Aligning Agile Processes and Software
Architectures, Waltham, Elsevier Inc, 2014, pp. 1-18.

[12] Microsoft Developer Network, "Chapter 2: Key Principles of Software Architecture," [Online].
Available: https://msdn.microsoft.com/en-us/library/ee658124.aspx.

[13] R. L. N. a. I. Ozkaya, "Flow Management in Lean Software Development," IEEE Software, no. 12, pp.
33- 38, 2012.

[14] A. C. Wills, "Modeling in an Agile Context," The Architecture Journal, no. 23, pp. 38 -43, 2010.
[15] M. Stal, "Refactoring Software Architectures," in Agile Software Architecture: Aligning Agile
Processes and Software Architectures, Waltham, Elsevier Inc, 2014, pp. 63 - 82.

[16] R. K. Humberto Cervantes, Designing Software Architectures: A Practical Approach, Addison-

Wesley Professional, 2016.

[17] R. K. M. K. Paul Clements, Evaluating Software Architectures: Methods and Case Studies, Pearson
Education, 2001.