Category: Software Architect

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.

You’ve probably heard this said before. If you’re an experienced architect, you know it’s true: if you can only think of one solution to a problem, you’re in trouble.

Software architecture is about finding the best possible solution for a problem given any number of constraints. It is rarely possible to satisfy all requirements and constraints with the first solution that comes to mind. Generally, trade offs must be made by choosing the solution that best satisfies the requirements according to the most critical priorities.

If you only have one solution to the problem at hand, it means that you will have no room to negotiate these trade offs. It’s very possible this one solution will be insatisfactory to the stakeholders of your system. It also means that if priorities are shifted due to a changing business environment, your system may have no room to adapt for new requirements.

Rarely, if ever, is this situation caused by a real lack of options. It is much more likely due to the inexperience of the architect in this particular problem domain. If you know this is the case, do yourself a favor and ask someone more experienced to give you a hand.

A more insidious manifestation of this problem is when an architecture is designed from habit. An architect can be experienced with a single style of architecture (e.g. a 3-tier, layered client-server system), but not know enough to recognize when that style doesn’t fit. If you find yourself in the situation where you automatically KNOW the solution, without having done any comparison to other approaches, stop, take a step back, and ask yourself if you can think of another way to do it. If you can’t, you may be in need of some help.

A friend of mine was once the technical person in charge of a small, but growing internet start-up. As their user base started growing, so did the load requirements on their system. Performance was going down the tubes, and they were starting to lose some of their hard-won user base.

So, the boss asked him, “What can we do to improve the performance?”

My friend had the answer: “Buy a bigger machine!”

“What else can we do?”

“Umm… as far as I know, that’s it.”

My friend was fired on the spot. Of course, the boss was right.