… with proper design, the features come cheaply. This approach is arduous, but continues to succeed.
System Architect Abstract
The role of architecture—and correspondingly, software architects—is still mildly controversial in some agile circles. There is no specific role defined in Scrum and XP, and most agile books are quiet (sometimes even pejorative) on the topic. In the context of the larger software enterprise, however, we take a different view. Just as content authority (what the system is to do) must be be put in place via an extended Product Owner/Product Manager/Portfolio management team, design authority for Portfolio and Program technological decisions (how the system is to do it) must also be put in place at scale.
To this end, the Framework identifies two specific roles for software architects: 1) the Enterprise Architect, depicted at the Portfolio Level, operates across Programs and has the responsibility to help assure that the IT/software development strategies and technologies are aligned with the evolving business needs of the enterprise; and 2) The System Architect operates within Programs, and has the responsibility for maintaining a high level understanding of the user’s vision for what the subject system needs to do, as well as maintaining and evolving an understanding of the implementation framework necessary to support current and upcoming user and business needs.
The System Architect works in daily collaboration with the Agile Teams, often focusing on design decisions that must be made now to support future features maturing in the Program Backlog. These can include new architectural Epics and Features as well as common governance items such as standard databases, protocols, web services, and Nonfunctional Requirements such as performance, scalability, regulatory requirements and others. However, as we will describe in the details below, the system architect’s role, responsibilities, and the manner in which those responsibilities are fulfilled, must evolve to facilitate the emergence of the truly lean and agile software enterprise.
Summary Role Description
While the “best requirements and designs emerge from self-organizing teams” (Agile Manifesto), the System Architect plays a unique role on the program team by understanding stakeholder needs, and helping the teams define and implement a technological solution suitable for hosting current and upcoming features, while conforming to evolving nonfunctional requirements.
In SAFe, System Architects typically fulfill the following primary responsibilities
- Work with customers, stakeholders, Product Managers and Product Owners to understand and maintain a high level understanding of the current and upcoming requirements for the system
- Understand and communicate the Nonfunctional Requirements for the system
- Evaluate design alternatives, and perform cost benefit analysis
- Develop and maintain whatever models and documentation are necessary to describe how the system does what it is intended to do, including recommended Domain and Use Case Models (see below)
- Define and split architectural Epics into Features for the Program Backlog, and allocating respective items to the individual Team Backlogs for implementation
- Present the technological Vision for the solution during PSI/Release Planning, provide domain models and exemplary use cases that describe larger system behavior, and participate actively and interactively during the PSI planning process
- Serve as a resource to help the teams make appropriate system and component level design decisions during implementation
- Work with Enterprise Architects at the Portfolio Level to establish Architectural Runway in support of upcoming user and business needs
What’s Different in Agile: Principles of Agile Architecture
While many of the responsibilities defined above are consistent with those of traditional software development, the manner in which these responsibilities are fulfilled is different. No longer do system architects have the authority to dictate designs to the Agile Teams, as doing so would eliminate the empowerment and accountability that is the basis for the agile Program dynamic. Instead an architect must be an advisor and facilitator to the teams and product owners, mentoring, coaching, guiding and collaborating with them to reach design decisions that are supportive of the current —and near-term future—state of the system. The following set of seven governing principles (adapted from reference , or “ASR”) to guide enterprises down an agile path:
Principle # 1 ─ Design emerges. Architecture is a collaboration.
Principle # 2 ─ The bigger the system, the longer the runway
Principle # 3 ─ Build the simplest architecture that can possibly work
Principle # 4 ─ When in doubt, code or model it out
Principle # 5 ─ They build it, they test it
Principle # 6 ─ There is no monopoly on innovation
Principle # 7 ─ Implement architectural flow
For an in-depth discussion of these principles, refer to ASR . However, the last principle, implement architectural flow, is unique to SAFe and the implications of this principle are worthy of further description here.
Implementing Architectural Epics and Features
In the same way that User Stories represent small, value objects that can be implemented incrementally, architectural Epics and Features behave largely the same way. They are defined, prioritized and implemented independently and incrementally. In addition, teams must do so in the context of continuous product development flow, as the long, waterfall-branch-and-merge strategies for architectural change are a thing of the past. Doing so requires new thinking, tools, and strategies that help make the upcoming work visible, and also provides for staging, prioritizing and analysis of these items before they reach program implementation boundaries. This can be assisted by the implementation of a kanban system for architecture, which is described within the framework and ASR .
Patterns of Incremental Implementation
In addition, actual implementation of the system must assure that the system always runs, or at least at a bare minimum, does so at PSI boundaries. In ASR  we described three architectural change implementation patterns that can be used to achieve this, which are summarized below.
Pretty big and incremental, the system always runs. In this, the ideal-pure-agile case, architectural work is divided into small value added pieces that are implemented within iterations, thereby assuring that the system is always available at these boundaries, and even more ideally, every day in between.
Big and not entirely incremental, the system takes a short break. Sometimes, the nature of the change and/or the economics makes approach #1 not feasible. In this case, rather than branching, or further subdividing architectural work in to smaller pieces (though preferred!), the teams perform major architectural work in the mainline during the PSI, during which the system may not be fully functional, but always completing the work in such time as to host the new features on the updated system by the end of that PSI.
Really big and not totally incremental, the system runs when needed; do no harm. Failing that, really big architectural work still has to be done in the mainline in real time, but the teams use whatever scaffolding and stubs are necessary to achieve solution integrity such that the system runs at PSI boundaries, but without completion of the entire initiative. In this way, the new architectural elements can be tested with existing and new regression and performance tests, and yet the value features, or the remaining architectural underpinnings, await implementation in future PSIs.
Splitting Architectural Backlog Items
No matter the pattern selected, in a manner similar to splitting user stories to fit in sprints, architectural epics and features must also be split to deliver their value in incremental, smaller parts. ASR  elaborates eight specific patterns to consider for splitting architectural epics and features, including partitioning by subsystem, component or product, achieving system qualities incrementally, implementing functionality incrementally, using scaffolding, splitting into major/minor effort, doing complex operations first, splitting by variations in data, and using spikes as appropriate.
Recommendations for Agile Modeling
A typical program (Agile Release Train) can contain a significant number of teams (as many as 10-15 is not unusual) who are collaborating on building a large and complex, enterprise-class system. Doing so incrementally is the art of agile at scale. Doing so incrementally requires the continuous splitting of value items— epics, feature and stories—into smaller and smaller independent objects for incremental implementation. That is all well and good up to a point. However, by the time a small story reaches an iteration, the larger understanding of the system can start to break down. To this end, we recommend agile modeling techniques be used to create context and aid understanding. Specifically, we recommend the development and maintenance of a domain model and use case model for each subject system. While the full scope of these models is outside the scope of the framework, we highlight them here as a pointer to further understanding.
Domain Model. One agile method, Feature-Driven Development (see references  and ) achieved some popularity for a time. One of the eight best practices of that method was domain modeling, which is the primary container for system architecture concepts. The domain model describes the system from the perspective of the real world objects (people, devices, other systems, other entities) that the system must support. It is used to identify the relevant objects in the system, as well as the static and dynamic elements of system behavior. As such the domain model gives a “big picture” view of the system as a whole, and provides important context for all who implement the system. For this reason, many programs find the development, maintenance and communication of the domain model as an important element of their agile process.
Use Case Model. In ASR  and , we also described Use Cases (originally defined in the context of the Rational Unified Process and the Unified Modeling Language) and the Use-case Model as highly useful tools to understand the behavior of the system and its interactions with its users, devices and other systems. Cockburn  (also a signer of the Agile Manifesto] has applied use cases extensively in the agile context. In addition, Chapter 19 of ASR  is dedicated solely to this topic. The use case model provides the context for all the user stories that are implemented individually, as well as elaborating how the features of a system achieve the users larger objectives. It also serves as the requirements model on which the system design can be based. Individual use cases can be used to describe larger end-to-end behavior, and main and alternate success scenarios are a primary mechanism for discovering and implementing user stories.
In our experience, the development, maintenance and communication of these two models can greatly benefit an agile program, as without them, a variety of hidden assumptions can create misunderstandings that exhibit themselves as errors in system design or behavior. A system architect who can develop these models, and can do so in accordance with the agile principles espoused above, will be a real asset to any agile program and will be very well received by the teams who are ultimately responsible for the solution.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.chaps. 18, 19.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. chap 16.
 Palmer, Steve, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, 2002.
 Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
Last update 15 January, 2013
© 2010-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.