16 Apr 2010 DoDAF - DM2 WG Agenda

1. 16 Apr 2010 DoDAF - DM2 WG Agenda • News: • M3 Incorporation of IDEAS Meetings this week • Others this week: JAIWG, DoD MDRWG, DoD COI Forum • Reminder: DoD Services Conference w/o 19 April, DoD EA Conference coming up soone • New References: • none • Parse of M3/IDEAS Group comments into DM2 AI list • Review new Action Items (“unassigned”) • Prioritization of 2.02 AI’s – in reverse order! • Others: • In queue but probably won’t have time to get to tomorrow: • 20 SoAML terms to compare to DM2 data dictionary • TBS from WG tomorrow

2. M3

3. M3

4. M3

5. M3

6. M3

7. M3

8. 9 Apr 2010 DoDAF - DM2 WG Agenda • Service Discussion with MOD • News: • FAC meeting this week • JAIWG Federated Data Exchange Pilots Progress • “M3 Incorporation of IDEAS” Meetings next week • DoD Services Conference w/o 19 April • New References: • Baseline: DM2 VDD v2.01.doc • DM2 WG Organizational and Meetings Information: FAC_meeeting__04_06_2010__Announcement_Agenda__V__2.2.doc and FAC_meeting__04_06_2010_BL_V_1.1 wDoDAF.ppt • Review new Action Items (“unassigned”) • Start with AIs 507-509 needed for JFCOM Federated Data Exchange Pilots • Prioritization of 2.02 AI’s – in reverse order! • Others: • In queue but probably won’t have time to get to tomorrow: • 20 SoAML terms to compare to DM2 data dictionary • TBS from WG tomorrow

9. Partridge Services Analysis for MODAF Must have Service End Point Equipment part of human performer – Guard system or CapabilityConfig in MOD

10. MODAF Services Analysis [1] The OASIS-RM definition is used in DM2 and noted in M3.

11. MODAF Services Analysis

12. Individual Guard System Guard Person Type Mouth and Ears Mouth and Ears Agreement Pre-conditions Steps Guard HQ System Biz nature of service – more work NCOIC -- Individual Guard System Radio Radio Call-in Service Guard Person Type Guard HQ System Binoculars Fire & blanket

13. NCOIC Anti-Piracy • Human parts – DoDAF not Human Factors and MoDAF does • Competency and roles. Willingness and trust. • IDEAS – disposition and manifestation

14. Ken’s Input to CP • After SOA-RM was deep into the final approval process, it became obvious that one really needed to differentiate between the idea of “business service” and the “SOA service” that is all the rage as an IT artifact.  It was too late to add it to the RM but there was a discussion thread on the OASIS email list on this distinction.  I tend to emphasize it because I find it avoids conflating different definitions and keeps any discussion on track. • I think the ServicePoint entered because a big part of WSDL is where is the endpoint.  In reality, the ServicePoint/endpoint is one piece of description about a (SOA) service. • I agree that some, and probably most, of the Service Provider should be outside the Service box. • The TOG-SO definition of service seems to be more on the business side, being a “logical representation” rather than an access mechanism.  However, the idea of a “specified outcome” aligns with the SOA-RM concept of real world effect.  Chris captures this point in the text following the SoaML ServicePoint definition box. • Chris notes the “unorthodox” sense in which SOA-RM defines service.  This was done on purpose per the caveat in the section 1.4: • Note that while the concepts and relationships described in this reference model may apply to other "service" environments, the definitions and descriptions contained herein focus on the field of software architecture and make no attempt to completely account for use outside of the software domain.  Examples included in this document that are taken from other domains are used strictly for illustrative purposes. • In Chris’ final point about the taxi service, an imperfect analogy (refer again to the caveat about examples) is the taxi service is an example of a capability that provides the business function of hired transportation, i.e. its business service.  The business service/capability can likely be accessed through several mechanisms: phone, maybe fax, possibly a Web form, or the traditional waving at a taxi driving by.  These access mechanisms are akin to the SOA service.  Note the power of this.  I have a capability but I may get greater value from it by changing the mechanism through which it can be accessed.  Maybe it will provide access through a Web service so a travel agent can automatically make a taxi reservation.  However, while the access mechanisms can change, there still needs to be a well-defined business function that needs to be satisfied and a well-defined implementation that can provide that function and realize its real world effects.  Without that, SOA or any other kind of access has nothing to access.  This leads to the common problem of trying to identify SOA services before your identify your business and how you expect to do it. Preparing to contract – execution context Trust model – trust, risk, real-world effects

15. Legacy Combat System Analog Trust at a distance – social, organizational – ownership boundaries Ability to establish trust, e.g., as in a contract DoD Policies -> Navy&DON Policies -> PEO-IWS Policies -> IWS-6 – PMS-400 MOA -> IDS IPT Rules of Conduct -> Software Engineering & Tesing Rules -> Communications Handshakes -> Information Exchange • What happens as a result, including “real-time” mini-negotiations • Systems exchange data on AEGIS ships using real-time communications • “real-time” negotiations (e.g., RTT’s, ACK’s, …) • Program Manager A’s policy is such and such • Program Manager B’s policy is such and such

17. DM2 Adjustments (DODAF WG) Many minor model updates Desired Effect structure Design reification and requirements traceability International Defence Enterprise Architecture Specification (IDEAS) alignment XML Schema Description (XSD) Format Beginning absorption of latest OASIS & Object Management Group (OMG) SoA concepts 17 UNCLASSIFIED

18. DODAF CM Plan (DODAF WG) • Annex A: DoDAF Meta Model (DM2) Working Group (WG) • Annex B: DoDAF Working Group (WG) 18 UNCLASSIFIED

19. DoDAF / DM2 CM Plan • Adopts terminology and process from EIA Standard 649, “National Consensus Standard for Configuration Management” • Contents: • Configuration Identification • Organizational Roles, Responsibilities, and Interactions, e.g., • DoDAF / DM2 Work Group • The DoDAF 2 Data TWG became the DoDAF / DM2 WG • This group has been meeting every Friday since 2007 and has over 190 members and a very extensive collaboration and research site • DoDAF / DM2 CM Processes and Procedures, e.g., • Tracking of Change Requests • Monthly submission to FAC of Configuration Status Accounting Report (CSAR) • DoDAF / DM2 CM Business Rules • DoD EA COI, e.g., • conduct of the DoD EA COI Data Management Working Group • DoDAF / DM2 Review of Federated Architectural Descriptions 19

20. Unassigned (New) AI’s • # Title • 476 Dispositional vs Categorical Properties • 477 SoAML Concepts • 478 OASIS SOA RAF Concepts • 479 Necessary and optional foundation elements in XML docs • 480 System vs Service • 481 Mandatory Service Descriptions and Ports • 482 Geostatoinary Point Type • 483 Region of World Type • 484 Project and Project Type have a TI and a PTI • 485 DesiredEffectWholeResourcePartType • 486 ARO as two couples • 487 Agreement constrains activityPerformedByPerformer • 488 Information Traceability to Data • 489 APBP redundancy with APUC • 500 Singleton Types • 501 Capability Phase <> Enterprise Phase • 503 Org/OrgType WP(T) Performer • 505 TV and StdV • 506 LocationType Measures • 507 TypeType… • 508 Forking under Conditions • 509 How to indicate methodology-dependent subclasses • 510 Coordinate AV-1 Defs with DARS • 511 How to categorize Arch Desc • 512 make the full inheritance taxonomy machine-accessible somehow, like in the XSD • 513 Partridge Services Questions & Comments • 514 M3 / LOK Questions and Comments • 515 Performer Flows and Tools • 516 Service Access to Resource or Performer • 517 Powertype Definition