You don’t start building a house without an architecture, yet when it comes to software development, most projects don’t have any well-defined architecture.
Many people attribute the difference in approaches to the fact that it’s hard to change the house that’s half done while software is malleable and hence can be changed easily at any moment.
But that’s not true. The further down the road a software project is, the harder and more expensive it is to change its architecture. It’s still doable, but it unnecessarily costs much more than it would’ve cost if some time would’ve been spent on the initial architecture.
What’s Software Architecture?
Architecture makes a lot of high-level decisions:
- Do you go with hardware servers or the cloud?
- Do you go with a monolith or microservices?
- Which programming language or a set of languages are you going use?
- Which framework are you going with? Or do you go without a framework?
- What kind of datastore types are you going to use? SQL? NoSQL? A combination of them?
- How do you automate deployments to staging and production environments?
- Once you’ve decided with the datastore types, which database systems are you going with? MySQL? PostgreSQL? MongoDB? Cassandra?
- Where do you store uploaded files? Directly on filesystem? AWS S3?
Architecture covers high-level decisions like that. And similar to house architecture, it doesn’t cover the interior design. That stuff is covered by an apt name practice called software design.
Architecture Is Not Design
Architecture doesn’t go into relatively lower level concerns like algorithms or libraries to solve particular day to day problems. It only focuses on the overall global structure of the whole system.
For instance, a particular architecture could say that a system is going to be built with microservices. And that microservices are going to communicate with each other with REST calls for synchronous tasks and Kafka for asynchronous tasks. And that there is going to be a service registry where each microservice instance needs to register itself.
But the architecture it’s not going to bother with whether you’re using an ORM library like Hibernate to interact with a relational database or just go with plain JDBC.
It’s also not going to bother with whether you build a fresh response for each REST request from other microservices or cache responses for a few minutes to reduce the load on the database and CPU.
Why Is Software Architecture Important?
It’s important because high-level decisions affect a project for a long time. If you don’t spend some time on thinking about architecture at the beginning of a project, poor choices will negatively impact its progress down the road.
For instance, if you pick a wrong programming language, it might bite you down the road when it turns out the language doesn’t have enough reusable code in the form of frameworks and libraries that could save a lot of time developing particular features of the system.
If you pick a wrong framework, you will waste a lot of time reinventing the wheels that come free with certain frameworks. Or you will be working around a framework instead of making good use of it.
If you pick a wrong database system, you might not be able to scale to the volume of data you’ll have. Or you won’t be able to make good use of data to answer the questions your business has. In the worst case scenario, you will even be losing important data and not even notice that until it’s too late.
Even though software really is malleable and most of the poor architectural decisions can be corrected down the road, the question is how much time and money that will cost.
For instance, say you pick MySQL and then you discover how inadequate it is as a relational database system. But you already have 200+ tables in it with even more foreign keys. You also have thousands of SQL queries that join multiple tables together. Then you discover that PostgreSQL is a much better relational database system and you decide to switch to it.
Given the high coupling of relational databases caused by foreign keys and joins, it’s very hard to migrate from MySQL to PostgreSQL one table a time. It’s doable, yes, but it requires a lot of effort.
You either need to halt development for a few months, recreate the same database schema in PostgreSQL, move all the data to it, rewrite many queries to work the same on PostgreSQL, and test the whole thing to ensure nothing got broken. Or you decide to keep development going and make the transition to PostgreSQL an ongoing effort that will take over a year.
So, yeah, it’s perfectly doable, but at what cost? While you’re struggling with bad architectural decisions, your competition that put some thought into architecture right from the start is churning out new features.
As another example, if you pick a programming language with poor performance, you’ll have to spend more money on more and bigger servers to be able to scale to a volume of traffic that a more suited language wouldn’t have problems with on less hardware.
Poor software architecture decisions or a complete lack of them unnecessarily slow down development down the road.
Even though it’s possible to amend software architecture at a later stage, it costs much more in terms of time, effort, and money spent on that. The later a change to architecture is done, the more expensive it will be.
Hence it makes sense to spend some time thinking out the overall architecture right at the start of a project and then refine its specifics as the project progresses and new information is available.