Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Abel Avram on Nov 21, 2008
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
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
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.
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.
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.
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.
Technical Debt and Design Death
Shouldn't the first output be:
* Architecturally significant use cases
* Architecture hot spots
* Candidate architectures
* Architectural spikes
Yes, thank you! I corrected it.
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?
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.
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?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply