Why Is Software Architecture Important?

Is software architecture still a thing? Doesn’t the latest language or framework make architecture obsolete?

No, not at all. Designing our systems so that we can make adjustments easily—without affecting many parts of a system—is still the name of the game. And this will not change.

Let’s consider an example:

You are a software engineer maintaining a bespoke eCommerce system. Currently, the system uses Stripe for its payment needs. You have looked at the code and noticed that the Stripe payment logic is coupled to the high-level payment business logic workflow. You find it hard to see where one responsibility ends, and another starts.

This image represents the payment code. The business logic (Orange) and Stripe payment code (Purple) are intermingled.

The Product Owner has requested that you extend the system to allow for Paypal payments. You’ve seen the code, and you know that this won’t be an easy task.

Now, compare that system architecture with a more ‘pluggable’ one designed with extensibility in mind.

The generic payment business logic workflow, the specific payment gateway code (e.g. Stripe), and an adapter to convert calls between the workflow and payment gateway, are separate components. So, if we wanted to replace Stripe with another payment gateway, say, Paypal, we would only need to write a Paypal adapter and plug this between the payment module and Paypal payment gateway, respectively. The business logic Payment Module would not need to be changed. And neither would the Paypal payment gateway code.

That is so much simpler. And we only wrote new code. Once we have the Paypal adapter, the plugging in will be a piece of cake.

This example demonstrates that the architecture of our systems can make a marked difference in how quickly we can respond to requirement changes—and how much existing code we must modify to effect those changes.

A Tale Of Two Architectures

A system that has little or no discernable architecture will experience the problems depicted in these graphs:

The number of developers needed to maintain a difficult to change system will skyrocket. Why? If many modifications are required to implement even minor features, many developers will need to make these changes. Making many changes by many developers will increase system entropy (and the number of bugs) and boost code churn without achieving much. What is one to do? Maybe hire more programmers will fix the problem?!? Productivity is racing to zero, not much new code is being written, and the cost per line of code increases sharply. We don’t want to be in this position.

What about a system with better software architecture, having well-thought-out pluggable extensibility points?

Over time, the overall system complexity still increases, requiring more developer resources. However, the growth is more linear since fewer developers are needed to effect the requested functionality changes. An increase in the number of lines in the code base is indicative of the system acquiring new functionality. The cost to maintain a line of code stays almost static.