ISO/IEC/IEEE 42010 defines architecture description (AD) and specifies requirements on architecture descriptions. See the [Conceptual Model] on which the requirements are based. For templates and guidance for creating ADs see [Templates].
architecture description (AD)
work product used to express an architecture
Just as building architects distinguish the architecture they have in mind from the sketches, drawings and blueprints they use to convey that vision, it is helpful to distinguish the architecture of a system or enterprise from the artifacts created to document that architecture – the architecture description.
The Standard does not prescribe the form that an AD takes, as long as it meets certain requirements. (These are the requirements found in Clause 5 of the Standard.) An architecture description might take the form of a document, hypertext or a wiki, a collection of models, a repository, or some other medium. When we say, "an AD includes contents X" below, that can mean either by physical inclusion or by reference (in a manner not defined by the Standard).
An architecture description conforms to ISO/IEC/IEEE 42010:2011 when it meets the requirements in Clause 5. The items below provide an informal overview; please see the original text for the actual requirements. Also, for insight into the terms used below, please refer to the conceptual model.
In the Standard, system is used as a placeholder for a wide variety of possible subjects. An AD can be produced for any of the following: a man-made system comprised of hardware, software, data, humans, processes and procedures facilities, materials and naturally occurring entities; software products and services; individual applications, subsystems, systems of systems, product lines, product families, whole enterprises, or other aggregations of interest.
Examples of this information might be: authors, reviewers, approving authority, issuing organization; change history; configuration management information; context; date of issue and status; glossary; overview; references; scope; summary; and version control information.
When identifying stakeholders, the following are to be considered and included when applicable: users of the system; operators of the system; acquirers of the system; owners of the system; suppliers of the system; developers of the system; builders of the system; maintainers of the system.
When identifying concerns, the following are to be considered and included when applicable: the purposes of the system; the suitability of the architecture for achieving the system’s purposes; the feasibility of constructing and deploying the system; the potential risks and impacts of the system to its stakeholders throughout its life cycle; maintainability and evolvability of the system.
We say "a viewpoint frames a concern" when the viewpoint gives the architect the means to express that concern. E.g., the formalism of Gantt charts frames concerns about project activities, schedule and dependencies, whereas other notations, such as UML use case diagrams, would not be helpful for modeling these concerns. Associating concerns with viewpoints contributes to architects "using the right tool for the job" when modeling the architecture.
A model kind captures conventions for a type of modeling. To adequate frame a set of concerns, a viewpoint can use one or more model kinds.
In addition, a viewpoint might define any of the following to aid the architect: