DOD EA conference DoDAF in Action

DoDAF 2.0In ActionIn Action

Search and Rescue (SAR) Example User Experience and Analysis

Presented by Shelton Lee

Paul Johnson11 April 2011

• 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

04/09/23 2DoD Enterprise Architecture Conference

• 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


• 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?


Complete 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 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


Other roles are typically necessary to complete a fully integrated enterprise architecture but will not be addressed for demonstration

SAR Scenario Trigger – Problem Statement


Rescuing the Coast Guard From Chronically Low BudgetJuly 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.

• 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


1. Determine Intended Use of architecture

2. Determine Scope of architecture

3. Determine Data Required to support architecture development

4. Collect, Organize, Correlate, & Store architectural data

5. Conduct Analyses in support of architecture objectives

6. Document Results in accordance with decision-maker needs

DoDAF Six-Step Development Process


• 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


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…

Mark 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)


Architecture 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.

• 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


• Phase 1 of EA development will provide enough “depth” to discover possible vulnerabilities that require future optimization

Mark Mellblom

Drop reference to method.No Flaws....vulnerabilties.

• 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)


Mark 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)


• 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)


Step 3 - Determine Data Required to Support Architecture Development


Reason Data Required

Understand high level context for scope Capabilities and Functions of Scope

Knowledge of how “search” capabilities are conducted by human functions

Human Processes and Rules regarding “search” specific functions

Provide static source to pinpoint high cost functional area(s) of human and system process

Data for cost and time of both acting together

Understand high level system functions and how they support process and rule

Systems and their designed System Functions

Knowledge of how “search” is conducted by systems and their system functions

“Search” specific System Processes and Rules

• 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


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

• 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)


SAR Overview and Summary Information (AV-1)


SAR Overview and Summary Information Graphical Example


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.

• 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)


• 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


• Data was stored in a repository that supports robust storage and analytical capabilities

• Data 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 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)


SAR Capability Vision (CV-1)


Capability

Goal

Guidance

Vision

Purpose: Understand relationships between SAR vision , goals and supportive capability

Focus for “thread”

• 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)


Focus for “thread”

• Definition: Hierarchy of capabilities decomposed down to leaf level to categorize activities


• 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)


SAR Capability Taxonomy(CV-2)


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.

• 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)


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.

Mark 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 activities

• Provides categorization and organization of activities


• Analysis: What activities support which capabilities

• Consumers:• Enterprise Architect• Program Manager

Capability To Operational Activity (CV-6)


Mark 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)


Most expensive activity

Capability

Purpose: Express leaf level capabilities and their supporting operational activities.

Leaf –level Capability relates to Operational Activity


• 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)


Most expensive activity

• “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)


Activity to Process Map (FFP)


ProcessModel(s)

Most expensive process

Purpose: Show relationships between activities and processes.


Pragmatica Innovations

Mark 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 events• Data Sources: Subject Matter Expert (SME) Interview, Concept of

Operations (CONOPs), Tactic, Technique and Procedure, Operational Requirement Document

• Analysis:• Cost and timing of process

• Process dependency on logical data and state changes

• Consumers:• Enterprise Architect

• Program Manager

• General Stakeholder

Operational (Human) Process Model (OV-6)


SAR Operational Process Model – Perform SARSAT Search (OV-6)


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


Supportive Data

• 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)


• 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


Mark 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 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)


SAR System Process – Monitor Distress Signal (SV-10)


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”


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

• 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


• 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)



• 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)



Process Analysis(Cost and Time)


121.5 MHz beacon search costs $103,000 and takes 55 hours to locate versus $28,500 and 11 hours to locate when using 406 MHz version


121.5MHzCost

406 MHzCost

121.5MHzTime

406 MHzTime

Mark Mellblom

CHANGE TO BEACON SEARCH

SWOT Analysis


Strength Weakness Opportunity Threat

121.5 MHz EPIRB

•Cheap to purchase•Light weight•Trusted technology

•Ineffective •Reduced range

•Salvage for parts•Recycle plastic•Investigate reuse?

•Very expensive to search•Increased chance of not locating victim in time

406 MHz EPIRB

•Instant pickup •Identifying information•More powerful signal•Transmits longer period of time

•Cost more•Heavier weight•Bulkier

•More lives saved•Reduced cost of searching

•No migration plan•Impacts to general public if mandated for use

• 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


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

Phase 2 of SAR Architecture Development


• 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


48

“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

Questions?

Contact Information

Shelton LeeOffice: 703-916-7340Mobile: 703-973-4274

[email protected]

04/09/23 49

Paul W. JohnsonOffice: 757-575-5243

Mobile: [email protected]

DoD Enterprise Architecture Conference

Backup Slides

• Following slides are backup and supporting information

Quality Assurance

• Architecture completeness - existing views compared to projected views in AV-1, object counts,

• Architecture validation – diagram counts and information compared to compliances such as JCIDS

• Object completeness – completeness of data attribute information

• Object connectedness – relationships between objects, count, average, lack of relationships

• Object correctness – validation of information vs sources, reference source tracking

DOD EA conference DoDAF in Action

Health & Medicine

Transcript of DOD EA conference DoDAF in Action