Version 5.2, 25 June 2009
IEEE Std 1471 is the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. It was developed by the IEEE Architecture Working Group (AWG) under the sponsorship of the IEEE Software Engineering Standards Committee.
IEEE 1471 was approved for use as a recommended practice in September 2000.
In March 2006, IEEE 1471 was adopted as an ISO standard. It was published in July 2007 as ISO/IEC 42010:2007. The text of this ISO standard is identical to IEEE 1471:2000.
Revision: The standard is now being jointly revised by ISO and IEEE.
One type of IEEE standard whose adoption and interpretation are the responsibility of the using organization. Naturally, the authors hope it will evolve to a standard with wide use. Of course, any organization may mandate its use within that organization.
Revision: The joint ISO and IEEE revision will produce a full international standard: ISO/IEC 42010 Systems and Software Engineering—Architecture description. The IEEE designation will follow the ISO designation, and IEEE 1471 will become IEEE 42010.
Its focus is software-intensive systems: any system in which software development and/or integration are dominant considerations (i.e., most complex systems these days). This includes computer-based systems ranging from individual software applications, information systems, embedded systems, software product lines and product families and systems-of-systems.
Revision: The scope will be aligned for use with ISO/IEC 15288, Systems and software engineering—Systems life cycle processes and ISO/IEC 12207, Systems and software engineering—Software life cycle processes, to match the current charters of its sponsors: the IEEE Systems and Software Engineering Standards Committee and ISO JTC1/SC7 (Systems and Software Engineering).
IEEE 1471 specifies requirements on the contents of architecture descriptions (ADs). An AD is a document, repository or collection of artifacts used to define and document an architecture. The specific content requirements are discussed below.
Revision: The revision adds requirements on architecture frameworks (more about this below).
The key insights of IEEE 1471 are:
Architecture is that which is essential or unifying about a system; the set of properties of a system which determine the system's structure (form), behavior (function), value, cost, and risk. The definition in the recommended practice is:
architecture: 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.
There are several key ideas in this definition:
First, an architecture is a conception of a system – i.e., something in the mind. Therefore, an architecture may exist without ever being written down. The standard distinguishes architectures and architecture descriptions: just as it is said, "the map is not the territory", an architecture description is not the architecture. An architecture description is what is written down as an artifact or tangible work product; an attempt to represent a conception for others. The focus of the standard is on requirements on architecture descriptions.
Second, an architecture embodies fundamental things about a system as a whole; the essential or key properties of a system.
Third, an architecture is understood in context; not in isolation. To understand a system's fundamental properties (i.e., architecture) is to understand how the system relates to, and is situated in, its environment. We cannot know what is fundamental about a system without knowing fundamental to whom? Therefore "fundamental" is to be interpreted in the context of a system's stakeholders and its environment.
Finally, there are some things that an architecture definitely is not. An architecture is not just the overall structure of physical components that make up a system. While physical structure is often a fundamental aspect of a system, it is not necessary.
The IEEE 1471 definition was the subject of long debate; reflecting the debate that has raged (and continues) in the community at large. (For further discussion, see annex B of the recommended practice itself and this paper from the International Conference on the Engineering of Complex Computer Systems, Montreal, October 1996 [PDF]).
In IEEE 1471, every system is considered in the context of its environment: the sum total of all influences determining the setting and circumstances of developmental, technological, business, operational, organizational, political, regulatory, social and any other influences upon a system.
As in building architecture, system architecture should be sensitive to a system's environment and to the influences of that environment upon the system.
In IEEE 1471, this environment is modeled in terms of the stakeholders of the system and the architectural concerns they hold for that system. Identifying the stakeholders helps the architect to get a detailed understanding of the context in which the system must be developed, used and operated.
Examples of stakeholders: the client for the system, its users, operators, maintainers, system developers, suppliers, regulators, etc.
Examples of architecture concerns: agility, autonomy, complexity, concurrency, cost, data access, data integrity, distribution, evolvability, flexibility, functionality, information assurance, modifiability, modularity, openness, performance, persistence, quality of service, reliability, safety, schedule, security, state change, usability.
Many equate architecture with structure. This might even be true, given a sufficiently general notion of structure. This issue goes to the heart of IEEE 1471. Fundamentally, IEEE 1471 rests on two principles:
Principle (I) deserves a bit more discussion. Consider the question:
What is the architecture of the Internet? (i.e., What is the fundamental, unifying organization of the Internet?)
A short reflection should convince you that the fundamental, unifying organization of the Internet is neither its physical structure nor its software structure. Both are quite volatile. Rather, the enduring, organizing elements of the Internet are its protocols, especially IP, and its key routing concepts. From IP and the routing concepts, one can infer a great deal about possible network structures, limitations on possible services, and much more. However, from the momentary physical, or even software, structure, one can learn very little about the fundamental nature of the Internet.
This exercise can be repeated for any enterprise information system, for the World Wide Web and many other systems. Our conclusion is that architectures are often, increasingly, non-physical and that the definition of architecture should respect and evoke that realization. Note that nothing in the definition precludes its application to systems where structural concerns dominate the architecture, but we chose not to make those concerns a defining property of the term.
The two concepts are different; both are important. Consider:
A viewpoint is a way of looking at a system.
A view is what you see when looking from the chosen viewpoint.
A view is a collection of models representing the architecture of the whole system relative to a set of architectural concerns. Separation of concerns is a useful technique for managing complexity. A view is part of a particular architecture description for a system of interest. For example, a structural view of a system might include a model showing components and their interfaces and a model of their dependencies and inheritance relationships. A performance view might consist of models for resource utilization, timing schedules and cause-effect diagrams. The idea of a view is that it addresses a specific set of concerns about a system using well-defined notations and models.
A viewpoint captures the conventions for constructing, interpreting and analyzing a particular kind of view. Viewpoint conventions include languages, notations, model types, modelling methods, analysis techniques, design rules or other operations on views.
It was a key decision in IEEE 1471 to leave the viewpoint selection to users of the standard – rather than require all users to adopt the same set – because architectural concerns will vary from system to system.
Recall principle (II), that all views are equal—each one addresses "fundamental" concerns to the system. Therefore, each view should be developed in the languages and fashion that best address system stakeholders' concerns.
The basic idea is that a viewpoint defines some notation and some methods associated with that notation which allow the architect to address particular concerns about an architecture. The methods express how to construct a view, how to check the well-formedness of that view, or how to analyze that view to predict various properties of the system. The viewpoint also gives stakeholders a key (or legend) to understanding the notations in views of that type.
In most cases, individual architects need not develop their own viewpoints. Generally, organizations will establish a set of viewpoints based on their experience architecting particular classes of systems.
Annexes C and D of the recommended practice provide some example definitions of viewpoints. Since 2000, various viewpoints have been defined and published. See the IEEE 1471 Bibliography for references.
Actually, the recommended practice requires a good deal more than may be apparent on first examination, because some of its implications are subtle. It does not explicitly require an AD to address the system's boundary, however, IEEE 1471 does require that a system's stakeholders and their concerns be identified and then addressed. Could the system's boundary be among those concerns? Frequently, this would be a stakeholder concern, therefore it would be captured among the stakeholder and concerns statements.
Once a stakeholder and her concerns have been identified they must be framed by a viewpoint. Once a viewpoint has been selected there must be a corresponding view with its models, conforming to that viewpoint. So, in those cases where it is a stakeholder concern, an AD conforming to IEEE 1471 will contain a model of the system's boundary. The same logic holds for any other aspect of systems.
IEEE 1471 does not tell architects which viewpoints to use because there is no consensus on which views are important. Nor does it specify required stakeholders or concerns (beyond a minimum set each Architect should consider). The selection of stakeholders, concerns, and viewpoints, and the construction of the views, is the obligation of the Architect, in association with the stakeholders.
Consistency is a potential problem whenever multiple models and views are used. Sometimes, consistency rules or procedures are defined as a part of viewpoints. In other cases, organizations will have pratices they use to check and enforce consistency.
Revision: Model correspondences and model correspondence rules are introduced to express relationships between models and views. These correspondences can be used to capture and enforce consistency, traceability, and other relations.
Because there is a broad consensus that having a good architecture is critical to the success of a system or enterprise, and IEEE 1471 reflects a consensus of best practices for describing architectures.
An architecture description conforms with IEEE 1471 if it can be shown to satisfy the requirements ("shalls") in clause 5 of the recommended practice. In brief, these pertain to:
No. There are many existing ADLs and other notations that are valuable for documenting various aspects of the architecture of a system. Using IEEE 1471, you may pick one, or more than one, or make up your own.
Regardless of the merits, there is no consensus on any single ADL among many user communities of IEEE 1471 . There isn't even a consensus on what the requirements for an ADL should be.
There is, however, a consensus that architects should choose their notations carefully, document these choices, and be encouraged to use well-founded ADLs. The philosophy of IEEE 1471 is use the right tool for the job: use notations appropriate to addressing the architectural concerns that specifically arise for the system at hand. If this can be accomplished with a single ADL; that's great. If other notations are needed; use them – in a principled fashion within the organizing framework provided by IEEE 1471.
The Unified Modeling Language provides a family of notations; many of which can, and have, been used for architecture description. A number of organizations already use one or more of the UML notations to address one or more architectural concerns. Under IEEE 1471, these notations may be made part of a viewpoint and used to create an architecture description. By defining these practices as viewpoints, a organization can continue to use the UML while creating architecture descriptions conforming to IEEE 1471.
Revision: There is a proposal to add conformance of ADLs (including UML), so that someone may document an ADL, or UML profile, in such a manner that this language conforms to the rules of the standard.
No. It defines what you should have when you claim to have an architecture description, but it does not say how to produce one. Processes and methods for Architecting may be areas for future standardization work.
We hope so, but we would not claim that system quality is an automatic, direct consequence of using IEEE 1471 by itself. The intended consequence of using IEEE 1471 is more understandable ADs, which should contribute to better architectures, and thus to better systems.
IEEE 1471 is not a replacement for architecture frameworks such as DODAF, MODAF, TOGAF, RM-ODP, GERAM, and so on; it is a set of best practices for architecture description. It can and has been used with these and other frameworks.
Revision: Architecture framework is defined in the revision. A set of requirements on frameworks are introduced as an additional point of conformance to the standard.
Visit the IEEE 1471 website or send mail to IEEE 1471 Info. There are a number of resources available on the website, including: overview presentations of IEEE 1471; papers about using IEEE 1471; details about the IEEE 1471 Interest Group; and links to applications of IEEE 1471.
IEEE Std 1471-2000 can be purchased from the IEEE Store or from ISO as ISO/IEC 42010:2007.
Revision: Copies of working drafts may be obtained by request, or by participating in the revision. How to participate.
Resources for this website, in support of the revision of ISO/IEC 42010, provided by DSCI.The IEEE 1471 FAQ was written by Mark Maier, Dave Emery, and Rich Hilliard. Thank you to Judy Kerner (Aerospace) and Philippe Kruchten (UBC) for comments on earlier versions.
Version 5.x addresses questions related to the joint ISO, IEEE revision of the standard.
If you have questions about IEEE 1471 not addressed by the FAQ, please send a note. Send any comments, suggestions or questions to: IEEE 1471 FAQ.