# Presentation: 797198

## Architectural Framework

- Applied Sciences Program
- Geosciences Interoperability Office
- Stephen Marley NASA /SCI

## What is an Architecture Framework?

- “Architecture frameworks address what it means to define and document an architecture” - _[http://www.software.org](http://www.software.org/)_
- The world has not really settled on precise definitions of architecture or architecture description as these terms relate to enterprises, systems, or software.
- Generally agree that architecture is about the structure of important things (systems or enterprises), their components, and how the components fit and work together to fulfill some purpose.

## Why do we need an Architecture Framework?

- Fundamentally, the problem is communication
- A framework provides a generic problem space and a common vocabulary within which individuals can cooperate to solve a specific problem.
- Frameworks are not necessarily comprehensive, but they can be leveraged to provide at least a starter set of the issues and concerns that must be addressed in architecture development
- If your framework does not facilitate communication of those things that are important to you - ***you have failed!***

## But What Is An Architecture Framework??

**But....there’s more to it than that!**

*But What Is An Architecture Framework??*

## Three Components of Frameworks

- Views
- Provides the mechanisms for communicating information about the relationships that are important in your architecture
- Methods
- Provides the discipline to gather and organize the data and construct the views in a way that helps insure integrity, accuracy and completeness
- Training/Experience
- Supports the application of method and use of tools

## You need all three legs for it to stand up

**Complexity**

- Training&
- Experience

- Views

- Methods

**“****When a wise man is in a hurry, he sits down first.”**
**	****	****	*****Old Chinese Proverb***

## What Are My Choices?

## Zachman Framework 

- The Zachman Framework describes a holistic model of an enterprise's information infrastructure from six perspectives
- There is no guidance on sequence, process, or implementation of the framework. The focus is on ensuring that all aspects of an enterprise are well-organized and exhibit clear relationships that will ensure a complete system regardless of the order in which they are established.

## Zachman Structure

## Federal Enterprise Architecture Framework

- An overriding goal of OMB is to improve interoperability within the United States Government by creating one FEA. The FEA integrates the separate architectures of the various Federal Agencies.
- In support of this goal, the Government needs a collaboration tool for collecting and storing common architecture information. The FEAF is the current version of that tool and allows the Federal Government to:
- Organize Federal information for the entire Federal Government
- Promote information sharing among Federal organizations
- Help Federal organizations develop their architectures
- Help Federal organizations quickly develop their IT investments processes
- Serve customer needs better, faster, and more cost-effectively
- The scope of application for the FEAF includes all organizations throughout the Federal Government and all their partners, including:
- Large, major Federal Departmental systems
- Departmental Divisions and Bureau systems
- Other Federal Agency systems
- Systems where substantial Federal investments are involved with international, State, or local Governments

## FEAF Structure

## FEAF Views and Perspectives 

**Planner**

**Owner**

**Designer**

**Builder**

**Sub-**
**Contractor**

**Data**
**Architecture**

**Applications**
**Architecture**

**People**
**(TBD)**

**Technology**
**Architecture**

**FEAF Views**

**Time**
**(TBD)**

**Motivation**
**(TBD)**

- “Modified Zachman” Structure

## DoD Architecture Framework

- The DoDAF is intended to ensure that the architecture descriptions developed by the Commands, Services, and Agencies are interrelatable between and among each organization’s operational, systems, and technical architecture views and are comparable and integratable across Joint and combined organizational boundaries.
- The framework provides rules and guidance for developing and presenting architecture descriptions.
- The products defined by the framework are the work products of architecture development, the descriptive artifacts that communicate the architecture.
- The framework provides direction on how to *describe* architectures; it does not provide guidance in how to *construct* or *implement* a specific architecture or how to *develop* and *acquire* systems or systems-of-systems.
- This framework covers the military domain and is used mainly by the DoD.

## DoDAF Structure

- Formerly known as the C4ISR EA Framework, C4ISR stands for “Command, Control,
-  Computers, Communications, Intelligence, Surveillance, and Reconnaissance”.

## The DoD Products Map to the Zachman Framework Cells

**List of Locations**
**Important to Business**

**Data**

**Function**

**Network**

**People**

**Time**

**Motivation**

**List of Things  **
**Important to Business**

**List of Processes **

**List of Organizations**
**Important to Business**

**List of Events**
**Significant to Business**

**List of Business**
**Goals/Strategies**
**End/Means=Major**
**Business Goal/CSF**

**e.g., Entity**
**Relationship**
**Diagram**

**e.g., Function Flow**
**Diagram**

**  **
**   **
**Entity=Data Entity**
**Relationship= Data**
**Relationship**

**e.g., Program**
**Funct=Language Stmts**
**Arg=Control Blocks**

**Agent=Org Unit**
**Work=Work Product**

**e.g., Business Plan**
**End=Business**
** ****Objectives**
**Means=Business**
**Strategy**

**e.g., Human Interface**
**Architecture**
**Agent=Role**
**Work=Deliverable**

**e.g., Processing**
** ****Structure**

**Time=Interrupt**
**Cycle=Machine Cycle**

**e.g., Knowledge**
**Architecture**
**End=Criterion**
**Means=Option**

**e.g., Knowledge **
**Design**
**End=Condition**
**Means=Action**

**e.g., Knowledge**
**Definition**
**End=Subcondition**
**Means=Step**

**Ent=Fields**
**Rel=Addresses**

**e.g., Data Design**

**e.g., Human/**

**Engineer**

** **

** **

**           **

**Time= Business Event**
**Cycle=Business Cycle**

**e.g., Distributed**

**Planner’s**
**View**

**Owner’s**
**View**

**Designer’s**
**View**

**Builder’s**
**View**

- System
- Interface
- Description
- (Detailed)

- System
- COMMS
- Description

- System
- Interface
- Description
- (Detailed)

**Operational**
**View**

**Technical View**

**Systems **
**View**

**(rules not explicit in Zachman)**

***DoD Architecture***
***Framework***** Products**

- System
- Functionality
- Description

- Operational
- Activity to
- Sys. Function
- Matrix

- An
- Aspect of
- Multiple
- Products

- System
- Interface
- Description
- (Detailed)

**Subcontractor’s**
**View**

- Physical
- Data
- Model

- Operational
- Event Trace
- Systems
- Event Trace

- System
- Interface
- Description
- (High
-    Level)

- Integrated
- Diction-
- ary

- Logical
- Data
- Model

- Activity
- Model
- (List)

- Activity
- Model

- Operational
- Node
- Connectivity
- Description

- Information
- Exchange
- Matrix

- Command
- Relationships
- Chart

- Activity
- Model

- Operational
- Event
- Trace

- Capability
- Maturity
- Profile

## The Open Group Architecture Framework

- TOGAF intends to provide a practical, freely available, industry standard method of designing an EA, leveraging all relevant assets in the process.
- TOGAF is sufficient for an organization to use "as-is" or to adapt as an EA development method for use with other deliverables-focused frameworks.
- It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF Architecture Development Method.

## TOGAF ADM

## Framework Summary

- Zachman - Fundamental Complete Framework. Zachman is the organizational model for an architecture.
- Views on Zachman
- FEAF - Legacy Integration & Evolution focused framework. Ideal for transitional architectures, and finding commonality across businesses.
- DoDAF - Mission Systems focused framework. Ideal for ensuring that my development will integrate with your development to achieve a mission.
- TOGAF - How-to-Framework.  The industry standard for putting an EA program in place.

## How Does This Apply to RPC?

## NASA Goals

- RPC has to support NASA Business Goals
- NASA Goal 3A- Study Earth from space to advance scientific understanding and meet societal needs.
- Applied Sciences Goals
- Goal 1: To understand Earth’s system and apply Earth-system science to improve the prediction of climate, weather, and natural hazards
- Goal 2: To enable a safer, more secure, efficient, and environmentally friendly air transportation system
- Goal 3: To create a more secure world and improve the quality of life by investing in technologies and collaborating with other agencies, industry, and academia

## RPC Problem Space

## Program Relationships

## SN/RPC/ISS Role in Achieving NASA Goals

- SN/RPC/ISS has to serve to support NASA’s business goals by:
- Providing an environment for the “proving” of NASA Science & Technology
- Observational Data
- Earth System Models
- Tools / Services (analysis, discovery, collaboration...)
- Addressing partner agencies business by:
- Facilitating better execution of existing services
- Facilitating new services
- The first capability is a technical or “mission” capability.
- The second is is a “business alignment” capability

## Framework Recommendations

- The overarching national goal is the satisfaction of Partner Agencies Business Objectives through the introduction and expansion of NASA Science & Technology.
- A key measure of success is the inclusion of SN/RPC/ISS concepts into Partner Agency EA processes.
*This requires FEAF as this is the mechanism for aligning under the FEA*
- The major internal goal is the establishment of a NASA internal environment to support the evaluation of NASA Science & Technology
*This does not require a separate framework, but will benefit from the mission-centric views of DoDAF*
***Recommendation is that interagency business alignment be achieved through FEA, whilst the definition and implementation of the RPC component uses DoDAF***
- Note both elements are integrated through a common Zachman based repository tool (e.g. METIS)

## High-Level Process Flow

***FEA***

***FEAF***

***DoDAF***

**Coordination of the Process provide through the Research Knowledge Base**

## Candidate RPC DoDAF Alignment

- DoDAF views coordinate aspects of the RPC Process

## RPC Functions / Roles

## Candidate RPC Technical Framework

## Thank-You

- smarley@pop600.gsfc.nasa.gov