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.
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.
3.
4.
5.
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.
8.
9.
10.
11.
12.
13. SAR High Level Operational Concept Graphic (OV-1) 10/17/11 DoD Enterprise Architecture Conference
14.
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.
17.
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.
21.
22.
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.
25.
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.
28.
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.
31.
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.
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.
36.
37.
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.
40.
41.
42.
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.
45.
46.
47.
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.
51.
Editor's Notes
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