In more traditional software development projects, software architecture are used to describing, modeling and perhaps creating the software architecture for the whole project beforehand. In agile projects not all requirements are known at the start of a project. Thus, creating the
final software architecture at an early point in the project can be very contra-productive, as it is likely to change under influence of the software being build.
Agile software development projects require a different style of software architecture - agile or evolutionary.
Triggers
The approach to software architecture to specify it at the start of the project might seem very effective. That is, all design decisions made during the development of the software will reflect this thorough architecture. However, as we learn more and more on the project we're in, it is possible that we miss out on architectural requirements, simply because at the start of a project we just don't know all requirements.
In agile projects we delay as much of the work as possible - if you don't need it now, postpone. New requirements, also to our software architecture, will pop up during the project. Agile software architects need to use this mechanism continuously to imporove and extend the existing software architecture. The question software architects need to answer is:
is refactoring my current solution worthwhile when a change in software architecture is discovered, or do we leave the exisiting software as is, and just apply the new software architecture to new functionality (in smart use cases)?Technique
We use a very basic technique to ensure that refactoring is kept to an absolute minimum. This techniques consists of three consecutive steps:
- 1. Take the Nike approach. The first time you are building a specific type of functionality - say selecting from a list in Sharepoint, you take the Nike approach: just do
- 2. Copy-and-paste. The second time you scratch your head, but just make a copy of the previous version, and go along with that, as you never know if this type of functionality will hit you
- 3. Three is a crowd. When you have an encounter of the third kind, it’s time to shuffle. Look at the previous two implementations, find and implement the pattern in a small framework, and refactoring the previous two implementations. Set out your guideline on your project wiki, or any other central place for saving standards and guidelines.
Read more
- Pattern catalog. Collection of analysis, design and software architectual patterns.