Thoughts on Architecting v4.3

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.

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 - 2

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 - 3

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

5/1/2009 - 4

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
(Othe rs )
5

Pro v ide /Pub lis h
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
(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

5/1/2009 - 5

In Reality … Dealing with Complexity Today

100s Actors / 100s Activities / 1000s Relationships / 10s Shared Information Spaces

5/1/2009 - 6

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


5/1/2009 - 7

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 - 8

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!


5/1/2009 - 9

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!

5/1/2009 - 10

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!

Bad Architecting Rule #1
―Don‘t ever let reality
get in the way of your
view of reality!‖
5/1/2009 - 11

Architecting and Engineering
Two Sides of the Same Problem


5/1/2009 - 12

─ 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‖


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

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

5/1/2009 - 14

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.

5/1/2009 - 15

─ Two Sides of the Same Problem

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

5/1/2009 - 16

From Capabilities to Systems
The Role of the Architect in DoD


5/1/2009 - 17

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.

5/1/2009 - 18

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


5/1/2009 - 19

There is a Significant Missing Link
in DoD’s Capability Value Chain!!
Desired Effects

“Strategist’s
View”


Doctrine,
CONOPS

Capability
Concept

“Planner’s
View”

Capability Planning
Capability
Need

JCIDS

Description
Gap

Engineerible
Requirements

“Builder’s
View”

Capability

“Operator’s
View”


DoD 5000*
components of a capability. In addition to materiel,
capability development should consider the range
of DOTMLPF solution components.

Warfighting

Achieved Effects

5/1/2009 - 20

Architecting is the Discipline
that Bridges the Description Gap
Desired Effects

“Strategist’s
View”


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

“Operator’s
View”


DoD 5000*
components of a capability. In addition to
materiel, capability development should consider
the range of DOTMLPF solution components.

Warfighting

Achieved Effects

5/1/2009 - 21

Architecting is the Discipline
that Bridges the Description Gap
Desired Effects


Capability
Capability
Concept
Concept

Architecting

Capability Planning
Capability Planning

Synthesis
of Form

Capability
Capability
Need
Need


Capability
Capability
Architecture
Architecture


Analysis
of Function

Capability
Capability

Engineering



Achieved Effects


5/1/2009 - 22

Architecting is a Multiple Domain Discipline

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
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
practices to select and integrate
operational resources into an effective
mission focused structure

In systems architecting the architect
practices to allocate engineering
requirements to system/product
components


5/1/2009 - 23

DoD Architects Practice in Multiple Domains
Desired Effects

Capability
Concept

“Planner’s
View”

Capability Planning
Capability
Need

“Architect’s
View”

Capability
Architecture

“Builder’s
View”

Capability

“Operator’s
View”

Enterprise
Architecting


System
Architecting

“Strategist’s
View”

Achieved Effects


5/1/2009 - 24

Architecture-Driven Systems Development
The Role of Architecture Throughout Systems Development


5/1/2009 - 25

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

5/1/2009 - 26

Description Gap Leads to Requirements Failure
Desired Effects

“Strategist’s
View”


Doctrine,
CONOPS

Capability
Concept

“Planner’s
View”

Capability Planning
Capability
Need

JCIDS

Description
Gap

Engineerible
Requirements

“Builder’s
View”

Capability

“Operator’s
View”


DoD 5000*
components of a capability. In addition to
materiel, capability development should consider
the range of DOTMLPF solution components.

Warfighting

Achieved Effects

5/1/2009 - 27

… And Requirements Failure Cascades Through
the Capabilities-to-Systems Value Chain
Desired Effects

“Strategist’s
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

“Operator’s
View”

Inability to validate resulting system against
Capability
original need


Warfighting

Achieved Effects

5/1/2009 - 28

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.


5/1/2009 - 29

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.

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

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.

Capability
Development
Document

Architecture
Specification

MS B
Functional
Specification

Functional Baseline

Item
Specifications

Allocated Baseline

Product
Specifications

Demonstration Phase

►

Product Baseline
MS C

5/1/2009 - 31

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?

5/1/2009 - 32

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

MS B
Functional
Specification

Functional Baseline

Item
Specifications

Allocated Baseline

Product
Specifications

Demonstration Phase

►

Product Baseline
MS C

Allocated Baseline translates an abstract
functional design into producible physical
components.

5/1/2009 - 33

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

MS B
Functional
Specification

Functional Baseline

Product Baseline translates the
configuration tree into COTS, GOTS or
developmental item products.

Item
Specifications

Allocated Baseline

Product
Specifications

Demonstration Phase

►

Product Baseline
MS C


5/1/2009 - 34

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


5/1/2009 - 35

Additional Slides


5/1/2009 - 36

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.

5/1/2009 - 37

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?


5/1/2009 - 38

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.


5/1/2009 - 39

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
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.

5/1/2009 - 40

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
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.

5/1/2009 - 41

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

5/1/2009 - 42

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


5/1/2009 - 43

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.

5/1/2009 - 44

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!


5/1/2009 - 45

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.‖

5/1/2009 - 46

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)


5/1/2009 - 47

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

► ―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

Architecture Semantics
When?

Event
selects

Where?

How?
groups

Function

Location

controls

Rule
Why?

Resource
Who?

Product

What?
5/1/2009 - 49

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


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

A Few Simple Principles
Words Mean
Things!!
One Aspect
at a Time!!


Foundation
Before Structure!!

5/1/2009 - 51

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


Tower of Babel

5/1/2009 - 52

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

5/1/2009 - 53

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


5/1/2009 - 54

Thoughts on Architecting v4.3

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Thoughts on Architecting v4.3

Ähnlich wie Thoughts on Architecting v4.3 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Thoughts on Architecting v4.3