Contenu connexe Similaire à Thoughts on Architecting v4.3 (20) Thoughts on Architecting v4.31. Thoughts on Architecting
. . . And How to Improve the Practice
Version 4.3
May 1, 2009
Brad Mercer
Chief Architect/Department Head
Naval C3 Systems Department
The MITRE Corporation
San Diego, California
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
2. 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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 2
3. 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
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 3
4. Complexity is the Enemy!!
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!
Adapted From: Enterprise Design Objectives: Complexity and Change
© 2008 John A. Zachman, Zachman International
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 4
5. Dealing with Complexity Today
Ex terna l
M OC
Organiz ati
USCG, DoS, DHS, CBP, Coa litio n, De fe ns e Ag e nc ie s ,
ons
Pro v ide /Pub lis h
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 .Da ta /In form a tion to Ne tCe ntric Env rionm e nt
(Othe r As s e ts )
5
Co lle c t
Da ta /In form a tion
(Hi ghe r HQ)
5
Co lle c t
Da ta /In form a tion
(Othe rs )
5
Pro v ide /Pub lis h
Da ta /In form a tion
to Ne t-Ce ntric
En v rion m e n t
(Hi ghe r HQ)
5
Ap prov e d Orde rs (Oth e rs )
Cro s s wa lk e d Ord e rs (Othe rs )
Ap prov e d Orde rs /Sc h e du ling M e s s a ge s
Su pple m e n ta l ROE
S ement al R R
uppl
OE equest
Oth e r As s e t Pla n s
Subordina
te Forc es
M SCP-Othe rs
Co lle c t
Da ta /In form a tion
(Su bs )
5
Ap prov e d Orde rs (Su bs )
M SCP-Subs
M OC
C l aborati ve I nformati on E r onment (C E
ol
nvi
I )
All oc a te d F orc e s /Re s ourc e s -COPS
Re fine d IPB
Ap prov e d M SCP-COPS
Ap prov e d M SCP-FOPS
All oc a te d F orc e s /Re s ourc e s -FOPS
Co lla bo ra tiv e In fo En v iro n (CI E)
(Gl oba l Info rm a tion Grid)
Oth e r
As s e t
Pla ns
Re fine d
IPE- Pla n
De v e lo p
Sy nc hroniz a tio
n M a tri x
All oc a te d
Fo rc e s /
Re s ourc e s
Su pple m e n ta l
ROE Re que s t
CONOP
S
Dra ft
M SCP
M SCP Ris k
As s e s s m e n t
Ris k
M i tiga tion
Pla n
Su pple m e n ta l
ROE
TSCP
Ap prov e d
OPORD/ Orde rs /
Sc he du ling
M e s s a ge s
Cro s s wa lk e d
Ord e rs
Ap prov e d
M SCP
Ris k
As s e s s m e n t
(On Ord e rs )
Ord e rs Ris k As s e s s m e nt
C
ommand El ement
Co m m a nd Ele m e nt
COPS/F OPS Orde rs
Ap prov e
M SCP
5
Ord e rs
Ap prov e d M SCP
Ap prov e
Ord e r
5
Ap prov e d Orde rs
Ap prov e d Orde rs
Type
CONOPS
Oth e r As s e t Pla n s
All oc a te d F orc e s /Re s ourc e s
TSCP
As s e s s m e n t
A
ssessment
R
econci d MS P
e
l
C
Su pp ROE-F OPS
Sy nc hroniz a tion M a trix
Dra ft M SCP-FOPS
M SCP-F OPS
Future P ans
l
Oth e r Age nc ie s / Orgs Pla n s Oth e r As s e t Pla n s
Fu ture Pla n s
CONOPS
CONOPS De v e lop e d
Un de rs ta nd
Pla ns Be ing
De v e lo pe d By
Oth e r As s e ts
5
Type
All oc a te d F orc e s /Re s ourc e s
Pre pa re M SCP
Ide ntify Allo c a te d
5
Fo rc e s / Re s ourc e s
Type
5
Sin gle
Type
IPB-Pla n (In te l)
IPB/As s e t Pla ns
Dra ft M SCP
Co nduc t M SCP
Ris k As s e s s m e nt
(Fu ture Pla n s )
5
FOPS Orde rs
M SCP Ris k
Re c onc ile M SCP
5
Type
Sin gle
Future Ops
Fu ture Ops
Cro s s wa lk e d Ord e rs (FOPS)
Re c onc ile d Orde rs (F OPS)
Pre pa re
Ord e rs
(FOPS)
5
Ord e rs (FOPS)
FOPS-Orde rs Ris k
Type
As s e s s Ris k
on Orde rs
(FOPS)
5
FOPS Orde rs Ris k
Ris k As s e s s m e nt FOPS
Ba c k Brie f &
Cro s s wa lk
Ord e rs (FOPS)
5
Re c onc ile Orde rs
(FOPS)
5
Co ordin a te Pla n s &
Ta s k in g w/Othe r
Co m po ne nts &
Su pporting
Org a niz a tio ns (F OPS)
5
Ord e r Pre pa ra tio n
FOPS Orde r Re qm ts
IPB Uod a te -Pla n De v e lop m e n t
C ent Ops
urr
Cu rre nt Ops
Su pp ROE COPS
I ntel l i gence
Inte l
Re fine IPB to
Su pport Pla n
De v e lo pm e nt (In te l)
5
Re a c hb a c k Ris k As s e s s m e n t
COPS Orde rs Re q m ts
M SCP-COPS
Logi sti cs
Lo gis ti c s
W o rk in g Gro ups , Boa rds , & Ce lls
W o rk in g Gro ups , Boa rds , & Ce lls
COPS-Orde rs Ris k
IPB Upd a te (Re a c h)
Pre pa re
Ord e rs
(COPS)
5
Type
Ord e rs (COPS)
As s e s s Ris k on
Ord e rs (COPS)
5
Ris k As s e s s m e nt COPS
Type
Re c onc ile d Orde rs (COPS)
COPS Orde rs Ris k
Re c onc ile Orde rs
(COPS)
5
Type
As s e s s Ris k -Ord e rs
Ord e rs Ris k As s e s s m e nts
Ba c k Brie f &
Cro s s W a lk
Ord e rs (COPS)
Co ordin a te Pla n s &
Ta s k in g w/Othe r
Co m po ne nts &
Su pporting
Org a niz a tio ns
(COPS)
COPs Orde rs
Cro s s wa lk e d Ord e rs (COPS)
Ord e rs Ris k As s e s s m e nt-Re a c hba c k
Re achbac
k
Co nduc t M SCP
Ris k As s e s s m e nt
(Re a c h )
5
Re fine IPB to
Su pport Pla n
De v e lo pm e nt
(Re a c h )
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 s
Pro c e s s )
Sy s te m Arc hite c t
Version 1.0 Dated 24
Tu e Fe b 0 6 , 2 0 0 7 0 5 :5 2
C
omment
JAN 07
Th is di a gra m de s c ri be 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 t
pla n. I t inc orpo ra te s c ha nge s dire 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 olor
c o ding m a tc he s tha t of the th e OV-5 Ac tiv i ty M ode l .
As s e s s Ris k on
Ord e rs (Re a c hba c k )
5
MHQ Plan (Provide Plans & Orders) Process Diagram
(Post MHQ w/MOC Wargame Draft)
10 Actors / ~ 25 Activities / ~ 20 Actor Relationships/ ~ 1 Shared Information Space
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 5
6. In Reality … Dealing with Complexity Today
100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 6
7. 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
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 7
8. Architecture Theory
A Quick Course
Yogi Berra said: “In theory
there is no difference between
theory and practice. In practice
there is.‖
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 8
9. All Systems have an Architecture
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.
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!
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 9
10. Why do we Practice Architecting?
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‖
The Architecting Thesis
If 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.
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)
If you don’t control the architecture of your system,
then that architecture will control your system!
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 10
11. Architecture Descriptions and Frameworks
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 is reality!
Architecture Description is a view of reality!
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Bad Architecting Rule #1
―Don‘t ever let reality
get in the way of your
view of reality!‖
5/1/2009 - 11
13. Architecting and Engineering
─ Two Sides of the Same Problem
Architecting
Engineering
Synthesis of Form
•
•
•
•
•
•
•
•
•
•
•
•
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‖
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
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‖
5/1/2009 - 13
14. Engineering – One Side of the Problem
Engineering employs analysis of function to iteratively decompose
and separate a primarily functional representation of a whole into
representations of economically producible components that can be
assembled to construct the functional whole.
Big implication here!
Engineering requires a
representation of the whole as an
―initial point‖ to be successful!
Engineering does not work
without an initial point!!
We call this ―initial point‖:
―initial point‖
engineerible
requirements
iteratively decompose and
separate a primarily functional
Analysis
representation of a whole
of Function
Engineering
representations of economically
producible components that can be
assembled to construct the functional whole
Engineerible Requirements
The set of engineering requirements necessary and sufficient to initiate
the successful engineering and production of a system
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 14
15. Architecting – The Other Side of the Problem
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.
Architecting synthesizes this
―initial point‖ from the collective
vision, goals, constraints, and other
needs of the stakeholders — converting
conflicting stake-holder demands into a
conceptualized whole that maximizes the
satisfaction of each stakeholder.
collective vision, goals, constraints,
and other needs of the stakeholders
Architecting
Synthesis
of Form
iteratively compose
separate elements to
form a coherent whole
architecture
specification
From the point of view of architecting,
we refer to this ―engineering initial point‖ as an:
Architecture Specification
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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 15
16. Architecting and Engineering
─ Two Sides of the Same Problem
collective vision, goals, constraints,
and other needs of the stakeholders
Architecting
Synthesis
of Form
iteratively compose
separate elements to
form a coherent whole
architecture specification
engineerible requirements
iteratively decompose and
separate a primarily functional
Analysis
representation of a whole
of Function
Engineering
representations of economically
producible components that can be
assembled to construct the functional whole
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 16
17. From Capabilities to Systems
The Role of the Architect in DoD
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 17
18. Yesterday … The Platform Enterprise Value Chain
Mission Need
Planner
Operational
Requirements
Platform
Operational
Requirements
Platform Development
Operator
Deployment
and Warfighting
Mission Need
Statement
Platform Planning
Builder
Requirements
Development
Platform
Requirements
Engineering
Systems Engineering
and
Development Process
Functional
Allocation
System Demo
& Validation
System Integ
& Test
Platform Employment
Component
Development
Mission Achieved
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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 18
19. Today … The Capability Enterprise Value Chain
Desired Effects
(conflict, market, social, other)
“Strategist’s
View”
Capability Expression
Doctrine,
CONOPS
Capability
Concept
“Planner’s
View”
Capability Planning
JCIDS
Capability
Need
“Builder’s
View”
Capability Development
Capability
“Operator’s
View”
Capability Employment
DoD 5000*
* 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.
Warfighting
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 19
20. There is a Significant Missing Link
in DoD’s Capability Value Chain!!
Desired Effects
(conflict, market, social, other)
“Strategist’s
View”
Capability Expression
Doctrine,
CONOPS
Capability
Concept
“Planner’s
View”
Capability Planning
Capability
Need
JCIDS
Description
Gap
Engineerible
Requirements
“Builder’s
View”
Capability Development
Capability
“Operator’s
View”
Capability Employment
DoD 5000*
* 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.
Warfighting
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 20
21. Architecting is the Discipline
that Bridges the Description Gap
Desired Effects
(conflict, market, social, other)
“Strategist’s
View”
Capability Expression
Doctrine,
CONOPS
Capability
Concept
“Planner’s
View”
Capability Planning
JCIDS
Capability
Need
“Architect’s
View”
Capability Architecting
Architecture
Specification
Capability
Architecture
“Builder’s
View”
Capability Development
Capability
“Operator’s
View”
Capability Employment
DoD 5000*
* 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.
Warfighting
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 21
22. Architecting is the Discipline
that Bridges the Description Gap
Desired Effects
(conflict, market, social, other)
collective vision, goals, constraints,
and other needs of the stakeholders
Capability Expression
Capability Expression
Capability
Capability
Concept
Concept
Architecting
Capability Planning
Capability Planning
Synthesis
of Form
Capability
Capability
Need
Need
Capability Architecting
Capability Architecting
architecture specification
engineerible requirements
Capability
Capability
Architecture
Architecture
Capability Development
Capability Development
Analysis
of Function
Capability
Capability
Engineering
Capability Employment
Capability Employment
representations of economically
producible components that can be
assembled to construct the functional whole
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 22
23. Architecting is a Multiple Domain Discipline
Capability Architecting
Enterprise Architecting
In capability architecting the architect
applies architecting principles and
practices to translate capability needs
into enterprise engineering
requirements
In enterprise architecting the architect
applies architecting principles and
practices to plan the alignment of IT
resources with corporate strategy
Core Principles and Practices
of Architecting
Operational Architecting
Systems Architecting
In operational architecting the architect
applies architecting principles and
practices to select and integrate
operational resources into an effective
mission focused structure
In systems architecting the architect
applies architecting principles and
practices to allocate engineering
requirements to system/product
components
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 23
24. DoD Architects Practice in Multiple Domains
Desired Effects
(conflict, market, social, other)
Capability
Concept
“Planner’s
View”
Capability Planning
Capability
Need
“Architect’s
View”
Capability Architecting
Capability
Architecture
“Builder’s
View”
Capability Development
Capability
“Operator’s
View”
Enterprise
Architecting
Capability Expression
System
Architecting
“Strategist’s
View”
Capability Employment
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 24
26. 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
outcomes
From: Huffman, Dr. S.D. Improving Acquisition Program
Performance: The “Architect” Role. 23 January 2006
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 26
27. Description Gap Leads to Requirements Failure
Desired Effects
(conflict, market, social, other)
“Strategist’s
View”
Capability Expression
Doctrine,
CONOPS
Capability
Concept
“Planner’s
View”
Capability Planning
Capability
Need
JCIDS
Description
Gap
Engineerible
Requirements
“Builder’s
View”
Capability Development
Capability
“Operator’s
View”
Capability Employment
DoD 5000*
* 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.
Warfighting
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 27
28. … And Requirements Failure Cascades Through
the Capabilities-to-Systems Value Chain
Desired Effects
(conflict, market, social, other)
“Strategist’s
Capability Expression
View”
Inadequate translation of capability need
Doctrine,
CONOPS
Capability
into engineering requirements results in …
Concept
“Planner’s
Capability Planning
View” Poor initial requirements baseline which
Capability
cascades through systems development
Need
and ultimately results in …
“Builder’s
View”
JCIDS
Description
Gap
Engineerible
Inadequate linkage of requirements to
Requirements
developed system which results in …
DoD 5000
Capability Development
“Operator’s
View”
Inability to validate resulting system against
Capability
original need
Capability Employment
Warfighting
Achieved Effects
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 28
29. 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 wellformed architecture description from which all other
descriptions are iteratively developed.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 29
30. Architecture Specification Establishes
the 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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability
Development
Document
Architecture
Specification
Engineering Baseline
System Requirements Review (SRR)
MS B
Functional
Specification
Functional Baseline
System Functional Review (SFR)
Item
Specifications
Allocated Baseline
Preliminary (PDR) and Critical
Design (CDR) Reviews
Product
Specifications
System Development and
Demonstration Phase
►
Product Baseline
MS C
5/1/2009 - 30
31. Functional Specification Establishes
the 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
Functional Specification translates a systemlevel ―black box‖ design into a first level
system design consisting of functional
elements that achieve system behavior and
performance.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Capability
Development
Document
Architecture
Specification
Engineering Baseline
System Requirements Review (SRR)
MS B
Functional
Specification
Functional Baseline
System Functional Review (SFR)
Item
Specifications
Allocated Baseline
Preliminary (PDR) and Critical
Design (CDR) Reviews
Product
Specifications
System Development and
Demonstration Phase
►
Product Baseline
MS C
5/1/2009 - 31
32. Traditional Systems Architecting
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.
Requirements
The Role of Systems
Architecting within
Systems Engineering
Requirements
Engineering
Functional
Allocation
System
Systems Engineering
and
Development Process
System Demo
& Validation
System Integ
& Test
Component
Development
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?
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 32
33. First Real “System Architecture” Emerges
at 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
Capability
Development
Document
Architecture
Specification
Engineering Baseline
System Requirements Review (SRR)
MS B
Functional
Specification
Functional Baseline
System Functional Review (SFR)
Item
Specifications
Allocated Baseline
Preliminary (PDR) and Critical
Design (CDR) Reviews
Product
Specifications
System Development and
Demonstration Phase
►
Product Baseline
MS C
Allocated Baseline translates an abstract
functional design into producible physical
components.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 33
34. 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‖
Capability
Development
Document
Architecture
Specification
Engineering Baseline
System Requirements Review (SRR)
MS B
Functional
Specification
Functional Baseline
System Functional Review (SFR)
Product Baseline translates the
configuration tree into COTS, GOTS or
developmental item products.
Item
Specifications
Allocated Baseline
Preliminary (PDR) and Critical
Design (CDR) Reviews
Product
Specifications
System Development and
Demonstration Phase
►
Product Baseline
MS C
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 34
35. Thank you!!
Please contact me at:
Brad Mercer
Chief Architect
Naval C4I Systems
Maritime IT and Engineering
The MITRE Corporation
SPAWARSYSCEN SD
49185 Transmitter Road, Building 626
San Diego, CA 92152-7335
bmercer@mitre.org
619-758-7814
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 35
37. 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
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 design through Analysis
Engineers apply the process of design through quantitative analysis to
tradeoff conflicting requirements until an optimal solution is determined.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 37
38. 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 engineeringfocused designers are now
―architects‖? What happened
to real engineers and architects?
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 38
39. Architect n. a person who practices ―architecting‖
The Practice of Architecting
From 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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 39
40. 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.
boundary defined by the
architecture specification
one potential
implementation
a set of potential
implementations
―a solution space‖
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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 40
41. Engineerible Requirements as a Solution Space
Engineerible Requirements are the set of engineering requirements
necessary and sufficient to initiate the successful engineering and
production of a system
boundary defined by
engineerible requirements
one candidate
implementation
a set of candidate
implementations
―a solution space‖
Engineers apply the process of design through quantitative analysis to
tradeoff conflicting requirements until an optimal solution is determined.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 41
42. What does an Architecture Specification Include?
Part I - Architectural Context
An 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 Qualities
Since 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 Description
Most likely expressed as a set of patterns
– Standard Patterns
– Solution Specific Patterns
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
Part IV - Architectural Guidance
A set of principles, practices, and constraints guiding implementation, operation, and evolution
of the developed system
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 42
43. Some Principles of Architecture Specification
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.
►
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).
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 43
44. Art or Science?
Science noun
1. 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.
Art noun
From: ―science‖ The American Heritage® Dictionary of the English
Language, Fourth Edition. Houghton Mifflin Company, 2004.
1. 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.
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 44
45. Architectures within Architectures within …
►
Architecture n. (another definition) the highest level conceptualization 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!
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 45
46. DODAF and DoD Architecting
A Case Study in “Reality”
―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!
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.‖
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 46
47. What is the structure or form of a system?
Functional ―Structure‖
Architecture
INFORMATION
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)
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.
Information ―Structure‖
Architecture Description n. a representation of
an architecture; a conceptualization of the form of
a system.
Described using Information
Models (e.g. data models,
ontologies)
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 47
48. The Architect’s View
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.‖
Architect’s View
Conceptual Model
Conceptual Data Model
Logical Data Model
Physical Data Model
Implemented Database
The Model Stack
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
► ―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
data models do not represent the architect’s
view – they include too many non-architecture
artifacts
► Logical
► The
―Architect’s View‖ is expressed using a formal
conceptual model that provides a common set of
semantics for expressing that view
5/1/2009 - 48
50. 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
selects
Event1
Event11
Event
(Time)
controls
Conditions
groups
pli
s
es
es
t
r
ra
e
es
om
e
ne
ge
s m
sum
ac
c
Ways
c n
c on
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
s
p
ps
ou
ou
Means
e
ro c e
produc
g
gr
Resource
Resource
Effect n. a change to a condition,
behavior, or degree of freedom
─ From CJCSM 3500.04D, Universal
Joint Task List, 1 August 2005
Function
Function
he
s
Location
Node
Node
Standards
Rule
Rule
Product
Product
Products and Events are not the actual
effects achieved by a capability. The
effect is achieved indirectly as
a change in state in response
Event
to the products and events.
Event2
Event
2
(Time) 2
―Effect‖
5/1/2009 - 50
51. A Few Simple Principles
Words Mean
Things!!
One Aspect
at a Time!!
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Foundation
Before Structure!!
5/1/2009 - 51
52. Words Mean Things!!
A community of discussion
must include all of the concepts
necessary to describe its
domain and there must be no
inconsistencies between the
concepts.
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).
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
Tower of Babel
5/1/2009 - 52
53. 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.
Self-Operating Napkin by Rube Goldberg
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
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 53
54. Foundation Before Structure!!
Structure is not a substitute
for 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
Copyright ©2009 The MITRE Corporation. All Rights Reserved.
5/1/2009 - 54