Importance of software architecture

So far, we have discussed the fundamental principles of software architecture, and also seen some of its characteristics. These sections, of course, assumed that software architecture is important, and is a critical step of the software development process.

It is time to play devil's advocate, and look back at software architecture and ask some existential questions about it as follows:

• Why software architecture?
• Why is software architecture important?
• Why not build a system without a formal software architecture?

Let us take a look at the critical insights that software architecture provides, which would otherwise be missing from an informal software development process. We are only focusing on the technical or developmental aspects of the system in the following table:

Aspect	Insight/Impact	Examples
Architecture selects quality attributes to be optimized for a system.	Aspects such as scalability, availability, modifiability, security, and so on of a system depend on early decisions and trade-offs while selecting an architecture. You often trade one attribute in favor of another.	A system that is optimized for scalability must be developed using a decentralized architecture where elements are not tightly coupled. For example: microservices, brokers.
Architecture facilitates early prototyping.	Defining an architecture allows the development organization to try and build early prototypes, which gives valuable insights into how the system would behave without having to build the complete system top down.	Many organizations build out quick prototypes of services—typically, by building only the external APIs of these services and mocking the rest of the behavior. This allows for early integration tests and figuring out interaction issues in the architecture early on.
Architecture allows a system to be built component-wise.	Having a well-defined architecture allows the reuse and assembly of existing, readily available components to achieve the functionality without having to implement everything from scratch.	Libraries or frameworks which provide ready-to-use building blocks for services. For example: web application frameworks such as Django/RoR, and task distribution frameworks such as Celery.
Architecture helps to manage changes to the system.	An architecture allows the architect to scope out changes to the system in terms of components that are affected and those which are not. This helps to keep system changes to a minimum when implementing new features, performance fixes, and so on.	A performance fix for database reads to a system would need changes only to the DB and Data Access Layer (DAL) if the architecture is implemented correctly. It need not touch the application code at all. For example, this is how most modern web frameworks are built.

There are a number of other aspects which are related to the business context of a system, into which architecture provides valuable insights. However, since this is a book mostly on the technical aspects of software architecture, we have limited our discussion to the ones given in the preceding table.

Now, let us take on the second question:

Why not build a system without a formal software architecture?

If you've been following the arguments so far thoroughly, it is not very difficult to see the answer for it. It can, however, be summarized in the following few statements:

• Every system has an architecture, whether it is documented or not
• Documenting an architecture makes it formal, allowing it to be shared among stakeholders, making change management and iterative development possible
• All the other benefits and characteristics of software architecture are ready to be taken advantage of when you have a formal architecture defined and documented
• You may be still able to work and build a functional system without a formal architecture, but it would not produce a system which is extensible and modifiable, and would most likely produce a system with a set of quality attributes quite far away from the original requirements