The architect's job: 1996 version

1

DII-AF Chief Architects’ Office

The Architect’s Job
6 June 1997
Rich Hilliard
(v 2.0)

current email: r.hilliard@computer.org

2

Acknowledgements
• 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

Outline
• 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

Why 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

What 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

The Architect’s Domain (I): Roles

Users Testers
Client

Program
Architect Manager Maintainers

Chief Developers
Operators Engineer
Installers

reporting-to and
influences relations

7

The Architect’s Domain (II): Products
Policies Available
Vision Funding

Technology
Trends
Architecture ...n

Goals Design
3
Legacy Design
2

Systems Design1

Needs
Design
Emerging Detailed
Open Stds System Requirements
Requirements
Operational
Requirements

Life cycle Phases
Requirements & Concepts
Architecture
Design & Implementation • • •

8

Characteristics 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

Characteristics 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

Characteristics 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)

client and other system
stakeholder priorities

architectural standards
known
requirements Architect
architectural specifications
a
System*
building permits and certificates

A0

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

12

Architect a System
I1 C1
formal client and stakeholder priorities
reqts

Understand needs, goals community standards:
Needs and and vision JTA, DII COE, etc.
Environment
A1

architectural
Devise rules O1
Architectural
Concepts

A2

appropriate
Produce architectural specifications
technologies O2
Engineering
Views

A3

Oversee
Construction
O3

design artifacts A4 approvals
and built system to proceed,
system
acceptance

13

Architectural 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

Produce Engineering Views
C1 C2

critical stakeholder architectural
architectural
concerns, programmatic standards and
rules
and technical issues constraints
predefined
views Define
Views

1

Analyze
architectural concepts documented engineering views
Each
I1 View O1

2

inconsistencies

Check
View inter-view links
Consistency
3

open issues

Verify
Satisfaction
of Needs &
Constraints needs, goals
4 vision traceability
matrix

15

Some 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

Principles 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

Example: Application View

Presentation Presents Information

Motif or MS Windows XVT

User Interface Prepares Information

API, Style Guide Ada

Application Transforms Information

API, Logical Data Model Ada, XDR, IDL

Data Access Stores/Retrieves Information

SQL, Physical Data Model, RDA RDBMS, File System, OLTP

Data Storage Maintains Information

legend
Connection
Component Connection Component Function
Technology

18

Example: Data View

DOD Data
IRDS
DOD Enterprise Dictionary Unified Repository
Data Model Data Model

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

Logical Legacy
Common Application COTS/GOTS
Data Models Data
Reference Data Models Data Models
Models
Data Model

SQL
ICD Interface

Data Stores Integrated
Database
Legacy

19

Example: Distribution View

Force XXI In Garrison
Server
Database

...
...
Intelligent PCs
• Application distribution via Remote
Remote Procedure Call

•Data distribution via OLTP
accessing split data
Database
Server

... Deployed Split Base

20

Example: Security View
Operational Security
Security Procedures Network Security

I&A
Encryption
Fortezza

Least Switch Routers
Privilege
LAN
Apps
Hubs

Secure
RPC
Data
Stores

21

Example: Developer-Maintainer View (partial)
from
system requirements Distributed
source View
documents
system requirements legacy system
capture and edit considerations
system
system requirements threads legacy systems
from
traces to Data
system component View
requirements ID and allocation software
HW, SW threads legacy software
software and DBMS
components threads
components components
behaviors
system software requirements considerations
system performance requirements definition software legacy S/W
modeling software threads
SW requirements
components
software top-level
software performance threads design
modeling behaviors
to Detailed Design to Testing

22

Supporting 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

Supporting 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

Organizing 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

Community 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

Our 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

Status: 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

Architecture 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

The 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

ADF Concept of Operations

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

Rapide Excel Browser ManSART AQAtool IMPS

RDD-100 Doors
Architecture Description Framework
HTML,
IDEF0,1 VRML
Catalyst

Object Request Broker

37

ADF Schedule

Phase 1: Phase 2: Phase 3:

• Design ADF • TBMCS trial use • Integrate with
• Small Experiments • IDL Implementation Architecture
• Host to Catalyst Quality
Assessment
• Provide to IEEE

6 (months) 12 18

38

“Community Outreach”
• IEEE Architecture Working Group
- “Design phase” leading to
! Recommended Practice for Architectural Description
• soft-sys-arch@spectre.mitre.org
- Internet discussion list for architecture issues

39

References
• 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

References (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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (13)

En vedette

En vedette (20)

Similaire à The architect's job: 1996 version

Similaire à The architect's job: 1996 version (20)

Plus de Rich Hilliard

Plus de Rich Hilliard (10)

Dernier

Dernier (20)

The architect's job: 1996 version