The architect's job: 1996 version

1

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office

The Architect’s Job

6 June 1997

Rich Hilliard

(v 2.0)

Rh

current email: [email protected]

Rh

2

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeAcknowledgements

• This briefing has been evolving since 1995. The original version

was called “Dick & Jane” and was created by Jeff Hustad, David

Emery for Army SBIS. Tim Rice and Kevin Heideman contributed

to “DISA Dick & Jane” in 1996 which added the results on the

SBIS Architecture. Subsequent versions added details on

MITRE’s work on Architecture Quality Assessment, and the

Architecture Description Framework.

• The latest versions start to define the major activities that the

Architect engages in and the activities needed to support that.

• Jim Moore, Eric Skoog, Jerry Friedman, David Emery all offered

comments on this version.

3

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeOutline

• What is architecture?

• Why have architects?

• What does the architect do?

• What does the architect need to do his job?

• MITRE’s work in architecture

4

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeWhy Architecture?

• Explicitly “architected” systems seem to turn out faster, better

and cheaper

• Separation of concerns:

- Essential system characteristics

- Multiple system stakeholders

- Separate long-term goals, and evolution from immediate

construction concerns

- Current systems are “contractor-architected”

! Not incentivized for the long-term

! Limited client (buyer) flexibility

! Narrows marketplace for mission functionality

• “Architecture” as response to failure of the waterfall to address

non-user, non-functional requirements of other stakeholders

5

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeWhat is “Architecture”?

• An architecture is the highest-level concept of a system in its

environment

- IEEE Architecture Working Group

• An architectural description is a model of the structure and

behavior of the whole system

- It shows how the system fulfills the needs in the context of its

environment

- It identifies major system components, their interconnections

and dependencies, and the limits within which they must

operate

6

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeThe Architect’s Domain (I): Roles

Users

Operators

Installers

Architect

ChiefEngineer

Developers

Testers

Maintainers

Client

ProgramManager

reporting-to andinfluences relations

7

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeThe Architect’s Domain (II): Products

EmergingOpen Stds

Vision

LegacySystems

TechnologyTrends

GoalsArchitecture . . . n

Design

Policies

3

Design2

Design1

Design

Life cycle Phases

Requirements & Concepts

Architecture

DetailedRequirements

Design & Implementation • • •

OperationalRequirements

SystemRequirements

AvailableFunding

Needs

8

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeCharacteristics of Architect’s Job

The ideal architect should be a man of letters, a skillful draftsman, a

mathematician, familiar with historical studies, a diligent student of

philosophy, aquainted with music, not ignorant of medicine, learned in

the responses of jurisconsults, familiar with astronomy and astronomical

calculations.

— Vitruvius, De Architectura (25 BC)

• Client-centered

- Architect works for the client

• Systems orientation: bridging problem definition and solution

conceptualization

- Architect’s job is to understand client’s needs to produce one

or more models (potential solutions)

9

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeCharacteristics of Architect’s Job (continued)

• Model-based

- Architect then works with engineer

- Engineer’s job is to design and implement architect’s model

• Certification of construction

- Architect oversees construction, ensuring actual

implementation meets design

• Determines acceptance of built system

10

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeCharacteristics of Architect’s Job (concluded)

• Multidisciplinary Synthesis: technical, programmatic, managerial

- Artistic, Heuristic

No person who is not a great sculptor or painter can be an architect. If

he is not a sculptor or painter, he can only be a builder.

— John Ruskin, Lectures on Architecture and Painting (1853)

11


Activities and Definitions:Architect a System (context)

Architect

a

System*

A0

client and other system

stakeholder priorities

known

requirements

architectural specifications

building permits and certificates

architectural standards

* Where “system” ranges over: individual applications, usual programs,product families, product lines, systems of systems or the whole enterprise.

12


Activities and Definitions:Architect a System

Understand

Needs and

Environment

A1

Devise

Architectural

Concepts

A2

Produce

Engineering

Views

A3

Oversee

Construction

A4

needs, goals

and vision

C1

I1

O1

O2

O3

client and stakeholder priorities formal

reqts

community standards:

JTA, DII COE, etc.

architectural

rules

appropriate

technologiesarchitectural specifications

design artifacts

and built systemapprovals

to proceed,

system

acceptance

13

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeArchitectural Description

• An architecture is documented as a model

• A model is comprised of one or more views

- A view represents the whole system to focus on one or more

critical concerns

- Support multiple audiences each with their own concerns

- Reduce perceived complexity through separation of concerns

14


Activities and Definitions:Produce Engineering Views

C1

O1

I1

C2

Define

Views

1

Analyze

Each

View

2

Check

View

Consistency

3

Verify

Satisfaction

of Needs &

Constraints4

predefined

views

critical stakeholder

concerns, programmatic

and technical issues

architectural concepts

architectural

rules

architectural

standards and

constraints

documented engineering views

inter-view links

needs, goals

vision traceability

matrix

inconsistencies

open issues

15

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeSome Typical Views

• functional, activity views [ICAM, Sowa]

• data, data flow, information views [Druffel94, Gacek95]

• static views [Kruchten95, Gacek95]

• logical views [Kruchten95, Moriconi]

• behavioral, dynamic, “operational” views [Luckham95a,

Kruchten95, TAFIM]

• development, maintenance views [Boehm, MITRE96]

• distributed, network views [Sowa, MITRE95]

• physical views [Kruchten95, TAFIM]

16

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficePrinciples of Views

• Each view presents the whole system from a chosen viewpoint

- Complete relative to that viewpoint

- Consistent with respect to other views

• Each view is modeled in terms of components, connections and

constraints (governed by a “meta model”)

• Views are linked to increase understanding, consistency and

completeness

17

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeExample: Application View

SQL, Physical Data Model, RDA

API, Style Guide

API, Logical Data Model

Motif or MS Windows

Data Storage

Presentation

Data Access

Application

User Interface Prepares Information

Presents Information

Transforms Information

Stores/Retrieves Information

Maintains Information

XVT

Ada

Ada, XDR, IDL

RDBMS, File System, OLTP

Component Function

legend

Component ConnectionConnectionTechnology

18

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeExample: Data View

LogicalData Models

Common ReferenceData Model

UnifiedData Model

ApplicationData Models

COTS/GOTSData Models

LegacyDataModels

DOD EnterpriseData Model

IntegratedDatabase

Legacy

SQL

Data Stores

IRDSDOD DataDictionary

<- ERA Diagrams (IDEF1X format) ->ERA Diagrams(IDEF1X format)

ICD Interface

Repository

19

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeExample: Distribution View

ServerDatabase

. . .

In Garrison

. . . Deployed

Remote

. . .

Force XXI

Split Base

Intelligent PCs

• Application distribution via Remote Procedure Call

•Data distribution via OLTP accessing split data

ServerDatabase

20


I&A

Security Procedures Network Security

LAN

Data

Stores

Secure

RPC

Operational Security

LeastPrivilege

Apps

EncryptionFortezza

RoutersSwitch

Hubs

Example: Security View

21


softwarerequirements

Example: Developer-Maintainer View (partial)

system requirementscapture and edit

system componentID and allocation

software requirementsdefinition

software top-leveldesign

legacy systemconsiderations

fromDistributed

View

legacy softwareand DBMS

componentsconsiderations

fromDataView

system performancemodeling

software performancemodeling

system requirements

sourcedocuments

systemthreadssystem requirements

traces torequirements

legacy systems

HW, SWcomponents threads

behaviors

softwarethreads

softwarecomponents

systemrequirements software

threadslegacy S/W

SWcomponents

threads

behaviorsto Detailed Design to Testing

22

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeSupporting Activities (Mechanisms)

• Operational modeling

• Doctrine and strategic studies

• Financial planning and analysis, ROI

• Requirements analysis

• Simulation

• Ergonomics, time-motion studies

• Prototyping

• Enabling technology studies: e.g., messaging, image processing,

information retrieval, multimedia

• Formal Specification

• Design and implementation techniques and methods

23

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeSupporting Activities (Mechanisms)

• Collaboration

• Self-criticism and architectural assessment

• Project development and management

• Planning and scheduling

• “Process”

• Contracting

• Design reviews, inspections and audits

• Compliance, conformance testing and analysis

• Quality assurance

24

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeOrganizing Architects

Where do architects and designers get their ideas? The answer,

of course, is mainly from other architects and designers, so is it

mere casuistry to distinguish between tradition and plagiarism?

— Stephen Bayley, Commerce and Culture (1989)

• Participative/collaborative: the critique is an essential ingredient

in “real” firms

• The architecture firm

• Methods: heuristic, patterns, reuse of solutions, experience base

• Tools: Creating, Assessment, Delivery, Certification

• Not a consulting firm

25

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeCommunity Support

• What help can we get from outside organizations?

- DII-AF

- DII COE

- Product Lines

• Architectural Standards

- DISA, CISA, JTA, ISO, IEEE

- Standards are a support and also a constraint

26


If Architecture were Software ...Architectural Maturity Model

• Level 0: Briefware (Total Chaos)

- “adjective architecture”

- cartoons and clip art

• Level 1: Developer-centric (Initial)

- Yesterday’s CASE techniques (IDEF, RDD-100, Teamwork)

now with “architecture”in the model names

- Ad hoc coordination between programs

- Overemphasis on structural aspects:

! CSCIs, modules, classes, ...

! e.g., Garlan and Shaw on software architecture

27



• Level 2: Master Builder (Repeatable)

- Distinct Architect / Developer roles

- Recognition of multiple stakeholders of a system

! and techniques for addressing their diverse needs

• Level 3: Self-Awareness (Defined)

- Recognition of architectural discipline

! Distinct from systems and software engineering

! Means to create and contract for architectural

specifications

- e.g., Rechtin and Maier

28



• Level 4: Architect Firms (Managed)

- Architects organized to support their discipline

- Tools to support that discipline

- Independent analysis of delivered architectural specifications

• Level 5: “Pre-fab” construction (Optimizing)

- Architectures as real engineering objects

- True separation of architectural specification from system

implementation

- Architectural evolution to support technology insertion

29


The Architectural Metaphor:Implications for Systems Engineering

• Systems are situated in their environments

• Inherently “multi-viewpointed”

- no essential or ‘correct’ single view

• The architect is one actor mediating among

- client, users and other stakeholders

- developers, vendors, maintainers

• What’s important are the descriptions

• Descriptions can be unified with appropriate meta model

- One set of “rendering primitives” with open semantics

dependent on the view

30

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeOur Work

• Technical foundations of software systems architecture

- DARPA Domain-Specific Software Architecture C2 Reference

Model (1990)

• Practical Architecture Method

- WCCS Force-level study (1992)

- Sustaining Base Information Services (1994)

- Army Reserve Component Automation System (1995)

- Missile Warning Laptop (1996)

- Theater Battle Management Core Systems (ongoing)

• Architecture Quality Assessment (AQA) (1996 - )

• Architecture Description Framework (1997- )

• Standardization: IEEE Architecture Working Group (1995 - )

31


Architecture Quality Assessment:Goals

• Repeatable method yielding objective results

- Evaluation based on documentation, not “hearsay”

• Based on “open sources”

- Architects will know the criteria on which architectures will be

judged

- Availability of the criteria may improve overall quality

• Independent from life cycle, documentation, methodology

- Cannot assume traditional deliverables and milestones

- No widely accepted architectural methods

- Don’t assume a Contractor is the Architect

32


Architecture Quality Assessment:Uses of an AQA

• Evaluate a candidate (proposed) architecture

• Review technical progress during ongoing architecture

development

• Assess a complete, delivered architecture prior to

acceptance/implementation

• Compare two or more architectures in a consistent fashion

33

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeStatus: Architecture Quality Assessment (AQA)

• Several “partial” uses

- FAA STARS acquisition

- National Missile Defense

- C2IPS

• Transition to TBMCS

• Identified by C2 Chief Architects Council for use in Architect’s

Toolkit

• Paper in MITRE’s Software Engineering & Economics Conference

(April 1997)

34

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeArchitecture Description Framework (ADF)

• Premise: To move “architecture” from buzzword to engineering

practice, we need techniques for architectural description

• Develop automation base for representing, manipulating, and

analyzing architectural models

- Allow information sharing between tools

- Provide a semantically rich delivery format (e.g., between

Contractors and Government)

• Demonstrate industrial-strength basis for architectural

description

• Status: Phase 1 (6 months) funded as MSR

35

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeThe Challenge

• Despite current interest in “architecture”

- No solid foundations for architectural description and

specification

• Our Contractors use off-the-shelf tools to produce “architectural”

deliverables

- IDEF, RDD-100, UML, OMT, ...

• Meanwhile, research community is developing next-generation

“architecture description languages”

- Rapide, Wright, Dicam, UniCon, ArTek, ACME, FR, MetaH,

Gestalt, Resolve, ...

36

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeADF Concept of Operations

Object Request Broker

Architecture Description FrameworkDoors

ADF Services• Core Semantics• Working Info• Traceability• Analysis• Presentation/Layout• Import/Export Adapters

RDD-100

IDEF0,1

HTML,VRML

Catalyst

Rapide Excel Browser ManSART AQAtool IMPS

37

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeADF Schedule

6 (months) 12

Phase 1:

• Design ADF• Small Experiments

Phase 2:

• TBMCS trial use• IDL Implementation• Host to Catalyst

Phase 3:

• Integrate with Architecture Quality Assessment• Provide to IEEE

18

38

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office“Community Outreach”

• IEEE Architecture Working Group

- “Design phase” leading to

! Recommended Practice for Architectural Description

• [email protected]

- Internet discussion list for architecture issues

39

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeReferences

• R. Hilliard, Representing Software Systems Architectures or,

Components, Connections, and (why not?), first-class Constraints and

Views. Proceedings of the SIGSOFT’96 2nd International Workshop on

the Architecture of Software Systems, October 15-16, 1996, San

Francisco.

• D. Emery, R. Hilliard, T. Rice, Experiences Applying a Practical

Architectural Method. In Reliable Software Technologies - Ada Europe

’96, Alfred Strohmeier (editor), Springer-Verlag, Lecture Notes in

Computer Science, volume 1088.

• R. Hilliard, Architectural View Selection, ESC Second Architecture

Technical Interchange Meeting, Gunter AFB, 5 December 1995.

• S. Schwarm, T. Rice, R. Hilliard, The Architectural Metaphor as a

Foundation for Systems Engineering. Proceedings INCOSE ’96

Symposium.

• D. Emery and R. Hilliard, “Architecture,” methods and open issues.

Proceedings First International Workshop on Software Architectures,

Seattle, WA, April 24-25 1995.

40

DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office OfficeReferences (Concluded)

• R. Hilliard, On The Notion of ‘Architecture’ in Model-Based Software Engineering.

Proceedings DARPA Workshop on Domain-Specific Software Architectures,

Hidden Valley, PA, 1990.

• W. Ellis, R. Hilliard, P. Poon, D. Rayford, T. Saunders, B. Sherlund and R. Wade,

Toward a Recommended Practice for Architectural Description. Proceedings of

2nd IEEE International Conference on Engineering of Complex Computer

Systems, Montreal, 1996.

The architect's job: 1996 version

Technology

Transcript of The architect's job: 1996 version