1
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
The Architect’s Job
6 June 1997
Rich Hilliard
(v 2.0)
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
I&A
Security Procedures Network Security
LAN
Data
Stores
Secure
RPC
Operational Security
LeastPrivilege
Apps
EncryptionFortezza
RoutersSwitch
Hubs
Example: Security View
21
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
If Architecture were Software ...Architectural Maturity Model
• 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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
If Architecture were Software ...Architectural Maturity Model
• 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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
DII-AF Chief ArchitectsDII-AF Chief Architects’’ Office Office
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
- 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.