Upload
brad-mercer
View
114
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Between 2006 and 2009 I developed and presented a number of versions of this presentation. It was intended as an exercise to develop my thinking about the practice of architecting. And, my thinking certainly did evolve during that period. This version is the last developed. Yet, my thinking on the subject has not remained static in the intervening 4+ years. Unfortunately I have encountered many differing versions of this presentation across the web. As a result, I thought it necessary to post this last version in hopes of normalizing the use of this presentation by others. I am flattered that so many have found this presentation useful. I urge all who appreciate this work to extend and modify the thinking in your own form in hopes of improving the state of architecting practice. My only request is that you comply with the requirement of the associated creative commons license.
Citation preview
Thoughts on Architecting. . . And How to Improve the Practice
Thoughts on Architecting. . . And How to Improve the Practice
Brad MercerChief Architect/Department Head
Naval C3 Systems DepartmentThe MITRE Corporation
San Diego, California
Version 4.3May 1, 2009
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 2Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Today’s Speaker
Brad Mercer is Chief Architect, Naval C4I Systems, with the MITRE Corporation in San Diego, California. The MITRE Corporation is a Federally Funded Research and Development Corporation (FFRDC). In this capacity Mr. Mercer serves as primary or consulting architect on multiple U.S. Navy system developments and net-centricity initiatives.
Mr. Mercer has served in a variety of roles assisting Navy programs and initiatives, including Chief Architect of the National Maritime Domain Awareness (MDA) Initiative; Chief Architect of the Consolidated Afloat Networks and Enterprise Services (CANES) Program; Chair of the DoD Multiservice SOA Consortium’s (MSC) Architecture Working Group; DON CIO Technical Director for SOA Transformation; and architecture advisor to the Office of the Chief Engineer of the U.S. Navy’s Space and Naval Warfare Systems Command (SPAWAR) in San Diego. Mr. Mercer has assisted with both FORCEnet architecture development and the development of SOA concepts for SPAWAR and it’s associated PEOs.
5/1/2009 - 3Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Overview
► Complexity is the Enemy!!
► Architecture Theory: A Quick Course
► Architecting and Engineering: Two Sides of the Same Problem
► From Capabilities to Systems: The Role of the Architect in DoD
► Architecture-Driven Systems Development: The Role of Architecture Throughout Systems Development
5/1/2009 - 4Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Complexity is the Enemy!!
Adapted From: Enterprise Design Objectives: Complexity and Change© 2008 John A. Zachman, Zachman International
If the object you are trying to create is simple, you can see the whole thing all at once, and it is not likely to change, then you don't need architecture. All you need is a tool, some raw material and some time.
On the other hand, if the object is complex, you can't see it in its entirety at one time and it is likely to change considerably over time, then you need Architecture.
If you can’t describe it … then you can’t create it!
5/1/2009 - 5Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Dealing with Complexity Today
MOC
Future Ops
Future Pl ans
Externa lMOC
Organiz ations
Subordinate Forces
Reachback
Col l aborati ve I nformati on Envi ronment (CI E)
Current Ops
Logi sti cs
I ntel l i gence
Command El ement
Assessment
W o rk in g Gro ups , Boa rds , & Ce lls
Pro v ide /Pub lis hDa ta /In form a tion to Ne t-
Ce ntric Env rionm e nt(Othe r As s e ts )
5
Co ordin a te Pla n s &Ta s k in g w/Othe rCo m po ne nts &
Su pportingOrg a niz a tio ns (F OPS)
5
Co ordin a te Pla n s &Ta s k in g w/Othe rCo m po ne nts &
Su pportingOrg a niz a tio ns
(COPS)
Un de rs ta ndPla ns Be ing
De v e lo pe d ByOth e r As s e ts
5Type
Pro v ide /Pub lis hDa ta /In form a tion
to Ne t-Ce ntricEn v rion m e n t(Highe r HQ)
5
Co nduc t M SCPRis k As s e s s m e nt
(Fu ture Pla n s )5
Co lle c tDa ta /In form a tion
(Su bs )5
Ap prov e dOPORD/ Orde rs /
Sc he du lingM e s s a ge s
Ide ntify Allo c a te dFo rc e s / Re s ourc e s
5Type
Co lle c tDa ta /In form a tion
(Highe r HQ)5
Co lle c tDa ta /In form a tion
(Othe rs )5
Pre pa re M SCP5
Type
Sin gle
Re fine IPB toSu pport Pla nDe v e lo pm e nt
(Re a c h )
As s e s s Ris k onOrd e rs (Re a c h-
ba c k )5
Re fine IPB toSu pport Pla n
De v e lo pm e nt (In te l)5
Co nduc t M SCPRis k As s e s s m e nt
(Re a c h )5
Re c onc ile Orde rs(COPS)
5Type
Pre pa reOrd e rs(FOPS)
5Type
Ba c k Brie f &Cro s s W a lk
Ord e rs (COPS)
Ba c k Brie f &Cro s s wa lk
Ord e rs (FOPS)5
As s e s s Ris k onOrd e rs (COPS)
5Type
Re c onc ile M SCP5
Type
Sin gle
Re c onc ile Orde rs(FOPS)
5
Pre pa reOrd e rs(COPS)
5Type
As s e s s Ris kon Orde rs
(FOPS)5
Ap prov eM SCP
5Type
Ris kAs s e s s m e n t(On Ord e rs )
Su pple m e n ta lROE
Cro s s wa lk e dOrd e rs
Sy nc hroniz a tion M a tri x
Ap prov eOrd e r
5
M SCP Ris kAs s e s s m e n t
Re fine dIPE- Pla nDe v e lo p
Su pple m e n ta lROE Re que s t
Alloc a te dFo rc e s /
Re s ourc e s
Ris kM i tiga tion
Pla n
IPB/As s e t Pla ns
Ord e r Pre pa ra tio n
As s e s s Ris k -Ord e rsOrd e rs Ris k As s e s s m e nts
COPS/F OPS Orde rs
Oth e rAs s e tPla ns
Ap prov e dM SCP
CONOPS
Dra ftM SCP
TSCP
Ap prov e d Orde rs
CONOPS De v e lop e d
M HQ w/ M OC_ Pla nnin g_ (Prov id e _ Pla ns _ &_ Orde rs )_ v 1 .0 _ VB_ Appro v e d_ 2 4 _ J a n_ 0 7 (Bus i ne s sPro c e s s )Sy s te m Arc hite c tTu e Fe b 0 6 , 2 0 0 7 0 5 :5 2Comment
Th is di a gra m de s c ribe s the M SCP de v e lop m e n t a n d foll ow o n ord e rs tha t a re g e ne ra te d ba s e d o n th a tpla n. I t inc orpo ra te s c ha nge s d ire c te d a s re s u lt of the M HQ with M OC wa rg a rm e . Proc e s s c olorc o ding m a tc he s tha t of the th e OV-5 Ac tiv i ty M ode l .
Version 1.0 Dated 24JAN 07 MHQ Plan (Provide Plans & Orders) Process Diagram
(Post MHQ w/MOC Wargame Draft)
USCG, DoS, DHS, CBP, Coa litio n, De fe ns e Ag e nc ie s ,Oth e r M ilita ry Se rv ic e s , I nte r-Age n c ie s , NGOs ,
Co m m e rc ia l Shi ppin g Co m pa nie s , e tc .
Lo gis ti c s
Co m m a nd Ele m e nt
Cu rre nt Ops
Fu ture Ops
As s e s s m e n t
Fu ture Pla n s
Inte l
Co lla bo ra tiv e In fo En v iro n (CI E)(Globa l Info rm a tion Grid)
W o rk in g Gro ups , Boa rds , & Ce lls
Oth e r As s e t Pla n s
Oth e r As s e t Pla n s
CONOPS
Alloc a te d F orc e s /Re s ourc e s
Dra ft M SCP-FOPS
TSCP
M SCP-Othe rs
M SCP-Subs
M SCP-F OPS
M SCP-COPS
Ord e rs Ris k As s e s s m e nt
Ap prov e d Orde rs (Su bs )
Ap prov e d Orde rs (Oth e rs )
Su pple m e n ta l ROE
Su pp ROE-F OPS
Su pp ROE COPS
CONOPS
Reconciled MSCP
Dra ft M SCP
Re c onc ile d Orde rs (F OPS) Cro s s wa lk e d Ord e rs (FOPS)
Ris k As s e s s m e nt FOPS
Ap prov e d M SCP
Ord e rs (FOPS)
Ap prov e d Orde rs
Oth e r Age nc ie s / Orgs Pla n s
IPB-Pla n (In te l)
IPB Uod a te -Pla n De v e lop m e n t
Oth e r As s e t Pla n s
Alloc a te d F orc e s /Re s ourc e s
M SCP Ris k
FOPS Orde r Re qm ts
FOPS-Orde rs Ris k
COPS-Orde rs Ris kOrd e rs (COPS)
Ris k As s e s s m e nt COPS
FOPS Orde rs Ris k
COPS Orde rs Ris k Re c onc ile d Orde rs (COPS)
Cro s s wa lk e d Ord e rs (COPS)
COPS Orde rs Re q m ts
FOPS Orde rs
COPs Orde rs
Ord e rs
Re fine d IPB
Ap prov e d Orde rs /Sc h e du ling M e s s a ge s
Supplement al ROE Request
Ap prov e d M SCP-FOPSAp prov e d M SCP-COPS
Cro s s wa lk e d Ord e rs (Othe rs )
Alloc a te d F orc e s /Re s ourc e s -FOPS
Alloc a te d F orc e s /Re s ourc e s -COPS
Sy nc hroniz a tion M a trix
IPB Upd a te (Re a c h)
Re a c hb a c k Ris k As s e s s m e n t
Ord e rs Ris k As s e s s m e nt-Re a c hba c k
10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space
5/1/2009 - 6Copyright ©2009 The MITRE Corporation. All Rights Reserved.
In Reality … Dealing with Complexity Today
100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces
5/1/2009 - 7Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Complexity increases as we . . .
► Increase the size and scope of the systems we are attempting to specify and build
► Move towards systems of systems and families of systems
► Strive for increased systems agility in support of increased operational agility
► Move from platform-base to capability-based planning
► Overly complicate acquisition practices
We may be hitting fundamental limits within the methods we use today for systems development
Architecture Theory
A Quick Course
Yogi Berra said: “In theory there is no difference between theory and practice. In practice there is.”
5/1/2009 - 8Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 9Copyright ©2009 The MITRE Corporation. All Rights Reserved.
All Systems have an Architecture
System n. a set of components and an associated mechanism, apparent or not, for integrating them as a cohesive whole. The whole is sufficiently cohesive to have an identity distinct from its environment.
System components might include people, cultures, organizations, policies, services, techniques, technologies, information/data, facilities, products, procedures, processes, other systems, and/or any other natural or artificial (i.e. man-made) things – much more than just information or communications system components!
Architecture n. an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.
5/1/2009 - 10Copyright ©2009 The MITRE Corporation. All Rights Reserved.
All systems have an architecture, intentionally architected or not, and that architecture is a primary determinant of other properties of the system — e.g. behavior, “ilities”
In architecting our goal is two-fold:– to understand the properties of existing systems (as-is, as built)– to understand and predict the properties of the systems we intend to
build (to-be, as-designed)
Why do we Practice Architecting?
The Architecting ThesisIf we can make apparent the architecture of a system, then we
can understand, effect, and manage that architecture in order to affect other properties of the system.
If you don’t control the architecture of your system, then that architecture will control your system!
5/1/2009 - 11Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecture n. an intrinsic quality or property of a system consisting of the arrangement and interrelationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.
Architecture Description n. a representation of an architecture; a conceptualization of the form of a system.
Framework n. a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality
Architecture Framework n. a way of conceptualizing the form of a system.
Architecture Descriptions and Frameworks
Architecture is reality!Architecture Description is a view of reality!
Bad Architecting Rule #1
“Don’t ever let reality get in the way of your
view of reality!”
Architecting and Engineering
Two Sides of the Same Problem
5/1/2009 - 12Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 13Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting and Engineering─ Two Sides of the Same Problem
Synthesis of Form ► ◄ Analysis of Function
• Reductionist• Reduces complexity• Optimizing - technical optimization• Quantitative costs• Deductive• Algorithms• Value in the “how”• Emphasis on arrangement (syntax)• Internal interfaces - Boundedness• Precision; exact• Produces implementation specification• Engineering “design”
Architecting Engineering
• Holistic• Manipulates complexity• Satisficing - client satisfaction• Qualitative worth• Abductive• Heuristics• Value in the “what”• Emphasis on meaning (semantics)• External interfaces - Openness• Abstraction; notional• Produces architectural
specification• Architectural “design”
5/1/2009 - 14Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Engineering – One Side of the Problem
Engineerible RequirementsThe set of engineering requirements necessary and sufficient to initiate
the successful engineering and production of a system
Big implication here!Engineering requires arepresentation of the whole as an“initial point” to be successful!
Engineering does not workwithout an initial point!!
We call this “initial point”:
Engineering employs analysis of function to iteratively decomposeand separate a primarily functional representation of a whole into representations of economically producible components that can be assembled to construct the functional whole.
“initial point”engineeriblerequirements
representations of economicallyproducible components that can be
assembled to construct the functional whole
Analysisof Function
iteratively decompose andseparate a primarily functional
representation of a whole
Engineering
“initial point”engineeriblerequirements
representations of economicallyproducible components that can be
assembled to construct the functional whole
Analysisof Function
iteratively decompose andseparate a primarily functional
representation of a whole
Engineering
5/1/2009 - 15Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting – The Other Side of the Problem
Architecture SpecificationAn architecture description to which all system implementations must adhere; and a set of principles, practices, and constraints guiding implementation, operation,
and evolution of the developed system.
Architecting employs synthesis of form to iteratively compose separate elements to form a coherent whole, or a representation of a coherent whole, that can serve as an “initial point” for system development.
collective vision, goals, constraints,and other needs of the stakeholders
iteratively composeseparate elements to
form a coherent whole
Synthesisof Form
Architecting
architecturespecification
collective vision, goals, constraints,and other needs of the stakeholders
iteratively composeseparate elements to
form a coherent whole
Synthesisof Form
Architecting
architecturespecification
From the point of view of architecting,we refer to this “engineering initial point” as an:
Architecting synthesizes this“initial point” from the collectivevision, goals, constraints, and otherneeds of the stakeholders — converting conflicting stake-holder demands into a conceptualized whole that maximizes the satisfaction of each stakeholder.
5/1/2009 - 16Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting and Engineering─ Two Sides of the Same Problem
architecture specification
engineerible requirements
collective vision, goals, constraints,and other needs of the stakeholders
representations of economicallyproducible components that can be
assembled to construct the functional whole
Analysisof Function
iteratively decompose and separate a primarily functional representation of a whole
iteratively compose separate elements toform a coherent whole
Synthesisof Form
Engineering
Architecting
From Capabilities to Systems
The Role of the Architect in DoD
5/1/2009 - 17Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 18Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Yesterday … The Platform Enterprise Value Chain
Mission Achieved
Mission Need
Platform EmploymentPlatform Employment
Platform PlanningPlatform Planning
Platform DevelopmentPlatform Development
PlatformPlatform
Mission NeedStatement
Mission NeedStatement
OperationalRequirementsOperational
Requirements
RequirementsDevelopment
Deploymentand Warfighting
ComponentDevelopmentComponent
Development
RequirementsEngineering
RequirementsEngineering
System Demo& Validation
System Demo& Validation
FunctionalAllocationFunctionalAllocation
System Integ& Test
System Integ& Test
Systems Engineeringand
Development Process
PlatformPlatformOperationalRequirementsOperational
Requirements
Planner
Builder
Operator
In the “platform world” operational requirements were expressed much like engineering requirements. It was possible for systems development to produce systems that usually could be easily validated against their operational requirements.
In the “platform world” operational requirements were expressed much like engineering requirements. It was possible for systems development to produce systems that usually could be easily validated against their operational requirements.
5/1/2009 - 19Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
Today … The Capability Enterprise Value Chain
“Builder’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
DoD 5000*
JCIDS
Doctrine,CONOPS
Warfighting
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
* DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components.
5/1/2009 - 20Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
There is a Significant Missing Linkin DoD’s Capability Value Chain!!
EngineeribleRequirementsEngineerible
Requirements
“Builder’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
DoD 5000*
JCIDS
Doctrine,CONOPS
Warfighting
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
* DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components.
DescriptionGap
5/1/2009 - 21Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
Architecting is the Disciplinethat Bridges the Description Gap
Capability ArchitectingCapability Architecting
CapabilityArchitectureCapability
Architecture“Builder’s
View”
“Architect’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
DoD 5000*
ArchitectureSpecification
JCIDS
Doctrine,CONOPS
Warfighting
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
* DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components.
5/1/2009 - 22Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting is the Disciplinethat Bridges the Description Gap
architecture specification
engineerible requirements
collective vision, goals, constraints,and other needs of the stakeholders
representations of economicallyproducible components that can be
assembled to construct the functional whole
Analysisof Function
Synthesisof Form
Engineering
Architecting
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
Capability ArchitectingCapability Architecting
CapabilityArchitectureCapability
Architecture
Capability ArchitectingCapability Architecting
CapabilityArchitectureCapability
Architecture
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
5/1/2009 - 23Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting is a Multiple Domain Discipline
Capability Architecting
In capability architecting the architect applies architecting principles and
practices to translate capability needs into enterprise engineering
requirements
Systems Architecting
In systems architecting the architect applies architecting principles and practices to allocate engineering requirements to system/product
components
Operational Architecting
In operational architecting the architect applies architecting principles and practices to select and integrate
operational resources into an effective mission focused structure
Enterprise Architecting
In enterprise architecting the architect applies architecting principles and
practices to plan the alignment of IT resources with corporate strategy
Core Principles and Practicesof Architecting
5/1/2009 - 24Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
DoD Architects Practice in Multiple Domains
Capability ArchitectingCapability Architecting
CapabilityArchitectureCapability
Architecture“Builder’s
View”
“Architect’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
En
terp
ris
eA
rch
ite
cti
ng
Sy
ste
mA
rch
ite
cti
ng
Architecture-Driven Systems Development
The Role of Architecture Throughout Systems Development
5/1/2009 - 25Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 26Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Why are Acquisition Programs Failing?
Many major government acquisition programs have failed to meet cost, schedule, and performance expectations because:
– Requirements were unrealistic, too complex, too rigid, and unstable
– Inadequate program planning and risk management– Insufficient effort on system architecture and systems
engineering– Contractor lacked sufficient capability or/and domain
experience– Insufficient commitment to ensure adequate and stable
funding– Use of program award/incentive fee not tied to program
outcomesFrom: Huffman, Dr. S.D. Improving Acquisition Program Performance: The “Architect” Role. 23 January 2006
5/1/2009 - 27Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
Description Gap Leads to Requirements Failure
EngineeribleRequirementsEngineerible
Requirements
“Builder’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
DoD 5000*
JCIDS
Doctrine,CONOPS
Warfighting
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
* DoD 5000 applies to the development of materiel components of a capability. In addition to materiel, capability development should consider the range of DOTMLPF solution components.
DescriptionGap
Issue #1 – Inadequate translation of capability need into
engineering requirements leads to requirements failure
5/1/2009 - 28Copyright ©2009 The MITRE Corporation. All Rights Reserved.
DoD 5000
Capability EmploymentCapability Employment
Capability DevelopmentCapability Development
CapabilityCapability
Achieved Effects
… And Requirements Failure Cascades Through the Capabilities-to-Systems Value Chain
EngineeribleRequirementsEngineerible
Requirements
“Builder’sView”
“Planner’sView”
“Strategist’sView”
“Operator’sView”
JCIDS
Doctrine,CONOPS
Warfighting
Capability ExpressionCapability Expression
Desired Effects(conflict, market, social, other)
Capability PlanningCapability Planning
CapabilityConcept
CapabilityConcept
CapabilityNeed
CapabilityNeed
DescriptionGap
Inability to validate resulting system against original need
Inadequate linkage of requirements to developed system which results in …
Poor initial requirements baseline which cascades through systems development and ultimately results in …
Inadequate translation of capability need into engineering requirements results in …
5/1/2009 - 29Copyright ©2009 The MITRE Corporation. All Rights Reserved.
What is Architecture-Driven Systems Development?
► The incremental specification and development of a successful system through iterative synthesis of architecture descriptions
► … where those architecture descriptions serve as the “scaffolding” upon which to attach, organize and relate requirements.
► An Architecture Specification serves as the initial well-formed architecture description from which all other descriptions are iteratively developed.
5/1/2009 - 30Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecture Specification Establishesthe Engineering Requirements Baseline
► Stakeholder developed capability descriptions– lack key engineering-level completeness
and consistency– not expressed in the form of requirements
traditionally expected as the input to system development, demonstration and production
► Architecture Specification is rigorous enough to form a set of engineering requirements that can drive the Defense Acquisition System– Provides a black box specification of the
system– Provides a performance specification of the
system as a whole– Describes the external interfaces to the
system
Architecture Specification translates vague stakeholder needs into specific engineering requirements from which a series of system
development baselines can be iteratively developed.
ProductSpecifications
Engineering Baseline
Functional Baseline
Allocated Baseline
Product Baseline
ItemSpecifications
FunctionalSpecification
ArchitectureSpecification
CapabilityDevelopment
Document
MS B
System Requirements Review (SRR)
System Functional Review (SFR)
MS C
Sy
ste
m D
ev
elo
pm
en
t a
nd
De
mo
ns
tra
tio
n P
ha
se
Preliminary (PDR) and Critical Design (CDR) Reviews
5/1/2009 - 31Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Functional Specification Establishesthe Functional Requirements Baseline
► Derives a functional solution to the engineerible requirements provided by the architecture specification– Provides a white box specification of the
system as a collection of functional elements– Provides a performance specification at the
level of functional elements– Describes the functional interfaces within and
to the system
► System development process continues through successive engineering baselines– Solution space continues to narrow and spiral
towards an optimal system design– Best implementation selected from the set of
candidate implementations ProductSpecifications
Engineering Baseline
Functional Baseline
Allocated Baseline
Product Baseline
ItemSpecifications
FunctionalSpecification
ArchitectureSpecification
CapabilityDevelopment
Document
MS B
System Requirements Review (SRR)
System Functional Review (SFR)
MS C
Sy
ste
m D
ev
elo
pm
en
t a
nd
De
mo
ns
tra
tio
n P
ha
se
Preliminary (PDR) and Critical Design (CDR) Reviews
Functional Specification translates a system-level “black box” design into a first level system design consisting of functional
elements that achieve system behavior and performance.
5/1/2009 - 32Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Traditional Systems Architecting
ComponentDevelopmentComponent
Development
RequirementsEngineering
RequirementsEngineering
System Demo& Validation
System Demo& Validation
System Integ& Test
System Integ& Test
Systems Engineeringand
Development Process
SystemSystemRequirementsRequirements
At the functional baseline the architecting paradigm is employed to synthesize a functional model from discrete requirements. But … again this begs the question
of where did the requirements come from?
At the functional baseline the architecting paradigm is employed to synthesize a functional model from discrete requirements. But … again this begs the question
of where did the requirements come from?
FunctionalAllocationFunctionalAllocation
The Role of Systems Architecting within
Systems Engineering
Some debate whether architecting is part of or separate from systems engineering. However, both views are correct! Traditional systems architecting is generally applied in the context of developing a series of engineering baselines—most notably a functional baseline which includes a functional architecture.
5/1/2009 - 33Copyright ©2009 The MITRE Corporation. All Rights Reserved.
First Real “System Architecture” Emergesat the Allocated Requirements Baseline
► Provides set of CI performance and interface specifications that satisfy the functional (and associated non-functional) requirements provided by the functional specification
► Specific system design emerges in the form of configuration items [hardware/software configuration items (CIs) ] and their interface specifications– May be a many-to-many relationship from
functions (and non-functional rqmnts) to CIs– Provides a structure for the “Configuration
Item (CI) Tree”
► In systems engineering the allocated baseline constitutes the first real system architecture and design — very different in concept from DoDAF’s system view which is commonly referred to as a system architecture
ProductSpecifications
Engineering Baseline
Functional Baseline
Allocated Baseline
Product Baseline
ItemSpecifications
FunctionalSpecification
ArchitectureSpecification
CapabilityDevelopment
Document
MS B
System Requirements Review (SRR)
System Functional Review (SFR)
MS C
Sy
ste
m D
ev
elo
pm
en
t a
nd
De
mo
ns
tra
tio
n P
ha
se
Preliminary (PDR) and Critical Design (CDR) Reviews
Allocated Baseline translates an abstract functional design into producible physical
components.
5/1/2009 - 34Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Product Specification Provides the “Build-to”Architecture at the Product Requirements Baseline
► Provides a mapping of COTS, GOTS or developmental item products to the hardware/software configuration items (CIs) described at the allocated baseline
► Provides a set of product performance and interface specifications that satisfy the requirements provided at the allocated baseline
► Follows the structure of the “Configuration Item (CI) Tree”
Product Baseline translates the configuration tree into COTS, GOTS or developmental item
products.Product
Specifications
Engineering Baseline
Functional Baseline
Allocated Baseline
Product Baseline
ItemSpecifications
FunctionalSpecification
ArchitectureSpecification
CapabilityDevelopment
Document
MS B
System Requirements Review (SRR)
System Functional Review (SFR)
MS C
Sy
ste
m D
ev
elo
pm
en
t a
nd
De
mo
ns
tra
tio
n P
ha
se
Preliminary (PDR) and Critical Design (CDR) Reviews
Thank you!!
Please contact me at:
Brad MercerChief ArchitectNaval C4I SystemsMaritime IT and EngineeringThe MITRE CorporationSPAWARSYSCEN SD49185 Transmitter Road, Building 626San Diego, CA 92152-7335
619-758-7814
5/1/2009 - 35Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Additional Slides
5/1/2009 - 36Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 37Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecting ≠ Designing
► Many believe that architecting and designing are the same thing — not true!– Designing is the process of resolving conflicting constraints– Architecting is the process of synthesizing form
► Architects and Engineers both apply the process of design and both produce “designs” — but through the application of very different paradigms …– Architects design through Synthesis
– Engineers design through Analysis
Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs.
Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs.
Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.
5/1/2009 - 38Copyright ©2009 The MITRE Corporation. All Rights Reserved.
A Proliferation of “architects”
► One result of confusing architecting and designing is that people who previously were designers now refer to themselves as architects — without any change in skill or objective!
► Anyone who previously did design (network designer, system designer, application designer, solution designer, data designer, business designer, security designer, process designer, etc.) is now an “architect” (network architect, system architect, application architect, solution architect, data architect, business architect, security architect, process architect, etc.)
► Serious implications! These new “architects” are now “architecting designs” (i.e. creating implementations) without a specification (i.e. architecture description) to guide them
OK, so … technicians are now “engineers”, and engineering-focused designers are now “architects”? What happened to real engineers and architects?
Architect n. a person who practices “architecting”
The Practice of ArchitectingFrom the simplest point of view, the practice of architecting is the
application of the architecting paradigm to the creation of architecture specifications that can be employed as engineerible
requirements for engineering and producing systems.
5/1/2009 - 39Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 40Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecture Specification as a Solution Space
An Architecture Specification is an architecture description to which all system implementations must adhere; and a set of principles, practices, and constraints guiding implementation, operation, and evolution of the developed system.
a set of potentialimplementationsa set of potentialimplementations “a solution space”“a solution space”
one potentialimplementation
boundary defined by thearchitecture specification
Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs.
Architects apply the process of design to synthesize a form through trials guided by heuristics in order to compare forms until a qualitative best-fit emerges that satisfices conflicting needs.
5/1/2009 - 41Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Engineerible Requirements are the set of engineering requirements necessary and sufficient to initiate the successful engineering and production of a system
a set of candidateimplementations
a set of candidateimplementations “a solution space”“a solution space”
one candidateimplementation
boundary defined byengineerible requirements
Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.Engineers apply the process of design through quantitative analysis to tradeoff conflicting requirements until an optimal solution is determined.
Engineerible Requirements as a Solution Space
5/1/2009 - 42Copyright ©2009 The MITRE Corporation. All Rights Reserved.
What does an Architecture Specification Include?
Part I - Architectural ContextAn expression or representation of the larger scope outside the boundary of the solution space to be established by this architecture specification. Includes expression of the key relationship between this architecture specification and others within the context.
Part II - Architectural QualitiesSince we are describing a “solution space” rather than a “point solution” architectural qualities are more generalized than requirements as commonly understood to allow for satisfaction by multiple potential implementations.
Part III - Architectural DescriptionMost likely expressed as a set of patterns
– Standard Patterns– Solution Specific Patterns
Part IV - Architectural GuidanceA set of principles, practices, and constraints guiding implementation, operation, and evolution of the developed system
A Pattern is a general repeatable solution to a commonly occurring problem; combination of implicit and explicit knowledge repeatedly applied with success in the past and commonly captured as best practices and models
5/1/2009 - 43Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Some Principles of Architecture Specification
► Well-Formedness – A well-formed outcome is a consequence that meets certain conditions designed to avoid classic self-defeating intentions. It has been clearly and well enough defined to be prima facie free of common "muddy thinking.“
► Semantic Completeness – The condition of a formal system in which (1) the formal language has the power to express as well-formed formulas all of the propositions intended by the maker to be meaningful (expressive completeness), and (2) the deductive apparatus has the power to prove as theorems all the propositions intended by the maker to be true (deductive completeness).
An architecture specification should be well-formed, complete, and consistent enough to allow an engineer to select and describe an
underlying implementation and to create a specification for production of the system.
5/1/2009 - 44Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Art or Science?
Art noun1. A system of principles and methods employed in the performance of a set of
activities: the art of building.
2. A trade or craft that applies such a system of principles and methods: the art of the lexicographer.
3. Skill that is attained by study, practice, or observation: the art of the baker; the blacksmith's art.
4. Skill arising from the exercise of intuitive faculties: "Self-criticism is an art not many are qualified to practice" (Joyce Carol Oates).
From: “art” The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004.
Science noun1. The observation, identification, description, experimental investigation, and
theoretical explanation of natural phenomena or object of study or inquiry.
2. Methodological activity, discipline, or study: I've got packing a suitcase down to a science.
3. An activity that appears to require study and method: the science of purchasing.
4. Knowledge, especially that gained through experience.
From: “science” The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004.
5/1/2009 - 45Copyright ©2009 The MITRE Corporation. All Rights Reserved.
► Architecture n. (another definition) the highest level conceptual-ization of a system.
► In defining a System as a “set of components and an associated mechanism, apparent or not, for integrating them as a cohesive whole” we allowed the components of a system to be other systems — and thus we have defined a system as a recursively hierarchical entity.
► As “architecture” is an intrinsic quality of each system in such a recursive hierarchy of systems, there will exist a recursive hierarchy of architectures as well — and each of the levels in this hierarchy will likely have a different conceptualization!
► Serious implications! Lots of debate about what really constitutes THE architecture!
Architectures within Architectures within …
5/1/2009 - 46Copyright ©2009 The MITRE Corporation. All Rights Reserved.
DODAF and DoD ArchitectingA Case Study in “Reality”
Although it was a good intentioned effort to codify the practice of architecting within DoD, DODAF led to the emergence of an entire generation of DoD architects that viewed architecting as focused on the creation of 26 artifacts or “architecture products.” An entire language of “SV-this” and “OV-that” emerged that soon forgot what architecting was really about — becoming an entire subculture “lost on a far away planet.”
“I once saw an episode of the original ‘Star Trek’ television series where a century earlier a space traveler from Earth had visited a primitive, but industrious humanoid culture on a far away planet — leaving behind an Earth novel about the conflict in the 1920’s and 30’s between Al Capone, the gangster, and Elliott Ness, the FBI G-man.”
“By the time Capt Kirk and his starship Enterprise arrived the culture of the entire planet had been modeled on the culture portrayed in the novel – right down to raging gun battles in the streets between gangsters and G-men.”
The misapplication of DODAF may be the worst thing that has ever happened to the practice of architecting within the DoD.
“Yeah, but it’s better than nothing!” No its not! “Nothing” costs less, happens faster, and has more positive impact!
5/1/2009 - 47Copyright ©2009 The MITRE Corporation. All Rights Reserved.
What is the structure or form of a system?
INFORMATION
FUN
CTI
ON B
EH
AVIO
R
Architecture
Functional “Structure”
Described using Functional Models (e.g. flow diagrams,
function hierarchies, interface diagrams)
Functional “Structure”
Described using Functional Models (e.g. flow diagrams,
function hierarchies, interface diagrams)
Behavioral “Structure”
Described using Behavioral Models (e.g. rule sets, state
diagrams, event traces)
Behavioral “Structure”
Described using Behavioral Models (e.g. rule sets, state
diagrams, event traces)
Information “Structure”
Described using Information Models (e.g. data models,
ontologies)
Information “Structure”
Described using Information Models (e.g. data models,
ontologies)
Architecture n. an intrinsic quality or property of a system consisting of the arrangement and inter-relationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.
Architecture n. an intrinsic quality or property of a system consisting of the arrangement and inter-relationships, both static and dynamic, among its components and their externally visible properties; the structure or form of a system.
Architecture Description n. a representation of an architecture; a conceptualization of the form of a system.
Architecture Description n. a representation of an architecture; a conceptualization of the form of a system.
5/1/2009 - 48Copyright ©2009 The MITRE Corporation. All Rights Reserved.
The Architect’s View
► “Architect’s View” – View taken by the architect in formalizing and expressing the client’s needs as an architecture description
► Contains only elements needed by the architect to describe an architecture and nothing more
► Logical data models do not represent the architect’s view – they include too many non-architecture artifacts
► The “Architect’s View” is expressed using a formal conceptual model that provides a common set of semantics for expressing that view
Implemented Database
Conceptual Data Model
Conceptual Model
Logical Data Model
Physical Data Model
Architect’s View
The Model Stack
The architect’s role is to formalize and represent the needs of his client – the warfighter. This role motivates a unique view
of the architecture – “the architect’s view.”
5/1/2009 - 49Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Architecture Semantics
groups
groups
acco
mpl
ishe
s produces
consumes
Who? What?
Where? How?
FunctionFunction
ResourceResource
LocationLocation
EventEvent
controls
selects
ProductProduct
RuleRule
When?
Why?
generates
5/1/2009 - 50Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Products and Events are not the actual effects achieved by a capability. The
effect is achieved indirectly asa change in state in response
to the products and events.
Products and Events are not the actual effects achieved by a capability. The
effect is achieved indirectly asa change in state in response
to the products and events.
Capability and Effects
Capability n. The ability to achieve a desired effect under specified standards and conditions through combination of means and ways to perform a set of tasks.
─ From CJCSI 3170.01E, Joint Capabilities Integration and Development System, 11 May 2005
Capability n. The ability to achieve a desired effect under specified standards and conditions through combination of means and ways to perform a set of tasks.
─ From CJCSI 3170.01E, Joint Capabilities Integration and Development System, 11 May 2005
Effect n. a change to a condition, behavior, or degree of freedom
─ From CJCSM 3500.04D, Universal Joint Task List, 1 August 2005
Effect n. a change to a condition, behavior, or degree of freedom
─ From CJCSM 3500.04D, Universal Joint Task List, 1 August 2005
Ways
Standards
Conditions
Means
groups
groups
acco
mpl
ishe
s
pro
du
ces
consumes
FunctionFunction
ResourceResource
NodeNode
Event1Event1
controls
selects
ProductProduct
RuleRule
Event2Event2
generates
“Effect”
Ways
Standards
Conditions
Means
groups
groups
acco
mpl
ishe
s
pro
du
ces
consumes
FunctionFunction
ResourceResource
NodeNode
Event1Event1
controls
selects
ProductProduct
RuleRule
Event2Event2
generates
“Effect”
Location
Event1
(Time)
Event2
(Time)
5/1/2009 - 51Copyright ©2009 The MITRE Corporation. All Rights Reserved.
A Few Simple Principles
FoundationBefore Structure!!
Words MeanThings!!
One Aspectat a Time!!
5/1/2009 - 52Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Words Mean Things!!
Principle of Semantic Completeness
The condition of a formal system in which (1) the formal language has the power to express as well-formed formulas all of the propositions intended by the maker to be meaningful (expressive completeness), and (2) the deductive apparatus has the power to prove as theorems all the propositions intended by the maker to be true (deductive completeness).
A community of discussion must include all of the concepts
necessary to describe its domain and there must be no inconsistencies between the
concepts.
A community of discussion must include all of the concepts
necessary to describe its domain and there must be no inconsistencies between the
concepts.
Tower of Babel
5/1/2009 - 53Copyright ©2009 The MITRE Corporation. All Rights Reserved.
One Aspect at a Time!!
A system should be described such that its
functions can be examined independently of one another in order to make the system easier to
understand, design and manage.
A system should be described such that its
functions can be examined independently of one another in order to make the system easier to
understand, design and manage.
Principle of Separation of Concerns
“… to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency.”
“… focusing one's attention upon some aspect: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.” – Edsger W. Dijkstra, On the role of scientific thought
Self-Operating Napkin by Rube Goldberg
5/1/2009 - 54Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Foundation Before Structure!!
Structure is not a substitutefor a good foundation.
Adding more structure will not remedy a bad foundation.
Structure is not a substitutefor a good foundation.
Adding more structure will not remedy a bad foundation.
Principle of Well-Formedness
A well-formed outcome is a consequence that meets certain conditions designed to avoid classic self-defeating intentions.
It has been clearly and well enough defined to be prima facie free of common "muddy thinking."
Tower of Pisa