I, Enterprise Architect

You first might want to quickly jump to the bottom and read a brief note about this essay.

In the information technology industry, we’re in an eternal naming game. Working actively in this industry for over 25 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 25+ 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.

The Architect’s Definition

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”. Here’s my definition:

“The very definition of the responsibilities, of the role, of a building architect, in the overall building process, is to ensure the realisation 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 realisation of the dream of the client, according to best practices and good principles.”

The Building Analogy

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 belief that it is a sound one.

This holds to some extent. 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.

The Three Phases

Initial Design Phase: The architect turns the informal dream into a formal specification - a high level representation with enough choices expressed to move forward.
Engineering Phase: Analysis takes the dream in formal representation and reduces the level of abstraction, making more decisions based on analysis and construction options.
Construction Phase: The actual building work begins. Even during construction, details emerge requiring decisions. The architect guides the client through these decisions while guarding the original dream.

Partner in Crime

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.

Software vs. Enterprise Architect

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 specialised sub-areas, ranging from enterprise architect, over solution architect, to integration architect and domain architect, application architect, cloud architect.

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

Post Scriptum

Since I initially wrote this thing, back in 2021, the world has evolved further, making the title “software architect” more confusing than its intended generalist meaning added value. Recent developments have led me to believe that I can avoid this confusion by adopting the title “Enterprise architect,” which is even more generic and focuses more on alignment of information and technology to the actual business, rather than just software.

URL: https://christophe.vg/about/I-Enterprise-Architect/ Author: Christophe Van Ginneken (Christophe VG)

👆