If you are new to software architecture, you may have seen a lot of material trying to decouple design from architecture or vice versa. The goal of this article is to show how each complements the other and why they are a sum of a whole. We will be reviewing a case study to break down how bad software architecture can affect developer productivity and the effects it can have on a company’s finances.
Software architecture vs design
What is architecture? What is design? Is architecture and design mutually exclusive? From my perspective no, they are not mutually exclusive. Architecture and design are the sum of a whole. As we go further into the topic my goal is to clear up a lot of the confusion around the matter and provide practical examples to support my point of view.
To establish a baseline of understanding I took the below definitions from IEEE Computer Society.
“Software architecture – refers to the high-level structures of a software system and the discipline of creating such structures. It involves the set of significant decisions about the organization of a software system including the selection of structural elements and their interfaces by which the system is composed and behavior as specified in collaborations among those elements.” – https://www.computer.org/resources/software-architecture
“Software design – describes how the software system is decomposed and organized into components and modules. It defines the relationship between these modules through interfaces. Software design translates the user’s requirements into a ‘blueprint’ for building the software. It is the link between problem space and solution space. The design represents the software architects’ understanding of how to meet the requirements.” – https://www.computer.org/resources/importance-of-software-design-is-important
Just going based on the definitions above its very hard to draw a line to say one can exist without the other. Instead we should view software architecture as more of an all encompassing software principle.
Lets look at an example, albeit a very cliche one; but it drives home the point succinctly. You are in the process of building your dream home, you have an idea in mind head of what you need done but you need an architect to put your vision to paper so the contractors can execute. Now lets look at two possible scenarios that we can pull from this example:
Scenario 1: Complete architecture – high and low level considerations
Architect delivered to you a complete plan. It has the high level requirements such as the size of the structure and the placement of the rooms. On the other hand it has all the low level details too, where the doors, windows, electrical outlets and plumbing should be.
In this scenario you can feel comfortable knowing all the requirements were considered and the plan is in keeping with your vision.
Scenario 2: Incomplete architecture – high level considerations only
Architect delivered to you a plan. It has only the high level requirements such as the size of the structure and the placement of the rooms. The low details are left to the discretion of the contractor, so doors, windows, electrical outlets can be placed anywhere the contractor sees fit.
I don’t know about you but for me personally I do not like the idea of having key areas of my dream home left to chance. Who knows I might just end up with all my electrical outlets placed in the worse possible areas because it was faster to install versus doing it right.
The concepts of design and architecture works hand in hand, any system that is being designed to not just work but scale and not require an army behind to keep it running needs to properly plan its architecture.
Case Study: Effects of Bad Software Architecture
In order to set the stage for articles to come, let us explore a case study. This study is based on a personal experience, as such company details will remain anonymous.
As engineers, we all love greenfield projects; however, we can get a bit ahead of ourselves in terms of how the project is approached and designed. Unfortunately, we were victims of this over-exuberance. Our company was first to market in the region with a product of this nature, and we were able to gain massive value from our first few releases. However, as time progressed, the time between major releases increased and the operating overhead increased to boot.
You may be wondering, how did you get there? Well, in hindsight, we allowed “urgency” to take precedence over important fundamental activities, which needed to ensure this product would bring value for releases to come. There are a few important and often overlooked areas of any software development project:
- Quality architecture that is easy to implement and maintain. What do I mean by this? Well, a system where your complexity is directly related to the operational overhead needed to keep it running is a poorly designed one. The goal is to deliver the most value possible to stakeholders while having the flexibility to add new features over time.
- Eliminating the “we will fix it next release” mindset. Let’s be real, there is technical debt in every system, but we tend to use the term as a blanket statement to kick the proverbial can down the road. Except there is one main issue with this, we hardly ever have the capacity to tackle these items, which eventually comes back to bite us.
Unfortunately, we got to a point where we needed to redesign this system from the ground up, as we were no longer in a position to deliver value in a timely manner to the business. As you can imagine, this did not go down well from an executive level. With the lessons learned from attempt one, we were able to put together a system which was much more robust than previously implemented. The bad test of cost and loss of business during this rebuild period was certainly not lost on senior leadership.
Conclusion
In order to deliver a quality product to your stakeholders, we can’t leave anything to chance. Consideration has to be given to both high and low-level details of the software architecture. Otherwise, we run the risk of making the same mistakes made by others and implementing a system that has a predetermined value lifecycle for the business.