If you are building a serious software system, the best way to reduce the cost of development while achieving the expected qualities is by spending some serious effort in software architecture.

We all know that requirements are broadly classified into functional and non-functional. Software developers very often overlook the non-functional requirements even though non-functional requirements are equally demanding and costly to achieve. The resulting systems tend to be functionally complete, yet fail to be usable. I have seen many systems suffering due to this. Here's what can happen:

1. Systems are repeatedly implemented throwing away one version after the other.
2. Project comes to a standstill where no one finds easy way out.
3. Initially, the software works well, but over time it becomes unacceptably slow or fail to scale no matter what amount of hardware is added.
4. Over time, design rationale is forgotten or become non-enforceable and software maintainers resist changes since maintenance becomes a nightmare.
5. Evolution of technologies used causes significantly expensive modifications to working software later on.
6. Developer frustration. Who's the culprit? Not me, right?

You can also read this article which is related to the same: Aging software is a trouble for enterprises

Meeting non-functional requirements is a major goal of software architecture. All the issues listed above generally originate due to not making technical decisions also based on non functional requirements, but only based on functional requirements. These issues are best tackled by software architecture.

Addressing the architectural concerns needs to happen as early as possible in the development life-cycle. Quality cannot be added later on. An attempt to do so causes the software development project to repeat.

Unfortunately, many developers don't understand the effect of software architecture. In a way, this is expected since software architectural concerns are understood once someone learns programming languages, designs, software development process aspects, team dynamics, business contexts behind software projects and so on. What typically goes wrong is when a software development team is established without the services of at least one person with architectural skills.

I am often requested by companies to investigate technical aspects of software projects/products. Often they call me when they are faced with troubles towards the latter part of development life-cycle. Almost in all cases I find that their root cause is the failure to address important non-functional requirements via the software architecture. Developers often cut code without firm design rationale. Again, quality cannot be added later on!

At times, projects only have produced source code. It's not an easy task to propose corrections since determining design rationale by looking at code is not an easy task (Not many document the design rationale either). At times it is impossible or meaningless since there had been no design rationale in the first place.

At times, I have also come across teams/product owners who think that technical problems they are faced with are inherent to software. They fail to recognize the troubles they can avoid or the money and effort they can save or continue to save in future due to realignment of software development or maintenance efforts based on architectural decisions.

You can view architecture itself as a technical decision framework. Architects make technical decisions taking into consideration downstream effects (during the development cycle, production use and maintenance). A focus on software architecture is also a risk management strategy. Overall, software architecture has enormous impact on the cost and quality of what you build, use or maintain.

Kamal Wickramanayake
Enterprise/Software Architect & Trainer