Developing software is complicated! With every passing year, software complexity seems to only be on the rise. More features are expected from stakeholders. Hardware advances, creating ever more complex devices to work with. Even simple applications can have several dozen software modules, an operating system and in today’s environment, internet connectivity. Unfortunately, a lot of companies I encounter skip over developing a software architecture for their systems. While this can be fine for simple, DIY projects, in product development, this can lead to spaghetti code, missed delivery deadlines and ballooning development costs. In today’s post, we are going to discuss the five reason that you need to develop a software architecture (even if your software has already been written!).

 

Reason #1 – An architecture helps you organize your thoughts

The first reason that developers should take the time to develop a software architecture is that it helps the developer and their team organize their thoughts. A software architecture will identify the major components in the system, their inputs, outputs and how they interact with each other. This activity can help a developer understand how the software can be organized and allows them to think through scalability and reuse issues. It’s important to note that a software architecture once developed is not set in stone. An architecture will often evolve based on the phase of the project and the business needs. Having a drawn-out architecture can also help to properly evolve the architecture versus just evolving code blindly on the fly which results in more software hacking then development work.

 

Reason #2 – An architecture gives you a map of what you are building

A software architecture can also act as a map for developers so that they understand what they are building. A building contractor would never start construction without the building architecture because the rework and material wastes would be tremendous. Just because software can be changed and recompiled with the push of a button doesn’t mean that rework and development costs can’t get out of control. In fact, in most cases that I see they are out of control. Having that high-level picture of what is being built can dramatically improve the implementation phase of the project which is where the majority of software costs are outside of the maintenance phase.

I often encounter teams that have no architecture and are busy wasting cycles trying to hack new features into their software. In these situations, I often will map out the current architecture so that the developers know where they currently are and then create an ideal architecture of what the architecture needs to evolve into. With each sprint, the teams then take on little improvements that over time result in taking the spaghetti code and turning it into a cleaner and well architected software solution.

 

Reason #3 – An architecture gives you requirements for code reviews

I’ve also found software architectures to be very useful for code reviews. As developers take the time to create an architecture, this architecture can be looked at as requirements for the software. During a code review, the architectural diagrams can be used to make sure that the implementation fits the architecture. If it doesn’t, then the software may need to change to meet the architecture or it may be that the architecture needs to evolve to handle new discoveries that from implementation. Without diagrams to explain what the code can be doing; it can be difficult to confirm that the software is matching the desired architecture.

 

Reason #4 – An architecture can be used to transfer knowledge to colleagues

I’ve found that businesses and developers often have their focus on the near term verses the long-term. They busily write their code trying to meet short term deadlines while neglecting activities that need to be done short-term in order to ensure long term success. While a software architecture will require a few cycles short-term, developing one and maintaining it can have the long-term benefit of transferring knowledge to colleagues and new hires on how the software system works. I’ve seen so many companies that can’t tell me why the software does something other than that’s just how it was done 5+ years ago and are too afraid to change it. Or where I’ve read through code and asked questions only to receive blank stares back. While an architecture won’t capture the low-level decisions, it should capture the high-level decisions and plan that can then in several diagrams allow someone to quickly get a feel for how the system should work. Without that knowledge, it can take months for someone to get up to speed on something that should have only taken a week or two.

 

Reason #5 – An architecture guides clean, reusable and portable software

Finally, a software architecture is the map, the guide that developers should use when they are writing their software. A clean, well thought out architecture leads to cleaner and easier to understand implementation. An architecture can guide developers on where to put interfaces, where dependencies need to be managed which then results in software that should be reusable and portable. While for some companies reuse and portability is not a main concern for a product line, if the product is successful, at some point that systems processor and components will reach a manufacturing end of life date. When that happens, if the code is written correctly upgrading to a new processor can be as simple as swapping out a software layer or as complicated as starting completely from scratch.

 

Conclusions

A software architecture is the map and guide that developers need in order to successfully develop software in an efficient manner. Without a map, developers will often have to constantly rework what it is they are doing in order to account for components and interactions they hadn’t thought about. A software architecture does not need to be done completely up front in a project in a waterfall way, but instead can evolve within an Agile environment to meet changing requirements and feature needs. In fact, having an architecture can ensure that the software is flexible and scalable to handle the changing requirements and needs that are often encountered in a development cycle. An architecture can help to minimize the chances that project costs and timelines will get out of control and lead to project failure.