Over several years of working in software development I have come to realise the term “architecture” means different things, to different people, in different contexts. More recently, there have been a couple of things that have caused me to think more deeply about this long and widely held belief and try and investigate towards a more formal, precise definition of what software architecture is, if one does, or even should exist at all.
The first thing was I read the excellent 97 things every software architect should know book. It contains 97 small pieces of literature from various contributors about core software architectural principles. It struck me as I progressed through the book that the various chunks of advice could all be considered at varying levels of abstraction in the context of designing a system. For example, we could apply some of these concepts at system level, in how disparate systems, running in their own process communicate with each other. The same principles on some occasions also made sense at a lower level of abstraction when thinking about how different internal components in a system, existing within the same process, communicate.
The second thing that made me think about what software architecture means lately was being involved in a hiring drive in my current place of work. We were hiring for a senior engineer and throughout the process and the various candidates we interviewed we would probe on how they would set about designing a brand new system from scratch. Naturally, the engineers we interviewed gravitated towards describing the architecture at quite a low level of abstraction. For example, some would talk about hexagonal architecture and how their application code would be designed and organised to follow this architecture. There was another candidate, who upon first reviewing their CV I formed the opinion that many of their more recent roles were more hands-off the code roles, that involved making decisions at a higher level of abstraction than the application code. A position that people would typically term as a software architect. When we asked this candidate the same question around designing a new system from scratch, they immediately started describing the architecture of their proposed system at a far higher level of abstraction. If we consider the engineers talking about their architecture from a ground level view, then this candidate can be thought of as speaking from a 10,000ft view of the system. They described the system in the terms of deployment architecture, discussing a microservices driven approach and the benefits of such an approach from an availability and resiliency perspective, all valid observations. However, this set a lightbulb off in my head around the varying interpretations of what architecture really means.
After this I thought more deeply about this definition and decided to ask ChatGpt what the definition of software architecture was:
Software architecture refers to the fundamental organization of a software system, including its components, their relationships, and the principles and guidelines governing their design and evolution over time. It provides a high-level view of the system's structure and behaviour and defines the overall framework within which individual components can be developed and integrated.
Software architecture is typically concerned with defining the software system's key properties, such as its reliability, scalability, performance, maintainability, and security. It also involves defining the interfaces between different system components, specifying the communication protocols used to exchange data and control flow, and ensuring that the system as a whole meets the functional and non-functional requirements of its users.
In practice, software architecture involves making a series of design decisions that are based on the goals and constraints of the project, as well as on the experience and expertise of the architects involved. These decisions can involve choosing the appropriate software patterns and frameworks, selecting the most suitable technologies and platforms, and defining the system's overall structure and organization. The goal of software architecture is to create a system that is efficient, reliable, and easy to modify and maintain over time.
When you read the above AI generated definition, I can’t help but think that this theme, that I’d been thinking deeply about, of architecture meaning different things at different levels of abstraction, in different eyes of beholders, being very apparent. However, the definition generated was quite contradictory; it describes architecture as a “high-level view of the system” yet mentions low level concerns such as software patterns and frameworks too. All the above made me consider whether it was worth it or valid to be in any way precise about what software architecture is. ChatGpt certainly couldn’t be precise about it anyway.
I then started thinking about the application of architecture and behaviours of architects in the various organisations where I’ve worked over the years to get closer to a concise understanding. I considered which models, approaches and behaviours worked well and not so well to see if that led me to a relevant and somewhat precise definition. When I thought specifically about the role of the architects I have collaborated with in this time, their behaviours and their associated organisational structures I narrowed things down to three categories:
Inhabitants of the ivory tower
Ivory tower architects are a well understood type of architect who are isolated from the context that concerns them, inhibiting their effectiveness at enabling their wider technical “peers” to make key decisions and as a result create environments where we build things that are difficult and expensive to maintain and understand. Ivory tower architecture tends to result in unidirectional communication and subsequently stifles collaboration.
At a particular client I worked with a few years ago they had a top-heavy collection of architects, where their role was precisely defined in that they were the gatekeepers for practically every technical decision, even at a micro level. The process would be that technical leads would produce reams of documentation around how they would design and organise their code and await approval from architecture so the dev teams could go off and write this code. The result of this was a drag on the ability to deliver features, an increased level of re-work where projects were perpetually restarted and re-designed and an inability to nimbly react to changes in requirements and priorities.
Nomads
The nomads are a group that I have defined in my own mind, they can be best thought of as a hybrid between the ivory tower architects and the enablers. Nomad’s tend to try and be enablers but slip into being inhabitants of the ivory tower on some occasions, forming poor lines of communication in certain situations, usually when cost and resourcing becomes a factor in technical decisions. They abandon communication and pragmatism in these instances and often leave the dev teams they engage with confused and disillusioned. The other pole of the nomad tends to be when they try and enable but instead muddy the waters to the extent dev teams can become rudderless. The nomad in these kinds of situations doesn’t have enough deep knowledge of the context of the domain they operate in or the technologies and/or approaches they are considering. Nomads in my experience struggle to clearly articulate the why around a lot of the decisions they make or the advice they provide. In these scenarios the nomad tends to distance themself and goes off to try and solve another problem, muddying the waters in another entirely different context.
A client I worked with several years ago had a nomad architect who worked with my team, an embryonic team, newly formed, who had little domain knowledge and needed support in this sense. The domain itself was complex, with many unknowns and was being re-engineered to represent something far different to what the legacy domain represented. Furthermore, the deployment architecture was largely undecided (public cloud v on-prem) and was a key requirement in unblocking the team from a design point of view. Instead of supporting and enabling our team in terms of facilitating the passing on of domain knowledge or driving collaborative decision making around deployment, the nomad was largely conspicuous in their absence. This led to a JIRA board where most items were perpetually blocked and delivery ground to a halt and the team became disillusioned.
Enablers
I’ll freely admit my opinion of the value of the role of the architect was somewhat dubious until around 18 months ago when I started working with my current client. With the benefit of hindsight this probably said more about some of the organisations I found myself working with than the value of the role itself. The role of the architect in my mind now couldn’t be clearer and that’s largely due the positive experiences I’ve had in the last 18 months and the relationships I’ve built with our own architects, the enablers. These types of architects in my experience are the most effective, approachable and knowledgeable. They add huge value to the development teams in an organisation and in turn their ability to deliver good quality software. They provide omnidirectional lines of communication, they have deep (enough) understanding of the context and the problems dev teams are trying to solve and they are clear on the how and why around the technology choices they provide direction on and how they fit into the wider technical business strategy. The most useful facet of the enabler is that they provide a sounding board to their peers and are clear on why they think the things we propose are good or bad ideas, In the case of the latter they have the knowledge to provide better alternatives in a clear and constructive way and crucially explain why.
In conclusion, where have my recent experiences, my thinking about what architecture is and the role architects have to play got me to in defining what software architecture actually is? The short answer is no closer. I don’t feel there is a standard, one size fits all description of architecture. It’s an ubiquitous term and concept that envelopes all aspects of software and system design at varying levels of abstraction, from deployment at 10,000ft to organising application code at ground level. Architecture is an emergent behaviour that means different things in different contexts and what makes a good architect in my experience is analogous to this. A valuable architect is someone who enables developers to write software systems in a timely manner that are easy to change and reason about. How these enabling architects do that isn’t an exact science, the same way defining architecture itself is not and trying to be exact about either in my experience is counterproductive.