FEA and DoDAF - iceaaonline.com FEA and DODAF to Support Cost Modeling. Andreas Tolk . Johnny Garcia, Holly Handley, Chuck Keating, Resit Unal. Old Dominion University, Norfolk, VA

Extending FEA and DODAF to Support Cost Modeling

Andreas Tolk Johnny Garcia, Holly Handley, Chuck Keating, Resit UnalOld Dominion University, Norfolk, VA 23529

Virginia Modeling Analysis and Simulation Center

Presented at the 2011 ISPA/SCEA Joint Annual Conference and Training Workshop - www.iceaaonline.com

© 2011 ODU

Discussion Points

Frameworks, Architectures, Designs, and Solutions– What is an Architecture?– Where are the costs?

Federal Enterprise Architecture (FEA) and the Department of Defense Architecture Framework (DoDAF)

– Enterprise Capabilities and System Functionalities– Define future systems and their interplay with current solutions to close capability

gaps with fit for purpose solutionsCurrent Research at Old Dominion University

– Assigning cost to operational functions over the life cycle in the desired resolution– Extending FEA and DODAF into executable architectures that can be embedded into

an operationally validated executable context

2


© 2011 ODU

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.[ANSI/IEEE 1471-2000]

An architecture describes the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated characteristics and behavior.[OPEN Process Framework (OPF) Repository]

A formal description of a system, or a detailed plan of the system at component level to guide its implementation. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.[TOGAF]

3

What is an Architecture

Framework

Architecture

Design

Solution


© 2011 ODU4

Interrogatives

EnterpriseEnterprise& Systems& Systems

Why

Who What

Where

WhenHow


© 2011 ODU5

John A. Zachman, Zachman International

DATA Implementation

DATAWhat

FUNCTIONHow

NETWORKWhere

e.g. D ata Definiti on

Entity = FieldRel. = Address

e.g., Physical Data Model

Entity = Tables/Segments /etc.Rel. = Key/Pointer/etc.

e.g., Logical D ata Model

Entity = Data EntityRel. = Data R elati onship

e.g., Sem antic Model

Entity = Business EntityRel. = Business Rel ationshi p

List of Things -Important to the Business

Entity = Class ofBusiness Thing

List of Processes -the Business Performs

Function = Class ofBusiness Process

e.g., Applicati on Architecture

Process.= Application Func tionI/O = User Viewse.g., System Design

Process= Computer F uncti onI/O =Data Elements/Sets

e.g. Progr am

Process= Language StatementI/O = Contr ol Block

FUNCTIONImplementation

e.g., Busi ness Process Model

Process = Business ProcessI/O = Busi ness R esources

List of Locations -in which the Busi ness Operates

Node = Maj or BusinessLocation

e.g., Logistics Network

Node = Business Location Link = Business Linkage

e.g., Distributed SystemArchitecture

Node = IS FunctionLink = Li ne C haracteristicse.g., Technical Architecture

Node = H ardware/SystemSoftw are

Link = Li ne Specifications

e.g. Network Architecture

Node = AddressesLink = Protocols

NETWORKImplementation

MOTIVATIONWhy

TIMEWhen

PEOPLEWho

e.g. R ule Specification

End = Sub-conditionMeans = Step

e.g., Rule D esign

End = C onditionMeans = Ac tion

e.g., Busi ness R ule Model

End = Structural AssertionMeans =Acti on Assertion

End = Business ObjectiveMeans = Business Str ategy

List of Busi ness Goals and Strategi es

Ends/M eans=Major Busi nessGoal/Critical Success Factor

List of Events -Significant to the Busi ness

Time = Major Business Event

e.g., Processing Structure

Time = System EventCycle = Processing Cycle

e.g., Control Struc ture

Time = ExecuteCycle = Component Cycle

e.g. Timing Defi nition

Time = InterruptCycle = Machine Cycle

SCHEDULEImplementation

e.g., Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizati ons -Important to the Business

People = Class of People andMajor Organizations

e.g., Work Flow Model

People = Organization UnitWork = Work Product

e.g., Human InterfaceArchitecture

People = Rol eWork = Deliverablee.g., Presentation Architecture

People = UserWork = Screen/D evice Format

e.g. Security Architectur e

People = IdentityWork = Job

ORGANIZATIONImplementation

STRATEGYImplementation

e.g., Busi ness Plan

SCOPEPlanner

SYSTEM MODELDesigner

TECHNOLOGYCONSTRAINED

MODELBuilder

DETAILEDREPRESEN-

TATIONSSubcontractor

ENTERPRISE MODEL

Owner

contextual

conceptual

logical

physical

out-of-context

FUNCTIONINGENTERPRISE

perspectivesabstractions

John A. Zachman, Zachman International

DATA Implementation

DATAWhat

FUNCTIONHow

NETWORKWhere

e.g. D ata Definiti on

Entity = FieldRel. = Address

e.g., Physical Data Model

Entity = Tables/Segments /etc.Rel. = Key/Pointer/etc.

e.g., Logical D ata Model

Entity = Data EntityRel. = Data R elati onship

e.g., Sem antic Model

Entity = Business EntityRel. = Business Rel ationshi p

List of Things -Important to the Business

Entity = Class ofBusiness Thing

List of Processes -the Business Performs

Function = Class ofBusiness Process

e.g., Applicati on Architecture

Process.= Application Func tionI/O = User Viewse.g., System Design

Process= Computer F uncti onI/O =Data Elements/Sets

e.g. Progr am

Process= Language StatementI/O = Contr ol Block

FUNCTIONImplementation

e.g., Busi ness Process Model

Process = Business ProcessI/O = Busi ness R esources

List of Locations -in which the Busi ness Operates

Node = Maj or BusinessLocation

e.g., Logistics Network

Node = Business Location Link = Business Linkage

e.g., Distributed SystemArchitecture

Node = IS FunctionLink = Li ne C haracteristicse.g., Technical Architecture

Node = H ardware/SystemSoftw are

Link = Li ne Specifications

e.g. Network Architecture

Node = AddressesLink = Protocols

NETWORKImplementation

MOTIVATIONWhy

TIMEWhen

PEOPLEWho

e.g. R ule Specification

End = Sub-conditionMeans = Step

e.g., Rule D esign

End = C onditionMeans = Ac tion

e.g., Busi ness R ule Model

End = Structural AssertionMeans =Acti on Assertion

End = Business ObjectiveMeans = Business Str ategy

List of Busi ness Goals and Strategi es

Ends/M eans=Major Busi nessGoal/Critical Success Factor

List of Events -Significant to the Busi ness

Time = Major Business Event

e.g., Processing Structure

Time = System EventCycle = Processing Cycle

e.g., Control Struc ture

Time = ExecuteCycle = Component Cycle

e.g. Timing Defi nition

Time = InterruptCycle = Machine Cycle

SCHEDULEImplementation

e.g., Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizati ons -Important to the Business

People = Class of People andMajor Organizations

e.g., Work Flow Model

People = Organization UnitWork = Work Product

e.g., Human InterfaceArchitecture

People = Rol eWork = Deliverablee.g., Presentation Architecture

People = UserWork = Screen/D evice Format

e.g. Security Architectur e

People = IdentityWork = Job

ORGANIZATIONImplementation

STRATEGYImplementation

e.g., Busi ness Plan

SCOPEPlanner

SYSTEM MODELDesigner

TECHNOLOGYCONSTRAINED

MODELBuilder

DETAILEDREPRESEN-

TATIONSSubcontractor

ENTERPRISE MODEL

Owner

contextual

conceptual

logical

physical

out-of-context

FUNCTIONINGENTERPRISE

perspectivesabstractions

But where are the costs?


© 2011 ODU

TAGGING FUNCTIONS WITH ASSIGNED COSTS

Research Effort Category One

6


© 2011 ODU

FEA and DODAF

Federal Enterprise Architecture (FEA)

Business and operational modelSets strategic goalsDefines capability needsConstraints the portfolioAgile and in flux

DoD Architecture Framework (DODAF)

Operational-tactical systemsDefines the systems to accomplish the goalsDefines the functionality to provide capabilitiesSystem architectures over the whole life cycle

7


© 2011 ODU

Organization Master Plan

System Master Plan

Enterprise and System Architectures

• An Enterprise Architecture (EA) Framework describes or prescribes the overall style and structure of an enterprise or organization. It is a blueprint for the organization.

It includes the functional components (operational view), the applications or systems that make up the organization (systems view), and enabling technology and standards (technical view).

• A System Architecture describes or prescribes the overall style and structure of a particular system or application within that organization that supports it in accomplishing its goals or mission.

This architecture is in accordance with the enterprise architecture framework, and constrains and shapes the detailed design of the system needed to realize it.


© 2011 ODU9

Federal Enterprise Architecture Framework


© 2011 ODU10

DoD Architecture Framework 2.0

DoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries.

Support the Department’s core processes:1.Joint Capabilities Integration and Development (JCIDS)2.Planning, Programming, Budgeting, and Execution (PPBE)3.DoD Acquisition System (DAS)4.Systems Engineering (SE)5.Operations Planning6.Capabilities Portfolio Management (CPM)


© 2011 ODU

DoDAF Evolution To Support “Fit For Purpose” Architecture

(Published in 2003)

(Published in 2007)

DoDAF 1.5• Addresses Net-Centricity • Volume III is CADM & Architecture Data Strategy• Addresses Architecture Federation• Baseline for DoDAF 2.0• Shifted away from DoDAF mandating

a set of products

DoDAF 2.0• Cover Enterprise and Program

Architecture• Emphasize Data versus Products• Tailored Presentation• AV-1 to capture federation metadata• Quality Support to Decision

Processes• FEA & Allied/Coalition Support• Journal: Errata & Interim Releases

DoDAF 1.0• CADM Separate• Baseline For DoDAF 1.5• Removed Essential & Supporting Designations• Expanded audience to all of DoD

(Published in 2009)


© 2011 ODU

Viewpoints That Fit-the-Purpose

All View

pointO

verarching aspects of architecture context that relate to all models

Data and Inform

ation Viewpoint

Articulate the data relationships and alignm

ent structures in the architecture content

Standards Viewpoint

Articulate applicable O

perational, Business, Technical, and Industry

policy, standards, guidance, constraints, and forecasts

Systems ViewpointArticulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD

functions

Services Viewpoint Articulate the performers, activities, services,

and their exchanges providing for, or supporting, DoD functions

Operational ViewpointArticulate operational scenarios, processes,

activities & requirements

Capability Viewpoint Articulate the capability requirement, delivery

timing, and deployed capability

Project Viewpoint

Describes the relationships betw

een operational and capability requirem

ents and the various projects being implem

ented; Details

dependencies between capability m

anagement and the D

efense A

cquisition System

process.


© 2011 ODU13

Data Driven Perspective


© 2011 ODU14


© 2011 ODU15


© 2011 ODU16

Capabilities Serv ices

P roj ec ts

Perform ersObj ec t Exchanges

RulesM easures

acco rd ing -to acco rd ing -toto -m ee t

m ee t

sa ti sfy fo l low

lead -to lead -to

m ee t com p ly-wi th

resu l t-inresu l t-in

conduct

T y p eC a p a b i l i ty

T e mp o ra l T y p eE ffe c t

T e mp o ra l T y p eC a p a b i l i ty C o n fi g u r a t io n

T y p eM e a s u re

T e mp o ra l T y p eC o n d i t io n

P e rfo rm e rO r g a n iz a tio n

E x c h a n g e O b je c tM a te r ie l

T e mp o ra l T y p eS k i l l

E x c h a n g e O b je c tP e rfo rme r

P e r s o n n e lTy p e

In te r fa c e T y p eT e mp o ra l T y p eA c tiv i ty

T e mp o ra l T y p eR e a l P r o p e r ty

P e rfo rme rS y s te m

re a l i z e s

1 . . *

i s-p a r t -o f

0 . . *

i s-a -p a r t -o f

0 . . *

i s-a -p a rt -o f

i s-a -p a rt -o f

0 . . *

i s-a -p a rt -o f

0 . . *

i s-a -p a rt -o f

0 . . *

re su l t s-i n

0 . . *

0 . . *i s-a -p a rt -o f

0 . . *a p p l i e s- to

0 . . *

1 . . *i s-p e rfo rm e d -u n d e r

Temp ora l Typ eE ffec t

Typ eM e as ure

Te mpo ra lTypeCondition

O rganiza tion

E xcha ng eO bje ctM ate rie l

Te mpo ra lTypeS kill

E xch an ge Ob jectP ersonne lType

In te rfa ce Typ eTe mpo ra lTyp eAc tiv ity

Temp o ra l Typ eRe alP roperty

S ys tem

S erv ic eRe quire me nt

S e rv ice Im plem e ntation

Ru leS ta ndard

Pe rfo rme rS ta teP e rform e r

S oftw areS e rv ic e

i s-a-pa rt-o f

0 ..*

resu l ts-i n

0 ..*

0 ..*

ap p l ies-to 0..*

0 ..*

p erform s1..*i s-p e rfo rm ed -b y

P erfo rmerS ta teP erform er

Te mpora lTypeE xc hangeO bj ec t

Data

M aterie l

Informa tion

In te rfaceTyp eTempo ra lTyp e

Activ ity

Ru leS tandard

acco rd ing -to

P ersonne lType

1 ..*

i s-pe rfo rm ed-by

0 ..*

pe rfo rm s

0 ..*

i s-p ro duced -by

0 ..*

0 ..*

i s-consum ed-by0 ..*

i s-a -p a rt-o f

E v ent

TypeV is ion

Tempora lTypeProj ec t

Tempora lTypeG oa l

Cost

P lan

Ru leM eans

In te rfaceTypeTempora lType

Activ ity

Tempora lTypeCondition

Tempora lTypeP erform erSta te

Tempora lTypeE ffec t

TypeM easure

1 ..*

i n i t ia tes-stim u la tes

0 ..*

i s-rea l i zed -by

0 ..*

d i rects

0 ..*

1 ..*

is-rea l ized -by

i n i t ia tesis-necessa ry-fo r

0 ..*

seeksChangeT o

1 ..*

0 ..*

changes1 ..*

0 ..*

resu l ts-i n0 ..*

0 ..*

app l ies-to

0 ..*

TypeRule

S tandard

Agreem ent

Functiona lStandard Technica lS tandard

G uidance

Constra int

Tempora lTypeCondition

M eans

UCO RE IC-IS M -v 2 ::SecurityAttributesGroup

0 ..*

i s-va l id -unde r

1..*

Cost

TypeBase line ::M easure

Tim e liness

RateThroughput

Capac ity

AccuracyPrec is ion

Dependability

NeedsSatis fac tionM eas ure

Perform anceM easure

M a inta inabilityM easure

AdaptabilityM eas ure

O rganiza tiona lM easure

Inte roperability

Trus tw orthiness

Re liability

Security

P erform er

Exch an geO bjectPe rs onne lType

Syste m

Softw a re Serv ic eOrganization

Temp ora lTyp eSk ill

E xcha nge Ob je ctM ate rie l

In te rfa ce TypeTe mpo ra lType

Activ ity

RuleS ta ndard

Te mp ora lTypeNetw ork

Tempo ra lTypePerform erSta te

acco rd ing -to

Ab stractFea tu reType

G eoFea ture

Loc ation

1..*

is-pe rfo rm ed-b y

i s-a -p art-o f

0 ..*

p erfo rm s

is a t

2 ..*

i s-part-o f

Conceptual View on the DODAF Metamodel

Costs


© 2011 ODU

FEA defines the operational constraints, including length of life cycles, likelihood of operations, etc.DODAF defines portfolios of systems that provide the functions delivering the capabilitiesOperational need and engineering means are captured in mapped data elementsDODAF allows and encourages the definition of metrics to be associated with all activities

17

Summary Research Effort One

We can define costs for all activities and use them as metrics in DoDAF!This allows to not only evaluate for operational efficiency,

But also for budgetary implications of applying the system!

We can define costs for all activities and use them as metrics in DoDAF!This allows to not only evaluate for operational efficiency,

But also for budgetary implications of applying the system!


© 2011 ODU

EXECUTING ARCHITECTURES IN OPERATIONAL CONTEXTS

Research Effort Category Two

18


© 2011 ODU

So far, we have the cost of each function in the blueprint as the metricsExecuting the architecture allows to “sum the individual costs up”Executing the architecture in the operational context given by FEA allows to realistically evaluate the costs for the system

19

Executable Architectures


© 2011 ODU

Why Executable Context?

Current State of the Art– Static Measures support WHO, WHAT, WHERE– Executable Architecture support WHEN– Open question: WHY and HOW

System will interact with other (external) system in the context of the operation

– Metrics to measure the success of an operation– Metrics to measure the contribution of the system– Effectiveness and Efficiency based on operational means need to be part of the V&V


© 2011 ODU

Executable Architecture & Context


© 2011 ODU

Several system architectures (of systems under development) can be taken into accountFEA sets parameters for scenarios, DODAF sets cost parameters for the system functionsWork can be enriched by validated M&S systems embedding the executable systemsPhD research of Johnny J. Garcia (SimIS, Inc) did set the frame for this research efforts

22

Summary Research Effort Two

By executing the Augmented DODAF Architecture in FEA Defined Contexts,we can generate realistic costs in the context of desired scenarios.

Life cycle can take more constraints into consideration.

By executing the Augmented DODAF Architecture in FEA Defined Contexts,we can generate realistic costs in the context of desired scenarios.

Life cycle can take more constraints into consideration.


© 2011 ODU

Enrich DODAF (DM2) with cost data for functionsEnrich operational evaluation with cost evaluationWhat-if analysis possible– Constraint function by budgets– Optimize operational effectiveness with given budget– Show effect of budget costs

FEA and DODAF and Cost Estimation can be synchronized!

23

Action Items


Documents

FEA and DoDAF - iceaaonline.com FEA and DODAF to Support Cost Modeling. Andreas Tolk . Johnny Garcia, Holly Handley, Chuck Keating, Resit Unal. Old Dominion University, Norfolk, VA