Introduction

Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often proves difficult to evolve, reuse, or integrate without substantial rework. It is also difficult to organize the team or communicate ideas without the common technical focus that the architecture provides.

Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the essential technical decisions through the growing architecture.

Practices

The next sections describe the practices associated with this principle.

Create the architecture for what you know today

As Albert Einstein said, make everything as simple as possible but no simpler. Software projects are resource-constrained, and the desire of developers to create elegant solutions may lead to a system of greater complexity than the stakeholder requires. Efforts to future-proof a system in a turbulent or uncertain environment will likely lead to code bloat , thus increasing overall cost with little actual benefit to show for it.

Therefore, create architectures that address the stakeholder’s real needs, and provide appropriate flexibility and speed for the requirements as they are known today. Avoid the desire, no matter how well intentioned, to speculate on future requirements and thereby over-engineer the architecture: if you have the skill to architect something today, then clearly you must also have the skill to architect it tomorrow when you actually need to.

Cope with complexity by raising the level of abstraction

Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it becomes difficult for the team to develop a common understanding of the system, because it is hard to see the bigger picture.

Therefore, use models to raise the level of abstraction to focus on important high-level issues, such as relationships and patterns, rather than getting bogged down in details. Modeling raises the level of abstraction and allows the system to be more easily understood from different perspectives.

Let the problem drive the solution

The architecture may become difficult to maintain and adapt to new stakeholder needs when technology, rather than the problem, drives the solution.

Therefore, let the needs of the stakeholders guide the architecture, instead.

Organize the architecture into loosely coupled, highly cohesive components

Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create, so if existing components can be reused, that may reduce effort required to create a system.

Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling. This improves comprehension, increases flexibility, and increases opportunities for re-use.

Reuse existing assets

It is wasteful to build what you can simply reuse, download, or even buy.

Therefore, make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those assets do not exactly meet their needs or those assets are of poor quality. Be prepared to balance the savings you can realize using an existing asset, even if the asset requires distorting the architecture or relaxing a constraint.

Leverage the architecture as a collaborative tool

Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers and can quickly paralyze the project. Developers may have different mental models of the system and work at cross purposes to each other.

Therefore, create and evolve the system architecture with the intention of using it to align the developer’s competing mental models of the system. A good architecture facilitates collaboration by providing a common vocabulary for all discussions regarding the system under development.