Software Architecture

What is software architecture? There are hundreds of definitions of what software architecture is, but there is none of what it isn't. In general it is considered more abstract than software design and more focused with non-functional requirements. So, in order to approximate the concept of software architecture, let's play a yes or no game:

Does software architecture define method signatures? NO…classes? NO
Does it model the domain? NO
Does it list existing domains (if there are more than one)? YES
Does it define the servers where the application is deployed? Not since the cloud era.
Which services comprise the system? YES
Does it divide the system into processes? YES
Does it define the programming language to use? YES…the framework to use (Spring, JEE, Angular, …)? YES-ish…libraries used (Guava, POI, …)? NO-ish
Database type (RDBMS, key-value store, tuple space, …)? YES
DBMS (Oracle, SQLServer, DB2, …)? YES-ish

After this Montecarlo simulation ( https://en.wikipedia.org/wiki/Monte_Carlo_method ), we should have a more refined idea of what is software architecture.

So what is a purpose of a software architect?

The SOLE purpose of being a Software Architect is to have a job title on which basis to ask for a pay raise. In the vast majority of cases, it is the developers that define the architecture, which amounts to being either this:

or this:

With microservices, the diagram can become arbitrarily, more often overly, complex, but it can and probably should be still defined by the developers.

The only case where a dedicated software architect is needed is if the system is so large that no developer can understand all of it. This means that the architect will not be aware of all the details and will have higher chances of overseeing some important aspect. That's why a good architect will rely on points of view of developers working in different parts of the system, rather than trying to be smart.

A good software architect will most likely have been a developer recently to avoid the ivory tower syndrome. This apparently leads to the paradox that a good architect must not have too much experience in software architecture. Of course this is not true, even full time architects often exchange periods of software development and architecture.

However, there is a minimum of experience that an architect must have. They must have extensively suffered the pain of maintaining, refactoring and migrating a legacy system. Which leads us to my patented "LEARN WITH PAIN®" method of grooming software architects (and part-time serial killers).

journey	pain exposure	lesson learned
Junior SW Eng to SW Eng	maintaining a legacy system	how not to write code
SW Eng to Senior SW Eng	refactoring existing system	what is bad design
Senior SW Eng to SW Architect	migrating a legacy system to a new technology	life sucks and then you die

The important nuance here is that the pain must be felt long enough to develop a sense of short periods of desperation and hatred towards who wrote the code.

I hope that this post helps you better understand software architecture and plan your career.

PS: This post is slightly humorous and not to be taken too seriously.