Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Rebecca Parsons - Thoughtworks CTO: by 2025 We'll See Evolution in Architecture, But Not Revolution

Rebecca Parsons - Thoughtworks CTO: by 2025 We'll See Evolution in Architecture, But Not Revolution

This item in japanese

On the second day of the QCon London conference, Rebecca Parsons, chief technical officer at Thoughtworks, revisited the idea of evolutionary architecture, imagining how it might evolve towards 2025. Starting from the definition of evolutionary architecture, she visited each of the "ilities" or attributes, anticipating how they will evolve in the next period. She concluded that we will see evolution but not a revolution.

Evolutionary architecture supports guided, incremental change across multiple dimensions.

Parsons provided insight into why the word evolutionary is used instead of agile or emergent. The name remained settled after a constructive but robust conversation with Neil Ford, co-author of the Evolutionary Architecture book. Initially, Ford called this practice "emergent" architecture. Even if it is relatively easy to agree on "good" or "bad" code, it is not the same when it comes to architecture. The guided part of the definition refers to what constitutes good architecture.

That’s why we introduced the notion of the fitness function. A fitness function is an objective characterisation of how well a particular system reflects a desired behavioural characteristic.

Next, Parsons focused on the importance of operationalizing this: how can you incrementally add new functionality and provide the mechanism on the path to production?

One of the important practices and enablers for evolutionary architecture is the level of rigour and automation that comes together with continuous delivery and ultimately continuous deployment.

These fitness functions should be baked into a deployment pipeline.

The last part of the definition highlighted was the multiple dimension aspect. A slide was shown containing the list of -ilities from Wikipedia from a couple of years back. The list has since evolved, for example, with more of a focus on observability. One of the fallacies of the list is that you cannot maximize all of them, as some of them are mutually exclusive: "There are systems that are a one-off; you don’t care about evolvability".


Next, Parsons looked at today’s principles of evolutionary architecture and then speculated on how they will evolve in the next two years.

Personally, I believe that one of the reasons our first attempt at doing SOA failed was because we were drawing the boundaries around the systems. More so than we have drawn them around concepts

Last responsible moment: in order to have as much information about the system as possible, you want to delay the decision to the last responsible moment. The tradeoff that needs to be made is the way it will translate into the "-ilities" and the fitness functions.

Architect and develop for evolvability: if evolvability is important for your system, it is important not only to how you write the code but how you structure the code too.

Readability is key and here is where the quality software metrics come in. [...] This is when we talk about boundaries, coupling and cohesion.

Postel’s Law: be generous with what you receive and be cautious about what you send.

If you only need a postcode, don’t validate your address. That way if I decide to split it into two lines you don’t need to pay attention to it.

Architect for testability: The ability to test something and how testable something is, is a pretty good indication of how well you have drawn your boundaries. If you focus on all levels of the testing pyramid you will have better architectures for your systems.

Conway’s Law: the dreaded people issue. Any system will reflect the communication (dis)function of any organisation.

If you want a three-stage pipeline, you have to have three groups.

Finally, she looked at how the principles will be affected in the next two years. According to Parsons, neither the "last responsible moment" nor Postel’s Law will not be affected.

Even though the principles will remain the same, there will be more innovation resulting in the building of more robust, more "immune" systems. More than just the incorporation of innovation in the complexity of the systems like IoT, Augmented or Virtual Reality, more innovation will happen in the way how Machine Learning models will be tested. AI-assisted development will facilitate the development of different types of development techniques like Test First Development - where the developer could write the test, and the AI generates the code or the other way around.

All these will be possible with enhanced continuous deployment pipelines, increased reliance on testing in production, and broadening of the suite of fitness functions and approaches.

She closed her talk by concluding that:

These principles remained constant throughout time and there is no indication yet there is a principle that we are missing. Practices will evolve, but not radically change[...] even though innovation will change the tools, the principles will hold. Evolutionary architecture will evolve, but it’s unlikely to be a revolution.

About the Author

Rate this Article