Software architecture is quite a big topic. I would argue that it ranges from software design patterns all the way up the design and configuration of cloud infrastructures, and the development of software development and deployment pipelines.
Software architecture features in a number of useful Software Engineering Radio podcasts. What follows is a brief summary of two of them. I then share an article by a fellow TM354 tutor and practicing software architect who shares his thoughts from 25 years of professional experience.
An important point is that there are, of course, links between requirements, non-functional requirements and architectural design. Architectures help us to ‘get stuff done’. There are, of course, implicit links and connections to other posts in this series, such as to the one that is about Infrastructure as Code (IaC).
On the Role of the Software Architect
In SE Radio 616: Ori Saporta on the Role of the Software Architect Saporta suggests that design doesn’t just happen at the start of the software lifecycle. Since software is always subject to change, this means that a software architect has a role across the entire software development lifecycle. Notably, an architect should be interested in the ‘connections between components, systems and people’. ‘You should go from 30,000ft to ground level’ (13:00), moving between the ‘what’ problem needs to be solved to the ‘how’ problems can be solved.
Soft skills are considered to be really important. Saporta was asked how might engineers go about ‘shoring up’ their soft skills? A notable quote was: “it takes confidence and self-assurance to listen”. Some specific soft skills were mentioned (29:20). As well as listening, there is the need for empathy and the ability to bridge, translate or mediate between technical and non-technical domains. Turning to the idea of quality, which was addressed in an earlier blog, quality can be understood as a characteristic, and a part of a process (which reflects how the term was earlier broken down by the SWEBOK).
A software architect means “being a facilitator for change, and being open for change” in other words, helping people across the bridge. An interesting point was that “you should actively seek change”, to see how the software design could improve. An important point and a reflection is that a good design accommodates change. In software, ‘the wind [of change] will come’ since the world is always moving around it.
Architecture and Organizational Design
The second podcast I would like to highlight is SE Radio 331: Kevin Goldsmith on Architecture and Organizational Design. Goldsmith’s is immediately asked about Conway’s Law (Wikipedia), which was summarised as “[o]rganizations … which design systems … produce designs which are copies of the communication structures of these organizations”. Put more simply, the structure of your software architecture is likely to reflect the structure of your organisation.
If there is an existing organisation where different teams do different things “you tend to think of microservices”; a microservice being a small defined service which is supported by a surrounding infrastructure.
If a new software start-up is created by a small group of engineers, a monolith application may well be created. When an organisation grows and more engineers are recruited, existing teams may split which might lead to decisions about how to break up a monolith. This process of identifying and breaking apart services and relating them to functionality can be thought as a form of refactoring (which is a fancy word for ‘structured software changes to software code’). This leads to interesting decisions: should the organisation use their own services, or should they use public cloud services? The answer of, course, relates back to requirements.
An interesting question ‘was which comes first: the organisational structure or the software structure’ (13:05)? Organisations could embrace Conway’s law, or they could do a ‘reverse Conway manoeuvre’, which means that engineering teams are created to support a chosen software architecture.
A really interesting point is that communication pathways within organisations can play a role; organisations can have their tribes and networks (49:30). It is also important to understand how work moves through an organisation (54:50). This is where, in my understanding, the role of the business analyst and software architect can converge.
Towards the end of Goldsmith’s podcast, there was a fascinating reflection about how Conway’s law relates to our brain (57:00). Apparently, there’s something called the Entorhinal cortex “whose functions include being a widespread network hub for memory, navigation, and the perception of time” (Wikipedia). As well as being used for physical navigation, it can also be used to navigate social structures. In other words, ‘your brain fights you when you try to subvert Conway’s law’.
Reflections
In my eyes, the key point in Saporta’s podcast was the metaphor of the bridge, which can be understood in different ways. There could be a bridge moving from the technical to the non-technical, or could be moving from the detail of code and services to the 30,000ft view of everything.
Goldsmith’s podcast offers a nice contrast. I appreciated the discussion about the difference between monoliths and microservices (which is something that is discussed in the current version of TM354). An important point is that when organisations flex and change, microservices can help to move functionality away from a monolith (or other microservices). A microservice can be deployed in different ways, and realised using different technologies.
I found the discussion about the Entorhinal cortex. Towards the end of my doctoral studies, I created a new generation of software metrics that was inspired by the understanding that software developers need to navigate their way across software code bases. It had never occurred to me that the same neural systems may be helping us to navigate our connections with others.
On a different (and final) note, I would like to highlight the work of an article called Software Architecture Insights by Andrew Leigh. Andrew is a former doctoral student from the OU School of Computing and Communications, a current software engineering tutor, and a practicing software engineer. He shares four findings which are worth having a quick look at, and suggests some further reading.
References
Leigh, A. (2024) Software Architecture Insights, ITNow, 66(3), pp. 60–61. Available at: https://doi.org/10.1093/itnow/bwae102.