2010 EA Conf_RA Track Presentation_20100506.ppt
-
Upload
thisisghostactual -
Category
Documents
-
view
216 -
download
0
Transcript of 2010 EA Conf_RA Track Presentation_20100506.ppt
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
1/47
Reference Architecture Track
Terry Hagle, Office of DoD CIO/AS&I703-607-0235
2010 EA Conference
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
2/47
Agenda
Enterprise Reference Architecture Cell (ERAC) Overview
Terry Hagle
Reference Architecture (RA)Steve Ring
Principles
Technical Positions Patterns
Enterprise-wide Access to Network and Collaboration
Services (EANCS) RANorm Minekime
DoD Information Enterprise Architecture (IEA)Al Mazyck
Purpose/Background Content
Application of the DoD IEA
Example EANCS RA
Compliance with the DoD IEA
Example EANCS RA 2
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
3/47
ERAC OVERVIEW
3
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
4/47
Enterprise Reference Architecture
Cell (ERAC)
Components have expressed the need for more detailed guidance
Enterprise patterns and processes
Army CIO/G-6 Comment on DoD IEA v1.1: establish a separate DoD IEA
Reference Architecture with sufficient granularity to enable interoperability
across the DOD IE/GIG. To foster such interoperability, these reference
architectures would need to include processes, process patterns and service
patterns, as well as service interfaces and metrics. Purpose:
Develop the reference architecture (artifacts)
Assist IT Decision Makers/Components/Programs/Solution Architects as
directed
Work as an advisor to the functional architect
Assist in the proper application of the DoD IEA, DoDAF and DARS Conduct architecture assessments as directed
Assess architecture compliance w/DoD IEA
Event Driven - Net Centric Reviews (ED-NCR)
JCIDS/DAS Milestone Reviews
Management:
ERAC funded by and resources managed by EA&S Taskings and guidance from the EGB/ASRG
4
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
5/47
Enterprise Reference Architecture
Mission Statement
The intent of Reference Architecture is to:
Normalize the institutional understanding of capabilities at
the enterprise level and provide a common set ofprinciples, patterns, and technical positionsfor use within
the DoD to guide development of Enterprise, Segment, or
Solution architectures.
Development of a Reference Architecture is aprocess that results in the required content
5
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
6/47
Reference Architecture
Description
Five components of a Reference Architecture:
Strategic Purpose
Describes the context, scope, goals, purpose, and intendeduse of the RA
Principles
High-level statements about the IT environment that tie backto business goals Incorporate values, organizational culture, and business goals Drive Technical Positions (and Patterns)
Technical Positions Statements that provide technical guidance (standards,
technologies, etc) for use with each major architectural
component or service Patterns/Templates
Diagrams that address the distribution of systems functionsand how they relate topologically
Models that show relationships between components specifiedby the Technical Positions
Vocabulary
Reference Architecture Description 6
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
7/47
ERAC Process for Developing RA
The ERAC leverages the six step architecture
development process of the DoDAF
The process steps are: Clarify Purpose(Architects & Architecture Owner)
Clarify Scope(Architects & Architecture Owner)
Identify key questions (Architects & Architecture Owner)
Determine required data/information (architects)
Collect and Organize data/information (architects collect
& organize, SMEs provide)
Analyze architecture data/information (architects)
Document the results (architects)
Use or apply results (Architecture Owner) 7
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
8/47
Proposed RA Product Structure
DoDAF Models to Be Developed:AV-1, AV-2, OV-1, OV-5a, OV-6a/c, and StdV-1
Overview and Summary Information (AV-1) Contract between Architecture Owner and Architect Guides development of the RA Executive level presentation of RA DM2: Vocabulary and Semantics
Reference Architecture Document Introduction (Content from AV-1) Context and Relationships (Resulting Principles) Term Definitions Architectural Patterns
Generic Standards and profilespolicy Use Case/Use Case Analysiso Implementation Specificso Specific Technical Standards and Profileso Deployment and Performance Considerations
8
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
9/47
http://cio-nii.defense.gov/sites/diea/
DoD IEA Website
9
http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/ -
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
10/47
REFERENCEARCHITECTURE
10
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
11/47
Purpose
DoD CIO intends to use Reference Architecture as a means to provide
Department-wide Guidance for architectures and solutions
Reference Architecture, as currently used within DoD
Is defined at different levels of detail and abstraction (from specific to
generalized) with Has little agreementand much confusion
Has multiple meanings relative to the context of the environment
To support the DoD CIO intent, a common definition of Reference Architecture
is needed that
Provides policyand directionto the DoD enterprise (commands, services,agencies) that guides and constrains architectures and solutions
Can be equally applied across the wide spectrum of DoD environments
IT/ Business and Service (SOA) domains
Warfighter domains
11
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
12/47
Objectives of a Reference
Architecture
Todirect, guide and constrain
architectures and solutions within a
domain
To serve as a reference foundation of
concepts, components and their
relationships
May be used for comparison andalignment purposes
Reference Architecture
Stakeholder
Requirements
Guides and
constrains thedevelopment of
Architectures
and
Solutions
Diagram derived from: The Importance of Reference Architecture, Architecture and Change (A&C), 2007,http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture 12
http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture/ -
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
13/47
Reference Architecture
is
an authoritative source of unambiguousarchitecture information within a domainenvironment
thatguides and constrains multiplearchitectures and solutions
by providingpatterns of abstractarchitectural elements, based on a strategic
purpose, principles, technical positions, together
with a common vocabulary. 13
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
14/47
Domain
Building a Reference Architecture
(The Five Components)
Reference Architecture Components
Principles
Patterns Vocabulary
Technical
Positions
StrategicPurpose
Architecture/
Solution
A
Guides ConstrainsAuthoritative
Source
Architecture/
Solution
B
14
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
15/47
DoDAF Models
Utilized in RAAV-1Overview & Summary Information
CV-1: Visionoverall strategic concept and high level scopeOV-1High Level Operational Concept Graphicwhat solution architectures are intended
to do and how they are supposed to do it
OV-6aOperational Rules Model
SvcV-10a Services Rules Model
SV-10aSystems Rules Model
OV-4Organizational Relationships Chartarchitectural
stakeholders
StdV-1Standards Profile
Operational Patterns
OV-2Operational Resource Flows
OV-5 {a,b}Activity diagrams
Service Patterns
SvcV-1Service Interfaces
SvcV-2Service Resource Flows
SvcV-4Service Functionality
SvcV-10bService State Transitions
System Patterns
SV-1System Interfaces
SV-2 System Resource Flows
SV-4System Functionality
SV-10bSystem State Transitions
Event-Based Scenario Patterns of Dynamic
Behavior
OV-6cEvent-Trace Description
SvcV-10c Services Event-Trace Description
SV-10cSystems Event-Trace DescriptionAV-2Integrated Dictionary- definitions of terms used throughout solution architectures
Strategic Purpose
TechnicalPositions
Principles
Patterns
15
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
16/47
Benefits
Authoritative source of architecture information within aproblem space that guides and constrains architectures andsolutions
Simplifies and standardizes solutions for complex problems by
providing common repeatable patterns
Provides early, focused guidance at a sufficient level of
abstraction and detail before concrete implementation
decisions are known
A tool to ensure interoperable architectures and solutions
based on common guidance
16
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
17/47
First Usage:EANCS Reference Architecture
Supports development of
EANCS implementation
guidance and solution
architectures focuses on that por t ion of thecharacter is t ic deal ing with glo bal
authent icat ion, auth or izat ion and
access co ntro l to g lobal ly
accessible resources. It is in tended
to gu ide the developm ent ofsolut ion archi tec tures and sup por t
the development of specif ic
imp lementat ion guidance for
achieving this capabi l i ty.
Department of Defense
Enterprise-wide Access to Network and
Collaboration Services (EANCS)
Reference Architecture
Version 3.0
December 2009
Prepared by the Office of the DoD CIO 17
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
18/47
Enterprise-wide Access to
Networks and CollaborationServices (EANCS) Reference
Architecture (RA)
18
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
19/47
EANCS RABackground
Operational Requirements GIG 2.0 Operational Reference Architecture (ORA) describes requirement for
Global Authentication, Access Control, and Directory Services
Vice Chairman Joint Chiefs of Staff (VCJCS) directed ability to go anywhere [in
DoD], login, and be productive
EANCS RA to address these requirements by: Providing basis for implementation guidance/roadmap for Enterprise Services
Security Foundation (ESSF)
Describing Authentication and Authorization and Access Control to networks
(NIPRNet and SIPRNet) and designated Enterprise Services (e.g., Enterprise
Directory Service, Enterprise e-mail, DCO, Intelink) Supporting implementation of an initial authentication and access control
capability in 6 to 9 months for Enterprise User Initiative
Leveraging:
Common credentials for authentication (PKI/CAC for NIPR, PKI/hard-token for SIPR)
Authoritative identity attributes for authorization and access control (Attribute-BasedAccess Control)
19
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
20/47
EANCS RAPurpose and Scope
Purpose
Gain Department-wide consensus on requirements for authenticating users and
authorizing user access to DoD Information Enterprise (IE) and, more
specifically, to representative collaborative services, to include portals and
enterprise e-mail
Describe architectural patterns to guide, standardize, and enable the most rapid
and cost-effective implementations of an authentication and authorization
capability in support of secure information sharing across DoD
Scope
To
Be Architectural Description Document requirements, activities, and information for authentication and
authorization and access control
Document standard/common authentication and authorization and access
control processes
20
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
21/47
EANCS RADevelopment Approach
Architecture Owner organized Working Group (WG) Composed of SMEs from ASD (NII)/CIO, Military Services, Joint Staff/J6,
Defense Manpower Data Center (DMDC), Defense Information Systems Agency
(DISA), and National Security Agency (NSA)
Team members represented their stakeholder organizations
Architecture Owner worked with ERAC to establish RA purpose,perspective, and scope
WG developed Concept of Operations (CONOPS) for context
WG provided necessary architecture data/information
Existing documents served as knowledge baseline
SME knowledge and experience provided rest of information
ERAC organized collected data into DoDAF-compliant RA description
WG approved RA content (Dec 2009)
Submitted to Architecture and Standards Review Group (ASRG) for
approval and federation into DoD EA 21
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
22/47
EANCS RASources
Federal
ICAM
ESSF
GIG 2.0
ORA
EANCS
RA
EANCS
CONOPS
USE
CASES
ESM
IMP
PLANIMP
PLANIMP
PLAN
Process &
Function
Operational
Requirements
- Patterns
- Rules
- Technical
Positions
- Operational
Requirements
- Implementation
Considerations
Provide
Analysis
- NIPRnet- SIPRnet
- Deployed User
-Unanticipated
User
-Maritime User
-VPN
-???
Service
Descriptions
- 6 to 9 months
- Longer Period
- Impacts
- Metrics
- Guidance
What To Do How To Do It 22
Legend ESSFEnterprise Security
Services Framework
ESMEnterprise Security
Management
ICAMIdentity, Credential, and
Access Management
ORA -Operational Reference
Architecture
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
23/47
EANCS RA
Arch i tectu re Art i facts
23
OV-1 (Concept
Consumer & Provider)
OV-5a (Activity
Decomposition)
OV-6a (Operational
Rules Model)
OV-6c (Event-Trace
Description)
EANCSRADocument
Department of Defense
Enterprise-wide Access to Network and
Collaboration Services (EANCS)
Reference Architecture
Version 3.0
December 2009
Prepared bythe Officeof the DoDCIO
-
GROUP TYPE NAME DESCRIPTION
OMB Policy M-04-04 This guidancerequires agencies to review new
and existingelectronic transactions to ensure
that authentication processes provide theappropriate level of assurance. It establishes and
describes four levels ofidentityassurance for
electronictransactions requiringauthentication.
Assurancelevels also provide abasis for
assessingCredential ServiceProviders (CSPs)on behalf ofFederal agencies. This document
will assist agencies in determiningtheir e-
government needs. Agencybusiness-process
owners bear theprimaryresponsibility to
identifyassurance levels and strategies forprovidingthem. This responsibility extends to
electronicauthentication systems.
OMB Policy M-05-05 This memo requires the useof ashared service
providerto mitigate the risk of commercial
managed services for publickey infrastructure
(PKI) and electronicsignatures.
OMB Policy M-05-24 This memorandum provides implementing
instructions forHSPD-12 and FIPS-201.
OMB Policy M-06-18 This memorandum provides updated direction
forthe acquisition of products and services for
the implementation ofHomeland Security
Presidential Directive-12 (HSPD-12) Policyfor
aCommon Identification Standard forFederalEmployees and Contractorsand also provides
status of implementation efforts.
Presidential
Directive
Policy HSPD-12 HSPD-12 calls foramandatory, government-
widestandard for secureand reliable forms of
ID issued bythe federal government to its
employees andemployees of federal contractors
foraccess to federally-controlled facilities andnetworks.
NIST Guidance SP 800-87 This document provides the organizational codes
forfederal agencies to establish the FederalAgencySmart Credential Number(FASC-N)
that is required to beincluded in the FIPS 201
Card HolderUnique Identifier. SP 800-87 is a
companion document to FIPS 201.
StdV-1 (Standards
Profile)Provides Department-
level guidance for
implementation of
common access
control elements
ArchitectureFederation
Enterprise-wideAccessto NetworkandCollaborationServices
ReferenceArchitecture
OverviewandSummaryInformation(AV-1)
1Architecture ProductIdentification
1.1Name: Enterprise-wideAccessto Networkand CollaborationServices (EANCS)
1.2LeadOrganization: Department ofDefenseDeputyChiefInformationOfficer. The
EnterpriseServicesReviewGroup(ESRG), as thearchitectureowner, isresponsiblefor
architecturecontent and will provideoverall coordinationto ensureappropriate
stakeholdersandsubject-matterexpertsare available; theEnterpriseReference
ArchitectureCell (ERAC), withoversight fromthe ArchitectureandStandardsReview
Group(ASRG), will support thedevelopment of appropriatearchitectureartifacts.
1.3Approval Authority: DoD CIOEnterpriseGuidanceBoard(EGB)
2Purpose andPerspective
2.1Purpose. AReferenceArchitecture(RA)abstractsandnormalizestheinstitutional
understandingofcapabilitiesat theenterpriselevel, andprovidesa commonset of
principles, technical positions, andpatternsforusewithinthe DoDtoguide development
ofEnterprise, Segment, orSolutionarchitectures.
AV-1 (Overview and
Summary)
Strategic
PurposePrinciples
Patterns Technical
Positions
AV-2 (Integrated
Dictionary)Vocabulary
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
24/47
Compliance
with DoD IEA
Development of RA guided by
Departments Net-centric vision to
function as one unified DoD
Enterprise, creating an informationadvantage for DoD, its people, and
its mission partners, as described in
DoD IEA
Alignment with DoD IEA built-in
during RA development IAW DoD
IEA Appendix D Compliance with DoD IEA
documented in IAW DoD IEA
Appendix E
24
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
25/47
DoD Information EnterpriseArchitecture (IEA)
25
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
26/47
Purpose
Unify the concepts embedded in the DoDs net-centric strategies into a common vision
Drive common solutions and promote consistency
Describe the integrated Defense Information
Enterprise and the rules for information assets andresources that enable it
Foster alignment of DoD architectures with the
enterprise net-centric vision
DoD Net-centric Vision
To function as one unified DoD Enterprise, creating an information advantage
for our people and mission partners by providing:A rich information sharing environment in which data and services are visible,
accessible, understandable, and trusted across the enterprise.
An available and protected network infrastructure (the GIG) that enables responsive
information-centric operations using dynamic and interoperable communications
and computing capabilities. 26
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
27/47
Background
Major Net-Centric Strategies
DoD IEA v1.0 (Approved 11 April 2008)
Established five priority areas for realizing net-centric goals
Provided key principles, rules, and activities for priority areas
Positioned as a tool to guide the net-centric transformation of the
Information Enterprise (IE)
DoD IEA v1.1 (Approved 27 May 2009)
Describes a process for applying the DoD IEA content (App D)
Describes compliance areas and criteria (App E)
Provides activity mapping between the DoD IEA and the NCOW RM(App F)
27
Data (9 May 2003) Spectrum Management (3 Aug 2006)
Services (4 May 2007) NetOps (February 2008)
Information Assurance (26 April 2006) Communications/Transport
Computing Infrastructure (September 2007) Information Sharing (4 May 2007)
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
28/47
Audience &
Intended Use
IT Architects
Align architecture with the DoD IEA
Apply DoD IEA content (rules, activities, etc) to guide and
constrain information enterprise solutions
Managers of IT Programs (PM, PEO, etc.)
Use the DoD IEA to support program design, development, and
implementation
Through solution architectures properly aligned with the DoD IEA
IT Decision-Makers (CPM, IRB, CIO, etc.)
Use the DoD IEA to support investment decisions
Through enterprise and solution architectures properly aligned
with the DoD IEA
28
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
29/47
Adds DoD EA Compliance Requirements (Appendix G)
Compliance with DoD IEA
Compliance with Capability and Component EAs
Compliance with the DISR
Compliance with Mandatory Core and Shared Designated DoD
Enterprise Services (ES)
Architecture Registration Requirements
Provides a table of Mandatory Core and Shared DesignatedDoD ES
Adds content to the Rules, App D, and App E to maintain
consistency with App G
DoD IEA v1.2
(Draft)
29
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
30/47
Applying the DoD IEA
(Appendix D)
30
Applying the DoD IEA
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
31/47
Applying the DoD IEAEstabl ish Net Cent r ic
Context fo r EANCS RA
31
Consumer/
User
Perspective Identify DoD IE Perspective for
Architecture
Develop Net-Centric OperationalConcept
Provider/
Producer
Perspective
Understand Net-Centric Concepts
Align with Net-Centric Vision
Identify Net-Centric Assumptions
Align with JCA Taxonomy
Net-Centric Assumptions
Portable identity credentials will be used to
support user authentication
Authorization attributes have already been
defined, collected, regularly updated, and madeavailable through standard interfaces from
reliable attribute sources
Relevant DoD IEA Priority Areas
Secured Availability (SA)
Data and Services Deployment (DSD)
Relevant JCAs
Net-Centric/Enterprise Services/Core
Enterprise Services/User AccessNet-Centric/Information Assurance
OV-1 (Operational
Concept Graphic)
Applying the DoD IEA
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
32/47
Applying the DoD IEAA l ign EANCS RA
Desc r ipt ion w ith DoD IEA
32
Align Operational Activities and
Processes with related DoD IEA
Activities
Incorporate applicable DoD
IEA Principles
Apply DoD IEA Rules
Use net-centric
terminology in
architecture
description
Guiding Principles and Rules for RA
Data assets, services, and applications on the GIG shall be visible, accessible, understandable, and trusted
to authorized (including unanticipated) users. (DoD IEA, GP 03)
Global missions and globally dispersed users require global network reach. Information Assurance
mechanisms and processes must be designed, implemented, and operated so as to enable a seamless
Defense Information Enterprise. (DoD IEA, SAP 03)
Authoritative data assets, services, and applications shall be accessible to all authorized users in the
Department of Defense, and accessible except where limited by law, policy, security classification, or
operational necessity. (DoD IEA, DSDR 01)
All DoD information services and applications must uniquely and persistently digitally identify and
authenticate users and devices. These services, applications, and networks shall enforce authorized accessto information and other services or devices according to specified access control rules and quality of
protection requirements for all individuals, organizations, COIs, automated services, and devices. (DoD IEA,
SAR 07)
OV-6c (Event-Trace
Description)
Oversee
Authentication
Initiatives
Manage
Authentication
Processes
A2.8.4
A2.8.4.1
Oversee
Privilege Mgmt
Initiatives
A2.8.5
Constrain
DoD IEA Terminology
DoD Net-Centric Vision
DoD IE Perspective
User/Consumer
Producer/Provider
Priority Areas
Data and Services Deployment
Secured Availability
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
33/47
Compliance with the DoD IEA
(Appendix E)
Compliance is about conveying the application of DoD IEA
Principles, Rules, and Activities
Use the process described in App D and provided in App E,
Tab A
Questions that expose the compliance process and application
of DoD IEA content are captured in the Enhanced ISP tool
Assessment of compliance is based on: Completed Compliance table
ISP and Architecture
EISP Report
33
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
34/47
Compliance w/the DoD IEA
34
Tab A to Appendix E: DoD IEA Compliance Assessment TableB. Align Architecture Description with the DoD IEA
B1. Use Net-
Centric
Terminology
2.3.2.1.1 Use key terms
contained in
the DoD IEA
Glossary
across
architecture
descriptions.
2.1.1.2.1 Describe
applicable
DoD IEA
key terms.
Describe in
the:
- AV-2
Integrated
Dictionary.
- Related
taxonomies.- ISP
descriptions
of the IE.
Q12 - Identify key
terminology from the
DoD IEA used in your
architecture/program
documents.
B2.
Incorporate
Applicable
DoD IEA
Principles
2.3.2.2.1 - Identify
applicable
DoD IEA
Principles and
use in
architecturedescriptions to
place
restrictions or
limitations on
operations.
- Use
applicable
Principles
2.1.1.2.2 Describe
DoD IEA
Principles.
Describe in
the:
- OV-1
Operational
Concept.
- OV-5Operational
Activity
Model.
- Process
Models
Q13 - Which DoD IEA
Principles apply to your
Program?
Q14 - How do the
Principles apply to your
Program?Q15 - How are the
applicable Principles
addressed in your
architecture/program
documents?
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
35/47
Compliance with the DoD IEAEANCS RA Example
35
Incorporated description of key alignment aspects into RA
document
Added section describing RA alignment with JCAs and DoD IEA
Priority Areas
Added text descriptions of how process patterns align with DoD IEA
activities into pattern discussions
Filled out Tab A Compliance Matrix for RA
Developed eISP excerpt for RA
Used Guidance for DoD Information Enterprise Architecture in
EISP 2.0 to identify and locate DoD IEA questions to be answered
Incorporated information and text from RA document
Generated compliance matrix using Xml2PDF 2007 application and
ISP_DoD_IEA_Compliance_Table style sheet
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
36/47
Initiatives and Projects
Reference Architecture Description
Comment Adjudication for ASRG Approval
DoD IEA
Comment Adjudication (v1.2) for DCIO Approval
Work on future versions of the DoD IEA
EANCS RA
Delivered to owner; now in FAC/ASRG approval process
Document Process for Developing RA
Describe the process used to develop the EANCS RA
FEA BRM Extension
Extend DoD LOBs for the FEA BRM
Recommended changes provided to OMB FEA for action36
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
37/47
DoD IEA Site:
http://cio-nii.defense.gov/sites/diea/
Questions?
37
http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/http://cio-nii.defense.gov/sites/diea/ -
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
38/47
BACKUP SLIDES
38
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
39/47
Information Enterprise
Services and Infrastructure
Architecture
23 November 2013
IE Service/Infrastructure Context Diagram
DRAFT
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
40/47
Human Computer InteractionWarfighterWarfighter
DefenseIntel
DefenseIntel
NetOpsNetOpsMissionPartnersMissionPartners
BusinessBusiness
IA InfrastructureDynamic Policy Management
Assured Resource AllocationMgmt of IA Assets and Mechanisms
NetOps Infrastructure Enterprise Management
Content Management Net Assurance
Functional Capability Enterprise Services
Mandatory Core & Shared Enterprise Services (ES)
Computing & Communications Infrastructure
Enterprise Services Security Foundation
Information SharingMessaging Portal
Collaboration Mediation
Content Delivery
Enterprise ManagementServices Management
Resource Management
Content Handling
IE Service/Infrastructure Context Diagram
40
DiscoveryPeople/Service Discovery
Content Discovery
Metadata DiscoveryGeospatial Visualization
Mission
&Business
IT
Enterprise
Services
&
Infrastructure
Digital Identity Privilege
Management
Credentialing Authentication Authorization
& Access
Auditing &
Reporting
Cryptography Configuration
Management
Computer
Network Defense
COOP/CIP
Force
Application
Portfolio
Building
Partnerships
Portfolio
Battlespace
Awareness
Portfolio
Protection
Portfolio
Corporate Mgmt
& Support
Portfolio
Force Support
Portfolio
Command &
Control Portfolio
Logistics
Portfolio
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
41/47
Use Enterprise Services Framework to
Organize and Focus ES Efforts
Enterprise Services Security Foundation (ESSF)41
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
42/47
Use ESSF Segment Architecture to Organize and
Focus Security Efforts
42
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
43/47
Development Approach
Describe the components of the context diagram
Build use cases based on GIG 2.0 Attributes to establish relationships
between its functional components (Mandatory Core & Shared Enterprise
Services)
Global Authentication, Access Control, and Directory Services
Information and Services From The Edge Joint Infrastructure
Common Policies and Standards
Unity of Command
Analyze use cases through identification, sequencing, and prioritization of
functional components to develop key or foundational Services first Apply analysis to prioritize and manage:
Reference Architecture Development (Principles, Technical Positions,
Patterns)
Sequence and Monitor Initiatives, Projects, and Programs
Identify Issues, Gaps, and Shortfalls43
Apply Enterprise Services &
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
44/47
Apply Enterprise Services &
Infrastructure to GIG 2.0
Requirements through Use Cases
44
Enterpr
ise
ServicesF
oundation
Enterprise
Security
ServicesFoundation
Computing & Communications Infrastructure
C ll b ti S i
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
45/47
User
45
Local Access
Request (Logon)
End User Device
(EUD)
Authorization
DecisionRequest
ESSF Authentication
ESSF Digital
IdentityESSF Credentialing
Credential
Validation
Response
Identity
Information
Secondary
Authentication
(if required)ESSF Authorization
& Access Control
Mission Manager
Environmental
Data Response
User
Attribute
Response
ResourceAccess
Policy
Response
Policy
Management
Portable
Identity
Credential
Identity Updates
+ Authentication
Factors Authentication
Decision
Response
Resource
Metadata
Response
Policy
ConstrainedAccess
Printer
Capability
Storag
e
Office Automation
Applicationse-Mail
Collaboration
Document
Sharing
Portal
Enterprise
Directory Desktop/
Browser
Indicates Dependency
Collaboration ServicesUse Case Example
(EANCS)
http://extensions.services.openoffice.org/taxonomy/term/5http://extensions.services.openoffice.org/taxonomy/term/3http://extensions.services.openoffice.org/taxonomy/term/2http://extensions.services.openoffice.org/taxonomy/term/1 -
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
46/47
Sample Use Case (Content Request)
User
Porta
l
Information Sharing
Enterprise Services Security Framework
Authenticatio
n
1
2
Discovery
Enterprise
Management
Content
Discover
y3
Content
Mgmt
Mediation
ContentDelivery
4
Authorization &
Access Control
5
6
78
9
10
Infrastructure
46
IE Service/Infrastructure Context Diagram
DRAFT
-
8/13/2019 2010 EA Conf_RA Track Presentation_20100506.ppt
47/47
Human Computer InteractionWarfighterWarfighter
DefenseIntel
DefenseIntel
NetOpsNetOpsMissionPartnersMissionPartners
BusinessBusiness
IA InfrastructureDynamic Policy Management
NetOps Infrastructure Enterprise Management
Functional Capability Enterprise Services
Mandatory Core & Shared Enterprise Services (ES)
Computing & Communications Infrastructure
Force
Application
Portfolio
BuildingPartnerships
Portfolio
BattlespaceAwareness
Portfolio
ProtectionPortfolio
Corporate Mgmt
& Support
Portfolio
Force Support
Portfolio
Command &
Control Portfolio
Logistics
Portfolio
Enterprise Services Security Foundation
Information SharingMessaging Portal
Collaboration Mediation
Content Delivery
Enterprise ManagementServices Management
Resource Management
Content Handling
g
DiscoveryPeople/Service Discovery
Content Discovery
Metadata DiscoveryGeospatial Visualization
Mission
&Business
IT
Enterprise
Services
&
Infrastructure
Digital Identity Privilege
Management
Credentialing Authentication Authorization
& Access
Auditing &
Reporting
Cryptography Configuration
Management
Computer
Network Defense
COOP/CIP
EANC
S RA
EU
ITI Opt
Arch
AD Opt
Arch
SAR SA