This question - what is a software architect? - is a bit of an expansive one; I wouldn't think that I could ever answer it thoroughly, much less succinctly in a few article links. I do however think it's worth some time considering some of the different perspectives we encounter. I'd venture that a poll of 10 software architects would yield 11 answers to this question.

Is software architecture decidedly different from software engineering? The analogy with which these titles are made - that of architects, engineers, and builders collaborating over the construction of a building - would seem to suggest so. However, a software project is decidedly different (in almost every single aspect) from a construction project. This is my opinion, but I would put it to you that while "software architecture" is probably a definable thing, a software architect is not really so different from an engineer. Indeed, I would also assert that a proper software engineer must be engaging with and actively doing software architecture as a part of their job.

Should a software architect be doing anything different from an engineer? Well, perhaps not on the surface. I'd expect that an architect would be writing code about as much as someone with an engineer title, and I'd expect that an engineer would be as engaged with diagrams and ephemeral conversations about the nature of software as someone with an architect title. The separate titles then are probably most useful as a way to distinguish the primary focus that one has within a software team, and an architect would be working differently from an engineer insofar as the architecture would be their primary focus, or area of responsibility.

So is it useful then to separate ourselves out with titles of "engineer" and "architect"? There are advantages to having the separate architecture title though: to motivate the team to keep architecture as a primary consideration, to be a figure of wisdom or authority with respect to the architecture, or to be the "point person" to communicate architectural concerns to other teams or other departments within a company. Perhaps it's not a useful title to have, but a separate role or "hat" which a member of a software team wears; in fact this was the way I was introduced to the concept of architecture.

Having both had the title of "architect" and having been an engineer at firms which had this title, I can see its utility. To caution though: just as every piece of software, every product, and every team is different - sometimes radically different - so too are the roles of those we call architects. This is perhaps why there are so many different ideas of what architecture is, and what a proper software architect ought be. Perhaps there can't be a single, specific definition to encapsulate the idea, as the types of architecture and architectural concerns are necessarily so varied between software efforts, domains, and technologies?

To try to pin some universals down, I think I could say a few definitive things about architects. Architects should be coding, and actively involved in the engineering process. Architects should primarily focus on assisting all of the members of a development team - helping to ensure alignment and stimulating everyone to think architecturally. Architects shouldn't be dictators or cudgels which make demands - a somewhat common perception which is unfortunately sometimes earned. Architects should strive to be the most approachable and collaborative members of a team.

While architects should be very technically knowledgeable, I don't know that they should have all the answers when it comes to architecture itself - curiously, I think the best architects are ones which are very creative and can help brainstorm architectural ideas, the idea being that they act as an enabler of a team to define a good architecture, rather than dictating an architecture from the start. In a difficult twist, this does mean that sometimes the architect will need to furnish a specific recommendation upon request, for example for a team in a tight bind which requires a quick resolution to a difficult problem.

I can hear a colleague of mine saying now: "This answer is so nonspecific as to be only slightly more helpful than a software architect theirself!"; unkind but not unfounded. I put it to you though that the composition of any software team is a jigsaw puzzle balancing who can do what with which areas of expertise are required of the technology and domain, and from team to team the jigsaw piece labeled "architect" will be a very different shape and in a very different place in the overall puzzle.

Links

• How to Become a Great Software Architect - Eberhard Wolff (2019)
• How we do Architecture at Okta - Monica Bajaj and Mark Voelker (2023)
• Democratizing Software Architecture - Eoin Woods (2023)
• How to "think" (and design) like a Software Architect - Ron Kleinman (2019)
• How I became a software architect... (or not) - CodeOpinion (2023)

I was recently recommended Mark Richard's series "Software Architecture Monday", which is a part of his site dedicated to developing more architects. This series is well-thought-out, and contain a few excellent articles/videos which contain insights directly related to this topic:

• The Role of a Software Architect
• My Architecture Journey: Lessons Learned
• The Software Architect's Bookshelf
• Agile and Software Architecture