By: Dr.Thomas J Mowbray Chairman, iCMG

4+1 View Model: A four viewpoint approach under development by Rational Software. The viewpoints include: logical, implementation (formerly "component"), process (i.e. run-time), and deployment. The "+1" denotes use case specifications supporting requirements capture. This approach is closely aligned with the Unified Modeling Language and the Unified Process.

Academic Software Architecture: Academic software architecture comprises a community of computer science researchers and educators constituting an academic field. Their educational efforts are focused on basics and fundamentals. In their research contributions, this community avoids proven architectural standards and practices, in order to achieve originality, theoretical formality, and other academic goals.

Common Principles

It is often said that the principles of software are simple. For example, let's consider (1) simplicity and (2) consistency. Architects agree that managing complexity (i.e. simplicity) is a key goal, because it leads to many architectural benefits, such as system adaptability and reduced system cost. For example, a simpler system is easier to test, document, integrate, extend, and so forth.

Simplicity is most necessary in the specification of the architecture itself. Most architectural approaches utilize multiple viewpoints to specify architecture. Viewpoints separate concerns into a limited sets of design forces which can be resolved in a straightforward and locally optimal manner. Consistency enhances system understanding and transference of design knowledge between parts of the system and between developers. An emphasis on consistency contributes to the discovery of commonality and opportunities for reuse. Architects agree that unnecessary diversity in design and implementation lead to decidedly negative consequences, such as brittle system structure.

Architecture Controversies

The principle disagreements among architecture schools include: (1) terminology, (2) completeness, and (3) a-priori viewpoints. Architects disagree on terminology due to their backgrounds or schools of thought. For example, when discussing software interfaces, the consistency principle is variously called: standard interfaces, common interfaces, horizontal interfaces, plug-and-play interfaces, and interface generalization. We can also argue that variation-centered design and component substitution are largely based upon consistent interface structure.

Unnecessary diversity of terminology leads to confusion, and sometimes to proprietary advantage. Some vendors and gurus change terminology so frequently, that it becomes a time-consuming career, keeping up with their latest expressions. Differences in terminology lead to mis-communication. In contrast, there are some distinct areas of disagreement among architecture schools, that can't be resolved through improved communications alone. The notion of complete models is promoted by legacy OO approaches (e.g. OMT), the Zachman Framework school, and various others. These groups have promoted a vision that complete models (describing multiple phases of development) are a worthwhile goal of software development projects.

Other schools would argue that multiple models are not maintainable; that unnecessarily detailed models are counterproductive; and that architectural significance should be considered when selecting system features for modeling. These contrary notions can be summarized as the principle of pragmatism. We side with the pragmatists for the above reasons and because most software systems are too complex to model completely (e.g. multi-threaded distributed computing systems). Pragmatism is a key principle to apply in the transition from document-driven process to architecture-centered software process. The selection of architecture viewpoints is a key point of contention among architecture schools. Some schools have pre-selected a-priori viewpoints.

Some schools leave that decision to individual projects. The Zachman Framework is an interesting case, because it proposes 30 viewpoints, among which, most projects select groups of viewpoints to specify. Variable viewpoints have the advantage that they can be tailored to address the concerns of particular system stakeholders. Pre-defined viewpoints have the advantage that they can accompany a stable conceptual framework and a well-defined terminology, as well as, pre-defined approaches for resolving viewpoint consistency and architecture conformance.