(Guided) Architectural Emergence
Architecture in an agile environment needs to be developed and filled with life bottom-up instead of top-down. Architectural solutions emerge over time; this doesn’t happen by accident, but instead can be guided by the goals the organization tries to achieve. Such an emergent architecture is best built on values and principles, not rules, and uses soft standards that have proven themselves useful in actual software systems.
Architecture that emerges makes life for developers easier, not harder. Different solutions compete against each other for being the best approach in the current context. High integrity is not enforced, but suggested.
Core Ideas
Embrace emergent practices that lead to innovation
Hard rules define exactly what to do in different situations. They usually consist of simple if-then-else decision trees, which makes them easy to define and check. But it also makes them inflexible and rigid. We instead try to install principles and guiding values. They describe how we want to work together and what we try to achieve. The specific solution can then be decided by those doing the work.
Create soft standards based on principles and trust in eventual integrity
Software developers try to solve problems. Complicated software designs or difficult-to-use APIs and frameworks prevent them from doing so. Blueprints of architectural solutions, libraries or ready-to-use artifacts make it easier to focus on the problem, not on the technology. Solutions and technical ideas are not forced onto developers though. Divergence is allowed within basic boundaries. Soft standards are established by making suggestions easy to follow. Over time the best approaches for a specific problem in a specific context emerge and are being used until the context, the problem, or available solutions change.
Market your proven architectural solutions
Often software architecture is defined and documented meticulously and then expected to be followed. Software developers having ad hoc questions are referred to the documentation. Instead the organization needs to install ways to provide support to answer questions around and challenges with the existing architecture. It is even better to proactively market architectural solutions and show where and how they can help making developers' lives easier. This way architecture can prove itself “in the field” when it is used in software systems, instead of just look good on a slide.
Sector Rating Aspects
These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page.
| Aspect | Adoption Lifecycle |
|---|---|
| Basic architecture principles are available as a blueprint | Late majority |
| Central architecture boards discuss, share and improve architecture proposals | Early majority |
| Architecture proposal creation is incentivized | Early majority |
| Specialists’ support is requested in a pull-approach | Early majority |
| Architecture proposals are used instead of hard architecture governance | Early adopters |
| A few well formulated architecture principles are used to guide decisions (principles vs. rules) | Early adopters |
| Deviations from central proposals are motivated by teams | Early adopters |
| Self-service infrastructure is offered for easy access | Early adopters |
| Software evolution is driven by architectural and quality goals, not rules | Innovators |
| Tested and validated solution proposals are offered to others in an internal marketplace | Innovators |
Connections
- Empirical Process Control: Stimulate proposals and an evolutionary creation of your macro architecture.
- Feedback & Transparency: Measure proposal quality to incentivize the implementation and maintenance of proposal-based solutions.
- Responsibility: Install identification with proposals and solutions in order for teams to realize when to not follow the easy standard path.
