Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DOD EA conference DoDAF in Action

2,837 views

Published on

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.

  • Be the first to comment

DOD EA conference DoDAF in Action

  1. 1. DoDAF 2.0 In Action Search and Rescue (SAR) Example User Experience and Analysis Presented by Shelton Lee Paul Johnson 11 April 2011
  2. 2. <ul><li>Search and Rescue (SAR) Example Overview </li></ul><ul><li>Why SAR as an Example? </li></ul><ul><li>SAR Scenario Perspective </li></ul><ul><li>SAR Scenario Trigger </li></ul><ul><li>DoDAF Development Process </li></ul><ul><li>SAR Analysis </li></ul><ul><li>Conclusion and Recommendations </li></ul>Contents 10/17/11 DoD Enterprise Architecture Conference
  3. 3. <ul><li>DoDAF architecture example using a functional “thread” of Search and Rescue (SAR) concept </li></ul><ul><li>Provides an architectural example of DoDAF 2.0 in Action using a real world construct </li></ul><ul><li>Shows how architectural analysis can answer SAR Program Management questions </li></ul><ul><li>Limited to United States Coast Guard SAR </li></ul><ul><li>Focused on “ search ” aspect of SAR only </li></ul><ul><li>Defined using current (as-is) capabilities </li></ul><ul><li>Data used throughout for illustrative purpose only </li></ul>Search and Rescue (SAR) Example Overview 10/17/11 DoD Enterprise Architecture Conference
  4. 4. <ul><li>Publicly and freely available information to support detailed architecture </li></ul><ul><li>Universally understood concept performed and supported worldwide </li></ul><ul><li>Enough information to support all relevant DoDAF 2.0 views </li></ul><ul><li>Concept contains real world problems that can be solved with architecture </li></ul>Why SAR as an Example? 10/17/11 DoD Enterprise Architecture Conference Complete example uses most of the DoDAF 2.0 views to describe SAR – demonstration only shows one small “thread”
  5. 5. <ul><li>SAR scenario will be accomplished through several roles in context of Program Management </li></ul><ul><li>Two primary roles will exchange information: </li></ul><ul><ul><li>SAR Program Manager (PM) </li></ul></ul><ul><ul><li>SAR Enterprise Architect (EA) </li></ul></ul><ul><li>Demonstration will alternate between static presentation and interactive product display </li></ul>SAR Scenario Perspective 10/17/11 DoD Enterprise Architecture Conference Other roles are typically necessary to complete a fully integrated enterprise architecture but will not be addressed for demonstration
  6. 6. SAR Scenario Trigger – Problem Statement 10/17/11 DoD Enterprise Architecture Conference 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” The service (USCG) saw its proposed 2011 budget cut by 3 percent.
  7. 7. <ul><li>Problem statement triggered conversation between PM and EA teams </li></ul><ul><li>Enterprise architecture team recommended using latest version of framework - DoDAF 2.0 </li></ul><ul><li>DoDAF six-step process recommended as best practice by enterprise architecture team </li></ul><ul><li>Collaborative efforts were undertaken between: </li></ul><ul><ul><li>Program Management Team </li></ul></ul><ul><ul><li>Enterprise Architecture Team </li></ul></ul><ul><ul><li>Operational Team </li></ul></ul><ul><ul><li>System and Engineering Team </li></ul></ul>SAR Scenario 10/17/11 DoD Enterprise Architecture Conference
  8. 8. <ul><li>Determine Intended Use of architecture </li></ul><ul><li>Determine Scope of architecture </li></ul><ul><li>Determine Data Required to support architecture development </li></ul><ul><li>Collect, Organize, Correlate, & Store architectural data </li></ul><ul><li>Conduct Analyses in support of architecture objectives </li></ul><ul><li>Document Results in accordance with decision-maker needs </li></ul>DoDAF Six-Step Development Process 10/17/11 DoD Enterprise Architecture Conference
  9. 9. <ul><li>Find ways we can reduce cost to meet new budget restrictions using enterprise architecture data </li></ul><ul><li>Use analysis methods for time and cost </li></ul><ul><li>Examine data and dependencies of “search” </li></ul><ul><li>What is highest value that could be gained for this effort? </li></ul><ul><li>Build “search” architecture outwards </li></ul><ul><li>Establish foundation for future optimization </li></ul>Step 1 - Determine Intended Use of Architecture 10/17/11 DoD Enterprise Architecture Conference 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…
  10. 10. <ul><li>Excerpt from Overview and Summary Information (AV-1) </li></ul>Purpose Excerpt from Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
  11. 11. <ul><li>Limit to Coast Guard specific SAR </li></ul><ul><li>Focus on “search” aspect of SAR through capability and functional analysis </li></ul><ul><li>Define AS-IS (current only) capabilities </li></ul><ul><li>Identify and focus on elements that have a high cost (time and money) </li></ul>Step 2 - Determine Scope of Architecture 10/17/11 DoD Enterprise Architecture Conference <ul><li>Phase 1 of EA development will provide enough “depth” to discover possible vulnerabilities that require future optimization </li></ul>
  12. 12. <ul><li>Definition : Scenario from a conceptual level. </li></ul><ul><ul><li>Main operational concepts </li></ul></ul><ul><ul><li>System and operational (human) interaction </li></ul></ul><ul><li>Data Sources : Mission Statement, Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document </li></ul><ul><li>Purpose : Provide high-level description of what the architecture is supposed to do and how it is supposed to do it. </li></ul><ul><li>Analysis : Find costly and burdensome capabilities that others are dependent upon for speed and reliability </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Executive Level Stakeholder </li></ul></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul><ul><ul><li>General Stakeholder </li></ul></ul>High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
  13. 13. SAR High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
  14. 14. <ul><li>Disaster occurs (person is in distress) </li></ul><ul><li>Emergency beacon is activated </li></ul><ul><li>Signal is picked up by other ships and satellites </li></ul><ul><li>Signal received by Mission Control Center </li></ul><ul><li>Search team analyzes signal for location </li></ul><ul><li>Rescue Coordination Center dispatches search and rescue team </li></ul><ul><li>Debrief and “lessons learned” </li></ul>High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
  15. 15. Step 3 - Determine Data Required to Support Architecture Development 10/17/11 DoD Enterprise Architecture Conference 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
  16. 16. <ul><ul><li>Operational (Human) Process (OV-6) </li></ul></ul><ul><ul><ul><li>Human Processes, Rules and Data </li></ul></ul></ul><ul><li>System Process (SV-10) </li></ul><ul><ul><li>System Processes, Rules and Data </li></ul></ul>Step 3 - Determine Artifacts Required to Support Architecture Development 10/17/11 DoD Enterprise Architecture Conference 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 <ul><li>Overview and Summary Information (AV-1) </li></ul><ul><ul><li>Scope, Goals and Purpose </li></ul></ul><ul><li>Capability Vision (CV-1) </li></ul><ul><ul><li>Goals, Purpose, and Capability dependencies </li></ul></ul><ul><li>Capability to Activity Map (CV-6) </li></ul><ul><ul><li>Capability and Functions of Scope </li></ul></ul><ul><li>Capability Taxonomy (CV-2) </li></ul><ul><ul><li>Capability Dependencies </li></ul></ul>
  17. 17. <ul><li>Description : Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Outcomes, and produced objects. </li></ul><ul><li>Purpose : </li></ul><ul><ul><li>Explains need for architecture and what it should demonstrate </li></ul></ul><ul><ul><li>Defines types of analyses and who is expected to perform analyses </li></ul></ul><ul><ul><li>Relates decisions expected to be made on basis of an analysis and resultant actions </li></ul></ul><ul><li>Data Sources : Policy Document, Subject Matter Expert (SME) Interview, Concepts of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document </li></ul><ul><li>Analysis : Determine level of effort required to produce product set to answer architectural questions </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Executive Level Stakeholder </li></ul></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul><ul><ul><li>General Stakeholder </li></ul></ul>Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
  18. 18. SAR Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
  19. 19. SAR Overview and Summary Information Graphical Example 10/17/11 DoD Enterprise Architecture Conference Overview Goal Vision View Architecture Development Phase 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.
  20. 20. <ul><li>Scenario </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Purpose </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Description </li></ul><ul><ul><li>This release and subsequent releases will describe USCG Search and Rescue (SAR) mission with enough details to optimize performance and reduce costs for SAR. </li></ul></ul><ul><li>Overview </li></ul><ul><ul><li>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. </li></ul></ul>SAR Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
  21. 21. <ul><li>Data was collected using tools that can capture all data to support DoDAF 2.0 views </li></ul><ul><li>Worked with operational and system team to gather information to create views </li></ul>Step 4 - Collect, Organize, Correlate, and Store Architectural Data 10/17/11 DoD Enterprise Architecture Conference <ul><li>Data was stored in a repository that supports robust storage and analytical capabilities </li></ul><ul><li>Data was collected through screen entry and import </li></ul>
  22. 22. <ul><li>Definition : Overall vision for transformational endeavors, which provides a strategic context for capabilities described and high-level scope. </li></ul><ul><li>Data Sources : Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document </li></ul><ul><li>Purpose : Provide strategic context for capabilities described in Architectural Description and communicates strategic vision regarding capability structure </li></ul><ul><li>Analysis : Vision to goals with supportive capability </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Decision maker </li></ul></ul><ul><ul><li>Enterprise Architect </li></ul></ul>Capability Vision (CV-1) 10/17/11 DoD Enterprise Architecture Conference
  23. 23. SAR Capability Vision (CV-1) 10/17/11 DoD Enterprise Architecture Conference Capability Goal Guidance Vision Purpose : Understand relationships between SAR vision , goals and supportive capability Focus for “thread”
  24. 24. <ul><li>Vision : Save lives, defend our borders, and protect the environment </li></ul><ul><li>Mission : Reduce operating costs to meet budget cuts </li></ul><ul><li>Goal : Increase personnel recovery effectiveness and efficiency </li></ul><ul><li>Capability </li></ul><ul><ul><li>Manage SAR Support </li></ul></ul><ul><ul><li>Operate SAR Mission </li></ul></ul><ul><ul><li>Coordinate SAR Operations </li></ul></ul>SAR Capability Vision (CV-1) 10/17/11 DoD Enterprise Architecture Conference Focus for “thread”
  25. 25. <ul><li>Definition : Hierarchy of capabilities decomposed down to leaf level to categorize activities </li></ul><ul><li>Data Sources : Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document </li></ul><ul><li>Purpose : Identify and organize capabilities through logical decomposition to support planning and gap analysis </li></ul><ul><li>Analysis : Which capabilities support & relate to each other </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul>Capability Taxonomy (CV-2) 10/17/11 DoD Enterprise Architecture Conference
  26. 26. SAR Capability Taxonomy (CV-2) 10/17/11 DoD Enterprise Architecture Conference Purpose: Understand SAR capabilities in context of each other and note any anomalies that are exposed through attributed “data graphics”. Focus for Scenario: Locate Person in Distress Capability Leaf Capability Time and cost data is for illustrative purpose only and does not reflect real values.
  27. 27. <ul><ul><ul><li>Execute SAR (Capability) </li></ul></ul></ul><ul><ul><li>Operate SAR Mission (Capability) </li></ul></ul><ul><ul><ul><li>Locate Person in Distress (Capability) </li></ul></ul></ul><ul><ul><ul><li>Support Person in Distress (Capability) </li></ul></ul></ul><ul><ul><ul><li>Conduct Recovery (Capability) </li></ul></ul></ul>SAR Capability Taxonomy (CV-2) 10/17/11 DoD Enterprise Architecture Conference <ul><ul><ul><li>Highest level Capability ( root ) </li></ul></ul></ul><ul><ul><ul><li>Lower level Capability ( child/parent ) </li></ul></ul></ul>Focus for Scenario (leaf) The border between capability and operational activity is defined at leaf level. Capabilities structure categories of activities independent of processes at an implementation.
  28. 28. <ul><li>Definition : Captures capabilities required and activities that enable those capabilities. </li></ul><ul><li>Purpose : </li></ul><ul><ul><li>Shows leaf level capabilities. </li></ul></ul><ul><ul><li>Aligns leaf level capabilities with supporting activities </li></ul></ul><ul><ul><li>Provides categorization and organization of activities </li></ul></ul><ul><li>Data Sources : Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement Document </li></ul><ul><li>Analysis: What activities support which capabilities </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul>Capability To Operational Activity (CV-6) 10/17/11 DoD Enterprise Architecture Conference
  29. 29. SAR Capability to Operational Activity (CV-6) 10/17/11 DoD Enterprise Architecture Conference Most expensive activity Capability Purpose : Express leaf level capabilities and their supporting operational activities. Leaf –level Capability relates to Operational Activity Time and cost data is for illustrative purpose only and does not reflect real values.
  30. 30. <ul><li>Operate SAR Mission (Capability) </li></ul><ul><ul><li>Locate Person in Distress (Capability) </li></ul></ul><ul><ul><ul><li>Perform Electronic Search (Activity) </li></ul></ul></ul><ul><ul><ul><li>Perform Visual Search (Activity) </li></ul></ul></ul><ul><ul><li>Support Person in Distress (Capability) </li></ul></ul><ul><ul><ul><li>Establish Communications (Activity) </li></ul></ul></ul><ul><ul><ul><li>Increase Situational Awareness (Activity) </li></ul></ul></ul><ul><ul><ul><li>Deliver Supply (Activity) </li></ul></ul></ul><ul><ul><li>Conduct Recovery(Capability) </li></ul></ul><ul><ul><ul><li>Deploy Recovery Team (Activity) </li></ul></ul></ul><ul><ul><ul><li>Recover Person in Distress (Activity) </li></ul></ul></ul><ul><ul><ul><li>Authenticate Person in Distress (Activity) </li></ul></ul></ul>SAR Capability to Operational Activity (CV-6) 10/17/11 DoD Enterprise Architecture Conference Most expensive activity
  31. 31. <ul><li>“ Fit for purpose” view to support relation of Activity to supportive Processes (one to many) </li></ul><ul><li>One Activity may support or describe many Processes </li></ul><ul><li>Each Process model supports different ways of performing each Activity </li></ul>Activity to Process Map (FFP) 10/17/11 DoD Enterprise Architecture Conference
  32. 32. Activity to Process Map (FFP) 10/17/11 DoD Enterprise Architecture Conference Process Model(s) Most expensive process Purpose : Show relationships between activities and processes. Time and cost data is for illustrative purpose only and does not reflect real values. Pragmatica Innovations
  33. 33. <ul><li>Definition : Models the timing and sequencing of events that capture operational behavior of an process or function. </li></ul><ul><li>Purpose : Traces actions in a scenario or sequence of even t s </li></ul><ul><li>Data Sources : Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document </li></ul><ul><li>Analysis : </li></ul><ul><ul><li>Cost and timing of process </li></ul></ul><ul><ul><li>Process dependency on logical data and state changes </li></ul></ul><ul><li>Consumers : </li></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul><ul><ul><li>General Stakeholder </li></ul></ul>Operational (Human) Process Model (OV-6) 10/17/11 DoD Enterprise Architecture Conference
  34. 34. SAR Operational Process Model – Perform SARSAT Search (OV-6) 10/17/11 DoD Enterprise Architecture Conference 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. Process Most expensive process Gateway Human(s) represented as Pool Time and cost data is for illustrative purpose only and does not reflect real values. Supportive Data
  35. 35. <ul><li>Deploy Direction Finding Team </li></ul><ul><li>Track Signal </li></ul><ul><ul><li>Emergency beacons of varying frequencies are used by victims to aid the coast guard in finding them. </li></ul></ul><ul><li>Determine Search Area </li></ul><ul><li>If search area is small then (determined in another process) </li></ul><ul><ul><li>Search small area ($25,000, 10 hours) </li></ul></ul><ul><li>If search area is large then (determined in another process) </li></ul><ul><ul><li>Search large area ($100,000, 54 hours) </li></ul></ul><ul><li>Search for Distressed Victims </li></ul><ul><li>Is Person in Distress Located? </li></ul><ul><ul><li>Person in Distress is located </li></ul></ul><ul><ul><li>Person in Distress is not located </li></ul></ul>SAR Operational Process Model - Perform SARSAT Search (OV-6) 10/17/11 DoD Enterprise Architecture Conference
  36. 36. <ul><li>Analysis revealed that “problem” was not in operational (human) process but possibly a system or system process problem </li></ul><ul><li>Had to move “through” the architecture to understand source of problem </li></ul><ul><ul><li>Large area resulted from Determine Search Area Process </li></ul></ul><ul><ul><li>Based on ability to track signal </li></ul></ul><ul><ul><li>Type of signal was based on type of satellite </li></ul></ul><ul><ul><li>Analysis performed on systems related to costs </li></ul></ul>Enterprise Architecture Analysis 10/17/11 DoD Enterprise Architecture Conference
  37. 37. <ul><li>Definition : Defines system scenario from a logical level with system and system process interaction </li></ul><ul><li>Data Sources : Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactics, Techniques and Procedures, Operational Requirement Documents </li></ul><ul><li>Purpose : Provide system process interaction </li></ul><ul><li>Analysis : System process cost and time analysis. Resource impact analysis. System Behavioral analysis. Identification of non-functional system requirements </li></ul><ul><li>Consumers : </li></ul><ul><ul><li>Enterprise Architect </li></ul></ul><ul><ul><li>Program Manager </li></ul></ul><ul><ul><li>General Stakeholder </li></ul></ul>System Process (SV-10) 10/17/11 DoD Enterprise Architecture Conference
  38. 38. SAR System Process – Monitor Distress Signal (SV-10) 10/17/11 DoD Enterprise Architecture Conference 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. Process Most complex path Data Object Gateway System(s) represented as “Lane” Time and cost data is for illustrative purpose only and does not reflect real values.
  39. 39. SAR System Process – Monitor Distress Signal (SV-10) <ul><li>Start Monitor Distress Signal </li></ul><ul><ul><li>Select Beacon? </li></ul></ul><ul><li>Transmit 121.5 MHz Signal </li></ul><ul><ul><li>LEOSAR in Range? </li></ul></ul><ul><li>Repeat 121.5 Signal </li></ul><ul><ul><li>LUT in Range? </li></ul></ul><ul><li>LUT Receive Signal </li></ul><ul><ul><li>Confirm Signal? </li></ul></ul><ul><li>LUT Transmit Signal </li></ul>
  40. 40. <ul><li>Multiple types of analyses are available to an architectural effort with two primary categories : </li></ul><ul><ul><li>Static analysis leverages model structure and attributes to derive qualitative, quantitative and functional analyses </li></ul></ul><ul><ul><li>Dynamic analysis (executable models) examine temporal, spatial, or other performance aspects of a solution through dynamic simulations </li></ul></ul><ul><li>Static analyses were performed using analysis tools through database queries for function and quantity </li></ul>Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
  41. 41. <ul><li>Quantitative analysis was performed across entire architecture to discover the process where anomaly first appears - Perform SARSAT Search </li></ul><ul><li>Looked at process from human and system side which are both tied to the same operational activity </li></ul><ul><li>Problem was revealed in system view analysis - specifically radio beacons (121.5 and 406 MHz) </li></ul>Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
  42. 42. <ul><li>Many types of static analyses are available using architectural data </li></ul><ul><li>Two specific types were chose to best represent our SAR example problem </li></ul><ul><ul><li>Process Analysis </li></ul></ul><ul><ul><ul><li>Operational from cost & time perspective </li></ul></ul></ul><ul><ul><ul><li>System from an efficiency perspective </li></ul></ul></ul><ul><ul><li>SWOT (Strength, Weakness, Opportunity and Threat) </li></ul></ul><ul><ul><ul><li>121.5 MHz beacon (EPIRB) </li></ul></ul></ul><ul><ul><ul><li>406 MHz beacon (EPIRB) </li></ul></ul></ul>Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
  43. 43. Process Analysis (Cost and Time) 10/17/11 DoD Enterprise Architecture Conference 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 Time and cost data is for illustrative purpose only and does not reflect real values. 121.5MHz Cost 406 MHz Cost 121.5MHz Time 406 MHz Time
  44. 44. SWOT Analysis 10/17/11 DoD Enterprise Architecture Conference <ul><ul><li>Strength </li></ul></ul><ul><ul><li>Weakness </li></ul></ul><ul><ul><li>Opportunity </li></ul></ul><ul><ul><li>Threat </li></ul></ul><ul><ul><li>121.5 MHz EPIRB </li></ul></ul><ul><ul><li>Cheap to purchase </li></ul></ul><ul><ul><li>Light weight </li></ul></ul><ul><ul><li>Trusted technology </li></ul></ul><ul><ul><li>Ineffective </li></ul></ul><ul><ul><li>Reduced range </li></ul></ul><ul><ul><li>Salvage for parts </li></ul></ul><ul><ul><li>Recycle plastic </li></ul></ul><ul><ul><li>Investigate reuse? </li></ul></ul><ul><ul><li>Very expensive to search </li></ul></ul><ul><ul><li>Increased chance of not locating victim in time </li></ul></ul><ul><ul><li>406 MHz EPIRB </li></ul></ul><ul><ul><li>Instant pickup </li></ul></ul><ul><ul><li>Identifying information </li></ul></ul><ul><ul><li>More powerful signal </li></ul></ul><ul><ul><li>Transmits longer period of time </li></ul></ul><ul><ul><li>Cost more </li></ul></ul><ul><ul><li>Heavier weight </li></ul></ul><ul><ul><li>Bulkier </li></ul></ul><ul><ul><li>More lives saved </li></ul></ul><ul><ul><li>Reduced cost of searching </li></ul></ul><ul><ul><li>No migration plan </li></ul></ul><ul><ul><li>Impacts to general public if mandated for use </li></ul></ul>
  45. 45. <ul><li>Results were documented using DoDAF 2.0 artifacts and supportive data </li></ul><ul><li>Architecture structured and reflected solution for analysis </li></ul><ul><li>Architecture presented requirements for change through updates in the architecture – the “to-be” or future state </li></ul>Step 6 - Document Results In Accordance With Decision-Maker Need 10/17/11 DoD Enterprise Architecture Conference
  46. 46. <ul><li>Updated views and new views to present the way forward... </li></ul>Phase 2 of SAR Architecture Development 10/17/11 DoD Enterprise Architecture Conference
  47. 47. <ul><li>Conclusion </li></ul><ul><ul><li>121.5Mhz beacons cost more time and money to locate </li></ul></ul><ul><li>Recommendations </li></ul><ul><ul><li>Phase out older 121.5mhz beacon technology </li></ul></ul><ul><ul><li>Change & implement new system standards </li></ul></ul>Conclusion and Recommendations 10/17/11 DoD Enterprise Architecture Conference
  48. 48. 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 Complete SAR enterprise architecture is also available at http:// DoDAFinAction.com
  49. 49. Contact Information Shelton Lee Office: 703-916-7340 Mobile: 703-973-4274 [email_address] 10/17/11 Paul W. Johnson Office: 757-575-5243 Mobile: 757-270-1770 [email_address] DoD Enterprise Architecture Conference
  50. 50. Backup Slides <ul><li>Following slides are backup and supporting information </li></ul>
  51. 51. Quality Assurance <ul><li>Architecture completeness - existing views compared to projected views in AV-1, object counts, </li></ul><ul><li>Architecture validation – diagram counts and information compared to compliances such as JCIDS </li></ul><ul><li>Object completeness – completeness of data attribute information </li></ul><ul><li>Object connectedness – relationships between objects, count, average, lack of relationships </li></ul><ul><li>Object correctness – validation of information vs sources, reference source tracking </li></ul>

×