1 Oct 2010 Do DAF — DM 2

1 Oct 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • DM 2 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) Do. DAF 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 – So. A 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!

http: //en. wikipedia. org/wiki/Relation_reduction Relation Reduction of 3 -adic to 2 -adic examples. DM 2 Use-Case Let Ap={a 1, a 3}, and Ac={a 2, a 4} where each ap in Ap is a producing Activity and each ac in Ac is a consuming Activity. Let R = {r 1 } where each r in R is a Resource. Let an Activity. Resource. Flow. Set 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 Activity. Resource. Flow. Sets. Graph 1 Activity. Resource. Flow. Set 1 = {(1, r 1, 2), (3, r 1, 4)} Table 1 Table form of ARFS 1 ap r ac 1 r 1 2 3 r 1 4

Graph 2 Activity. Resource. Flow. Set 2 = {(1, r 1, 4), (3, r 1, 2)} Table 2 Table form of ARFS 2 ap r ac 1 r 1 4 3 r 1 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 Activiyt. Resource. Flow. Set 1 and Activity. Resource. Flow. Set 2. Set of Activity. Produces. Resource = Projap, r(Activiyt. Resource. Flow. Set 1) = {(1, r 1), (3, r 1)} = Proj ap, r(Activiyt. Resource. Flow. Set 2). Table 3 proj_apr(ARFS 1) ap r 1 3 r 1

Table 4 proj_apr(ARFS 2) r ap 1 r 1 3 r 1 Set of Activity. Consumes. Resource = Projr, ac(Activity. Resource. Flow. Set 1)={(r 1, 2), (r 1, 4)} = Proj r, ac(Activity. Resource. Flow. Set 2). Table 5 proj_rac(ARFS 1) ac r r 1 2 r 1 4 Table 6 proj_rac(ARFS 2) r ac r 1 4 r 1 2 Without considering Projap, ac(Activity. Resource. Flow. Set), Activity. Resource. Flow. Sets 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 Activity. Resource. Flow to be reduced carries a unique Resource, the resulting Activity. Resource. Flow. Set can be reduced without ambiguity.

Joint Action: Fatma Selling Cup to Dave time Handover Transfer type. Instance Dave (Person) Handtake Fatma (Person) type. Instance Buyer (Person. Type) Seller (Person. Type) Transfer Handover Handtake Activity. Types Cash (Resource. Type) Cup (Materiel. Type)

Can go into very precise modeling using temporal parts (states) Dave Copy and Send time Dave’s Document, Copy 1, in flow state Ian Send part Flow process Receive part Dave’s Document, copy 1 Dave’s Document, Orig Copy Dave’s Doc Ind Type = {Orig, Copy 1, Copy 2, …} Dave’s Doc Ind Type Orig = {Orig} Dave’s Doc Ind Type Copies = {Copy 1, Copy 2, …}

1. 579 Inconsistent Model Descriptions Please align model descriptions to http: //cio-nii. defense. gov/sites/dodaf 20/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 Do. DAF V 1. 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 Do. DAF V 1. 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-5 a: Operational Activity Decomposition Tree The capabilities and activities (operational activities) organized in a hierarchal structure. OV-5 b: 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-6 a: Operational Rules Model One of three models used to describe activity (operational activity). It identifies business rules that constrain operations. OV-6 b: 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-6 c: 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 the specific projects and program elements help to achieve a capability.

Svc. V-1 Services Context Description The identification of services, service items, and their interconnections. Svc. V-2 Services Resource Flow Description A description of Resource Flows exchanged between services. Svc. V-3 a Systems-Services Matrix The relationships among or between systems and services in a given Architectural Description. Svc. V-3 b 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). Svc. V-4 Services Functionality Description The functions performed by services and the service data flows among service functions (activities). Svc. V-5 Operational Activity to Services Traceability Matrix A mapping of services (activities) back to operational activities (activities). Svc. V-6 Services Resource Flow Matrix It provides details of service Resource Flow elements being exchanged between services and the attributes of that exchange. Svc. V-7 Services Measures Matrix The measures (metrics) of Services Model elements for the appropriate time frame(s). Svc. V-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. Svc. V-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. Svc. V-10 a 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. Svc. V-10 b Services State Transition Description One of three models used to describe service functionality. It identifies responses of services to events. Svc. V-10 c 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. Std. V-1 Standards Profile The listing of standards that apply to solution elements. Std. V-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-5 a Operational Activity to Systems Function Traceability Matrix A mapping of system functions (activities) back to operational activities (activities). SV-5 b 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-10 a 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-10 b Systems State Transition Description One of three models used to describe system functionality. It identifies responses of systems to events. SV-10 c 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 Svc. V 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 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • IDEAS meeting in London last week UPDM 2 meeting at OMG Tech Meeting DM 2 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 Do. DAF-DM 2 Conformance going to FAC Do. DAF 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 Svc. V’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 – So. A 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!

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)

What this could look like

Disjointness

New Overlap: Allows multiple overlap things

Criteria for an architectural description to be conformant with Do. DAF-DM 2 e. g. , so that it is deemed capable of being federated • Level 1 -- Conceptually conformant – Uses Do. DAF terms and aliases (from DM 2 CDM) to categorize its concepts – Do. DAF 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 DM 2 LDM and aliases • Level 3 -- Physically conformant – Level 2 + expressed as Do. DAF – DM 2 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

Do. DAF 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 Svc. V’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 1 st pass fixes – For descriptions, base on “monster matrix”: • Short first • Then long – Entertain proposals to merge or split / subtype

Systems and Services in Do. DAF 2 • A mechanism to enable access • A functionally, physically, to a set of one or more and/or behaviorally related capabilities , where the access group of regularly interacting or is provided using a prescribed interdependent elements. interface and is exercised consistent with constraints and • A System ≠ POR policies as specified by the • 4 -D service description. The • Parts mechanism is a Performer. • Before-after’s The "capabilities" accessed are • Disposed to perform activities Resources -- Information, • Must have Person. Role. Types Data, Materiel, Performers, and Geo-political Extents. 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 (DM 2 WG Rule) Mc. Daniel Snyder / Bocast

Systems and Services in Do. DAF 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-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

Capability Data Group CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

Core Components of Capability CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-2 Capability Taxonomy CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-3 Capability Phasing CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-4 Capability Dependencies CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-5 Cap to Org Development CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-6 Capability/Activities CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

CV-7 Capability/Services CV-1 Vision CV-5 Capability To Organizational Development Mapping CV-3 Capability Phasing CV-2 Capability Taxonomy CV-6 Capabilities to Operational Activities Mapping CV-4 Capability Dependencies CV-7 Capabilities to Services Mapping

Model Categories ≠ Presentation Types (AI # 557) • • Model Categories (Do. DAF 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 Do. DAF 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.

Extending IT System Operating System Big System Little Bitty System Bit Really. Big. WPT

Currently Queued for 2. 03 Next

Unassigned – Candidates for 2. 03 (pg 1 of 9)

Unassigned – Candidates for 2. 03 (pg 2 of 9)

Unassigned – Candidates for 2. 03 (pg 3 of 9)

Unassigned – Candidates for 2. 03 (pg 4 of 9)

Unassigned – Candidates for 2. 03 (pg 5 of 9)

Unassigned – Candidates for 2. 03 (pg 6 of 9)

Unassigned – Candidates for 2. 03 (pg 7 of 9)

Unassigned – Candidates for 2. 03 (pg 8 of 9)

Unassigned – Candidates for 2. 03 (pg 9 of 9)

10 Sept 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • • – Upcoming: • • • – • • 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 So. AML key terms – add to dictionary as new and alias/composite -- what is the rqmt for Do. DAF to accommodate So. AML? Prioritization for 2. 03 – • 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: • – IS&T NR-KPP WG Do. DAF and Net Centric Data Strategy goals USAF EA 3. 5 FAC correspondence UK Integrated EA Conference planning Pentagon IT Master Plan architecture DM 2 PES Submission to DISR So. A 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!

Draft DODI 8320. 02 -M (Manual): Implementing Data Sharing in a Net-Centric Do. D • • • Implements policy, assigns responsibilities, and provides procedures for implementing Data Sharing in a Net-Centric Department of Defense. Cancels and incorporates guidance in Do. D Guide 8320. 02 -G Provides guidance to the Do. D 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 Do. DAF and DM 2 so that it is deemed capable of being federated? • Level 1 -- Conceptually conformant – uses Do. DAF terms and aliases (from DM 2 CDM) to categorize its concepts defined – Do. DAF 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 DM 2 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

Implementing Do. DAF 2. 0 – DM 2: Success Stories to Date • Joint Mission Threads • Command 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 Human Views in NCOIC HIE Project Rex Brooks 09 June, 2010 • IDEAS in Do. DAF, Do. DAF Metamodel, Mo. DAF, NAF & NATO Network Enabled Capability (NNEC) – International Defence Enterprise Architecture Specification – Ontological Framework Expressed in UML • Focus on Mo. DAF & NNEC • Multiple Views and Separation of Concerns Necessitate Multiple Viewpoints. • Multiple Views Introduce Problems of View Integration and View Consistency.

Human View Product Descriptions Mo. DAF 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? NO UNIFYING CENTRAL CONCEPT Value of Human View is to Organizational and Operational Performance 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 Follow-on questions extend Mo. DAF Human Views What are the required changes to formal organisational structures and processes? Is it humans fitting structure or the structure fitting humans? 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?

Mo. DAF Human Views Dependencies

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, Ph. D, PE; Pacific Science & Engineering Group Nancy P. Houston, Ed. D; NATO Allied Transformation Command

Human View Product Descriptions NATO Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, Ph. D, PE; Pacific Science & Engineering Group Nancy P. Houston, Ed. D; NATO Allied Transformation Command

Human Views-NATO & Mo. DAF NATO Mo. DAF Adapted from NATO Human View Architecture And Human Networks Holly A. H. Handley, Ph. D, PE; Pacific Science & Engineering Group Nancy P. Houston, Ed. D; NATO Allied Transformation Command

Human Views: Different Models Churchill Revisited: Different Cultures Divided by a Common Language Mo. DAF NATO Value of Human to Organization Role of Human in Organization Centric Network Centric 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, Ph. D, PE; Pacific Science & Engineering Group Nancy P. Houston, Ed. D; NATO Allied Transformation Command

Human Views: Different Models Churchill Revisited: Different Cultures Divided by a Common Language 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, Ph. D, PE; Pacific Science & Engineering Group Nancy P. Houston, Ed. D; NATO Allied Transformation Command

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

Knowledge Automation and Bayesian Network Analysis • Bayesian Network Analysis Provides Probabilistic Modeling Links to Hypotheses by Analyst Personality Ratings by Analyst Situational Model Linking Variables Personality Model

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 Do. D 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 Do. D IT Standards Repository (DISRonline), AF information metadata captured in the Do. D Metadata Registry, and architecture metadata captured by the AF Architecture Repository (AFAR). • • Air Force Enterprise Architecture v 3. 5 Object Type and Location (by model area) with Equivalent Do. DAF 2. 0 Object Type – seems to map to DM 2, 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 •

So. AML Key Terms (page 1 of 2)

So. AML Key Terms (page 2 of 2)

3 Sept 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • Do. DAF 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 Do. DAF-DM 2 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 – So. A Consolidation -- Ellis • Others: – – – Ports (Terebesi) JMT Use Case (Vicense) Capability model (Terebesi) So. A High-Pri issues (Ellis) – inc. So. AML 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!

IEEE 1320. 1. 1998 Make ROE Info Follow. Rule Conduct mission Follow. ROE Commander Force ROE followers

IEEE 1320. 1. 1998 Make Standard Ieee 806. 2 info Rule Communicate correctly DISA Switch standards followers

IEEE 1320. 1. 1998 Give rudder Rudder orders order Rule Operate rudder Steer correctly Captain Bowswain’s mate Good bowswain’s mate

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 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • Do. DAF and Joint HSI WG (Human View) Dialog Kick-Off – NCOIC is crossconnecting 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 Do. D EA COI – DODI 8320. 02 G – Dave plan next steps – Upcoming: • • IDEAS & NATO PWG prep in London OMG Technical Meeting – Cambridge MA – UPDM 2. 0 – New References: • • Do. DAF 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 Do. DAF-DM 2 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) So. A High-Pri issues (Ellis) – inc. So. AML 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!

WG Tasker from FAC to Review USAF EA 3. 5 for Do. DAF-DM 2 Conformance • • • The following is sent on behalf of Mr. Alan Golombek, Do. D Federated Architecture Committee Chairman: Attached, for Do. DAF and DM 2 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 Do. D EA. Also attached is an Air Force Do. D 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 Do. DAF and DM 2 Working Groups evaluate the Architecture for Do. DAF and DM 2 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 DM 2. A copy of the briefing is on DKO in the FAC_Forum folder for FAC_08_172010 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 Po. C is Howard Kern, howard. kern. ctr@osd. mil, 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 Do. DAF Metamodel (DM 2) Wall Chart • - Navigation and User Guide • - AFEA model package (zipped) • - Reusable Architecture Data

Levels & Alternatives send prescribe constraints and allow design tradeoffs at appropriate levels CAS Org owns / employs CAS A/C receive Downed Pilot owns / employs SOF Rescue Team Pilot CAS A/C Pilot

20 Aug 2010 Do. DAF - DM 2 WG Agenda • Announcements: – THANK YOU This week: FOR BEING ATTENTIVE • FAC -- went well, 2. 02 on track, TO MUTING • JAIWG Arch Federation SWG – still in planning, new team heads, WHEN NOT use cases SPEAKING! • IS&T WG – data group is forming – Upcoming: • OMG Technical Meeting – Cambridge MA • IDEAS mini-meeting in London – New References: • Do. DAF Plenary briefs in Tutorials and Briefings folder • FAC briefs, including Do. DAF-DM 2 CSAR, in WG folder • 2. 02 Finalization (26 Aug) Status – XSDs, documentation, … • • • Do. DAF website change process Prioritization for 2. 03 Others: – – Ports (Terebesi) JMT Use Case (Vicense) Capability model (Terebesi) So. A High-Pri issues (Ellis) – inc. So. AML terms submitted by Dandashi – Naming pattern, System meaning inputs – Alex – Partitions (they are modeled in IDEAS!)

Port A port is not independent, depends on the whole to perform. Port An interface (logical or physical) provided by a System. Sense in which a Performer • Mouth talking • Computer IO card, controller (e. g. , a subsystem) (Do. DAF/CADM): Node. Port: The specification of a physical interface point for a specific Node. (DDDS Counter (19607/1)(A)) (NAF): System. Port: An interface (logical or physical) provided by a <>. A <> may implement a <>, though there is no requirement for <>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. Sense in which a connector (Materiel) • Electrical socket • Hubs, switches • Where – e. g. , shipping port The resource(s) being exchanged depends on the resolution, may not be identical Port was made an alias. Service Port was left in – still is it location, or piece? ? ? Further work.

13 Aug 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • Do. DAF Plenary – Dave post all except AT&L on WG site (tutorials and briefings) and add Do. DAF, 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) – So. A High-Pri issues (Ellis) – inc. So. AML terms submitted by Dandashi – Naming pattern, System meaning inputs – Alex – Partitions – Def of Capability. Phase PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

23 July 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • • Semantic Interoperability Workshop – Vocabulary One. Source – 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 – Mc. Daniel vacation; resume 13 Aug FAC 3 Aug – readahead summary of 2. 02 Do. DAF plenary 12 Aug – New References: • UPDM/bock-ontological-behavior-modelingdm 2. 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) – So. A High-Pri issues (Ellis) – inc. So. AML terms submitted by Dandashi – Naming pattern, System meaning inputs – Alex – Partitions PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

2. 02’s in Progress (page 1 of 2)

2. 02’s in Progress (page 2 of 2)

Can go into very precise modeling using temporal parts (states) Dave Copy and Send time Dave’s Document, Copy 1, in flow state Ian Send part Flow process Receive part Dave’s Document, copy 1 Dave’s Document, Orig Copy Dave’s Doc Ind Type = {Orig, Copy 1, Copy 2, …} Dave’s Doc Ind Type Orig = {Orig} Dave’s Doc Ind Type Copies = {Copy 1, Copy 2, …}

Joint Action: Fatma Selling Cup to Dave time Handover Transfer type. Instance Dave (Person) Handtake Fatma (Person) type. Instance Buyer (Person. Type) Seller (Person. Type) Transfer Handover Handtake Activity. Types Cash (Resource. Type) Cup (Materiel. Type)

16 July 2010 Do. DAF - DM 2 WG Agenda • Announcements: – This week: • • – Upcoming: • – • Do. D 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? • • Small group for DODAF table for CJCSI 6212. 01 F (DODI 4630 I&S applies to everything) New References: • • • Do. D MD Working Group – Guy Caron Do. D COI Forum – Guy Caron INCOSE International Symposium, to be held 12 - 15 July Chicago FAC cancelled Ver 2. 00 and 2. 01 AI’s archived See Walter Pierce email Others: – – – JMT Use Case (Vicense) Capability model (Terebesi) So. A High-Pri issues (Ellis) – inc. So. AML terms submitted by Dandashi Naming pattern, System meaning inputs – Alex Partitions PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

405 Physical and Temporal Measures for SV 10 b "DM 2 Concepts, Associations, and Attributes" Composite Definition Physical. Measure A category of measures of spatio-temporal extent of an Individual such as length, mass, energy, velocity, … Temporal. Measure A type of measure of time A V 1 M a t e r in e l N e n e d l i n e E x c h a n g e I A V 2 O V 1 O V 2 O V 3 O V 4 O V 5 a O V 5 b O V 6 a O V 6 b O V 6 c S V 1 S V 2 S V 3 S V 4 S V 5 a S V 5 b S V 6 S V 7 S V 8 S V 9 S V 1 0 a S V 1 0 b S V 1 0 c o n o o n n o o o o n n

405 Physical and Temporal Measures for SV 10 b M a t e r i e l N e e d l i n e E x c h a n g e I

406 Rename/Def change for desired. Effect structure desired. Effect A desired state of a Resource

407 Capability. Type and other Types activity. Maps. To. Capability. Type 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 activity. Super. Subtype. Of. Measure. Type Def activity. Super. Subtype. Of. Measure. Type activity. Type is a member of Measure. Type

409 ARO irrelevent pieces

410 Missing relationships

503 Org/Org. Type WP(T) Performer

004: (001, 005) tuple type CONDITION 003 measure. Of. Type. Activity. Performable. Under. Condition Says: apuc Î motapuc 006: (007, 004: (001: (002, 003), 005) question tuple activity. Performable. Under. Condition ACTIVITY MEASURE tuple CAPABILITY 001: (002, 003) Many-to-many type To produce a desired effect (State of Resource) question Make peace 002 Many-to-many CAPABILITY MODEL today State of Resource future Whole-life of Taliban (t 1, t 2) (t 3, ¥)Taliban (Taliban are peace loving mean) state Taliban in skinny (t 3, ¥)Taliban rule state the world type Resource. Temporal. State tuple measure. Of. Type. Resource

9 July 2010 Do. DAF - DM 2 WG Agenda • PLEASE BE ATTENTIVE TO MUTE WHEN NOT – This week: • NR KPP WG – Table E revision, deeper dive for data, not view – need to SPEAKING Announcements: know what data being used in the analysis and decisions; 11 ? ’s; sub. WG – 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. 02 F Do. DAF 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 Do. DAF 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) So. A High-Pri issues (Ellis) – inc. So. AML terms submitted by Dandashi Naming pattern, System meaning inputs – Alex Partitions

Particular. Individuals Î Measures Particular. Individual. Types Ì Measures “Forrest’s cube” “x” Forrest’s cube Î {individuals | measure =1 & measure. Type = weight in lbs} Also related to 408 activity. Super. Subtype. Of. Measure. Type Def 441 The Measures model in DM 2 differs from the Measures model IDEAS 450 rule. Part. Of. Measure. Type 451 measure. Of. Type. Whole. Part. Type 467 Measures and tuples 497 Measures 506 Location. Type Measures Measure. Type “weight in lbs” units

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

First Pass – High Level . . .

Next Pass – Add Notes . . .

To Complete • Use notes version to add text to end of each model description – – Part 1 – purpose in the 6 core processes Part 2 – DM 2 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 / Producer. NOTE 1 Annotation 1 NOTE 2 Annotation 2. . . Resources NOTE 4 Receiver / Consumer Annotation 1 NOTE 3 Annotation 2. . . NOTE 1: Performer (where the send & receive activities are implied) or Activities NOTE 2: Activities performer by Performer, Performers that perform the Activities, Standards / Rules, Metrics, and/or Conditions NOTE 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

• • • Name: Systems Interface Description SV-1 Issues 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 x. V – 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.

Detailed Description: • • • • SV-1 Issues 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 DM 2 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-3 b. 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.

Detailed Description: • • • • SV-1 Issues 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 Do. DAF-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 Do. DAF 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. Do. DAF V 2. 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-1 a Interface Description. The SV-1 a describes interfaces (Resource Flows) between Systems, Services, and/or Person Types. Can have multiple levels of detail. 2. SV-1 b Perfomer Configuration. Interface Description plus composition (whole-parts) of Resources involved. If Locations are involved in the configuration, relationships to Resources. 3. SV-1 c 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-5 7. 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 DM 2 Mapping and Measures Use Case Dr. David Dryer Mr. Johnny Yohman Mr. Walter Pierce Visense dryerd@visense. net 757 -966 -5780

2 July 2010 1 st Do. D 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 Do. DAF 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 DM 2 • MDR WG and COI Forum • New References: – none • New submissions by members: – N/A • Do. D EA COI Charter – Step through 8320. 02 G and relate to Do. D EA COI – Action Items for next quarter’s meeting • Others: – TBS PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

Table C 2. T 1. 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 Do. D 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. 01 F & 3170, NCSS, NCDS, DODD/I 4630, Arch Do. DI, DISA cross -agency (DHS, NGO’s) Visible -- DARS, NCES Enterprise Search, MDR, DISR, Understandable -- DM 2, UCORE, IDEAS Accessible – SSO, Intelipedia (U), … distribution restrictions, aggregation problem, pedigree

Table C 2. T 2. 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 Do. D 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 Do. D 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 DM 2 PES XML files % completeness, # registered users & level of activity in COI, DM 2, IDEAS, Do. DAF, UCORE-relationship, DDMS-relationship DM 2 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 C 2. T 3. Summary Descriptions of COI Roles ROLE DESCRIPTION COI Governing Authority Individual or organization that will review and adjudicate COI conflicts and push for Do. D 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 missions Review and adjudicate resolution of discrepancies across COIs Promote and endorse COI activities and implement agreements through the Joint Capabilities Integration and Development System, Acquisition, and Planning, Programming, Budgeting, and Execution process Promote COI support to Do. D Components Review COI plan of action and milestones (POAM) status and success measures COI Lead An individual from a specific Do. D 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 Do. D 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 authority Lead the COI, including developing and tracking POAMs Act as a primary point of contact (POC) for the COI Promote policies and practices for data sharing and participating in cross-Component COIs Identify mission-specific success criteria for the COI Stakeholder s 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 Do. D Components in terms of practices and standards in the implementation areas, including those for data tagging, data access services, and registration of metadata artifacts Promote the reuse of data access services within programs and systems Track Do. D Component implementation of Reference (a) through COI activities Ensure 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 Who / How in Do. D EA COI?

Table C 2. T 3. Summary Descriptions of COI Roles ROLE DESCRIPTION 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 efficiently Participate in COI working groups, particularly as they relate to architectures, standards, and technical specifications Identify implementation alternatives, including common or reusable services or technical capabilities Identify technical impacts of COI agreements, for example the impact of a data access service on system performance to critical users Implement and maintain agreed-upon capabilities Ensure 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 Do. D 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 agreements Advise the governing authority on subject matter priorities Promote use of COIs to solve data sharing problems and advocate for implementation of COI agreements Assist in the identification of mission-specific value measures for COI success Who / How in Do. D EA COI?

Duties • COI FORMATION AND EXECUTION – ESTABLISH AND EVOLVE A COI – COI MANAGEMENT AND GOVERNANCE – CAPABILITY PLANNING AND USER EVALUATION • DATA SHARING IMPLEMENTATION – MAKING DATA VISIBLE – MAKING DATA ACCESSIBLE – MAKING DATA UNDERSTANDABLE – PROMOTING TRUST • Relevance / meaning to Do. D EA COI