Architected Futures™

Tools and strategies ... for boiling the ocean

IEEE1471

ANSI/IEEE-1471:2000 Recommended Practice for Architectural Description of Software-Intensive Systems is a formal engineering standard that establishes a set of content requirements on an architectural description. This standard was adopted as an ISO standard (ISO 42010:2007) in 2006 and published in 2007 with an identical text to IEEE-1471:2000. ISO/IEC/IEEE 42010:2011 has since replaced both ISO/IEC 42010:2007 and IEEE Std 1471:2000.[bib]Hilliard2011[/bib]

IEEE 1471 Recommended Practice

The framework defined by IEEE 1471 is shown in Figure 1 as a UML class diagram.

IEEE 1471 Conceptual Framework

Figure 1IEEE 1471 Conceptual Framework

The focus of IEEE 1471 is the Architectural Description. Our focus is the architecture itself, as a mirror of the system. However, we need a vehicle for describing the architecture (as a means of describing the system) in order to be able to manage its evolution in the achievement of its mission, within a constantly changing environment. Thus, our incorporation of IEEE 1471 as an engineering specification.

The following narrative reads the IEEE framework generally from upper right to lower left. Bold, italicized words refer to the boxes in the diagram, which represent the significant entities in the model. The narrative largely describes the relationships being defined between the entities which gives the totality of the Architecture Description system its function. It states:

  • Systems inhabit and are influenced by their Environments. The environment defines the context for and imposes requirements on the system. In a static analysis the environment is considered a given. In a dynamic analysis, over the life cycle of a system, the system can also impact and influence its environment. The impacts in both directions can be positive or negative.
  • Systems have one or more Stakeholders each of whom have one or more Concerns. Concerns may be important to one or more Stakeholders. Typical stakeholders include owners, customers, investors, employees and the communities in which the system operates.
  • Systems exist to fulfill one or more Missions. The mission provides purpose to the system. The mission of the system involves the satisfaction of one or more of the significant concerns of the primary stakeholders.
  • Systems have Architecture. This is defined by IEEE 1471 as the fundamental organization of the system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. The architecture of the system exists independent of its documentation.
  • The Architecture of a System is described by one and only one Architecture Description. A complete, consistent and up-to-date architectural description is a valuable engineering tool for the management of the system. However, the architecture description may be missing, incomplete, inconsistent, obsolete, or in contradiction to the actual architecture. All of these are qualities that would detract from the efficient and effective operation and development of the system.
  • The Architecture Description provides Rationale, and the Rationale participates in the Architectural Description. The rationale explains the architecture and trade-offs or other choices that were made in its development. The rationale also provides guidance in the management and maintenance of the architecture where the choice and arrangement of components may need to change over time.
  • A complete Architecture Description identifies all Stakeholders and their associated Concerns and explains how the concerns are resolved. This is accomplished by identifying and selecting one or more Viewpoints, each of which are addressed to one or more Stakeholders and used to cover one or more Concerns. Viewpoints may be sourced from a Library Viewpoint, which is a standard perspective with some demonstrated utility.
  • The Architectural Description is organized into one or more Views which conform to the Viewpoints. The views provide the actual documentation about the architecture of the system from the perspective of the viewpoint. Each view documents the whole of the system from that viewpoint. Views consist of Models which are aggregated in the Architectural Descriptions. The same models may be used in multiple views and the same system components may be specified in multiple models, potentially in different levels of detail or from differing perspectives. The Viewpoint establishes the methods to be used in the Model.

IEEE 1471 does not prescribe any particular view or viewpoint as mandatory. Nor does it prescribe specific models or modeling technologies.

The Zachman Framework described earlier can be mapped into the IEEE 1471 framework as a comprehensive set of 36 views where each view conforms to a viewpoint defined by an abstraction level and point of focus. The Enterprise Architecture Tool Suite supports this and other mappings as part of an architecture description.

 

 

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.