Getting Started with ISO/IEC/IEEE 42010

This page provides some starting points for using the Standard (previously IEEE 1471:2000).

The Standard

The best place to start is with the Standard itself. The published version of ISO/IEC/IEEE 42010 can be obtained from ISO or from IEEE.

The Standard has several parts. The first part is a conceptual model of architecture descriptions (ADs). The conceptual model, sometimes called the “metamodel”, defines a set of terms and their relations [see Conceptual Model]. This metamodel has been widely used and discussed in industry and in the academic literature [see Bibliography]. The conceptual model establishes terms, their definitions and relations which are then used in expressing the requirements.

Architecture Descriptions

The second part of the Standard describes best practices for creating an architecture description. The best practices are specified in the Standard as 24 requirements (written as “shalls”) [see ADs]. An architecture description conforms to the Standard if it satisfies those requirements. Taken together, the “shalls” imply a process for preparing an AD roughly like this:

1. Identify the system stakeholders who have a stake in the architecture and record them in the AD. Be sure to consider: the users, operators, acquirers, owners, suppliers, developers, builders and maintainers of the system – when applicable.
2. Identify the architecture concerns of each stakeholder. Be sure to consider these common concerns – when applicable:
   • purposes of the system;
   • suitability of the architecture for achieving system’s purposes;
   • feasibility of constructing the system;
   • potential risks and impacts of the system to its stakeholders, throughout the life cycle; and
   • maintainability and evolvability of the system
3. Choose one or more architecture viewpoints for expressing the architecture, such that each concern [see 2, above] is framed by at least one viewpoint.
4. Record those viewpoints in the AD and provide a rationale for each choice of viewpoint.
5. Document each chosen viewpoint by writing a viewpoint definition [see below] or citing a reference to an existing definition. Each viewpoint definition links the architecture stakeholders and concerns to the kinds of notations and models to be used. Each viewpoint definition helps readers of the AD interpret the resulting view.
6. Produce architecture views of the system, one for each chosen viewpoint. Each view must follow the conventions of its viewpoint and include:
   • one or more models;
   • identifying information;
7. Document correspondences between view and model elements. Analyze consistency across all views. Record any known inconsistencies.
8. Record the AD the rationale(s) for architecture decisions made and give evidence of the consideration of multiple architectures and the rationale for this choice.

Templates for architecture descriptions and for documenting viewpoints are available [see: Templates].

Architecture Viewpoints

At the core of the Standard is the idea of architecture viewpoints. A viewpoint is a way of looking at the architecture of a system – or a set of conventions for a certain kind of architecture modeling. An architecture viewpoint is determined by:

1. one or more concerns;
2. typical stakeholders (intrested in those concerns and therefore a potential audience for views resulting from this viewpoint);
3. one or more model kinds;
4. for each model kind (above), the conventions: languages, notations, modelling techniques, analytical methods and/or other operations to be used on models of this kind;
5. sources.

The ISO/IEC/IEEE 42010 Bibliography contains references to definitions of many existing viewpoints.

Architecture Frameworks and ADLs

The third part of the Standard specifies best practices for architecture frameworks.

The Standard only specifies best practices on the documentation of architectures. It is intended to be used within a life cycle and/or within the context of a method or architecture framework – used to develop ADs. The Standard may be used to structure an AD when applied with various architecture frameworks. For example, the Zachman framework matrix essentially identifies a set of stakeholders and concerns to be addressed, and the cell entries suggest the (viewpoint) notations, languages and models. [See the Survey of Architecture Frameworks which includes a number of “viewpoint sets”, for the application domains of enterprises, systems and software.

The Standard also defines requirements on documenting an architecture framework.

In a similar manner, the Standard can be used to specify Architecture Description Languages (ADLs).

Further Reading

If you are new to modeling and architecting, the following books are good starting points – building upon the 42010 framework.

Nick Rozanski and Eoin Woods. Software Systems Architecture: Viewpoint Oriented System Development, 2nd edition. Addison Wesley, 2012.

Paul C. Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford. Documenting Software Architectures: views and beyond, 2nd edition. Addison Wesley, 2011.

Older sources, from the IEEE 1471 era:

Jeff Garland and Richard Anthony. Large Scale Software Architecture: A Practical Guide Using UML. John Wiley and Sons, 2002.

John Reekie and Rohan McAdam, A Software Architecture Primer, 2006.

There are several papers describing the background and key ideas of the original (IEEE 1471) edition of the Standard [see Bibliography]. Discussion of rationale for the features of the Standard:

Rich Hilliard. IEEE Std 1471 and beyond. Workshop on Software Architecture Representation, 16–17 January 2001. Software Engineering Institute, 2001.

These papers describe the design goals for the first edition of the Standard (IEEE 1471:2000):

Mark W. Maier, David Emery, and Rich Hilliard. Software architecture: Introducing IEEE Standard 1471. Computer, 34(4):107–109, April 2001.

Walter J. Ellis, Rich Hilliard, Peter T. Poon, David Rayford, Thomas F. Saunders, Basil Sherlund, and Ronald L. Wade. Toward a recommended practice for architectural description. Proceedings of 2nd IEEE International Conference on Engineering of Complex Computer Systems, Montreal, Quebec, Canada, October 21–25, 1996.

Comments Appreciated

This page is a work-in-progress. Comments or suggestions appreciated. Send to webmaster.