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
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:
- 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.
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.
Error in quote?
* Architecturally significant use cases
* Architecture hot spots
* Candidate architectures
* Architectural spikes
What's Agile about that approach?
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?
Looks like RUP Elaboration Phase Re-branded
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.
Re: What's Agile about that approach?
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?