Architectural Framework

1
Architectural Framework

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

2
What is an Architecture Framework?

• Architecture frameworks address what it means to
  define and document an architecture -
  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.

3
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!

4
But What Is An Architecture Framework??
A bunch of shapes connected by lines?
But.theres more to it than that!
5
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

6
You need all three legs for it to stand up
Complexity
Methods
Training Experience
Views
When a wise man is in a hurry, he sits down
first. Old Chinese Proverb
7
What Are My Choices?
8
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.

9
Zachman Structure
10
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

11
FEAF Structure
12
FEAF Views and Perspectives
FEAF Views
Planner
Applications Architecture
People (TBD)
Technology Architecture
Data Architecture
Time (TBD)
Owner
Motivation (TBD)
Designer
Builder
Sub- Contractor
Modified Zachman Structure
13
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
  organizations 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.

14
DoDAF Structure

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

15
The DoD Products Map to the Zachman Framework
Cells
Data
Function
Network
People
Time
Motivation
List of Locations Important to Business
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/MeansMa
jor Business Goal/CSF
Planners View
Operational Node Connectivity Description
Integrated Diction- ary
Capability Maturity Profile
Activity Model (List)
Operational Event Trace
Command Relationships Chart
e.g., Entity Relationship Diagram
e.g., Function Flow Diagram

AgentOrg Unit WorkWork Product
e.g., Business Plan EndBusiness
Objectives MeansBusiness Strategy
Time Business Event CycleBusiness Cycle
Activity Model
Owners View
Information Exchange Matrix


Logical Data Model

EntityData Entity Relationship
Data Relationship
e.g., Human Interface Architecture AgentRole
WorkDeliverable
e.g., Processing Structure
e.g., Knowledge Architecture EndCriterion Me
ansOption

e.g., Distributed
Operational Activity to Sys. Function Matrix
Activity Model
System Interface Description (High Level)
Designers View

System Functionality Description
Operational Event Trace Systems Event Trace



e.g., Knowledge Design EndCondition MeansAc
tion
e.g., Data Design
e.g., Human/
System Interface Description (Detailed)
Physical Data Model
System Interface Description (Detailed)
System Interface Description (Detailed)
Builders View
Engineer

e.g., Program FunctLanguage
Stmts ArgControl Blocks
EntFields RelAddresses


TimeInterrupt CycleMachine Cycle
e.g., Knowledge Definition EndSubcondition Mea
nsStep
System COMMS Description
An Aspect of Multiple Products
Subcontractors View
Technical View
DoD Architecture Framework Products
Systems View
Operational View
(rules not explicit in Zachman)
Only selected DoD products are shown on this
figure.
16
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.

17
TOGAF ADM
18
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.

19
How Does This Apply to RPC?
20
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 Earths 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

21
RPC Problem Space
22
Program Relationships
23
SN/RPC/ISS Role in Achieving NASA Goals

• SN/RPC/ISS has to serve to support NASAs
  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

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

25
High-Level Process Flow
Coordination of the Process provide through the
Research Knowledge Base
DoDAF
FEAF
FEA
26
Candidate RPC DoDAF Alignment
DoDAF views coordinate aspects of the RPC Process
27
RPC Functions / Roles
28
Candidate RPC Technical Framework
29
Thank-You

• smarley_at_pop600.gsfc.nasa.gov