1. DODAF 2.0 In Action User Experience and Analysis
February 14, 2011
We will be showing you a scenario of how architecture can be used to solve a particular problem. For this scenario we chose the Coast Guard Search and Rescue operations. We used DODAF 2.0 to collect data and various tools to perform analysis to show how an architecture can support real world analytics.

2. Contents The Six Step Process DODAF 2.0 example architecture Scenario
Coast Guard Search and Rescue Architecture
Follows the Six Step Process
Shows use of DODAF 2.0 to solve real world problems
Real Data
Powerful analysis

3. The Six Step Process Recommended process for architecture development
Steps 1-3 and 6 recorded in an architecture’s DODAF All View 1 (AV-1)

4. Put all steps here

5. 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
SAR EA: 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

6. Types of Analysis Trade off Analysis
Duplicative Functionality Analysis
SWOT Analysis
There are many overarching types of higher level analysis that can be performed using architecture but we won’t know which ones we need until we look at the problem further.
Reuse Opportunities
Sensitivity Analysis
Interoperability Challenges
Lean Six Sigma

7. Types of analysis bullets
Explanation of why each type was selected

8. AV-1 Supports capturing of data for Steps 1-3 and Step 6
Project Information
Project Management
Architecture development timeline/criticality
Review cycles
Current state
Can be created using tools such as Microsoft Word or a proper EA tool.
Can be used to assist searching in an architecture registry such as DARS
What we plan to do
What we are doing
What we have done

9. SAR Enterprise Architecture AV-1

10. AV-1 Graphical Representation Example
SAR EA: Here is a graphical view of the AV-1 that shows the architecture effort by architecture phase
SAR PM: I can use this as a quick reference guide when explaining what we are doing to others
SAR PM: I like what you’ve shown me.

11. Search and Rescue (SAR) Scenario
Discover the value of architecture through a real world scenario
See how architectural analysis can answer Program Manager level questions with ease
Follow the development of an architecture using the Six Step Process

12. Scenario Contents Overview Perspective Problem Statement
Scope and Purpose
Data collection through DODAF 2.0 views
Analysis

13. SAR Overview Why Search and Rescue? (SAR)
Publicly and freely available information to support detailed architecture
Enough information to support all 52 views of DODAF 2.0
Real world problems that can be solved with architecture
Talk through SAR and why we chose SAR
Publicly and freely available information to support detailed architecture
DoD supported through USCG and USAF with supportive USN and USMC roles.
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.
Several 'fit for purpose' views will also be developed to fully articulate the vision of DOD SAR.

14. SAR Scenario Perspective
For the Perspective of the SAR Program Manager
Roles:
SAR Program Manager (PM) - Shelton Lee
SAR Enterprise Architect (EA) - Paul Johnson
SAR Data Analyst (DA) - ?? Maybe only need 2 people
How we are going to tell the story…
Through various roles – SAR PM, EA and DA
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
Carson will play the role of the data analyst

15. The service saw its proposed 2011 budget cut by 3 percent.
Problem
The service saw its proposed 2011 budget cut by 3 percent.
“Everyone loves the Coast Guard, but that affection hasn’t translated into a budget that can sustain its ships, aircraft and personnel”
SAR PM to SAR EA: How can we achieve our goals of saving lives while responding to budget cuts?
SAR PM to SAR EA: Show me the scope and possible analysis needed
Rescuing the Coast Guard From Chronically Low Budget
July 2010 
By Stew Magnuson 
National Defense Magazine article

16. Step 1 Determine Intended Use of Architecture (Phase 1)
Find ways we can reduce cost to meet new budget restrictions
Using DODAF 2.0
There may be phasing in or out of systems or modifications to processes that impact the general public
Step 1: Determine Intended Use of Architecture
Methods
Types of Data Needed
Potential Impacts on others
How is success measured?

17. Step 2 Determine Scope of Architecture (Phase 1) At sea rescue
AS-IS capabilities
Only Coast Guard SAR
Looking at costs of processes for Search and Rescue Missions
Distress signal is received until the victim is either recovered and treated medically until stable or the search is determined to be unfeasible
Step 2: Determine Scope of Architecture
Depth and Breadth
Views needed
Context
As-is or to-be?
from when a distress signal is received until the victim is either recovered and treated medically until stable or the search is determined to be unfeasible
Scope, Purpose, and Questions to Answer (AV-1)
Vision and Goals (CV-1)
Current Capabilities (CV-2)
Capabilities to Functions (CV-6)
Human Business Process (OV-6c)
System Business Process (SV-10c)
Other supporting views (SV-1, SV-2, SV-4, SV-5, DIV-1, DIV-2)

18. Step 3 Determine Data Required to Support Architecture Development
Data Needed
View
Add date to table
Level of detail for each artifact/entity
Maybe a table with data you need, with one side being data you need and the other being views
Concepts from step 1-2 for data you need to the views you need
Scope, Purpose, and Questions to Answer (AV-1)
Vision and Goals (CV-1)
Operational level information (CV-2, CV-6)
Human Business 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

19. Narrowing in on the Process
CV-1 -> CV-2 -> CV-6 -> OV5a -> OV5b -> OV6abc (BPMN)
SV-1->SV-2->SV-4->SV6->DIV-1->DIV-2->SV10abc(BPMN)

20. Step 4
Step 4: Collect, Organize, Correlate, and Store Architectural Data.
Data was collected using tools that can capture all DODAF 2.0 views and data
Data is stored in a repository that supports robust storage and business intelligence capabilities
Repository supports DM2 PES import and export for data reuse and federation with other tools, environments, or repositories
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

21. OV-1: High Level Operational Concept Graphic
Describes a scenario from a conceptual level.
Main operational concepts
System Interaction
Human Interaction
Provides a tool for discussion and presentation

22. OV-1 Overview A disaster happens such as a ship sinking
An emergency beacon is activated
The signal is picked up by other ships or satellites
The signal is sent to a Mission Control Center
The Rescue Coordination Center dispatches a search and rescue team

23. SAR OV-1 As Is
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

24. SAR Enterprise Architecture CV-1
Overall vision for transformational endeavors, which provides a strategic context for the capabilities described and a high-level scope.
Data comes from : Mission Statement, Company Homepage / About Page, or a CONOPS
Analysis :You can analyze which capabilities you need to build or improve or even which ones are not necessary to meet your future business goals.
Who uses it :
Decision makers
Architects
SAR EA: Necessary to know what capabilities may be effected by the goals so that further analysis can be done to see if any critical pieces are effected
Fix

25. SAR Enterprise Architecture CV-1
Vision
Mission
Goal
SAR EA: I used this to focus deep dive architecture efforts down to BPMN level
Capability

26. SAR Enterprise Architecture CV-2
Hierarchy of capabilities decomposed down to leaf level to expose activities
Data comes from: Manuals, plans, web sites, CONOPS, etc
Purpose: Capture and organize the capabilities
Analysis:
Which capabilities support each other.
Who uses it:
Architects
SAR EA: This is the first level of deep dive information collection that I mentioned. I used this to get a general idea of all capabilities to look for redundancy at a high level.

27. SAR Enterprise Architecture CV-2
Capability
Focus for Scenario
Other data created
Focus was on
Locate Personnel
Perform Visual Search
Other Capabilities were decomposed to the process level but we will not be focusing on those during this presentation

28. CV-6 Capability To Operational Activity
Description: Captures capabilities required and the activities that enable those capabilities.
Purpose: Decomposes down to the process level. Provides organization of activities.
Data comes from: Manuals, plans, web sites, CONOPS, etc
Analysis
Which activities support which capabilities
Who uses it
Architects
SAR EA: We needed to break down the architecture to one more level before we can get to the BPMN level. Specifics on capabilities

29. SAR Enterprise Architecture CV-6
Maybe start here
Change color of focus area on diagram then show excerpt
Operational Activity
Focus for Scenario
Other data created
Capability

31. SAR Enterprise Architecture OV-6c
Description: Event-Trace Description
Purpose: Traces actions in a scenario or sequence of events.
Data comes from: Manuals, plans, web sites, CONOPS, etc
Analysis:
Cost of processes, timing of processes, aggregate up to activity based costing (ABM)
Process dependency on data from systems
Which business rules effect which processes
Who uses it:
Architects
SAR EA: After that we mapped out at the process level what exactly is going on to support each capability. We collected specific metrics such as cost and time required for each process. This allowed us to find bottlenecks.

32. List of Processes Analyze Distress Signal Locate Victim
Decide How to Inform Family
Inform Family of Situation
Finalize Case Documentation
Suspend Case
Conclude Mission
Add time and money in table here

33. OV-6c Textual Walkthrough
Deploy Direction Finding Team
Track Signal
Determine Search Area
If search area is small then (determined in another process)
Search small area
If search area is large then (determined in another process)
Search large area
Search for Distressed Victims
Is Victim Located?
Victim is located
Victim is not located
SAR EA: We wanted to know exactly what was determining the difference in search area size so we did a deep dive on the system side into the various types of emergency beacon technology and monitoring technology. It was found that an older beacon technology could be the root cause of the issue that’s when we asked why does this system even exist? Let’s look at the SV-10.

34. SAR Enterprise Architecture OV-6c Locate Victim
Supportive Data
Go into tool here
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.
Investigate what is causing this bottleneck.

35. SAR Enterprise Architecture SV-10c
Description:
Purpose
Data comes from: Manuals, plans, web sites, CONOPS, etc
Analysis:
Who uses it:

36. SAR Enterprise Architecture SV-10c
Looking at the systems involved in this process we can see that the system technology seems to be the root cause of the issue.

37. SV-10c Textual Walkthrough
Deploy Direction Finding Team
Track Signal
Determine Search Area
If signal is from a 406mhz beacon then
Search area is small
If signal is from a 121.5mhz beacon then
Search area is large
SAR EA: It was found that a system was at the root cause of the issue that’s when we asked why does this system even exist? Let’s look at the SV-10.

38. Step 5 Conduct Analyses in Support of Architecture Objectives
Analysis was performed on the process for Locate Victim
It was found that there are 2 scenarios that can cause a major difference in the cost of the search effort
These scenarios are the result of 2 similar systems (121.5 mhz beacons and 406mhz beacons)
Further analysis was performed to find the differences in these 2 systems
Conduct Analyses in Support of Architecture Objectives
Architecture validation
May help determine future architectural efforts
Repeat steps 3-5 as necessary

39. Trade-off Analysis
Analog (121.5 MHz) Beacons
406 MHz (Digital) Beacons
SAR response delay
SAR response to anonymous beacons can be delayed 4–6 hours, and as much as 12 hours.[15]
Resolution or response to registered beacons is very swift. SAR response can be activated within approximately 10 minutes of beacon activation (and GEOSAR detection) if distress is evident.
Unregistered beacons can usually be responded to after only 1 LEOSAR satellite pass; after two passes, response is immediate.
False alerts
Fewer than 2 in 1000 alerts and 2 in 100 composite alerts are actual distress.[16]
The Cospas-Sarsat system has no way of distinguishing between analog beacons and interference (from set top boxes, etc.)
False alerts may result in a long and fruitless search by costly SAR assets, although rescue co-ordination centres typically analyse the circumstances, considering location, movement of the source and confirmatory reports before launching an operation[citation needed]
Searches for interference signals and false alerts inhibit SAR assets from being available for real searches
All alerts (100%) come from beacons (analog interference is ignored).
Approximately 7 out of 10 false alerts are resolved by a phone or radio call, therefore,
SAR resources are not wasted
SAR assets are more available for actual distress
Persons responsible for causing false alerts can avoid having to pay fines and/or paying the costs of operating SAR assets
Follow-up to false activations allows continuous reductions in the number of false alerts
SAR EA: We decided that based on the problem we found in the BPMN we would use trade-off analysis to find out exactly how much of a difference there is between using these two systems. We looked to see if there were any advantages to using 121.5mhz beacons.
Conclusion: No major advantages to using 121.5mhz beacons

40. SWOT Chart for and 406

41. Trade-off Analysis
SAR EA: We also looked at the cost and time differences using analysis from the data collected in the BPMN.
SAR EA: After careful analysis of system functionality we determined there was no advantage to using the older 121.5mhz technology
DODAF 2.0 plug?
Conclusion: 121.5mhz beacons cost a substantial amount more time and money to search for compared to 406mhz beacons

42. Step 6
Step 6: Document Results in Accordance with Decision-Maker Needs
Conclusions and Recommendations were documented in AV-1
Supportive data, reports, and drawings were provided to decision makers
Creation of presentations for decision makers
Documentation of results and lessons learned in AV-1

43. Architect Recommendation
Phase out older 121.5mhz EPIRB technology
Standards (StdV-2) change to implement new system standards
SAR EA: I recommend we phase out the older technology and update our system standards to only support the newer technology. This will be a gradual phase out with much warning given to the public so that individuals can make the switch.

44. Detailed Solution Phase 2 of AV-1
SAR EA: I recommend we start another development phase of the architecture to detail exactly how this transition will occur
SAR PM: I agree, collecting and architecting out that information will be necessary to get system owners and commanding officers to buy in on this initiative.
To see more about this story, how we collected the data, did the analysis, etc proceed to the OSD booth at your own leisure.

45. AV-1 Recap

46. Questions?

47. Step 1 Determine Intended Use of Architecture Methods
Types of Data Needed
Potential Impacts on others
How is success measured?
Step 1: Determine Intended Use of Architecture. Defines the purpose and intended use of the architecture ("Fit-for-Purpose"); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction. This information is generally provided by the process owner to support architecture development describing some aspect of their area of responsibility (process, activity, etc.).

48. Step 2 Determine Scope of Architecture Depth and Breadth Context
Views needed
Context
As-is or to-be?
Depth and Breadth
The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture's problem set, helps define its context and defines the level of detail required for the architectural content.

49. Step 3 Determine Data Required to Support Architecture Development
Level of detail for each artifact/entity
The required level of detail to be captured for each of the data entities and attributes is determined through the analysis of the process undergoing review conducted during the scoping in Step 2. This includes the data identified as needed for execution of the process, and other data required to effect change in the current process, (e.g., administrative data required by the organization to document the Architectural Description effort). These considerations establish the type of data collected in Step 4, which relate to the architectural structure, and the depth of detail required.

50. Step 4 Collect, Organize, Correlate, and Store Architectural Data.
At a minimum, Collect data through a tool that supports 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 among various architectural efforts
Architects typically collect and organize data through the use of architecture techniques designed to use views (e.g., activity, process, organization, and data models as views) for presentation and decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool. Terms and definitions recorded are related to elements of the (DM2).

51. Step 5 Conduct Analyses in Support of Architecture Objectives
Quality Assurance
May help determine future architectural efforts
Analysis
Answers the questions captured in step 1
Repeat steps 3-5 as necessary
Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner. Changes required from the validation process, result in iteration of the architecture process (repeat steps 3 through 5 as necessary).

52. Step 6
Step 6: Document Results in Accordance with Decision-Maker Needs
Creation of presentations for decision makers
Documentation of results and lessons learned in AV-1
The final step in the architecture development process involves creation of architectural views based on queries of the underlying data. Presenting the architectural data to varied audiences requires transforming the architectural data into meaningful presentations for decision-makers. This is facilitated by the data requirements determined in Step 3, and the data collection methods employed during Step 4.

53. Backup Slides

54. Problem Scoped
Architect finds anomaly in search time where one appears less efficient
Search area is reduced when using 400 MHz EPIRB (Radio Beacon)
SAR Analyst shows amount of money, time, and lives saved
Further analysis reveals that lower frequency EPIRB requires more search time
Updated through LEO vs geostationary satellites requires additional time

55. Scenario Trigger
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, said some of the service’s former leaders.
The service saw its proposed 2011 budget cut by 3 percent. Lawrence Korb, senior fellow at the Center of American Progress, said that is going in the opposite direction of what is needed. In a new report, “Building a U.S. Coast Guard for the 21st Century,” he proposed adding $5 billion to its $10.1 billion budget.

56. SAR Enterprise Architecture
Architecture Overview as AV-1
Display textual version as PDF
Display textual version in repository
Address Scope, Context and analysis
Display graphic version

57. SAR Enterprise Architecture OV-5a
Activity Decomposition to support subset of activities that define personnel location
SAR

58. SAR Enterprise Architecture OV-5a