11 September DM2 TWG Agenda - silverbulletinc.com€¦ · PPT file · Web viewDraft DODI 8320.02-M...

107
1 Oct 2010 DoDAF - DM2 WG Agenda Announcements: This week: DM2 PES Submission to DISR Federal arch F/W Upcoming: IS&T NR-KPP WG Oct 4-6 FAC 5 Oct NCOIC Plenary next week New References: Others? ARO and Joint Action (Benfield) DoDAF Model (View) Names and One- Liner Consistency Suggestions, AI # 579 Systems vs Services, Performers vs. Systems, etc. – definitions, inter- relationships, structural distinctions, e.g., AI # 398 Prioritization for 2.03 SoA Consolidation -- Ellis Others: Capability model (Terebesi) Naming pattern, System meaning inputs – Alex Partitions – optional or mandatory? CV-6 contained in all other CV’s (briefed but no AI yet) What is a Service Port? THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING! DM2 DoDAF COI In Ver2.02 28 27 1 0 In Progress for2.02 1 0 1 0 In Progress for2.03 53 49 3 1 U nassigned 101 69 32 0 C onsultID EAS G roup 15 14 1 0 Defer 92 84 5 3 Rejected 0 0 0 0 N o Action R equired 0 0 0 0 290 290 CI

Transcript of 11 September DM2 TWG Agenda - silverbulletinc.com€¦ · PPT file · Web viewDraft DODI 8320.02-M...

1 Oct 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• DM2 PES Submission to DISR• Federal arch F/W

– Upcoming:• IS&T NR-KPP WG Oct 4-6• FAC 5 Oct• NCOIC Plenary next week

– New References: – Others?

• ARO and Joint Action (Benfield)• DoDAF Model (View) Names and One-Liner

Consistency Suggestions, AI # 579• Systems vs Services, Performers vs. Systems,

etc. – definitions, inter-relationships, structural distinctions, e.g., AI # 398

• Prioritization for 2.03– SoA Consolidation -- Ellis

• Others:– Capability model (Terebesi)– Naming pattern, System meaning inputs – Alex– Partitions – optional or mandatory?– CV-6 contained in all other CV’s (briefed but no AI

yet)– What is a Service Port?

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 28 27 1 0

In Progress for 2.02 1 0 1 0In Progress for 2.03 53 49 3 1

Unassigned 101 69 32 0Consult IDEAS Group 15 14 1 0

Defer 92 84 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0290 290

CI

http://en.wikipedia.org/wiki/Relation_reduction Relation Reduction of 3-adic to 2-adic examples.DM2 Use-CaseLet Ap={a1,a3}, and Ac={a2,a4} where each ap in Ap is a producing Activity and each ac in Ac is a consuming Activity. Let R = {r1 } where each r in R is a Resource.Let an ActivityResourceFlowSet be defined as some subset, ARFS= {(ap,r,ac)| The activity ap produces a resource r consumed by activity ac}, of Ap x R x Ac.Consider the following graphs and the corresponding ActivityResourceFlowSets.Graph 1

ActivityResourceFlowSet1 = {(1,r1,2),(3,r1,4)}Table 1 Table form of ARFS1

ap r ac

1 r1 2

3 r1 4

Graph 2

ActivityResourceFlowSet2 = {(1,r1,4),(3,r1,2)}Table 2 Table form of ARFS2

ap r ac

1 r1 4

3 r1 2

“A 2-adic projection of a 3-adic relation L is the 2-adic relation that results from deleting one column of the table for L and then deleting all but one row of any resulting rows that happen to be identical in content. In other words, the multiplicity of any repeated row is ignored.”-Wikipedia Definition

Consider the following partial 2-adic projective reductions of ActiviytResourceFlowSet1 and ActivityResourceFlowSet2. Set of ActivityProducesResource = Projap,r(ActiviytResourceFlowSet1) = {(1,r1),(3,r1)} = Projap,r(ActiviytResourceFlowSet2).

Table 3 proj_apr(ARFS1)

ap

r

1 r1

3 r1

Table 4 proj_apr(ARFS2)

ap

r

1 r1

3 r1

Set of ActivityConsumesResource = Projr,ac(ActivityResourceFlowSet1)={(r1,2),(r1,4)} = Projr,ac(ActivityResourceFlowSet2).Table 5 proj_rac(ARFS1)

rac

r1 2

r1 4

Table 6 proj_rac(ARFS2)

rac

r1 4

r1 2

Without considering Projap,ac(ActivityResourceFlowSet), ActivityResourceFlowSets may be projectively irreducible. That is, any graph that contains a sub-graph of the form of Graph 1 or 2, will be irreducible. If each ActivityResourceFlow to be reduced carries a unique Resource, the resulting ActivityResourceFlowSet can be reduced without ambiguity.

Joint Action: Fatma Selling Cup to Dave

Buyer(PersonType) Seller

(PersonType)

Fatma(Person)

typeInstance

TransferHandover

HandtakeDave(Person)

typeInstance

Transfer

Handtake

Handover

ActivityTypes

Cash (ResourceType) Cup (MaterielType)

time

Sendpart

Receivepart

Flow process

Dave

Ian

Dave

’s D

ocum

ent,

Orig

Dave’s Document, Copy 1, in flow state

Copy

Copy and SendDa

ve’s

Doc

umen

t, co

py 1

Dave

’s D

ocum

ent,

copy

1Dave’s Doc Ind Type = {Orig, Copy1, Copy2, …}

Dave’s Doc Ind Type Orig = {Orig}Dave’s Doc Ind Type Copies = {Copy1, Copy2, …}

Can go into very precise modeling using temporal parts (states)

time

579 Inconsistent Model DescriptionsPlease align model descriptions to

http://cio-nii.defense.gov/sites/dodaf20/models.html, with detailed content that futher describes the models, which is contained in the

hotlinks off of the "Models" page.

Models Descriptions

AV-1: Overview and Summary Information Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.

AV-2: Integrated Dictionary An architectural data repository with definitions of all terms used throughout the architectural data and presentations.

CV-1: Vision The overall vision for transformational endeavors, which provides a strategic context for the capabilities described and a high-level scope.

CV-2: Capability Taxonomy A hierarchy of capabilities which specifies all the capabilities that are referenced throughout one or more Architectural Descriptions.

CV-3: Capability Phasing The planned achievement of capability at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions.

CV-4: Capability Dependencies The dependencies between planned capabilities and the definition of logical groupings of capabilities.

CV-5: Capability to Organizational Development Mapping

The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase. The CV-5 shows the planned solution for the phase in terms of performers and locations and their associated concepts.

CV-6: Capability to Operational Activities Mapping A mapping between the capabilities required and the operational activities that those capabilities support.

CV-7: Capability to Services Mapping A mapping between the capabilities and the services that these capabilities enable.

DIV-1:Conceptual Data Model The required high-level data concepts and their relationships.

DIV-2: Logical Data Model The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7.

DIV-3: Physical Data Model The physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema. In DoDAF V1.5, this was the SV-11.

OV-1: High-Level Operational Concept Graphic The high-level graphical/textual description of the operational concept.

OV-2: Operational Resource Flow Description A description of the Resource Flows exchanged between operational activities.

OV-3: Operational Resource Flow Matrix A description of the resources exchanged and the relevant attributes of the exchanges.

OV-4: Organizational Relationships Chart The organizational context, role or other relationships among organizations.

OV-5a: Operational Activity Decomposition Tree The capabilities and activities (operational activities) organized in a hierarchal structure.

OV-5b: Operational Activity Model The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs; Additional data can show cost, performers, or other pertinent information.

OV-6a: Operational Rules Model One of three models used to describe activity (operational activity). It identifies business rules that constrain operations.

OV-6b: State Transition Description One of three models used to describe operational activity (activity). It identifies business process (activity) responses to events (usually, very short activities).

OV-6c: Event-Trace Description One of three models used to describe activity (operational activity). It traces actions in a scenario or sequence of events.

PV-1: Project Portfolio Relationships It describes the dependency relationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects.

PV-2: Project Timelines A timeline perspective on programs or projects, with the key milestones and interdependencies.

PV-3: Project to Capability Mapping A mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability.

SvcV-1 Services Context Description The identification of services, service items, and their interconnections.

SvcV-2 Services Resource Flow Description A description of Resource Flows exchanged between services.

SvcV-3a Systems-Services Matrix The relationships among or between systems and services in a given Architectural Description.

SvcV-3b Services-Services Matrix The relationships among services in a given Architectural Description. It can be designed to show relationships of interest, (e.g., service-type interfaces, planned vs. existing interfaces).

SvcV-4 Services Functionality Description The functions performed by services and the service data flows among service functions (activities).

SvcV-5 Operational Activity to Services Traceability Matrix A mapping of services (activities) back to operational activities (activities).

SvcV-6 Services Resource Flow Matrix It provides details of service Resource Flow elements being exchanged between services and the attributes of that exchange.

SvcV-7 Services Measures Matrix The measures (metrics) of Services Model elements for the appropriate time frame(s).

SvcV-8 Services Evolution Description The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation.

SvcV-9 Services Technology & Skills Forecast The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future service development.

SvcV-10a Services Rules Model One of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SvcV-10b Services State Transition Description One of three models used to describe service functionality. It identifies responses of services to events.

SvcV-10c Services Event-Trace Description One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint.

StdV-1 Standards Profile The listing of standards that apply to solution elements.

StdV-2 Standards Forecast The description of emerging standards and potential impact on current solution elements, within a set of time frames.

SV-1 Systems Interface Description The identification of systems, system items, and their interconnections.

SV-2 Systems Resource Flow Description A description of Resource Flows exchanged between systems.

SV-3 Systems-Systems Matrix The relationships among systems in a given Architectural Description. It can be designed to show relationships of interest, (e.g., system-type interfaces, planned vs. existing interfaces).

SV-4 Systems Functionality Description The functions (activities) performed by systems and the system data flows among system functions (activities).

SV-5a Operational Activity to Systems Function Traceability Matrix A mapping of system functions (activities) back to operational activities (activities).

SV-5b Operational Activity to Systems Traceability Matrix A mapping of systems back to capabilities or operational activities (activities).

SV-6 Systems Resource Flow Matrix Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange.

SV-7 Systems Measures Matrix The measures (metrics) of Systems Model elements for the appropriate timeframe(s).

SV-8 Systems Evolution Description The planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation.

SV-9 Systems Technology & Skills Forecast The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future system development.

SV-10a Systems Rules Model One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SV-10b Systems State Transition Description One of three models used to describe system functionality. It identifies responses of systems to events.

SV-10c Systems Event-Trace Description One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint.

398 SvcV vs SV It seems like the separation is contrived in many cases since the service is a mechism to access "capabilities", in many cases Systems.

24 Sept 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• IDEAS meeting in London last week• UPDM 2 meeting at OMG Tech Meeting • DM2 PES Submission to DISR• Federal arch F/W – Ellis. Okon working with.

– Upcoming:• IS&T NR-KPP WG Oct 4-6• FAC 5 Oct• NCOIC Plenary next week

– New References: – Others?

• Levels of DoDAF-DM2 Conformance going to FAC• DoDAF Model (View) issues plan for next week

– Many names are misleading and inconsistent with one-liner names. (AI # 579)

– The separation of SV’s and SvcV’s makes it unclear how Services provide access to Systems (AI # 398)

– CV-6 contained in all other CV’s (briefed but no AI yet)

• Prioritization for 2.03– SoA Consolidation -- Ellis

• Others:– ARO (Benfield)– Capability model (Terebesi)– Naming pattern, System meaning inputs – Alex– Partitions – optional or mandatory?– What is a Service Port?

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 28 27 1 0

In Progress for 2.02 1 0 1 0In Progress for 2.03 53 49 3 1

Unassigned 101 69 32 0Consult IDEAS Group 15 14 1 0

Defer 92 84 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0290 290

CI

New IDEAS Overlap Involves

Intersection

IDEAS Intersection

IntersectionIntersections are are the sets of relationships that relate overlapping things to their overlaps. An IntersectionOfSetOfOverlappingIndividuals is a set of wholePart relationships relating the overlapping Individuals to the overlap they form (itself also an Individual). An IntersectionOfSetOfOverlappingTypes is a set of superSubtype relationships relating the overlapping Types to the overlap they form (itself also a Type).

«IDEAS:Powertype»SuperSubtypeType

«IDEAS:Powertype»CoupleType

«IDEAS:Powertype»WholePartType

«IDEAS:Powertype»Indiv idualType

«IDEAS:Powertype»TupleType

«IDEAS:Type»PlaceableType

Thing

«IDEAS:Type»Type

«IDEAS:Type»SetOfOv erlappingThings

«IDEAS:Type»SetOfOv erlappingIndiv iduals

«IDEAS:Type»SetOfOv erlappingTypes

«IDEAS:Type»IntersectionOfSetOfOv erlappingThings

«IDEAS:Type»IntersectionOfSetOfOverlappingTypes

«IDEAS:Type»IntersectionOfSetOfOverlappingIndiv iduals

Examples : Intersection - Example

See also:

«IDEAS:Type»SingletonIndiv idualType

«IDEAS:Type»Singleton

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«place1Type»{subsets places}

«place2Type»{subsets places}

«IDEAS:superSubtype»

wholeType

«place1Type»

partType

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»*

places

«placeType»

2..*

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

overlappingPart

«place2Type»

«IDEAS:superSubtype»«IDEAS:

superSubtype»

«IDEAS:superSubtype»

Familiar to Rex

Example

IDEAS Intersection - Example

Type

«IDEAS:Type»SetOfOv erlappingThings

«IDEAS:Type»SetOfOv erlappingIndiv iduals

CoupleType

«IDEAS:Type»IntersectionOfSetOfOv erlappingThings

«IDEAS:Type»IntersectionOfSetOfOv erlappingIndiv iduals

«IDEAS:IndividualType»BordersOfFranceAndBelgiumOv erlap

The example below shows that the borders of France and Belgium overlap. Their intersection is an Individual (OverlapOfFRBorderAndBEBorder). The wholePart couples that relate them are members of the IntersectionsOfFrAndBe TupleType. Note that a Singleton has been created to act as the Type of the overlap Individual so as to keep the Type levels consistent.

SetOfProperOverlappingThings

«IDEAS:Type»SetOfProperOv erlappingIndiv iduals

«IDEAS:TupleType»IntersectionsOfFrAndBe

«IDEAS:Individual»EntireBorderOfBelgium

«IDEAS:Individual»EntireBorderOfFrance

Type

«IDEAS:Type»Singleton

«IDEAS:IndividualType»Ov erlapOfFrBorderAndBeBorderType

Intersection - Example

«IDEAS:Type»SingletonIndiv idualType

Type

«IDEAS:Powertype»Indiv idualType

CoupleType

«IDEAS:Powertype»WholePartType

«IDEAS:IndividualType»NewYorkStreetOv erlap

«IDEAS:Indi...23rd street

«IDEAS:Indi...5:th avenue

«IDEAS:IndividualType»5thAv enueAnd23rdStreetCrossing

«IDEAS:TupleType»IntersectionsOf5thAv enueAnd23rdStreet

«IDEAS:Individual»5thAv enue23rdStreetCrossing

«IDEAS:superSubtype»

wholeType

«place1Type»

«IDEAS:typeInstance»

«place2Type»

«IDEAS:typeInstance»

«place1Type»

«IDEAS:typeInstance»

intersectioned

«place1Type»

«IDEAS:typeInstance»

«IDEAS:superSubtype»

«tuplePlace1»

«IDEAS:superSubtype»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

partType

«place2Type»

intersectioned

«place1Type»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«IDEAS:typeInstance» «tuplePlace1»

«tuplePlace1»

«tuplePlace2»

«tuplePlace2»

«IDEAS:typeInstance»

«tuplePlace1»

«place2Type»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«IDEAS:typeInstance»

«place2Type»

overlappingPart

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«place1Type»

• Next time walk through in more detail.

• Be aware of concepts in geopolitical notations – GML.

• OASIS Customer Information Quality (CIQ)

IDEAS Common Patterns

TemporalWholePartType

couplesuperSubtype

Type

couplewholePart Individual

couplebeforeAfter

CoupleType

WholePartType

CoupleType

BeforeAfterType

IndividualType

Common Patterns

powertypeInstance

coupletypeInstance

temporalWholePart

Thing

Singleton

SingletonIndividualType

CoupleTypetypeInstanceType

CoupleTypeSuperSubtypeType

SetOfOverlappingThings

SetOfOverlappingIndiv iduals

SetOfOv erlappingTypes

CoupleTypeIntersectionOfSetOfOverlappingThings

IntersectionOfSetOfOverlappingTypes IntersectionOfSetOfOv erlappingIndiv iduals

before

partType

wholeType

before

after

whole

part

supertype

subtype

instance

intersectioned

overlappingPart

intersectioned

intersectioned

after

type

instance

type

0..1instance What

this could look like

DisjointnessIDEAS Domain Class Hierarchy

FacilityType

RealPropertyTypeSiteType

SetOfDisjointThingsSetOfDisjointTypes

PartitionOfSetOfDisjointThingsUnionOfSetOfTypes

PartitionOfSetOfDisjointTypes

RealPropertySingletonType SetOfSiteTypeAndFacilityType

RPTSSTST

RPTSSTFT

superSubtypeRPTPartition subTypesuperType

parti tions

New Overlap: Allows multiple overlap things

IDEAS Intersection

IntersectionIntersections are are the sets of relationships that relate overlapping things to their overlaps. An IntersectionOfSetOfOverlappingIndividuals is a set of wholePart relationships relating the overlapping Individuals to the overlap they form (i tself also an Individual). An IntersectionOfSetOfOverlappingTypes is a set of superSubtype relationships relating the overlapping Types to the overlap they form (itsel f also a Type).

«IDEAS:Powertype»SuperSubtypeType

«IDEAS:Powertype»CoupleType

«IDEAS:Powertype»WholePartType

«IDEAS:Powertype»Indiv idualType

«IDEAS:Powertype»TupleType

«IDEAS:Type»PlaceableType

Thing

«IDEAS:Type»Type

«IDEAS:Type»SetOfOv erlappingThings

«IDEAS:Type»SetOfOv erlappingIndiv iduals

«IDEAS:Type»SetOfOv erlappingTypes

«IDEAS:Type»IntersectionOfSetOfOv erlappingThings

«IDEAS:Type»IntersectionOfSetOfOv erlappingTypes

«IDEAS:Type»IntersectionOfSetOfOv erlappingIndiv iduals

Examples : Intersection - Example

See also:

«IDEAS:Type»SingletonIndiv idualType

«IDEAS:Type»Singleton

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«place1Type»{subsets places}

«place2Type»{subsets places}

«IDEAS:superSubtype»

wholeType

«place1Type»

partType

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»*

places

«placeType»

2..*

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

intersectioned

«place1Type»

overlappingPart

«place2Type»

«IDEAS:superSubtype»«IDEAS:

superSubtype»

«IDEAS:superSubtype»

Criteria for an architectural description to be conformant with DoDAF-DM2e.g., so that it is deemed capable of being federated

• Level 1 -- Conceptually conformant – Uses DoDAF terms and aliases (from DM2 CDM) to categorize

its concepts– DoDAF views (AV-1 thru DIV-3) have correct information

according to “monster matrix”).  For example, • an OV-2 with radios would be non-conformant • An OV-4 with Tank parts would be non-conformant • Fit-For-Purpose (FFP) would have to be conformant with whatever

the FFP model specifier said, e.g., a "Mary-Mintor-1" view for which Mary specified the model as Services mapping to Capabilities should have Services and Capabilities and the relationship but shouldn't have unrelated info

• Level 2 -- Logically conformant – Level 1 + adheres to terms and relationships from DM2 LDM and

aliases• Level 3 -- Physically conformant

– Level 2 + expressed as DoDAF – DM2 PES that can be consumed by others

• Level 4 -- Semantically conformant – Level 3 + IDEAS semantics are correct (more work to define this

but we have time to work on)

DRAFT

DRAFT

DoDAF Model (View) Issues• Some issues that have been raised:

– Many names are misleading and inconsistent with one-liner names. (AI # 579)

– The separation of SV’s and SvcV’s makes it unclear how Services provide access to Systems (AI # 398)

– CV-6 contained in all other CV’s (briefed but no AI yet)• Recap how models are described:

– Name– One-liner– Short description– Long description

• Plan– Provide read-ahead this week for names and one-liner draft 1st pass

fixes– For descriptions, base on “monster matrix”:

• Short first• Then long

– Entertain proposals to merge or split / subtype

Systems and Services in DoDAF 2• A mechanism to enable

access to a set of one or more capabilities , where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The "capabilities" accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.

• A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.

480 System vs Service

Is there an example of a Service that is not a System? The way System is defined -- A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements -- is pretty broad. Are there any Services that don't fit that?

2-Dec-09 Thornburg In Progress for 2.03

Need structure for System that distinguishes it from Perfomer (DM2 WG Rule)

McDanielSnyder / Bocast

• A System ≠ POR• 4-D

• Parts• Before-after’s• Disposed to perform activities• Must have PersonRoleTypes

Systems and Services in DoDAF 2• Deliver service:

•What I want to deliver•Parameters on the delivery

• Used by multiple individuals• Any number of implementations, e.g.,

•Electronic, others, post office, FEDEX, …

Capability Viewpoint Models

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

Capability Data Group

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

Core Components of Capability

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-1 Vision

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-2 Capability Taxonomy

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-3 Capability Phasing

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-4 Capability Dependencies

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-5 Cap to Org Development

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-6 Capability/Activities

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

CV-7 Capability/Services

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-7 Capabilities to Services

Mapping

CV-6 Capabilities to Operational

Activities Mapping

CV-2 Capability Taxonomy

CV-5 Capability To Organizational Development

Mapping

CV-1 Vision

Model Categories ≠ Presentation Types (AI # 557)Model Categories (DoDAF 2.02)

• Tabular: Models which present data arranged in rows and columns, which includes structured text as a special case.

• Structural: This category comprises diagrams describing the structural aspects of an architecture.

• Behavioral: This category comprises diagrams describing the behavioral aspects of an architecture.

• Mapping: These models provide matrix (or similar) mappings between two different types of information.

• Ontology: Models which extend the DoDAF ontology for a particular architecture.

• Pictorial: This category is for free-form pictures.

• Timeline: This category comprises diagrams describing the programmatic aspects of an architecture.

Resource FlowTem pora l Sequence and/or dependencyRelationshipBehavior

Shapes and Connectorsoptionally sw imlanes , overlays, annotations

AllocationOwnershipSupportsCom m andsInterfaces / interoperatesSim ilarity / Mappings

M atrices, Indented Textoptionally valued or annotated matix cells

part-ofproperty ("has")performs

Shape Enclosuresoptionally enclosed text

rule descriptiontem poral behavior

Conditional Logic Text / Diagram

resource flow

Tabular / Columnaroptional attribute colum ns

part-oftype-of

Tree (graphic, indented text, ...)

Presentation Types (DoDAF-DM 2 W G)and their general uses

Extending

<System id=“idref001” ><Name>IT System</Name>

</System><System id=“idref002” >

<Name>Operating System</Name></System><superSubtype id=“idref003” place1=“001” place2=“002” /><System id=“idref009” >

<Name>Big System</Name></System><System id=“idref010” >

<Name>Little Bitty System</Name></System>

<System id=“idref004” ><Name>Bit</Name>

</System><WholePartType id=“idref005” place1=“001” place2=“004” /><WholePartTypeType id=“idref006” />

<Name>ReallyBigWPT</Name></WholePartTypeType><WholePartType id=“idref007” place1=“009” place2=“010” /><typeInstance id=“idref008” place1=“006” place2=“007” />

IDEAS Common Patterns

CoupleType

WholePartType

ReallyBigWPT

Currently Queued for 2.03# Title Description108 BPMN Take a look at BPMN

114 Bussiness Rules and Dave Hay Download and distribute David Hay’s papers on representing business rules as data to the Data TWG.

115 SBVR Download and distribute the OMG SBVR model to determine the best way to represent rules.141 SoA Execution Context Rule, Activity, Performer, Resource Flow, Before-After relationships145 AV-1&2 "template" AV-1&2 "template"168 Subtypes and partitions Need to de-overlap the subtypes

333 GeopoliticalExtent both a Resource and a Location

GeopoliticalExtent is currently a subtype of Resource and Location. This should be changed so that GeopoliticalExtent is a subtype of Location and has an intersection with Resource

342 Desired Effect in SoA Example of Desired Effect and actual effect in SoA

383 Rules and Contexts

Are there examples of Rules that don't have spatio-temporal extent? For example, does the Constitution exist separate from any printed copy? Should the context of a Performer WRT a rule constraining an Activity be generalized? Rules and superrules? See SBVR WRT rules, operative rules, and enforcement.

393 SOAML Verify DM2 covers SOAML and represents it correctly.

395 Prescription of "role", basis of authority Possibly to OV-4 command relationships discussion

396 Is Vision truly distinct from DesiredEffect? They both have to do with a Resource (state)

397 How does a ServiceChannel distinguish itself from activityResourceOverlap? Should be not just a relationship, but the actual physical connection.

448 Dispositional vs Categorical Properties Maybe has to do with M3 Capability Configurations distinct from Capability456 Rules tied to Measures and Activities Rules constrain what Activities? Don't all Rules have Measures?460 UPDM 3 Element intersection has duplicate names for place1Type and place2Type

471 ServiceDescription desribes ServicePort, not Service

ServiceDescription contains all the information relating to a service but it is linked to a ServicePort not a Service

477 SoAML Concepts Need to verify that DM2 concepts and relationships cover and are consistent with SoAML

478 OASIS SOA RAF Concepts Need to verify that DM2 concepts and relationships cover and are consistent with OASIS SOA RAF

480 System vs Service Is there an example of a Service that is not a System? The way System is defined -- A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements -- is pretty broad. Are there any Services that don't fit that?

481 Mandatory Service Descriptions and Ports How to signify mandatory in the LDM

488 Information Traceability to Data1) DIV-2 with attributes, 2) DIV-1 with OV-5 traceability, or 3) DIV-1 concepts and relationships only. What to do with "attribute" relationships and un-named relationships. Question of "standard" rules, relationships, e.g., cardinalities, attributes, unnamed relationships, etc.

490 Source / agreement / rule associated representation schemes

508 Forking under Conditions How are decision processes modeled in detail, e.g., to support executable architectures?528 Statemachine diagram Shared state, joint action530 Desired effect aliases Augment defs of outcomes, objectives, effects, goals, result, and desired effects

Next

Unassigned – Candidates for 2.03 (pg 1 of 9)# Title Description

405 Physical and Temporal Measures for SV10b UPDM example does not have these mandatory elements

406 Rename/Def change for desiredEffect structure

Capability connects to Resource via desiredEffectOfCapability which is descended from WholePartType. Capability is descended from IndividualType, i.e. it is the set of sets where the instances of each of the sets it contains are entities that have a capability, i.e. some of these can easily contain individuals that are kinds of performers. There is no argument however concerning the need to have something that connects a capability to a desired outcome in the form of a state of a given resource. As an example taken from the SAR it would seem likely that the end desired effect of a Maritime search and rescue would be that the state of the resources that are in need of rescue is changed from "in need of rescue" to "rescued and safe" and that the state of the resource "a place of safety" is changed from having "no rescued" to "all in need rescued". This would however seem to imply a certain multiplicity as regards the resource. Is this assumption relating to multiplicity correct? The naming of the element gives the impression that it has something to do with desiredEffect which however is not the case. This would seem to require some handling to avoid misunderstandings. An associated element is effectMeasure and MeasureOfEffect. The definition of effectMeasure talks about desiredEffect in spite of the fact that there is no relationship to this element. A change of definition would seem to be in order here.

407 CapabilityType and other Type Types

The use of the powertype CapabilityType requires some further discussion since its utility is less than clear. Based on the definition it is automatically populated by the subsets of a set of sets (capability). The OverlapType descendent activityMapsToCapabilityType is also less obvious especially given its definition: "Represents that an activity was / is / can-be/ must-be conducted under certain conditions with a spatiotemporal overlap of the activity with the condition." which seems to be talking about something different. The fact that the element maps instances of a set of subsets (Activity) to instances of a set of subsets of a set of sets (CapabilityType) also needs to be considered.

408 activitySuperSubtypeOfMeasureType Def

activitySuperSubtypeOfMeasureType is defined as: " activityType is a member of MeasureType". There is no element named activityType and this implies that the definition needs to be changed. Since Activity is the set of all subsets of IndividualActivity and MeasureType is the set of all subsets of a set of sets of Individual Measures, the connection is less than obvious and the author of this report would like to discuss this.

409 ARO irrelevent pieces

activityResourceOverlap is used to indicate flow of resources from one activity to another. Since Resources are transferred this gives rise to some rather strange interactions given that Performer is a subset of Resource. As a result of this all elements that are subsets of Performer can flow between activities in addition to Materiel and Information (and all of its subsets), GeoPoliticalExtentType (and all of its subsets), i.e. System, Service, PersonType, OrganisationType, Port, ServicePort, GeoPoliticalExtentType (the subsets that are categorized properly). Is this really the intention?

410 Missing relationships

It is generally felt that the number of distinct elements that define how resources can be combined are few and far between and that unless foundational elements are made use of no really complex resource combinations can really be defined properly. The roles that the various entities play in different combinations are also not covered to any extent.

414 Ways The proposed action is incorrect and leads to ambiguity. Ways are activities (behavior, tactics, etc.), means are systems (materiel facilities, people, etc)

428 Enterprise CV-3 Capability phasing The text describing the view talks about phases derived from CV-1. What is being referred to here? (since no direct enterprise phase exists in DM2).

429 DependenciesCV-4 Capability dependencies How are dependencies to be modelled. The only way of doing this would seem to require the use of foundational elements, presumably OverlapType. Is this a proper interpretation? If this is the case this needs to be stated explicitly.

430 Singletons In order for the singleton approach to work, the corresponding individual class must be part of a view.

Unassigned – Candidates for 2.03 (pg 2 of 9)# Title Description

431 Relationships in monster matrix Need to make sure all pieces of a relationship are part of a view in the monster matrix. In CV-7, if ServicePortDescribedBy is a necessary element why is ServicePort optional?

432 Milestones

Only way to tie Org to Project is through Milestones (Activities) as activityPerformedByPerformer. Is that sufficient?Also, the only measures for a milestone are through activityPerformedByPerformer. Do milestones have performers?Reconsider the def of milestone.

433 SV10 The descriptive text mentions ports. Ports are however neither optional nor necessary for this view.

434 SV5a SV-5a Operational activity to systems traceability matrix It is noted that System as an element is neither optional nor necessary in this view. How is this traceability to be depicted in this case?

435 SvcV-5 Operational activity to services traceability

It is noted that Activity is only shown as an optional element which seems strange given the name of the view.

436 Capability Boundary The text describing the view states that OV-2 can be used to express a capability boundary. How is such a boundary defined?

437 XML id Potential issue - id attribute is defined as String. This forces first character to be alpha. Some ids come from DBs and are numeric

438 Maps To Concept needs to be teased out. Currently using OverlapType with annotation to describe ordering of place positions.

439 activityResourceOverlapSuperSubtypeOfRule

This seems weird to be a supersubtype since the super and sub are different types (Type and tuple type)

440 Why Before After? Why do you need before after if you have temporal extents?

449 Ind. PersonIt has been stated previously that IndividualPerson is to be considered as meta-data. It is however still shown as part of the Performer data group. Does this mean that the use of IndividualPerson has changed?

450 rulePartOfMeasureType

The element rulePartOfMeasureType is defined as: "A couple that represents the whole part relationship between types of measures and rules." This is strange since it descends from WholePartType which in turn descends from CoupleType. Furthermore MeasureType is a Powertype (of Measure). Measure is a set of sets, i.e. MeasureType is the set of all subsets of a set of sets. Rule is also a set of sets. Is an instance of the Rule set, i.e. for example set ruleA, really a part of the a set that is a subset of the set of sets that is Measure?

451 measureOfTypeWholePartType

The element measureOfTypeWholePartType appears in a number of places. Is the intent here to apply a measure onto a rules based approach of the WholePartType concept? Ians comment regarding the inability in general to apply measures to relationships needs to be noted here. Is anything intended to be done as regards this in the future?

452 Additional IDEAS elements

In earlier versions of DM2, notably from October 2009 a significant amount of additional elements were included under the foundation folder in DM2. All of this has since been removed. What was the reason for this? It is the understanding of the author that the items contained acted as grounding for significant portions of the model, needed in order to handle things at Type level.

Unassigned – Candidates for 2.03 (pg 3 of 9)# Title Description

453 capabilityOfPerfomer

Capability is related to Performer via capabilityOfPerformer. This in turn is descended from propertyOfType which is defined as " A superSubtype that asserts an IndividualType is a subtype of a Property - i.e. it asserts all members of the Individual type "have" a property. Examples: All London Buses are red, All Porsche 911 2.2S have a mass between 900 and 960 kg.". In PropertyOfType <<place1Type>> is Property and <<place2Type>> is IndividualType. In capabilityOfPerformer <<place2Type>> is Performer which is a subset of Resource which in turn is a subset of IndividualType. <<place1Type>> is Capability which is a subset of IndividualType i.e. less restricted than the <<place1Type>> that propertyOfType links to since Property is a subset of IndividualType. The following therefore seems to be a valid question: Why is Capability not a subset of Property?

455 OV-2 Anticipated UsersThe aim of the OV-2 is to record the operational characteristics for the community of anticipated users relevant to the Architectural Description and their collaboration needs, as expressed in Needlines and Resource Flows. (Anticipated users, to us would indicate Performers.)

491 State

The concept of state seems to be missing. While each element from a temporal perspective can be viewed as a state i.e. an IndividualResource for a limited temporal duration can be considered as being in a state. As types of resources are being considered however there would seem to be a need to discuss the types of states that these resources can be in. The temporal dimension is less easy to deal with under these circumstances. This therefore needs further discussion.

492 Powertype

While the model has been modified such that no real powertypes exist that do not have associated individuals that they are a powertype of (previously the case to a very large extent in DM2 2.00) the actual use of powertypes still needs to be considered from a modeling perspective. A Powertype has a very strict definition, it is the set of all subsets that can be created from a set of either individuals or sets. An example of this is ProjectType and Project. Project is descended from IndividualType i.e. it is a set of Individuals. If a modeler creates three instances of the Project set (the equivalent of creating three elements that is given the stereotype <<Project>> namely PrjA, PrjB and PrjC, this implies that the following ProjectTypes automatically exist (see report). The <<ProjectType>> set is therefore equal to: { PrjTpInst1, PrjTpInst2, PrjTpInst3, PrjTpInst4, PrjTpInst5, PrjTpInst6, PrjTpInst7, PrjTpInst8} as soon as new individual projects are created, the powertype is made larger. How does DM2 intend that these should be dealt with by a modeler creating a real model? Obviously only a few of the above subsets have any real use, the powertype however contains all possible subsets. From a meta-model perspective would it not be more clear to identify an element called ProjectCategory as a subset of ProjectType where the modeler is allowed to actually create categories as needed. Such an approach would give the individual modelers more control and since this argument can be put forward for all Powertypes in DM2 something similar could be done there as well. The Powertypes, when they are used can be viewed as abstract entities, never to be instantiated.

493 Overlap Will overlap/ OverlapType ever be harmonized with the IDEAS foundation since at present they are not the same?

495 desiredEffectWholeResourcePartTypeIn the latest version of the model desiredEffectWholeResourcePartType has been moved to the side, i.e. it is no longer situated within an inheritance hierarchy. What purpose does this element have? It seems consistently to be in the wrong color in the model.

496 MeasureRange and MeasurePoint Why have MeasureRange and MeasurePoint (integrated from IDEAS foundation up until the latest version), been deleted? (see also 2.6 in the report)

497 Measures Why have measureOfIndividual been treated differently from MeasureOfType (see 2.6 in the report).

498 Rules There is a need to get final confirmation regarding the rules described in paragraph 2.7 of the big report.

499 Naming and Desc Will the DM2 Naming and description pattern be brought in line with the IDEAS foundation?503 Org/OrgType WP(T) Performer Relationship missing - Org/OrgType Part Of Performer505 TV and StdV How to relate to contraints in DISR

506 LocationType Measures e.g., you want to say a High Mountain is > 3000 ft. Does raise issue of interpretation of a Type being a typeInstance to Measure.

Unassigned – Candidates for 2.03 (pg 4 of 9)# Title Description

511 How to categorize Arch Desc

describedBy and Arch Desc are used tie all the bits of a view/model together.is there a good way to identify an architectural description as a particular model/product. you can name the arch. desc. anything - "my OV5b". the exemplar can be anything (could tag it as "OV5b"). Some enum or subclass? or is there some official guidance about that?

512make the full inheritance taxonomy machine-accessible somehow, like in the XSD

currently, only ties back to Ideas foundation. Is needed for OWL expriements

513 Partridge Services Questions & Comments See emails in R&R folder for details

515 Performer Flows and Tools

516 Service Access to Resource or Performer

517 Powertype Definition The definition for “Powertype” seems a bit garbled (“A Type that is the is the set (i.e., Type) of all subsets (i.e., subTypes) that can be taken over the some Type.”

518 Business Aspect of Services And how they're reflected519 Description Scheme is missing Need to add to Naming pattern and class hierarchy

520 Individual Person If needed only for metadata, does not need to be structured so remove. If intended only for AV-1, how would you restrict?

521 Service Description Specialization If you have a ServicePort, you need a Service. The only way to insure this is to make a specialized relationship and make it mandatory for the service views.

522 Denormalized DB

Consider denormalizing name and description on the core objects – activity, capability, performer, system, etc. What I have found is that by having only the ID column on the core objects, and making the name and description “properties” associated objects, it seems unnecessarily complex to do just a simple query to pull a list of names and descriptions for a given object type, much less cross reference it against a related object – say systems and the activities they perform. That query alone is like a 10 table join – or more (I got side-tracked halfway through and then gave up). Thus I would like to request that the DM2 work group consider adding name and description to the core objects. The benefit being that I think it makes the PES database far more usable by analysts and more readily adoptable by the tool vendors. (And by the way, I understand the logic behind making “Name”, “namedby”, “NameType”, “describedBy”, “descriptionType”, etc. all individual objects in and of themselves. I’m not challenging the logic. I get it. I’m simply suggesting that in the interest of usability and “supportability”, I think this would go a LONG way towards making the PES more usable for most folks.)

523 Business vs SoA Service524 personTypePartOfPerformer How can a Person Type be part of a Person Type?525 Reification levels diagram

529 Objectives vs Desired Effects

During our email discussions all members of the UPDM group have converged on the same position regarding enterprise phase and project. There is a large unanimity on this topic from people coming from different viewpoints. I have looked at documents from the DoD* that reinforce the position that “capability planning” is linked to strategy. The debate is about the clarification of “desired effect” the conclusion being that “objectives are truly the basis of military planning” (see attached document).Consequently, when we say “capability” in this paper, we mean: the ability to achieve an objective in a military operation.We do not reject the notion of an effect. Physical and behavioral conditions matter, and the definition above does not preclude you from considering effects as defined by Joint Publication 3.0. However, objectives are truly the basis of military planning, and defining capabilities in that way is more straightforward.The UPDM/MOD approach provides a formal solution for this (capabilities, enterprise phases, and capability requirements for each phase). The traditional “requirement/acquisition management” has to be reconsidered because of the introduction of a new time dimension. Therefore, the time for the enterprise/strategy planning has to be assessed and aligned with the time for capability configuration availability. Mixing these two dimensions may prevent from achieving effective EA governance processes.

Unassigned – Candidates for 2.03 (pg 5 of 9)# Title Description

531 Capability relationships Should Capability be a tuple and should it link to measureOfTypeActivityPerfomedUnderCondition? Since all it does it relate desired effects and activities. See diagram from 2010-06-11.

532 Conditions Conditions as defined in UJTL and DM2 are different from Conditions and Preconditions as needed in SoA.

533 EA RolesCurrently they are Manager, Architect, and Developer. Recommend: Change: "Developer" to "Tool Developer"; "Manager" to "Process Manager"; Add: Analyst, Integrator, Architecture Project Manager, SME

534 Definitions of important non-model terms For example, reification, time-wise as well. Where in DoDAF is this defined?

535 SV-1 Inconsistencies Name, one line description, description, and detailed description are inconsistent.536 Security Attribtes Group SAG is actually a type of Information. Think about the markings on a document.537 desiredEffectDirectsActivity How does a desired effect guide/direct Activities?

538 Not all Performers can desired an effect Probably limit to Oganizations, Organization Types, and Person Types

539 Guidance and Rule Guidance serves no purpose in DM2. It should either be deleted or linked to something. 540 Performers in OV-2 Performers in OV-2, not Orgs / Org Types / Person Types

541 PersonType part of Individual Performer Need Individual Person part of Individual Performer to do correctly

542 Representation Type is a Resource Type Information Type is a Resource Type but forgot to show Representation Type

543 Pedigree type Pedigree is a type of Information that describes the workflow544 Pedigree activities Pedigree Activities are Individual Activities545 Singleton Ind Type Need Singleton Ind Types to emphasize singleton

546 Properties and Measures Need to complete adoption of IDEAS model for this, basically using inheritance to allow all individuals and individual types to have properties and measures

548 Name def doesn't match model549 Action Should be in data dictionary

550 Plans

a plan is not an activity or an aggregation of activities (or actions or processes or doings or anything). Planning is the activity (action, process, doing); a plan results from the planning activity (action, process, doing). It’s conceptual, a recipe to be followed in the future, etc. The JC3IEDM gets this somewhat right: A PLAN is a proposal for putting into effect a command decision or project; it represents the preparation for future or anticipated operations.

554 Using OverlapType to associate Rules to MeasureTypes and Measures

We are using a generic OverlapType to go from the TemporalMeasure to Rule (to be able to perform the duration calculation) and then from the Rule to the PerformanceMeasure (the actual calculation).

555 More Specific association for MeasureOfDesire

We have the actual measure PerformanceMeasure relating to MeasureOfDesire with a generic CoupleType. Can we find more specific associations?

Unassigned – Candidates for 2.03 (pg 6 of 9)

# Title Description

556 Activity to Measure Apart from ConditionAlso, how about a direct association between Activity (or activityType) and Measure, so we don’t have to go through the Condition just to get to the measure.

557 Model CategoryThese are really presentation categories. And their relationship to the models s/b many-many; many views have multiple valid ways of being presented.

560 UPDM 16 Definition of ServiceChannel mentions "requisitions", there is no such concept in DM2 ! Please explain

564 AV-1 and AV-2 for DARS565 GTP and GTG consistency with StdV's

566 Monster Matrix review

especially:1. desiredEffect the tuple is required in many products, but we tend to use the resource state instead.

2. ov5a has no optional elements. that really limits things.

3. most SvcV products require port even though we alway use serviceport instead.

567 Powertypeinstance cardinalities why is place2 0..1?

568 Conceptual Overview diagram needs updating

569 Individual for each Individual Type Now that we have a Type Type level for everthing, should we do the same for the Ind.

570 Data Dictionary Could use a def review571 Type Type names Agree on naming convention for type types572 Singleton Types why only some singletons called out?

Unassigned – Candidates for 2.03 (pg 7 of 9)# Title Description

573 RepresentationType / Resource RepresentationType cannot be an IndividualTypeType and a Resource (IndividualType). This occurs because InformationType is needed in ResourceFlow

575Relationship between Capability and Performer should be derived, not declared

577 Methods and redundant tables Links, navigation helpers, …

578 Wrong ISO number for 15407

On 17 Aug 2009 14:49 GMT sidney.antommarchi Wrote ---- The following reference in page 19 of Volume 1 should cite ISO 15704 rather than ISO 15407:"10 International Standards Organization (ISO) Standard 15407:200x, Industrial Automation Systems – Referencebase for enterprise architecture and models, dated 10 January 2009; International Standards Organization (ISO)Standard 42010, Systems and Software Engineering – Architecture Description, dated 16 January 2009."ISO 15407's title is "Pneumatic fluid power -- Five-port directional control valves, sizes 18 mm and 26 mm -- Part 1: Mounting interface surfaces without electrical connector" which is not related to the discussion at hand.

579 Inconsistent Model DescriptionsPlease align model descriptions, http://cio-nii.defense.gov/sites/dodaf20/models.html, with detailed content that futher describes the models, which is contained in the hotlinks off of the "Models" page.

580 BTA OV-6c Guidelines in JournalAdd "Guidelines for the Design and Development of Business Process Models (DoDAF OV-6c) using BPMN" to the DODAF Journal, submitted on 19-Nov-2009, by James Kindrick, [email protected]

581 BTA AV-2 Guidelines in JournalAdd updated version of "Guidelines for DoDAF AV-2: Design and Develop of the Integrated Dictionary" to the DoDAF Journal, submitted opn 19-Nov-2009, by James Kindrick, [email protected]

582 DM2 Data Group Use Cases

daniel.clemons on 8 Sep 2009 19:35 Reply Rate Average Rating: Not Yet Ratedpara. "Step 5.1" states:The architect has determined the architectural data that will meet the DoD Manager’s purpose (“Fit-for-Purpose”) and support their decision processes (use-cases).Section 2 of Volume 2 contains a Use subsection for each of the Meta-model groups which describe example uses. The DoD Manager needs to verify that the data collected meets their needs (use-cases) to support the analysis that will be performed in Step 5 of the 6-Step Architecture Development Process.I could not locate a use-case subsection in any section of volume 2. Is this an editing error from v1.5 or an omission from v2.0?

Unassigned – Candidates for 2.03 (pg 8 of 9)# Title Description

573 RepresentationType / Resource RepresentationType cannot be an IndividualTypeType and a Resource (IndividualType). This occurs because InformationType is needed in ResourceFlow

575Relationship between Capability and Performer should be derived, not declared

577 Methods and redundant tables Links, navigation helpers, …

578 Wrong ISO number for 15407

The following reference in page 19 of Volume 1 should cite ISO 15704 rather than ISO 15407:"10 International Standards Organization (ISO) Standard 15407:200x, Industrial Automation Systems – Referencebase for enterprise architecture and models, dated 10 January 2009; International Standards Organization (ISO)Standard 42010, Systems and Software Engineering – Architecture Description, dated 16 January 2009."ISO 15407's title is "Pneumatic fluid power -- Five-port directional control valves, sizes 18 mm and 26 mm -- Part 1: Mounting interface surfaces without electrical connector" which is not related to the discussion at hand.

579 Inconsistent Model DescriptionsPlease align model descriptions, http://cio-nii.defense.gov/sites/dodaf20/models.html, with detailed content that futher describes the models, which is contained in the hotlinks off of the "Models" page.

580 BTA OV-6c Guidelines in JournalAdd "Guidelines for the Design and Development of Business Process Models (DoDAF OV-6c) using BPMN" to the DODAF Journal, submitted on 19-Nov-2009, by James Kindrick, [email protected]

581 BTA AV-2 Guidelines in JournalAdd updated version of "Guidelines for DoDAF AV-2: Design and Develop of the Integrated Dictionary" to the DoDAF Journal, submitted opn 19-Nov-2009, by James Kindrick, [email protected]

582 DM2 Data Group Use Cases

daniel.clemons on 19:35 Reply Rate Average Rating: Not Yet Ratedpara. "Step 5.1" states:The architect has determined the architectural data that will meet the DoD Manager’s purpose (“Fit-for-Purpose”) and support their decision processes (use-cases).Section 2 of Volume 2 contains a Use subsection for each of the Meta-model groups which describe example uses. The DoD Manager needs to verify that the data collected meets their needs (use-cases) to support the analysis that will be performed in Step 5 of the 6-Step Architecture Development Process.I could not locate a use-case subsection in any section of volume 2. Is this an editing error from v1.5 or an omission from v2.0?

Unassigned – Candidates for 2.03 (pg 9 of 9)

# Title Description

583 Missing Net Centric RA's

In DoDAF 2.0, Volume 1, Section 11.2.2., page 87, please clarify the reference to:"the Net-Centric Reference Architectures and the DoD IE as outlined in Section 3.0 of the DoDAF and the Net-Centric Guidance contained in Volume 2."I was unable to find, in Section 3.0 and Volume 2, any mention of the "Net-Centric Reference Architectures"

585 Showing Software Processes

Operational Activities and System Functions: When developing the viewpoints, do we have to list / show processes controlled by software, such as "receive crew data", "transmit crew data", "render crew data" or "process crew data", "provide transmit data"? How is the best way to list / show these activities (internal within a LAN or Server)? How is server/workstation processing indicated in the architecture?

586 UJTLs Hightlight the use of UJTLS in AV-2.587 Training Resources in Journal Please add a Training Resources page to the DoDAF Journal.

588 Track ChangesPlease add a mechanism to track changes with access to the old version of the content, the new content, the date of change, reason for the change (should have a change request).May want to include the change request information.

589 Videos of Outreaches Please post videos of the Outreach Session on the DoDAF Journal

590 DoDAF PDFPlease regenerate the DoDAF V2.0 PDF at http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_web.pdf.It is 3 months out of date. I am no longer a contact for DoDAF V2.0.

591 DoDAF Releasability Please post a DoDAF Releaseability Statement (to include releaseability to Foreign Nationals) on the DoDAF website, cio-nii.defense.gov/sites/dodaf20/.

592 Models <> Monster Matrix

593 SBSI Website: DM2 Action Itemhe DoDAF website should have a process to submit change requests. Also, there should be a way to see the submitted change requests in a log on the public site (whether it is DoDAF or DoDAF Journal). It needs to collect the appropriate status and change information.

594 TupleTypeType Relationships between types should be stereotypes TupleTypeType and colored green

595 IDEAS plugin model tweaks In order for the IDEAS plugin to work properly with the model, Ian will run a script to tweak it

596 Multiple stereotypes In IDEAS, how do you handle a class that is both a relationship and a Powertype. Should the Stereotype be TupleType, or Powertype, or both

10 Sept 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• IS&T NR-KPP WG • DoDAF and Net Centric Data Strategy goals• USAF EA 3.5 FAC correspondence• UK Integrated EA Conference planning• Pentagon IT Master Plan architecture• DM2 PES Submission to DISR

– Upcoming:• IDEAS & NATO PWG prep in London next week• OMG Technical Meeting – Cambridge MA – UPDM 2.0 week after

next• IS&T NR-KPP WG Oct 4-6

– New References: • Rex Brooks presentation to TRADOC from the NCOIC Human

Interoperability Enterprise (HIE) Ad Hoc WG. in HSI folder – Bob Smile NATO WG

• ELS folder– Others?

• USAF EA 3.5 – what level is it?• Some SoAML key terms – add to dictionary as new and

alias/composite -- what is the rqmt for DoDAF to accommodate SoAML?

• Prioritization for 2.03– SoA Consolidation -- Ellis

• Others:– Capability model (Terebesi)– Naming pattern, System meaning inputs – Alex– Partitions – optional or mandatory?– ARO– What is a Service Port?

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 27 26 1 0

In Progress for 2.02 1 0 1 0In Progress for 2.03 31 27 3 1

Unassigned 101 69 32 0Consult IDEAS Group 17 16 1 0

Defer 93 85 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0270 270

CI

Draft DODI 8320.02-M (Manual): Implementing Data Sharing in a Net-Centric DoD

• Implements policy, assigns responsibilities, and provides procedures for implementing Data Sharing in a Net-Centric Department of Defense.

• Cancels and incorporates guidance in DoD Guide 8320.02-G

• Provides guidance to the DoD stakeholders to facilitate the implementation of DODD 8320.02 and to enable an information sharing environment that supports warfighter requirements

• Describes key enablers necessary to make data assets, services and information sharing solutions visible, accessible, understandable, trusted and interoperable.

• ENCLOSURE 4 DATA STANDARDS AND ARCHITECTURE

What is the criteria for an architectural description conformance with DoDAF and DM2 so that it is deemed capable of being federated?

• Level 1 -- Conceptually conformant – uses DoDAF terms and aliases (from DM2 CDM) to categorize

its concepts defined – DoDAF views (AV-1 thru DIV-3) have correct information

according to “monster matrix”).  For example, • an OV-2 with radios would be non-conformant • An OV-4 with Tank parts would be non-conformant • Fit-For-Purpose (FFP) would have to be conformant with whatever

the FFP model specifier said, e.g., a "Mary-Mintor-1" view for which Mary specified the model as Services mapping to Capabilities should have Services and Capabilities and the relationship but shouldn't have unrelated info

• Level 2 -- Logically conformant – Level 1 + adheres to terms and relationships from DM2 LDM and

aliases• Level 3 -- Physically conformant

– Level 2 + expressed as PES that can be consumed by others • Level 4 -- Semantically conformant

– Level 3 + IDEAS semantics are correct (more work to define this but we have time to work on)

DRAFT

DRAFT

Implementing DoDAF 2.0 – DM2: Success Stories to Date

• Joint Mission Threads• Command and Control Capability Architeture• Enterprise Reference Architectures

– Enterprise-wide Access to Network and Collaboration Services (EANCS) Reference Architecture

– Active Directory Optimization Reference Architecture (ADORA)

Views and Viewpoints

• IDEAS in DoDAF, DoDAF Metamodel, MoDAF, NAF & NATO Network Enabled Capability (NNEC)

– International Defence Enterprise Architecture Specification – Ontological Framework Expressed in UML

• Focus on MoDAF & NNEC• Multiple Views and Separation of Concerns Necessitate

Multiple Viewpoints.• Multiple Views Introduce Problems of View Integration and

View Consistency.

Human Views in NCOIC HIE Project

Rex Brooks09 June, 2010

HV-A:PersonnelAvailability

HV-B: QualityObjectives and

Metrics

HV-C: HumanInteractionStructure

HV-D:Organisation

HV-E: HumanFunctions and

Tasks

HV-G: DynamicDrivers of Human

Behaviour

HV-F:Roles and

Competencies

Who could be made available? Which Personnel processes are needed? Does it match those that are being used?

How may human-related benefits be expressed and measured?Do we use quantitative and qualitative measures?

What are the human interaction structures to be supported by technology solutions? Is it a good match?

What are the required changes

to formal organisational structures and

processes? Is it humans

fitting structure or the structure fitting humans?

Which human activities are to be supported by technology functions, and how should humans and technology complement each other?

Which human roles and skills need to be

supported, based on task demands?

Are there credentialing, bonding, licensing and

performance measuring issues to

be considered?

What are the time structures, conditions, and scenarios to be supported for different configurations? Are there human concerns to accommodate?

Adapted from Dr Anne Bruseberg, Systems Engineering & Assessment Ltd., Human Factors Integration Defence Technology Centre

Value of Human View is to Organizational and Operational Performance

Follow-on questions extend MoDAF Human Views

Human View Product DescriptionsMoDAF

NO UNIFYINGCENTRAL CONCEPT

MoDAF Human ViewsDependencies

Sequence Statechanges& Rules

Assess-ment

Whatto

achieve

Functionalstructure

What to do

Technologyenablers &

team structure

Task workand team work

needs Targets

Performanceneeds

Personneldevelopmentconstraints

and enablersSkillneeds

Teamconstraints Components

of humannetworks

Organisational andprocedural

definitions (formal)

Jobsto be filled

& Personneldevelopmentmechanisms

Who canbe madeavailableto fill jobs

Human interactionneeds (functional)

Constraintsfrom

formalstructure Job

components

HV-A:PersonnelAvailability

HV-B: QualityObjectives andMetrics

HV-C: HumanInteractionStructure

HV-D:Organisation

HV-E: HumanFunctionsand Tasks

HV-F: RolesandCompetencies

HV-G: DynamicDrivers of HumanBehaviour

HV-G:DynamicDrivers

HV-G:DynamicDrivers

HV-G:DynamicDrivers

HV-G:DynamicDrivers

Human Networks (HV-E)NATO Focus

Central concept: The Human Network (HV-E) product focuses on the interaction of the human elements of the system.

Human networks can connect different individuals performing roles in the same or different locations and the same or different organizations.

The performance of the process supported by the human network is affected by the assignment of roles, responsibilities, and the existence of needed relationships.

Focus on Network Performance, not human performance

Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, PhD, PE; Pacific Science & Engineering Group

Nancy P. Houston, EdD; NATO Allied Transformation Command

Human View Product DescriptionsNATO

Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, PhD, PE; Pacific Science & Engineering Group

Nancy P. Houston, EdD; NATO Allied Transformation Command

Human Views-NATO & MoDAF

Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, PhD, PE; Pacific Science & Engineering Group

Nancy P. Houston, EdD; NATO Allied Transformation Command

NATO MoDAF

Human Views:Different Models

Churchill Revisited: Different Cultures Divided by a Common Language

HV-A:PersonnelAvailability

HV-B: QualityObjectives and

Metrics

HV-C: HumanInteractionStructure

HV-D:Organisation

HV-E: HumanFunctions and

Tasks

HV-G: DynamicDrivers of Human

Behaviour

HV-F:Roles and

Competencies

Adapted from Dr Anne Bruseberg, Systems Engineering & Assessment Ltd., Human Factors Integration Defence Technology Centre

Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, PhD, PE; Pacific Science & Engineering Group

Nancy P. Houston, EdD; NATO Allied Transformation Command

MoDAF NATOValue of Human to Organization Role of Human in Organization

Organization Centric Network Centric

Human Views:Different Models

Churchill Revisited: Different Cultures Divided by a Common Language

Can Semantic Knowledge ModelingBring these Systemic Human Views Together?

HV-A:PersonnelAvailability

HV-B: QualityObjectives and

Metrics

HV-C: HumanInteractionStructure

HV-D:Organisation

HV-E: HumanFunctions and

Tasks

HV-G: DynamicDrivers of Human

Behaviour

HV-F:Roles and

Competencies

Adapted from Dr Anne Bruseberg, Systems Engineering & Assessment Ltd., Human Factors Integration Defence Technology Centre

Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, PhD, PE; Pacific Science & Engineering Group

Nancy P. Houston, EdD; NATO Allied Transformation Command

Knowledge Automation andBayesian Network Analysis

• Knowledge Automation Processes and Models Large Structured, Unstructured and Semi-Structured Datasets

Knowledge Automation andBayesian Network Analysis

• Bayesian Network Analysis Provides Probabilistic Modeling

Situational Model

Personality ModelLinking Variables

Personality Ratings by AnalystLinks to Hypotheses by Analyst

USAF EA 3.5• The AFEA is the Air Force’s

“capstone” architecture that provides context for all of the architectures that together describe the AF enterprise. It is based upon the Federal Enterprise Architecture Reference Models, but has been extended to include all of the types of architecture information captured by DoD Architecture Framework based architectures. It draws upon and relates relevant information from the sub-enterprise and lower level architectures and also provides enterprise wide architecture guidance and resources organized by the reference models. It includes IT systems information captured by the AF Enterprise Information Technology Data Repository (EITDR), enterprise IT standards reflected in the DoD IT Standards Repository (DISRonline), AF information metadata captured in the DoD Metadata Registry, and architecture metadata captured by the AF Architecture Repository (AFAR).

Summary of Changes from Previous Version (v3.4.7) DoDAF - DM2 Relationship(s) Conformance Level

Added AF ACS/Communication & Infrastructure (C&I) programs and their mapping to the Joint Capability Areas (JCAs)

CapabilityType - Capability - Performer

Added relationships between JCAs and the AF Universal Task List (AFUTL), Universal Joint Task List (UJTL) and Joint CONOPS Added relationships between AF Core Functions and the UJTL and AFUTL

Added relationships between AF organization types and their associated AFUTL based Mission Essential Tasks List (METL)

Created an analytic console to explore the relationships among JCAs, UJTLs, AFUTLs, AF Core Functions, AF ACS C&I Programs, and AF organization types Updated the DoD BEA information to reflect v7.0 activities, system functions, systems, their interrelationships, and their relationships to the JCAs, Federal Enterprise Architecture (FEA), and AF systems

Created an analytic console to explore DoD BEA relationships with DoD and AF Systems, JCAs, and the FEA

Added the mapping of DoD Architecture Segments to the FEA BRM Updated the AF PRM and Enterprise Performance analytic console to reflect updates to the DoD Enterprise Transition Plan (ETP) and Strategic Management Plan (SMP) Added Federal statutes dealing with (Title10) Data to include Subtitle A, Part I, Chapter 5 Revamped the AF BRM by removing HQ Structure from AF Organizations other than the HAF and streamlining location data Updated SRM Services List to reflect current NCES Service Registry information

Updated AF Systems List and associated relationships to the GIG functions, FEA BRM, FEA SRM, AF BRM, Organizations, System Tiers, and planned target system and replacement date

Updated TRM IT standards to DISR version 10-1 Removed the Architecture Analytic Console and AFAR data reflected in the AFEA Updated Enterprise Sequencing Plan (ESP) with current EITDR data Updated the AFEA Content Metamodel vs DoDAF Metamodel (DM2) Wall Chart

• Air Force Enterprise Architecture v3.5 Object Type and Location (by model area) with Equivalent DoDAF 2.0 Object Type – seems to map to DM2, review• Need to see either in tool, tool viewer, or extract• Can think about changes since 3.4.7

• Further work to review 3.4.7 baseline

SoAML Key Terms (page 1 of 2)Concept

Service oriented architecture Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS) Beta 2-FTF Submission

http://www.merriam-webster.com/

Agent

An Agent is a classification of autonomous entities that can adapt to and interact with their environment. It describes a set of agent instances that have features, constraints, and semantics in common. Agents in SoaML are also participants, providing and using services.

2 a : something that produces or is capable of producing an effect : an active or efficient cause

Collaboration Collaboration is extended to indicate whether the role to part bindings of CollaborationUses typed by a Collaboration are strictly enforced or not.

3 : to cooperate with an agency or instrumentality with which one is not immediately connected

CollaborationUseCollaborationUse is extended to indicate whether the role to part bindings are strictly enforced or loose.

Milestone

A Milestone is a means for depicting progress in behaviors in order to analyze liveness. Milestones are particularly useful for behaviors that are long lasting or even infinite.

2 : a significant point in development

: one that participatesparticipate: to have a part or share in somethingA fulfillment,2 : something that inevitably follows an antecedent (as a cause or agent)

A Request represents a feature of a Participant that is the consumption of a service by one participant provided by others using well-defined terms, conditions and interfaces. A Request designates ports that define the connection point through which a Participant meets its needs through the consumption of services provided by others.

A request port is a “conjugate” port. This means that the provided and required interfaces of the port type are inverted; this creates a port that uses the port type rather than implementing the port type.

Real World EffectA ServicesContract is used to model an agreement between two or more parties and may constrain the expected real world effects of a service.

Request (port stereotype) 2 : something asked for <granted her request>

Participant A participant is the type of a provider and/or consumer of services. In the business domain a

SoAML Key Terms (page 2 of 2)Concept

Service oriented architecture Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS) Beta 2-FTF Submission

http://www.merriam-webster.com/

Capability

A Capability is the ability to act and produce an outcome that achieves a result. It can. Specify a general capability of a participant as well as the specific ability to provide a service.

3 : the facility or potential for an indicated use or deployment <the capability of a metal to be fused> <nuclear capability>

Service

A Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A Service designates a Port that defines the connection point through which a Participant offers its capabilities and provides a service to clients

2 a : the work performed by one that serves <good service>

Contract: 1 a : a binding agreement between two or more persons or parties; especially : one legally enforceable b : a business arrangement for the supply of goods or services at a fixed price <make parts on contract> c : the act of marriage or an agreement to marry2 : a document describing the terms of a contractInterface:2 a : the place at which independent and often unrelated systems meet and act on or communicate with each other <the man-machine interface> b : the means by which interaction or communication is achieved at an interface

ServiceChannel A communication path between Services and Requests within an architecture.

Channel: d : a means of communication or expression: as (1) : a path along which information (as data or music) in the form of an electrical signal passes

Services Architecture

The high-level view of a Service Oriented Architecture that defines how a set of participants works together, forming a community, for some purpose by providing and using services.

: one that consumesConsume: 5 : to utilize as a customer

Port Extends UML Port with a means to indicate whether a Connection is required on this Port or not

2 a : a harbor town or city where ships may take on or discharge cargo

: one that providesProvide:2 a : to supply or make available

Consumer Consumer models the type of a service consumer. A consumer is then used as the type of a role in a

providerProvider models the type of a service provider in a consumer/provider relationship. A provider is then used as the type of a role in a service contract and

ServiceContract A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service.

Service InterfaceProvides the definition of a service. Defines the specification of a service interaction as the type of a «Service» or «Request» port.

3 Sept 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• DoDAF website cosmetics and completeness – digital object identifiers• Enterprise Lexicon Service AV-2 – One Source

– Upcoming:• IDEAS & NATO PWG prep in London• OMG Technical Meeting – Cambridge MA – UPDM 2.0

– New References: • Rex Brooks presentation to TRADOC from the NCOIC Human

Interoperability Enterprise (HIE) Ad Hoc WG. in HSI folder – Bob Smile NATO WG

– Others?• Review DoDAF-DM2 Conformance Levels

– Using levels, thoughts on USAF EA 3.5• Rules and Guidance

– At BTA, Guidance includes Laws, Regulations, … and Rules are unbreakable

– Related to AI #539• Prioritization for 2.03

– SoA Consolidation -- Ellis• Others:

– Ports (Terebesi)– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms submitted by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions email from Chris Partridge

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 26 26 0 0

In Progress for 2.02 0 0 0 0In Progress for 2.03 30 26 3 1

Unassigned 100 67 33 0Consult IDEAS Group 17 16 1 0

Defer 93 85 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0266 266

CI

Conduct mission

Make ROE

Commander Force

IEEE 1320.1.1998

FollowROE

ROE followers

FollowRule

ROE Info

Communicate

Make Standard

DISA Switch

IEEE 1320.1.1998

Communicate correctly

standards followers

Rule

Ieee 806.2 info

Operate rudder

Give rudder order

Captain Bowswain’s mate

IEEE 1320.1.1998

Steer correctly

Good bowswain’

s mate

Rule

Rudder orders

Operate rudder

AI # 168• How do you tell which subtypes are partitions vs not.  •  • This should read - How do you tell which sets of subtypes are

partitions vs not. •  • The background to this is covered quite extensively in BORO book. •  • Normally there is a notion of complete and incomplete partitions -

the definition below is of complete partitions.• The second property “2.The intersection of any two distinct

elements of P is empty. (We say the elements of P are pairwise disjoint.)” is handled by the disjoint property in the IDEAS model.

• The first property “1.The union of the elements of P is equal to X. (The elements of P are said to cover X.)” is handled by the union property in the IDEAS model.

•  • So, I believe this can be closed.

27 Aug 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• DoDAF and Joint HSI WG (Human View) Dialog Kick-Off – NCOIC is cross-

connecting MODAF and Human Views. Rex to send info on NCOIC for Dave to forward to HSI WG; Dave to post Navy HV data model info in folder

• DoD EA COI – DODI 8320.02G – Dave plan next steps– Upcoming:

• IDEAS & NATO PWG prep in London• OMG Technical Meeting – Cambridge MA – UPDM 2.0

– New References: • DoDAF and Joint HSI WG (Human View) Dialog Kick-Off briefs in HSI folder• USAF EA 3.5 + comment instructions in WG folder “Arch for Review/USAF

3.5”– Others?

• WG Tasker from FAC to Review USAF EA 3.5 for DoDAF-DM2 Conformance

– Air Force looking at way to publish, maybe free viewer, also SADIE• 2.02 Finalization (26 Aug) Status

– Revised CDM review– LDM documentation

• Prioritization for 2.03• Others:

– Ports (Terebesi)– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms submitted by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions (they are modeled in IDEAS!)

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 26 26 0 0

In Progress for 2.02 6 3 3 0In Progress for 2.03 23 22 0 1

Unassigned 85 67 18 0Consult IDEAS Group 18 17 1 0

Defer 93 85 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0251 251

CI

WG Tasker from FAC to Review USAF EA 3.5 for DoDAF-DM2 Conformance

• The following is sent on behalf of Mr. Alan Golombek, DoD Federated Architecture Committee Chairman:

•  • Attached, for DoDAF and DM2 Working Groups’ review, is the Air Force Enterprise

Architecture (AF EA), version 3.5, Architecture Certification Package (ACP) in preparation for a Federated Architecture Committee (FAC) vote recommending the incorporation of the AF EA, ver. 3.5 into the DoD EA.  Also attached is an Air Force DoD Information Enterprise Architecture Checklist as supporting documentation.  We anticipate the vote on the architecture will take place at the next FAC meeting on 5 October.   

•  • We request the DoDAF and DM2 Working Groups evaluate the Architecture for

DoDAF and DM2 compliance.  The Air Force’s briefing presented at the 17 August FAC meeting provides amplifying information such as on the mapping of the AF EA to the DM2.  A copy of the briefing is on DKO in the FAC_Forum folder for FAC_08_17-2010 at https://www.us.army.mil/suite/files/23725957. 

•  • Request all comments regarding the AF EA be provided to the FAC Secretariat using

the attached comments matrix by COB 6 September.   The FAC Secretariat will consolidate the comments and forward them to the Air Force for adjudication as appropriate.

•  • FAC Secretariat PoC is Howard Kern, [email protected], 703-607-0249.•  • On Behalf of Mr. Alan Golombek

USAF EA 3.5 Files• - AFEA AV-1 -- DARS• - AFEA Release Talking Paper• - AFEA Overview Briefing Slides• - AF Enterprise Sequencing Plan (ESP)• - AFEA Content Metamodel vs DoDAF Metamodel

(DM2) Wall Chart• - Navigation and User Guide• - AFEA model package (zipped)• - Reusable Architecture Data

Title or Description yes no Comments Complete

A. Name of DoD Component, Producing Organization, and POC Info provided?

U.S. Air Force, SAF/CIO A6, Col David C. Geuting, 703-696-7777, [email protected]

B. Name and type of candidate architecture provided? Air Force Enterprise Architecture (AFEA) v3.5, ComponentC. Name of functional offi cial approving the candidate architecture, and POC info provided?

Lt Gen William T. Lord, 703-695-6829, [email protected]

D. Is the Candidate Architecture's AV-1 registered in DARS and is it attached or linked?

Yes (Uploaded to DARs and linked to by the AV-1 registration)

E. Are additional DoDAF views or other representations of the candidate architecture attached or linked?

Yes. The following artifacts are available for download at:https://afkm.wpafb.af.mil/community/views/home.aspx?Filter=OO-EA-AF-SE- AFEA AV-1- AFEA Release Talking Paper- AFEA Overview Briefing Slides- AF Enterprise Sequencing Plan (ESP)- AFEA Conte

F. Which strategic goals of the DoD does the candidate architecture align to?

The AFEA model includes the priorities, outcomes, goals, and objectives reflected in the DoD Strategic Management Plan, DoD Performance Report, DoD Enterprise Transition Plan and DoD Information Enterprise Architecture.

G. Is the candidate architecture conformant with DoDAF 2.0, including DM2?

The AFEA is partially conformant. DoDAF v2 (Vol I) states:"DoDAF conformance is achieved when:• The data in a described architecture is defined according to the DoDAF Meta-model (DM2) concepts, associations, and attributes• The architecture data is ca

H. Is the candidate architecture compliant with the business rules of the entities listed that it exchanges data with? (OV-2)

Yes. The architecture does not specifically portray information exchanges among specific entities. The AFEA model does cite the Federal and DoD laws and policies that impact AF IT systems, DoDIEA Business Principles and Rules, and also provides links to

I. Is the candidate architecture compliant with the technical standards listed in the DISR?

Yes. All DISR IT standards are cited in the Technical Reference Model (TRM) portion of the AFEA model.

J. Does the candidate architecture make maximum reuse of the current Enterprise Vocabulary?

No. There is no approved or published Enterprise Vocabulary to reuse.

K. Is the candidate architecture compliant with the DoD Information Enterprise Architecture (DoD IEA)?

Yes, with the exception that it does not currently include DoD mandated Enterprise Services. These will be reflected in the next version of the AFEA. A copy of the completed DoD IEA Compliance Assessment Table is included with this package.

L. Are artifacts attached to substantiate the above? They are not attached. They are available for download from the shared space cited below.

Artifacts List [title & location text field]DoD IEA Compliance Assessment Table Included with this ACP.AFEA Model (and supporting files) https://afkm.wpafb.af.mil/community/views/home.aspx?Filter=OO-EA-AF-SEAFEA Content Metamodel vs DoDAF Metamodel (DM2) Wall Chart

https://afkm.wpafb.af.mil/community/views/home.aspx?Filter=OO-EA-AF-SE

AFEA Compliance Guidance Document https://afkm.wpafb.af.mil/community/views/home.aspx?Filter=OO-EA-AF-SE

Federated Architecture Committee Membership Acceptance Disposition Recommendation

Air Force Enterprise Architecture (AFEA) v3.5 Architecture Certification Package

Levels & Alternatives

CAS Org

Downed Pilot

receivesend

CAS A/C Pilot

SOF Rescue Team

Pilot

CAS A/C Pilot

CAS A/CPilot

owns / employsowns / employs

prescribe constraints and allow design trade-offs at appropriate levels

20 Aug 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• FAC -- went well, 2.02 on track, • JAIWG Arch Federation SWG – still in planning, new team heads,

use cases• IS&T WG – data group is forming

– Upcoming:• OMG Technical Meeting – Cambridge MA• IDEAS mini-meeting in London

– New References: • DoDAF Plenary briefs in Tutorials and Briefings folder• FAC briefs, including DoDAF-DM2 CSAR, in WG folder

• 2.02 Finalization (26 Aug) Status– XSDs, documentation, …

• DoDAF website change process• Prioritization for 2.03• Others:

– Ports (Terebesi)– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms submitted by

Dandashi– Naming pattern, System meaning inputs – Alex– Partitions (they are modeled in IDEAS!)

THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING!

DM2 DoDAF COIIn Ver 2.02 26 26 0 0

In Progress for 2.02 6 3 3 0In Progress for 2.03 23 22 0 1

Unassigned 85 67 18 0Consult IDEAS Group 18 17 1 0

Defer 93 85 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0251 251

CI

Port

Sense in which a Performer• Mouth talking• Computer IO card, controller (e.g.,

a subsystem)

Sense in which a connector (Materiel)• Electrical socket• Hubs, switches• Where – e.g., shipping port

IDEAS Performer

Performer

Port

Port An interface (logical or physical) provided by a System.

(DoDAF/CADM): NodePort: The specification of a physical interface point for a specific Node. (DDDS Counter (19607/1)(A))(NAF): SystemPort: An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for <<SystemPort>>s to be typed. (MM).(Webster's): 1. A data connection in a computer to which a peripheral device or a transmission line from a remote terminal can be attached. 2. An entrance to or exit from a data network. 3. A connection point for a peripheral device.

A port is not independent, depends on the whole to perform.

Port was made an alias. Service Port was left in – still is it location, or piece??? Further work.

The resource(s) being exchanged depends on the resolution, may not be identical

IDEAS Partition

PartitionThe partition model brings together the disjoint and union models to build the basis for partition. The principle is that if a thing is parti tioned, the parti tions must be disjoint, and the union/sum/fusion of the partitions is the Thing that was partitioned.

«IDEAS:Powertype»SuperSubtypeType

«IDEAS:Powertype»CoupleType

«IDEAS:Powertype»WholePartType

«IDEAS:Type»SumOfSetOfThings

«IDEAS:Type»UnionOfSetOfTypes

«IDEAS:Type»FusionOfSetOfIndiv iduals

«IDEAS:Powertype»Indiv idualType

«IDEAS:Powertype»TupleType

«IDEAS:Type»PlaceableType

Thing

«IDEAS:Type»Type

«IDEAS:Type»SetOfDisjointTypes

«IDEAS:Type»SetOfDisjointIndiv iduals

«IDEAS:Type»SetOfDisjointThings

«IDEAS:Type»PartitionOfSetOfDisjointThings

«IDEAS:Type»PartitionOfSetOfDisjointIndiv iduals

«IDEAS:Type»PartitionOfSetOfDisjointTypes

«IDEAS:Type»SingletonIndiv idualType

«IDEAS:Type»Singleton

summed

«place2Type»

«place1Type»

fusioned

«place2Type»

«IDEAS:superSubtype»«IDEAS:superSubtype»

unioned

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«place1Type»

«IDEAS:superSubtype»

partType

«place2Type»

wholeType

«place1Type»

«IDEAS:superSubtype»

«place2Type»{subsets places}

«place1Type»{subsets places}

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

partitions

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

partitions«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

partitions

«place2Type»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

«IDEAS:superSubtype»

*

places

«placeType»

2..*

«IDEAS:superSubtype»

«IDEAS:superSubtype»

13 Aug 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• DoDAF Plenary – Dave post all except AT&L on WG site

(tutorials and briefings) and add DoDAF, MDR, IDEAS, IDEAS blog site and login info to weekly announcement

– Upcoming:• FAC 17 Aug – readahead summary of 2.02

– New References: • none

• 2.02 Finalization (26 Aug) Status• Prioritization for 2.03• Others:

– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms

submitted by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions– Def of CapabilityPhase PLEASE BE ATTENTIVE TO MUTE

WHEN NOT SPEAKING

DM2 DoDAF COIIn Ver 2.02 26 26 0 0

In Progress for 2.02 6 3 3 0In Progress for 2.03 26 25 0 1

Unassigned 85 67 18 0Consult IDEAS Group 15 14 1 0

Defer 92 84 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0250 250

CI

23 July 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• Semantic Interoperability Workshop – Vocabulary

OneSource – distribution mechanism, AV-2, PES – is that the best vocabulary representation – or would OWL be better – Ian knows how to do this, did it before

• INCOSE International Symposium• NR-KPP WG

– Upcoming:• No WG 30 July or 6 Aug – McDaniel vacation;

resume 13 Aug• FAC 3 Aug – readahead summary of 2.02• DoDAF plenary 12 Aug

– New References: • UPDM/bock-ontological-behavior-modeling-

dm2.pdf– A companion paper is available to OMG members at:

http://doc.omg.org/ad/09-08-05

• 2.02 Technical Cutoff– Nomination of Defers (post 2.02’s) &

Unassigned’s urgently needed for 2.02 (Dave and Greg)

– 2.02 in-progress’s nominated for post-2.02 (WG)• Others:

– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms

submitted by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions

PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

DM2 DoDAF COIIn Ver 2.02 15 14 1 0

In Progress for 2.02 38 35 2 1

Unassigned 75 59 16 0Consult IDEAS Group 15 14 1 0

Defer 92 84 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0235 235

CI

2.02’s in Progress(page 1 of 2)

109 Service layers In Progress for 2.02114 Bussiness Rules and Dave Hay In Progress for 2.02 defer to next version115 SBVR In Progress for 2.02 defer to next version129 Timeliness In Progress for 2.02141 SoA Execution Context In Progress for 2.02 defer to next version145 AV-1&2 "template" In Progress for 2.02 defer to next version168 Subtypes and partitions In Progress for 2.02 defer to next version179 Performer vs CapabilityConfiguration In Progress for 2.02326 Example XML docs In Progress for 2.02332 Changing a resource versus producing it In Ver 2.02333 GeopoliticalExtent both a Resource and a Location In Progress for 2.02 defer to next version342 Desired Effect in SoA In Progress for 2.02 defer to next version365 Information and Data: In Ver 2.02383 Rules and Contexts In Progress for 2.02 defer to next version384 XSD documentation In Progress for 2.02393 SOAML In Progress for 2.02 defer to next version395 Prescription of "role", basis of authority In Progress for 2.02 defer to next version396 Is Vision truly distinct from DesiredEffect? In Progress for 2.02 defer to next version

397 How does a ServiceChannel distinguish itself from activityResourceOverlap?

In Progress for 2.02 defer to next version

401 OV-2 Locations In Progress for 2.02

402 External Performer In Progress for 2.02In MODAF, would be known resource. Private action and public actions in Joint action.

404 Information or DomainInformation for SV1, SV10b In Ver 2.02448 Dispositional vs Categorical Properties In Progress for 2.02 defer to next version

454 Condition/ActivityPerformableUnderCondition optional for SV1

In Ver 2.02

456 Rules tied to Measures and Activities In Progress for 2.02 defer to next version457 Agreements, Guidance, Rules have parties In Progress for 2.02 defer to next version

2.02’s in Progress(page 2 of 2)

460 UPDM 3 In Progress for 2.02 defer to next version467 Measures and tuples In Progress for 2.02 Serious470 Person WPT In Progress for 2.02 Serious

471 ServiceDescription desribes ServicePort, not Service In Progress for 2.02 defer to next version

473 UPDM 16 In Progress for 2.02477 SoAML Concepts In Progress for 2.02 defer to next version478 OASIS SOA RAF Concepts In Progress for 2.02 defer to next version480 System vs Service In Progress for 2.02 defer to next version481 Mandatory Service Descriptions and Ports In Progress for 2.02 defer to next version486 ARO as two couples In Ver 2.02

487 Agreement constrains activityPerformedByPerformer In Ver 2.02

Rule is the super of Agreement but not all Agreements are Rules. And Agreement is only a part of a Rule. Related to Rules formal relationship to Activity. 2.02

488 Information Traceability to Data In Progress for 2.02 defer to next version489 APBP redundancy with APUC In Ver 2.02 2.02

490 Source / agreement / rule associated representation schemes In Progress for 2.02 defer to next version

494 Info Type and Data Type In Progress for 2.02

501 Capability Phase <> Enterprise Phase In Ver 2.02

Capability should be a dispositional type whereby it doesn't have start and stop times

508 Forking under Conditions In Progress for 2.02 defer to next version

509 How to indicate methodology-dependent subclasses In Ver 2.02

526 UPDM Markup the enterprise phases should be Project phases In Ver 2.02

528 Statemachine diagram In Progress for 2.02 defer to next version530 Desired effect aliases In Progress for 2.02 defer to next version547 Units In Ver 2.02551 Placeable types In Ver 2.02552 TI between Couple Type and PT In Ver 2.02553 Overlap In Ver 2.02558 visionIsRealizedByDesiredEffect In Ver 2.02559 Keep number of diagrams manageable In Progress for 2.02

Sendpart

Receivepart

Flow process

Dave

Ian

Dave

’s D

ocum

ent,

Orig

Dave’s Document, Copy 1, in flow state

Copy

Copy and SendDa

ve’s

Doc

umen

t, co

py 1

Dave

’s D

ocum

ent,

copy

1Dave’s Doc Ind Type = {Orig, Copy1, Copy2, …}

Dave’s Doc Ind Type Orig = {Orig}Dave’s Doc Ind Type Copies = {Copy1, Copy2, …}

Can go into very precise modeling using temporal parts (states)

time

Joint Action: Fatma Selling Cup to Dave

Buyer(PersonType) Seller

(PersonType)

Fatma(Person)

typeInstance

TransferHandover

HandtakeDave(Person)

typeInstance

Transfer

Handtake

Handover

ActivityTypes

Cash (ResourceType) Cup (MaterielType)

time

16 July 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• DoD MD Working Group – Guy Caron• DoD COI Forum – Guy Caron• INCOSE International Symposium, to be held 12 - 15 July

Chicago• FAC cancelled

– Upcoming:• Small group for DODAF table for CJCSI 6212.01F (DODI 4630

I&S applies to everything)– New References:

• DoD Governance / Architecture Types Matrix• NIST Conrad Bock OMG brief• System source def – (Gene Bellinger): A system is an

entity that maintains its existence through the mutual interaction of its parts. -- Putman

• Preparation for 2.02 Technical Cutoff:– Recap of process to 26 Aug – production, QA, VDD for

FAC, publish to sites (MDR, dko, cio-nii.defense.gov, SIPR)– Review In-Progress AI’s– Defers, Unassigned urgently needed for 2.02?

• See Walter Pierce email• Others:

– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms submitted

by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions

PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

DM2 DoDAF COI

In Ver 2.02 4 4 0 0

In Progress for Next Version 53 49 3 1

Unassigned 71 56 15 0Consult IDEAS Group 15 14 1 0

Defer 87 79 5 3Rejected 0 0 0 0

No Action Required 0 0 0 0230 230

CI

Ver 2.00 and 2.01 AI’s archived

405 Physical and Temporal Measures for SV10b

Materiel NeedlineExchangeItem/Artifact

nonICmarkings Attribute

PerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraint

PhysicalMeasure MeasureOfPerformance

Plan ProjectSequence, MilestoneSequence

PolygonArea LocationType

RateThroughput MeasureOfPerformance

releasableTo Attribute

RuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraint

ServiceEnablesAccessTo ServiceConsumer

ServicePort ServiceInterface

Skill Competence

"DM2 Concepts, Associations,

and Attributes"Composite Definition

AV-1

AV-2

OV-1

OV-2

OV-3

OV-4

OV-5a

OV-5b

OV-6a

OV-6b

OV-6c

SV-1

SV-2

SV-3

SV-4

SV-5a

SV-5b

SV-6

SV-7

SV-8

SV-9

SV-10a

SV-10b

SV-10c

PhysicalMeasure

A category of measures of spatio-temporal extent of an Individual such as length, mass, energy, velocity, …

n o     n     o o n n o o o o     n o o o o n n

TemporalMeasure A type of measure of time n       n     o o n n o o o o     n o o o o n n

405 Physical and Temporal Measures for SV10b

Materiel NeedlineExchangeItem/Artifact

nonICmarkings Attribute

PerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraint

PhysicalMeasure MeasureOfPerformance

Plan ProjectSequence, MilestoneSequence

PolygonArea LocationType

RateThroughput MeasureOfPerformance

releasableTo Attribute

RuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraint

ServiceEnablesAccessTo ServiceConsumer

ServicePort ServiceInterface

Skill Competence

Move

Reported Location Reported Condition

Mar

itim

e R

escu

e U

nit

MR

T Se

arch

er Reassure Victim Apply First Aid Recover Victim

Determine Destination

Name

Updated Condition

Transport

Updated Location

An Event or Trigger in DoDAF 2 is akin to a near-zero duration Activity

Bounding box differentiates internal from external Performers

Legend:

Person Type

Time

Activities performed by Performer

Performer (aka Capability Configuration)

Activities

Information

Consume (Activity)

Produce (Activity)

Just a diagramming shortcut

Before-After

Resource Flow

406 Rename/Def change for desiredEffect structure

class Goals

Performer

IndividualType

Resource

TemporalWholePartTypedesiredEffectWholeResourcePartType

OverlapTypedesiredEffect

Property

Measure

+ numericValue: string

MeasureOfEffect

measureOfTypeeffectMeasure

MeasureOfDesire

desiredFutureResourceState

desirer

howMuchDesired

subtype

supertype

desiredEffect A desired state of a Resource

Objective

A clearly defined, decisive, and attainable end toward which every operation is directed. An objective is a specific, time-targeted, measurable, and attainable target that an enterprise seeks to meet in order to achieve its goals.

Desired Result, Effect, Outcome, Consequence

(See above) (BMM Concept Catalog): An end that is a specific time-targeted, measurable, attainable target that an enterprise seeks to meet in order to achieve its goals.Dictionary Basis: something toward which effort is directed: an aim or end of action [MWUD 'objective' (1)] Note: Compared to a goal, an objective is: short-term; not continuing beyond its time frame (although such time frames can be cyclical – monthly, quarterly, etc.). objective quantifies goal Definition: objectives provide the basis for measures to determine that progress is being made towards a goal.

407 CapabilityType and other Type TypesIDEAS Domain Class Hierarchy

MeasureType

+ units: string

InformationType

DataType

NameType

RepresentationType

CapabilityType

ActivityType

IDEAS Capability

IndividualType

Activity

Type

CapabilityTypeOverlapType

activityMapsToCapabili tyType

activityMapsToCapabilityType Represents that an activity was / is / can-be/ must-be conducted under certain conditions with a spatiotemporal overlap of the activity with the condition.

408 activitySuperSubtypeOfMeasureType DefIDEAS Measure

Type

MeasureType

+ units: string

superSubtypeactivitySuperSubtypeOfMeasureType

Activity

IDEAS Measure

superSubtypepropertyOfType

measureOfType

activitySuperSubtypeOfMeasureType activityType is a member of MeasureType

409 ARO irrelevent piecesIDEAS Domain Class Hierarchy

Data

Materiel

System

OrganizationType

Service

Information

Performer

Resource

PersonType

DomainInformation

Port

ServiceDescription

ServicePort

PositionReferenceFrame

GeoPoliticalExtentType

CountryType

RegionOfCountryType

InstallationType

FacilityType

RealPropertyType

SiteType

GeoFeatureType

RegionOfWorldType

ArchitecturalDescription

410 Missing relationshipsIDEAS Foundation for Associations

BeforeAfterTypeOverlapType

WholePartType

couple

namedBy

powertypeInstance

Thingtuple

typeInstance

describedBy

serviceEnablesAccessToResource

activityPerformableUnderCondition

activityResourceOverlap

activityPartOfCapabi li ty

activityPerformedByPerformer

associationOfInformation

activityChangesResource

desiredEffectOfCapabil ity

desiredEffectDi rectsActivity desiredEffectIsRealizedByProjectTypematerielPartOfPerformer

capabili tyOfPerformer

personTypePartOfPerformer portPartOfPerformer

ruleConstrainsActivi ty

ruleConstraintOfActivityVal idUnderCondition

ski llOfPersonType

visionIsRealizedByDesiredEffect

measureOfTypeActivityChangesResource

measureOfTypeActivityPartOfCapabi lity

activityPartOfProjectType

measureOfTypeActivityPerformableUnderCondition

measureOfTypeActivityPerformedByPerformer

ruleConstrainsActivityPerformedByPerformer

measureOfTypeActivityResourceOverlap

activi tyResourceOverlapSuperSubtypeOfRule

activitySuperSubtypeOfMeasureType

axesDescribedBy

measureOfTypeCondition

coordinateCenterDescribedBy

resourceInLocationType

linePartOfPlanarSurface

locationNamedByAddress

measureOfIndividualPoint

pointPartOfLine

pointPartOfPlanarSurface

measureOfTypeProjectType

regionOfCountryPartOfCountry

measureOfTypeResource

rulePartOfMeasureType

measureOfTypeWholePartType

Foundation For Associations

WORKING DRAFT

faci li tyPartOfSite

si tePartOfInstallation

EndBoundaryType

StartBoundaryType

TemporalBoundaryType

measureOfIndividualEndBoundary

measureOfTypeEndBoundaryType

measureOfIndividualStartBoundary

measureOfTypeStartBoundaryType

desiredEffectWholeResourcePartType

Type

TupleType

WORKING DRAFT

wholePart

TemporalWholePartType propertyOfType

superSubtype

CoupleType

measureOfType

representedBy

desiredEffect

measureOfIndividual

propertyOfIndividual

informationPedigree

effectMeasure

individualResourceInLocation

measureableSkillOfPersonType

activityMapsToCapabilityType

servicePortDescribedBy

503 Org/OrgType WP(T) Performer

tupleCAPABILITY

typeACTIVITY

typeCONDITION

typeMEASURE

tupleactivityPerformableUnderCondition

tuplemeasureOfTypeActivityPerformableUnderCondition

typeResourceTemporalState

tuplemeasureOfTypeResource

State of Resource

To produce a desired effect (State of Resource)

CAPABILITY MODEL

Many-to-many

Many-to-many

(t3, )Taliban peace loving

state

Make peace

(t1, t2) (Taliban are

mean)

Whole-life of Taliban

(t3, )Taliban rule the world

today future

Taliban in skinny state

question

Says: apuc motapuc

001: (002, 003)

004: (001, 005)

006: (007, 004: (001: (002, 003), 005)

002

003

question

9 July 2010 DoDAF - DM2 WG Agenda• Announcements:

– This week:• NR KPP WG – Table E revision, deeper dive for data, not view – need to

know what data being used in the analysis and decisions; 11 ?’s; subWG– Upcoming:

• INCOSE International Symposium, to be held 12 - 15 July Chicago. • MDR WG and COI Forum• FAC next Tuesday

– New References: • In CJCSI folder:

– Working draft of CJCSI 6212.02F– DoDAF brief to NR KPP WG

• Urgent AI for 2.02– 546 -- Properties and Measures Need to complete adoption of

IDEAS model for this, basically using inheritance to allow all individuals and individual types to have properties and measures

– ARO• Sub-working group for DoDAF models descriptions cleanup• New submissions by members:

– SV-1 QA Problem Status Update• Preparation for 2.02 Technical Cutoff:

– Review new Action Items, 66 of them – 7 teed up in read-ahead• Others:

– JMT Use Case (Vicense)– Capability model (Terebesi)– SoA High-Pri issues (Ellis) – inc. SoAML terms submitted by Dandashi– Naming pattern, System meaning inputs – Alex– Partitions

PLEASE BE ATTENTIVE TO MUTE WHEN NOT

SPEAKING

In Ver 2.00 231In Ver 2.01 72

Other Done 1In Progress for Next

Version 61

Rejected 0No Action Required 0

Unassigned 77Consult IDEAS Group 14

Defer 89545

ParticularIndividuals MeasuresParticularIndividualTypes Measures

IDEAS DM2 Diagrams

Measure

+ numericValue: string

Type

IndividualType

Property

superSubtypepropertyOfType

measureOfTypemeasureOfIndividual

typeInstancepropertyOfIndividual

Thing

Individual

Also related to 408 activitySuperSubtypeOfMeasureType Def441 The Measures model in DM2 differs from the Measures model IDEAS450 rulePartOfMeasureType451 measureOfTypeWholePartType467 Measures and tuples497 Measures506 LocationType Measures

“Forrest’s cube”

“x”

MeasureTypeunits

“weight in lbs”

Forrest’s cube {individuals | measure =1 & measureType = weight in lbs}

Concept

R e so u rc e F low

T e m p o ra l

R e la t io n s h ip

B o xe s* a nd L in es(in c . a n n o ta t io ns a nd "s w im lan e s ))

A llo ca tionO w n e rs h ipS u pp o rtsC o m m a n dsIn te rfa c es / in te ro p era tes

M a tric e s(in c. in de n te d te x t)

p a rt-o fp ro p e rty ("h a s ")p e rfo rm s

O b je cts ** ins id e o th e rs(p a rt-o f, "h a s", p e rfo rm s)

C o nd ition a l Lo g ic

T a b u la r R e s o urc e F low(in c . a n no ta tio n s)

T re e(in c. in de n te d te x t)

E A P re sen ta tio n Typ es

AV-1AV-2OV-1OV-2OV-3OV-4OV-5aOV-5bOV-6aOV-6bOV-6cSV-1SV-2SV-3SV-4

SV-5aSV-5bSV-6SV-7SV-8SV-9

SV-10aSV-10bSV-10cSvcV-1SvcV-2

SvcV-3aSvcV-3bSvcV-4SvcV-5SvcV-6SvcV-7SvcV-8SvcV-9

SvcV-10aSvcV-10bSvcV-10cStdV-1StdV-2PV-1PV-2PV-3CV-1CV-2CV-3CV-4CV-5CV-6CV-7DIV-1DIV-2DIV-3

X

*Actually can be any geometric shape, e.g., rectangle, ellipse, etc.** e.g., boxes, text phrases

Res

ourc

e Fl

ow

Tem

pora

l

Ann

otat

ions

/ sw

imla

nes

Rel

atio

nshi

p

part

-of

prop

erty

("ha

s")

perf

orm

s

Allo

catio

n

Ow

ners

hip

(par

t-of)

Supp

orts

(ove

rlap)

App

lies-

to (p

rope

rty)

Com

man

ds

Inte

rfac

es /

inte

rope

rate

s

AV-1 Overview and Summary Information

Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.

AV-2 Integrated Dictionary

Architecture data repository with definitions of all terms used throughout the architecture data and presentations. x

OV-1: High Level Operational Concept Graphic

High-level graphical/textual description of operational concept

OV-2: Operational Connectivity Description

Operational connectivity and iresource flow needlines x o o

OV-3: Operational Resource Flow Matrix

Information exchanged and the relevant attributes of that exchange x

OV-4: Organizational Relationships Chart

Organizational, role, or other relationships among Organizations x

OV-5a: Activity Decomposition Tree

Activities and their decomposition hierarchy. x

OV-5b: Activity ModelCapabilities, activities (operational activities), relationships among activities, inputs, and outputs; overlays can show cost, performers or other pertinent information

x o

Tree

(inc

. ind

ente

d te

xt)

Tabu

lar R

esou

rce

Flow

w /

Ann

otat

ions

Boxes and Objects Matrices (inc.

Con

ditio

nal L

ogic

First Pass – High Level

.

.

.

Next Pass – Add Notes

Res

ourc

e Fl

ow

Tem

pora

l

Ann

otat

ions

/ sw

imla

nes

Rel

atio

nshi

p

part

-of

prop

erty

("ha

s")

perf

orm

s

Allo

catio

n

Ow

ners

hip

(par

t-of)

Supp

orts

(ove

rlap)

App

lies-

to (p

rope

rty)

Com

man

ds

Inte

rfac

es /

inte

rope

rate

s

AV-1 Overview and Summary Information

Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.

AV-2 Integrated Dictionary

Architecture data repository with definitions of all terms used throughout the architecture data and presentations.

For DoDAF 2 principal concepts (see CDM)

OV-1: High Level Operational Concept Graphic

High-level graphical/textual description of operational concept

OV-2: Operational Connectivity Description

Operational connectivity and iresource flow needlines

Orgs, Org Types, Person Types

Activities, Resources, Metrics

Orgs, Org Types, Person Types

Tabu

lar R

esou

rce

Flow

w /

Ann

otat

ions

Tree

(inc

. ind

ente

d te

xt)

Boxes and Lines Objects inside others (inc. Matrices (inc. indented text)

Con

ditio

nal L

ogic

.

.

.

To Complete• Use notes version to add text to end of each model

description– Part 1 – purpose in the 6 core processes– Part 2 – DM2 elements– Part 3 – Diagram notes– Part 4 – Reification, traceability, etc. notes

• A new section with generic descriptions, e.g., next slide

Example: Resource Flow Boxes and Lines

Sender / ProducerNOTE 1

Receiver / Consumer

Annotation1NOTE 2

Annotation2...

Resources NOTE 4

NOTE 1: Performer (where the send & receive activities are implied) or ActivitiesNOTE 2: Activities performer by Performer, Performers that perform the Activities, Standards / Rules, Metrics, and/or ConditionsNOTE 3: Annotations can be placed anywhere understandable, some can be done by “swimlanes”, and/or could be described separately in matrices, indented text, or other forms.NOTE 4: Including Resource States

Annotation1NOTE 3

Annotation2...

SV-1 Issues• Name: Systems Interface Description• One liner: The identification of systems, system items, and their interconnections.• Description:

– composition and interaction of Systems– links together the operational and systems architecture models -- a SV-1 may represent

the realization of a requirement specified in an OV-2 -- traceability & reification– there may be many alternative SV models that could realize the operational requirement. –

what does this have with the model description? True of anything– in an “As-Is” architecture, the OV-2 may simply be a simplified, logical representation of

the SV-1 to allow communication of key Resource Flows to non-technical stakeholders – again T&R – part of any xV

– A System Resource Flow is a simplified representation of a pathway or network pattern,

– Note that Resource Flows between Systems may be further specified in detail in SV-2 (why wouldn’t you just do a more detailed SV-1?, SV-2 show’s comms means?) Systems Resource Flow Description and SV-6 Systems Resource Flow Matrix (not just “more detail”, adds details about the resources that flow and measures and rules associated with that resource’s flow).

– Sub-System assemblies– SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are

deployed– optionally overlay Operational Activities and Locations – In many cases, an operational activity and locations depicted in an OV-2 may well be the

logical representation of the resource that is shown in SV-1.– The SV-1 is used in two complementary ways:

• Describe the Resource Flows exchanged between resources in the architecture. • Describe a solution, or solution option, in terms of the components of capability and

their physical integration on platforms and other facilities.

SV-1 IssuesDetailed Description:• Either could be modeled first, but usually an iterative approach is used to model these together gradually

building up the level of detail in the System description. • Note that the same type (class) of resource may be used in different contexts in a given SV-1. For this

reason, the tracing of functions to resources is specified in context of their usage (see DM2 for details).• addresses Resource Flows. A Resource Flow, as depicted in SV-1, is an indicator that resources pass

between one System and the other. • In the case of Systems, this can be expanded into further detail in SV-2 Systems Resource Flow

Description.• Interactions are only possible between Systems and Services. • System Resource Flows provide a specification for how the operational Resource Flows Exchanges

specified in Needlines are realized with Systems. • A single Needline shown in the OV-2 Operational Resource Flow Description model may translate into

multiple System Resource Flows. • The actual implementation of a System Resource Flow may take more than one form (e.g., multiple

physical links). • Details of the physical pathways or network patterns that implement the interfaces are documented in SV-

2. • System Resource Flows are summarized in a SV-3b. • The functions performed by the resources are specified in a SV-4, but may optionally be overlaid on the

Resources in a SV-1.• An Operational Viewpoint (OV) suite may specify a set of requirements – either as a specific operational

plan, or a scenario for procurement. • As OV-2 and OV-5 specify the logical structure and behavior, SV-1 and SV-4 specify the physical

structure and behavior • separation of logical and physical presents • The structural and behavioral models in the OVs and SVs allow architects and stakeholders to quickly

ascertain which functions are carried out by humans and which by Systems for each alternative specification and so carry out trade analysis based on risk, cost, reliability, etc.

SV-1 IssuesDetailed Description:• Systems and sub-systems • The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact

with Systems. • Capability and Performers which is used to gather together systems, assets and people into a configuration,

which can meet a specific capability. • A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary

sub-systems, performer and activities (functions) and their interactions. • SV-1 contributes to user understanding of the structural characteristics of the capability.• The physical resources contributing to a capability are either an organizational resource or a physical asset,

i.e., a system cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both).

• Organizational aspects can now be shown on SV-1 (e.g., who uses System). • Resource structures may be identified in SV-1 • DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a

position relative to a structural hierarchy. • Any System may combine hardware and software or these can be treated as separate (sub) Systems.

DoDAF V2.0 includes human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.

• optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2

• shows Systems, Physical Assets and System interfaces for the entire Architectural Description on the same diagram.

• Some Resources can carry out System Functions (Activities) as described in SV-4• these functions can optionally be overlaid on a SV-1. • the SV-1 and the SV-4 model provide complementary representations (structure and function).

SV-1 Content Guidance for Template and Description Streamlining: AI#535

• Severn distinct pieces are currently described. They should be broken out as follows::1. SV-1a Interface Description. The SV-1a describes interfaces

(Resource Flows) between Systems, Services, and/or Person Types. Can have multiple levels of detail.

2. SV-1b Perfomer Configuration. Interface Description plus composition (whole-parts) of Resources involved. If Locations are involved in the configuration, relationships to Resources.

3. SV-1c Functional Allocation. Activities (System Functions) performed by Systems, Services, and Person Types.

4. SV-x Organizational Resources. Shows Resources that are part of (whole-part) Organizations.

5. SV-x Organizational Dependencies. Shows Organizations whose Activities are reified by System Functions (Activities) performed by Performer Configurations.

6. Systems relationship to Capabilities – already in SV-57. All views should show traceability to higher-order reifications, other

views that constitute requirements, and/or other non-view requirements. This should be restated for just about every model.

Enterprise Architect to DM2 Mapping and Measures Use Case

Dr. David DryerMr. Johnny Yohman

Mr. Walter PierceVisense

[email protected]

2 July 2010 1st DoD EA COI Data Management Working Group (DMWG) Agenda

• Announcements:– New Members: – This week:

• IDEAS, OMG email trails on Milestones, Projects, PES, XMI, …

– Levine to contact Bailey re XSD generator and IDEAS plugin

– Upcoming:• 12 August 2010 DoDAF Plenary• DARS Users and Vendors Day 28-29 June

– Services to meet re DARS rqmts, DARS “compliant”, put what in DARS, R = repository, registry, or both

– AV-1 XML X DM2• MDR WG and COI Forum

• New References: – none

• New submissions by members:– N/A

• DoD EA COI Charter– Step through 8320.02G and relate to DoD EA COI– Action Items for next quarter’s meeting

• Others:– TBS

PLEASE BE ATTENTIVE TO MUTE WHEN NOT

SPEAKING

Table C2.T1. Key COI Attributes• Formed to meet a specific data

sharing mission or fulfill a task• Composed of stakeholders

cooperating on behalf of various organizations, with emphasis on cross-Component activities

• Members committed to actively sharing information in relation to their mission and/or task objectives

• Recognize potential for authorized but unanticipated users and therefore, strive to make their data visible, accessible, and understandable to those inside and outside their community.

Relevance / meaning to DoD EA COI• Reuse, compliance (solutions, C&A),

interoperabilty, net-centricity, data sharing, federation, solutions arch standization, … in support of the 6 core processes (JCIDS, DAS, PPBE, CPM, SE, Ops Plng)

• CSA’s, CIOs, Acq’s, inter-agency (at specific reification / meta levels), PM’s,

• Governance, e.g., DTM-93, CJCSI’s 6212.01F & 3170, NCSS, NCDS, DODD/I 4630, Arch DoDI, DISA cross-agency (DHS, NGO’s)

• Visible -- DARS, NCES Enterprise Search, MDR, DISR,

• Understandable -- DM2, UCORE, IDEAS

• Accessible – SSO, Intelipedia (U), … distribution restrictions, aggregation problem, pedigree

Table C2.T2. Primary Responsibilities of COIs• Identify data assets and information sharing

capabilities, both operational and developmental, that should conform to the data strategy goals of NCDS.

• Identify approaches to enable those data assets and information sharing capabilities to satisfy data strategy goals and to measure the value to consumers of shared data.

• Develop and maintain semantic and structural agreements to ensure that data assets can be understood and used effectively by COI members and unanticipated users.

• Register appropriate metadata artifacts for use by the COI members and others.

• Extend the DoD Discovery Metadata Specification (DDMS) (Reference (c)) as required to ensure that COI-specific discovery metadata is understandable for enterprise searches.

• Partner with a governing authority, as appropriate, to ensure that COI recommendations are adopted and implemented through programs, processes, systems and organizations

Relevance / meaning to DoD EA COI• Naval Architecture Repository System

(NARS), MCAE, CADIE, SADIE?, JACAE, AF?, DLA?, AMC?, EISP DB? BEA encyclopedia, TV repository in DISR?…all sorts of other locations, e.g., sharepoints, legacy fileservers – in future DM2 PES XML files

• % completeness, # registered users & level of activity in COI,

• DM2, IDEAS, DoDAF, UCORE-relationship, DDMS-relationship

• DM2 CDM, LDM, PES XSD, and documentation registered in MDR in Arch namespace

• Need to develop discovery use cases, DARS rqmt?, register extensions in MDR, IC? 500-21 IRM 1.0 maps to DDMS 2.0, cross-domain discovery and retrieval

• FAC, Army NCDS ideas (ADTP, Army Data Transformation Plan)

Table C2.T3. Summary Descriptions of COI RolesROLE DESCRIPTION Who / How in DoD

EA COI?

COI Governing Authority

Individual or organization that will review and adjudicate COI conflicts and push for DoD Component implementation and support of COI data sharing agreements. The appropriate governance forums and authorities may already exist and should be leveraged where possible. This role is typically filled by the Mission Area lead, but in the initial stages of operationalizing portfolio management, may also be a Combatant Command or Functional Support Agency (e.g., DLA). The COI governing authority acts as an external champion with authority and cross-COI visibility to affect change. Responsibilities:Identify information sharing problems and COI missionsReview and adjudicate resolution of discrepancies across COIsPromote and endorse COI activities and implement agreements through the Joint Capabilities Integration and Development System, Acquisition, and Planning, Programming, Budgeting, and Execution processPromote COI support to DoD ComponentsReview COI plan of action and milestones (POAM) status and success measures

COI Lead An individual from a specific DoD Component who has been tasked with managing the COI. Generally, the organization leading the COI activity has committed to driving the COI to a data sharing solution and will advocate that data sharing agreements be implemented within DoD Component plans, programs, and budgets. The COI lead helps address internal COI conflicts and issues, keeping the COI on track.The COI lead role may be established on a shared or rotating basis, and should be filled by a functional expert, rather than an IT specialist.Responsibilities:Ensure that appropriate stakeholders participate in COIs via COI working groups, and appropriate representatives participate via the governing authorityLead the COI, including developing and tracking POAMsAct as a primary point of contact (POC) for the COIPromote policies and practices for data sharing and participating in cross-Component COIsIdentify mission-specific success criteria for the COI

COI Stakeholders

Organizations or personnel who have an interest in the outcome of the COI effort. These may not be active participants in the COI, but will likely use and/or benefit from the capability, such as data consumers.COI stakeholders are those who stand to benefit, and those whose processes and/or systems will change, as a result of COI activity.Responsibilities:Promote policies across DoD Components in terms of practices and standards in the implementation areas, including those for data tagging, data access services, and registration of metadata artifactsPromote the reuse of data access services within programs and systemsTrack DoD Component implementation of Reference (a) through COI activitiesEnsure operator/end-user views and needs are represented in COI semantic and structural agreements, contribute to COI requirements gathering processes, and provide feedback on COI-defined information sharing capabilities

Table C2.T3. Summary Descriptions of COI RolesROLE DESCRIPTION Who / How in DoD EA COI?

Capability Developers

Personnel or organizations responsible for serving as the technical representative and implementing the data sharing agreements (e.g., data access services), and applying technical approaches (e.g., tools for associating discovery metadata with data assets).Capability developers are the critical COI participants that turn COI agreements and requirements into live information sharing capabilities.Responsibilities:Identify technical requirements for supporting information sharing capabilities (e.g., common tagging tools) and recommend the necessary programming and budgeting changes for supporting them efficientlyParticipate in COI working groups, particularly as they relate to architectures, standards, and technical specificationsIdentify implementation alternatives, including common or reusable services or technical capabilitiesIdentify technical impacts of COI agreements, for example the impact of a data access service on system performance to critical usersImplement and maintain agreed-upon capabilitiesEnsure operator/end-user views and needs are represented in COI semantic and structural agreements

Data Producers

A program, organization, or person that controls, creates, and/or maintains data assets within the Department. These are typically the DoD Component program managers and system owners who provide the resources to implement data sharing agreements within their programs.

Subject Matter Experts

Individuals who represent specific operators and possess knowledge of their business processes.Responsibilities:Ensure operator/end-user views and needs are represented in COI semantic and structural agreementsAdvise the governing authority on subject matter prioritiesPromote use of COIs to solve data sharing problems and advocate for implementation of COI agreementsAssist in the identification of mission-specific value measures for COI success

Duties• COI FORMATION AND

EXECUTION– ESTABLISH AND EVOLVE A

COI– COI MANAGEMENT AND

GOVERNANCE– CAPABILITY PLANNING AND

USER EVALUATION• DATA SHARING

IMPLEMENTATION– MAKING DATA VISIBLE– MAKING DATA ACCESSIBLE– MAKING DATA

UNDERSTANDABLE– PROMOTING TRUST

• Relevance / meaning to DoD EA COI