Automatically enforcing decisions

Project Beacon: our take at fitness function driven architecture

Managing technical quality for a distributed architecture

In the world of distributed systems and microservices, we build and maintain applications with varying age, technologies, ownership and technical debt. Also knowledge is lost over time. Which make it hard to know what’s the current state of the global system and each of it’s parts.

So how can we monitor our technical quality and decide where we need to focus our efforts to improve? How do we know if we are improving or not? How far away from our target architecture and standards are we?

Previously at TheFork we were using a very manual and not so accessible spreadsheet mechanism to try and keep an eye on all of this. But we wanted to do better and open up to a wider audience!

There can be different levels of engagement with this information depending on peoples roles:

• Tech leaders, architects and management to get a global picture
• Developers to get a view on the systems they own
• Product teams to help prioritise improvements

What is a fitness function?

At the time we didn’t see any tools on the market that gave us everything we wanted, so it was proposed to build a tool called Beacon based on the concept of fitness functions (inspired by the ThoughtWorks article on the topic). The idea has its roots in evolutionary design, as the way to drift the system architecture towards given predefined criteria.

Our take on this states; during test-driven development we write tests to verify that features conform to desired business outcomes, so with fitness function-driven development we can also write tests that measure a system’s alignment to architectural goals.

So what would these fitness functions actually look like? Well they can actually be almost anything we deem important to track:

• Code quality e.g. test coverage is > X%
• Resiliency e.g. no production incidents in Y months
• Version of framework/language matches what we want to support
• Operability e.g. applications are correctly configured (logging/monitoring/documentation/ownership)
• Security and compliance

A lot of data already exists in external tools Jira, NewRelic, SonarQube etc. and Beacon can make use of this raw or pre-calculated data to make autonomous checks.

The possibilities are almost endless, and not just static code analysis, we may want to check dynamic things like performance testing, security scans etc. Essentially any technical decision we make can be backed up by a fitness function to check our progress.

So what did we build so far?

We built an API with an easily extendable library of fitness functions and then provided a mechanism for these to be run against all our software components, both:

• Periodically
• On demand

Each given fitness function has:

• Logic to specify which of our components it applies to
• Logic to specify the rules for passing the assessment
• Tags for categorisation
• The results of each assessment stored in a database

The stored results allow us to create a current score for each component as well as track the change over time to see how we are doing.

We also made as many of the features to our teams available ‘out of the box’ requiring minimal effort to make use of the tool.

Visualisations

We built a series of dashboard views in a tool called Metabase, giving visual answers to questions/problems such as:

• Show me an overview of all my teams components
• Show me the latest score and assessment results for my component
• Show me all the components that are currently ‘failing’ a given fitness function
• How have scores changed over time?

The data can be searched and filtered enabling easy access to the data you are interested in, so can be tailored by audience.

The future is bright

The tool is already being used by technical teams to prioritise and monitor improvements to their score (especially during planning cooldown periods).

Other features we have been thinking about including in Beacon:

• CI integration
• Gamification
• Combine with an API catalog tool or internal developer portal (such as Backstage or Cortex). In fact since we built Beacon some products in this space have now developed similar features
• Automatically fix issues
• But mainly more and more functions!

Its early stages for the project but we already feel that it can provide a lot of value to a variety of people within the organisation. With the aim to become a key mechanism to ensure the quality of systems, make sure they adhere to our standards and drive improvement over time.