This summer, The Workshop’s Director of Architecture, Joaquín Guillén presented Continuous evolution: Using fitness functions to drive platform modernisation at Málaga’s J on the Beach conference. Below, he explores the power of evolutionary architecture and explains how The Workshop is integrating this approach.  

Modernising software systems and products is always a big investment. Over the years, engineers have struggled to justify the associated costs – such as technical debt, code refactoring and tech refresh plans. Meanwhile, the lack of tools available to measure degradation makes it a challenge to explicitly identify when upgrades are needed.

At The Workshop, we’re determined to keep our products up-to-date. Over the past three years, we’ve developed a framework to help us measure software degradation – and we’re using this data as a touchpoint to make sure we’re constantly evolving.

The challenge of software evolution

Software systems naturally degrade over time. This isn’t because the software itself is deteriorating, but because it exists within a dynamic ecosystem. Its lifecycle is impacted by a whole host of external factors: changing business priorities, emerging technologies and new features that need to be integrated. As a result, many software products become more fragile – and less efficient – as time passes.

Let’s consider a real-life example to illustrate the point, using the visuals below.

Imagine a newly developed residential area. Let’s say a family builds a house and connects it to the sewage treatment plant using pipes (Figure 1.a). Initially, everything functions perfectly. But as the population of the area grows, the demand placed on these perfectly functional pipes increases, leading to issues like leaks (Figure 1.b). As more people arrive, the original pipes no longer serve their purpose and must be replaced with larger ones to accommodate demand (Figure 1.c). Plus, as technology advances, newer pipes made of different materials are introduced, requiring adjustments to the existing connections.

Then, eco-friendly sewage enters the picture. New treatment plants are developed and, once again, the pipes’ connections need to be adapted to ensure compatibility with an updated infrastructure (Figure 1.d).

This is a great example of a solution becoming less efficient over time, primarily due to external factors. Something that was initially perfectly suitable has to evolve in order to remain effective. This same principle applies to software products.

Evolutionary architecture

In the software industry, evolutionary architecture is a technique aimed at solving these problems and ensuring our systems can age gracefully, meeting changing demands while staying relevant.

The idea was initially introduced by Thoughtworks director and software architect Neal Ford. Alongside his co-authors Rebecca Parsons and Patrick Kua, Ford explained the core principles of the approach in the book Building Evolutionary Architectures: Support Constant Change.

The main principles supporting evolutionary architecture are as follows:

• Incremental change: Aligned with the principles of Agile software development, evolutionary architecture promotes making small incremental changes (instead of “big bang” changes), in order to reduce risk and enable smoother evolution.
• Fitness functions: These measure how changes are impacting the efficiency of a system, allowing us to measure its alignment to our overall goals. (Fitness functions may also fit into various categories based on context, e.g. atomic vs. holistic, automated vs. manual or triggered vs. continual.)
• Quality attributes: These are characteristics specific to a software system, and based on that system’s needs and purpose. (For an example, check out the attributes defined in ISO/IEC 25010:2011.)

The Workshop framework

At The Workshop, we carried out a detailed analysis of our products, taking into account the principles of evolutionary architecture alongside our particular challenges and operating environment. As a result, we decided to implement a framework for tackling software degradation that focused on four specific dimensions: quality, technology, security and maintainability.

Our overall goal is to ensure that our products meet exceptional quality standards, use fit-for-purpose technologies, are resilient to security threats and can be maintained in line with our rigorous architecture and coding standards. With all this in mind, our next step was to define the exact fitness functions we wanted to use. In order to achieve a holistic view, we landed on the following four:

• Quality index
• Technology alignment
• Security index
• Technical debt

We knew that by analysing these fitness functions, we’d get a clear picture of how our products were really holding up.

As the saying goes, «only what gets measured, gets managed.» This four-part framework provides valuable metrics for measuring the true degradation of software products.

Leveraging the results of a framework like this enables us to more effectively prioritise work, identifying and tackling the components, systems, domains or products that are in the worst shape. Decisions can then be driven by the criticality of each area, and we can be confident that our efforts are focused on the most impactful improvements.

A framework like this also functions as a powerful tool for communicating with stakeholders. As I mentioned above, it can sometimes be challenging to secure stakeholder investment in technical improvements, but with a framework like this it becomes possible to clearly demonstrate the rationale behind any product or system evolution, and discussions become much easier as a result.

Product scores

Each index of the framework was given its own rating based on a range of unique factors (if you’re interested in the details, check out the recording of my live lecture) but we also wanted to combine the ratings into a single product score, assessing the overall health of products.

Embracing this approach not only helps us measure the health of each product but also helps us identify the areas in need of a little extra effort, empowering our teams to develop clear roadmaps, set defined targets and prioritise the product modernisation process.

Some areas for improvement

Our fitness function framework has been a game-changer for us, but we’re still committed to making it even better. We’ve already targeted a few specific areas for improvement:

• Visualisation: We’re looking at incorporating visualisation tools, such as the Backstage development portal, to make sure the insights gained through the framework are easily accessible to our Product and Engineering teams. We also want to make use of traditional data analytics visualisation tools like Tableau for product stakeholders.
• Automation: Some metrics still require manual calculation. We want to automate these processes wherever possible, with a focus on improving adoption and ensuring fairness of the tool.
• Gathering feedback: Getting feedback from the teams using the tool is vital for refining the algorithms we use. We’re using this crucial feedback to determine the ideal balance of fitness function components when assessing the overall product score. We’re also eager to identify any additional elements that we should be considering in our metrics to enhance their accuracy and relevance.

A last word

It’s been an amazing journey since we embarked on our initial discussions around evolutionary architecture three years ago. Since then, this framework has become a crucial component guiding and empowering our organisation to continuously evolve software products and ensure their relevance in a dynamic landscape.

Even though we still have work to do, we’re determined to adopt this framework across our entire range of products. In the beginning, we lacked sufficient data, necessary processes and tools, but we’re now beginning to reap the rewards of our early investment. We’ve gained fresh clarity around our current position, and we’re ready to chart a path towards our desired future state, enabling continuous evolution.