Focus on articulating the architecture.
Without a focal point a system can evolve in an inefficient and possibly haphazard way. Such as system may prove difficult to evolve, re-use, or integrate without substantial rework. Furthermore, it may prove difficult to organize the team or communicate ideas without a common focus.
Therefore, articulate essential technical decisions through a growing architecture. Develop the architecture of the system early and use the architecture and use the architecture as a focal point for the developers to align their interests and ideas.
Practices
Architect for what you know today.
Make everything as simple as possible but no simpler. (A. E.)
Software projects are resource constrained and the desire of developers to create elegant solutions may lead to a system of greater complexity than is required by the stake holders. Furthermore efforts to “future proof” a system in a turbulent uncertain environment will likely lead to bloat and increase cost.
Therefore, understand the real needs of the stake holders and use judgment when selecting architectural mechanisms. Create architectures that 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 over engineer the architecture.
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 very hard to see the system forest due to the software trees.
Therefore use models to raise the level of abstraction, allowing you to focus on important aspects, 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.
When technology drives the architecture for a system then the architecture may be difficult to maintain and grow as the stake holder needs change.
Therefore, let the needs of the stake holder drive the architecture rather than the implementation technology.
Architect with loosely coupled cohesive components.
Software is complex and people have a limited capacity for coping with complexity. Furthermore, software is expensive to create and if existing components may be re-used then this may reduce effort required to create a system. Finally, tightly coupling between components makes a system fragile and difficult to understand.
Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling. This will improve comprehension, increase flexibility, and increase opportunities for re-use.
Re-use existing assets.
It is wasteful to build what you can simply re-use, download, or even buy.
Therefore, make every effort to re-use existing assets. Developers are often reluctant to use assets because those assets do not exactly meet their needs. 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, evolve, and communicate the system architecture with the intention of using it to align the developer’s competing mental models of the system. Furthermore, the architecture facilitates collaboration by providing a common vocabulary for all discussions regarding the system under development. |