This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
Software systems consist of components and their relationships. A system’s architecture is the organization of its components and relationships, along with the principles that govern their design and evolution. An architecture describes a system in both its current and future states.
When a system’s organization is not governed, decisions tend to be driven by external factors. Often these involve respecting reporting structures, minimizing the scope of change, and shipping quickly. These can be important factors, but they can work against creating a system with a clear fundamental organization.
We can better manage a system’s fundamental organization by applying principles to its design and evolution. These architectural principles don’t need to replace other factors—shipping quicky may still be important—but they need to be part of the conversation. Software architecture, like any engineering discipline, involves trade-offs between competing goals.
Evolution is intrinsic to software architecture. Teams that use architectural principles to drive change over time—including adopting new principles when appropriate—can evolve their systems to deliver new capabilities and improve the security, dependability, maintainability, and other aspects of their system.
Ultimately, architecture’s role in software development is to take a holistic and intentional view of the system. It begins by identifying the fundamental organization of a system, describing its components and relationships. It sets principles that govern design to realize that fundamental organization. Most of all, it’s about establishing the principles via which those designs, components, and relationships will change over time.