SDD Conference Top Takeaways - Evolutionary Architecture

Spread the love

This entry is part 1 of 1 in the series SDD Conference 2022
  • SDD Conference Top Takeaways - Evolutionary Architecture

These are just a few of my takeaways from Neal Ford’s Building Evolutionary Architectures workshop at SDD Conference 2022. More to come.

Bit Rot

  • Software degrades over time, like cracks appearing in a building. Structural defects can start small and get more problematic. This seems inevitable, but it isn’t.
  • QA helps to reduce degradation, but it doesn’t cover everything. It misses the architectural characteristics, e.g. auditability, scalability, performance, etc.

Architectural Characteristics

  • A full list is not possible, they change over time. You need to create a list specific to your organisation and iterate on it. 
  • Ensure you use ubiquitous language within a project team and across the architects in an organisation.


  • Tech change is pretty much forced upon us. 
  • If you don’t evolve or pivot you get left behind. 
  • Patterns emerge and are given a name when they are recognised as a good solution to a problem.

Q: How is long-term planning possible?
A: Plan for things to change!

Evolutionary Architecture

“An evolutionary architecture supports guided, incremental change across multiple dimensions.” i.e. architectural characteristics that are relevant to the project.

Fitness Functions

  • Automating checks for architectural characteristic support work in the same way as unit tests. 
  • Higher level functions will require possibly stringing things together, as there isn’t a specific library or tool that can be used.
  • You are creating an objective integrity assessment of one or more architectural characteristics.
  • Iterate. You don’t know what you don’t know. Things will change.

All architectures become iterative because of unknown unknowns; agile just recognizes this and does it sooner. - Mark Richards

  • Fitness functions overlap with other premises, e.g. monitors, unit tests, chaos engineering…
Fitness Functions Venn diagram, reproduced with reference to Neal Ford's version

Some Examples of Architectural Fitness Functions

  • Cyclic Dependency Function - ensure you don’t have e.g. ClassA referencing ClassB that references ClassC, which references Class A… This is a small thing that can be missed and leads to Bit Rot.
  • Directionality of imports - ensure rules on this are followed.
  • Data displayed on screen is not stale - ensure HIPPA is followed for US healthcare systems.
  • Chaos Monkey & the Simian Army - check your system copes with systems, availability zones and even whole cloud regions being taken down.
  • Naming conventions - ensure that naming conventions are followed by specifying a pattern to use or antipattern to avoid.
  • Afferent (incoming) and efferent (outgoing) coupling - check whether coupling falls within specified limits.
  • Identify changes in open-source software licenses - make sure any changes in open-source software you depend on are put under the noses of your legal team.

Developer Torture is not the aim

  • Architects and developers need to work together.
  • Fitness functions are a checklist to stop important things falling through the cracks. Doctors use checklists too!

What makes microservices so evolvable?

  • Extremely lose coupling.
  • Fine granularity / small quanta, including any data stores.

Implementing Fitness Functions

  1. Identify your dimensions (including architectural characteristics and linked metrics)
  2. Define fitness functions for them.
  3. Use deployment pipelines to run your fitness functions (quick and atomic functions running earlier than slow and holistic functions)

Low/No Code

  • Beware of the Last 10% antipattern! 80% of requirements are implemented easily, the next 10% are hard as the tool/platform doesn’t really support them, the last 10% are impossible. Low/No Code is prone to this, otherwise we would all be using it!
  • Try the hardest thing as a proof-of-concept (PoC), not the simplest (we would hope it can do that easily!). Will it really do what you need?
  • If it acts like code it should be handled like code with unit tests, versioning, etc. 

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

  • We’re told low/no code isn’t for developers so it doesn’t integrate with pipelines, version control, etc. 

Some Tools for fitness functions


What next?

Let me know if there is anything specific you would like me to expand on. More to come from SDD 2022.

Spread the love