Presented by Shelton Lee Paul Johnson 11 April 2011

Presented by Shelton Lee Paul Johnson 11 April 2011
4/19/2017 DoDAF 2.0 In Action Search and Rescue (SAR) Example User Experience and Analysis Introduction… Shelton and Paul Presented by Shelton Lee Paul Johnson 11 April 2011

DoD Enterprise Architecture Conference
4/19/2017 Contents Search and Rescue (SAR) Example Overview Why SAR as an Example? SAR Scenario Perspective SAR Scenario Trigger DoDAF Development Process SAR Analysis Conclusion and Recommendations Shelton 4/19/2017 DoD Enterprise Architecture Conference

Search and Rescue (SAR) Example Overview
4/19/2017 Search and Rescue (SAR) Example Overview DoDAF architecture example using a functional “thread” of Search and Rescue (SAR) concept Provides an architectural example of DoDAF 2.0 in Action using a real world construct Shows how architectural analysis can answer SAR Program Management questions Limited to United States Coast Guard SAR Focused on “search” aspect of SAR only Defined using current (as-is) capabilities Data used throughout for illustrative purpose only Shelton Intent of this architecture effort is to describe the DOD SAR with enough clarity to offer an architect an example of all the DoDAF version 2.0 views and how they relate and support each other to describe a total enterprise architecture. 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 Why SAR as an Example? Publicly and freely available information to support detailed architecture Universally understood concept performed and supported worldwide Enough information to support all relevant DoDAF 2.0 views Concept contains real world problems that can be solved with architecture Shelton Talk through why we chose SAR DoD supported through USCG and USAF with supportive USN and USMC roles Example of all DoDAF version 2.0 views and how they relate and support each other to describe a total enterprise architecture Several 'fit for purpose' views will also be developed to fully articulate vision of DOD SAR Complete example uses most of the DoDAF 2.0 views to describe SAR – demonstration only shows one small “thread” 4/19/2017 DoD Enterprise Architecture Conference

SAR Scenario Perspective
4/19/2017 SAR Scenario Perspective SAR scenario will be accomplished through several roles in context of Program Management Two primary roles will exchange information: SAR Program Manager (PM) SAR Enterprise Architect (EA) Demonstration will alternate between static presentation and interactive product display Shelton How we are going to tell the story… Through various roles – SAR PM and EA Knitting it all together with architecture views and supportive data Shelton will play the role of the PM Paul will play the role of the enterprise architect Other roles are typically necessary to complete a fully integrated enterprise architecture but will not be addressed for demonstration 4/19/2017 DoD Enterprise Architecture Conference

SAR Scenario Trigger – Problem Statement
4/19/2017 SAR Scenario Trigger – Problem Statement The service (USCG) saw its proposed 2011 budget cut by 3 percent. Rescuing the Coast Guard From Chronically Low Budget July 2010 By Stew Magnuson National Defense Magazine article “Everyone loves the Coast Guard, but that affection hasn’t translated into a budget that can sustain its ships, aircraft and personnel” Shelton How can we achieve our goals of saving lives while responding to budget cuts? Show me the scope and possible analysis needed 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 SAR Scenario Problem statement triggered conversation between PM and EA teams Enterprise architecture team recommended using latest version of framework - DoDAF 2.0 DoDAF six-step process recommended as best practice by enterprise architecture team Collaborative efforts were undertaken between: Program Management Team Enterprise Architecture Team Operational Team System and Engineering Team Shelton transition to Paul Given our problem statement, lets talk through artifacts required to support 4/19/2017 DoD Enterprise Architecture Conference

DoDAF Six-Step Development Process
4/19/2017 DoDAF Six-Step Development Process Determine Intended Use of architecture Determine Scope of architecture Determine Data Required to support architecture development Collect, Organize, Correlate, & Store architectural data Conduct Analyses in support of architecture objectives Document Results in accordance with decision-maker needs Paul to PM In keeping with DoDAF architecture best practice we recommend as six step process for development I need you and your team’s assistance in the first several steps to ensure success of the project 4/19/2017 DoD Enterprise Architecture Conference

Step 1 - Determine Intended Use of Architecture
4/19/2017 Step 1 - Determine Intended Use of Architecture Find ways we can reduce cost to meet new budget restrictions using enterprise architecture data Use analysis methods for time and cost Examine data and dependencies of “search” What is highest value that could be gained for this effort? Build “search” architecture outwards Establish foundation for future optimization Paul We need to determine the primary intent of the EA effort Shelton We have a budget crisis and need to look at ways to reduce costs Where do you feel that the highest value could be gained for this effort? The “search” aspect of our program has the highest cost and should be your initial target area So our primary intention for the effort is to understand costs associated with “search” and look for any anomalies that may reveal a way to cut costs without reducing efficiency Our primary intent is to understand costs associated with “search” and look for any anomalies that may reveal a way to cut costs without reducing efficiency… 4/19/2017 DoD Enterprise Architecture Conference

Purpose Excerpt from Overview and Summary Information (AV-1)
4/19/2017 Purpose Excerpt from Overview and Summary Information (AV-1) Excerpt from Overview and Summary Information (AV-1) Paul 4/19/2017 DoD Enterprise Architecture Conference

Step 2 - Determine Scope of Architecture
4/19/2017 Step 2 - Determine Scope of Architecture Limit to Coast Guard specific SAR Focus on “search” aspect of SAR through capability and functional analysis Define AS-IS (current only) capabilities Identify and focus on elements that have a high cost (time and money) Phase 1 of EA development will provide enough “depth” to discover possible vulnerabilities that require future optimization Paul Analyze processes from when a beacon distress signal is received until the victim is either recovered and medically stable in a safe location or the search is determined to be unfeasible Shelton questions? 4/19/2017 DoD Enterprise Architecture Conference

High Level Operational Concept Graphic (OV-1)
4/19/2017 High Level Operational Concept Graphic (OV-1) Definition: Scenario from a conceptual level. Main operational concepts System and operational (human) interaction Data Sources: Mission Statement, Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document Purpose: Provide high-level description of what the architecture is supposed to do and how it is supposed to do it. Analysis: Find costly and burdensome capabilities that others are dependent upon for speed and reliability Consumers: Executive Level Stakeholder Enterprise Architect Program Manager General Stakeholder Paul 4/19/2017 DoD Enterprise Architecture Conference

SAR High Level Operational Concept Graphic (OV-1)
4/19/2017 SAR High Level Operational Concept Graphic (OV-1) Paul Search and rescue requires a complex cooperation between many organizations and systems to perform a mission. There are many technologies involved some which have been around for decades and some that are new technology 4/19/2017 DoD Enterprise Architecture Conference

High Level Operational Concept Graphic (OV-1)
4/19/2017 High Level Operational Concept Graphic (OV-1) Disaster occurs (person is in distress) Emergency beacon is activated Signal is picked up by other ships and satellites Signal received by Mission Control Center Search team analyzes signal for location Rescue Coordination Center dispatches search and rescue team Debrief and “lessons learned” Paul 4/19/2017 DoD Enterprise Architecture Conference

Step 3 - Determine Data Required to Support Architecture Development
4/19/2017 Step 3 - Determine Data Required to Support Architecture Development Reason Data Required Understand high level context for scope Capabilities and Functions of Scope Knowledge of how “search” capabilities are conducted by human functions Human Processes and Rules regarding “search” specific functions Provide static source to pinpoint high cost functional area(s) of human and system process Data for cost and time of both acting together Understand high level system functions and how they support process and rule Systems and their designed System Functions Knowledge of how “search” is conducted by systems and their system functions “Search” specific System Processes and Rules Paul Data to support level of detail for each artifact/entity Scope, Purpose, and Questions to Answer (AV-1) Vision and Goals (CV-1) Operational level information (CV-2, CV-6) Human operational Processes (OV-6c) Organizational Information System level information (SV-1, SV-2, SV-4, SV-5, DIV-1, DIV-2) System Processes (SV-10c) Rough cost of processes 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 Step 3 - Determine Artifacts Required to Support Architecture Development Overview and Summary Information (AV-1) Scope, Goals and Purpose Capability Vision (CV-1) Goals, Purpose, and Capability dependencies Capability Taxonomy (CV-2) Capability Dependencies Capability to Activity Map (CV-6) Capability and Functions of Scope Operational (Human) Process (OV-6) Human Processes, Rules and Data System Process (SV-10) System Processes, Rules and Data Paul Depth and Breadth (Views needed) AV-1 - Scope, Purpose, and Questions to Answer CV-1 - Overall vision provides a strategic context for capabilities described including goals CV-2 - hierarchy which specifies all capabilities that are referenced throughout one or more Architectural Descriptions CV-6 - Mapping between capabilities required and operational activities that those capabilities support. OV-6 - Traces actions in a scenario or sequence of events from a human (operational) perspective. SV-10 – System perspective action trace for a scenario or sequence of events A number of other supportive views were created to understand and define the entire SAR program – only ones relevant to the demonstration thread are listed 4/19/2017 DoD Enterprise Architecture Conference

Overview and Summary Information (AV-1)
4/19/2017 Overview and Summary Information (AV-1) Description: Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Outcomes, and produced objects. Purpose: Explains need for architecture and what it should demonstrate Defines types of analyses and who is expected to perform analyses Relates decisions expected to be made on basis of an analysis and resultant actions Data Sources: Policy Document, Subject Matter Expert (SME) Interview, Concepts of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document Analysis: Determine level of effort required to produce product set to answer architectural questions Consumers: Executive Level Stakeholder Enterprise Architect Program Manager General Stakeholder Paul 4/19/2017 DoD Enterprise Architecture Conference

SAR Overview and Summary Information (AV-1)
4/19/2017 SAR Overview and Summary Information (AV-1) Paul 4/19/2017 DoD Enterprise Architecture Conference

SAR Overview and Summary Information Graphical Example
4/19/2017 SAR Overview and Summary Information Graphical Example Vision Architecture Development Phase Goal Overview View Paul Here is a graphical view of the AV-1 that shows the architecture effort by architecture phase You can use this as a quick reference guide when explaining what we are doing to others Purpose: Enable readers to understand the scope of the EA effort through graphic visualization of the vision, goals, overview and the views contained in each development phase. 4/19/2017 DoD Enterprise Architecture Conference

SAR Overview and Summary Information (AV-1)
4/19/2017 SAR Overview and Summary Information (AV-1) Scenario The scenario for this example begins with an event resulting in the activation of a beacon. The particular beacon used will affect the time required to receive and transmit the signal to a Local User Terminal and onward to a Mission Control Center where it may be validated. Once validated the signal is the basis of a satellite based search for the “person in distress”. Here again , time delays may result because of the beacon used. The “person in distress” is located, rescued and returned to the Mission Control Center where the SAR mission is administratively closed. Purpose The EPIRB (Emergency Position Indicating Radio Beacon) for 121 MHz are being phased out and 406 MHz are becoming the standard for search and rescue (SAR) throughout the world. This system change will affect the way SAR is conducted primarily from a search perspective. Description This release and subsequent releases will describe USCG Search and Rescue (SAR) mission with enough details to optimize performance and reduce costs for SAR. Overview This architecture is scoped to the USCG SAR mission and specifically to events immediately following an incident up to the administrative closure of the response effort. This will present an opportunity to demonstrate how systems and people act together to accomplish this mission while data associated with these actions will expose utility, value and opportunities for improved performance. Paul Actual Av-1 is online as document, graphical, textual freeform input 4/19/2017 DoD Enterprise Architecture Conference

Step 4 - Collect, Organize, Correlate, and Store Architectural Data
4/19/2017 Step 4 - Collect, Organize, Correlate, and Store Architectural Data Data was collected using tools that can capture all data to support DoDAF 2.0 views Worked with operational and system team to gather information to create views Data was stored in a repository that supports robust storage and analytical capabilities Data was collected through screen entry and import Paul Collection of data through a tool that supports at a minimum the DoDAF 2.0 metamodel Data stored in a tool that has robust storage and business intelligence capabilities Tools used should support DM2 PES import and export for data reuse and sharing amongst various architectural efforts 4/19/2017 DoD Enterprise Architecture Conference

Capability Vision (CV-1)
4/19/2017 Capability Vision (CV-1) Definition: Overall vision for transformational endeavors, which provides a strategic context for capabilities described and high-level scope. Data Sources: Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document Purpose: Provide strategic context for capabilities described in Architectural Description and communicates strategic vision regarding capability structure Analysis: Vision to goals with supportive capability Consumers: Decision maker Enterprise Architect Paul Necessary to know what capabilities may be effected by goals so that further analysis can be done to see if any critical pieces are effected 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability Vision (CV-1)
Purpose: Understand relationships between SAR vision , goals and supportive capability Vision Guidance Goal Focus for “thread” Capability 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability Vision (CV-1)
4/19/2017 SAR Capability Vision (CV-1) Vision: Save lives, defend our borders, and protect the environment Mission: Reduce operating costs to meet budget cuts Goal: Increase personnel recovery effectiveness and efficiency Capability Manage SAR Support Operate SAR Mission Coordinate SAR Operations Paul Focus for “thread” 4/19/2017 DoD Enterprise Architecture Conference

Capability Taxonomy (CV-2)
4/19/2017 Capability Taxonomy (CV-2) Definition: Hierarchy of capabilities decomposed down to leaf level to categorize activities Data Sources: Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document Purpose: Identify and organize capabilities through logical decomposition to support planning and gap analysis Analysis: Which capabilities support & relate to each other Consumers: Enterprise Architect Program Manager 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability Taxonomy (CV-2)
4/19/2017 SAR Capability Taxonomy (CV-2) Time and cost data is for illustrative purpose only and does not reflect real values. Focus for Scenario: Locate Person in Distress Capability Leaf Capability Paul First level of entities that expose the overall capabilities of SAR Graphical view of all capabilities to look for high cost or inefficiencies Purpose: Understand SAR capabilities in context of each other and note any anomalies that are exposed through attributed “data graphics”. 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability Taxonomy (CV-2)
4/19/2017 SAR Capability Taxonomy (CV-2) Execute SAR (Capability) Operate SAR Mission (Capability) Locate Person in Distress (Capability) Support Person in Distress (Capability) Conduct Recovery (Capability) Highest level Capability (root) Focus for Scenario (leaf) Lower level Capability (child/parent) Paul Other Capabilities were decomposed to process level but we will not be focusing on those during this presentation The border between capability and operational activity is defined at leaf level. Capabilities structure categories of activities independent of processes at an implementation. 4/19/2017 DoD Enterprise Architecture Conference

Capability To Operational Activity (CV-6)
4/19/2017 Capability To Operational Activity (CV-6) Definition: Captures capabilities required and activities that enable those capabilities. Purpose: Shows leaf level capabilities. Aligns leaf level capabilities with supporting activities Provides categorization and organization of activities Data Sources: Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document Analysis: What activities support which capabilities Consumers: Enterprise Architect Program Manager Paul decomposes capabilities into unique operations at a leaf level Each of these level functions can now be analyzed in a context level process model 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability to Operational Activity (CV-6)
4/19/2017 SAR Capability to Operational Activity (CV-6) Purpose: Express leaf level capabilities and their supporting operational activities. Time and cost data is for illustrative purpose only and does not reflect real values. Leaf –level Capability relates to Operational Activity Capability Most expensive activity Paul Part of a bigger diagram - excerpt Shows leaf capability and “nested” activities. (These activities are themselves Leaf activities – children of a separate hierarchy expressing the work necessary to organize Process (How). Capabilities form the effects hierachy… Activities form the work hierarchy and Process form the ‘solution’ hierarchy where it really gets done. 4/19/2017 DoD Enterprise Architecture Conference

SAR Capability to Operational Activity (CV-6)
4/19/2017 SAR Capability to Operational Activity (CV-6) Operate SAR Mission (Capability) Locate Person in Distress (Capability) Perform Electronic Search (Activity) Perform Visual Search (Activity) Support Person in Distress (Capability) Establish Communications (Activity) Increase Situational Awareness (Activity) Deliver Supply (Activity) Conduct Recovery(Capability) Deploy Recovery Team (Activity) Recover Person in Distress (Activity) Authenticate Person in Distress (Activity) Most expensive activity Paul 4/19/2017 DoD Enterprise Architecture Conference

Activity to Process Map (FFP)
4/19/2017 Activity to Process Map (FFP) “Fit for purpose” view to support relation of Activity to supportive Processes (one to many) One Activity may support or describe many Processes Each Process model supports different ways of performing each Activity Paul “Fit for purpose” views enable us as architects to communicate information relevant to illustrate a point 4/19/2017 DoD Enterprise Architecture Conference

Activity to Process Map (FFP)
4/19/2017 Activity to Process Map (FFP) Time and cost data is for illustrative purpose only and does not reflect real values. Pragmatica Innovations Most expensive process Paul “Fit for purpose” views enable us as architects to communicate information relevant to illustrate a point Purpose: Show relationships between activities and processes. Process Model(s) 4/19/2017 DoD Enterprise Architecture Conference

Operational (Human) Process Model (OV-6)
4/19/2017 Operational (Human) Process Model (OV-6) Definition: Models the timing and sequencing of events that capture operational behavior of an process or function. Purpose: Traces actions in a scenario or sequence of events Data Sources: Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document Analysis: Cost and timing of process Process dependency on logical data and state changes Consumers: Enterprise Architect Program Manager General Stakeholder Paul Process diagrams enable architects to understand the many nuances of operational activities Specific metrics can be captured to analyze processes that may be problem sources 4/19/2017 DoD Enterprise Architecture Conference

SAR Operational Process Model – Perform SARSAT Search (OV-6)
4/19/2017 SAR Operational Process Model – Perform SARSAT Search (OV-6) Time and cost data is for illustrative purpose only and does not reflect real values. Supportive Data Human(s) represented as Pool Most expensive process Paul Gateway Process Using supportive data (as mandated in DoDAF 2.0) we can see this process seems to be taking too long and thus costing too much money. 4/19/2017 DoD Enterprise Architecture Conference

SAR Operational Process Model - Perform SARSAT Search (OV-6)
4/19/2017 SAR Operational Process Model - Perform SARSAT Search (OV-6) Deploy Direction Finding Team Track Signal Emergency beacons of varying frequencies are used by victims to aid the coast guard in finding them. Determine Search Area If search area is small then (determined in another process) Search small area ($25,000, 10 hours) If search area is large then (determined in another process) Search large area ($100,000, 54 hours) Search for Distressed Victims Is Person in Distress Located? Person in Distress is located Person in Distress is not located Paul wanted to know exactly what was determining the difference in search area size 4/19/2017 DoD Enterprise Architecture Conference

Enterprise Architecture Analysis
4/19/2017 Enterprise Architecture Analysis Analysis revealed that “problem” was not in operational (human) process but possibly a system or system process problem Had to move “through” the architecture to understand source of problem Large area resulted from Determine Search Area Process Based on ability to track signal Type of signal was based on type of satellite Analysis performed on systems related to costs Paul Walking dog backward ...to beacon. Emphasize it was expensive, Cumulative cost analysis will reveal on next few sides that systems contribute to cost (in time, which is $ once active in a search) By delay in getting a valid signal to begin SARSAT search 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 System Process (SV-10) Definition: Defines system scenario from a logical level with system and system process interaction Data Sources: Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactics, Techniques and Procedures, Operational Requirement Documents Purpose: Provide system process interaction Analysis: System process cost and time analysis. Resource impact analysis. System Behavioral analysis. Identification of non-functional system requirements Consumers: Enterprise Architect Program Manager General Stakeholder Paul 4/19/2017 DoD Enterprise Architecture Conference

SAR System Process – Monitor Distress Signal (SV-10)
4/19/2017 SAR System Process – Monitor Distress Signal (SV-10) Time and cost data is for illustrative purpose only and does not reflect real values. Most complex path Gateway System(s) represented as “Lane” Process Paul deep dive on system side into the various types of emergency beacon technology and monitoring technology. older beacon technology could be root cause of issue Data Object Looking at systems involved in this process we can see that the system (EPIRB) seems to be the root cause –specifically the 121 MHz beacon. 4/19/2017 DoD Enterprise Architecture Conference

SAR System Process – Monitor Distress Signal (SV-10)
Start Monitor Distress Signal Select Beacon? Transmit MHz Signal LEOSAR in Range? Repeat Signal LUT in Range? LUT Receive Signal Confirm Signal? LUT Transmit Signal Paul Walk thru SV-10 “happy path” for 121 MHZ beacon

Step 5 – Conduct Analysis in Support of Architecture Objective
4/19/2017 Step 5 – Conduct Analysis in Support of Architecture Objective Multiple types of analyses are available to an architectural effort with two primary categories: Static analysis leverages model structure and attributes to derive qualitative, quantitative and functional analyses Dynamic analysis (executable models) examine temporal, spatial, or other performance aspects of a solution through dynamic simulations Static analyses were performed using analysis tools through database queries for function and quantity Paul Conduct Analyses in Support of Architecture Objectives Architecture validation May help determine future architectural efforts Repeat steps 3-5 as necessary 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 Step 5 – Conduct Analysis in Support of Architecture Objective Quantitative analysis was performed across entire architecture to discover the process where anomaly first appears - Perform SARSAT Search Looked at process from human and system side which are both tied to the same operational activity Problem was revealed in system view analysis - specifically radio beacons (121.5 and 406 MHz) Paul 4/19/2017 DoD Enterprise Architecture Conference

4/19/2017 Step 5 – Conduct Analysis in Support of Architecture Objective Many types of static analyses are available using architectural data Two specific types were chose to best represent our SAR example problem Process Analysis Operational from cost & time perspective System from an efficiency perspective SWOT (Strength, Weakness, Opportunity and Threat) 121.5 MHz beacon (EPIRB) 406 MHz beacon (EPIRB) Paul many overarching types of higher level analysis that can be performed using architecture chose several in order to best understand problem 4/19/2017 DoD Enterprise Architecture Conference

Process Analysis (Cost and Time)
4/19/2017 Process Analysis (Cost and Time) Time and cost data is for illustrative purpose only and does not reflect real values. 121.5MHz Cost 121.5MHz Time 406 MHz Cost 406 MHz Time Paul looked at cost and time differences using analysis from data collected in process models Architect finds anomaly in search time where one process appears less efficient Search area is reduced when using 400 MHz EPIRB (Radio Beacon) Architectural analysis reveals cost and time Further analysis reveals that lower frequency EPIRB requires more search time Updates through LEO vs geostationary satellites also requires additional time 121.5 MHz beacon search costs $103,000 and takes 55 hours to locate versus $28,500 and 11 hours to locate when using 406 MHz version 4/19/2017 DoD Enterprise Architecture Conference

SWOT Analysis Strength Weakness Opportunity Threat 121.5 MHz EPIRB Cheap to purchase Light weight Trusted technology Ineffective Reduced range Salvage for parts Recycle plastic Investigate reuse? Very expensive to search Increased chance of not locating victim in time 406 MHz EPIRB Instant pickup Identifying information More powerful signal Transmits longer period of time Cost more Heavier weight Bulkier More lives saved Reduced cost of searching No migration plan Impacts to general public if mandated for use 4/19/2017 DoD Enterprise Architecture Conference

Step 6 - Document Results In Accordance With Decision-Maker Need
4/19/2017 Step 6 - Document Results In Accordance With Decision-Maker Need Results were documented using DoDAF 2.0 artifacts and supportive data Architecture structured and reflected solution for analysis Architecture presented requirements for change through updates in the architecture – the “to-be” or future state Paul Creation of presentations for decision makers Documentation of results and lessons learned in AV-1 Supportive data, reports, and drawings were provided to decision makers 4/19/2017 DoD Enterprise Architecture Conference

Phase 2 of SAR Architecture Development
4/19/2017 Phase 2 of SAR Architecture Development Updated views and new views to present the way forward... Paul recommend phase 2 of architecture development center on details of modifying new solution… 4/19/2017 DoD Enterprise Architecture Conference

Conclusion and Recommendations
4/19/2017 Conclusion and Recommendations Conclusion 121.5Mhz beacons cost more time and money to locate Recommendations Phase out older 121.5mhz beacon technology Change & implement new system standards Paul …handoff to Shelton 4/19/2017 DoD Enterprise Architecture Conference

Questions? “DoDAF in Action” booth is at T5 for complete details of SAR Example DoD booth is at T1 for details or DoDAF general questions DoD booth is at T4 for government representative Shelton Complete SAR enterprise architecture is also available at

Contact Information Shelton Lee Office: Mobile: Paul W. Johnson Office: Mobile: 4/19/2017 DoD Enterprise Architecture Conference

Backup Slides Following slides are backup and supporting information

Quality Assurance Architecture completeness - existing views compared to projected views in AV-1, object counts, Architecture validation – diagram counts and information compared to compliances such as JCIDS Object completeness – completeness of data attribute information Object connectedness – relationships between objects, count, average, lack of relationships Object correctness – validation of information vs sources, reference source tracking There are many types of analysis. We will perform quality assurance analysis on the architecture as we are developing it to ensure accuracy and completeness. Avoid conflict of completeness vs counts

Presented by Shelton Lee Paul Johnson 11 April 2011

Similar presentations

Presentation on theme: "Presented by Shelton Lee Paul Johnson 11 April 2011"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Presented by Shelton Lee Paul Johnson 11 April 2011

Similar presentations

Presentation on theme: "Presented by Shelton Lee Paul Johnson 11 April 2011"— Presentation transcript:

Similar presentations

About project

Feedback