Architectural Fitness Function: build measurable evolutionary architecture

Evolutionary architecture is something every software architect thinks about. It supports guided, incremental change as the first principle across multiple dimensions. To support this evolution, fitness functions can help in finding how well a system meets specified architecture goals and constraints in an automated way. And today’s post is about architectural fitness functions.

What is Architectural Fitness function?

Fitness function is a type of objective function that is used to summarize how close a given software architecture solution is to achieving the set aims.

When defining an evolutionary architecture, the software architect seeks a ‘better’ algorithm; the fitness function defines what ‘better’ means in this context. Software architects can communicate, validate and preserve architectural characteristics in an automated, continual manner, which is the key to building evolutionary architectures.

The fitness function is constructed on the basis of the software under test. With fitness-function-driven development, you can write tests that measure a system’s alignment with architectural goals.

When starting using fitness functions is to begin by gathering input from all stakeholders to get an understanding of what they consider to be the most important architectural attributes. These should then be grouped into common themes like resilience, stability, etc.

All collected fitness functions should describe their intent using an objective metric meaningful to teams and stakeholders. This will help the teams in measuring technical debt but also to avoid architectural drift. All functions should be drafted in a testing framework and included in appropriate delivery pipelines. One example of a fitness function is code quality where modifiability, manageability and adaptability can be measured in order to prevent code with too low quality from being deployed to production. Also, Implementing automated performance tests as fitness functions and added to the build pipelines means tests are run early with results immediately accessible.

The real proof of architectural fitness functions comes with derived measures that describe how the system is being used and whether it is meeting expectations. For example, this can include more commercially-orientated tests that reflect business priorities as much as technical implementation:

• How long does it take to deliver a feature, from conception to release?
• How often are deployments being made and how many of them fail?
• How much unscheduled down-time is going on?

Architectural Fitness Function Forms

1. Atomic vs Holistic

1. Fitness functions run against a singular context and exercise one particular aspect of the architecture. An excellent example is a unit test that verifies some architectural characteristic, such as modular coupling or cyclomatic complexity.
2. Holistic fitness functions run against a shared context and exercise a combination of architectural aspects such as security and scalability.

2. Triggered vs Continual

1. Triggered fitness functions run based on a particular event, such as a developer executing a unit test, a deployment pipeline running unit tests, or a QA person performing exploratory testing.
2. Continual tests don’t run on a schedule, but instead execute constant verification of architectural aspect such as transaction speed. Monitoring Driven Development (MDD) is a testing technique gaining popularity. Rather than relying solely on tests to verify system results, MDD uses monitors in production to asses both technical and business health.

3. Static vs Dynamic

1. Static fitness functions have a fixed result, such as the binary pass or fail of a unit test.
2. Dynamic fitness functions rely on a shifting definition based on extra context. For example, a company might build a sliding value for performance based on scalability.

4. Automated vs Manual

1. Software architects like things automated. Automated fitness functions execute within an automated context, while manual fitness functions, like legal requirements, defy automation.
2. Manual fitness functions are cases that require the verification of person-based process.

Key Architectural Fitness Functions benefits

• Fitness Functions can objectively measure technical debt and drive code quality.
• They also provide real-time feedback when changes are made in fitness functions due to for instance new security or operational standards.
• They can inform about coding choices for interfaces, events, and APIs related to downstream processes.
• When applying the strangler pattern they can be useful to verify that requirements are met when business logic is decoupled.
• They can communicate architectural standards in the form of code, thus helping developers to deliver features better aligned with the architecture.
• An architect can request changes to some architecture concern which will then be verified during the build process.
• Communicate, validate and preserve architectural characteristics in an automated, continual manner.
• Sometimes Software architects don’t know all important parts of an architecture at the beginning and thus can identify fitness functions as the system evolves. These emerge during the actual development of the system.
• Maintains coding standards.

While most fitness functions trigger on change, software architects may want to build a time component into assessing fitness. For example, if a project uses an encryption library, the architect may want to create a temporal fitness function as a reminder to check if important updates have been performed.

If you would like to know more about architectural fitness functions, I highly recommend you to:

• Watch Video by Mark Richards
• Read Building Evolutionary Architectures book by  Neal Ford, Rebecca Parsons, Patrick Kua

We live in a world where software technologies and systems are ever changing. And we want to build architecture that is able to evolve with them. We want our architectures to evolve in a guided way. Fitness Functions are a good way to place constraints on different aspects of the architecture to guide them in certain evolutionary directions.

I hope you found it useful, if you have any questions, let us know! We specialize in software architecture!