Java Application Architecture: Architecture and Modularity
3.1. Defining Architecture
There are numerous definitions of architecture. But within each lies a common theme and some key phrases. Here are a few of the definitions. From Booch, Rumbaugh, and Jacobson (1999):
- An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural elements and behavioral elements into progressively larger subsystems, and the architecture style that guides this organization—these elements and their interfaces, their collaborations, and their composition.
Now, from the ANSI/IEEE Std 1471-2000 (the Open Group):
- The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
In the Open Group Architecture Framework (TOGAF), architecture has two meanings depending on context (the Open Group):
- 1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation
- 2) The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
Examining these definitions reveals many common keywords, which I’ve made bold in the various definitions. Important underlying currents are embodied by these keywords. But, these keywords lead to some important questions that must be answered to more fully understand architecture. What makes a decision architecturally significant? What are the elements of composition? How do we accommodate evolution of architecture? What does this have to do with modularity? As we delve into these questions, I want to start with a story on software architecture.