Category: Software Architect

It‘s important to remember when architecting a system that maintenance will, in the long run, consume more resources than initial development of the project. Short cuts taken during the initial development phase of a project can result in significant maintenance costs later.

For example, you may have been informed that unit tests don’t deliver direct value and so you tell your developers to skip the rigorous application of them. This makes the delivered system much more difficult to change in the future, and decreases confidence when making those changes. The system will require far more manual testing for a smaller set of changes, leading to brittleness and increased maintenance expenses as well as a design that’s not as appropriate as a fully-tested design (let alone a test-first design).

A serious architectural mistake that is sometimes made is to adapt an existing system for a purpose that it is not fit for, on the basis that using an existing system somehow reduces costs. For example, you might find yourself utilizing BPEL architectural components coupled with database triggers to deliver an asynchronous messaging system. This might be done or insisted upon for reasons of convenience or because that is the architecture is known to you or the client. But a messaging architecture should have been selected in the first instance after requirements made it clear it was a necessary component. Poor decisions made at the inception of a project make it much more expensive to re-architect the system to meet new requirements.

In addition to avoiding short cuts during the initial development phase, it‘s also important to correct poor design decisions as quickly as they are discovered. Poorly designed features can become the foundation for future features making corrective action later even more costly.

For example, if you discover that inappropriate libraries were selected for some underlying functionality they should be replaced as soon as possible. Otherwise the effort to make them fit evolving requirements will result in additional layers of abstractions, each designed to hide the poor fit of the previous layer. You are building yourself a ball of tangled twine, tack, and sticky tape and with every layer you add, it is harder to unravel. This easily results in a system that is resistant to change.

As an architect, when you encounter an architectural problem or design flaw insist that it be rectified now, when it cheapest to fix it. The longer you leave it to drag out, the higher the interest payment is.

For many software architects, hardware capacity planning is a topic that lies beyond their comfort zone, yet it remains an important part of the architect‘s job. There are a number of reasons software architects often fail to properly consider hardware but they mostly have to do with a lack of understanding and unclear requirements.

The primary reason we neglect hardware considerations is that we are focused on software and tend to ignore hardware demands. In addition, we are naturally isolated from hardware by high-level languages and software frameworks.

Unclear requirements are also a factor as they may change or may be poorly understood. As the architecture evolves hardware considerations will also change. In addition, our clients may not understand or be able to predict the size of their own user base or system usage dynamics. Finally, hardware is constantly evolving. What we knew about hardware in the past does not apply today.

Without hardware expertise predicting hardware configurations for systems to be developed is highly error prone. To compensate some software architects use large safety factors. Such safety factors are generally not based on objective assessments or founded in any methodology. In most of the cases, this leads to excessive infrastructure capacities that will not be utilized even in periods of peak demand. As a result, clients’ money is wasted on more hardware than a system will ever need.

The best defense against poor hardware planning is to work closely with an infrastructure architect. Infrastructure architects, unlike software architects, are specialists in hardware capacity planning and they should be a part of your team. However, not every software architect has the luxury of working with an infrastructure architect. In such cases there are some things a software architect can do to mitigate errors when planning for hardware.

Drawing on your own past experience can help. You’ve implemented systems in the past and so you have some knowledge of hardware capacity planning – even if it was an after thought at the time. You can also discuss the topic with your client and convince them to set aside funds for hardware capacity planning. Budgeting for capacity planning can be much more cost effective than buying more hardware than you need. In this case, horizontal scalability is the key – adding hardware as needed rather than over-buying in the beginning. To make a horizontal strategy work software architects need to constantly measure capacity and isolate software components to execute in performance predictable environments.

Hardware capacity planning is as important as software architecture and it needs to be given a first order priority whether you have an infrastructure architect on hand or not. Just like an architect is responsible to establish the links between business demands and a software solution, she is responsible to envision the links between hardware and software.