Monday, June 27th, 2016
Software Architecture is defined as the structure of the components of a program/system and their interrelationships, that meets all of the technical and operational requirements, while optimizing quality attributes such as performance, security, and maintainability.
Traditionally, before starting any development, the architect of the system was in charge of creating big documents and diagrams explaining the architecture. But the architecture is far too important to leave in the hands of a single person no matter how bright they are.
Therefore, architecture should be a team effort. The words agile and architecture are often seen as mutually exclusive, but nothing could be further from the truth. Instead of creating the architecture before the development, the architecture emerges collectivelly iteration by iteration, with the support and guidance of the “architecture owner”.
Base your architecture on requirements. Travel light and prove your architecture with concrete experiments.
The Agile Architecture is created as we go. Effective architecture owners work on architecture spikes, creating prototypes and experiments to explore new strategies. They have a good understanding of the business domain and work with the rest of the team to prove portions of the architecture via concrete experiments.
One goal of the architectural efforts is to travel light, to be as agile as possible:
- Don’t create a fifty-page document when a five-page one will do.
- Don’t create a five-page document when a diagram will do.
- Don’t create a diagram when a metaphor will do.
In a few words: short and useful architecture documentation that reflects reality over encyclopaedias that nobody reads, understands or cares about.
Summing-up: as the first metric for agile software development is whether or not working software actually exists, the same applies to agile architecture: structure of components and their interrelationship that is currently working.
These Notes have been taken from: