Abstract: This recommended practice addresses the activities of the creation, analysis, and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions . A conceptual framework for architectural description is established. The content of an architectural description is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards, and examples of usage. Keywords: architectural description, architecture, software-intensive system, stakeholder concerns, system stakeholder, view, viewpoint IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA IEEE is the sole entity that may authorize the use of certification marks, trademarks, or other designations to indicate compliance with the materials set forth herein. Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Note: Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. It has long been recognized that "architecture" has a strong influence over the life cycle of a system. In the past, hardware-related architectural aspects were dominant, whereas software-related architectural integrity, when it existed, often was to be sacrificed first in the course of system development. Today, softwareintensive systems are pervasive. The cost of software development and the increasing complexity of software systems have changed the relative balance. Software technology is maturing rapidly. The practice of system development can benefit greatly from adherence to architectural precepts. However, the concepts of architecture have not been consistently defined and applied within the life cycle of software-intensive systems. Despite significant industrial and research activity in this area, there is no single, accepted framework for codifying architectural thinking, thereby facilitating the common application and evolution of available and emerging architectural practices. The IEEE Architecture Planning Group (APG) was formed in August 1995 to address this need. The APG was chartered by the IEEE Software Engineering Standards Committee (SESC) to set a direction for incorporating architectural thinking into IEEE standards. The result of the APG's deliberations was to recommend an IEEE activity with the following goals: -To define useful terms, principles and guidelines for the consistent application of architectural precepts to systems throughout their life cycle -To elaborate architectural precepts and their anticipated benefits for software products, systems, and aggregated systems (i.e., "systems of systems") -To provide a framework for the colilection and consideration of architectural attributes and related information for use in IEEE standards -To provide a useful road map for the incorporation of architectural precepts in the generation, revision, and application of IEEE standards In April 1996 SESC created the Architecture Working Group (AWG) to implement those recommendations. iv Copyright © 2000 IEEE. All rights reserved. At the time this recommended practice was completed, the Architecture Working Group had the following membership.  This recommended practice addresses the architectural description of software-intensive systems. A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. The scope of this recommended practice encompasses those products of system development that capture architectural information. This includes architectural descriptions that are used for the following: a) Expression of the system and its evolution b) Communication among the system stakeholders c) Evaluation and comparison of architectures in a consistent manner d) Planning, managing, and executing the activities of system development e) Expression of the persistent characteristics and supporting principles of a system to guide acceptable change f) Verification of a system implementation's compliance with an architectural description g) Recording contributions to the body of knowledge of software-intensive systems architecture The purpose of this recommended practice is to facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardization of elements and practices for architectural description. Despite significant efforts to improve engineering practices and technologies, software-intensive systems continue to present formidable risks and difficulties in their design, construction, deployment, and evolution. Recent attempts to address these difficulties have focused on the earliest period of design decision-making and evaluation, increasingly referred to as the architectural level of system development. The phrases archi- tectural level and architecture are widely, if imprecisely, used. Their use reflects acceptance of an architectural metaphor in the analysis and development of software-intensive systems. A key premise of this metaphor is that important decisions may be made early in system development in a manner similar to the early decision-making found in the development of civil architecture projects. Many innovations are resulting from this attention to the architectural level, among them architectural description languages and associated tools and environments; architectural frameworks, models, and patterns; and techniques for architectural analysis, evaluation, and architecture-based reuse. While these efforts differ considerably in important aspects, sufficient commonality exists to warrant the development of a recommended practice to codify their common elements. These innovations are occurring, and maturing, rapidly within many research and application communities, and they reflect differing interests, influences, insights, and intentions. There is a general consensus on the importance of the architectural level of systems development , and that that level consists of early decisionmaking about overall design structure, goals, requirements, and development strategies. However, there has not yet emerged any reliable consensus on a precise definition of a system's architecture , i.e., how it should be described, what uses such a description may serve, or where and when it should be defined. The boundaries and relationships between architectural trends and practices, and other practices; and between architectural technology and other technology, are not yet widely recognized. In such situations, progress often depends on mediating influences. Potential adopters of architectural practices and technology need a frame of reference within which to address implementation and adoption decisions. Technology developers need a frame of reference within which to communicate the motivating concepts of their technology, and to accumulate and appreciate feedback from early adoption. To these ends, this recommended practice is intended to reflect generally accepted trends in practices for architectural description and to provide a technical framework for further evolution in this area. Furthermore, it establishes a conceptual framework of concepts and terms of reference within which future developments in system architectural technology can be deployed. This recommended practice codifies those elements on which there is consensus; specifically the use of multiple views, reusable specifications for models within views, and the relation of architecture to system context. The principal class of users for this recommended practice comprises stakeholders in system development and evolution, including the following: -Those that use, own, and acquire the system (users, operators, and acquirers, or clients ) -Those that develop, describe, and document architectures (architects) -Those that develop, deliver, and maintain the system (architects, designers, programmers, maintainers, testers, domain engineers, quality assurance staff, configuration management staff, suppliers, and project managers or developers ) -Those who oversee and evaluate systems and their development (chief information officers, auditors, and independent assessors) A secondary class of users of this recommended practice comprises those involved in the enterprise-wide infrastructure activities that span multiple system developments, including methodologists, process and process-improvement engineers, researchers, producers of standards, tool builders, and trainers.  An architectural description conforms to this recommended practice if that description meets the requirements listed in Clause 5. This recommended practice shall be used in conjunction with the following publications. When the following standards are superseded by an approved revision, the revision shall apply.  For the purposes of this standard, the following terms and definitions apply.  An organization that procures a system, software product, or software service from a supplier. (The acquirer could be a buyer, customer, owner, user, or purchaser.) The person, team, or organization responsible for systems architecture. The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. A collection of products to document an 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. A framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, which spans the life of the system from the definition of its requirements to the termination of its use. A collection of components organized to accomplish a specific function or set of functions. 3.8 system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. A representation of a whole system from the perspective of a related set of concerns.  A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. This clause introduces a conceptual framework, or frame of reference, for architectural description. The framework establishes terms and concepts pertaining to the content and use of architectural descriptions. These terms and concepts will be used in subsequent clauses. For the purposes of this recommended practice, the term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system inhabits an environment. A system's environment can influence that system. The environment, or context , determines the setting and circumstances of developmental, operational, political, and other influences upon that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems. A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to, that system. Concerns are those interests which pertain to the system's development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability. A system exists to fulfill one or more missions in its environment. A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. Every system has an architecture, in the terms of this recommended practice. An architecture can be recorded by an architectural description (see Figure 1 ). This recommended practice distinguishes the architecture of a system, which is conceptual, from particular descriptions of that architecture, which are concrete products or artifacts. Architectural descriptions (ADs) are the subject of this recommended practice. In the conceptual framework of this recommended practice, an architectural description is organized into one or more constituents called (architectural) views . Each view addresses one or more of the concerns of the system stakeholders. The term view is used to refer to the expression of a system's architecture with respect to a particular viewpoint. NOTE-This recommended practice does not use terms such as functional architecture , physical architecture , and technical architecture , as are frequently used informally. In the conceptual framework of the recommended practice, the approximate equivalents of these informal terms would be functional view , physical view , and technical view , respectively. Other information, not contained in any constituent view, may appear in an AD , as a result of an organization's documentation practices. Examples of such information are the system overview, the system context, the system stakeholders and their key concerns, and the architectural rationale. A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modeling methods or analysis techniques to be Copyright © 2000 IEEE. All rights reserved. applied to these representations of the view. These languages and techniques are used to yield results relevant to the concerns addressed by the viewpoint. An architectural description selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration of the stakeholders to whom the AD is addressed and their concerns. A viewpoint definition may originate with an AD, or it may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this recommended practice as a library viewpoint . A view may consist of one or more architectural models . Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view. NOTE-In a complex system, ADs may be developed for components of the system, as well as for the system as a whole. In this case, it may be that one AD will have a view corresponding to a particular viewpoint and another AD will have a view corresponding to the same viewpoint. Although the system being described by these two views has the whole-part relationship, this is not an instance of multiple views corresponding to one viewpoint. The ADs are considered separate even though they are related by the systems they describe. NOTE- Figure 1 provides an informative summary of the key concepts introduced by this recommended practice and their inter-relationships. The figure presents these concepts in the context of an architecture for a particular system and an associated architectural description. This is not to assume or require that a system has only one architecture or that there is only one architectural description depicting that architecture. In the figure, boxes represent classes of things. role can optionally be named with a label. The role from A to B is closest to B, and vice versa. For example, the roles between SYSTEM and ENVIRONMENT can be read: A SYSTEM inhabits an ENVIRONMENT , and an ENVIRONMENT influences a SYSTEM . In the figure, roles are one-to-one unless otherwise noted. A role can have a multiplicity, e.g., a role marked with "1..*" is used to denote many , as in a one-to-many or many-to-many association.  Lines connecting boxes represent associations between things. An association has two roles (one in each direction Stakeholders have various roles with regard to the creation and use of architectural descriptions. Stakeholders include clients, users, the architect, developers, and evaluators. Two key roles among stakeholders are the acquirer (or client) and the architect. The architect develops and maintains an architecture for a system to satisfy the acquirer. The architect may work from requirements provided by an acquirer or may be responsible for eliciting and developing requirements as part of the architecture development. The role of the acquirer can be filled by a buyer, customer, owner, user, or purchaser (see IEEE/EIA Std 12207.0 − 1996 3 ). The role of the architect can be filled by different persons, teams, or organizations throughout the life cycle of the architecture. The architect records the architecture for the system's stakeholders in the form of an architectural description. In this form, the architecture serves to guide the system's developers. Architecting contributes to the development, operation, and maintenance of a system from its initial concept until its retirement from use. As such, architecting is best understood in a life cycle context, not simply as a single activity at one point in that life cycle. Architecting is concerned with developing satisfactory and feasible system concepts, maintaining the integrity of those system concepts through development, certifying built systems for use, and assuring those system concepts through operational and evolutionary phases. Detailed systems engineering activities, such as detailed requirements definition and interface specification and the architecting of major subsystems are tasks that typically follow development of the system architecture. This recommended practice neither assumes nor prescribes a specific life cycle model-a life cycle model is to be separately chosen by users of the recommended practice. The scenarios in 4.3.1-4.3.4 are intended to suggest the range of uses of the recommended practice within a system life cycle. For new system construction, in cases where the user and the acquirer are identical, architecting is carried out in response to the user-acquirer's vision for the system, the system goals, and stakeholders' needs and constraints. The primary stakeholders are the user-acquirer and the system developers. The architectural description can be used throughout the life cycle to predict the fitness for use of a system whose architecture conforms to the architectural description. In addition, the AD will typically evolve throughout the life cycle, and can thus act as a means for assessing changes to the system. 3 Information on references can be found in Clause 2. Copyright © 2000 IEEE. All rights reserved.  Under this scenario, the architecture, the delivered systems, and the stakeholders coevolve. An initial architecture is prepared in response to current and expected user needs using current and estimated technological capabilities. Initial systems are delivered using this architecture. As the architecture evolves in response to new stakeholders' needs, systems are delivered based on the architecture current at the time of development. Likewise, the set of stakeholders in the systems and architecture will change as the architecture evolves. For evolutionary systems, the architectural description is used for system development and evaluation, but its uses and development are concurrent. Stakeholder needs are reassessed with each iteration of the architecture; the AD is used to guide each system as it moves through development, and appropriate AD versions are used to evaluate each system on delivery. Architectures developed under this scenario will naturally emphasize flexibility and adaptability more strongly than single system architectures. Architectural descriptions for evolving systems will typically be developed in an iterative pattern, or rhythm, of version changes. The architecture development will normally be carried out by the developer as part of the overall activity of developing a sequence of systems. The architecture can also be established by the acquirer as a way of organizing the acquisition and evolution of a sequence of systems. This approach is one way to evolve a product line architecture. Evolution of the architecture will normally be sponsored by the acquirer as a part of the overall activity of sequential development or, in the case of commercial-off-the-shelf software, deployment of systems. A third scenario occurs when system development has taken place without an architectural description, or when the AD, and perhaps the architect, are no longer available. The built system will have an architecture (since every system has an architecture, whether known or not) but it will lack an architectural description. In this case, an AD can be created through a reverse-engineering effort. Using this recommended practice, an architectural description of the existing system is first constructed. This AD is then used to develop a new system, to guide maintenance or evolution activities, or to establish an evolutionary architecture as in the scenarios above (see 4.3.1 and 4.3.2). In some cases, a new AD is needed because the original description does not provide views that are necessary later in a system's life cycle. The purpose of evaluation is to determine the quality of an architectural description and to predict the quality of systems whose architectures conform to the architectural description. Quality of an architectural description refers to its capability to meet the needs and concerns of the stakeholders for whom it was constructed. Such concerns typically include understandability, consistency, completeness, and analyzability of the description. Prediction of the quality of systems resulting from the architectural description includes such qualities as feasibility, efficiency, and reliability. In order to evaluate conformance of an architecture to an architectural description, a process for reverse engineering an architectural description from an implementation is needed (see 4.3.3).  Architectural descriptions are applicable to a variety of uses, by a variety of stakeholders, throughout the life cycle. These uses include, but are not limited to the following: NOTE -This recommended practice does not specify a delivery format for an architectural description. An AD shall contain the following information pertaining to the AD as a whole: The detailed form and content of the corresponding information items shall be determined by the using organization. These items were selected to allow users to satisfy the requirements of IEEE/EIA Std 12207.0-1996. An AD shall identify the stakeholders considered by the architect in formulating the architectural concept for the system. At a minimum, the concerns identified should include the following: -The purpose or missions of the system -The appropriateness of the system for use in fulfilling its missions -The feasibility of constructing the system -The risks of system development and operation to users, acquirers, and developers of the system -Maintainability, deployability, and evolvability of the system The specific intent of the terms mission , appropriateness , and feasibility will vary from system to system. An AD shall further specify the concerns identified in the context of the system of interest. An AD shall identify the viewpoints selected for use therein. e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization). A viewpoint specification may include additional information on architectural practices associated with using the viewpoint, as follows: -Formal or informal consistency and completeness tests to be applied to the models making up an associated view -Evaluation or analysis techniques to be applied to the models -Heuristics, patterns, or other guidelines to assist in synthesis of an associated view Viewpoint specifications may be incorporated by reference (such as to a suitable recommended practice or previously defined practice). An AD shall include a rationale for the selection of each viewpoint. The rationale shall address the extent to which the stakeholders and concerns required in 5.2 are covered by the viewpoints selected under this clause. NOTE  The recommended practice does not require that any particular viewpoints be selected by an architectural description. However, the rationale for selection of the viewpoints shows that the selected viewpoints cover the minimum set of stakeholders and concerns required in 5.2. Each stakeholder and each concern identified in an AD in accordance with 5.2 shall be addressed by at least one viewpoint selected in accordance with 5.3. A stakeholder or concern may be addressed by more than one viewpoint in an architectural description. 1-It is envisioned that through the selection of suitable viewpoints, an AD can achieve conformance to other development or architecture standards. 2-Annex C and Annex D contain examples of viewpoints and viewpoint specifications. An AD shall contain one or more architectural views. Each view in an AD shall correspond to exactly one viewpoint, as selected in accordance with 5.3. Each view in an AD shall conform to the specification of its corresponding viewpoint. Each view shall include: a) An identifier and other introductory information, as defined by the using organization b) Representation of the system constructed with the languages, methods, and modeling or analytical techniques of the associated viewpoint c) Configuration information, as defined by the using organization An architectural view may consist of one or more architectural models. Copyright © 2000 IEEE. All rights reserved. 11 An AD shall record any known inconsistencies among its architectural views. An AD should contain an analysis of consistency across all of its architectural views. An AD shall include the rationale for the architectural concepts selected. An AD should provide evidence of the consideration of alternative architectural concepts and the rationale for the choices made. When the AD describes a system that pre-exists the development of the AD, the rationale for the legacy system architecture shall be presented, if known. A brief example shows how the normative requirements of Clause 5 interconnect. To claim conformance with this recommended practice, the architect must produce an architectural description meeting the requirements in 5.1 through 5.6. Subclause 5.1 requires that the AD include basic documentary information. By 5.2, the AD must identify architecturally relevant stakeholders and concerns. For example, one stakeholder must be the system builder, and one of that stakeholder's concerns might be the input/output behavior of the system. This recommended practice places only minimal requirements on the concerns selected and thus deemed architectural. The using organization and the architect must make the central choice of what concerns to address. Subclause 5.3 requires that a set of viewpoints be selected, defined, and analyzed for coverage and that the rationale be given for their selection. The architect might therefore select a behavioral viewpoint that would describe the system's input/output behavior. The architect would also be obligated to define what languages or models will be employed to describe system behavior under that viewpoint. No restriction is placed on the language or modeling technique used, but it must be explicitly specified in accordance with 5.3. Subclause 5.4 requires the representation of the resulting architecture through one or more views. The architect will construct a behavioral view of the system, and that behavioral view must conform to the behavioral viewpoint defined previously. Subclause 5.5 requires that any known inconsistencies among or between views (e.g., between the behavioral view provided and a structural view) be listed in the architectural description. Lastly, in accordance with 5.6, the AD must contain a rationale for the architectural decisions and choices made by the architect. NOTES: 1-The materials pertaining to 5.2 and 5.3, the stakeholders, concerns, and viewpoints, should be readily reusable elements for active architecting organizations. It is likely that such organizations will adopt common sets of viewpoints and  Annex B (informative) This recommended practice makes use of three terms, architecture, view, and viewpoint, which reflect community consensus, but are nevertheless employed in ways differing from some current uses. This annex discusses the terms to make clear the fundamental concepts of the recommended practice.
These authors use the heavyweight extension mechanism to incorporate their particular interpretation of the "architectural viewpoint" concept REF to the UML metamodel, and the lightweight extension mechanism to specify connectors, components, architectural patterns, and configurations.
IEEE Recommended Practice for Architectural Description of Software-Intensive Systems