Since becoming a software architect, I have wondered what my core responsibilities are. If you are reading this, you are possibly asking the same question or simply confused by the software architecture definition in general. I personally haven’t found any definitive answer yet, but I hope you can help me find out.

The Problematic State of Software Architecture

First of all, there’s a certain stigma about software architects, that comes from the old understanding of the profession. For the sake of convenience, let’s call that term “an ivory tower architect”. A typical day at the ivory tower consists of meetings, those abstract “strategic decisions“, and making components of your system work together. I used to work with such people and their work day appeared boring. They never coded. I don’t recall whether they had a coding background, but possibly they did. Despite this, they were arrogant and hard to work with. The entire niche became so mythologized, in a bad way, that startups seem to abandon this position altogether. Because there’s this “bad” architect concept, we must have a good one, too.

Developers are smart, though, and as with any other group of smart people, they tend to have strong opinions on matters related and unrelated to their jobs. Just like any other opinion, they ultimately differ from each other. A company can tolerate a lot, but having a mess in their code base… Well, companies usually tolerate mess, too. Eventually, someone has to come up with a higher-level vision of the system, where semicolons and variable names do not matter. One can hate software architects, but doing software architecture is unavoidable: someone has to guide the system development, mentor people, and make technical decisions.

The Solution that is more of a Problem

People solve the lack of architecture in different ways:

• Assign a manager capable of making such decisions. Sometimes it works, but in my experience, a manager with a technical background eventually drifts too far away to the world of office politics.
• Assign an engineer instead. E.g. “Staff Engineer“. Given that we have no idea what exactly software architects do, this new role can have a list of similarly nebulous responsibilities.
• Forget the stereotypes and hire a software architect. Your software architect has to be a cool one. They have to code. They have to spend time with engineers, and assist engineers, but, ultimately, be something else than engineers.

I like the idea of “Staff Engineer”.

Does this person code? They do. Rumors are, they don’t paint buttons, or create CRUDs. They tirelessly run between departments, make prototypes, and sell ideas. They connect clueless teams. They make basic infrastructure, so the proposed applications work and can be shown to stakeholders. They mentor people if needed. Given that they move between departments, they have a bit of every knowledge available in the organization that people within those departments don’t, because they don’t know what knowledge matters. As you correctly guessed, the main benefit of a staff engineer is that they code. Despite having such an abstract role, seemingly disconnected from a specific product, they understand the flow of data in the company. No UML is capable of providing the same level of understanding. A good staff engineer is a glue and a grease at the same time.

Software Architect’s Classification Pseudo-science

People like to have their stuff structured. Uncertainties clearly bother some people, so you may come across a variety of classifications of architects. A popular one divides architects according to the software architecture function they primarily perform:

• Code
• Integrate
• Mentor
• Document
• Improve
• Sit in an ivory tower

You can come up with fancy names for architects that do one of them. The problem with a classification by function is that one cannot reliably normalize and share it between different organizations. No matter whom you ask, the idea of software architecture boils down to making certain decisions, that are apparently beyond the scope of an ordinary engineer. However, a good engineer does all of the listed activities with ease. The main function of an engineer is to engineer applications, by designing applications and writing code. This definition is so straightforward, you can move an engineer to another company and they will be able to perform this function. Something we don’t do with architects who, let’s say, only write good lengthy docs.

A Theory What Software Architecture is

Software Architecture is a vocabulary of engineering knowledge that contains grammar and lexemes that make sense in this specific environment (domain and organization).

• Grammar is a set of rules that engineers adhere to. Don’t push to master. Don’t test in prod. Don’t send internal messages through the Internet. Write tests. Dockerize. Don’t lock. Be performant. Use CI/CD.
• Lexemes are the tools the organization is supposed to use. Use Kafka. Use Redis. Don’t use Memcached. Switch to Cloud. Switch to SQS. PostgreSQL or MongoDB? Time series?

Software Architect is a writer of the vocabulary, an engineer who for one reason or another defines the terms: a list of technologies that the organization uses as well as requirements and boundaries. Similar to real human languages, the rules are often ad hoc. There’s always legacy code, we can’t do anything about, we call them exceptions, but keep up with a set of general, thoughtfully defined rules. 

The process of making connections between lexemes, taking into account our organization’s established grammar, is nothing other than software design. 

Don’t take this theory too seriously. It exists purely for illustration purposes. Writing software is inherently related to human languages for obvious reasons, therefore some common patterns can be drawn. Lexems can be used together logically, which has to be common practice so others understand the usage, too. The same applies to the grammar of software architecture. In any case, you may have your abstraction to help categorize the field.