There is no correct software architecture. But there are an unlimited number of ways to incorrectly architect your software. The best we can do is state some principles and use those to help narrow the solution space of all possible architectures. This will help us identify a more correct architecture.

Architecture – a quick definition

Building Architecture is a combination of two things, making the building suitable for purpose and making the overall structure pleasing to the eye.

Making a building suitable for purpose is mostly dividing the space in to boundaries. Like rooms are often grouped near one another. Some structural considerations may help this grouping, such as bathrooms being above the kitchen to limit the number of wet walls. Some rooms may have internal subdivisions like nooks and archways that don’t limit the flow or utility of a space but visually define these regions. This defines the utility of a building.

Aesthetic considerations help make the building feel as it belongs. This means it fits in the surrounding landscape as well as feels balanced and consistent with itself. The balance and feel contribute to the habitability of a space.

Utility and Habitability in Software

Software architecture also controls the utility and habitability of a program.

Software Architectural utility is not the UX, but the software’s ability to perform its tasks quickly enough, reliably enough, and a host of other so-called –ilities. This is done by determining if you need extra caching for speed, separation of the active data set from the reporting data set, splitting the application in to multiple programs to better handle failure, and interfacing with other systems. And that’s just a start!

Software Architectural habitability is about the ease of development. Simple changes should be simple. Changes that depend on multiple business concepts interacting should only be as complex as those interactions. This is done by being deliberate about what code interacts with other code, by drawing boundaries between software concepts that reinforce boundaries between business concepts.

These forces can be in tension. Adding robustness to an application can make changes harder. Making it more flexible can degrade performance. Focusing solely on making easily changeable software if fine for small scale software. Wringing every last ounce of throughput is perfect for less complex software. Finding the balance is the art of Software Architecture.

Principles for Improving Communication

If you need someone called “Architect” on your project, the odds are you have a team larger than the two-pizza rule. That means that several decisions a day are going to need the architect to be there, and some times she can’t be present in person. Be stating not only the design goals but what purpose they serve, the architect empowers the team to make correct choices when they find themselves on their own.

It isn’t sufficient to say the software must be robust. But if we say minimize the impact of failure on non-related operations and enable a manual retry of failed transactions we are clearly stating what we mean by robust. When dealing with a design decision I can now ask myself a few questions to guide my implementation.

1. Does failure impact other users?
2. Do I have enough information to recreate this request if it fails to complete?
3. When I fail, can I undo the partial operation?
4. Are my operations Idempotent?

By stating the outcomes desired instead of the means we use to get there, the architect prevents the same problem being addressed by nothing more than a bunch of null checks and try/catch blocks.

It’s Only Business

Theses principles should come from the business case for the software. How many users are you supporting at once? Are they _occasionally connected_ or always connected? What is the impact of failure on a sale? The impact of failure on trust in the system? How about the impact of failure in the lives of thousands of children? Will someone die if your software falls down or corrupts data?

What are the reasons for your architecture choices? Have your design choices helped or hindered those goals? Is there tension between the design impacts of your business goals? Do you have some design changes to go deal with?