thoughts on architecting v4.3

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.


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


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!


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


(Highe r HQ)5


(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


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


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


In Reality … Dealing with Complexity Today

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


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



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.


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!


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



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”


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



Analysisof Function

iteratively decompose andseparate a primarily functional

representation of a whole

Engineering


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


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.


Architecting and Engineering─ Two Sides of the Same Problem

architecture specification

engineerible requirements




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



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


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.


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.





Achieved Effects

There is a Significant Missing Linkin DoD’s Capability Value Chain!!

EngineeribleRequirementsEngineerible

Requirements





DoD 5000*

JCIDS

Doctrine,CONOPS

Warfighting




CapabilityConcept

CapabilityConcept

CapabilityNeed

CapabilityNeed


DescriptionGap





Achieved Effects

Architecting is the Disciplinethat Bridges the Description Gap

Capability ArchitectingCapability Architecting

CapabilityArchitectureCapability

Architecture“Builder’s

View”

“Architect’sView”




DoD 5000*

ArchitectureSpecification

JCIDS

Doctrine,CONOPS

Warfighting




CapabilityConcept

CapabilityConcept

CapabilityNeed

CapabilityNeed



Architecting is the Disciplinethat Bridges the Description Gap

architecture specification

engineerible requirements




Analysisof Function

Synthesisof Form

Engineering

Architecting




Achieved Effects




Achieved Effects



Architecture



Architecture




CapabilityConcept

CapabilityConcept

CapabilityNeed

CapabilityNeed




CapabilityConcept

CapabilityConcept

CapabilityNeed

CapabilityNeed


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





Achieved Effects

DoD Architects Practice in Multiple Domains



Architecture“Builder’s

View”

“Architect’sView”







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



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





Achieved Effects

Description Gap Leads to Requirements Failure


Requirements





DoD 5000*

JCIDS

Doctrine,CONOPS

Warfighting




CapabilityConcept

CapabilityConcept

CapabilityNeed

CapabilityNeed


DescriptionGap

Issue #1 – Inadequate translation of capability need into

engineering requirements leads to requirements failure


DoD 5000




Achieved Effects

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


Requirements





JCIDS

Doctrine,CONOPS

Warfighting




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 …


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.


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


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


Functional Baseline

Allocated Baseline

Product Baseline

ItemSpecifications




Document

MS B



MS C

Sy

ste

m D

ev

elo

pm

en

t a

nd

De

mo

ns

tra

tio

n P

ha

se


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.


Traditional Systems Architecting

ComponentDevelopmentComponent

Development





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.


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


Functional Baseline

Allocated Baseline

Product Baseline

ItemSpecifications




Document

MS B



MS C

Sy

ste

m D

ev

elo

pm

en

t a

nd

De

mo

ns

tra

tio

n P

ha

se


Allocated Baseline translates an abstract functional design into producible physical

components.


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


Functional Baseline

Allocated Baseline

Product Baseline

ItemSpecifications




Document

MS B



MS C

Sy

ste

m D

ev

elo

pm

en

t a

nd

De

mo

ns

tra

tio

n P

ha

se


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

[email protected]

619-758-7814


Additional Slides



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.


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.


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.



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




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


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


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.


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.


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


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!


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.




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


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


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)


A Few Simple Principles

FoundationBefore Structure!!

Words MeanThings!!

One Aspectat a Time!!


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


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


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

thoughts on architecting v4.3

Technology

s e ts

e r onment c e ol nvi

fe ns e ag e nc

e rc ia

r r uppl oe equestoth

ide pub lis hoth e r

ap prov e d orde rs

tion othe rs