Practicing Agility in Application Architecture

Microsoft has published a How-To Design Using Agile Architecture guide under patterns & practices providing detailed guidelines to follow when architecting an application, the Agile way.

The guide recommends to start with the following input:

• Use cases and usage scenarios
• Functional requirements
• Non-functional requirements (quality attributes such as performance, security, and reliability)
• Technological requirements
• Target deployment environment
• Constraints

The design should produce the next output:

• Architecturally significant use cases
• Architecture hot spots
• Candidate architectures
• Architectural spikes

The guide introduces agility by specifically advising on not doing the architecture in one step, but recommends doing it in five iterative steps:

• Step 1. Identify Architecture Objectives. Clear objectives help you to focus your architecture, and will help you focus on solving the right problems in your design. Good objectives help you to determine when you are finished, and when you are ready to move to the next phase.
• Step 2. Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
• Step 3. Application Overview. Understand your application type, deployment architecture, architectural styles, and technologies in order to connect your design to the real world in which the application will have to operate.
• Step 4. 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.
• Step 5. Candidate Solutions. Create a candidate architecture or architectural spike and evaluate it against your key scenarios, hot spots, and deployment constraints

Step 1. Identify Architecture Objectives.

According to J.D. Meier, Principal Program Manager on patterns & practices at Microsoft, the purpose of this step is to scope “how much time and energy to spend on subsequent steps as well as guide your overall effort”. The result of Step 1 should be:

• Build a prototype
• Identify key technical risks
• Test potential paths
• Share models and understanding

Step 2. Key Scenarios.

The best scenarios are identified by following the next criteria for use cases, according to J.D. Meier:

1. They are important for the success and acceptance of the deployed application.
2. They exercise enough of the design to be useful in evaluating the architecture.

Step 3. Application Overview.

An application overview is necessary to introduce real life details and concreteness into the design, and it is created by performing these 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 and other constraints, and determine which technologies you will leverage in your architecture.

The guide offers advice for all the above mentioned steps, an example being the option of choosing between several architectural styles:

• Client/server. Segregates the system so that the client makes requests from the server.
• Component-based. Decomposes application design into re-usable components that expose well-defined interfaces.
• Layered. Segregates the system into groups of similar functionality as separate layers.
• Message-bus. Defines a set of known formats used by all connected systems so that they do not have to know about the differences between the actual recipients.
• Object-oriented. A programming style based on the division of tasks into reusable objects that contain both the data and the behavior relevant to the object.
• Service-oriented (SOA). An application that exposes and consumes functionality as a service using contracts and messages.

Step 4. Key Hot Spots.

In this step one should "identify the hot spots in your application architecture to understand the areas where mistakes are most likely to be made. Key hotspots can be organized around quality attributes and cross cutting concerns”. The long list of hotspots presented by the guide include: availability, interoperability, maintainability, reliability, security, etc.

Step 5. Candidate Solutions.

After identifying the key hotspots, the first draft of the architecture can be produced. After that, one should go back to Step 2 to validate the candidate architecture, then follow steps 3-5 to generate a new candidate. The process is repeated iteratively improving it with each iteration.