What is ISO/IEC/IEEE 42010?

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.

What does the Standard standardize?

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.]

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.

What are the main contributions of the Standard?

The key tenets of the Standard are:

that the architecture of a system of interest is what is
considered fundamental about that system in the context of its
environment;

that an architecture description documents an architecture;

that architecture descriptions should demonstrate how an
architecture meets the needs of the system’s diverse
stakeholders;

that the architecture concerns of the diverse stakeholders can be
addressed by an architecture description constructed with multiple
architecture views of the system, where each view covers an
identified set of those concerns;

that the rules for well-formedness, completeness and analyzability
of each architecture view should be explicit to readers of an
architecture description via an architecture viewpoint;

that these ideas can be captured via a
conceptual model or,
metamodel, establishing the key concepts and terms for
talking about architectures and architecture descriptions.

So, what is an architecture?

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:

"Architecture" names that which is fundamental or unifying about a
system as a whole; the set of essential properties of a system which
determine its form, function, value, cost, and risk.

An architecture is a conception of a system – i.e.,
it is in the human mind. An architecture may exist without ever
being written down. Therefore, 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 a concrete work product. An architecture description
represents an attempt to express a conception of a system to share
with others. The focus of the Standard is on requirements on
architecture descriptions.

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. Often, the architect 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 in its environment.

Finally, there are some things that an architecture definitely is
not. An architecture is not merely the overall structure
of physical components that make up a system. While physical
structure can be fundamental to a system, it need not be.
[See below.]

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].

What do you mean by "context"?

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.

Isn’t the architecture of a system its top-level structure?

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.

What’s all this about views and viewpoints?

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.

Why aren’t any viewpoints required by the Standard?

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.

What do viewpoints look like and how do I write them?

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.]

This Standard doesn’t require anything! It doesn’t even require an
Architect to define the system’s boundary.

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.

Multiple views can get very complicated. How do you keep views
consistent?

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.

Why should I use the Standard?

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.

What is involved in conforming to the Standard?

The Standard defines four cases of conformance:

architecture description (AD)

architecture framework

architecture description language (ADL)

architecture viewpoint

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:

identifying the stakeholders of the system and their
concerns;

choosing and defining viewpoints that frame, or cover, those
concerns;

documenting the views of the architecture, such that each
satisfies one of those viewpoints;

linking together those views with correspondences and recording
any known inconsistencies between views; and

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.

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].

Does the Standard require a particular ADL? If not, why
not?

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.

How does the Standard relate to the Unified Modeling
Language?

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.

Does the Standard require a specific Architecting process?

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.

Does conforming with the Standard lead to better systems?

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.

We are already using an architecture framework –
what do we need this Standard for?

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.

How can I find out more about the Standard?

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.