Agile development was developed from a reaction to the slow pace of the traditional waterfall approach. Companies were not happy spending months of time and lots of money to create nothing but documentation. The agile approaches all stress working software over documentation. For instance the Scrum process tries to find what working software it can deliver within two weeks.
When you talk with Software Architects who have never worked in an agile environment they always are concerned with the time-frame that they should deliver a completed project. How can they architecture be sound in such a short term? In this article we are going to discuss some of the basics of agile architecture and address this concern. There is a myth that agile development does not do architecture.
One of the issues software architecture models can bump into is when they are applied to normal development they can become cumbersome. Agile techniques stress speed of development, the architecture needs to evolve quickly. Architecture is a concern of all the developers on the team, not some model that is approved by one team and used every where. There are no special roles for architects in the team it is everyone’s responsibility.
One important aspect of any technical solution is its scalability. We never know what application may become popular so we must always ask the question, “will it scale?” Using pair programming and code reviews is a great technique to spot issues in the development phase. As things progress you can use the test layering approach that will add some load testing to check this.
Architecture should be reviewed throughout the product’s lifecycle. In initial stages the design should be reviewed and changed to meet the goals of the product owners. Then as modifications are made in testing and release it needs to be monitored for any issues.
The Agile Model Driven Development approach looks at initial requirements and then discusses architectural requirements to ensure the technology can deliver. It identifies the high level scope and from their creates an architectural vision.
This approach uses modeling as part of the iteration planning. This modeling is done to help give good estimates of the time to completion. In iteration modeling there are a few attempts to find a solution that fits the architectural vision. From there you move into Model storming where stakeholders review the various aspects of the partial solutions. Test Driven Development is used to test these solutions to ensure they can scale and meet demands dependably.
The team is sharing the responsibility of the the architecture. It is important not to let one person dominate the architecture as everyone makes mistakes and reviewing the proposals is helpful. All team members should have input on this and questions are encouraged.
To make this scale to multiple teams you may have to designate Architecture Owners. Unlike the traditional Software Architect they will collaborate with the teams to create the overall solution architecture. Similar to the product owner this person will have the final say on any technology questions.
It is important to create models for the architecture and a consider the different options ahead of time. As you look at these look at the enterprise constraints that will affect your final decisions. As you come to a solution make it as simple as possible and only document what will be necessary. Extensive documentation invites people to avoid it. Communicate out your solution in many channels to make sure everyone knows and understands the solution.