dod ea conf sar dodaf in action

DoDAF 2.0In Action Search and Rescue (SAR) Example User Experience and AnalysisPresented by Shelton LeePaul Johnson11 April 2011

DoD Enterprise Architecture Conference

Search and Rescue (SAR) Example OverviewWhy SAR as an Example? SAR Scenario PerspectiveSAR Scenario TriggerDoDAF Development ProcessSAR AnalysisConclusion and RecommendationsContents**DoD Enterprise Architecture Conference


DoDAF architecture example using a functional thread of Search and Rescue (SAR) conceptProvides an architectural example of DoDAF 2.0 in Action using a real world constructShows how architectural analysis can answer SAR Program Management questionsLimited to United States Coast Guard SARFocused on search aspect of SAR onlyDefined using current (as-is) capabilitiesData used throughout for illustrative purpose onlySearch and Rescue (SAR) Example Overview**DoD Enterprise Architecture Conference


Publicly and freely available information to support detailed architectureUniversally understood concept performed and supported worldwideEnough information to support all relevant DoDAF 2.0 viewsConcept contains real world problems that can be solved with architecture

Why SAR as an Example? **DoD Enterprise Architecture ConferenceComplete example uses most of the DoDAF 2.0 views to describe SAR demonstration only shows one small thread


SAR scenario will be accomplished through several roles in context of Program ManagementTwo 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**DoD Enterprise Architecture ConferenceOther roles are typically necessary to complete a fully integrated enterprise architecture but will not be addressed for demonstration


SAR Scenario Trigger Problem Statement**DoD Enterprise Architecture ConferenceRescuing the Coast Guard From Chronically Low BudgetJuly 2010 By Stew Magnuson National Defense Magazine articleEveryone loves the Coast Guard, but that affection hasnt translated into a budget that can sustain its ships, aircraft and personnel The service (USCG) saw its proposed 2011 budget cut by 3 percent.


Problem statement triggered conversation between PM and EA teamsEnterprise architecture team recommended using latest version of framework - DoDAF 2.0DoDAF six-step process recommended as best practice by enterprise architecture teamCollaborative efforts were undertaken between:Program Management TeamEnterprise Architecture TeamOperational TeamSystem and Engineering Team

SAR Scenario**DoD Enterprise Architecture Conference


Determine Intended Use of architectureDetermine Scope of architectureDetermine Data Required to support architecture developmentCollect, Organize, Correlate, & Store architectural dataConduct Analyses in support of architecture objectivesDocument Results in accordance with decision-maker needsDoDAF Six-Step Development Process**DoD Enterprise Architecture Conference


Find ways we can reduce cost to meet new budget restrictions using enterprise architecture dataUse analysis methods for time and costExamine data and dependencies of searchWhat is highest value that could be gained for this effort?Build search architecture outwardsEstablish foundation for future optimization

Step 1 - Determine Intended Use of Architecture**DoD Enterprise Architecture ConferenceOur 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

DoD Enterprise Architecture ConferenceMark Mellblom - Emphasize data in the EA.

Reasons too vague. (Cost) Drivers and (EA relationship) Dependencies.

Excerpt from Overview and Summary Information (AV-1)

Purpose Excerpt from Overview and Summary Information (AV-1)**DoD Enterprise Architecture Conference


Limit to Coast Guard specific SARFocus on search aspect of SAR through capability and functional analysisDefine AS-IS (current only) capabilitiesIdentify and focus on elements that have a high cost (time and money)Step 2 - Determine Scope of Architecture**DoD Enterprise Architecture ConferencePhase 1 of EA development will provide enough depth to discover possible vulnerabilities that require future optimization

DoD Enterprise Architecture ConferenceMark Mellblom - Drop reference to method.

No Flaws....vulnerabilties.

Definition: Scenario from a conceptual level. Main operational concepts System and operational (human) interactionData Sources: Mission Statement, Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement DocumentPurpose: 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 reliabilityConsumers:Executive Level StakeholderEnterprise ArchitectProgram ManagerGeneral StakeholderHigh Level Operational Concept Graphic (OV-1)**DoD Enterprise Architecture Conference

DoD Enterprise Architecture ConferenceMark Mellblom - Talk to the OV-1 as the visual statement of scope and complexity as a high order abstract. Can we visually examine the denisty of the graphic and infer multiple orchestrated flows?

SAR High Level Operational Concept Graphic (OV-1)**DoD Enterprise Architecture Conference


Disaster occurs (person is in distress)Emergency beacon is activatedSignal is picked up by other ships and satellitesSignal received by Mission Control CenterSearch team analyzes signal for locationRescue Coordination Center dispatches search and rescue teamDebrief and lessons learned

High Level Operational Concept Graphic (OV-1)**DoD Enterprise Architecture Conference


Step 3 - Determine Data Required to Support Architecture Development**DoD Enterprise Architecture Conference

ReasonData RequiredUnderstand high level context for scopeCapabilities and Functions of ScopeKnowledge of how search capabilities are conducted by human functionsHuman Processes and Rules regarding search specific functionsProvide static source to pinpoint high cost functional area(s) of human and system processData for cost and time of both acting togetherUnderstand high level system functions and how they support process and ruleSystems and their designed System FunctionsKnowledge of how search is conducted by systems and their system functionsSearch specific System Processes and Rules


Operational (Human) Process (OV-6)Human Processes, Rules and DataSystem Process (SV-10)System Processes, Rules and Data

Step 3 - Determine Artifacts Required to Support Architecture Development**DoD Enterprise Architecture ConferenceA number of other supportive views were created to understand and define the entire SAR program only ones relevant to the demonstration thread are listedOverview and Summary Information (AV-1)Scope, Goals and PurposeCapability Vision (CV-1)Goals, Purpose, and Capability dependenciesCapability to Activity Map (CV-6)Capability and Functions of Scope

Capability Taxonomy (CV-2)Capability Dependencies


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 demonstrateDefines types of analyses and who is expected to perform analysesRelates decisions expected to be made on basis of an analysis and resultant actionsData Sources: Policy Document, Subject Matter Expert (SME) Interview, Concepts of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement DocumentAnalysis: Determine level of effort required to produce product set to answer architectural questionsConsumers:Executive Level StakeholderEnterprise ArchitectProgram ManagerGeneral StakeholderOverview and Summary Information (AV-1)**DoD Enterprise Architecture Conference


SAR Overview and Summary Information (AV-1)**DoD Enterprise Architecture Conference


SAR Overview and Summary Information Graphical Example**DoD Enterprise Architecture ConferenceOverviewGoalVisionViewArchitecture Development PhasePurpose: 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.


ScenarioThe 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.PurposeThe 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. DescriptionThis release and subsequent releases will describe USCG Search and Rescue (SAR) mission with enough details to optimize performance and reduce costs for SAR.OverviewThis 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)**DoD Enterprise Architecture Conference


Data was collected using tools that can capture all data to support DoDAF 2.0 viewsWorked with operational and system team to gather information to create views

Step 4 - Collect, Organize, Correlate, and Store Architectural Data**DoD Enterprise Architecture ConferenceData was stored in a repository that supports robust storage and analytical capabilitiesData was collected through screen entry and import


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 DocumentPurpose: Provide strategic context for capabilities described in Architectural Description and communicates strategic vision regarding capability structureAnalysis: Vision to goals with supportive capabilityConsumers:Decision makerEnterprise Architect

Capability Vision (CV-1)**DoD Enterprise Architecture Conference


SAR Capability Vision (CV-1)**DoD Enterprise Architecture ConferenceCapabilityGoalGuidanceVisionPurpose: Understand relationships between SAR vision , goals and supportive capabilityFocus for thread


Vision: Save lives, defend our borders, and protect the environmentMission: Reduce operating costs to meet budget cutsGoal: Increase personnel recovery effectiveness and efficiencyCapabilityManage SAR SupportOperate SAR MissionCoordinate SAR Operations

SAR Capability Vision (CV-1)**DoD Enterprise Architecture ConferenceFocus for thread


Definition: Hierarchy of capabilities decomposed down to leaf level to categorize activitiesData Sources: Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement DocumentPurpose: Identify and organize capabilities through logical decomposition to support planning and gap analysisAnalysis: Which capabilities support & relate to each otherConsumers:Enterprise ArchitectProgram Manager

Capability Taxonomy (CV-2)**DoD Enterprise Architecture Conference


SAR Capability Taxonomy(CV-2)**DoD Enterprise Architecture ConferencePurpose: 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 DistressCapabilityLeaf CapabilityTime and cost data is for illustrative purpose only and does not reflect real values.


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)**DoD Enterprise Architecture ConferenceHighest 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.

DoD Enterprise Architecture ConferenceMark Mellblom - A little more descriptive and I added a PURPOSE block for the purpose of a hierarchy is the semantic structure.

Definition: Captures capabilities required and activities that enable those capabilities.Purpose: Shows leaf level capabilities.Aligns leaf level capabilities with supporting activitiesProvides categorization and organization of activitiesData Sources: Policy Document, Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique & Procedure, Operational Requirement DocumentAnalysis: What activities support which capabilitiesConsumers:Enterprise ArchitectProgram Manager

Capability To Operational Activity (CV-6)**DoD Enterprise Architecture Conference

DoD Enterprise Architecture ConferenceMark Mellblom - I did not go to the spec to update the fields. only updated the purpose field with my thoughts on structure

SAR Capability to Operational Activity (CV-6)**DoD Enterprise Architecture ConferenceMost expensive activityCapabilityPurpose: Express leaf level capabilities and their supporting operational activities.Leaf level Capability relates to Operational ActivityTime and cost data is for illustrative purpose only and does not reflect real values.


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)**DoD Enterprise Architecture ConferenceMost expensive activity


Fit for purpose view to support relation of Activity to supportive Processes (one to many)One Activity may support or describe many ProcessesEach Process model supports different ways of performing each Activity

Activity to Process Map (FFP)**DoD Enterprise Architecture Conference


Activity to Process Map (FFP)**DoD Enterprise Architecture ConferenceProcessModel(s)Most expensive processPurpose: Show relationships between activities and processes.Time and cost data is for illustrative purpose only and does not reflect real values.Pragmatica Innovations

DoD Enterprise Architecture ConferenceMark Mellblom - This needs to be an activity to process DIAGRAM NAME FFP view.

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 eventsData Sources: Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement DocumentAnalysis:Cost and timing of processProcess dependency on logical data and state changesConsumers:Enterprise ArchitectProgram ManagerGeneral Stakeholder

Operational (Human) Process Model (OV-6)**DoD Enterprise Architecture Conference


SAR Operational Process Model Perform SARSAT Search (OV-6)**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.ProcessMost expensive processGatewayHuman(s) represented as PoolTime and cost data is for illustrative purpose only and does not reflect real values.Supportive Data


Deploy Direction Finding TeamTrack SignalEmergency beacons of varying frequencies are used by victims to aid the coast guard in finding them. Determine Search AreaIf 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 VictimsIs Person in Distress Located?Person in Distress is locatedPerson in Distress is not located

SAR Operational Process Model - Perform SARSAT Search (OV-6)**DoD Enterprise Architecture Conference


Analysis revealed that problem was not in operational (human) process but possibly a system or system process problemHad to move through the architecture to understand source of problemLarge area resulted from Determine Search Area ProcessBased on ability to track signalType of signal was based on type of satelliteAnalysis performed on systems related to costsEnterprise Architecture Analysis**DoD Enterprise Architecture Conference

DoD Enterprise Architecture ConferenceMark Mellblom - Walking the dog backward...to the beacon. Emphasize it was expensive, but a cumulative cost analysis will reveal on the next few sides that the systems contribute to the cost (in time, which is $ once active in a search) by the delay in getting a valid signal to begin the SARSAT search.

Definition: Defines system scenario from a logical level with system and system process interactionData Sources: Subject Matter Expert (SME) Interview, Concept of Operations (CONOPs), Tactics, Techniques and Procedures, Operational Requirement DocumentsPurpose: Provide system process interactionAnalysis: System process cost and time analysis. Resource impact analysis. System Behavioral analysis. Identification of non-functional system requirementsConsumers:Enterprise ArchitectProgram ManagerGeneral StakeholderSystem Process (SV-10)**DoD Enterprise Architecture Conference


SAR System Process Monitor Distress Signal (SV-10)**DoD Enterprise Architecture ConferenceLooking at systems involved in this process we can see that the system (EPIRB) seems to be the root cause specifically the 121 MHz beacon. ProcessMost complex pathData ObjectGatewaySystem(s) represented as LaneTime and cost data is for illustrative purpose only and does not reflect real values.


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 SignalLUT in Range?LUT Receive SignalConfirm Signal?LUT Transmit Signal


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 analysesDynamic analysis (executable models) examine temporal, spatial, or other performance aspects of a solution through dynamic simulationsStatic analyses were performed using analysis tools through database queries for function and quantity

Step 5 Conduct Analysis in Support of Architecture Objective**DoD Enterprise Architecture Conference


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


Many types of static analyses are available using architectural dataTwo specific types were chose to best represent our SAR example problem Process AnalysisOperational from cost & time perspectiveSystem from an efficiency perspectiveSWOT (Strength, Weakness, Opportunity and Threat)121.5 MHz beacon (EPIRB)406 MHz beacon (EPIRB)

Step 5 Conduct Analysis in Support of Architecture Objective**DoD Enterprise Architecture Conference


Process Analysis(Cost and Time)**DoD Enterprise Architecture Conference121.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 versionTime and cost data is for illustrative purpose only and does not reflect real values.121.5MHzCost406 MHzCost121.5MHzTime406 MHzTime

DoD Enterprise Architecture ConferenceMark Mellblom - CHANGE TO BEACON SEARCH

SWOT Analysis**DoD Enterprise Architecture Conference

StrengthWeaknessOpportunityThreat121.5 MHz EPIRBCheap to purchaseLight weightTrusted technologyIneffective Reduced rangeSalvage for partsRecycle plasticInvestigate reuse?Very expensive to searchIncreased chance of not locating victim in time

406 MHz EPIRBInstant pickup Identifying informationMore powerful signalTransmits longer period of timeCost moreHeavier weightBulkierMore lives savedReduced cost of searchingNo migration planImpacts to general public if mandated for use


Results were documented using DoDAF 2.0 artifacts and supportive dataArchitecture structured and reflected solution for analysisArchitecture 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**DoD Enterprise Architecture Conference


Updated views and new views to present the way forward...

Phase 2 of SAR Architecture Development**DoD Enterprise Architecture Conference


Conclusion 121.5Mhz beacons cost more time and money to locateRecommendationsPhase out older 121.5mhz beacon technologyChange & implement new system standardsConclusion and Recommendations**DoD Enterprise Architecture Conference


*DoDAF in Action booth is at T5 for complete details of SAR ExampleDoD booth is at T1 for details or DoDAF general questionsDoD booth is at T4 for government representativeComplete SAR enterprise architecture is also available at http://DoDAFinAction.comQuestions?


Contact Information

Shelton LeeOffice: 703-916-7340Mobile: [email protected]

**

Paul W. JohnsonOffice: 757-575-5243Mobile: [email protected]



Backup SlidesFollowing slides are backup and supporting information


Quality AssuranceArchitecture completeness - existing views compared to projected views in AV-1, object counts,Architecture validation diagram counts and information compared to compliances such as JCIDSObject completeness completeness of data attribute informationObject connectedness relationships between objects, count, average, lack of relationshipsObject correctness validation of information vs sources, reference source tracking


Introduction Shelton and Paul**Shelton**SheltonIntent 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.

**SheltonTalk through why we chose SARDoD supported through USCG and USAF with supportive USN and USMC rolesExample of all DoDAF version 2.0 views and how they relate and support each other to describe a total enterprise architectureSeveral 'fit for purpose' views will also be developed to fully articulate vision of DOD SAR**SheltonHow we are going to tell the storyThrough various roles SAR PM and EA Knitting it all together with architecture views and supportive dataShelton will play the role of the PMPaul will play the role of the enterprise architect **SheltonHow can we achieve our goals of saving lives while responding to budget cuts? Show me the scope and possible analysis needed**Shelton transition to Paul

Given our problem statement, lets talk through artifacts required to support

**Paul to PMIn keeping with DoDAF architecture best practice we recommend as six step process for developmentI need you and your teams assistance in the first several steps to ensure success of the project

**PaulWe need to determine the primary intent of the EA effort Shelton We have a budget crisis and need to look at ways to reduce costsPaulWhere 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 areaSo 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**Paul**PaulAnalyze 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 unfeasibleShelton questions?**Paul**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

**Paul**PaulData to support level of detail for each artifact/entityScope, 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 InformationSystem level information (SV-1, SV-2, SV-4, SV-5, DIV-1, DIV-2)System Processes (SV-10c)Rough cost of processes **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 goalsCV-2 - hierarchy which specifies all capabilities that are referenced throughout one or more Architectural DescriptionsCV-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**Paul **Paul**PaulHere is a graphical view of the AV-1 that shows the architecture effort by architecture phaseYou can use this as a quick reference guide when explaining what we are doing to others

**PaulActual Av-1 is online as document, graphical, textual freeform input**PaulCollection of data through a tool that supports at a minimum the DoDAF 2.0 metamodelData stored in a tool that has robust storage and business intelligence capabilitiesTools used should support DM2 PES import and export for data reuse and sharing amongst various architectural efforts

**PaulNecessary to know what capabilities may be effected by goals so that further analysis can be done to see if any critical pieces are effected

**Paul****PaulFirst level of entities that expose the overall capabilities of SARGraphical view of all capabilities to look for high cost or inefficiencies

**PaulOther Capabilities were decomposed to process level but we will not be focusing on those during this presentation

**Pauldecomposes capabilities into unique operations at a leaf levelEach of these level functions can now be analyzed in a context level process model

**PaulPart of a bigger diagram - excerptShows 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 hierachyActivities form the work hierarchy and Process form the solution hierarchy where it really gets done.

**Paul**PaulFit for purpose views enable us as architects to communicate information relevant to illustrate a point

**PaulFit for purpose views enable us as architects to communicate information relevant to illustrate a point

**PaulProcess diagrams enable architects to understand the many nuances of operational activitiesSpecific metrics can be captured to analyze processes that may be problem sources**Paul**Paulwanted to know exactly what was determining the difference in search area size

**PaulWalking 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**Paul**Pauldeep dive on system side into the various types of emergency beacon technology and monitoring technology. older beacon technology could be root cause of issue**PaulWalk thru SV-10 happy path for 121 MHZ beacon*PaulConduct Analyses in Support of Architecture ObjectivesArchitecture validationMay help determine future architectural effortsRepeat steps 3-5 as necessary

**Paul**Paulmany overarching types of higher level analysis that can be performed using architecture chose several in order to best understand problem

**Paullooked at cost and time differences using analysis from data collected in process modelsArchitect finds anomaly in search time where one process appears less efficientSearch area is reduced when using 400 MHz EPIRB (Radio Beacon)Architectural analysis reveals cost and timeFurther analysis reveals that lower frequency EPIRB requires more search timeUpdates through LEO vs geostationary satellites also requires additional time**PaulCreation of presentations for decision makersDocumentation of results and lessons learned in AV-1

Supportive data, reports, and drawings were provided to decision makers

**Paul recommend phase 2 of architecture development center on details of modifying new solution

**Paul handoff to Shelton**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

*

dod ea conf sar dodaf in action

Documents

sar demonstration

architecturewhy sar

architectural example

rescue sar conceptprovides

relevant dodaf

engineering teamsar

action search

available information