Your SlideShare is downloading. ×
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
DOD EA conference DoDAF in Action
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

DOD EA conference DoDAF in Action

1,226

Published on

DoDAF architecture example using a functional “thread” of Search and Rescue (SAR) concept …

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.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,226
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
68
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Introduction… Shelton and Paul 10/17/11
  • Shelton 10/17/11
  • 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. 10/17/11
  • 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 10/17/11
  • 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 10/17/11
  • Shelton How can we achieve our goals of saving lives while responding to budget cuts? Show me the scope and possible analysis needed 10/17/11
  • Shelton transition to Paul Given our problem statement, lets talk through artifacts required to support 10/17/11
  • 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 10/17/11
  • 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 Paul Where do you feel that the highest value could be gained for this effort? Shelton 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 10/17/11
  • Paul 10/17/11
  • 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? 10/17/11
  • Paul 10/17/11
  • 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 10/17/11
  • Paul 10/17/11
  • 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 10/17/11
  • 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 10/17/11
  • Paul 10/17/11
  • Paul 10/17/11
  • 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 10/17/11
  • Paul Actual Av-1 is online as document, graphical, textual freeform input 10/17/11
  • 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 10/17/11
  • 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 10/17/11
  • Paul 10/17/11
  • 10/17/11
  • Paul First level of entities that expose the overall capabilities of SAR Graphical view of all capabilities to look for high cost or inefficiencies 10/17/11
  • Paul Other Capabilities were decomposed to process level but we will not be focusing on those during this presentation 10/17/11
  • 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 10/17/11
  • 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. 10/17/11
  • Paul 10/17/11
  • Paul “ Fit for purpose” views enable us as architects to communicate information relevant to illustrate a point 10/17/11
  • Paul “ Fit for purpose” views enable us as architects to communicate information relevant to illustrate a point 10/17/11
  • 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 10/17/11
  • Paul 10/17/11
  • Paul wanted to know exactly what was determining the difference in search area size 10/17/11
  • 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 10/17/11
  • Paul 10/17/11
  • 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 10/17/11
  • Paul Walk thru SV-10 “happy path” for 121 MHZ beacon
  • Paul Conduct Analyses in Support of Architecture Objectives Architecture validation May help determine future architectural efforts Repeat steps 3-5 as necessary 10/17/11
  • Paul 10/17/11
  • Paul many overarching types of higher level analysis that can be performed using architecture chose several in order to best understand problem 10/17/11
  • 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 10/17/11
  • 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 10/17/11
  • Paul recommend phase 2 of architecture development center on details of modifying new solution… 10/17/11
  • Paul …handoff to Shelton 10/17/11
  • Shelton
  • 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
  • Transcript

    • 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.
      • 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
      Contents 10/17/11 DoD Enterprise Architecture Conference
    • 3.
      • 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
      Search and Rescue (SAR) Example Overview 10/17/11 DoD Enterprise Architecture Conference
    • 4.
      • 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
      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.
      • 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
      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. 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.
      • 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
      SAR Scenario 10/17/11 DoD Enterprise Architecture Conference
    • 8.
      • 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
      DoDAF Six-Step Development Process 10/17/11 DoD Enterprise Architecture Conference
    • 9.
      • 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
      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.
      • Excerpt from Overview and Summary Information (AV-1)
      Purpose Excerpt from Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 11.
      • 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)
      Step 2 - Determine Scope of Architecture 10/17/11 DoD Enterprise Architecture Conference
      • Phase 1 of EA development will provide enough “depth” to discover possible vulnerabilities that require future optimization
    • 12.
      • 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
      High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 13. SAR High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 14.
      • 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”
      High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
        • Operational (Human) Process (OV-6)
          • Human Processes, Rules and Data
      • System Process (SV-10)
        • System Processes, Rules and Data
      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
      • Overview and Summary Information (AV-1)
        • Scope, Goals and Purpose
      • Capability Vision (CV-1)
        • Goals, Purpose, and Capability dependencies
      • Capability to Activity Map (CV-6)
        • Capability and Functions of Scope
      • Capability Taxonomy (CV-2)
        • Capability Dependencies
    • 17.
      • 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
      Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 18. SAR Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
      • 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.
      SAR Overview and Summary Information (AV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 21.
      • 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
      Step 4 - Collect, Organize, Correlate, and Store Architectural Data 10/17/11 DoD Enterprise Architecture Conference
      • Data was stored in a repository that supports robust storage and analytical capabilities
      • Data was collected through screen entry and import
    • 22.
      • 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
      Capability Vision (CV-1) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
      • 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
      SAR Capability Vision (CV-1) 10/17/11 DoD Enterprise Architecture Conference Focus for “thread”
    • 25.
      • 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
      Capability Taxonomy (CV-2) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
          • Execute SAR (Capability)
        • Operate SAR Mission (Capability)
          • Locate Person in Distress (Capability)
          • Support Person in Distress (Capability)
          • Conduct Recovery (Capability)
      SAR Capability Taxonomy (CV-2) 10/17/11 DoD Enterprise Architecture Conference
          • Highest level Capability ( root )
          • Lower level Capability ( child/parent )
      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.
      • 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
      Capability To Operational Activity (CV-6) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
      • 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)
      SAR Capability to Operational Activity (CV-6) 10/17/11 DoD Enterprise Architecture Conference Most expensive activity
    • 31.
      • “ 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
      Activity to Process Map (FFP) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
      • 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 even t s
      • 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
      Operational (Human) Process Model (OV-6) 10/17/11 DoD Enterprise Architecture Conference
    • 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.
      • 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
      SAR Operational Process Model - Perform SARSAT Search (OV-6) 10/17/11 DoD Enterprise Architecture Conference
    • 36.
      • 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
      Enterprise Architecture Analysis 10/17/11 DoD Enterprise Architecture Conference
    • 37.
      • 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
      System Process (SV-10) 10/17/11 DoD Enterprise Architecture Conference
    • 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. SAR System Process – Monitor Distress Signal (SV-10)
      • Start Monitor Distress Signal
        • Select Beacon?
      • Transmit 121.5 MHz Signal
        • LEOSAR in Range?
      • Repeat 121.5 Signal
        • LUT in Range?
      • LUT Receive Signal
        • Confirm Signal?
      • LUT Transmit Signal
    • 40.
      • 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
      Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
    • 41.
      • 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)
      Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
    • 42.
      • 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)
      Step 5 – Conduct Analysis in Support of Architecture Objective 10/17/11 DoD Enterprise Architecture Conference
    • 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. SWOT Analysis 10/17/11 DoD Enterprise Architecture Conference
        • 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
    • 45.
      • 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
      Step 6 - Document Results In Accordance With Decision-Maker Need 10/17/11 DoD Enterprise Architecture Conference
    • 46.
      • Updated views and new views to present the way forward...
      Phase 2 of SAR Architecture Development 10/17/11 DoD Enterprise Architecture Conference
    • 47.
      • Conclusion
        • 121.5Mhz beacons cost more time and money to locate
      • Recommendations
        • Phase out older 121.5mhz beacon technology
        • Change & implement new system standards
      Conclusion and Recommendations 10/17/11 DoD Enterprise Architecture Conference
    • 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. 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. Backup Slides
      • Following slides are backup and supporting information
    • 51. 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

    ×