Agile Architecture Method
The Agile Architecture Method is a way to bake quality into the life cycle. It’s also an iterative and incremental approach for architecture and design. In its simplest form, it’s a way to help you identify potential hot spots against your prioritized scenarios. The hot spots are key engineering decision. The main hot spots are cross-cutting concerns, such as data access, exception management, logging … etc. and quality attributes, such as security, performance, reliability … etc. I first presented our Agile Architecture Method at the patterns & practices Summit. Since then, I’ve presented it to various customers and learned more on how to make it easier to use. This post includes my key learnings and refinements based on those discussions.
Candidate Architectures, Architecture Spikes, and Inspections
The Agile Architecture Method is a structured approach for helping you create your candidate architecture, identify relevant spikes and guide your inspections throughout your life cycle. During each iteration, you can use the frames to identify relevant intersections between your user stories and hot spots.
Agile Architecture Method in a Nutshell
To summarize, it’s a technique that:
- Scopes and focuses your architecture exercise.
- Uses scenarios to drive the design and evaluate potential solutions.
- Helps you think through your choice of application type, deployment, architectural style and technologies.
- Helps you quickly iterate through potential solutions.
- Helps you map potential patterns.
I’ve summarized the approach below, and we posted a step-step how to on CodePlex:
Here’s the key input into the process:
- Use cases and usage scenarios
- Functional requirements
- Non-functional requirements (quality attributes such as performance, security, and reliability)
- Technological requirements
- Target deployment environment
Here’s the key output of the process:
- Architecturally significant use cases
- Architecture hot spots
- Candidate architectures
- Architectural spikes
Summary of Steps
- Step 1. Identify Architecture Objectives.
- Step 2. Identify Key Scenarios.
- Step 3. Create an Application Overview.
- Step 4. Analyze Key Hot Spots.
- Step 5. Create Candidate Solutions.
Step 1. Identify Architecture Objectives
This is a scoping exercise. The purpose of this step is to figure out how much time and energy to spend on subsequent steps as well as guide your overall effort. You should know what you want in terms of outcomes. Here’s an example of potential goals:
- Build a prototype
- Identify key technical risks
- Test potential paths
- Share models and understanding
Step 2. Identify Key Scenarios
Identify relevant scenarios to focus your design on what matters most, and to evaluate your candidate solutions. In this case, you want to identify architecturally significant use cases. Architecturally significant use cases are those that meet the following criteria:
- They are important for the success and acceptance of the deployed application.
- They exercise enough of the design to be useful in evaluating the architecture.
You can draw key scenarios from your user stories, business stories and system stories.
Step 3. Create an Application Overview
Create an application overview. The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions.
An application overview consists of the following steps:
- Determine your application type. First, determine what type of application you are building. Is it a mobile application, a rich client, a rich internet application, a service, a Web application, or some combination?
- Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact this will have on your architecture.
- Identify important architectural styles. Determine which architectural styles you will be using in your design. Will you build a service oriented architecture, client/server, layered, a message bus, or some combination?
- Determine relevant technologies. Finally, identify the relevant technology choices based on your application type, architectural styles and deployment constraints.
A good test of an application overview is whether you can whiteboard it.
Step 4. Analyze Key Hot Spots
Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.
Prioritized Scenarios and Hot Spots
Your prioritized scenarios are input. Based on your scenarios, you can map which hot spots are relevant. You may be able to address the hot spots simply through experience, or through inspections, or you may need to spike on your choices.
Hot Spots for Architecture
The application feature frame represents cross cutting concerns that will impact your design across layers and tiers. These are also the areas in which high impact design mistakes are most often made. Use the architecture frame to identify hot spots in your design that require additional attention to get right. You can use the following architecture frame to identify cross cutting concerns in your design:
|Authentication and Authorization||
|Caching and State||
|Concurrency and Transactions||
|Coupling and Cohesion||
|Logging and Instrumentation||
Hot Spots for Quality
Understand the quality attributes that are important for your application and scenarios. For instance, most applications need to address security and performance and will be traded against usability, flexibility and other attributes that may be more or less important to you depending on your scenarios and requirements. You can use the following frame to identify key quality attributes to consider:
The following example show how you can frame a quality attribute and its hot spots. Although these examples only show security and performance, you can use the same approach for any quality attribute. The key is to identify the top hot spots, along with relevant issues, impact, and countermeasures.
Hot Spots for Security
Here’s a visual of common security hot spots:
You can use the security frame to help you identify potential hot spots for security:
|Auditing and Logging||Who did what and when? Auditing and logging refer to how your application records security-related events.|
|Authentication||Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.|
|Authorization||What can you do? Authorization is how your application provides access controls for resources and operations.|
|Configuration Management||Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.|
|Cryptography||How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.|
|Exception Management||When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?|
|Input and Data Validation||How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output through exit points. Do you trust data from sources such as databases and file shares?|
|Sensitive Data||How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.|
|Session Management||How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application.|
Here’s a set of additional resources you can use to help you evaluate your security hot spots:
- Security Frame
- Security Design Inspection Checklist
- Security Design Inspection
- Security Design Guidelines
Hot Spots for Performance
Here’s a visual of common performance hot spots:
You can use the performance frame to help identify potential hot spots for performance.
|Caching||Per user, application-wide, data volatility.|
|Communication||Transport mechanism, boundaries, remote interface design, round trips, serialization, bandwidth.|
|Concurrency||Transactions, locks, threading, queuing.|
|Coupling / Cohesion||Loose coupling, high cohesion among components and layers.|
|Data Access||Schema design; Paging; Hierarchies; Indexes; Amount of data; Round trips.|
|Data Structures / Algorithms||Choice of algorithm; Arrays vs. collections.|
|Exception Management||Where to validate; Whether to throw; Whether to catch.|
|Resource Management||Allocating, creating, destroying, pooling.|
|State Management||Per user, application-wide, persistence, location|
Here’s a set of additional resources you can use to help you evaluate your performance hot spots:
- Performance Frame
- Performance Design Inspection Checklist
- Performance Design Inspection
- Performance Design Guidelines
Step 5. Create Candidate Solutions
Create a candidate architecture and along with architectural spikes and evaluate it against your key scenarios, hot spots, and deployment constraints. The outcomes of this step are:
- Baseline / Candidate Architectures
- Architectural Spikes
Iterative and Incremental Design
You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. You don’t have to design your architecture in a single iteration. Do not get lost in the details; focus on sketching your design, identifying risks, and elaborating as necessary.
Mapping the Agile Architecture Method to Your Life Cycle
Now that you have the basic technique, you can stretch it to fit your needs. For example, you can use it as a short-burst, whiteboard technique to model your application or create candidate architectures. You can use it to guide your design, implementation, and deployment inspections. You can use it to identify and prioritize your technical risks. You can use it to identify relevant hot spots during your iterations.
During exploration, you can use the Agile Architecture Method to help you figure out a few things:
- Technical goals. You can figure out your basic technical goals from a design standpoint.
- Technical risks. You can map out your key high risk areas, to help prioritize your architectural spikes.
- Architecture spikes. You can identify your high risk spikes such as intersections with cross-cutting concerns or quality attributes.
For iteration 0, you can use the Agile Architecture method to help you with:
- Candidate architecture / solutions. You can also identify candidate application type, potential deployment scenarios,and potential architecture styles.
- Prioritized technical risk. You should have a good handle on technical risks, at least in terms of priorities.
- Prioritized technical goals. You should have also have a good handle on your prioritized technical goals, based on your learnings from exploration.
Iteration 1 to N
During each iteration, you can identify relevant hot spots for your prioritized scenarios. This includes both relevant cross-cutting concerns and quality attributes. For each story, simply map relevant hot spots from the various frames. You can then decide whether you need to spike or whether you can address the hot spots through inspections. You may need to refactor your design. At least for security and performance, you can use the patterns & practices resources. For additional quality attributes, that’s open opportunity.
Just in Time Architecture (JITA)
Rather than Big Design Up Front (BDUF), the Agile Architecture Method helps you both do just enough design, as well as just in time architecture. You can do just enough design up front to help you move forward with prioritized risks, candidate solutions, and potential architecture spikes. During iterations, you can do just in time architecture by finding intersections between stories and quality attributes and cross-cutting concerns.
My Related Posts