Practicing Agility in Application Architecture

Posted by Abel Avram on Nov 21, 2008 05:24 AM

Community

Architecture

Topics

Methodologies ,

Design

Tags

Emergent Architecture ,

Patterns and Practices

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.

 

1. Back to top

   Error in quote?

   Nov 21, 2008 10:33 AM by Christopher Brind

   Shouldn't the first output be:
   * Architecturally significant use cases
   * Architecture hot spots
   * Candidate architectures
   * Architectural spikes

   Reply

2. Back to top

   Re: Error in quote?

   Nov 22, 2008 7:19 AM by Abel Avram

   Yes, thank you! I corrected it.

   Reply

3. Back to top

   What's Agile about that approach?

   Nov 22, 2008 1:49 PM by Johannes Link

   It's arguably iterative but does that suffice to make it Agile? I wouldn't think so: Iterations are for correcting mistakes but not for responding to (major) changes. Some kind of incremental and evolutionary architecture would be required whereas the 5 steps look a lot like classical up-front-architecture to me.
   
   Is that just another attempt of Microsoft to distort the meaning of a successful term - as they tried to with "TDD" a few years ago?

   Reply

4. Back to top

   Looks like RUP Elaboration Phase Re-branded

   Nov 23, 2008 6:07 PM by Bill Ross

   Reading this I cannot help but notice the similarity of this with the Rational Unified Process Elaboration Phase activities, with each iteration through their steps being an iteration in the elaboration phase.
   
   They also seem to have coined the new term "Key Hot Spots" for aspects of architecture that have been called "Non-functional Requirement" or "System Qualities" for many years.
   
   Mind you I'm not knocking it, I think you have to use an approach like this for any new non-trivial system.

   Reply

5. Back to top

   Re: What's Agile about that approach?

   Nov 24, 2008 6:58 AM by Jeff Santini

   Agree completely. The first step to improve this article if for someone to connect the ideas presented to something vaguely related to Agile software development.
   
   What is happening with the rest of the team while Architects are creating their Agile Architecture? Is software being developed, showcased to users, tested, released during this phase or is this some iterative/Agile phase that exists before development has begun? If so who is going to validate the models and prototypes? Other architects? Testers? Users? What will you do when your iteratively developed architectural solutions run into the real world of other people delivering working software to users? Will there be no architectural problems to revisit? if there are then will you have to repeat these iterations? Were the original ones then a waste?

   Reply

• Older >