Categories
Software Architect

You have to understand Hardware too

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.

'Coz sharing is caring
Categories
Software Architect

Understand the impact of change

A good architect reduces complexity to a minimum and can design a solution whose abstractions provide solid foundations to build upon, but are pragmatic enough to weather change.

The great architect understands the impact of change – not just in isolated software modules, but also between people and between systems.

Change can manifest in a variety of forms:

  • Functional requirements change
  • Scalability needs evolve
  • System interfaces are modified
  • People in the team come and go
  • and the list goes on…

The breadth and complexity of change in a software project is impossible to fathom up-front, and it’s a fruitless task trying to accommodate every potential bump before it happens. But the architect can play a crucial role in determining whether the bumps in the road make or break a project.

The architect’s role is not necessarily to manage change, but rather to ensure change is manageable.

Take, for example, a highly distributed solution that spans many applications and relies on a variety of middleware to glue the pieces together. A change in a business process can cause havoc if the set of dependencies are not correctly tracked or accurately represented in some visual model. The impact downstream is particularly significant if the change affects the data model, breaks existing interfaces, and the existing long-running, stateful transactions must successfully complete under the old version of the process.

This example may appear extreme, but highly integrated solutions are now mainstream. This is evident in the choice of integration standards, frameworks and patterns available. Understanding the implications of change in these outlying systems is critical in ensuring a sustainable level of support to your customers.

Fortunately, there are many tools and techniques to mitigate the impact of change:

  • Make small, incremental changes
  • Build repeatable test cases – run them often
  • Make building test cases easier
  • Track dependencies
  • Act and react systematically
  • Automate repetitive tasks

The architect must estimate the risk of change on various aspects of the project’s scope, time and budget, and be prepared to spend more time on those areas whose impact would be the greatest as the result of “a bump in the road”. Measuring risk is a useful tool for knowing where your valuable time should be spent.

Reducing complexity is important, but reduced complexity it does not equate to simplicity. The pay-off for understanding the type and impact of change on your solutions is immeasurable in the medium- to long-term.

'Coz sharing is caring