Version 5.7, 7 November 2013
ISO/IEC/IEEE 42010 is an International Standard entitled, Systems and software engineering — Architecture description.
The Standard, published in 2011, is the result of a joint ISO and IEEE revision of the earlier IEEE Std 1471:2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.
IEEE 1471 was developed by the IEEE Architecture Working Group under the sponsorship of the IEEE Software Engineering Standards Committee. In September 2000, the IEEE Standards Board approved IEEE 1471 for use.
In March 2006, IEEE 1471 was adopted as an ISO standard. It was published in July 2007 as ISO/IEC 42010:2007. Its text was identical to IEEE 1471:2000.
ISO/IEC/IEEE 42010:2011 replaces both ISO/IEC 42010:2007 and IEEE Std 1471:2000.
The original IEEE 1471 specified requirements on the contents of architecture descriptions of systems. An architecture description (AD) expresses the architecture of a system of interest. An AD could be a document, a repository or a collection of artifacts used to define and document an architecture. [The content requirements are discussed below.]
ISO/IEC/IEEE 42010 adds definitions and requirements on architecture frameworks and architecture description languages (ADLs) as conformance cases [more about these cases below].
The focus of the Standard is on three classes of systems:
The scope of the original IEEE 1471 was software-intensive systems. The revision widened the scope to align with the current charters of its sponsors: the IEEE S2ESC (Systems and Software Engineering Standards Committee) and ISO JTC1/SC7 (Systems and Software Engineering).
However, nothing in the Standard depends on the kind of system users of the Standard are interested in. It can be used to develop architecture descriptions for any kind of system or enterprise, as conceived by users of the Standard.
The key tenets of the Standard are:
The Standard defines architecture this way:
fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
There are several key ideas in this definition:
For further discussion of the definition, see [Defining architecture].
The original 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 A of the Standard, Notes on terms and concepts, and this paper from the International Conference on the Engineering of Complex Computer Systems, Montreal, October 1996 [PDF].
In the Standard, 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 is sensitive to the system’s environment and to the influences of that environment upon the system.
In the Standard, the environment of a system is understood through the identification of the stakeholders of the system and their system concerns. Identifying the stakeholders and concerns 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.
Examples of System Concerns: affordability, agility, assurance, autonomy, behavior, business goals, business strategies, complexity, concurrency, control, cost, customer experience, data access, data accessibility, data integrity, deadlock, disposability, distribution, evolvability, feasibility, flexibility, functionality, information assurance, inter-process communication, known limitations, maintainability, modifiability, modularity, openness, performance, persistence, privacy, quality of service, regulatory compliance, reliability, resource utilization, safety, schedule, security, state change, structure, subsystem integration, system features, system properties, system purposes, usability, and usage.
Architecture is often equated with structure. This might even be true, given a sufficiently general notion of structure. This issue goes to the heart of the Standard, which rests on two principles:
(I) The fundamental concepts of systems are increasingly non-physical and increasingly removed from what has been traditionally called "structure". In this tradition, "structure" usually refers to the components and organization of physically identifiable things, such as hardware entities or software objects such as modules.
(II) All architecture views of the system are of equal importance. The Standard does not assume that a physical-structural view is primary or that it can be used to derive other views or properties of the system.
Principle (I) deserves a bit more discussion. Consider the question:
What is the architecture 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 enterprise information systems, for the World Wide Web and many other types of 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:
An architecture viewpoint is a way of looking at a system.
An architecture view is what you see when looking at a system from a chosen viewpoint.
An architecture view is a collection of models representing the architecture of the whole system relative to a set of architectural concerns. Architects use multiple views for two reasons: First, because different notations have different strengths for exprssing various aspects of a system. Second, because 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 models of their dependencies and inheritance relationships. A performance view might consist of models for resource utilization, timing schedules and cause-effect diagrams. The key idea of a view is that it addresses a specific set of concerns about a system using well-defined notations and models.
An architecture viewpoint documents the conventions for constructing, interpreting and analyzing a particular kind of view. Viewpoint conventions include languages, notations, model types, modeling methods, analysis techniques, design rules and any associated methods.
It was a key decision in the original IEEE 1471 to leave the viewpoint selection to users of the Standard – rather than require all users to adopt the same set – because concerns will vary widely from system to system.
Recall principle (II), that all views are equal – each one addresses concerns which are fundamental 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 an architecture viewpoint defines some notation and some methods associated with that notation which allow the architect to frame specific 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.
The Standard encourages this – reusable viewpoints – by specifying requirements on architecture viewpoints. If viewpoints are defined in a uniform manner, then they can be documented, put on the shelf, reused, and improved upon across the community of architects.
An integrated set of viewpoints intended for a certain stakeholder community or domain of application is an architecture framework. [See below.]
A template for writing and documenting viewpoints is available. [See Templates.]
Annexes B and C of the Standard provide some example definitions of viewpoints. Since 2000, various viewpoints have been defined and published. [See the ISO/IEC/IEEE 42010 Bibliography for many references.]
Actually, the Standard requires a good deal more than may be apparent on first examination, because the implications of its requirements are subtle. While it does not explicitly require an architecture description to address the system’s boundary, the Standard 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 identified stakeholders and concerns.
Once a stakeholder and her concerns have been identified, they must be framed by one or more viewpoints. Once viewpoints have been selected, there must be a view, with its models, adhering to the conventions of each viewpoint.
Therefore, in those cases where the system boundary is a stakeholder concern, an architecture description conforming to the Standard will contain a model of the system’s boundary. The same logic holds for any other aspect of systems.
The Standard does not dictate to architects which viewpoints to use because there is no consensus on which views are important and because systems vary widely. Nor does it specify any required stakeholders or concerns for a system – beyond a minimum set which each architect must consider. The identification and selection of stakeholders, concerns, and viewpoints, and the construction of architecture views, is the responsibility 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 practices they use to check and enforce consistency.
ISO/IEC/IEEE 42010 introduces correspondences and correspondence rules to express relationships between elements within an architecture description. Correspondences can be used to capture and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation.
Because there is a broad consensus that having a good architecture is critical to the success of a system or enterprise. The Standard reflects the current consensus of the systems and software community’s best practices for describing architectures.
The Standard defines four cases of conformance:
1. Architecture Descriptions. An architecture description (AD) conforms to the Standard if it can be shown to satisfy the requirements ("shalls") in clause 5. In brief, these pertain to:
The requirements on ADs are summarized here.
Building upon the concepts in IEEE 1471:2000, the revision defines architecture framework and architecture description language as new conformance cases.
2. Architecture Frameworks. An architecture framework is defined as the conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders.
To conform to the Standard, an architecture framework must specify:
Further discussion of the requirements on frameworks is here.
3. Architecture Description Language. An architecture description language (ADL) is any form of expression for use in architecture descriptions. Examples of ADLs include: Rapide, Wright, SysML, AADL, ArchiMate and the viewpoint languages of RM-ODP [ISO 10746].
To conform to the Standard, an ADL must specify: the identification of concerns; the identification of stakeholders having those concerns; the model kinds implemented by the ADL which frame those concerns; any architecture viewpoints; and correspondence rules.
4. Architecture Viewpoint. A viewpoint may be separately specified from an AD, an architecture framework or an ADL. This is to promote reuse of best practices within the community.
The astute reader will notice a certain similarity to the requirements for the various cases above. The core case in the original IEEE 1471:2000 was the motivation for specifying requirements on frameworks and ADLs. In each case, the basic idea is: tell the reader who are the stakeholders, what are their concerns, and what notations, models and techniques will you use to frame those concerns for those stakeholders. In practice, frameworks and ADLs may have much more information, practices and processes associated with their use. An ADL will typically have automated tool support. The Standard does not put requirements on these, but establishes a minimal basis for comparision in terms of the stakeholders, concerns and viewpoints.
Templates for architecture descriptions and for architecture viewpoints are available to help users conform to the Standard. Other templates will be posted as they become available. [See Templates].
No. There are numerous ADLs and other notations that are valuable for documenting various aspects of the architecture of a system. Using the Standard, the architect may pick one, or more than one, or make up her own.
The Standard avoids choosing a particular ADL for the same reasons that it does not require a particular set of viewpoints: systems vary in the concerns that need to be addressed. The philosophy of the Standard is use the right tool for the job: choose notations appropriate to framing the relevant concerns that 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 offered by the Standard.
As noted above, ISO/IEC/IEEE 42010 defines minimum requirements on an ADL, these criteria may be helpful in selection of useful ADLs for a given project.
UML provides a family of notations; many of these notations can, and have, been used for architecture description. A number of organizations already use one or more of the UML notations to frame various system concerns. Using the Standard, these notations may be made part of a viewpoint and used to create an architecture description. By defining these practices through viewpoints, a organization can continue to use the UML while creating architecture descriptions that conforming to the Standard.
No, the Standard is process neutral. It defines what you should have when you claim to have an architecture description; it does not mandate how to produce one. There are many architecting processes and methods being used with the Standard. Processes and methods for Architecting may be areas for future standardization.
We hope so, but we would not claim that system quality is an automatic, direct consequence of using the Standard by itself. The intended consequence of using it is more understandable ADs, which should contribute to better architectures, and thus to better systems.
The Standard is not a replacement for architecture frameworks such as MoDAF, TOGAF, DoDAF, RM-ODP and so on; it is a set of best practices for architecture description. It can be – and has been – used with these and other frameworks. Our Survey of Architecture Frameworks presents a long list of recent frameworks and their attributes from the perspective of the Standard.
In the current revision, “architecture framework” is defined and minimum requirements on frameworks are specified. We hope that future and existing frameworks will orient themselves around these requirements thereby improving understandability and interoperability for architects working in various frameworks.
Visit the ISO/IEC/IEEE 42010 website or send questions to the webmaster. There are a number of resources available on the website, including: Getting Started, overview presentations about the Standard; papers about using it; details about the 42010 Users Group; and links to applications of the Standard.
ISO/IEC/IEEE 42010 can be obtained from ISO or from IEEE.
Resources for the ISO/IEC/IEEE 42010 website provided by Olimpia.com. Comments, corrections, suggestions on this site to: Webmaster.Version 5 is updated to the recently published joint revision of the Standard, ISO/IEC/IEEE 42010:2011.
The original IEEE 1471 FAQ was written by Mark Maier, David Emery, and Rich Hilliard. Thank you to Judy Kerner (Aerospace) and Philippe Kruchten (UBC) for comments on earlier versions.
If you have questions about ISO/IEC/IEEE 42010 not addressed by the FAQ, please send a note. Send any comments, suggestions or questions to: ISO/IEC/IEEE 42010 FAQ.