The term “architecture” is widely used in software and systems engineering. One hears of “software architectures,” “technical architectures,” “operational architectures,” “network architectures,” etc. Within these labels, there are a variety of methods and techniques used to capture the “architecture” in question. The IEEE recently approved IEEE Std 1471, “Recommended Practice for Architecture Descriptions of Software-Intensive Systems.” One of the key contributions of this standard is its ability to capture what is meant by an “architecture.” IEEE 1471 defines architecture as : The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. Within the ontology of IEEE 1471, every system has an architecture, which may have one or more representations. Representations are described by one or more views, where each view represents the notion of “fundamental organization” of interest to one or more stakeholders for the system.
Rather than specifying the exact contents of an architectural description, IEEE 1471 instead provides the framework for defining architectural descriptions. In Ada terms, IEEE 1471 is a generic for constructing architecture descriptions, with generic formal parameters that capture the stakeholders of a system, their concerns and a set of viewpoints that can be used to represent stakeholder concerns. A conforming architectural description of a system is an instance of this generic template. An advantage of this approach is that it supports the notion of 'reuse' of viewpoints, i.e. an organization can define standard ways for representing parts of an architecture, which are instantiated for each architectural description developed by the organization. There are several standard techniques for architectures that can be represented by the IEEE 1471 model, including RM ODP, C4ISR Architecture Framework, and the “4+1 Model.”
This talk will introduce the IEEE 1471 model, and use it to examine several different methods to describe architectures. We do not define a “single right answer.” Instead, we hope to provide the tools to allow architects to select an architectural description that matches the specific needs of their problem.