Dr Andrew Leigh CITP MBCS reflects on 25 years of professional experience as a software architect and offers his insights and a reading list of recommendations.
‘Software architecture’ covers how we satisfy stakeholder concerns by making decisions, and how those decisions are realised as software components and connectors. Architectural decisions can be difficult to change once embodied in code, and determine whether software supports the competing quality attributes that stakeholders are concerned about. This means architecting is pivotal to software development. The award-winning book Software Architecture in Practice by Bass et al. covers the topic well.
My software architecture thesis cited 113 academic papers published between 1981 and 2021. Having had time to reflect on the literature, this article offers the papers and books that resonated the most. There is no scientific basis or rigorous criteria for my selections — I merely selected what rings true when looking back over 25 years of industry experience and, in my opinion, provides useful findings for practice. With fair warning of the caveats, I present my four selected findings.
Finding one: tools and ideologies must fit practice to be widely adopted.
The first selection, Marian Petrie’s 2013 paper UML in practice, investigates practitioner usage of Unified Modelling Language (UML). Marian interviewed 50 informants with experience across 21 industry domains from across the world. Most informants (70%) said they didn’t use UML and of those that did, most used UML selectively (22%), employing class, sequence and activity diagrams the most for stakeholder communication and collaboration. Marian identified that practitioners think UML is useful when the diagrams are fit for their purposes, capture structure at the right level and make behaviour explicit.
I’ve used UML on several projects. Using UML to design an Application Programming Interface (API) enabled teams to advance before the API had been developed. In contrast, an expansive set of carefully composed use case diagrams were hardly used because developers had little motivation to understand them when the requirements were readily available in text. My experiences echo Marian’s conclusion and her work reminds me that developers should have the loudest voice when deciding what tools to use and how to apply them.
Since reading Marian’s paper, I have discovered Simon Brown’s C4 model for visualising software architecture, which chimes with Marian’s work. Simon advocates describing an architecture at four levels as required (context, containers, components and code), whereby developers can zoom in from one level to the next.
Finding two: architecture smells really are a problem. Consider refactoring.
Architecture smells are indicators of deeper problems in code that can cause symptoms such as error proneness, change proneness and technical debt. Many articles suggest architecture smells are problematic, but what evidence supports that?
In 2015, Mo et al. expressed common architecture smells such as unstable interfaces and cross-module cycles as formal signatures in their paper Hotspot Patterns: The Formal Definition and Automatic Detection of Architecture Smells. Formalisation enabled automated searching to see if the smell signatures could be found in 10 Java projects sized between 56,000 and 2.3 million lines of code. The team observed that the more smells code has, the more likely it is to be error prone, and the more effort will be required to fix and modify. Whilst other work has shown correlations between quality metrics and error proneness, this work shows developers what code structures to look for to avoid problems. Building on Marian’s findings, the paper is important because developers understand code, but they do not necessarily know and understand metrics.
This work gains further importance when combined with research into technical debt. In their 2019 study Software developer productivity loss due to technical debt — A replication and extension study examining developers’ development work, Besker et al. showed that almost 25% of developer time is typically wasted by technical debt such as architecture smells. This means architecture smells and their associated technical debt must be managed, for which Carola Lilienthal’s 2019 book Sustainable Software Architecture offers a wealth of practical advice.
Finding three: all architectures have pros and cons.
I’ve seen many architecture styles, patterns and frameworks rise and fall over 25 years — I was lucky enough to work with two visionaries who introduced me to service broker architectures as far back as the year 2000. Since then, webservices and microservices have come to the fore and few architectures have been more hyped than microservices.
For you
Be part of something bigger, join BCS, The Chartered Institute for IT.
In 2018, Soldani et al. published The pains and gains of microservices: A Systematic grey literature review, presenting their thematic analysis of 51 articles written between 2014 and 2017, authored by 40 organisations, identifying 29 pains and 34 gains of microservices. This paper provides a crucial reminder that all decisions are subject to trade-offs no matter the hype surrounding a technology — a point reinforced by Mendonça et al.’s more recent, fantastically titled: The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture. May the force be with us.
Finding four: think team, stakeholders, and continuous architecture!
My fourth selection is a fitting mission statement for software architecture. In the The Pragmatic Architect Evolves, Eoin Woods and George Fairbanks reflect on how technology advancing through the five ages of software systems (monoliths, distributed monoliths, internet-connected, internet is the system and intelligent connected) means that practitioners must always be ready to adapt.
Their finding that architecting responsibility should be shared across the team reminds us that software development is a socio-technical discipline and a team game because it depends on the joint optimisation of people and technology. Eoin delivered a compelling talk about this theme, Democratising Software Architecture. It reminds me of when a great mentor once said, ‘Andrew, it always comes down to people’.
Four for further reading
We have reached 2021 — so what’s been on my reading list since then? Here are my top four picks.
- Recently, AI has led the hype standings, which begs the question: what role will software architecture play in AI? That is the subject of Software Architecture and Artificial Intelligence by Malavolta, Muccini and Ozkaya
- According to Power Hungry Processing: Watts Driving the Cost of AI Deployment by Luccioni et al., its role will be responsibly leveraging AI to improve life whilst addressing the staggering energy consumption and environmental impacts
- Architecting for Sustainability by Andrikopoulos et al. is a great insight into green IT
- Marquez et al.’s 2023 study Architectural tactics in software architecture: A systematic mapping study is helping me understand my blind spots, revealing unfamiliat architecture tactics
I will end by reinforcing Eoin and George’s point: that we must be ready to learn, adapt and evolve to be effective in the team game of software development.
