U.S. Environmental Protection Agency
2006 Architecture Standard and
Guidance
CIO 2122-S/G-01.0 (no former number)
»EPA
OFFICE OF
ENVIRONMENTAL
INFORMATION
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Date
04-07-2006
04-10-2006
04-10-2006
04-12-2006
04-25-2006
04-27-2006
04/28/2006
05/01/2006
05/10/2006
5/10/2006
5/11/2006
5/15/2006
5/22/2006
5/26/2006
6/9/2006
Version #
0.01
0.02
0.03
0.04
0.05
0.06
0.01
(started
versioning
again with
new
document
title)
0.02
0.03
0.04
0.04
0.05
0.06
0.07
0.08
Reason
First draft of Phase 1 Baseline Segment Information Collection Guidance
created by Kevin Brett
Edited and formatted by Cecilia Farell
Updates by Kevin Brett
Fixed Table of Contents - Cecilia Farell
Added a clarification in the introduction that this is a phased, incremental and
iterative approach.
Added a Timeline section 1.2
Added clarification and expansion of how to use the Data Asset object.
Added a description in section 3.2 of the BMPN notation requirement for any
business process diagrams.
Added new section 4.7 on a usage convention for representing Geospatially-
related assets in the architecture.
First draft of 2006 Architecture Standard and Guidance (replaces Draft Phase 1
Baseline Segment Information Collection Guidance)
Technical Writer edit
Incorporated the table of steps in Appendix A into Section 3 as a sub-section
above the description of the layers and objects. Added a column to the table
with references to the sections that describe the objects involved in each step.
Made minor text edits. Re-numbered sections and corrected internal references
as needed.
Incorporated edits from QA and added EPA cover to the document.
Changed Section 3.3 to describe 'Object Reference' in greater detail.
Addressed various comments throughout the document that were provided
following review of the working draft delivered on 5/1/2006.
Addressed comments provided during EAWG review.
Revised definition of Data Mart and Data Warehouse and added reference to
ADC in Section 3.7.2 in response to EAWG comments.
Revised language in Section 2.1 Segment Architecture Compliance based on
EAWG comment
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
1. INTRODUCTION 1-1
2. ARCHITECTURE COMPLIANCE CRITERIA 2-1
2.1 Segment Architecture Compliance 2-1
2.2 Future Segment Architecture Activities 2-1
2.3 Solution Architecture Compliance 2-5
3. SEGMENT ARCHITECTURE DEVELOPMENT GUIDANCE FOR 2006 3-1
3.1 Introduction 3-1
3.2 Timetable 3-2
3.3 Phase I Information Collection and Modeling Steps 3-2
3.4 Strategic Layer 3-5
3.4.1 Overview 3-5
3.4.2 Organization Goal 3-6
3.4.3 Organization Objective 3-7
3.4.4 Organization Sub-Objective 3-7
3.5 Business Layer 3-7
3.5.1 Overview 3-7
3.5.2 Organization 3-8
3.5.3 Business Process 3-8
3.6 Data Layer 3-9
3.6.1 Overview 3-9
3.6.2 Data Entity 3-10
3.6.3 Conformed Dimension 3-10
3.6.4 Database 3-11
3.6.5 Data Asset 3-11
3.6.6 Data Mart 3-12
3.6.7 Data Warehouse 3-12
3.7 Application Layer 3-13
3.7.1 Overview 3-13
3.7.2 Application 3-14
3.7.3 Application Module 3-14
3.7.4 Service 3-16
3.8 Technology Layer 3-16
3.8.1 Overview 3-16
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3.8.2 Hardware Platform 3-17
3.8.3 Software Platform 3-17
3.9 Partner Architectures 3-18
3.9.1 Overview 3-18
3.9.2 Partner Application 3-19
3.9.3 Partner Business Process 3-19
3.9.4 Partner Data Asset 3-19
3.9.5 Partner Organization 3-20
3.10 Transition Architecture 3-20
3.10.1 Overview 3-20
3.10.2 Investment 3-20
3.10.3 Solution 3-21
3.10.4 Performance Measurement Indicator 3-21
APPENDIX A: PHASE I INFORMATION COLLECTION OBJECTS AND RELATIONSHIPS.A-
1
APPENDIX B: ADDITIONAL GUIDANCE B-l
of
Figure 2-1. Segment Architecture Objects 2-2
Figure 2-2. Segment Architecture Properties 2-3
Figure 2-3. Segment Architecture Relationships 2-4
of
Table 1-1. Data Collection Phases of the EA Development Effort 1-1
Table 3-1. Phase I Information Collection Timeline 3-2
Table 3-2. Phase I Information Collection and Modeling Steps 3-2
(.**,
-------
Draft 2006 Architecture Standard and Guidance
Jum 9, 2006
t INTRDQUmiOII
This document provides the Environmental Protection Agency (EPA) Enterprise Architecture (EA)
Program 2006 requirements for developing and modeling compliant Segment and Solution Architectures.
This document will be updated on an ongoing basis to reflect new standards and guidance as compliance
requirements evolve. The information in the document is complemented by two additional documents: 1)
the EPA EA Architecture Development Methodology and 2) the EPA EA Framework MetamodeI.
EPA is currently engaged in a multiphase development effort designed to increase the breadth and depth
of the architecture information represented in the Agency architecture repository. The information
collection phases of this effort are defined in Table 1-1 below:
Table 1-1. Data Collection Phases of the EA Development Effort
Phase
Phase I
Phase II
Phase III
Description
Baseline Segment Information Collection
Target Segment Information Collection
Transition Segment Information Collection
Timeline
March - June 2006
July -September 2006
October - December 2006
Each phase is designed to collect a particular subset of the total set of information that could potentially
represent a Segment Architecture based on the structure (metamodel) of the new Architecture Repository
and Tool (ART 4.0). As time goes on, successive iterations and phases of information collection will
encompass more details of the segments. In addition, development of specific Solution Architectures as
defined in the ART 4.0 metamodel will be conducted as well.
The organization and contents of this document are listed and described below:
Section 1: Introduction - Provides an introduction to this document.
Section 2: Architecture Compliance Criteria - Describes the 2006 compliance criteria for Segment and
Solution Architectures. Details of the Segment Architecture criteria are provided in the remainder of the
document.
Section 3: Segment Architecture Development Guidance for 2006 - Provides explanations,
definitions, examples, and guidance to aid developers in identifying and representing Segment
Architecture information for the Phase I Baseline Segment Data Collection effort. The section also
contains a table that provides a suggested sequence for developing a Segment Architecture by listing
information collection and modeling steps based on a logical ordering of the defined objects and their
relationships. When using this section, readers can refer to Appendix A and Appendix B for additional
guidance.
Appendix A: Phase I Information Collection Objects and Relationships - Lists the objects and
relationships that define the minimum content standard for Segment Architectures in 2006.
Appendix B: Additional Guidance - Provides additional clarification about certain object properties in
response to questions the EA Team has received to-date from Segment Architecture development teams.
1-1
-------
Draft 2@Q,6 Architecture Standard and Guidance
June 9, 2006
This Page Intentionally Left Blank
1-2
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
2. ARCHITECTURE COMPLIANCE CRITERIA
This section defines the 2006 compliance criteria for EPA Segment and Solution Architectures. The
compliance criteria represent the minimum requirements that Segment and Solution Architectures must
meet to be certified compliant by EPA's Chief Architect. The compliance criteria will be updated on an
annual basis to correspond with EPA's adopted incremental, phased approach to defining, collecting, and
updating architecture information.
2.1 Segment Architecture Compliance
The figures below depict the minimum set of Segment Architecture metamodel object types that must be
identified, populated, and collected during Phase I: Baseline Segment Information Collection. The
diagrams represent the following:
Figure 2-1. Segment Architecture Objects - Required baseline segment architecture objects.
Figure 2-2. Segment Architecture Properties - Properties to be collected for each of these objects.
Figure 2-3. Segment Architecture Relationships- Relationships between the objects.
Segment architectures must submit the following documentation by September 1st, 2006:
1. Existing baseline architecture information that meets the required objects and is structured in the
EA standard format (either in the Metis metamodel or in the structured excel spreadsheet)
2. A plan of action, including dates and activities, to complete the remaining, or defined scope, of
required objects, properties and relationships. Plans of action must be approved by Chief
Architect prior to EA certification of segment architecture.
Segment Architecture documentation will be certified as EA compliant according to the processes
outlined in the EA Governance Procedure.
2.2 Future Segment Architecture Activities
Moving forward in the multiphase development effort, the Chief Architect, in consultation with the
EAWG, will recommend segments and their architecture priorities to the QIC for formal review and
approval. The next stage of EA development will use these approved priorities to define and focus
architecture activities in Phase II: Target Segment Information Collection scheduled to begin July 2006.
Segment architecture compliance criteria will evolve iteratively in future years and this document will be
updated to reflect new requirements as EPA's EA matures.
2-1
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
EPA Enterprise Architecture
Data Collection Phase I Model
Segment Architecture
Federal Architecture
I Federal Agency Partner Architecture
Strategic Layer
Organization Goal
Organization
Objective-
Organization
Sub-Objeclhre
Business Layer
Organization
Business Process
Data Layer
Application Layer
Application
Module
Service
Technology Layer
Transition Archil'
Performance
Solution Measurement
| | Indicator |,
Non-Federal Partner Architecture
Non-Federal Partner Architecture
Partner
Application
Partner
Data Asset
Partner
Organization
Partner Process
Figure 2-1. Segment Architecture Objects
2-2
^x-
e
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
EPA Enterprise Architecture
Data Collection Phase I Model
Strategic Laye
Ovswtiiallon Goal
HMM
Dswslfoon
Organization Objocliv*
Mm
DHotakn
Organuation
Sub-Ob!«e1iv(!
Niamn
Dwscripior
Justness Layer
Organization
Agincy Name
Oijji-i/a-jtM- Narnti
Ofgamzatiw Description
Builnmi Process
Mm
Dwtripjpn
Data Coflecikxi S^iut
Prac«s Swieilfwy
Froquorc,' of DM
FTfe
Urk to Pnjcsw Diagram
Da
la Layer
D,l(a Wiwhoirtf
Him
DescitpOon
COM Wart
Narrw
OtsonpHoo
Conformed
Oimeniion
Nan»
0«=enplion
DgblMH
NMM
Deecnptkxi
C^l'KKfV
DIIIJI Enrlty
MM*
Deser^Wfi
mttAtui
NnM
OweripiiQn
iyp»
t>ospaliall BnaWBdT
Appll»l»n Modulo
Nan*
Descnpwxi
Technology Layer
Sott*»ro Filiform
Nm
Vnfxtof
MaM
Annual Md"1:«
FterJomtUsa
Targot Availabity Oil*
Hardware PtaCform
Na/ne
'"'v^oT'
MUM
I,1. :..--!
Arru.i '.' -! ;
....
Figure 2-2. Segment Architecture Properties
2-3
^x-
e
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
EPA Enterprise Architecture
Data Collection Phase I Model
Fs-dwal Agency Partner Architecture
Figure 2-3. Segment Architecture Relationships
2-4
^x-
e
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
2.3
This sub-section defines the 2006 compliance criteria for all EPA information technology (IT)
investments funded through the Capital Planning and Investment Control (CPIC) major procedures and
non-major (CPIC-Lite) processes.
With the recent CIO approval of the EA Governance Procedure, EPA will continue to phase in the
Solution Architecture requirements for IT investments. Beginning in FY06, for use in the development of
the BY08 IT investment portfolio, Solution Architectures must meet the following documentation
requirements:
1. EA questions in the BY08 business cases are completed and accurately documented for all CPIC major
investments; and
2. A complete and accurate systems inventory record is documented in the Registry of EPA Applications
and Databases (READ). READ is the Agency's authoritative information resource inventory. The
inventory record captures important information on EPA's IT systems including the strategic goals the
system supports, the data housed and used by the system, and critical architecture information.
Solution Architecture documentation will be certified as EA compliant according to the processes
outlined in the EA Governance Procedure.
2-5
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3.1 Introduction
The guidance provided in this section of the document supports the first information collection phase of
the EPA EA development effort (Phase I: Baseline Segment Information Collection). Phase I information
collection is being conducted from March through June of 2006.
The objects defined below, structured according to the layers of the EPA EA framework, represent an
initial subset of the larger set of elements that comprise a fully specified Segment Architecture. This
definition of an initial subset is in keeping with the EA Team's approach to the development of EPA's
EA as an ongoing effort requiring an iterative and incremental structure. Through various phases of
information collection, a more complete picture of the Agency's Baseline, Target, and Transition
Architectures will emerge overtime. The section preceding the object definitions provides a suggested
sequence for developing a Segment Architecture by listing information collection and modeling steps
based on a logical ordering of the objects and their relationships.
These objects have been identified as the most crucial in establishing the basic structural foundation of
EPA's Segment Architectures. Some of these elements are part of the overall EPA EA metamodel, but
need not be collected or identified during this initial phase (for a complete identification of objects
required for this phase, see Section 2.1, Segment Architecture Compliance). When reading through the
guidance, refer to the appendices in this document for additional information. Appendix A includes a list
of all Phase I objects and their relationships. Appendix B includes additional guidance on certain object
properties.
As the EA matures through future, more detailed data collection efforts, the Agency will be well-armed to
make vital, informed decisions.
3-1
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3.2
Table 3-1 below provides the timetable for Phase I information collection activities.
Table 3-1. Tentative Phase I Information Collection Timeline
Time Range
March -June 9
June 9
June 12-16
June 19
June 20- 30
June 20- July 3
July 3-7
July 10-14
July 31
Activity
Segment Architect identifies and collects Phase I segment data.
Segment Architect submits Metis models or data collection spreadsheets to EPA EA
Team for import into ART test environment.
Segment Architects obtains SIO validation.
SIO submits validated metis models or data collection spreadsheets and plan of
action to Chief Architect
Chief Architect, ordesignee, and Segment Architect meet to review segment
documentation and concur on action plan
Chief Architect certifies segment architecture as EA compliant for 2006
Segment Architect obtains AA approval.
Segment Architect notifies EA Team of AA approval.
EATeam publishes EA Baseline
3.3 I
Table 3-2 below provides a suggested sequence for developing a Segment Architecture by listing
information collection and modeling steps based on a logical ordering of the objects and relationships
defined in the sub-sections below. Although modeling of a segment may begin at any point in any layer of
the architecture and proceed outward, the steps outlined below start at the top of the Strategic Layer with
the Segment Name and continue through the various supporting layers of the Segment Architecture.
Following these steps will result in the creation of a Segment Architecture that represents all of the
objects, relationships, and properties required for Phase I of the architecture information collection effort.
The "Object Reference" column directs the reader to the location in the document that gives a definition,
examples and guidance on the specific object(s) referenced in each step.
Table 3-2. Phase I Information Collection and Modeling Steps
Step
1.
2.
3.
Description
Map the Segment to Organizations that are part of the Segment (the Segment
object will already be built into the Segment Architecture).
Map the Organization Goals, Objectives, and Sub-Objectives to the
Organization.
Map the Organization Goals, Objectives, and Sub-Objectives to the EPA
Objectives and Sub-Objectives.
Object
Reference
3.5.2
3.4.2, 3.4
3.5.2
3.4.2, 3.4
3, 3.4.4,
3, 3.4.4
3-2
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Step
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Description
Identify the segment's Business Processes.
Map the processes to the Organizations in the segment.
Map the processes to the lowest-level EPA BRM Sub-Function.
Map the processes to Program/Project List.
Define Performance Measurement Indicators and map them to the
Organization Objectives and Sub-Objectives.
Map the Performance Measurement Indicators to the FEA Performance
Reference Model (PRM).
Identify Names of Partner Organizations that your segment interacts with.
These Organizations may be federal agencies, state or local governments,
tribal nations, or industry and academic institutions.
Map the segment Organizations to the Partner Organizations.
Identify Partner Business Processes that interact with EPA Business
Processes in some manner.
Map the EPA Business Processes in your segment to Partner Business
Processes they interact with or are part of.
Identify any Data Warehouses and relate them to their constituent Data Marts.
Note: Some Data Marts may not be part of a Data Warehouse. There may
also be some situations where a typical database is referred to as a "data
warehouse." If the object being represented is actually just a database, then
use the Database object to represent it even if it is called a data warehouse. If
the object is a dimensional data mart and it is part of a collection of data marts
that make up a larger actual data warehouse or a collection of data marts that
are conceptually viewed as a data warehouse, use the Data Mart object and
group the related data marts by linking them all to the same Data Warehouse
object.
Identify the Names of the Conformed Dimensions represented by all Data
Marts. Link the Conformed Dimensions to their owning Data Marts.
Identify all Conceptual Data Entities that are represented in the Data Marts
and map the Conceptual Data Entities to their owning Data Marts.
Map Conceptual Data Entities to Business Processes that Create, Read,
Update, or Delete (CRUD) these entities.
Map the Data Warehouses and Data Marts to the Organizations.
Identify Databases that are part of the segment.
Map the Conceptual Data Entities to the Databases that contain them.
Map the Databases to the Organizations.
Object Reference
3.5.3
3.5.3, 3.5.2
3.5.3
3.5.3
3.10.4, 3.4.3, 3.4.4
3.10.4
3.9.5
3.5.2, 3.9.5
3.9.3, 3.5.3
3.5.3, 3.9.3
3.6.7, 3.6.6
3.6.3, 3.6.6
3.6.2, 3.6.6
3.6.2, 3.5.3
3.6.7, 3.6.6, 3.5.2
3.6.4
3.6.2, 3.6.4
3.6.4, 3.5.2
3-3
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Step
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
Description
Identify other Data Assets such as:
Data Set
Registry
Data Service
Repository
Map the Data Assets to the Organizations.
Identify Partner Applications that interface with EPA Databases and Data
Marts.
Map the Partner Applications to the EPA Databases and Data Marts that they
use.
Identify EPA Applications in the segment that interface with external Partner
Applications.
Map the EPA Applications to the Partner Applications that they interface with.
Identify remaining Applications in the segment that do not have interfaces with
external Partner Applications.
Map Applications to the Conceptual Data Entities that they Create, Read,
Update, or Delete (CRUD), or simply map the Applications to the Conceptual
Data Entities and indicate that the relationship is "uses" if the CRUD
relationships are not known.
Map Applications to any Data Marts that they use.
Map Applications to any Databases that they use.
Map Applications to any other Data Asset they use such as:
Data Set
Registry
Data Service
Repository
Map Applications in the segment to Investments whether the Investment is a
Major or Non-Major. There may be one or more Applications per Investment.
In the case where an Application is not covered by a Major or Non-Major
Investment, map the Application to the Solution that it is part of.
A Solution to a business problem can be composed of one or more
Investments. Map the Investments to the Solutions that they belong to.
Map the Applications to the Business Processes that they support.
Map the Business Processes to the Solution that they are part of.
Map the Business Processes to the Investment that they are part of. However,
note that not all Business Processes are funded for re-engineering by an
Investment.
Object Reference
3.6.5
3.6.5, 3.5.2
3.9.2, 3.6.4, 3.6.6
3.9.2, 3.6.4, 3.6.6
3.7.2, 3.9.2
3.7.2, 3.9.2
3.7.2, 3.9.2
3.7.2, 3.6.2
3.7.2, 3.6.6
3.7.2, 3.6.4
3.7.2, 3.6.5
3.7.2, 3.10.2, 3.10.3
3.10.3, 3.10.2
3.7.2, 3.5.3
3.5.3, 3.10.3
3.5.3, 3.10.2
3-4
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Step
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
Description
Identify the Application Modules or major sub-systems of each Application.
Map the Application Modules to the Applications they are part of.
Identify the Services provided by either the Application or the Application
Modules.
Map the Services to the Application Modules or Applications (if the Application
cannot be decomposed into Application Modules).
Map the Services to the FEA Service Component Reference Model (SRM).
Services should be described at a specific level as a decomposition or further
elaboration of the lowest level of the SRM.
Identify the Hardware Platforms (servers, server farms, mainframes, etc.) that
the Applications run on.
Map the Hardware Platforms to the Applications that run on them.
Identify the Software Platforms that host or support the Applications.
Map the Software Platforms to the Hardware Platforms that they run on.
Map the Software Platforms to the EPA Technology Reference Model (TRM).
Map the Hardware Platforms to the EPA TRM.
Object Reference
3.7.3, 3.7.2
3.7.3, 3.7.2
3.7.4, 3.7.2
3.7.4, 3.7.3,
3.7.3
3.7.2
3.7.4
3.8.2, 3.7.2
3.8.2, 3.7.2
3.8.3, 3.7.2
3.8.3, 3.8.2
3.8.3
3.8.2
3.4
3.4. f
The primary purpose of the segment Strategic Layer is to describe the goal structure of the segment. The
goal structure consists of Organization Goals, supported by Organization Objectives and Organization
Sub-Objectives. An Organization Goal maps directly to one or more EPA (i.e., enterprise) Objectives or
Sub-Objectives making it, in effect, a further decomposition and specification of the EPA Objective/Sub-
Objective. Since segments are an organizing principle of the EPA EA, a segment's Organization Goals
give it its driving force and provide the "Why" for the supporting layers of the Segment Architecture and
its supporting Solution Architectures.
NOTE: Segments themselves are an architectural construct and, as such, do not have their own distinct
goals. It is the Organization or Organizations composing the segment that have Goals, Objectives, and
Sub-Objectives.
The capabilities of the segment Strategic Layer include mapping Organization Goals to the EPA goal
structure. This mapping ensures fulfillment of existing EPA Strategic Goals and helps minimize deviation
from them. Population of segment Drivers and Critical Dependencies (to be performed during later phases
of data collection) enables business decision-makers and architects to analyze and evaluate factors that
influence the establishment and successful accomplishment of the segment's goals and objectives, and to
plan for the necessary steps to achieving them.
The Strategic Layer, specifically the Segment object itself, provides the ability to establish a high-level
mapping to other Organizations such as federal and non-federal partners (i.e., state and local
governments, tribes, industry, academia, and international partners). The Organization Objectives in the
3-5
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Strategic Layer facilitate mapping to initiatives in the segment's Business Layer, which in turn map to
projects supporting these Initiatives in the Transition Architecture (to be captured in later data collection
phases). These combined sets of relationships provide the ability to select and target expenditures towards
specific goals and measure their progress, and to assess the Solutions and Investments supporting the
Organization Goals.
OBJECTS:
Organization Goal (3.4.2)
Organization Objective (3.4.3)
Organization Sub-Objective (3.4.4)
3.4.2
Agency Program Offices and business/service functions have goals, and generally these goals are
decomposed into objectives or even sub-objectives.
Definition:
An Organization Goal articulates the way a segment Organization's business is intended to be
conducted once the Target Architecture is achieved. An Organization Goal may also add a new
function to the existing work of the segment. An Organization Goal may map to one or more EPA
Objectives or Sub-Objectives.
Examples:
"Improve the scientific defensibility of existing monitoring programs."
"Create an emergency response capability that provides on-site response teams within two hours of
a disaster."
Guidance:
Start by identifying your Organization Goals and continue by identifying any Organization Objectives
and Sub-Objectives. Next, identify how these Organization Goals, Objectives, and Sub-Objectives
map to the EPA Strategic Plan in order to establish a line of sight from segment, through goals, to
objectives and, where applicable, sub-objectives.
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3.4.3
Organization Objectives can be related to their parent Organization Goals and decomposed into
Organization Sub-Objectives.
Definition:
An Organization Objective is a discrete and measurable action to be carried out or state to be achieved
in furtherance of an Organization Goal. An Organization Objective directly supports the
accomplishment of an Organization Goal and must be directly mapped to it.
Examples:
"Replace 80% of existing monitoring stations with state-of-the-art technology by August 2007."
"Deploy 200 trained field personnel at 20 national sites by the end of 2009."
Guidance:
Link Organization Objectives to Organization Goals to provide a line of sight from the organization
and segment up to the goals, objectives, and sub-objectives of the EPA Strategic Plan.
3,4.4
Organization Sub-Objectives are decomposed from Organization Objectives.
Definition:
An Organization Sub-Objective is a discrete and measurable action to be carried out or state to be
achieved in furtherance of an Organization Objective.
Examples:
"Complete reliability testing of state-of-the-art monitoring stations by September 2006."
Guidance:
Enter the information for the Organization Sub-Objectives and identify the Organization Objectives
that they relate to or support.
3.5
3.5.1
The purpose of the segment Business Layer is to provide the context and description of the functions,
processes, and initiatives that compose the segment's business domain. The Business Layer provides
support to the Strategic Layer goal hierarchy through initiatives and Business Processes. The Business
Layer supports process reengineering and optimization as well as data integration and management. It
also provides a functional orientation to the Segment Architecture and defines the human capital elements
required to perform the Business Processes (e.g., Person and Competency). The Segment Architecture
encapsulates the business subset of the EPA EA allocated to a given segment. The specific scope of the
segment is defined by activities identified in the Definition property of the Segment object.
Documentation of baseline and target Business Processes facilitates the discovery of similarities or
redundancies among processes that may be consolidated, reused, or reengineered to meet new
performance criteria. Business Processes have a Data Collection Status property ("Red," "Yellow," or
"Green") that gives architects and business users an indication of the extent to which information about a
Business Process has been defined, documented, or validated. Business Process interfaces document the
connectivity between any two Business Processes. This connectivity includes related details such as
3-7
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
frequency of exchange, type and format of data exchanged, and the purpose for which the sending or
receiving process uses the information. Interfaces in the Target Architecture are qualified by a Target
Completion Date, which allows architects and business users to plan for future transformations of
Business Processes based on new or modified interfaces and exchanges of information.
Representation of people and their roles and skills in relation to Business Processes provides key elements
for human capital planning. These essential elements provide the ability to identify excess or insufficient
resources for performing Business Processes and conducting the business of the segment. Alignment of
Business Processes to EPA Business Reference Model (BRM) Sub-Functions minimizes duplication of
functions or processes across the Agency and corrects scoping of Solutions within the segment.
Mapping Business Processes to the Solutions they support and to the Applications that support them
establishes a chain of connected elements that makes it possible to identify all related elements of a
Solution Architecture, thus providing architects with the ability to visualize the baseline or target well in
advance of developing the architecture more specifically and in more detail as part of the System Life
Cycle Management (SLCM) Procedures. Also, mapping Applications and Business Processes to
Investments provides the association of these elements to the Investments that fund them.
OBJECTS:
Organization (3.5.2)
Business Process (3.5.3)
3.5.2
An Organization is a designated group within the Agency as defined by the Agency's organizational
structure.
Definition:
An Organization is a designated group within the Agency as defined by the Agency's organizational
structure. The internal organizations are one set of stakeholders.
Examples:
OW - Office of Water
AIEO - American Indian Environmental Office
OSWER - Office of Solid Waste and Emergency Response
LRS - Land Revitalization Staff
3.5.3
A Business Process is a set of sequential or related steps that together accomplish a business function or
provide a service. Steps in a Business Process are time-bound and denoted by verbs and nouns, (e.g.,
"interview candidate").
Based on guidance from the Object Management Group (creators of the Business Process Modeling
Notation (BPMN) standard),1 Business Processes are made up of activities, i.e., work that is performed as
part of a Business Process. An activity can be either atomic or non-atomic (a compound entity that can be
decomposed into more steps at a lower level of detail). The types of activities that are a part of a Business
Process Model are: Process, Sub-Process, and Task. One or more Business Processes make up a business
' Object Management Group (OMG) Business Process Management Initiative, http://www.bpmn.org/index.htm.
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
function. Business functions (EPA BRMSub-Functions) are defined in the EPA Business Reference
Model (BRM).
Definition:
A Business Process is a set of sequential or related steps that together accomplish a business function
or provide a service. Steps in a Business Process are time-bound and denoted by verbs and nouns.
(e.g., "interview candidate").
Examples:
"Register Pesticide"
"Process New Hire"
"Acquire Staff'
"Develop Budget"
Guidance:
If your segment owns or uses business processes, provide information about them via the Business
Process object. If a process is represented and it interfaces in some way with another process within
EPA, enter a record for both processes and indicate how they interface with one other.
If you use a process that belongs to a Federal or Non-Federal Partner Organization, create this
process as a Partner Process, and link the Organization's processes to it in order to indicate that an
interface exists.
Business Processes should be named starting with a verb followed generally by the noun that the verb
acts upon. Avoid long names such as "Develop the Initial Budget for the Next Fiscal Year" and
simply name the process "Develop Budget." Save the details and enhancements or qualifying text for
the Description property of the Business Process.
NOTE: Some organizations have and are providing process maps, flowcharts of tasks, or process flows.
For compatibility reasons, these process diagrams must be developed using the BPMN standard
developed by the Object Management Group. BPMN templates for flowchart tools such as Visio are
available by doing a search on the Web. Process maps or flowcharts are not mandatory for this first phase
of data collection. However, realizing that many will likely be submitted as part of this phase, the EA
Team wants to ensure that all segment developers are aware of the BPMN requirement.
3.6
3.6.1
The purpose of the segment Data Layer is to promote data integration and data management. The Data
Layer is structured to represent the data resources of the segment and to show critical relationships
between these vital resources and the Business Processes and Applications that use or rely on them.
The Data Layer is consistent with the FEA Data Reference Model (DRM) 2.0 and consists of three
primary areas: Data Description, Data Context, and Data Sharing. All three areas of the Data Layer, and
the objects and relationships within them, contribute to achieving the goal of improved information
sharing, management, and discovery.
To achieve improved integration, the EPA EA must make evident to business users, architects, and
system owners the sources, locations, structure, content, stewardship, exchanges, and queries of Segment
and Solution Architecture data. This information about the data, together with its relationship to Business
"-"* " ' $$ ^vit
3-9 fhj
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Processes and Applications, is the cornerstone for improving interoperability within the Agency and
between the Agency and its partners.
Integrating details of the various data schemas (such as those in the EPA XML Repository) into the EA
enables system designers and architects to identify reusable, similar, or redundant schemas for use in the
design of Agency Business Processes and Applications. Mapping to data standards and resources enables
architects and business users to understand the format, structure, purpose, and validity of the data and its
sources.
OBJECTS:
Data Entity (3.6.2)
Conformed Dimension (3.6.3)
Database (3.6.4)
Data Asset (3.6.5)
Data Mart (3.6.6)
Data Warehouse (3.6.7)
Definition:
A Data Entity is an abstraction (a class of something) that is part of a conceptual data model.
Examples:
Regulated Entity
Waste Stream
Employee
Organization
Guidance:
Enter any Data Entities that are used by an Application or a Business Process and indicate how they
are used by either Business Processes or Applications. For each Data Entity, indicate the database in
which it is represented. You can also indicate the Application Modules that use each Data Entity.
3.6.3
Definition:
A Conformed Dimension is a common element that appears in multiple Data Marts.
Examples:
Facility
Substance
Time
Organization
Guidance:
Conformed Dimensions must be identically identified everywhere they are used so they mean exactly
the same thing to every user.
3"10
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Definition:
A Database is an organized collection of electronic records stored in a computer in a systematic way
that can be accessed by a user to answer questions. Typically, a Database refers to a relational
database.
Examples:
"Toxics Release Inventory"
"Air Quality System Database"
Guidance:
If your segment owns or uses databases, identify them through the Database object. Even if the
databases belong to other Organizations within EPA, indicate their names, and then identify mappings
between Databases and their supporting and related object types.
If a Database belongs to a Federal or Non-Federal Partner Organization, represent it as a Federal or
Non-Federal Partner Data Asset, then link your Organization's Databases to the Federal or Non-
Federal Partner Data Asset to indicate that an interface exists. Finally, decompose an EPA Database in
order to indicate the Conceptual Data Entities and Logical Databases that are represented in the
Database.
A Data Asset is a term used to identify a variety of other data resources under a somewhat generic object
type. Data Assets can be created to represent a Data Set, a Registry, a Directory, a Data Service, or a
Repository.
Some Data Assets are often referred to as a "Data Set," which in fact is true for any Database, Data Mart,
Data Warehouse, or other data structure. Knowing what technology underlies a Data Asset can often help
determine which object type to use to model it. For example, something known as a "Data Set" that is
actually implemented in an Oracle database should not use the Data Asset object. Instead, it should be
modeled by creating a Database object with the name of the data set and then linking the Database object
to a Software Platform object that is an instance of an Oracle database. The Software Platform object can
in turn be linked to a Hardware Platform object that represents the server on which the data set resides
inside its Database.
Definition:
A Data Asset is a managed container for a collection of data. The Data Asset is the physical
representation of a digital data source.
Examples:
Data Set
Registry
Directory
Data Service
Repository
Guidance:
Link Data Assets to known related objects.
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
A Data Mart is a specialized type of Database that is optimized for efficiency for a particular purpose and
audience. Data Marts draw data from other sources, such as multiple contributing Databases.
In the EPA EA, Data Marts are assumed to be "dimensional," using conformed and un-conformed
dimensions with fact tables (often known as a star schema). Data Marts are for analytical use only: they
do not process transactions or manage data prior to publication. Data Marts are able to hold a great deal of
historical data and are often a sub-set or specialized collection of data within a larger Data Warehouse
that is broader in scope and purpose.
Definition:
"A Data Mart is a database, or collection of databases, designed to help managers make strategic
decisions about their business. Whereas a Data Warehouse combines databases across an entire
enterprise, Data Marts are usually smaller and focus on a particular subject or department. Some Data
Marts, called dependent Data Marts, are subsets of larger Data Warehouses." - www.Webopedia.com
A Data Mart only exists because there is a need to "report" on the data it is collecting. It provides
easier access to disparate data by combining it into a Data Mart, for ease of use and accessibility.
Examples:
"AQS Data Mart" (which holds historical ambient air quality data for analytical use)
"Children's Health Data Mart" (a hypothetical data mart that combines information relevant to
children's health analysis from multiple databases)
Guidance:
Enter the names and descriptions of any Data Marts owned or used by your segment. Even if the Data
Marts are not all owned by your segment, you will need to enter the names of those that are used by
Applications in your segment.
Indicate any relationships between your Data Marts and any Data Warehouses they may be a part of.
Not all Data Marts are contained within a Data Warehouse. Some may be free-standing specialized
Data Marts, in which case it is not necessary to relate them to a Data Warehouse. In cases where a
collection of related Data Marts exists, they may collectively define a Data Warehouse. If this is the
case, create a Data Warehouse and relate the constituent Data Marts to it.
Definition:
"A Data Warehouse is a database geared towards the business intelligence requirements of an
organization. The Data Warehouse integrates data from the various operational systems and is
typically loaded from these systems at regular intervals. Data Warehouses contain historical
information that enables analysis of business performance overtime. It is the cohesive data model
that defines the central data repository for an organization. An important point is that we don't define a
warehouse in terms of the number of databases. Instead, we consider it a complete, integrated data
model of the enterprise, regardless of how or where the data is stored." - SQL Server Magazine
www.sqlmag.com
Generally, a Data Warehouse is used to store data on a temporal basis (e.g. snapshots of data stored
every night at Sam, once a week, etc.) while maintaining previous information -data is added, and not
3-12
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
deleted, from the Data Warehouse. The collection of this data in a warehouse allows you to perform
long-term analysis on your data. A Data Warehouse allows you to see how your data changes over
time by maintaining copies of this data in discrete time intervals.
Examples:
"Administrative Data Warehouse - ADW"
"Financial Data Warehouse - FDW"
"Cleanup Data Warehouse - CDW"
3.7
3.7.1
The purpose of the Application Layer is to facilitate improved data management and application
interoperability. This is achieved in part by providing key information about segment Applications, the
nature of their interfaces with other Applications, mappings to the Business Processes they support, and
the degree and quality of support provided.
One of the key capabilities provided by the Application Layer is the ability of baseline Applications to
link to one or more target or replacement Applications. Target Applications have a Target Completion
Date property that enables time-based views of interim targets for the Application Layer. For example, a
user of the EPA EA would be able to query the architecture to see which Applications will be completed
or in existence in a given fiscal year. This capability supports the notion of interim targets in a Transition
Strategy and Sequencing Plan as described in the OMB FEA Program EA Assessment Framework 2.0.
Another key capability of the Application Layer is the ability to run queries that show how EPA
Applications interface with each other and under what conditions, as well as how EPA Applications
interface with Partner Applications. This capability supports EPA's continuing efforts to achieve data and
application integration and to improve the interoperability of its systems.
The Application Layer enables architects to indicate the Services provided by an Application and, in a
more detailed breakdown, the Services provided by the Application Modules (or sub-systems) of an
Application. The identification and mapping of these Services to the FEA Service Component Reference
Model (SRM) enable EPA to identify candidates for submission to Core.gov's inventory of reusable
service components. The mapping of Services also enables EPA to search its own EA as well as Core.gov
to determine whether EPA is building redundant service components or whether existing service
components in the EPA EA or in Core.gov can be reused in EPA Applications to achieve more
economical implementations of EPA Solutions.
Other key object relationships to the Business Layer of the segment include the mapping of an
Application to any or all Business Processes that it supports. This mapping provides the ability to identify
the extent to which the Business Processes are supported by Applications. This information provides
inputs to the gap analysis process and definition of future Target Architectures and performance
measurements. Applications have a Data Collection Status property ("Red," "Yellow," or "Green") that
gives architects and business users an indication of how much information has been collected or created
about the Application.
OBJECTS:
Application (3.7.2)
Application Module (3.7.3)
3-13
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Service (3.7.4)
3.7,2
An Application is a computer program designed to fulfill one or more business functions. It may be a
single product designed for a single business function, or it may be a multi-module or multi-sub-system
entity with modules that support multiple business functions. An Application may be purchased (COTS),
custom-developed in-house, or repurposed from another entity.
Although products like Microsoft SQL Server, Oracle, Windows XP, and others are technically
applications, the EPA EA does not represent them in the Application Layer as an Application object.
Instead, they are represented in the Technology Layer as a Software Platform object. This is because these
types of applications do not perform direct, mission-oriented business functions, but play a system
support role and often host, support, or otherwise facilitate end-user applications.
The term "application" tends to be used synonymously with "system." A system may be one Application
or a group of related Applications, Business Processes, people, and other business elements.
Definition:
An Application is a computer program designed to fulfill one or more business functions.
Examples:
"Deltek" (a commercial application with numerous modules or sub-systems performing various
financial management business functions)
"eCPIC" (an application that is used to store business cases and investment information for OMB
Exhibit 300s)
Guidance:
If your Organization owns or uses Applications, enter information about them through the Application
object. This information can first be obtained by importing portions of the application's inventory
record contained in the Registry of EPA's Applications and Databases (READ) into your spreadsheet
or Metis model and then filling in gaps in application properties and relationships. Additional
application information may also be gathered from the Application Deployment Checklist. Even if the
Applications belong to other Organizations within EPA, enter their Names and Acronyms to establish
an initial mapping and interface between them. If an Application interfaces in some way with
another Application within EPA, enter both Applications and indicate which Applications interface
with each other. Later data collection phases will focus on more specific details of the interfaces and
data exchanges between the Applications. For now, the focus is on identifying the fact that interfaces
exist.
If an Application belongs to a Federal or Non-Federal Partner Organization, create it as a Federal or
Non-Federal Partner Application and link your Organization's Applications to the Partner Application
to indicate that an interface exists. Also, remember to indicate any Services that this Application
supports. If the Application is going to be decomposed into Application Modules, indicate the
Services each Application Module provides or supports rather than indicating the Services at the more
generic Application level of mapping.
3.7.3
The highest grouping of functional software units is an Application. An Application is often composed of
numerous Application Modules (sub-systems or smaller applications).
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Definition:
An Application Module is a sub-part or sub-system of an Application. It provides a distinct business
function that contributes to the overall functionality of the Application.
Examples:
"Payroll Processing"
"Timesheet Management"
"Invoice"
"Contract Reports"
Guidance:
Use the Application Module object to identify the modules for any Applications that can be
decomposed into their next smallest constituent units. A key aspect of both Applications and
Application Modules is that they provide or support a Service. It is important to note that it is not
necessary for a Service to be a Web Service. It can be a service in the broader sense as defined in the
FEA Service Component Reference Model (SRM).
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Although the FEA SRM defines "service" to a certain level of granularity, you should identify
functionality to a lower level of granularity that is more specific to the business function and to EPA.
Defining these services using the Service object will provide for very EPA-specific functionality to be
characterized as part of a Service Oriented Architecture (SOA). Once some or all of the Application
Modules have been identified, indicate which Services these Application Modules provide or support.
3.7.4
A Service is a self-contained business function that accepts requests and returns responses through a well-
defined standard interface. Services are "stateless," that is, they do not depend on any pre-existing
conditions to operate. Services can be provided or supported by Applications, or they may be specified at
a more granular level by relating them to Application Modules.
Services are provided or supported by Applications and Application Modules. Within the context of the
EPA EA, Services are more specialized instances of "services" as defined in the FEA SRM. Services need
not be limited to Web Services, but should follow from the definition in the FEA SRM.
Definition:
A Service, as defined within the Application Layer of a Segment Architecture, is a self-contained
business function that accepts requests and returns responses through a well-defined standard
interface.
Examples:
"A service that returns estimated latitude and longitude coordinates based on an address"
"A service that provides local weather updates"
"A service that allows data capture of employee timesheet data"
Guidance:
Enter all Services provided by your segment's various Applications and Application Modules, and
relate them to the Applications or Application Modules that provide or support them.
3.8
3.8.1
The purpose of the segment Technology Layer is to facilitate improved application and network
interoperability, reliability, security, processing and storage capacity, and adherence to technology
standards. The Technology Layer enables EPA to identify the capabilities and capacities of its hardware
and software base. Networks can be reconfigured for improved performance and resource sharing based
on segment-wide or enterprise-wide views of Technology Layer elements. Enterprise planning and
acquisitions can be made more efficient through an enterprise view of hardware and software licenses for
EPA standard technology elements. EPA can more effectively interface with other Federal and Non-
Federal Organizations, and show these interfaces in the EA across all segments to improve data flows
between Organizations.
The three primary objects of the Technology Layer of Segment and Solution Architectures are Software
Platform, Hardware Platform, and Network/Telecom Platform2 Each of these objects maps to multiple
2 This phase of information collection focuses only on Hardware Platform and Software Platform.
3-18
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
services of the Agency's Technical Reference Model (TRM) as defined within the EA Framework. These
generic object groupings were established to simplify the capture and reporting of technology data in
support of Segment and Solution Architectures.
The EPA EA Team expects that architects will most often select the hardware, software, and networks
that support their segments and solutions from the instances of objects defined in the EPA EA
Framework. The Agency's technology and security architecture program will establish an inventory of
hardware, software, and networks available for use throughout the Agency. In the case that a Segment or
Solution Architecture relies upon technology not captured or supported at the enterprise level, the
architecture can populate instances of these objects to depict unique aspects of the Agency's Technology
Layer. In all cases, Segment and Solution Architecture technologies should map to Agency technology
standards (EPA Technology Standards'). Failure to do so will reveal a gap in standards compliance that
requires either a change to the architecture or a waiver from Agency policy.
OBJECTS:
Hardware Platform (3.8.2)
Software Platform (3.8.3)
3.8.2
Definition:
A Hardware Platform is any physical hardware device on which software runs.
Examples:
"Webserver"
"Domain Name Server"
"Handheld Wireless Device"
"Firewall Server"
"Mainframe"
"High Performance Computer (supercomputer)"
"Mass Storage Device"
Guidance:
Enter the general types or specific names of the Hardware Platforms that make up a Segment
Architecture. Hardware Platforms can be identified for the various types listed in the Platform Class
drop-down list.
One example of how to identify Hardware Platforms is to create a record and indicate that its name is
simply "Development Server" or "Production Server." If it is known, for example, that a particular
server has a specific name, such as "Lincoln," put that in the Name property and use the Platform Use
drop-down list to indicate the purpose for which that server is typically used. Either way, give a
generic name to your server, such as "GEO Main Server" or "Katrina Response Server," or use the
specific name assigned to it by the network teams.
3.8.3
Software Platforms host Applications and Application Modules, and run on Hardware Platforms.
Software Platforms may also host other Software Platforms. The primary difference between an
Application and a Software Platform is that a Software Platform is not characterized as an end-user
application that performs some mission-oriented function. Software Platforms play more of a support role
3"17
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
for end-user applications and constitute the system environment for these applications. Although Software
Platforms often provide important business functions, they do not provide or perform Agency mission-
related functions.
Definition:
A Software Platform is generally a commercial software environment in which COTS or custom-built
Applications run or reside. Software Platforms include database packages, operating systems, web
servers, network management packages, and other system-oriented software that supports or facilitates
the operation or execution of Applications and networks that perform business functions.
Examples:
"Database" - Oracle, SQL Server, Sybase
"Operating System" - Windows Server, MVS, Linux
"Web Server" - Cold Fusion Server, J2EE, IBM WebSphere, BEA Web Logic, Apache
"Network Management" - CISCO Works for Switched Internets (CWSI)
"API" - An application program interface:
DPMI - DOS Protected Mode Interface
ISAPI - MS Internet Server API
J2ME - Java 2 Platform Micro Edition
MIDP - Mobile Information Device Profile
NSAPI - Netscape Server API
SAX - Simple API for XML
Guidance:
Once the segment's Software Platforms have been identified, indicate what Hardware Platforms they
run on and what Applications they host.
3.9
3.9.1
The EPA Partner Architecture is a modeling construct that allows Agency architects to identify Federal
and Non-Federal Partners with which EPA interacts in various ways. The main elements of this
architecture include state and local governments, tribal governments, industry partners, academia, and
international partners and other federal agencies.
Major aspects represented in this architecture also include Partner Processes, Applications, Data Assets,
and network interfaces. For each partner that interfaces with EPA, an instance of a Partner Architecture
should be created to represent the partner's Organization and its elements. This structure supports the
ability to model data flows and process interaction between EPA and all federal and non-federal entities.
OBJECTS:
Partner Application (3.9.2)
Partner Business Process (3.9.3)
Partner Data Asset (3.9.4)
Partner Organization (3.9.5)
3"18
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3,9.2
Definition:
A Partner Application is an Application used by an EPA partner in relation to a Partner Business
Process.
Examples:
"eRulemaking"
"STORET"
3.9.3
Definition:
A Partner Business Process is a Business Process carried out by a partner in relation to some process
in which EPA plays a role.
Examples:
"Criteria pollutant air quality monitoring"
A Partner Data Asset is essentially the same as the Data Asset object type. The main difference is that the
Partner Data Asset can be used to represent any type of data asset in a Partner Architecture and is not
limited to the short list of data asset types in the Types property of the Data Asset object.
This object type is used to identify a variety of data resources under a somewhat generic object type. Data
Assets can be created to represent Databases, Data Marts, Data Warehouses, Data Sets, Registries,
Directories, Data Services, and Repositories.
Definition:
A Partner Data Asset is a repository of data that is a managed container for a Partner collection of
data. The Data Asset is the physical representation of a digital data source.
Examples:
"Data Set"
"Registry"
"Directory"
"Data Service"
"Database"
"Data Mart"
"Data Warehouse"
"Repository"
"Taxonomy"
Guidance:
Once you have created one or more Partner Data Assets, map them to related objects.
3-19
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
3. S. 5
Definition:
A Partner Organization is a federal, state, local, tribal, or commercial organization that plays a role
within an EPA Business Process.
Examples:
"California Air Resources Board"
"Federal Emergency Management Agency"
"Department of the Interior"
"NASA"
3.10
3.10.1
The Transition Architecture is a model of the elements of the Transition Strategy that the Agency has
developed to govern the transition from the Baseline Architecture to the Target Architecture. These
elements include Investments, Gaps, Solutions, Projects, Performance Measurement Indicators for the
Target Architecture (which compose the performance improvement plan), and the sequencing of
milestones.
The Transition Architecture is used to track and report on progress of milestones toward the construction
of the Target Architecture and their relationships to Performance Measurement Indicators (PMIs). The
Transition Architecture enables 1) identification of relationships between Investments and funding
sources, 2) tracing of expenditures on Organization Goals and Objectives, and 3) establishment of a line
of sight from Solutions up through EPA Strategic Goals and EPA Objectives.
The bulk of the Transition Architecture information will be captured in a third phase of information
collection. However, during this first phase, the following elements are essential to laying the foundation
for the Transition Architecture.
OBJECTS:
Investment (3.10.2)
Solution (3.10.3)
Performance Measurement Indicator (3.10.4)
3.10.2
Definition:
An Investment is any ongoing expenditure subject to the Capital Planning and Investment Control
(CPIC) Procedure. Investments include Major Investments, Non-Major Investments, and small
investments.
Examples:
"FinRS - Financial Replacement System" (the single Investment that covers the entirety of the
Solution for Financial System Modernization)
"CDX - Central Data Exchange" (one of several Investments that collectively define the Agency
Solution for data integration)
3-20
e
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Guidance:
One or more Investments may compose a single Solution. Applications and Business Processes can be
mapped to Investments that fund them, although not all Business Processes re-engineering and
Applications may be funded by an Investment. Those Applications and Processes not currently funded
by some Investment can still be mapped to a Solution of which they are a part.
3.10.3
A Solution is an answer to a business problem and typically funds one or more Investments with a
corresponding OMB Exhibit 300 or 53. According to the EPA EA Policy, a Solution Architecture must be
developed for each Solution to ensure compliance with EA standards and the Target Architecture. A
Solution may have a number of Business Processes and/or Applications associated with it. Some of these
may or may not be funded by the Investments composing the Solution, but are still part of the Solution.
Definition:
A Solution is an answer to a business problem and typically funds one or more Investments with a
corresponding OMB Exhibit 300 or 53.
Examples:
"FinRS - Financial Replacement System" (an Investment, but it is also a Solution to the financial
systems modernization issue)
"Enterprise Tools" (a Solution made up of a number of Investments that fund the various systems or
Applications that compose Enterprise Tools - including CDX, EPA Portal, IAM, ETL and others)
Guidance:
Once Solutions for the segment have been identified, map the Investments that compose those
Solutions to the Solutions themselves.
3,10,4
Definition:
A Performance Measurement Indicator (PMI) is a quantifiable measure of progress against a
benchmark state.
Examples:
"In 600 of the Nation's watersheds, water quality standards are met in at least 80% of the assessed
water segments" (Mission and Business Results)
"Reduce the response time for each help desk call from 1 day to 1 hour" (Customer Results)
"Increase the percentage of help desk calls that are closed within one call from 20% to 50%"
(Processes and Activities)
"Install 25 additional help desk stations by the end of the calendar year" (Technology)
Guidance:
Indicators may be applied to multiple object types and align with the terminology and structure of the
FEA Performance Reference Model, which recognizes four measurement areas that operate along a
"line of sight":
3"21
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
1. Mission and Business Results - Measures that capture the outcomes that the Agency seeks. In EA
Segments, mission and business results measure link to objectives and sub-objectives at the
Enterprise level, not the segment level.
2. Customer Results - Measures how well a specific process within the Agency is serving its
customers, internal or external, including citizens where applicable.
3. Processes and Activities - Measures outputs that are the direct result of the process in question.
4. Technology - Captures key elements of performance that directly relate to the object in question, if
appropriate.
Note that Technology measures are only applicable where technology plays a role, such as in an IT
Investment. A PMI can relate to other PMIs to indicate line of sight. It should also be mapped to
Organization Objectives and Sub-Objectives (whatever is the lowest level in the goal hierarchy for the
Organization.), EPA Objectives and Sub-Objectives, and finally to the appropriate level in the FEA
Performance Reference Model.
The examples given above show statements that can be transformed into PMIs at various levels within
the architecture that relate to or support Organization Objectives and Sub-Objectives.
3-22
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
APPENDimA;
PHASE IINFOKMATIGN COLLECTION O1JECT1
AND RELATIONSHIP!
The table below identifies all objects and relationships that are part of the Phase I Baseline Information
Collection Spreadsheet and that are supported by ART 4.0. There are a number of instances where there
may be multiple relationship types that exist between two object types. Generally, there should only be
one relationship used between any two instances. For example: Organization A owns Application B, OR
Organization uses Application B, but not both. However, the existence of multiple relationship types
between two objects allows the architecture developer to choose the relationship that most accurately
describes the situation that is being modeled.
Information Type
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application
Application Module
Application Module
Relationship Type
contains
critical to
uses
accesses
accesses
accesses
accesses
performs
contains
provides
is hosted by
is contained in
is used by
supports
is owned by
supports
supports
supports
interfaces
exposes
uses
composes
is contained in
uses
Related Information Type
Application Module
Business Process
Data Entity
Data Asset
Data Mart
Data Warehouse
Database
EPA BRM
EPA Data Class
FEA SRM (service)
Hardware Platform
Investment
Organization
Organization
Organization
Organization Goal
Organization Objective
Organization Sub-Objective
Partner Application
Service
Software Platform
Solution
Application
Data Entity
A-1
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Information Type
Application Module
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Data Entity
Data Entity
Data Entity
Data Entity
Data Entity
Conformed Dimension
Cross-Goal Strategy
Data Asset
Data Asset
Data Asset
Data Asset
Data Asset
Data Asset
Data Asset
Data Mart
Relationship Type
accesses
relies on
uses
supports
uses
is contained in
is used by
regulated by
involves
is owned by
is executed by
is consultant to
supports
supports
supports
is funded by
is critical to
is used by
is used by
is used by
is contained in
is represented in
is conformed dimension of
is supported by
is accessed by
is accessed by
sources
sources
is hosted by
is owned by
is hosted by
is accessed by
Related Information Type
Data Asset
Application
Data Entity
EPA BRM
EPA Data Class
Investment
Organization
Organization
Organization
Organization
Organization
Organization
Organization Goal
Organization Objective
Organization Sub-Objective
Program/Project
Solution
Application
Application Module
Business Process
Data Mart
Database
Data Mart
Organization Goal
Application
Application Module
Data Mart
Database
Hardware Platform
Organization
Software Platform
Application
A-2
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Information Type
Data Mart
Data Mart
Data Mart
Data Mart
Data Mart
Data Mart
Data Mart
Data Warehouse
Data Warehouse
Data Warehouse
Data Warehouse
Database
Database
Database
Database
EPA BRM
EPABRM
EPA Data Class
EPA Data Class
EPATRM
EPATRM
FEA PRM
FEA SRM (service)
FEA SRM (service)
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Relationship Type
contains
has
sourced from
is contained in
is used by
is owned by
is managed by
is accessed by
is accessed by
contains
is owned by
is accessed by
represents
sourced from
is hosted by
is performed by
is supported by
is contained in
is used by
is aligned to
is aligned to
is aligned to
is provided by
includes
hosts
hosts
aligns with
is used by
supports
is owned by
is hosted by
hosts
Related Information Type
Data Entity
Conformed Dimension
Data Asset
Data Warehouse
Organization
Organization
Organization
Application
Application Module
Data Mart
Organization
Application
Data Entity
Data Asset
Software Platform
Application
Business Process
Application
Business Process
Hardware Platform
Software Platform
Performance Measurement Indicator
Application
Service
Application
Data Asset
EPA TRM
Organization
Organization
Organization
Organization
Software Platform
A-3
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Information Type
Investment
Investment
Investment
Objective
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization Goal
Organization Goal
Organization Goal
Organization Goal
Organization Goal
Organization Goal
Relationship Type
contains
contains
is contained in
is supported by
uses
is supported by
owns
uses
regulates
participates in
owns
executes
consults on
owns
uses
owns
manages
owns
uses
is supported by
owns
hosts
is included in
uses
is supported by
owns
is supported by
is supported by
supports
supports
supports
supports
Related Information Type
Application
Business Process
Solution
Organization Goal
Application
Application
Application
Business Process
Business Process
Business Process
Business Process
Business Process
Business Process
Data Asset
Data Mart
Data Mart
Data Mart
Data Warehouse
Hardware Platform
Hardware Platform
Hardware Platform
Hardware Platform
Segment
Software Platform
Software Platform
Software Platform
Application
Business Process
Cross-Goal Strategy
Objective
Organization Objective
Segment
A-4
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Information Type
Organization Goal
Organization Objective
Organization Objective
Organization Objective
Organization Objective
Organization Objective
Organization Objective
Organization Sub-Objective
Organization Sub-Objective
Organization Sub-Objective
Organization Sub-Objective
Organization Sub-Objective
Organization Sub-Objective
Partner Application
Partner Application
Partner Business Process
Partner Data Asset
Partner Organization
Partner Organization
Partner Organization
Performance Measurement
Indicator
Performance Measurement
Indicator
Performance Measurement
Indicator
Program/Project
Segment
Segment
Service
Service
Software Platform
Software Platform
Relationship Type
is supported by
is supported by
is supported by
supports
is supported by
is supported by
is supported by
is supported by
is supported by
supports
is supported by
is supported by
supports
interfaces with
is owned by
is owned by
is owned by
owns
owns
owns
aligns with
supports
supports
funds
includes
is supported by
is exposed by
maps to
is used by
hosts
Related Information Type
Sub-Objective
Application
Business Process
Organization Goal
Organization Sub-Objective
Performance Measurement Indicator
Solution
Application
Business Process
Organization Objective
Performance Measurement Indicator
Solution
Sub-Objective
Application
Partner Organization
Partner Organization
Partner Organization
Partner Application
Partner Business Process
Partner Data Asset
FEA PRM
Organization Objective
Organization Sub-Objective
Business Process
Organization
Organization Goal
Application
FEA SRM (service)
Application
Data Asset
A-5
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
Information Type
Software Platform
Software Platform
Software Platform
Software Platform
Software Platform
Software Platform
Solution
Solution
Solution
Solution
Solution
Sub-Objective
Sub-Objective
Relationship Type
hosts
aligns with
is hosted by
is used by
supports
is owned by
is composed of
relies on
contains
supports
supports
supports
supports
Related Information Type
Database
EPA TRM
Hardware Platform
Organization
Organization
Organization
Application
Business Process
Investment
Organization Objective
Organization Sub-Objective
Organization Goal
Organization Sub-Objective
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
APPENDS &
This appendix provides additional clarification about certain object properties in response to questions the
EA Team has received to-date from Segment Architecture development teams.
Data Collection Status - This property is a qualitative or subjective assessment of how much
information about an Application has been collected and put into the architecture. If only the Name and
Acronym have been identified, the status should be "Red." If a few of the properties and some
relationships to other related objects have been identified, the status should be "Yellow." If most or all of
the properties have been populated and most or all of the relationships to other objects have been
established, or if the information collected thus far is as complete as it is likely to be, the status should be
"Green."
Strategic Value - This property is a qualitative or subjective assessment of the strategic value of an
Application as it relates to its use by multiple Organizations. The following guidelines should be used
when making this assessment:
If an Application is used by multiple Organizations, it has high strategic value because of its
widespread use.
If an Application is used only internally by a single Organization, it is more likely of medium to low
strategic value.
This property is in effect a measure of the Application's value to the Agency as a whole and could be
termed "Agency Strategic Value."
Application Criticality - This property is related to Strategic Value in that it is a measure of the
importance of the Application. The following guidelines should be used when assigning a value to this
property:
The difference between Application Criticality and Strategic Value is that Application Criticality is
more of an internal assessment of the importance of an Application to the Organization that owns it
and of the Organization's ability to safely and effectively operate and perform its function.
An Application could be critical to the Organization that owns itwhich would give it an Application
Criticality rating of "High"but still have a "Low" or "Medium" Strategic Value because it is used
only internally by a single Organization and not more broadly across the Agency in support of a wider
array of Organizations.
Deployment Profile - This property characterizes the installation of the Application. The following
guidelines should be used when assigning a value to this property:
If an Application resides on several servers in a single server farm acting as a cluster and there are
several instances of it installed on each machine in the cluster, it should be flagged as "Single
Instance" because the cluster still functions as a single instance of the Application, which is merely
load-balanced to handle the number of users it must handle.
If an Application is distributed, it should still be flagged as "Single Instance."
If an Application is installed on various desktops or laptops (e.g., an MS-Access application installed
on many desktops), it should be flagged "Multiple Instances."
B-1
-------
Draft 2006 Architecture Standard and Guidance
June 9, 2006
If an Application is installed on multiple, geographically dispersed servers and is not considered
distributed but, in fact, these individual server instances are being used separately and are hosting
separate instances of a supporting database for the Application, the Application should be flagged
"Multiple Instances."
Application Accessibility - This property indicates whether an Application is available to the public and
has potential security ramifications. The following guidelines should be used when assigning a value to
this property:
If an Application is used by EPA only, it should be flagged "Agency Only."
If an Application is used by EPA and other Federal Agencies, it should be flagged "Intra-
Government."
If an Application is used by the public, industry, academia, or tribal, state, or local governments, it
should be flagged "Public."
B-2
------- |