I, Software Architect

In the information technology industry, we’re in an eternal naming game. Working actively in this industry for over 20 years, I’ve seen many methodologies, ideologies, roles, paradigms,… appear, soar and most often disappear. Each of them had a very distinct name and its share of advocates, all with the goal to find that silver bullet to rescue the software development process. And although all of them tried to overcome the shortcomings of those that came before them, they all succeeded and failed equally. After 20+ years a pattern emerges and the essence presents itself: “What’s in a name? That which we call a rose, by any other name would smell as sweet.”

My rose is software architecture, and since the very beginning of my professional career I’ve referred to my role in the software development process as software architect. There it is, a name. And very much like business representatives, product owners, program managers,… in short every possible stakeholder that initiates the process that eventually might lead to the actual development of software, does this: name that what he/she wants, I name my role. And that is also where I, as a software architect, step into the picture for the first time.

Naming something is important. Ensuring everybody is talking about the same underlying thing, might prove to be even more important. Initial stakeholders have a vision, an idea, a dream. The name they apply to it is important in their personal/business context, still typically triggers a lot of possible interpretations. Each of those interpretations can lead to very different solutions.

Why do I believe that the name “software architect” suits my role like a glove? Cross out the “software” prefix for a second, and think of the architect most people commonly know, the architect who drew up the plans for their house, let’s call her the “building architect”. Now, I know people have advocated that this analogy is a bad one, for various valid reasons. Personally, I believe this is mostly because they started of from an ill posed definition of the building architect in the first place. So here’s mine:

“The very definition of the responsibilities, of the role, of a building architect, in the overall building process, is to ensure the realization of the dream of the client, according to best practices and good principles.”

Here’s another definition you might have heard me formulate over the years…

“The very definition of the responsibilities, of the role, of a software architect, in the overall software development process, is to ensure the realization of the dream of the client, according to best practices and good principles.”

And there it is: my one sentence definition of an architect. As with many condensed definitions it benefits from some additional context, maybe some examples, to make sure it is fully understood, as intended. Here’s my backstory: In the early 2000s, I was preparing to build our first house. So I had my first hands-on experience with the building process, architects and all other parties involved. Today, while writing this thing, I’ve just completed the construction of my new home. On both occasions, I experienced the analogy from the other side and it reaffirmed my believe that it is a sound one.

As a I have a dream about what I want my house to be, I have strong ideas about how and what. I’ve seen many houses, flipped through many magazines, read tons of online articles, made my own drawings,… So, I know what I want, and how I want it. So who really needs an architect? I can explain what I want and have this built easily without one. In the end they simply draw some pretty pictures and give it to the actual construction builders. Right?

This holds… to some extend. If I, as a client, would settle for that level of service, I’d cut myself… very short. This was the mistake we made with our first house. We contracted an “architectural drawer”, who simply drew whatever we wanted. The result was a spitting image of our architectural capabilities: a very dull house that we couldn’t afford. We ended up with a (not even nice) drawing and had to go look for an actual architect.

Of course, we had to start over and had to reiterate and reduce our dream - something no-one likes to do. Only this time, we got feedback, feedback in the form of a magnifying mirror. While listening to our dream, the (new) architect mirrored what she heard, rephrasing it in more correct terms, explaining what it meant, outlining consequences, formulating alternatives, backing it up with her own previous experiences, introducing opportunities offered by different construction possibilities,… Basically, she translated our dream in (high level) building terms, explaining the best practices and principles that our own mental model had beautifully crashed into, resulting in the dull and over-budget design. This feedback loop resulted in many “aha erlebnisse”, allowing us to revisit our dream and upgrade it to the one we actually wanted.

When I recently took on the same process again, to construct my new home, I had even more concrete ideas on how I wanted my house to be. In a way, I was an even tougher client to my architect. Of course, I didn’t make the mistake again to consider the architect to be a mere drawer. I knew from experience that that would be a very bad, and costly, mistake. I went right back to my real architect.

Now, by that time, I had been a (software) architect for many years, so I had already formulated this mental model of “the” architect role, and had already discovered this analogy between both building and software architect. So I knew what I could, or rather should, expect from my (building) architect, and I’ve treated her accordingly: asking for and listening to her feedback, evaluating it and revisiting my dream as much as I could.

Although I was mid-40 and she was in her early 20s, although I tend to have a big mouth and am not easy to convince, she did an incredible job, she was a true architect. The feedback she gave, the ideas she coined, the previous experiences she brought to the table, the best practices she explained, all resulted in the home I’m 100% happy with, which is not 100% what I saw in my (initial) dreams, but was actually 100% what I wanted.

She didn’t make any final decisions, didn’t dictate any choices. In the end, every detail she put on (digital) paper was decided by me, as a direct representation of my (revised and upgraded) dream. And this is the absolute core responsibility of any architect: “ensure the realization of the dream of the client”. With the creation of the initial set of plans, the first iteration of the formalization of the client’s dream is realized. Because that is what both the building and development process have in common: the realization of a dream, turning this vague mental idea into a tangible result, turning the informal dream into a formal representation. Be it a home, be it software, in both cases, the end result is as formal as it can get. Still, this is merely the first iteration, and it’s an important one. The more correctly defined at this stage, the better the chance we end up with a happy client, who actually recognizes his dream in that result.

Most of the evolutions in software development address this problem: the end result is not what the client envisaged in his dreams. There are many reasons why this is a problem and they are inherent to the software development process. In contrast to methodologies, ideologies, paradigms,… I’m not addressing the problem here, I simply acknowledge it and project my role against it. No silver bullet here people.

Let’s recognize what the architect did in this first iteration: she turned the informal dream into a formal specification. A high level one, because it doesn’t include any construction details yet, no exact paint colors, no serial-number level decisions on materials, no dimensions of beams,… just enough high level choices, as expressed by the client, to be able to move forward.

So we enter the next phase: the engineering phase, which takes the architectural drawings and zooms in on every little detail, to come up with calculations for beams and other construction elements, along with technical drawings of those details. This phase does essential the same as before, hence I refer to it as an iteration: it takes the dream, now already in a formal representation, yet still at a rather high level of abstraction, and reduces this level of abstraction, again possibly revisiting some of the design ideas.

Even at this point feedback is formulated. I, as a client, can dream big, but some of those dreams are hard to construct in the real world. During this engineering phase, all aspects that are still too abstract, need to be clearly defined. Based on analysis and again forward thinking about actual construction options, more decisions have to be made, by me the client. The same holds for software development: The architect already took a lot of these aspects into consideration, based on previous experience, best practices and principles. Still, at every step in the process, feedback can and will emerge, requiring the client to evaluate it and possible revisit its dream.

This is where the continued role of the architect comes into play. Her responsibility didn’t end with the abstract drawings she made. She’s in it for the long run, because she needs to ensure the realization of the dream of the client.

And so, the architect becomes a true partner in crime, standing by her client every step of the way, capturing the feedback from analysts and engineers, evaluating it based on her own experience and ideas, explaining it to the client and coming to a consensus on how to apply the feedback into the iterated design and move forward.

After this second big phase, the analysis has resulted in clearly defined formal specifications of every aspect of the construction. Now, in phase three, the actual construction work can finally begin. And again, this phase is iterative. Even during the actual construction small or large details emerge - because reality bites every design in the butt - and additional decisions need to be made with relative urgency. This is true for the building analogy, this certainly holds for the software development process. And in both cases, things can go very wrong at this stage.

The architect, as partner in crime, still follows up and guides the client, translating the problems at hand, explaining the possible solutions, in short supporting the client in making a decision on how to resolve and proceed. This support especially extends to the level of guarding the initial ideas, the dream. When issues arise, decisions are often taken in a very focused scope. Not always, but often not taking the holistic picture into account. It’s the continued role of the architect to always frame the decisions in the broader picture, to ensure the realization of the dream of the client. This doesn’t mean the architect makes the final decision, nor that she has a veto. She needs to remind the client of his previous choices and decisions, pointing out where decisions might violate those, explaining the consequences, allowing the client to be fully aware of and confident when making decisions in this iteration.

It is clear that the supporting role requires a thorough understanding of each phase of the process and the architect needs to be able to talk not only to the client, but also to engineers, construction workers, analysts, developers, testers,… to ensure the realization of the dream of the client. To achieve this, the architect often has to dive into a very detailed discussion with engineers and construction workers, often actively challenging them or proposing alternative solutions, coaching them based on previous experience, all to ensure…

I guess my definition and the analogy are clear by now. So, let’s leave the construction site, return to the comfort of our software development world, and reflect on the picture we just drew.

Was I right, back in the early 2000’s, to call myself a software architect? Yes and no. Yes, because I believe it to be the correct name for the role I want(ed) to take on. No, because at that time, although I was actively working with software already for about 20 years at that time, I didn’t have the experience to back some of the support I had to give. Today, after having supported many organizations in hard software development processes, in many different business areas and in a multitude of technological environments, I feel comfortable to take on a broad spectrum of dreams, knowing that I will be able to support my clients in any way, throughout the entire process as an architect should.

Over the years, since I adopted the name, many methodologies, ideologies, paradigms,… have come and gone. The name “architect” has been applied in different ways, has been split up across specialized sub-areas, ranging from enterprise architect, over solution architect, to integration architect and domain architect, application architect, cloud architect,… All of them are valuable, clearly show the need for architecture, and depending on the size of the dream, one or more are required, and some others might be optional. I believe there are two different flavors of architects here to be identified, depending on the level of technology of the outcome of their work.

When I refer to a software architect I refer to the coverage of enterprise, solution and integration architects, focussing on the overall business domains and capabilities, along with the interactions between them.

When entering the realm of the actual domains, applications,… the focus shifts to the important more technological aspects, on a sub-scope of the overall dream.

Listening to, challenging and advising business stakeholders, resulting in just enough up front design to establish a stable goal and strategy to get there; supporting the business stakeholders and guarding their decisions throughout the different iterations, each of which adds more formality, up to the actual implementation; coaching analysts, being a soundboard for developers, establishing integrations, oversee consistency, in short: being a single point of contact to ensure the realization of the dream of the client.

That’s the software architect I wanted to be and am proud to be today.

#howcanihelp