Agile Architecture Principles
Agile Architecture Principles
You are applying the agile, lean approach to your software product development. Your teams use Scrum or Kanban to deliver running software every two weeks. The product market introduction is a success and you will successfully sell the solution for the next ten years.
How shall you define the software architecture of your product and insure a long living and high quality solution? The experts tell you the design is emergent, what does it means?
LeSS Architecture Observations
The following observations are true for any software product. It is irrelevant if developed using agile approaches or traditional older ones.
- The sum of all source code is the true design blueprint or software architecture,
- The real software architecture evolves (better or worse) every day of the product, as people do programming,
- The real living architecture needs to be grown every day through acts of programming by master programmers,
- A software architect who is not in touch with the evolving source code of the product is out of touch with reality,
- Every programmer is some kind of architect — whether wanted or not. Every act of programming is some kind of architectural act — good or bad, small or large, intended or not.
Agile architecture comes from the behavior of agile architecting
- hands-on master-programmer architects, a culture of excellence in code,
- ban emphasis on pair-programming coaching for high-quality code/design,
- agile modeling design workshops,
- test-driven development and refactoring,
- and other hands-on-the-code behaviors.
Quality of Your Architecture
You shall measure the quality of your design and produced software artifacts.
- Static analysis tools - validate your source code -,
- Test driven development - validate your design -,
- Acceptance test driven development - validate your functional requirements -,
- Fitness functions - validate your non-functional requirements -,
- Pair programming - improve the produced artifacts through wisdom of the crowd -,
- Pair review and pull requests - validate your developers' work -.
The above validation activities are backed through tools. But these tools can only detect non-quality and never provide a proof you achieved quality. Qualified and experienced engineers is your best guaranty to achieve and sustain high quality in architecture and software products.
Implement the above measures to gather data and publish the actual state of your source code. You find further information in Code Scene as Crime Scene, SonarLint for the Impatient, and Pragmatic Craftsmanship articles.
Read the LeSS architecture page for a comprehensive discussion of agile architecting.
Good versus bad architecture
A good architecture fulfills the specifications and is easy to change.
It shall emerge during the development and intentionally implement the known requirements.
Your architects are talented developers and are full members of your Scrum teams.
Your development teams * are expert in the used programming language and stack, * understand object-oriented, functional and rule based programming, * known all major patterns and idioms of the used development stack, * practice TDD, ATDD, clean code, refactoring, embrace CI/CD and DevOps, * read source code from open source projects to learn better ways, * know SMART, INVEST, SOLID, KISS, YAGNI, * hold weekly design workshops with huge whiteboards, * use domain driven design and event storming, * avoid BDUF.
You shall keep it simple, make it valuable, and build it piece by piece.
The above hints and practices shall empower your teams to practice successfully agile architecture and timely deliver delightful software solutions. Your organization shall train your collaborators, see also Shu Ha Ri model. Smart money goes in training your collaborators.
Agile Architecture Series
The agile architecture track contains the following blogs
We also published our agile architecture course (3 ECTS) used for teaching computer science students at bachelor level at Swiss technical universities.