1.07k likes | 1.09k Views
This agenda outlines upcoming meetings, model submissions, and new references for the DoDAF-DM2 Working Group. Learn about model consistency suggestions and how to differentiate between systems and services. Explore examples and definitions for better understanding. Additionally, find information on how to align model descriptions and improve conformity. Stay updated on relevant topics and upcoming events.
E N D
1 Oct 2010 DoDAF - DM2 WG Agenda THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING! • 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?
http://en.wikipedia.org/wiki/Relation_reduction Relation Reduction of 3-adic to 2-adic examples. DM2 Use-Case Let 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
Graph 2 ActivityResourceFlowSet2 = {(1,r1,4),(3,r1,2)} Table 2 Table form of ARFS2 “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)
Table 4 proj_apr(ARFS2) Set of ActivityConsumesResource = Projr,ac(ActivityResourceFlowSet1)={(r1,2),(r1,4)} = Projr,ac(ActivityResourceFlowSet2). Table 5 proj_rac(ARFS1) Table 6 proj_rac(ARFS2) 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 time Buyer (PersonType) Seller (PersonType) Transfer Handover Dave (Person) Handtake typeInstance Fatma (Person) typeInstance Transfer Handover Handtake ActivityTypes Cash (ResourceType) Cup (MaterielType)
Can go into very precise modeling using temporal parts (states) time Dave Dave’s Document, Copy 1, in flow state Copy and Send Ian Copy Dave’s Document, copy 1 Flow process Send part Receive part Dave’s Document, Orig Dave’s Document, copy 1 Dave’s Doc Ind Type = {Orig, Copy1, Copy2, …} Dave’s Doc Ind Type Orig = {Orig} Dave’s Doc Ind Type Copies = {Copy1, Copy2, …}
579 Inconsistent Model DescriptionsPlease align model descriptions tohttp://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.
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 THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING! • 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?
New IDEAS Overlap Involves Intersection Familiar to Rex
Example • Next time walk through in more detail. • Be aware of concepts in geopolitical notations – GML. • OASIS Customer Information Quality (CIQ)
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
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. Systems and Services in DoDAF 2 • 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-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
Capability Data Group CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
Core Components of Capability CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-1 Vision CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-2 Capability Taxonomy CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-3 Capability Phasing CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-4 Capability Dependencies CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-5 Cap to Org Development CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-6 Capability/Activities CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
CV-7 Capability/Services CV-3 Capability Phasing CV-2 Capability Taxonomy CV-4 Capability Dependencies CV-1 Vision CV-6 Capabilities to Operational Activities Mapping CV-5 Capability To Organizational Development Mapping CV-7 Capabilities to Services Mapping
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. Model Categories ≠ Presentation Types (AI # 557)
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” />
10 Sept 2010 DoDAF - DM2 WG Agenda THANK YOU FOR BEING ATTENTIVE TO MUTING WHEN NOT SPEAKING! • 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?
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 ProjectRex Brooks09 June, 2010
Human View Product DescriptionsMoDAF Follow-on questions extend MoDAF Human Views Who could be made available? Which Personnel processes are needed? Does it match those that are being used? 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? How may human-related benefits be expressed and measured? Do we use quantitative and qualitative measures? NO UNIFYING CENTRAL CONCEPT Value of Human View is to Organizational and Operational Performance 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? Which human activities are to be supported by technology functions, and how should humans and technology complement each other? Adapted from Dr Anne Bruseberg, Systems Engineering & Assessment Ltd., Human Factors Integration Defence Technology Centre