(Guided) Architectural Emergence

Evolutionary Systems - (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.

Low Rating:

  • There are a multitude of rules, comprising a binding ‘architectural standard’
  • Diversity in the solution space is seen as a problem and labeled ‘inconsistency’
  • Innovation is driven by a view appointed masterminds
  • Communication is oriented towards teams and focuses on how to do things the right way.
  • Problems are seen as setbacks and associated with unprofessional behavior or personal mistakes

High Rating:

  • Soft standards are in place – consisting of suggestions with associated goals. It is allowed to deviate from suggestions, but the goals are binding
  • When developing a solution it is easy to stay within the communicated architectural ideas. Blueprints, templates, libraries and/or central roles support it
  • Architectural principles and guiding values are well established and communicated
  • Innovation is driven by everybody, constantly challenging the status-quo

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