Basics of Software Architecture
The role and definition of a Software Architect today are different from what they were a decade or more ago, and they will be different in ten to fifteen years. This is due to the evolution of software architecture which has seen a frequent change over the years: new patters, new principles, new abstractions, ... This is why it will be difficult to find an evergreen job description (don't even get me started on the fact that different companies also describe this differently) but the best I can do is get a snapshot of what a software architect looks like today. To do so I'll talk (informally) about software architecture basics to help understand the range of responsibilities of an architect.
As I look at how an architecture is talked about in conversation across the industry I realize that we often define one aspect of a system. I remember a friend of mine asking me about the architecture of Triggers at MongoDB and my answer for it was along the lines of "it's an event driven system, we use a mediator pattern". I didn't add much to that but realize that I oversimplified and missed many aspects of it. Sometimes we even just use the structure of a system to define a whole architecture "it's microservices all the way down!".
I recently read the work of Mark Richards and Neal Ford and they are able to give 4 aspects that cover what "architecture" means in the software industry.
Structure
This is the architecture style. You should be familiar with things like microservices, monolithic, layered, event-driven. I bet you big money that if you look at how microservices are implemented at Netflix vs Amazon vs Google you will see significant differences. This is to say that a system architecture is not just defined by its structure.
Characteristics
Independent from its structure what should your system be like to function successfully? Is Security a strict requirement, or is it its Scalability? The ability to satisfy Performance, Reliability, Security, Testability and so on is how you would describe the characteristics of a system. At this point it doesn't matter if the structure is microservices or monolithic. Keep in mind that these are often driven by business requirements that the architect translates into system characteristics.
Constraints
Which service can access the DB directly? As we make these decisions for our architecture we are effectively defining constraints. An example of this can be the decision that every service in a microservices architecture has to vet every request through an Auth service. The decision here can be that every request that enters the system should be vetted and that the Auth service implements the vetting while every other service is responsible for satisfying the constraint.
But what if due to other constrains this one cannot be satisfied? This can be OK as long as there's a process for making this type of decisions. This is what is usually referred to as a variance.
Design principles
These are guidelines which differ from constraints or rules. I find this easier to reason about when you associate it with the characteristics of a system. For example you might want a service to have fast deployability. This does not dictate HOW it needs to be achieved but just that it should achieve it. We stay away from implementation details and focus on following the principles.
Thoughts
This is a natural way to think about a system but I rarely see a proposal outlining these pillars of software architecture clearly. I think that Characteristics and Constraints are driving factors, at the end of the day they define requirements more strictly. The structure of a system can vary and some are more suitable to fit certain requirements BUT you might operate in a system that makes a specific structure a requirement. Think about a medium-large company moving to a microservices architecture, that now becomes a requirement. Design principles can become service specific so an architect might have more freedom on defining which ones to follow (e.g. reactive vs non reactive framework). That said, everything must come together in a meaningful way. No matter what choice is made it has to make sense in the context of the system you're building.