Presentation is loading. Please wait.

Presentation is loading. Please wait.

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,

Similar presentations


Presentation on theme: "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,"— Presentation transcript:

1 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

2 Currently Queued for 2.03

3

4 Unassigned – Candidates for 2.03 (pg 1 of 6)

5 Unassigned – Candidates for 2.03 (pg 2 of 6)

6 Unassigned – Candidates for 2.03 (pg 3 of 6)

7 Unassigned – Candidates for 2.03 (pg 4 of 6)

8 Unassigned – Candidates for 2.03 (pg 5 of 6)

9 Unassigned – Candidates for 2.03 (pg 6 of 6)

10 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: Technical Cutoff –Nomination of Defers (post 2.02s) & Unassigneds urgently needed for 2.02 (Dave and Greg) –2.02 in-progresss 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

11 2.02s in Progress (page 1 of 2)

12 2.02s in Progress (page 2 of 2)

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

14 Joint Action: Fatma Selling Cup to Dave Buyer (PersonType) Seller (PersonType) Fatma (Person) typeInstance Transfer Handover Handtake Dave (Person) typeInstance Transfer Handtake Handover ActivityTypes Cash (ResourceType) Cup (MaterielType) time

15 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 July Chicago FAC cancelled –Upcoming: Small group for DODAF table for CJCSI F (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 AIs –Defers, Unassigned urgently needed for 2.02? See Walter Pierce 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 Ver 2.00 and 2.01 AIs archived

16 405Physical and Temporal Measures for SV10b Materiel NeedlineExchangeItem/ArtifactnonICmarkings AttributePerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraintPhysicalMeasure MeasureOfPerformancePlan ProjectSequence, MilestoneSequencePolygonArea LocationTypeRateThroughput MeasureOfPerformancereleasableTo AttributeRuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraintServiceEnablesAccessTo ServiceConsumerServicePort ServiceInterfaceSkill CompetenceMateriel NeedlineExchangeItem/ArtifactnonICmarkings AttributePerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraintPhysicalMeasure MeasureOfPerformancePlan ProjectSequence, MilestoneSequencePolygonArea LocationTypeRateThroughput MeasureOfPerformancereleasableTo AttributeRuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraintServiceEnablesAccessTo ServiceConsumerServicePort ServiceInterfaceSkill Competence "DM2 Concepts, Associations, and Attributes" Composite Definition AV-1AV-1 AV-2AV-2 OV-1OV-1 OV-2OV-2 OV-3OV-3 OV-4OV-4 OV-5aOV-5a OV-5bOV-5b OV-6aOV-6a OV-6bOV-6b OV-6cOV-6c SV-1SV-1 SV-2SV-2 SV-3SV-3 SV-4SV-4 SV-5aSV-5a SV-5bSV-5b SV-6SV-6 SV-7SV-7 SV-8SV-8 SV-9SV-9 SV-10aSV-10a SV-10bSV-10b SV-10cSV-10c PhysicalMeasure A category of measures of spatio-temporal extent of an Individual such as length, mass, energy, velocity, … no n oonnoooo noooonn TemporalMeasur e A type of measure of timen n oonnoooo noooonn

17 405Physical and Temporal Measures for SV10b Materiel NeedlineExchangeItem/ArtifactnonICmarkings AttributePerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraintPhysicalMeasure MeasureOfPerformancePlan ProjectSequence, MilestoneSequencePolygonArea LocationTypeRateThroughput MeasureOfPerformancereleasableTo AttributeRuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraintServiceEnablesAccessTo ServiceConsumerServicePort ServiceInterfaceSkill CompetenceMateriel NeedlineExchangeItem/ArtifactnonICmarkings AttributePerformerRuleConstrainsActivityOverlap SubjectOfResourceConstraintPhysicalMeasure MeasureOfPerformancePlan ProjectSequence, MilestoneSequencePolygonArea LocationTypeRateThroughput MeasureOfPerformancereleasableTo AttributeRuleConstraintOfActivityValidUnderCondition SubjectOfOperationalConstraintServiceEnablesAccessTo ServiceConsumerServicePort ServiceInterfaceSkill Competence

18 406Rename/Def change for desiredEffect structure desiredEffectA desired state of a Resource

19 407CapabilityType and other Type Types activityMapsToCapabilityTypeRepresents that an activity was / is / can-be/ must-be conducted under certain conditions with a spatiotemporal overlap of the activity with the condition.

20 408activitySuperSubtypeOfMeasureType Def activitySuperSubtypeOfMeasureTypeactivityType is a member of MeasureType

21 409ARO irrelevent pieces

22 410Missing relationships

23 503Org/OrgType WP(T) Performer

24 tuple CAPABILITY type ACTIVITY type CONDITION type MEASURE tuple activityPerformableUnderCondition tuple measureOfTypeActivityPerformableUnderCondition type ResourceTemporalState tuple measureOfTypeResource State of Resource To produce a desired effect (State of Resource) CAPABILITY MODEL 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) question

25 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 July Chicago. MDR WG and COI Forum FAC next Tuesday –New References: In CJCSI folder: –Working draft of CJCSI F –DoDAF brief to NR KPP WG Urgent AI for 2.02 – Properties and MeasuresNeed 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

26 ParticularIndividuals Measures ParticularIndividualTypes Measures Also related to 408activitySuperSubtypeOfMeasureType Def 441The Measures model in DM2 differs from the Measures model IDEAS 450rulePartOfMeasureType 451measureOfTypeWholePartType 467Measures and tuples 497Measures 506LocationType Measures Forrests cube x MeasureType units weight in lbs Forrests cube {individuals | measure =1 & measureType = weight in lbs}

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

28 First Pass – High Level......

29 Next Pass – Add Notes......

30 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

31 Example: Resource Flow Boxes and Lines Sender / Producer NOTE 1 Receiver / Consumer Annotation 1 NOTE 2 Annotation 2. Resources NOTE 4 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 Annotation 1 NOTE 3 Annotation 2.

32 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 wouldnt you just do a more detailed SV-1?, SV-2 shows 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 resources 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.

33 SV-1 Issues Detailed 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.

34 SV-1 Issues Detailed 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).

35 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-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.

36 Enterprise Architect to DM2 Mapping and Measures Use Case Dr. David Dryer Mr. Johnny Yohman Mr. Walter Pierce Visense

37 2 July st DoD EA COI Data Management Working Group (DMWG) Agenda Announcements: –New Members: –This week: IDEAS, OMG 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 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 G and relate to DoD EA COI –Action Items for next quarters meeting Others: –TBS PLEASE BE ATTENTIVE TO MUTE WHEN NOT SPEAKING

38 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) CSAs, CIOs, Acqs, inter-agency (at specific reification / meta levels), PMs, Governance, e.g., DTM-93, CJCSIs F & 3170, NCSS, NCDS, DODD/I 4630, Arch DoDI, DISA cross-agency (DHS, NGOs) Visible -- DARS, NCES Enterprise Search, MDR, DISR, Understandable -- DM2, UCORE, IDEAS Accessible – SSO, Intelipedia (U), … distribution restrictions, aggregation problem, pedigree

39 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? IRM 1.0 maps to DDMS 2.0, cross-domain discovery and retrieval FAC, Army NCDS ideas (ADTP, Army Data Transformation Plan)

40 Table C2.T3. Summary Descriptions of COI Roles ROLEDESCRIPTIONWho / 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 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 DoD Components Review COI plan of action and milestones (POAM) status and success measures COI LeadAn 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 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 COI Stakeholde rs 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 artifacts Promote the reuse of data access services within programs and systems Track DoD 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

41 Table C2.T3. Summary Descriptions of COI Roles ROLEDESCRIPTIONWho / 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 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 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 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

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


Download ppt "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,"

Similar presentations


Ads by Google