Fundamentals toCreating Architectures

using ISO/IEC/IEEE Standards

What to Architect?How to Architect?

IEEE Goals and Objectives

● Chartered by IEEE Software Engineering Standards Committee to:

● Define direction for incorporating architectural thinking into IEEE standards

● Take a “wide scope” interpretation of architecture as applicable to software-intensive systems

● Establish a conceptual framework and vocabulary for talking about architectural issues of systems

● Identify and promulgate sound architectural practices● Allow for the evolution of those practices as relevant

technologies mature

Motivation – Why Architecture?

● Why do some systems “succeed”? ● Explicitly “ architected ” systems seem to turn out

“faster, better and cheaper”● Architecture is recognized as a critical element in

the successful development and evolution of software-intensive systems

Using the Standard● The Standard is a recommended practice

● One kind of IEEE standard● The Standard applies to Architectural Descriptions

● How to describe an architecture● Not a standard architecture, or architectural process, or

method● The Standard is written in terms of “shall,” “should” and

“may”● ADs may be checked for conformance to the recommended

practice● The Standard does not define any conformance of systems,

projects, organizations, processes, methods, or tools

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.

Purpose of IEEE 1471● According to IEEE 1471 an architecture description can be used

for the following:● Expression of the system and its evolution

● Communication among the system stakeholders

● Evaluation and comparison of architectures in a consistent manner

● Planning, managing, and executing the activities of system development

● Expression of the persistent characteristics and supporting principles of a system to guide acceptable change

● Verification of a system implementation’s compliance with an architectural description

● Recording contributions to the body of knowledge of software-intensive systems architecture

History of the Current StandardAugust 1995 - the IEEE Software Engineering Standards Committee (SESC)

chartered an IEEE Architecture Planning Group (APG) to set direction for incorporating architectural thinking into IEEE standards.

April 1996 - the Architecture Working Group (AWG) was created to implement the recommendations made by APG to the SESC.

The AWG had 25 members.

Drafts of the specification were balloted and commented on by 130 international reviewers.

In September 2000, the IEEE-SA Standards Board approved the specification as IEEE Std 1471-2000.

2006 - ISO/IEC Joint Technical Committee 1 (JTC1), Information technology / Subcommittee SC 7, Software and systems engineering, adopted the specification as ISO/IEC 42010, under a special “fast-track procedure”, in parallel with its approval by national bodies of ISO and IEC.

A coordinated revision of this standard by ISO/IEC JTC1/SC7/WG42 and IEEE CS commenced in 2006, following the successful ISO/IEC fast-track ballot and in line with the IEEE standard 5-year review of the standard.

November 2011 - IEEE 1471-2000 and ISO/IEC 42010:2007 was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

What kind of systems does the Standard cover?

● The focus of the Standard is on three classes of systems:● software-intensive systems are systems in which software

development and/or integration are dominant considerations (i.e., most complex systems these days).

● This includes computer-based systems ranging from individual software applications, information systems, embedded systems, software product lines and product families and systems-of-systems;

● general systems as defined in ISO/IEC 15288, Systems and software engineering — Systems life cycle processes; and

● software products and services as defined in ISO/IEC 12207, Systems and software engineering — Software life cycle processes.

TerminologyAccording to IEEE Standard Glossary of Software Engineering

Terminology, the following definitions are used:● architect: The person, team, or organization responsible for designing systems architecture.

● architectural description (AD): A collection of products to document an architecture. Notation Independent.

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

● designing: The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.

● system: A collection of components organized to accomplish a specific function or set of functions. 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.

● system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.

● view: A representation of a whole system from the perspective of a related set of concerns.

● viewpoint: 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.

Architecture defined by Standard● 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.

The Standard

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

● This metamodel has been widely used and discussed in industry and in the academic literature.

● The conceptual model establishes terms, their definitions and relations which are then used in expressing the requirements.

Architecture Descriptions (ADs)

●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”).

●An architecture description conforms to the Standard if it satisfies those requirements.

●Taken together, the “shalls” imply a process for preparing an AD.

● Templates for ADs and for documenting viewpoints are available.

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:● one or more concerns;

● typical stakeholders (interested in those concerns and therefore a potential audience for views resulting from this viewpoint);

● one or more model kinds;

● 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;

● sources.

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.

● 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).

Model and Meta Model is Important Since the initial publication of the Standard for Architecture Documentation,

it has been built upon a conceptual model, often called a “meta model,” of the terms and concepts pertaining to Architecture Description.

The revised 2011 Standard also established a specific requirement on architecture frameworks claiming conformance to the Standard that referred to the conceptual (or meta) model: An architecture framework shall establish its consistency with the provisions of the

conceptual model.

It is therefore, important to see, how various architecture frameworks (MODAF, DODAF, NAF, TRAK, TOGAF) use meta models.

Jean Bézivin’s “On the Unification Power of Models” offers a useful way of thinking about these matters. The diagram on next slide uses Bézivin’s 3+1 MDA scheme from to “sort out” the

concepts in the Standard.

3+1 MDA scheme

Standard

The left-hand side of the diagram depicts Bézivin’s original scheme.

The right-hand side shows where Standard constructs align with the levels.

Level M0, the green level, depicts the real world of Systems, Architectures, their Stakeholders and Concerns.

Standard

Level M1, the light blue level, is the world of models.

Models represent things in the real world.

Architecture Descriptions are models, consisting of other models: (Architecture) Views and (Architecture) Models, which represent Architectures.

Level M1 is distinct from M0, as in the slogan: The map is not the territory. This distinction is useful to remember when talking to people who confuse Architectures and Architecture Descriptions (or do not use the latter term at all).

Level M2 captures the conventions, or rules, that models on the M1 level conform, or adhere, to.

This is the world of meta models.

In the Standard, (Architecture) Viewpoints and Model Kinds are found at this level. Level M2 is distinct from M1; here the slogan could be: The map is not the legend.

Often, the terms view and viewpoint are used interchangeably, or by folks who do not understand the difference. This explains that difference: viewpoints provide the conventions, the “legends,” for views.

Standard

Standard

Level M3 is the world of meta meta models, where the rules for expressing conventions on models are located.

Note that the Standard spans M2 and M3: it specifies both conventions on Architecture Descriptions, and conventions on specifying Viewpoints and Model Kinds (not shown: architecture frameworks and architecture description languages).

Architecture Frameworks The Standard defines architecture framework and specifies

requirements on architecture frameworks. Architecture Framework:

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

Requirements on Frameworks An architecture framework conforms to the International Standard (IS) when

it specifies: information identifying the framework; one or more concerns; one or more stakeholders having those concerns; one or more architecture viewpoints (and their specifications conforming to the IS); correspondence rules, integrating the viewpoints (as per IS); conditions on applicability (as per IS); consistency of the framework with the provisions of the Standard conceptual model.

A Conceptual Model of Architecture Description

About the Standard 42010

ISO/IEC/IEEE 42010 is based upon a conceptual model – or “meta model” – of the terms and concepts pertaining to Architecture Description.

The conceptual model is presented in the Standard using UML class diagrams to represent classes of entities and their relationships.

Context

In original edition of the Standard, systems were said to have missions; in revision, Purpose was chosen as a more general replacement to this term. Premise of Standard is, for a system of interest to you, the Standard provides guidance for documenting an architecture for that system.

Systems exist.A System is situated in its Environment.That environment could include other Systems.

Stakeholders have interestsin a System; those interestsare called Concerns. A system’sPurpose is one very common Concern.

Systems have Architectures. An Architecture Description is

used to express an Architectureof a System.

Every System inhabits its Environment.A System acts upon that Environment and vice versa. A system’s Environment determines the range ofinfluences upon the system.

The Standard takes no position on Q. What is a system?In the Standard, the term system is used as a placeholder –e.g., it could refer to an enterprise, a system of systems, a product line, a service, a subsystem, or software. Systems can be man-made or natural. Nothing in the Standard depends upon a particular definition of system.Users of the Standard are free to employ whatever systemtheory they choose.

In the Standard, architecture of a system is defined as: “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”.

Architects and other system stakeholders use ADs to understand, analyze and compare Architectures, and often as “blueprints” for planning and construction.

The definition was chosen (1) to accommodate broad range of things listed above under System: the architecture of X is what is fundamental to X (whether X is an enterprise, system, system of systems, or some other entity); and (2) to emphasize that a system can have an architecture even if that architecture is not written down.

In the Standard, Environment is intended in thewidest possible sense to include developmental,operational, technical, political, regulatory, and allother influences which can affect the architecture.These influences are categorized as Concerns.

Architecture Description An Architecture Description (AD) is an artifact that expresses an Architecture.

Typical StakeholdersClient

AcquirerOwnerUser

OperatorArchitect

System EngineerDeveloperDesignerBuilder

MaintainerService Provider

VendorSubcontractor

Planner

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.

Core of Architecture Description

An Architecture Description is a work product used to express the Architecture of some System Of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System Of Interest. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard).

Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect.

A Concern is any interest in the system. The term derives from the phrase “separation of concerns” as originally coined by Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.

An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information.

An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models.

Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view.A Model Kind defines the

conventions for one type of Architecture Model.

Standard is organized around terms & concepts of the diagram above. It depicts the contents of an AD and the relations between those

content items when applying the Standard to produce an AD to express an Architecture for some System of Interest.

AD Elements and Correspondences

Architecture Descriptions are comprised of AD Elements.

Correspondences capture relationships within or between AD Elements.

Correspondences and Correspondence Rules are used to express and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation within or between ADs.

Correspondences can be governed by Correspondence Rules.

Any item in an AD is considered an element.

Every Stakeholder, Concern, Viewpoint, View, Model Kind in an AD is an AD Element.

When a Viewpoint or Model Kind introduces constructs, these too are considered AD Elements.

Architecture Decisions and Rationale

An Architecture Decision affects AD Elements and pertains to one or more Concerns. By making a Decision, new Concerns may be raised.

Architecture Rationale records the explanation, justification or reasoning about Architecture Decisions that have been made and architectural alternatives not chosen.

Creating an Architecture involves making Architecture Decisions.ISO/IEC/IEEE 42010 specifies requirements for capturing key decisions within an AD in terms of the concepts shown in the above diagram.

Architecture Frameworks and Architecture Description Languages

Architecture frameworks and ADLs are two mechanisms widely used in architecting.

Diagram depicting contents of an Architecture Framework

An architecture framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain of application or stakeholder community.

Examples of Architecture Frameworks: MODAF, TOGAF, Kruchten’s 4+1 View Model, RM-ODP, Zackman.

An ADL is any form of expression for use in ADs.An ADL might include a single Model Kind, a single viewpoint or multiple viewpoints.

Examples of ADLs: Rapide, SysML, ArchiMate, ACME, xADL.

Elements of ADL

Some Important Questions

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.

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.