In this post I will deal with an interesting (and thorny) set of questions regarding architecture.
Without much further ado, let’s get into the game.
What is software architecture?
In a broad sense, software architecture is the complete set of design decisions that defines and determines the structure of a given software solution, but let’s bear in mind that when we talk about “software architecture“, we really mean the main design decisions that define the main structural elements of a given software solution, and not each and every design decision, that may include a large amount of rather simple, obvious and very uninteresting design decisions.
What does a software architect do?
In plain and simple terms, the software architect is the person that makes those design decisions, so, that is mainly what the software architect does:
making the design decisions regarding a given software solution.
How could we tell the good software architects from the bad software architects?
To be able to answer this question, we should start with a simpler question:
How could we tell a good design decision from a bad design decision?
Well, design decisions are either good or bad just because of their consequences: a design decision is good if and only if it produces good consequences, just as much as it will be bad if and only if it produces bad consequences.
So, getting back to the answer for the original question, the good software architects are the ones that make design decisions that have good consequences for the project, the team and the product, and the bad software architects are the ones that make design decisions that have bad consequences for the project, the team and the product.
I am aware of the fact that any Product Owner may argue that my answer is not useful for them since, by the time they realize that the software architect is not any good, it is already too late!
Well, allow to say in my defense that it is not so, since you can detect the tell-tale signs of either good or bad consequences from design decisions being made by the architect early on the duration of any software development project.
As a parting idea to this post, I will give you another tip on good software architects. All of them are really good at these two things:
1) Good software architects, when they have to make a design decision, they never forget to ask the following question:
“How could I make sure that the design decision that I’m about to make will neither compromise nor limit our ability to keep making the design decision that we need, for the forseeable future?”
(Since you have allowed me a few things, allow me to say that this is a quote of my own batch)
2) Good software architects, when they ask themselves this question, they always figure out a successful answer to it for the solution at hand.
Most people may argue that the question in 1) is an impossible question since we cannot predict the future, so, there is no way that today we could guess what might be the design decisions that we will need to make in the future.
Again, allow me to say in my defense that most people are not software architects (let alone good software architects), so, most people will not pay attention to the key to this question: “neither compromise nor limit our ability to keep making the design decision that we need”
Good software architects do not need to predict the future to be able to figure out the answer to the key to the question.
Kind regards, GEN