Details

system architecture

Summary Role Description

While the “best requirements and designs emerge from self-organizing teams” (Agile Manifesto), the System Architect plays a unique role on our team of Agile Teams. the Agile Release Train , 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 . 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.

Responsibilities

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
  • Present the technological Vision for the solution during Release Planning. provide domain models and exemplary use cases that describe larger system behavior, and participate actively and interactively during the 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 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 seven governing Agile Architecture  principles are intended to guide enterprises down an agile path.

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 SAFe and ASR [1].

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 Program Increment  boundaries. In ASR [1] 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 into smaller pieces (though preferred!), the teams perform major architectural work in the mainline during the PI, 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 PI.

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 PI 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 PIs.

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 [1] 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 ART can contain a significant number of teams 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 [2] and [3]) 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 [1] and [2], we also described Use Cases 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 [4] (also a signer of the Agile Manifesto] has applied use cases extensively in the agile context. In addition, Chapter 19 of ASR [1] 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.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.  Addison-Wesley, 2011.chaps. 18, 19.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises.  Addison-Wesley, 2007. chap 16.

[3] Palmer, Steve, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, 2002.

[4] Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.

Last update 22 July, 2014

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.

Information on this page is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, visit the Permissions FAQ and Form .

Similar articles: