presentations from 2009 dinner meeting

8/9/2019 Presentations from 2009 Dinner Meeting

1/22

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training

Introducing ISO/IEC 42010:

Architecture Description

David Emery

DSCI

Copyright 2009, David Emery & D&S Consultants, IncAll rights reserved. Permission granted to INCOSE WMA members

for personal use only, providing the presentation is used intact andthis statement is included


2/22

Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training

-2Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info

Agenda

Where did this standard come from?What is in the Standard?

-Current IEEE 1471-2000 / ISO/IEC 42010:2007-Proposed additions IEEE/ISO/IEC 42010:201x

How can it be applied (to the DoDAF)?

How to participateSummary


3/22



History:Where did this standard come from?

1990-1995: multiple books/papers on software architecture (e.g. Perry & Wolf, Kruchten,Shaw), system architecture (e.g. Rechtin & Maier), enterprise architecture (e.g.Zachman)

1995: Formation of IEEE Architecture Working Group to update the IEEE standarddefinition of architecture

1996-1998: Authoring the IEEE 1471 standard 1998-1999: Balloting same 2000: Publication as IEEE Std 1471-2000 2001: Adoption as ANSI standard 2005: ISO SC7 Architecture Working Group formed 2006: ISO agreement to fast-track IEEE 1471 with immediate coordinated update

Scope to align with SC7 ISO/IEC 15288 as well as ISO/IEC 12207, software andsystems

Alignment as part of overall SC7 set of standards and related ISO work (e.g. TC184work on Enterprise Architecture)

2007: Publication of ISO/IEC 42010:2007 (cover page on IEEE 1471-2000) 2007-2009: Draft revision of ISO/IEC 42010/IEEE 1471 2009-2010(?): Balloting same 2010 or 2011(?): Publication of revised ISO/IEC 42010/IEEE 42010


4/22



Whats in the 2000/2007 Standard?

Definitions (1 page)Metamodel/ontology for architecture descriptions

(ADs) (4 pages)

23 Normative requirements for ADs (4 pages)Annexes (including relationship/mapping to RM

ODP) (10 pages)


5/22



Motivation: Why a standard forArchitecture Description?

Architecture is an abstract property of systems/software (I cant define it,but I know it when I see it)

Architecture works best when its written down, so we can review it, analyzeit, and build to it

Most of the papers talk to how to describe an architecture (e.g. Kruchtens4+1 views)

Thus a standard that gathers current practice on descriptions would haveboth a sound basis in practice and provide a concrete description of theconcrete artifact of an architecture

The standard for architecture description should not restrict the process/methodology or intellectual practice of architecting

- Provide constraints on describing the architecture, not on the architecture itself- Akin to standards for house blueprints as opposed to building codes

Focus on ontology for elements of architecture description (means tocompare description approaches, as well as compare descriptions) Minimal set of conformance requirements, provide flexibility for extensions

and adaptations


6/22



The Metamodel


7/22



Definitions*

Architecture: fundamental conception of a system in its environment embodied inelements, their relationships to each other and to the environment, and principles guidingsystem design and evolution

Architecture description: collection of work products used to describe anarchitecture

Stakeholder: individual, team, organization, or classes thereof, having concerns withrespect to a system

Concern: area of interest in a system pertaining to developmental, technological,business, operational, organizational, political, regulatory, social, or other influencesimportant to one or more of its stakeholders

Viewpoint: work product establishing the conventions for the construction, interpretationand use of architecture views and associated architecture models

View: work product representing a system from the perspective of architecture-relatedconcerns

Model: work product from which architecture views are composed* Text from the draft revised standard


8/22



4 Big Ideas from the Standard

0. Architecture /= Architecture Description

1. Architectures exist for systems (including software-only systems) to

satisfy known concerns from stakeholders

- This ensures the architecture, and its description, are relevant-

Stakeholder concerns, often non-functional, drive the architecture2. Architecture Descriptions are inherently multi-view

- No single view addresses all concerns- A view should cover the entire system (with respect to the concerns of interest)

3. Viewpoints (what to describe) are separate from Views (this

description)

- Represents current practices with viewpoint sets such as Kruchtens 4+1- Ensures consistency and repeatability, particularly when evaluating alternative

architectures


9/22



0. Architecture is distinct fromDescription of Architecture

The concept of architecture is a holistic notion, i.e. thetotality of the building

- That totality is not wholly captured in any individual blueprint, drawing, ormodel

- Architecture Descriptions are not uniquely defined by an Architecture. Multiplesets of (equally valid) renderings can exist for a given building/system.

- The drawings or models allow to reason about particular concerns about thebuilding or system

Center photo is of a model of Sagrada Familia, inverted with weights suspended

across the structure, used to make sure gravity loads were uniformly spread


10/22



Architectures are effective when they answer relevant concerns- Difficult to answer the question if you dont know either the question or questioner- Concerns range from how the system works to can we build this architecture within

cost and schedule

Formally documenting stakeholders and concerns provides a strong basisfor ensuring the architecture description is scoped correctly- Gathering stakeholders and concerns is an implied process step by the standard- Reviewing stakeholder/concerns list with the stakeholders early prevents unpleasant

surprises later

The standard requires that architecture stakeholders and theirarchitecture-related concerns be identified- But it doesnt tell you how to determine the architecture stakeholders and architecture-

related concerns

- This can be used as a scoping mechanism for the architecture effort

1. Stakeholder Concerns should driveArchitectures and Their Descriptions


11/22



2. Multiple Views Each covers theSystem for (relevant/allocated) Concerns

Architecture Descriptions are inherently multi-View- No single View addresses all concerns- This was somewhat controversial in the 90s but is generally

accepted now

A View should cover the entire system (with respect to theConcerns of interest for that view)- Thus a View has a specific set of Concerns (e.g. performance,

security, functionality)

- The View can be composed of multiple models, which together coverthe system

E.g. a network queuing Model and a CPU processing model togethercould address end-to-end performance concerns

The View aggregates Models/Model contents sufficient to to ensurecompleteness


12/22



3. Viewpoints distinct from Views

Viewpoints (what to describe) are separate from Views (this description)- View is to Viewpoint as Map is to Legend- Viewpoint defines how to construct the view, e.g. modeling language(s),

contents, relationship with other viewpoints, etc.

- Views contain the content specific to This Architecture (Description) of thisparticular system

- Viewpoints ensure stakeholder concerns are identified and allocated/covered Viewpoints enable better architectural practices

- Represents current practices with viewpoint sets such as Kruchtens 4+1- Explicitly capturing Viewpoints as part of an AD ensures consistency and

repeatability, particularly when evaluating alternative architectures

- Supports development of architecture tool, techniques and methods- Akin to declaration before use ideas in software

The standard requires a 1-1 relationship between Viewpoint and View ina given AD (consequence of entire system requirement on views)


13/22



Proposed Additions to the Standard:Correspondences and Architecture Frameworks


14/22



New Definitions

Model Correspondence Rule: constraint on two ormore architecture models enforced on a model

correspondence

Model Correspondence: relation on two or morearchitecture modelsArchitecture Framework: conventions and common

practices for architecture description established

within a specific domain or stakeholder community


15/22



Model Correspondences

Model Correspondences and Model Correspondence Rules filla hole in the current standard- Current standard provides no requirement or guidance on cross-view

consistency (other than inconsistencies should be documented)

- Many existing approaches provide such rules (e.g. RM-ODP)

Model Correspondences relate elements of an AD (Models)to each other- Model Correspondence Rules tell you what correspondences should exist in an

AD Example: Every software element in a Logical View should be allocated to at least

one processing node in the Deployment View

- Model Correspondences represent the connections within this architecture Example: A table showing CSCIs allocated to computers

Model Correspondences can exist in an AD without anassociated Correspondence Rule- Allows connections specific to the Architecture being described to be captured


16/22



Architecture Frameworks

There are a lot of Architecture FrameworksE.g. DODAF, MODAF, TOGAF, RM-ODP, GERAM, 4+1, Zachman

each provide a set of reusable viewpointsClearly there is existing practice that could be codified

Architecture Frameworks can be described in terms of thestandards Metamodel/ontology (with the addition of ModelCorrespondence Rules)

Key contribution/addition: An Architecture Frameworkshould explicitly identify the stakeholders & concerns thatmotivate the Frameworks choice of Viewpoints

Revision adds new conformance pointsArchitecture Description to Architecture FrameworkArchitecture Framework to standard


17/22



How can the ISO Standard beapplied to the DODAF?

Application to DODAF document itself, i.e. making theDODAF a conforming Architecture Framework

- Facilitate the description of the DODAF itself (e.g. byreusing standardized definitions)

-Support comparisons and integration with otherArchitecture Frameworks

Application to the construction of ArchitectureDescriptions governed by DODAF (and possibly otherArchitecture Frameworks)

- Common practice seems to be Do DODAF and do 4+1for software


18/22



DoD should make the DODAFa conforming framework

Changes in terminologyDODAF 1.5 has 3 viewpoints (Operational, System, Technical) and

~25 Models (depends on how you count the productsSome products (e.g. SV-5 Operational Activity to System Function

matrix) are really Model Correspondence RulesAdd a metamodel/ontology that builds on the Standards model to

show relationship of concepts within the DODAF

Explicit identification of Stakeholders and Concerns Why am I doing this product? Who is going to use it, and for what purposes?

Ensure conformance with DODAF leads to (or at leastdoes not contradict) conformance to the Standard

DODAF 2.0 talks about IEEE Std 1471, but not in anyconsistent (or conforming) way


19/22



Applying DODAF + ISO/IEC 42010to produce an Architecture Description

Reconcile differences in terminology, e.g. view vsviewpointClearly distinguish between the concepts in the DODAF from the

concepts in the AD for the specific system

Explicitly identify stakeholders & concerns for eachDODAF view (Viewpoint) and productE.g. through an SEI Quality Attribute WorkshopMake sure each product has a very clearly defined customer and the

right- information and the right- level of detail Include provisions for rationale capture, evaluation/review

Define the full set of Viewpoints and Models and makesure they are appropriately connected E.g. DODAF SV-4 System Functions are mapped to elements in the 4+1

Logical View(point)


20/22



Another application: Product Lines

Product Lines can/should share a common Architecture Framework Each product within the Product Line should be a separate (ISO 42010

conforming) Architecture Description

The Architecture Framework can define Models that are shared amongall product line instances

The conformance points in the standard are defined in terms of a singlesystem in a point in time when conformance is claimed

- Consider the architecture of each vehicle (built on a common chassis):


21/22



How to Participate

IEEE Balloting Group for P42010 closed in March, ballotingon first IEEE draft just completed- 87% response rate, 87% of those approved

US participates in ISO/IEC JTC1/SC7 through the USTechnical Activities Group (SC7 US TAG)- TAG membership is by organization/company- TAGs Technical WG 42 recommends US position to US TAG

Current plan:- Resolve ballot comments (IEEE & ISO) by early June, submit next draft for

Final Committee Draft status optimistic but achievable!

- Next ballot over the summer, hope for SC7 approval of the DIS in Nov 2009-

Final ballot should lead to ISO standardization in 2010 under this schedulehttp://www.iso-architecture.org/ieee-1471


22/22



Summary

ISO/IEC 42010:2007 (nee IEEE Std 1471-2000) is a standardfor describing architectures- Does not prescribe how to do architecture- Does not prescribe any particular set of representations/renderings- Provides a metamodel/ontology for elements of an Architecture Description

Emphasizes Architectures should address (known)stakeholders & their concerns

Provides for multiple views as (usually) necessary torepresent an architecture (covering the entire system fromset of stakeholder concerns)- Views are composed of models, and models/model components can be

shared across views

Separates the Viewpoint (what to describe) from the View(description for this architecture)Proposed revision introduces a means to connect modelcomponents in views with each other

Proposed revision provides a standard definition forArchitecture Framework

presentations from 2009 dinner meeting

Documents