A Cause For Breadth

Definitions

The Role As It Is Defined In Software Today

On Techopedia:

“A software architect is a developer who is responsible for the high-level design and strategic planning of new software products. This can include hardware planning as well as the design methodology of the code.”

On Wikipedia:

“A software architect is a software engineer responsible for high-level design choices related to overall system structure and behavior”

The Role As It Is Defined “Offline” (Brick & Mortar)

On Wikipedia.org:

“An architect is a person who plans, designs and oversees the construction of buildings.[1] To practice architecture means to provide services in connection with the design of buildings and the space within the site surrounding the buildings that have human occupancy or use as their principal purpose.”

There need be no similarities in definition or in practice between these two within these two vastly different industries, but one sees curious similarities at a very high-level, and because analogs are often so useful in understanding our world we seek to use brick-and-mortar as our analog here.

The impulse to do so is born from needs accumulated across multiple organizations over the years, revealing opportunities for improvement upon the definition and execution of the role within the software community, all done simply by taking some clues from historical definitions.

As water is analog to electricity, so too can be earth and its structures an analog to computing technology. The buildings of apps built upon the firmament of electricity.

Why Definitions Matter

Well, they matter a whole lot in software. But I’m not talking about definitions within the code itself. In our modern day, our personal identities themselves are torn and mired in brooding definitions awaiting (r)evolution. So there is great cause to take language seriously and its effects on our lives, and so too then we aim to take our roles seriously, if not a bit more literally.

Common implementation of the term and/or role Architect (in computing) nowadays refers to a blob of ever-changing nebulous tasks. But the fragmentation of roles, though not always a bad thing, can often lead to the weakening of the impact (and value) of the individual, which creates challenges for both the self and the org.

So we aim to zero-in on the definition of the “Architect” role, interpretations of the word “design” and how it comes to be practiced, the end result or product of architecture, the title’s debatable inclusion/exclusion of hardware, as well as the divergent use of human-centric language across these definitions.

It’s important to note that no definition is inscrutable, or rule of law. We interpret definitions, and they evolve with us. And in practice, day by day, they are debated, often with bias. Definitions seek to establish clarity and distinction, especially when none are present, or when their presence is felt too greatly. They are boundaries around ideas which often overlap with similar but different definitions. They increase alignment and order, which is often quite desirable in our work.

Ultimately, this all came about because I just take my job seriously.

What We Aim To Do

This effort exists for both the individual but for the whole of the group, and for several reasons. The re-defining of the role seeks to be a form of empowerment, an enriching, ideally resulting in ever-better product PoCs and more valuable team members.

The first of our motivations to broaden the definition of this role is clearly & simply the comparison to (and presumably the inheritance of) the title from the real-world age-old historic title; this is a prestigious role with societies and myths surrounding it. The practice of which in today’s world requires degrees and the swearing of an oath, presumably in-part at least because of the role’s implicit responsibility to adhere to the fundamental physical laws & properties we are constrained within, but also to protect life within its structures. We see more and more each day, the Software or Hardware Architect faces similar responsibilities and challenges today; protecting life within our technology products becomes increasingly harder with each cycle. We might as well sign an oath too. This is also due to the inherently broader nature of the earliest “online” roles matching the job description, previously known as “webmaster” (circa 1998-2009) as defined by Wikipedia or more colloquially by Justin Jackson, a term no longer in-use or perhaps entirely out-of-vogue. There is also an inherently open & accessible nature to both software design & development; without leaving one’s own seat, one can see-through the entire process of software creation, from vision to publication, soup to nuts. In a more “heady” sense, some job functions should require (or rather, are greatly enhanced by) the use of both hemispheres of the brain, as described on PsychologyToday in a survey of the popular book “Drawing On The Right Side of The Brain”. Another reason being the efficiency provided to a team when an Architect creates a design prototype and a PoC with code.

Note: It’s worth mentioning that not every known definition of the term “webmaster” or “architect” acknowledges a responsibility or requirement of the understanding or aptitude of design or design-thinking, but the vast majority do.

Enhancements (Nudging) On Scope Of Definition

• Common definitions include design, but often fall short in practice.
• Comparison to the broader scope of the real-world and age-old “architect” title.
• Historical beginnings of early “webmasters” embracing a wider range of responsibilities.
• The open & accessible nature of modern design and development tools and skills.
• Efficiency benefits of multi-hat operation, especially throughout prototyping and Proofs of Concept (PoCs).
• Missed opportunities for integrating bleeding-edge tooling-awareness directly into the design phase.

Conclusion

By taking a cue from the historical and broader definition of an architect, especially in the brick-and-mortar world, we can enrich and empower the software architect role. This expanded perspective fosters a deeper sense of responsibility, encourages a more holistic approach to design and development, and ultimately leads to more robust, valuable products and more impactful team members. It’s about recognizing that the “cause for breadth” in our definitions directly correlates to the depth of our impact in the ever-evolving landscape of technology.