Dylan Beattie

It is not uncommon for software engineers to be eventually decorated with the grade of “software architect” in their careers. Logic would suggest that the latter, the better, but I have seen many a fresh graduate with such a stamp on their job offer, and a correspondingly worried look upon their faces. For the responsibility is high, yet the job description is as vacuous as one might expect from the almighty software industry. Graduate students get very little coaching from their alma maters before becoming “architects”, so they wander in life asking themselves how to become one, let alone how to be good on the job.

Thankfully, it is 2024, and we can call YouTube for help; if the preceding phrase does not worry you, we clearly do not have the same values. We have to invoke the powers of those who have been architects before us, to understand the intricacies and the dangers of the profession. Yes, dangers, because just like “real life” architecture can fall upon your actual head, bad software architecture is harmful in various ways, starting with the anecdotal ones, and ending with the life-threatening ones.

One of the best examples of explaining architecture to software engineers on their call of duty is what Dylan Beattie did in his NDC Oslo 2019 presentation “Architecture: The Stuff That’s Hard to Change”, which, incidentally, is our Vidéothèque movie of the month.

Dylan, a gifted coder, musician, and trainer, starts with the obvious definitions, because the word architect is, of course, borrowed from the field of building design and construction. This is a long tradition in our field; software architects are not designing Brasília, yet just like a “bug” or an “adapter” or a “linker” mean different things to non-software folks, here we are.

So, before software “architect” we needed software “engineers”. As Dylan rightfully mentioned, and as legend has it, Margaret Hamilton (of whom we have already talked in a previous edition of this magazine) was the first software engineer, or at least the first person to call themselves such.

A few years earlier than Margaret, the first people to use the analogy of architecture in our field were two IBM engineers (of course!), called Eliot Noyes and Fred Brooks. You might have heard of the latter, for sure.

Noyes’ use of the term computer architecture transformed computer engineering by applying principles drawn from modernist architecture—specifically, Ludwig Mies van der Rohe—to IBM industrial design.

(From “Computer Architecture: How a Metaphor Transformed the Computing Age. It Began with an IBM Industrial Designer named Eliot Noyes.”, May 2018)

The quote above comes from a summary at the IEEE Computer Society website of a March 2018 article on the “IEEE Annals of the History of Computing” called “The Origins of the Architectural Metaphor in Computing: Design and Technology at IBM, 1957–1964” in which the author mentions Fred Brooks’ inspiration:

While the introduction of the metaphor may seem relatively natural for Noyes, who was a practicing architect, Brooks came at it from a different direction. Brooks was a trained computer scientist, a product of Howard Aiken’s pioneering program at Harvard. The architectural metaphor represented a way of understanding his own new and rapidly evolving field.
(…)
Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that the design will be economical and feasible; but the emphasis in architecture is upon the needs of the user, whereas in engineering the emphasis is upon the needs of the fabricator.

Suffice to mention that it is because of Fred Brooks that the computer in front of you has 8-bit words. Talk about impact. (And yes, there were lots of computers, before and after Fred Brooks, with other sizes of words. But that is material for another edition.)

Dylan links the increasing attention required to architecture to the explosion of software in the world that happened during the 1990s thanks to Windows, Visual Basic, and the World Wide Web. Books such as “Software Architecture: Perspectives on an Emerging Discipline” published by Mary Shaw and David Garlan in 1995 set the tone for this new field of activity.

We have, at this point, at least two questions. The first one is, what does a software architect do? Well, as Dylan clearly explains, their job is to come up with ideas for software designs that they are not going to write themselves. The problem they have is how to transport those ideas from their brains to the poor souls who will have to bear the task of translating the boxes and arrows into actual lines of Java code.

This reality can seem both a trauma or an advantage for the newly appointed architect, depending on their level of comfort with the task of writing code. Some people excel at coding; some others at telling others what to do. But Dylan is very clear about one thing: he thinks that yes, architects should code, too, even if they should avoid becoming a pain in the neck bottleneck.

Your job as an architect, then, is to bridge the impossible dialogue between business and tech; to make developers understand the constraints of their organization, of their technology, to build the best possible product that could be built. And yes, I would add, also to explain those same constraints to managers, and to defend their team with all their might.

The architect’s job, as Dylan points out, does not stop at making and communicating decisions, but also at reinforcing them. It is effectively their job to deliver a solid system, and that includes validating it (that is, making sure that the team is building the right thing) as well as verifying it (making sure they are building the thing right.)

Second question: how do architects work? Dylan answers this one with a series of 5 questions that they should ask themselves before taking any new assignment, or drawing any box or arrow on the whiteboard:

1. What do they have?
2. What do users need?
3. What can be built? The answer of which might include a trip or two to Martin Fowler’s bliki.
4. What can you buy? The answer to which includes an epic quote to remember: “Never use Powershell when you could use Mastercard.”
5. And finally, what can you lose?

Nobody said the answers to these questions would be easy, though; hence, the core idea (and title) of Dylan’s talk: “Architecture is the stuff that’s hard to change”. Not a bad definition as far as I am concerned, and an excellent set of kick-off questions to keep in mind as you are promoted to architect in your next assignment.

If you have just been appointed to such a role, and a search engine brought you to this page in desperation, just take a deep breath and watch our Vidéothèque movie of the month: “Architecture: The Stuff That’s Hard to Change” by Dylan Beattie, on YouTube. You will be thankful you did.

Cover snapshot taken from the video.

Continue reading Amy Brown & Greg Wilson or go back to Issue 069: Architecture. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!