Version 5.0, 19 July 2007
IEEE Std 1471 is the 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.
Revision: In March 2006, IEEE 1471 was also adopted as an ISO standard. It was published in July 2007 as ISO/IEC 42010:2007, Systems and software engineering—Architectural description. The text of this ISO standard is identical to IEEE 1471:2000. This standard will now be 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 revision will produce a full international standard.
Its focus is software-intensive systems—any system in which software development and/or integration are dominant considerations—most complex systems these days. This includes computer-based systems ranging from individual software applications, information systems, embedded systems, product lines and product families and systems-of-systems.
Revision: One area for consideration during the revision is broadening the scope of the standard to "general systems" to better align with the charter of its sponsors: the IEEE Systems and Software Engineering Standards Committee and SC7 (Systems and Software Engineering) of ISO.
Conventions on Architectural Descriptions (ADs). That is, on documents or other artifacts that define an architecture. IEEE 1471 standardizes a basic framework for the content of an architectural description, in particular giving specific meaning to views and viewpoints.
No. There are many existing ADLs and other notations that are valuable for documenting various aspects of a software system's architecture. As a user of IEEE 1471, you may pick one, or more than one, or make up your own, within the framework provided by IEEE 1471.
Regardless of the merits of any particular ADL, there is no consensus among the broad spectrum of potential user-communities for IEEE 1471 on any ADL. 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 architectural 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 architectural description. By defining these practices as viewpoints, a organization can continue to use the UML while creating architectural descriptions conforming to IEEE 1471.
That architectures take into consideration the context of the system of interest.
That architectural descriptions be structured to meet the needs of the multiple stakeholders of the system, including, but certainly not limited to, the builders of the system.
That the concerns of multiple stakeholders are most readily addressed by architectural descriptions constructed with multiple views of the system, with each view covering an identified set of system concerns.
That the conditions on the completeness, well-formedness, and analyzability of views, be made explicit to readers of an architectural description in an architectural viewpoint (just as maps have legends next to them).
Every system has a context, or environment, in which the system is developed, operated and used. As in building architecture, system architecture should be sensitive to that 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 their specific concerns for that system. Stakeholders typically include the client for the system, its users, maintainers, operators, system developers, component vendors, and so on. Typical concerns include: reliability, functionality, security, data integrity, usability, and so on. Identifying the stakeholders helps the architect to get a detailed understanding of the context in which the system must be developed, used and operated.
We're not sure, but we know one when we see one. Seriously, it is a difficult concept to make precise. Perhaps this is not too surprising, given that the civil architecture community, with 5000 years or so of practice, has had little more success defining the architecture of a building.
Broadly speaking, an architecture is that which is essential or unifying about a system. It is that set of things about a system which largely determine the system's 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.
The definition in IEEE 1471 was the subject of long debate; reflecting the debate that has raged (and continues to rage) in the community at large. (For further discussion, see annex B of the recommended practice itself and our paper in the International Conference on the Engineering of Complex Computer Systems, Montreal, October 1996 [ICECCS'96 paper]).
There are several key ideas in our definition.
First, an architecture is a conceptual thing whereas an architectural description is a concrete artifact. An architecture may exist without ever being written down. An architectural description is not the architecture, it is an attempt to represent that concept for others.
Second, an architecture embodies "fundamental" things about a system. We mean "fundamental" in the sense of an abstraction of things that are important about the system as a whole—not in the sense of the top level in some arbitrary system/subsystem hierarchy. In general, a system will exist in many such hierarchies and no single one can be preferred.
Third, an architecture exists in context; not in the abstract. To understand a system's most fundamental characteristics (i.e., architecture) we must understand how the system relates to and is embedded into its environment. "Fundamental" should be interpreted in the context of stakeholders and the environment. We cannot know what is fundamental about a system without knowing "fundamental to whom?"
Fourth, 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 aspects of a system, it is not necessary.
Lots of people think they know that. It is even true, if the notion of "structure" used is sufficiently broad. This issue goes to the heart of what IEEE 1471 is all about. Fundamentally, the IEEE 1471 approach rests on two principles:
Principle (I) deserves a bit more discussion. Consider: What is the architecture of the Internet? That is, 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 also 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 same exercise can be repeated for enterprise information systems and for the World Wide Web. Our conclusion is that architectures are often, and increasingly, non-physical and that we should have a definition of architecture that respects and evokes that realization. Note that nothing in the definition precludes its application to systems where structural concerns dominate the architecture, but we did not want to make those concerns a defining property of "architecture".
The two concepts are different; both are important. Try this:
A viewpoint is a way of looking at a system.
A view is what you see when looking from the chosen viewpoint.
A bit more rigorously: a view is a collection of models that represents the whole system with respect to a set of related concerns. A view belongs to a particular architectural description. For example, a structural view of a system might include a model showing components, their interfaces and the classes comprising them, 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. We use terms like "operational view" and "performance view" where others have used terms like "operational architecture" and "performance architecture."
A viewpoint captures the rules for constructing and analyzing a particular kind of view. It is a template for a view which can be reused across many architectural descriptions. The term "view type" was considered as an alternative for viewpoint because of the strong analogy of view and viewpoint to instance and type; but we chose "viewpoint" because of its use in existing standards and the requirements engineering literature.
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 may 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.
For the most part, we expect individual architects will not write viewpoints. Organizations will develop libraries of viewpoints based on their experience architecting particular classes of systems. The software architecture literature documents numerous existing architectural techniques that can be (re)packaged as viewpoints. Annexes C and D of the recommended practice provide some example definitions of viewpoints. Papers such as Kruchten95 and Emery-Hilliard-Rice96 provide examples of viewpoints. Now that the recommended practice has been published, one area of focus for members of the working group is to create a repository of documented architectural viewpoints.
A key decision in IEEE 1471 was to leave the selection of viewpoints to using organizations, rather than require a fixed set of viewpoints in the standard. Although reducing the apparent normative content of the document, this avoided otherwise irreconcilable problems in establishing a consensus—given the diversity of view methods currently in use. In the future, perhaps this diversity can be brought into a common framework of viewpoint definitions; but this must await additional research and practical experience.
Recall our 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 stakeholder concerns. If, for example, financial auditors need their concerns about an on-line accounting system expressed in a particular way, we are inclined to agree with them.
We know that one important thrust in current research is to develop sophisticated languages for describing system structure (and usually more as well) and then develop methods for analyzing other properties (such as reliability, availability, security, etc.). We did not adopt this approach of single language (or, viewpoint) primacy for several reasons. First, we don't think it really works. These methods have not convinced domain specialists to give up their proven domain models, and we doubt they will. Second, real success in these research efforts is actually complementary to the IEEE 1471 approach rather than competitive with it. If these language and analysis techniques work well, they will help to solve the inter-view consistency problem (see below). The analysis methods allow one to resolve consistency issues between the views, each written in its stakeholders' "natural languages," and thus give a strong competitive advantage to the method's users.
Actually, the recommended practice requires a good deal more than may be apparent on first examination, because some of its implications are subtle. It is true that it does not explicitly require an AD to cover the system's boundary. However, IEEE 1471 does require that the system's stakeholders and their concerns be identified. Would a system's boundary be among those concerns? Almost certainly, and therefore it would be captured among the stakeholder and concerns statements. Once a stakeholder and her concerns have been identified they must be covered by a selected viewpoint. Once a viewpoint has been selected there must be a corresponding (and conforming) view with its models. So, in almost any conceivable case, a conforming IEEE 1471 AD will contain a model of the system's boundary. The same logic holds for many other aspects of systems.
Fundamentally, IEEE 1471 does not tell architects what views to use because there is no consensus on what views are important. Similarly, it does not specify required stakeholders or concerns (beyond a minimum set: users, acquirers, developers and maintainers). The selection of stakeholders, concerns, and viewpoints, and the construction of the views, is up to the architect (in association with others). Using organizations will develop processes that produce AD's conforming with IEEE 1471, or adapt their current processes. After some period of use perhaps additional consensus can emerge and be codified in standards or recommended practices, either in general or in domain-specific cases.
Well, we tried. Early drafts (through version 1.5) had much more direct normative statements; but these were soundly rejected by the reviewers, and for good reasons. All of the formulations we found essentially institutionalized one set of views, models, and/or processes over others. In this rapidly evolving field, we felt this was not acceptable. The formulation we have is an abstraction from examination of a wide range of best practices in these methods.
This multiple view stuff is very complicated. How are you going to reconcile across all those views?
We aren't—using organizations will, just as they do now. This is not a problem introduced by IEEE 1471. We already have multiple views and cross-view consistency problems: whenever the system has, for example, distinct descriptions of form and function, there is a cross-view consistency problem; adding reliability or security concerns compounds the problem. We hope that by making the treatment of views and viewpoints explicit, more attention will be given to the problem of cross-view consistency.
Because there is a broad consensus that having a good architecture is critical to system success, and IEEE 1471 presents consensus elements of good practice in describing architectures.
An architectural description is conformant with IEEE 1471 if it satisfies the requirements ("shalls") in clause 5 of the recommended practice. Briefly, these pertain to:
identifying the stakeholders of the system and their architectural concerns;
selecting and defining viewpoints to address those concerns;
documenting views of the architecture satisfying those viewpoints;
recording any known inconsistencies between views; and
providing rationale for architectural decisions made in the AD.
No. It defines what you should have when you claim to have an architectural description, but it does not say how to get one. However, using IEEE 1471 within the context of a well-defined process is definitely a good idea. Choosing that process is a task for using organizations. While eliminating process elements makes the application of the recommended practice somewhat less obvious, it was essential in finding a set of architectural practices on which community consensus exists. There was much more consensus on the contents of an AD than on the process for constructing an AD.
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 (indirectly) to better systems.
Our position on this is sometimes referred to as the "great compromise." During the AWG deliberations, there was some pressure to specify IEEE 1471 such that a system built to a conforming AD would be more or less "guaranteed" to be a "good" system. However, many efforts in that direction, to put greater restrictions on possible methods, to further standardize good processes, and so on, ran into problems of consensus—for obvious reasons.
To see the problem, consider the following hypothetical situation: a company proposes to build an automated tax return processing system for the Internal Revenue Service (IRS). Suppose that upon examining their architectural description we see they propose that all of the nation's tax returns can be processed in two days on a single Pentium-based PC—clearly, this is ludicrous. But one could prepare a IEEE 1471-compliant AD to document this proposed system. Therefore, one can write a IEEE 1471-conforming AD that makes ludicrous claims; we have tried to structure the requirements of the recommended practice in such a way that it enhances the ability of skilled practitioners to identify such problems, but it does not preclude their ability to express them.
It is apparent that no broad standard can exclude the descriptions of ludicrous architectures. Understanding what is and is not patently bad analysis requires significant domain knowledge, and that level of knowledge cannot be embedded into a standard. The choice then becomes, Can we structure the standard so that an AD must contain the analysis, done rightly or wrongly, or should the AD just enable the analysis to be done? As of draft version 2, the latter approach was taken, although with a nod to the former in the form of a requirement to include any known inconsistencies.
IEEE 1471 is not a replacement for these other standards; it is an organizing framework intended to supplement such standards, by providing specific content requirements on architectural descriptions. Annex D of the recommended practice addresses its relationship to IEEE/EIA 12207 Software life cycle processes and the ISO/IEC Open Distributed Processing—Reference Model (RM-ODP). The Open Group Architecture Framework (TOGAF) is also moving toward harmonization with IEEE 1471.
Other standards can be similarly recast as additional normative restrictions on IEEE 1471 ADs. For example, the US DOD's C4ISR Architecture Framework can be cast as requiring ADs to have three particular viewpoints selected, the viewpoints corresponding to the three C4ISR views (operational, system, and technical views). Seen this way C4ISR is an additional requirement placed on ADs for certain classes of system that facilitates the evaluation of those ADs from the perspective of the C4ISR group. This highlights the value of IEEE 1471 as an organizing framework for ADs in different domains, and potentially a means for understanding between domains. It also highlights that many existing architecture standards do not specify a set of views sufficient to satisfy all concerns, just those of particular stakeholder groups. There is nothing wrong with this, as long as system developers do not think that an incomplete expression of a systems architecture is actually anywhere near complete.
The topic will be further dealt with in the companion Guide to the recommended practice.
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; links to applications of IEEE 1471; and to an architecture curriculum and courses based on IEEE 1471.
IEEE Std 1471-2000 can be purchased from the IEEE Store or from ISO as ISO/IEC 42010:2007.
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 the previous version.
This version (5.0) starts to address issues pertaining 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.