Do you need Architecture?
“Lets don’t waste time on the architecture now, let’s start building the application and later draw the architecture diagram of it”
I heard this in one of the meetings a few years back, some of the developers tried to influence this statement with no luck. We lost that debate to delivery deadlines. I’m sure a lot of you might have also heard this in one way or another.
While most of the teams I’ve worked with take the architecture seriously, some of them were more focused on building the software first, and let the architecture evolve holistically.
You will always end up with an architecture, whether you choose to have one or not.
Let’s talk a bit about boats.
People used to build boats and ships long before Archimedes came up with Archimedes’ principle.
You can still build a boat without considering the Archimedes’ principle.
If you need to calculate how much load the boat can handle, you’ll need to load the boat till it sinks and weigh the load.
Imagine that we’ve built 3 different boats, and after building them, we needed to know how much load can it carry. We’ve done the above weighing test and found out that they can handle 320 kg, 350 kg and 400 kg respectively.
Now we’ve got an order to build a boat that can handle a maximum of 600 kg. We can build a larger boat than that of 400 kg with the assumption that it can handle 600 kg.
But will we be sure ?
What if the boat can handle only 550 kgs.
Or what if the boat is too big that it can handle 800 kgs?Then you’ve spent more resources than you should have.
What if you could ‘design’ the boat in advance and know how much load it can handle ?
Archimedes law states that the buoyant force on an object is equal to the weight of the fluid displaced by the object.
Fb = ρ × g × V
Where Fb is the buoyant force, ρ is the density of the fluid, V is the submerged volume, and g is the acceleration due to gravity.
Volume of the boat is the deciding parameter for the buoyant force as the density of the water and the acceleration due to gravity are constants. This enables us to compute what the exact volume of the boat should be in order to handle a specific weight.
This principle will enable us to design a boat that can handle specific loads.
Now coming back to the software development, non functional requirements of the software are as important as the functional requirements, if not more important. One of the most important non-functional requirements is the ability to respond to changes. It should be possible to apply functional changes and non functional changes into the software throughout its lifetime and the software should respond to the changes (as per the intent of the change, of course).
There are software systems that cannot be efficiently modified for its own improvement or to accommodate changing requirements. In certain cases, impact of change is unknown until it’s implemented, just like we don’t have a clarity on the maximum load in the boat unless we do trial and error. Software systems that are unresponsive to changes are a nightmare for both the Business and the IT. Systems that respond with the opposite effect of intent of the change are more dangerous. Example- employing horizontal scaling for performance improvement results in rather poor performance than before, as a result of bottleneck in one of the points transaction journey.
Proper software architecture not only fulfils the functional requirements of the system, but also enables the system to respond to changes in the future, both functional and non-functional.
There could be arguments and differing opinions, definitely !!
A few years back, I heard a person saying — “We don’t need to use Hibernate or any other ORM tools as we are not going to change our backend, it is Oracle database and it is not going to change”. Later, the database changed to another relational database by a different vendor and recently it changed to a No-SQL database.
In the software domain, just like any other place — “The only thing that never changes is the change.”
