The position of Software architect is one of the most confused concepts of the entire software industry in my opinion. Despite being very simple at first glance, it can become very messy when companies and developers try to implement it.
Let’s start off by talking about the position of software architect itself. Who should occupy the position? The oldest developer, right? Wrong!. Is the company’ star developer eager to get a promotion otherwise will quit whom should get it? Probably not!. The most experienced developer? Maybe.
Well, who else should get it then? Ok, first of all, it is important to understand that software architect is not a title or position like the others but a very important one, vital for the health of the company’ software and so it shouldn't be take lightly. That way, the answer to the question lies in what a software architect really is.
Ok. then, what is a software architect? A software architect is software developer whose only responsibility is to create and watch over the entire software architecture.
No, seriously. I like to consider this position like some sort of a guardian. They are responsible to guard the code quality, establish general rules for writing the software, design patterns used throughout the codebase as well as the user experience with the code. They are also responsible to design other aspects of the system like: reliability, fault tolerance, code quality, code maintenance, code refactoring, services communication, services orchestration among other things. They are responsible to choose which architecture (MVC, MVVM or DDD?; Monolith or microservice?; etc.) will be used. Their decisions will directly influence the development speed, maintainability and code reliability (how much do you trust your software?) and the most important one for the company: The profitability of the software.
It is also important to note that you cannot be a software architect and developer at the same time. If you put any good software architect to write a good software architecture and at the same time a very complicated and important functionality for the company’ software, they will write a shit code and that's a fact. The pressure to deliver the functionality will blind any good architecture or principles and will block their creativity to write a good code. That's why you need someone not involved directly in the development process to watch over the entire codebase.
And yes, software architecture is a pure creative process. It is not just following the standard design patterns (gang of four, KISS, SOLID, etc.) or architectures(microservice, serverless, monolith, etc.). Because it is not always possible or suitable to use them. Sometimes by making things simple is the best approach instead of overengineering everything. Other times you’ll have to adopt the architecture for the company’s needs.
That's why you should not give this position to anyone like some sort of reward for being a good employee otherwise you may be ruining your own company. You must choose the best developer with a good taste for code quality, readability, maintainability and the most important one: a excellent sense of abstraction. By choose someone with these qualities you can be sure that not only you have a good software but you can also be confident enough to show it to anyone without the fear of collapsing it in your presentation (I’ve seen it happen so many times that I lost track of them). You will have good sleep nights for sure and a even better profitability.
Image source: Daniel McCullough