1 Selecting DoDAF 2.0 Views and Models for Use in DoD Projects, Their Integration & AnalysisAnn Reedy, PhD DoDAF Program Director and Beryl Bellman, PhD FEAC Academic Director Federated Enterprise Architecture Certification Institute

2 Agenda A short introduction to the FEAC DoDAF Certification ProgramOverview of DoDAF 2.0 Changes from 1.5 Six Step Process for Planning Examples Example questions and corresponding views Example planning example

3 The FEAC DoDAF Program FEAC was founded in 2001 and has certified over 1300 architects FEAC offers DoDAF education and training that leads to FEAC Certification, which is given by California State University East Bay The program consists of five courses, four of which can be taken for graduate academic credit from the Department of Engineering at CSUEB Students learn how to plan, develop, model, implement and do EA analysis for an actual DoDAF project throughout the program and delivered as a practicum FEAC also offers short workshops and DoDAF boot camps, as well as TOGAF 9 certification courses

4 The DoDAF Courses The five basic FEAC courses are designated by the following course numbers; depending on whether you are taking the program for CEU or graduate academic units: EXSP 8680/ENGR 7806 Framework Basics EXSP 8681/ENGR 7807 Planning for Architecture Development and Use EXSP 8682/ENGR 7808 Framework Views and Models EXSP 8683/ENGR 7809 Advanced DoD Architecture Modeling and Analysis EXSP 8684 DoDAF Practicum/Thesis We also provide an Elective TOGAF Course for those wanting TOGAF Certification, which qualifies those who want to TOGAF 9 to take the Bridging Examination

5 Organizations that have sent students to FEAC for CertificationGovernment Army Def Med Log SS Army AIMD TRADOC Air Force HQ OSSG Air Force AIMD TRADOC Air Force USJFCOM Air Force US PACOM Air Force US STRATCOM Bureau of Engraving & Printing City of Glendale, CA City of Virginia Beach DOD OSD BMSI Department of Commerce - NTIA Department of Commerce PTO Department of Education SFA Department of Education HQ Department of State DOI CIO DOI OSM DISA HHS -ASBTF-OIRM FDA Federal Railroad Administration FERC Forest Service GAO GSA IRS Joint Forces Command Lawrence Livermore National Labs National Park Service Navy ONR Navy NAVSISA NASA HQ NASA Centers NOAA Office of the Comptroller of the Currency OMB OPM Security and Exchange Commission Smithsonian Treasury - US Mint USDA HQ USDA RMA US Postal Service US Coast Guard US Commerce Department US Patent and Trademark US PACOM/J2T2 US Senate University Of Leuven (Belgium) Veterans Administration VA Veterans Benefits Administration White House-EOP Industry Aerospace Corporation AMIT AMS Analytics and Mechanics Assoc Anteon Apteon Arinc BAE Systems BEA Boeing Booz Allen Hamilton Burk Consortium CACI Conquest-Boeing CSC Dell DiamondCluster International DigitalNet Eagan McAllister East Bank Technologies ERPi General Dynamics GroupoActivity (Spain) Headstrong Hewlett Packard IBM Independent Consultants Information Dynamics Johns Hopkins University-APL Knowledge Code L-3 Communications Lockheed Martin Co Mitre Northrup Grumman NTT Data Agilnet (Japan) Oracle PacTel Phase One Inc Raytheon RG2 RGS Assoc Rose International RSIS SAIC Samsung (Korea) Schafer Sci Group ScotCro SKCC (Korea) SRA Stanley Associates Inc Summaria Sys Inc Titan VAAP Technologies

6 Goals of this Tutorial Understanding how to identify required data and select DoDAF described models based on stakeholder questions

7 DoD Architecture Framework 2.0What it is: Guidance on the types of data and relationships needed to document a DoD architecture in a standard way (new in 2.0) Guidance on format and content for a standard set of DoDAF Described Models for describing architectures High level meta-process for using the DoDAF What it isn’t: A specific architecture A tool A detailed architecture development process

8 DoDAF V2.0 Vision Views for Other Stakeholders Structured KnowledgeBase – Common Model Views for the Architect

9 Levels of ArchitectureDoD Enterprise Enterprise Level Architectures System Context SoS Architectures FoS Architectures Capability Based Segment Level Architectures Solution Level Architectures

10 DoDAF V2.0 Viewpoints New in V2.0Data models split out into separate Viewpoint in V2.0 Services views split out into separate viewpoint in V2.0

11 Views Are Models Not PicturesModels have a standard semantic interpretation Rules for correctness and consistency Most DoDAF described models/views have a graphic template The graphic is backed up with dictionary entries (data entities and relationships from DM2): Data elements provide definitions and descriptions of items in the graphic plus Additional supporting information and relationships to other architecture elements The data elements integrate the set of views

12 DoDAF As Guidance Views have options discussed in Volume IIChoices of things like: Techniques/notations Level of detail All views may be tailored Graphic conventions Techniques to manage complexity Edits of dictionary entries: changes to data elements

13 Architecture Planning

14 Six Step Process (V2.0) - The Planning Perspective1 2 3 4 5 6 Determine the intended use of the architecture Scoping Architecture Work Planning the Architecture Project Determine scope of the architecture Determine data required to support architecture development Collect, organize, correlate, and store architecture data Conduct analyses in support of architecture objectives Document results IAW with Decision-Maker needs What Needs to be Done How the Work Will Be Done

15 Why Look at the Six Step Process?The Six Step Process is important to the identification of required data and selection of views together with their options and tailoring Performance of Steps 1-4 yields information for your AV-1: Purpose and stakeholders Scope Views with options and tailoring Planning for Steps 4-6 yields constraints on view options and tailoring based on development and analysis processes

16 Step 1: Determine Intended Use The Problem StatementWhat questions need to be answered? Are there specific strategic objectives to be satisfied? Are there specific trade offs to be considered? What critical issues need to be addressed? How is the EA used to support key decision-making processes? What types of analysis need to be supported? The real issue: Why are you building an architecture? Note that the answer isn’t “to build an architecture!” Examples for each question: Program objective: “Increase overall efficiency of process A by X%.” where example processes might be real-time (targeting) or non-real time (production of an ATO) Trade offs: “Determine impact of distributed versus centralized control of intelligence data.” Note these may include both operational and IT issues. Critical issue: “How can Air Defense C2 be handled in the context of a JTF?” The analysis needed will depend on the answers to the other questions. For example, performance issues in the operational context may activity based costing analysis.

17 Why Is Purpose Important?Architecture is a tool to support decision making If you don’t know what you are going to use it for, there is a good chance it won’t be useful You need to identify and understand the different purposes of different stakeholders Architectures can be expensive to build Doesn’t make sense to build one if you don’t plan to use it!

18 Why Is Purpose Important?DRIVES Class discussion: You’re never really “done,” just done with the current phase! VIEWS DETAIL COMPLETION

19 Step 2: Determine Scope Operational boundsWhat’s the enterprise, what level of architecture What mission(s), functions, and organizations What geographical context Constraints on technology to be considered Timeframes As-Is, To-Be, phasing and evolution Specific project schedule and resource constraints Driven by intended use State the enterprise involved – most practicum projects are just a slice of a larger architecture; see example of identity theft project Operational bounds: is this a mission oriented or support service oriented architecture? What about Missions Other Than War? Geographical context: can be either specific - i.e., Africa, Southeast Asia, Bosnia - or generic - i.e., land, sea, littoral, limited, regional, or world-wide Technology constraints: Will the IT architecture focus on infrastructure only? For To-Be timeframes: what assumptions will be made in terms of capability and availability of technology - although this may be part of the architecture development For As-Is timeframes: what is the technology focus of the architecture - e.g., will communications be looked at in detail as opposed to applications. Does the initial phase focus on documenting the current IT inventory only? Architecture schedule and resource constraints: what can I accomplish with given resources and schedule?

20 Step 3: Determine Data Required to Support Architecture Development - Think About Architecture Primitives (DoDAF Conceptual and Logical Data Model Entities) Performers Activities Information elements Events/triggers Capabilities Goals Systems Services Rules Standards Locations Measures Projects

21 DoDAF Conceptual Data Model

22 Step 4: Collect, Organize, Correlate, and Store Architecture DataEmphasis in planning is how data will be organized That is, what DoDAF views will eventually be used, including options and tailoring This tells us what the meta-data should be and identifies repository requirements This tells us what needs to be collected and how it should be correlated 4 Collect, Organize, Correlate, and Store Architecture Data Automated repositories Activity Models Data Models Dynamic Models Organizational Models Metadata registration

23 All Viewpoint Views Capture Information That Applies to the Architecture OverallIntegrated Dictionary (AV-2) Overview and Summary Information (AV-1) Identification Name Architect Organizations Involved When Developed Purpose Analysis Needs Decision Support Needs Scope Views and Products Used Time Frames Addressed Context Mission Geographical Rules, Criteria, and Conventions Followed Findings: Results, Recommendations Tools and File Formats Integrated Dictionary At a minimum, the integrated Dictionary is a glossary with definitions of terms used in the given architecture description. Each labeled graphical item in the graphical representations should have a corresponding entry in the Integrated Dictionary. AV-1 Key Concepts: The Overview and Summary Information provides an executive summary and reader’s guide to the enterprise architecture. This product is mostly textual, and provides an introduction to the architecture products that will follow. One important item to tell your audience is why the architecture was developed. This product should contain a list of the products included in the architecture, together with the options selected and tailoring used for the products. AV-2 Key Concepts: The Integrated Dictionary is composed of the completed data element tables of all the other products. The Integrated Dictionary is a virtual concept. All the information doesn’t necessarily need to be in a single repository or document.

24 Examples: Enterprise-Level ArchitectureCapability Management Portfolio Management

25 Example Capability Management QuestionsRequired Data Types Views How do the capabilities relate to enterprise strategy and goals? Vision Goals Desired Effects Capabilities Relationship between capabilities and goals Vision (CV-1) Are there dependencies among the capabilities? Capabilities Relationships among capabilities, including dependencies Capability Dependencies (CV-4) How will capability performance be measured? Capabilities Performance Measures Relationships of capabilities to performance measures Capability Taxonomy (CV-2)

26 Example Capability Management Questions (continued)Required Data Types Views When will the capabilities be available and what projects will provide them? Capabilities Projects Timeframes Relationships among the above Capability Phasing (CV-3) What organizations will use the capabilities? Capabilities Organizations Relationships among capabilities and organizations Capability to Organizational Development Mapping (CV-5) Organizational Relationships Chart (OV-4)

27 Example Portfolio Management QuestionsRequired Data Types Views What organizations are in change of which projects? Organizations Projects Relationships between organizations and projects Project Portfolio Relationships (PV-1) Organizational Relationships Chart (OV-4) What are the timelines for the projects and are there dependencies among them? Projects Timelines: start and end dates Dependencies among projects Project Timelines (PV-2) Which projects are delivering capability configurations that realize which capabilities? Projects Capabilities Relationships between projects and capabilities Project To Capability Mapping (PV-3) 27

28 Recommendation: Basic Views for Enterprise-Level ArchitecturesVision (CV-1) Capability Phasing (CV-3) Capability Dependencies (CV-4) Capability to Organizational Development Mapping (CV-5) Project Portfolio Relationships (PV-1) Project Timelines (PV-2) Project to Capability Mapping (PV-3) Organizational Relationship Chart (OV-4) Plus AV-1 and AV-2, as always

29 Integration of Enterprise Level Architecture Basic Views29

30 Examples – Solution-Level ArchitectureSetting Context for a System, SOS, or FOS

31 Example Solution-Architecture QuestionsRequired Data Types Views What are the key elements of the Operational Concept for this architecture? Abstractions of: Key mission process/activities Key performers Key resource exchanges High-level Operational Concept Description (OV-1) How are mission operations performed (now or in the future)? Mission process/activities Resources exchanged/inputs & outputs Performers Activity Model (OV-5) Operational Resource Flow Description (OV-2) Operational Resource Flow Matrix (OV-3)

32 Basic Operational Views Capture the Critical Mission Relationships and Resource ExchangesResource Flows Matrix Operational Resource Flow Description Activity Model High-Level Operational Concept Description From External Performer Performer B OPERATIONAL INFORMATION ELEMENT DESCRIPTION MEDIA SIZE UNITS NAME/IDENTIFIER DEFINITION DIGITAL, VOICE, TEXT, IMAGE, ETC. RANGE LIMITS FEET, LITERS, INCHES, ELEMENT & ACTIVITY IDENTIFIER PRODUCING OF OE CONSUMING SOURCE DESTINATION FREQUENCY, TIMELINESS, THROUGHPUT SECURITY REQUIREMENTS INTEROPER- ABILITY EXCHANGE ATTRIBUTES Activity 2 Activity 3 Performer C Activity 3 This graphic illustrates relationships among the Operational View core products. The elements that appear on the High-Level Operational Concept Description (OV-1) should represent, at some level of abstraction, element that appear elsewhere in the Operational View. The activities that appear in the Activity Model (OV-5) should be allocated to operational nodes in the Operational Node Connectivity Description (OV-2). The needlines from the Operational Node Connectivity Description (OV-2) should be decomposed into information exchanges in the Operational Information Exchange Matrix (OV-3). Activity 1 Activity 2 Performer A High-level graphical description of the operational concept of interest To External Node Operational activities performed and their input/output relationships Resources exchanged between performers and the relevant attributes of the exchanges Performers, Activities for each performers and resource needlines

33 Example Basic Solution Architecture Questions (continued)Required Data Types Views What systems/services and what are their interfaces (internal and external)? Systems/services System/service interfaces Standards System Interface Description (SV-1) or Services Context Description (SvcV-1) Standards Profile (StdV-1) How do the systems/services support operations? Relationship of systems/services to performers Relationship of systems/services interfaces to needlines Relationship of systems/services to activities OV-2 SV-1/SvcV-1 Operational Activity to Systems Function Traceability Matrix (SV-5) or Operational Activity to Services Traceability Matrix (SvcV-5)

34 Relationships Between OV-2 and SV-1(SvcV-1) Put IT in Context with Mission OperationsLocation B Location A Location C The figure illustrates that relationships will be established between the Operational View and the Systems View. Relationships will be identified between operational nodes and the systems nodes that support them. In many cases the operational nodes and the systems nodes will be two views of the same facility or organization. In addition, relationships will be established between the needlines and the system interfaces that implement them. Performer B Activity 2 Activity 3 Activity 1 Activity 2 A Performer To External Node Performer C Activity 3

35 Standards Profile Identifies Implementation Criteria That Govern the Given ArchitectureLOCATION B LOCATION A LOCATION C This figure illustrates the relationships between the Technical Standards Profile (TV-1) and the Systems Interface Description (SV-1). The standards should be mapped to the systems or interfaces where they apply.

36 Recommendation: Basic Views for Solution-Level ArchitectureHigh Level Operational Concept Description (OV-1) Operational Resource Flow Description (OV-2 Operational Resource Flow Matrix (OV-3) Operational Activity Model (OV-5a, b) Systems Interface Description (SV-1) or Services Context Description (SvcV-1) Standards Profile (StdV-1) Capability to Operational Activity Mapping (CV-6)* Plus AV-1 and AV-2, as always *New with DoDAF V2.0; assumes a Segment-Level or Enterprise-Level architecture related to the Solution-Level architecture.

37 These Basic Views Link to Each OtherHIGH-LEVEL OPERATIONALCONCEPT DESCRIPTION (OV-1) STANDARDS PROFILE (StdV-1) VALUE ADDED: SUMMARY LEVEL REPRESENTATION OF ORGANIZATIONS/ROLES, MISSION, AND CONTEXT FOR THE ARCHITECTURE VALUE ADDED: COMPLETE LIST OF RELEVANT STANDARDS WITH OPTIONS & PARAMETERS OPERATIONAL CONCEPT ROLES & MISSIONS SET SCOPE FOR ACTIVITY MODEL STANDARDS APPLY AT SYSTEM TO SYSTEM INTERFACES OPERATIONAL ACTIVITY MODEL (OV-5) ACTIVITIES MAP TO OV-2 PERFORMERS I/OS MAP TO NEEDLINES PERFORMERS OF ACTIVITIES, IF SHOWN ON 0V-5, MAP TO OV-2 PERFORMERS SYSTEMS INTERFACE DESCRIPTION (SV-1) OPERATIONAL CONCEPT CONNECTIVITY & RESOURCE EXCHANGES, IF SHOWN ON 0V-1, MAP TO OV-2 NEEDLINES & RESOURCE EXCHANGES VALUE ADDED: BUSINESS/MISSION PROCESS & RELATIONSHIPS AMONG ACTIVITIES AND RESOURCE EXCHANGES This figure summarizes the relationships among the core products. INPUT/OUTPUT LABELS MAP TO OPERATIONAL RESOURCE EXCHANGES (NOT ALWAYS ONE-TO-ONE) RESOURCE EXCHANGES ASSOCIATED WITH EACH NEEDLINE ARE DETAILED IN OV-3 OPERATIONAL RESSOURCE FLOW DESCRIPTION (OV-2) VALUE ADDED: STATEMENT OF LOCATIONS, SYSTEMS & INTERFACES PERFORMERS ARE ASSOCIATEAD WITH SYSTEMS AND LOCATIONS EACH OPERATIONAL NEEDLINE MAPS TO ONE OR MORE SYSTEM INTERFACES OPERATIONAL RESOURCE FLOW MATRIX (OV-3) VALUE ADDED: INDIVIDUAL RESOURCE EXCHANGES ASSOCIATED WITH EACH NEEDLINE & PERFORMANCE REQUIREMENTS VALUE ADDED: STATEMENT OF OPERATIONAL PERFORMERS, ACTIVITIES, AND CRITICAL RESOURCE EXCHANGE NEEDS

38 Segment-Level ArchitectureCapability Focus

39 Recommendation: Basic Views for Segment-Level ArchitectureCombination of Enterprise and Solution Level core views If the Segment is used to manage the investments and portfolio for the capabilities included in the segment, then the Enterprise Level core views apply If the Segment is used to coordinate a set of Solution Level architectures, then the Solution Level core views apply to set the business context and document: Relationship of major systems to high-level business process Interfaces among business processes and among systems necessary to ensure interoperability

40 Example Questions for Additional Views

41 Example Dynamic Behavior (Timing & Sequencing) QuestionsRequired Data Types Views What scenarios explain the concept of operation or key performance or security issues? Events Messages Performers/systems/services Relationship among the above Event/Trace Descriptions: Operational (0V-6c) Systems (SV-10c) Services (SvcV-10c) What are the states/statuses that key elements of the architecture have and how do they change? States for a given element of the architecture Transitions Events Relationships among the above State Transition Descriptions: Operational (OV-6b) Systems (SV-10b) Services (SvcV-10b) What are the rules that constrain operations, systems and/or services? Rules Relationships of rules to other elements of the architecture Rules Models: Operational (OV-6a) Systems (SV-10a) Services (SvcV-10a)

42 Example Domain Data QuestionsRequired Data Types Views What are the shared mission/business concepts and their relationships? Entities Attributes Relationships among the above Conceptual Data Model (DIV-1) What is the logical structure of the key structured shared data in the architecture? Entities Attributes Relationships among the above Logical Data Model (DIV-2) What is the physical structure of the key structured shared data in the architecture? Entities, Attributes, and Relationship among the above or File Structures or Message Structures or ? Physical Data Model (DIV-3)

43 Example Transition Planning QuestionsRequired Data Types Views When will new systems/services be available? Systems/Services Timeframes Relationship among the above Systems Evolution Description (SV-8)/ Services Evolution Description (SvcV-8) What IT performance improvements should be expected at key transition milestones? Systems/Services Performance measures Relationships among the above Systems Measures Matrix (SV-7)/ Services Measures Matrix SvcV-7) What are the trends in systems/services and standards and associated personnel skills that may impact IT during the transition period? Systems/Services Areas, Categories, and Standards Timeframes Forecasts Systems Technology and Skills Forecast (SV-9)/ Services Technology and Skills Forecast (SvcV-9) Standards Forecast (StdV-2)

44 Example Matrix/Mapping QuestionsRequired Data Types Views Which systems/services interface with which other systems/services? Systems/services Systems/services interfaces Systems2 Matrix (SV-3) Systems-Services Matrix (SvcV-3a) Services2 Matrix (SvcV-3b) How do services relate to capabilities? Services Capabilities Relationships among the above Capability to Services Mapping (CV-7) What are the key attributes (such as throughput) of the system/services resources flows? System/Service Interfaces System/Services Resource Flows Attributes of Resource Flows Systems Resource Flow Matrix (SV-6)/ Services Resource Flow Matrix (SvcV-6)

45 Mapping Summary PV-1 Project Organization SV-3 PV-3 CV-5 SV-5Systems/Services Operational Activity Capability CV-6 SvcV-5 CV-7 SvcV-3 Mappings help check for architecture consistency.

46 Other Example QuestionsRequired Data Types Views What organizations are included in the architecture and how do they relate to the performers or other elements of the architecture? Organizations Reporting/management relationships Relationships of organizations to other elements of the architecture Organizational Relationships Chart (OV-4) What are the key communications IT that support the systems/services interfaces? Systems/services Communications systems, technologies & protocols Relationships among the above Systems Resource Flow Description (SV-2)/ Services Resource Flow Description (SvcV-2) What are the systems functions/services and the data flow among them? Systems functions/services Data flows among the systems functions/producer-consumer flows among the services System Functionality Description (SV-4)/ Services Functionality Description (SvcV-4)

47 Planning Example

48 Purpose Document As-Is process for project financial management for Company X Basis for business process standardization Reference for Project Managers (PMs) Training for new PMs Basis for process improvement and upgraded automation

49 Stakeholders and Issues (1)Project Managers What actions are required to initiate a contract? What actions are required to complete the mid-month and end-of-month direct charge amount checks? What actions are required to complete invoice approval? What information needs to be provided to Accounting? How is that information provided (i.e., what mechanism is used)?

50 Stakeholders and Issues (2)Accounting What information is required from the PM prior to initiating a contract? What information do PMs require to ensure accurate invoices? How does Accounting receive and provide this information? What are the information and reporting requirements for an integrated financial system?

51 Stakeholders and Issues (3)Group Managers Are all the PMs following the same procedures to initiate contracts and approve invoices? Are the system(s) used by PMs to manage financial information adequate? [Are the system(s) used by the PMs to manage financial information support easy and accurate assessment of project status?]

52 Stakeholders and Issues (4)Executive Management Are there opportunities to simplify the contract initiation process? What activities would a new, integrated financial system have to support? What is the set of projects and internal organizations involved?

53 Scope Solution Level architectureMission/function/organizational bounds: Normal interactions between PMs and Accounting in the execution of a single, prime contract Normal bi-monthly interaction Geographic bounds: Activities are all performed at Company X HQ for projects in the U.S. Timeframe: As-Is Constraints: Application level analysis; no infrastructure to be examined; systems to be treated as “black boxes” Expected Analysis: Opportunities for improvement

54 Data & Views – Processes (1)Related Issues What actions are required to initiate a contract? What actions are required to complete the mid-month and end-of-month direct charge amount checks? What actions are required to complete invoice approval? Are all the PMs following the same procedures to initiate contracts and approve invoices? Are there opportunities to simplify the contract initiation process?

55 Data & Views – Processes (2)Needed Data & Views As-Is Business Process descriptions, including systems used, organizations involved, and where policies are implemented – Activity Model (OV-5) with IDEF0, activities decomposed to show interactions between PMs and Accounting; OV-1 Policies – Operational Rules Model (OV-6a) with structured English; rules mapped to controls on OV-5 Scenarios showing differences between individual PM’s processes and showing opportunities for improvement – Operational Event/Trace Descriptions (OV-6c), specific scenarios TBD

56 Data & Views – Information (1)Related Issues What information needs to be provided to Accounting? What information is required from the PM prior to initiating a contract? What information do PMs require to ensure accurate invoices?

57 Data & Views – Information (2)Needed Data & Views Inputs and outputs from business process activities that go between PMs and Accounting Activity Model (OV-5) Operational Resource Flow Description (OV-2) with organizations as nodes Operational Resource Flow Matrix (OV-3) with following columns: Needline ID, Information Exchange ID, Description, Media, Triggering Event, Producing Node and Activity, Receiving Node and Activity; may potentially need format standards for information exchanges

58 Data & Views – Information Mechanisms (1)Related Issues How is that information provided (i.e., what mechanism is used)? How does Accounting receive and provide this information?

59 Data & Views – Information Mechanisms (2)Needed Data & Views Form and format of the information – Operational Resource Flow Matrix with media and format columns Systems and system interfaces used to automate information exchanges – Systems Interface Description (SV-1), system-to-system perspective, showing applications and databases on graphic

60 Data & Views – Process Improvement (1)Related Issues What is the set of projects and internal organizations involved? Are the system(s) used by PMs to manage financial information adequate? What are the information and reporting requirements for an integrated financial system? What activities would a new, integrated financial system have to support?

61 Data & Views – Process Improvement (2)Needed Data & Views Company X organizations and reporting relationships – Organizational Relationships Chart (OV-4) showing existing project organizations; color code to show relationships to performers Mapping of systems to business processes and information exchanges – Systems Interface Description (SV-1); Operational Activity to Systems Function Traceability Matrix (SV-5) with applications instead of systems functions Current standards in support of interoperability - Standards Profile (StdV-1) with FEA TRM and service areas of interest TBD

62 Summary of Selected ViewsOV-1 OV-2: performers are roles OV-3: with Needline ID, Information Exchange ID, Description, Media, Format, Triggering Event, Producing Node and Activity, Receiving Node and Activity columns OV-4: with map to performers OV-5: IDEF0 with controls and system mechanisms OV-6a: Structured English, mapped to activity controls OV-6c: scenarios TBD SV-1: System to System perspective with applications and database SV-5: with applications instead of systems StdV-1: using FEA TRM Plus AV-1 and AV-2, as always