A disambiguation of "architecture"

I've lost count of the number of times that I've been asked what it is that an architect at a technology organisation does. I mean, it's pretty straight forward, isn't it? They are someone whom architects... stuff, right?! Or is it services? No, maybe software? Or systems? Maybe they architect applications? The answer requires that you take step back and think of technology problems at a level of abstraction above what you would typically.

I find that it doesn't help that the role is generally a conflation of a wish-list of responsibilities and that architects, too often, don't know why they are architects.

What is "architecture"?

Unsurprisingly, there have been many attempts to define "architecture" in the context of a technology organisation. Grady Booch once described it as a representation of "the significant design decisions that shape a system, where significant is measured by cost of change". Ralph Johnson, tongue in cheek, penned a popular one; "It's the stuff we wish we could get right at the start of a project". Dave Farley offered an extension to another of Ralph's in one of his recent videos: "it's [a snapshot of] the shared understanding the expert developers have of the system design".

You can see, immediately, that these are all quite different. Grady's tends to imply deliberate design and upfront work. Ralph's pokes fun at and reinforces a meme or common sentiment among developers. Dave's is quite analytical, my personal favourite though I feel he is focusing specificaly in the context of software development. Importantly they all seem to be tackling this at slightly different levels of abstraction.

It's probably a good time to highlight that there are many different types of architecture but they all have something in common — they are a set of evolving constraints applied to a complex system to meet a collection of functional or non-functional objectives. How these constraints are applied and to what system they are applied to is specific to the domain within which they are practiced.

What does an architect do?

With that rather dry description now out of the way, let's talk about architecture in the context of the role of "Architect". What exactly does it mean to be an architect and why do organisations need them, especially as they change?

When we architect (the verb) something, we plan to meet some need through the creation or adaptation of a complex system. It's the process of understanding the relationship between the different participants in that complex system that underpin why an architect (the noun) is a necessary component of any mature technology team. An architect (specifically in the role of "Architect") deploys domain expertise in applying constraints to large software and organisational systems (systems comprised of both technology and people) to meet the needs of the business, all while maintaining and socialising a shared understanding of the current state of the world. It might be useful for us to define the title of "Architect" as "Technology Organisation and System Architect"... one heck of a mouthful. An architect can help an organisation answer or provide input on questions like:

• Can we derive value from having multiple teams contribute to this system at the same time? How?
• How can we scale this system while taking into consideration our operational budget and the overhead experienced by the teams?
• How do we influence teams to address technical debt alongside their product delivery?
• We have this fundamental organisation need/problem, how might we solve that with technology? Or, how might we deploy X vendor's product to solve it?
• What shape should our organisation take to best meet the needs of our system, product, and business?
• What is our trust model? How do systems communicate, validate their identity, and restrict what actions each can take?
• Our teams keep running into this similar problem that is difficult to solve, or there is a gap in our technology landscape. Does it look like a consistent, distributed key-value store might fill that?
• How do we meet the growing needs of our customers while keeping in mind the operational overhead of our technology landscape?
• When should we sunset this piece of the system to meet our business goals? And should it be replaced? How?
• How can we start to move this heckin'-big, on-premises, distributed-monolith to the cloud?
• What are some of the fundamental ways we should secure our systems?
• How can our teams deliver software that meets our non-functional obligations?

Shh... It's not about code

An Architect (the role) does not typically architect code. Insomuch as they don't sit down and design the way the objects, classes, instances interact or the overarching coding patterns employed by a team. Where they may get involved in the design of an application is when they must advocate for the needs of other teams or the business. For example, a large monolithic application that requires contributions from many teams across an organisation may need architectural input to guide the developers in building the underlying software architecture to facilitate that need, perhaps guiding them towards a platform-like architecture. They don't design or architect software themselves — software developers do that.

Everyone is responsible for architecture

If I could suggest that you take one thing away from this it would be that everyone in a technology organisation is an architect. We are all designing and architecting the future, just at different levels of abstraction, and it's important that we do the best we can with the information that we have at the time. Being a great architect is rarely ever about knowing if we can, but instead understanding if we should. You won't always make the best decisions, but it's important that the poor decisions (in retrospect) are made with purpose and with the understanding that things will change — a concept that should be built, fundamentally, into every system.

"Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental." — Grady Booch