ARTIFACT WORKING GROUP MEETING MINUTES

Date / Friday, April 13, 2012
Time / 0730-1120 hours
Location / Lockheed Martin Information Technology Offices, Alexandria, VA

Background:

The initial meeting of the Artifact Working Group to address input into the Documentation section of the proposed Common Planning Methodology (currently at version 0.7).

Participants:

Walt Okon, DoD(Chair)
Raymond Berg, DoD (Secretary)
Marco Demartin, HHS
Heather Shappee, NGA
Caroline Tran, DHS
Kim Ellmore, DHS
Robert Damashek, DoD
Bill Garvin, SSA
Karl Schreder, DNI / Brian Boynton, DOJ
Jim Walterman, DOJ
Lin Zhang, DOI
Terry Horning, FAA
Dave McDaniel, DoD
Vanessa Trinh, OMB
Minesh Patel, SBA *
Gregory Weidman, ODNI
Jeffrey S. Coffin, DoD

*Represented on behalf of Marlon Sellow

Introductions

·  Walt Okon –Chair of Artifacts Working Group, DoD IT Architect Senior Engineer, Lead for DoD IT Standards (Over DISR), owner of the DoDAF, information sharing, education and training.

·  Jim Walterman - Enterprise Architect from DoJ, enterprise architecture is federated (ATF, FBI, DEA) each with own architecture, most is high-level, also deal with info sharing, lead for cloud computing, lead for shared services, green it lead, DAWG,

·  Bill Garvin - SSA works for chief Architect, reexamining approach to FEAF, redesigning governance process

·  Lin Zhang - DOI enterprise Architect, interested in how do we deliver services without mentioning architecture

·  Terry Horning - FAA - Office of Aviation Safety, FEAF is primary tool in his shop, but Air Traffic control uses DoDAF

·  Karl Schreder - Came out with Program Architecture guide using DoDAF-like architectures and JARM (FEA-like) , have identified a number of artifacts that you must turn in like JCIDS

·  Heather Shappee-Chair of the JARM working group, part of enterprise architecture group at NGA, recently reorganized

·  Caroline Tran – (DHS)-Came from Information Security shop, now in DHS architecture

·  Kim Elmore - DHS, HQ methodologies, frameworks, and FSA(M). DHS is maturing, developing approach to architectures. Working to integrate CPIC/CFO/… to be a part of methodologies. Ask that we not "modernize" as all are needed, and we need to "converge". The FSA(M) has been helpful to get collaboration.

Presentation on DoDAF Strategy (Walt Okon)

·  Need single architecture framework, Policy require to enforce, exchange necessary to support interoperability, compliant tools are required.

·  Presentation of DoDAF future state, integration with DNDAF, MoDAF, using UPDM as an exchange mechanism, merging toward UDAF. Moving DoDAF into the DoD as required standard and will pursue OMG making DoDAF a Standard.

·  Bill: What does MoDAF bring to the table? Project and Capabilitie views were added in 2.0, which is where MoDAF was already.

·  What are the implications of "vetted at OMG as a national standard"? What happens once it becomes a standard? OMG specializes with exchange and interchange. If we own it, we will fund all development. If OMG owns it, we still define the requirements while they develop the specifications (Raytheon, IBM, NoMagic, Lockheed, 20+ company SMEs). To partake in this activity, the companies at OMG must volunteer their services and must implement specification if it becomes a standard. We pay for membership at OMG (~$2k), we put our requirements on the table at OMG. If we want to standardize around one common arena why would we continue to pay millions to maintain and not get industry participation/buy-in?

Open Discussion

·  Walt: We haven't done a good alignment with FEA, reference models, and architectures supporting those. Standardized reporting methods to OMB requests is still complex. We can't agree on how to report (e.x. 53s & 300s and Difference between systems and services).

·  Robert: In big data, the health industry has a big focus on the genome. Architecture is the genome of the IT space; it defines how we're organized and functions. By standardizing the nomenclature we can start solving the harder problems.

·  Jim: EA has limited perceived internal value for CIOs today, mostly see EA as opportunity to ensure compliance. Need to identify artifacts and methods that can provide value to the CIO.

·  Karl/Kim: Look at it from "righteous program management" perspective - are they doing architecture on the back of a napkin? Or are the blueprinting? How can you move slightly to compliance instead of proposing new methods? A lot of this is at the program/system level, but we need to aggregate and provide at the right level.

·  Walt: The Army has adopted DoDAF at the data layer. The metadata that's being embedded in the architecture at the tactical PM levels is able to be rolled up into higher level decision reviews. Senior analysts are able to use this information to identify critical paths across architectures.

·  Terry: Artifacts should, at a minimum, focus on making sure that we can achieve compliance-oriented data (GAO EAMMF and Federal data calls).

·  Walt: Walked through the structure of the document. This document is a replacement for the Practical guide for architectures. The abstract is going to be the Methodology in the common approach document. Get the basic architectures in the common approach so that we can further develop those artifacts in another document.

·  Walt: DoD has committed to aligning the DoDAF Volume 1 with the methodology being proposed in this document rather than holding to current DoDAF Methodology.

·  Kim: Speaking on Reference Methodology Working Group – Business Reference Model is getting some mash-up with the budget aspects. The MWG submitted recommendations to OMB, but haven't received feedback on direction.

·  Terry: Don't know what the replacement to the EASRs, EAMMF went up by 4x, need to understand the OMB reporting requirements before we volunteer new artifacts for this effort.

·  Kim: Previously used the term "methodology of methodologies” to bring together the set of federal methodologies for easy reference and cohesion between groups.

·  Vanessa: The documentation section is the section for AWG to review/update/validate. Include items from associated reference models (need to get as close as we can without knowing the future reference model states). Thought we knew new reference modules were going to be added.

·  Walt: In the DoDAF Mapping, he saw that the artifacts were mapped to multiple domains. We have decided the 6 core artifacts will remain in the document, while the rest are moved into a documentation appendix (table A). Responder: These are required, but for what process (reporting, budgeting) and at what scope(program/solution, high-level architecture)?

·  Kim: What is the data that we really need before we decide what artifacts come out? What type of decision are we attempting to make with these data types? Are you asking how to characterize, or how to use characterization, or what a solution looks like?

·  Jim: DoJ has certain functions that are tracked at the enterprise level and need more detail, but for most solutions, the architecture doesn't need to expose that. What am I able to do? What's relevant to key missions?

Break (10 Minutes)

ODNI Program Architecture Guide (Karl)

·  What's the value to the CIO? Need to move program management functions from one-off status, just tweaking their internal development processes. Most ODNI requirements will map right into DoDAF, but have more detail. DoDAF didn't mandate a language for levels, which the JARM provides.

·  Walked through ODNI Program Architecture Guide. ODNI started with what the program managers were already developing to reduce the number down to 11 mandatory artifacts (ex. If you ask for 5B, you can derive the 5A), 22-25 for major systems acquisitions. 4 artifacts early on, 4 more later on, 3 more near the end. For the CIO, each artifact talks through what it is, who it's for. These artifacts are mapped to the JARM.

·  ODNI and DoD both do the 53 report mapping. To achieve this, we need to pull from repositories to get this data (in DoD this is the DITPR). ODNI showed the 100% mission system mapped through the JARM and showed that all systems effect CIO space. When you ask "how much money are you spending on cyber or other domains", the JARM allows for us to do that analysis.

·  Kim: Security artifacts aren't going to be at extreme high or low levels. We may want to focus at the program level, and not try to be all things at all levels. To identify all artifacts at all the 8 levels. (For the first cut, we may not agree with those 6. That's when we see the deep dive into the artifacts.

·  Jim: When it comes to doing the system level solutions architecture, they're doing it already for Certification and Accreditation. FISMA reporting is easier once you have a repository with the information that you have already collected.

DoDAF Mapping Attempt

·  David: Walked through DoDAF X Common Approach. Mappings are not 1-to-1 because the reports ideally should be generated from a tool repository based on an underlying infrastructure.

·  David/Walt: Think of the AV-1 as the metadata about the architecture (who designed it, when, etc..) . CONOPS has a semi-formal meaning in DoD. CONOPS are required in a formal description of the JCIDS, but what data is in the CONOPS is pretty loose. You develop in the following order: Mission Statement -> CONOPS-> Mission Threads->Data Elements in the architecture.

·  Heather: From a CONOPS, you can pull an AV-1, OV-1, OV-2 and other artifacts. At DHS CONOPS are coming in at an investment level, ~560 is too many to extract architecture from this. (Does NGA have a CONOPS development guide? Unknown) CONOPS are developed all over the map (from developers or operators) and can swing from scenario vignettes to architecture.

·  David: The effect is that The S-3 CONOPs has no usable definition because open ended text is not an appropriate definition for an artifact.

·  Lin: CONOPS how instead of what. This makes more sense to Business Owners rather than Strategic.

·  Walt: Task: Return to OMB in a more objective state by 30 April, preferably to point to a specific artifact. The Common Approach is at the High Level, we're adding some specificity to the Document section.

·  Terry: For the next two weeks, can we propose a Zachmann-style framework where we add applicable scope to the required artifacts table? (The 8 levels of Scope) Do we want to distinguish scope in determining required artifacts?

·  Greg: You start tripping over term "required" in segregating scope. In ODNI, use 3 lifecycles to mandate certain artifacts at those levels because a program will traverse levels of scope during it's lifecycle. This approach isn't done in the Common Approach. Can we leverage the PIR process as the driver for the required trait here.

·  Kim: Trying to shift influence on 1) planning, 2) on building, 3)during steady state. We can’t just focus on the program/project building phases.

·  Lin: The problem with mandating at the artifact level is that documents can apply at almost every scope, so the issue isn't the required artifact, but rather the level of detail to the artifact.

·  David: One approach is to get rid of Required/Recommended/Optional and go with Applicable or non-Applicable. Here’s a view of what our options are for the table, alternatives underlined.

Artifact Name / Required/
recommended
/Optional / SDLC (or other Lifecycle [like CPIC]) / 8 Levels of Scope / Scope Alternative: 3 Audiences

·  Greg: One benefit of the ODNI PAG is that it forces people to use the lexicon of the JARM instead of creating new definitions for services.

·  Heather: Did some high-level analysis using the DM2 to identify lowest common denominator to build out on. Action: Provide this input to the group.

Wrap-up:

·  Walt: We've baselined the group on the task expectations, shared information and initial thoughts. We need to capture what we've learned, we understand the common approach task (just the high-level artifact). Team will need to sit down next week with Dave, try to attack the detailed way-forward for our documentation. Minutes will be ready Monday. Action: Dave set up meeting with group next week after Monday.

·  Walt/Terry: Believe the scope can include adding or shortening this list of artifacts (potentially performance documents). Even though we can't get this done in two weeks, might want to start developing the artifact mapping to EAMMF.

·  What about participation from those not using DoDAF? David: Hopefully, the documents descriptions will drive organizations to develop internal processes to make these artifacts part of their processes.

·  Kim: Common App Methodology: Need to revisit methodology that's part of the common approach in order to understand where the artifacts fit because otherwise silos will develop within the common approach methodology.

·  Kim: Is the working group able to view the documents we're supporting? Action: Vanessa will get distributable copy decision on Monday.

ACTION ITEMS:

·  (Walt/Dave/Vanessa) Discuss progress and plans with Dr. Bernard to get clear way forward.

·  (Vanessa) Get decision from Dr. Bernard on distribution of Common Approach Version 0.8 document on Monday.

·  (Dave) Set up working meeting with AWG for next week, sometime after responses come back from actions to discuss items with Dr. Bernard

·  (Karl) Provide ODNI Program Architecture Guide

·  (Heather) Provide analysis work done with DM2 and the NGA CONOPS Guide

·  (Terry) Provide the FAA CONOPS Guidance

1