11 September DM2 TWG Agenda - silverbulletinc.com€¦ · PPT file · Web viewDraft DODI 8320.02-M...
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
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
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