1. VERSION 15
4/22/ :02
DoD-CIO/ASD-NII Enterprise Architecture & Standards Directorate Presentation to DAU IRM Class Level III 28 July 2008
Walt Okon
Chief Architect, DoD Information Sharing

2. Agenda Introduction/Overview DoDAF 2.0 Development
Architecture Federation
DoD Standards (DISR/ICISR/FISR)
DoD Architecture Training
DoD Technical Direction
DoD Information Sharing Environment
DoD Enterprise Architecture Conference
Questions/Wrap-Up

3. DoDAF 2.0 Development The Vision and the Effort

4. Key Policies Requiring DoDAF
VERSION 15
Key Policies Requiring DoDAF
4/22/ :02
Joint Staff
CJCSI F, 1 MAY 2007, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”
CJCSM C, 1 MAY 2007, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”
CJCSI D, 8 MAR 2006, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS”

5. DoDAF Evolution To Support “Fit For Purpose” Architecture
VERSION 15
DoDAF Evolution To Support “Fit For Purpose” Architecture
4/22/ :02
DoDAF 1.0
CADM Separate
Baseline For DoDAF 1.5
Removed Essential & Supporting Designations
Expanded audience to all of DoD
(Published in 2003)
DoDAF 1.5
Addresses Net-Centricity
Volume III is CADM &
Architecture Data Strategy
Addresses Architecture Federation
Baseline for DoDAF 2.0
Shifted away from DoDAF mandating
a set of products
(Published in 2007)
DoDAF 2.0
Cover Enterprise and
Program Architecture
Emphasize Data versus
Products
Tailored Presentation
AV-1 to capture federation
metadata
Quality Support to Decision
Processes
FEA & Allied/Coalition
Support
Journal
- Errata & Interim Releases
DoDAF
2.0
(To Be Published)
(Late 2008)

6. Net-Centric Concepts addressed in DoDAF 1.5
VERSION 15
Net-Centric Concepts addressed in DoDAF 1.5
4/22/ :02
The following Net-Centric Concepts were presented and discussed to be included in DoDAF 1.5
Populate the Net-Centric Environment
Represent what information and capabilities are being made available (as services) to the NCE so they can be leveraged by others.
Utilize the Net-Centric Environment
Represent what information and capabilities provided on the GIG will be available to service consumers through service discovery and leveraged across the NCE.
Support the Unanticipated user
Represents that 1) capabilities can scale to support both human and system unanticipated users, and 2) the posting of information, data, applications and services to the NCE occur as soon as possible to enable multiple use.
Leverage COIs to promote Jointness
Represents the utilization of COI specific interface specifications, taxonomies, and common vocabulary to support interoperability in the NCE.
Support Shared Infrastructure
Represents that the shared physical and services infrastructure (the EIE) is identified and leveraged in the NCE.

7. Volume II Net-Centric Example
VERSION 15
Volume II Net-Centric Example
4/22/ :02
“5.4.3 Net-Centric Guidance for SV-4b
Augmented Product Purpose. In a net-centric architecture, the SV-4b is used to document
service functionality that is exposed to the NCE, their respective grouping into service families,
and their service specifications. It is the SV counterpart to OV-5. Although there is a correlation
between OV-5 or business-process hierarchies and the service functional hierarchy of SV-4b, it
need not be a one-to-one mapping, hence, the need for the Operational Activity to Services
Traceability Matrix (SV-5c), which provides that mapping.
Net-Centric Product Description. The SV-4a traditionally describes system functions and
the flow of system data between functions and correlated to SV-1 and SV-2 systems. In the NCE,
the SV-4b should capture and depict how services are orchestrated together to deliver
functionality associated with an operational need. In industry, this is often referred to as
composeable applications.
Services are a key means to share information and capabilities in the NCE and can be
captured in the SV-4b by relevant service groupings or families to assist in understanding how a
set of services align with an operational domain or a system capability. The SV-4b also
documents the data flows between services and may represent external services, systems, or
humans that interact with the service. Multiple SV-4b products can be utilized to show deeper
levels of detail as system nodes are decomposed into service families which further decompose
into services that consist of specific operations and data.
In the NCE, services require robust and consistent descriptions to operate in the NCE where
service capabilities are discoverable and able to be consumed in a scalable and flexible manner.
The SV-4b should capture and depict information about each service that collectively represents
the service specification. A service specification should be provided for each service that is or
will be provided to the NCE. The service specification enables services to be documented in a
consistent manner, and the DoD-wide SST should be used to the extent possible for describing
each service. Regardless of the precise SST, the necessary minimum subset of information from
the SST for each service must be captured in the SV-4b:
- Interface Model Category includes information of the service specification that identifies the service and enables service consumers to discover the service and determine the service’s suitability for their needs. It also provides assistance in the usage of the service, and includes service policies and the following types of attributes:
- Service Name is a short descriptive name for the service to be provided and
as it appears in the SV-1…”
Document service functionality that is exposed to the NCE
Capture and depict how services are orchestrated together to deliver functionality
Services are a key means to share information and capabilities in the NCE
Document data flows between services
Service Specification Template
Service
Specifications

8. Three Integrated Volumes
VERSION 15
Three Integrated Volumes
4/22/ :02
Net-Centricity Sources & Prioritization
Decision Support Processes
Survey, SME interviews, Feedback
Workshop Inputs
State of DOD Architecting
Architecture
Data Strategy
CADM 1.5
Federation Strategy
Volume I
Volume II
Volume III

9. DoDAF v1.5 Stakeholder Feedback
VERSION 15
DoDAF v1.5 Stakeholder Feedback
4/22/ :02
Service Oriented Architecture
ABM/ASM
Other Frameworks
Net-Centric Examples
Service Specification Template
Capability related concepts
Service Interfaces
Service Description Framework
UPDM
Net-Centricity
Measurement concepts
Operational Node
Program vs. Enterprise Architecture Content
Strategic Goals
Relationship to FEA
Information Assurance/Security
SA and OO
Architecture Tiers
Relationship to NCOW RM
BPMN
Alignment to JCIDS/JROC
Authoritative Sources

10. Vision Statement for the DoDAF v2.0
VERSION 15
Vision Statement for the DoDAF v2.0
4/22/ :02
To enable the development of architectures that are meaningful, useful, and relevant to the DoD Requirements, Planning, Budgeting, Systems Engineering, and Acquisition decision processes.

11. Definition for the DoD Architecture Framework
VERSION 15
Definition for the DoD Architecture Framework
4/22/ :02
The DoD Architecture Framework is the structure for organizing architecture concepts, principles, assumptions, and terminology about operations and technology into meaningful patterns to satisfy specific DoD purposes.

12. DoDAF 2.0 Development Organizational Structure
VERSION 15
DoDAF 2.0 Development Organizational Structure
4/22/ :02 EA
Summit
CIO Executive Board
Core
Management
Group
Development Team
DoDAF Plenary
SE Workshop
DAS Workshop
JCIDS Workshop
PfM/CPM Workshop
PPBE Workshop
Operations Workshop
Data
Working
Group
ARMY*
Method
Working
Group
BTA*
Presentation
Working
Group
OUSD(P&RM)*
* Led and Staffed by Component Representatives

13. Focused on DoD Decisions
VERSION 15
Focused on DoD Decisions
4/22/ :02
Cost View
Capability View
SE View
Acquisition etc.
Architecture
Views
“Fit for Purpose”
DoD Core Decision Processes
PPBE/PfM
JCIDS
DOTLMPF
Acquisition
Systems Eng M C E P
Federated Architectures
E – Enterprise
M – Mission Area
C – DoD Component
P - Program
Architecture IT
Technology
Governance
Link Technology to Objectives
Institutionalize IT Best Practices
Protect digital assets

14. DoDAF V2.0 DoDAF Metamodel (DM2)
VERSION 15
4/22/ :02
Fit For
Purpose
Presentation
Dashboards
Graphical
Depictions
Reference
Models
Fusion
Products
Composite
DoDAF V2.0
DoDAF V1.5
Standards
View
Operational
Rest of OVs
All TVs
All
All AVs
Systems
View
All “Systems”
Versions of
SV Products
Data &
Information
View
OV-7
Net-Centric
SV-11
All “Service”
Versions of
SV Products
DoDAF Metamodel (DM2)
DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions.
In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.).
Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience.
DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues.
BUILD ONE:
The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose
The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations
All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views.
BUILD TWO:
The new Systems view better accommodates our legacy system descriptions.
The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services.
The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.
The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective.
BUILD THREE:
The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both.
Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View.
There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker.
Capability
View
Project
System
Engineering
New
Updated
Moved

15. DoDAF 2.0 Perspectives Operations Perspective Technology
What needs to be done.
Who does it.
Information required to do it.
Systems, Services, and Technical Standards
that support or enable getting things done.

16. DoDAF 2.0 Views Capability View Operational View
VERSION 15
4/22/ :02
VERSION 15
4/22/ :02
DoDAF 2.0 Views
Capability View
Articulate the capability requirement, delivery timing, and deployed capability
Operational View
Articulate operational scenarios, processes, activities & requirements
System Engineering View
Articulate activities to design and implement solution based on operational and capability requirements
Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts
Standards View
Overarching aspects of architecture context that relate to all views
Common View
Articulate the data relationships and alignment structures in the architecture content
Data and Information View
Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process.
Project View
Net-Centric View
Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions
Systems View
Articulate the legacy systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions CT 16 16

17. VERSION 15
4/22/ :02
DoDAF Metamodel 17

18. Metadata Registration Service
Federation Client
Services Menu
DARS
Federated Catalog
DARS Federation Web Services
Register Provider
View Provider
Update Provider
Register Metadata
Search Holdings
SOAP
DDMS +
Metadata
(XML)
AV-1 metadata
captured and extracted
by repository/tool
environment
Federation Web services
Federation
Client
Federation
Repository
Repository/Tool
Environment

19. “Fit for Purpose” Architecture Descriptions

20. Notional DoDAF v2.0 Development Schedule (cont)
VERSION 15
Notional DoDAF v2.0 Development Schedule (cont)
4/22/ :02
2nd
QTR 08
3rd
QTR 08
QTR 08
4th
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
EA Summit
23 Jan 08
EA Conf
14-19 Apr
Approval
DoD CIO
Plenary
22 July
Vwendor
Tool Session
Develop
Writing
Technical Editing
Cood
Plenary
1 Apr
PfM WS
PPBE WS
Feb 08
Post to
DARS
Validation
SPIRAL II
4 Apr 08
SPIRAL III
27 Jun 08
SPIRAL IV
12 Sep 08
Phase I
Phase II
Phase III

21. VERSION 15
Points of Contact
4/22/ :02
OSD
Brian Wilczynski
Alan Golombek
Walt Okon
Michael Wayson
Scott Badger
Mike McFarren
CADM
Francisco Loaiza
Forest Snyder
REQUIREMENTS BASELINE
Charles Thornburg
Hilda Pineda
SOO
Tracy LaRochelle
SCHEDULE
Craig Cromwell
Tracy LaRochelle
DARS
Bruce Dunn
DEV-T LEAD
DEV-T SECRETARIAT

22. Federated Architectures The Connection

23. What the Operator Sees Today
VERSION 15
What the Operator Sees Today
4/22/ :02

24. What the Operator Expects to See
VERSION 15
4/22/ :02

25. A Federation of Data Producers
VERSION 15
A Federation of Data Producers
4/22/ :02
Federation
Strategy
Reporting (OMB, GAO, etc)
DARS
DoD EA
Reference Models
CADM
DoDAF
NCOW RM
MILDEP
COCOM
AGENCY
COI x
COI y
DATA
REQTS.
COI = Community of Interest
CADM = Core Architecture Data Model
DoDAF = DoD Architecture Framework
NCOW RM – Net-Centric Operations & Warfare Reference Model
DoD Decision Processes

26. Architecture Federation
VERSION 15
Architecture Federation
4/22/ :02
- Completed
- In Process
- Planned
DoD Architecture Federation (Notional) M I S O N A R E D P T
GIG Architectural Vision
DoD EA
RMs
NCOW RM C G
JCA
BEA
4.1
COMMS
TAMD
(ES, IA, CI)
Business
Warfighter
Defense
Intelligence
Enterprise Information Environment
WIN-T
ARMY
NAVY
AIR FORCE
OSEA
COCOMS & Agencies
JTRS
JTF HQ
GLOBAL C2
TSAT
DCGS – A
NECC
LandWarNet
GIG Capability
Increments
DISR
JDDA
IA Component
of the GIG
DON EA Coordination Board
METOC
HRM EA
USMC EA Efforts
MCASE MAGTAF
FORCEnet
GCSS USMC
CAC2S
NMCI
DJC2
Navy ERP
GCCS M
JC2
AENIA
LIAA C2
Constellation
Discovery and Information Sharing
What is Available?
Who Owns the Content?
Where is it Located?
What is the Current Status?
What Tool was it Developed in?
What Level of Detail?
Working Draft Pre-decisional

27. DoD EA Federation Strategy Completed
VERSION 15
DoD EA Federation Strategy Completed
4/22/ :02
Available on DARS Website:

28. GIG Architecture Enterprise Services in Use
VERSION 15
GIG Architecture Enterprise Services in Use
4/22/ :02
DARS
Federated Catalog
NCES Federated
Search Client
Title
C2C Architecture
Other
Federated Catalogs
Federated EA
Catalogs
Search
Results
Creator
AFC2ISRC
STRATCOM
Hanscom
Identifier (URL)

29. DoD EA Federation Pilot
VERSION 15
DoD EA Federation Pilot
4/22/ :02
Participants:
BTA USTRANSCOM Army
DARS Marine Corps Navy
Air Force Joint Staff – J6I
- Completed
- In Process
- Planned
DoD Architecture Federation M I S N O A R E D P T
GIG Architectural Vision
DoD EA
RMs
NCOW RM C G
JCA
BEA
4.1
COMMS
TAMD
(ES, IA, CI)
Business
Warfighter
Defense
Intelligence
Enterprise Information Environment
WIN-T
ARMY
NAVY
AIR FORCE
OSEA
COCOMS/ Agencies
JTRS
JTF HQ
GLOBAL C2
TSAT
DCGS – A
NECC
LandWarNet
GIG Capability
Increments
DISR
JDDA
IA Component
of the GIG
DON EA Coordination Board
METOC
HRM EA
MCASE MAGTAF
USMC EA Efforts
FORCEnet
GCSS USMC
CAC2S
NMCI
DJC2
Navy ERP
GCCS M
JC2
AENIA
LIAA C2
Constellation
Objectives:
Develop a Component value proposition to test through architecture federation (Use Case)
Use Registration and Discovery services (GAES)
Federate the items in the “Table” Graphic (minimum)
Validate federation process and tools (technical)
Validate usefulness of federation (use cases)
Issue federation implementation guidance

30. DoD EA Federation Pilot Use Cases
VERSION 15
DoD EA Federation Pilot Use Cases
4/22/ :02
BTA/USTRANSCOM/Marine Corps:
Federate the BEA with JDDA and Marine Corps Logistic architectures and register in DARS to gain visibility into “end to end” logistics process
Army:
Create a “knowledge base” through architecture federation for Army communities.
Test tools and concepts through federation, i.e. social networking (ontology development, semantic indexing,) architecture data analysis, UPDM applicability
Air Force:
Establish interface and search capability between DARS and AFARS. Demonstrate search capability
Navy:
Implement and use procedures outlined in the GIG Enterprise Architecture Federation Strategy and DARS CONOPS to create a repeatable federation process
Joint Staff/J6I:
Identify interface points and alignment between Mission Area-level architectures to obtain enable a horizontal view across mission areas and drill down to Program level.
DARS:
Develop registration template for AV-1 and DDMS metadata

31. Points of Contact OSD: DoDAF & Architecture Federation
VERSION 15
Points of Contact
4/22/ :02
OSD: DoDAF & Architecture Federation
Brian Wilczynski
Walt Okon
Alan Golombek
Michael Wayson
Scott Badger
DARS
Bruce Dunn
Tracy LaRochelle

32. DoD IT Standards Registry (DISR) IC/DoD IT Standards Registry
Walt Okon
Senior Architect Engineer
Architecture & Interoperability Directorate Office of the DoD CIO/ASD NII
28 July 2008

33. Information Technology Standards Authority
Clinger-Cohen Act
Requires Performance Based Management Principles for Acquiring Information Technology (IT), Including National Security Systems (NSS)
DoD Directive (DoDD)
DoD Executive Agent for Information Technology Standards
Develop, Prescribe, and Implement IT and NSS Standards Throughout the DoD.

34. IT and NSS Interoperability and Supportability Policy and Process Overview
DoD Sponsored Policy
JCIDS Documents (ICD, CDD, CPD) ACAT I - III & Special Interest
J6 Interoperability Requirements Certification of All JCIDS Docs (JCPAT-E Tool)
ITS & NSS Predecessor Doc. System Profile Requirement
- IT Standards Profile (DISRonline)
- IIC Profile (LISI)
Maintain OASD(NII) JCIDS/ISP Assessment Capability (JCPAT-E Tool)
Maintain IT Standards and Profiles (DISRonline)
Certify Standards Conformance
ITS and NSS Interoperability Requirements Certification
Assessments of NR-KPP in JCIDS Docs
KM/DS
Joint Staff
J-8
CJCSI D
Joint Staff J-6 Interoperability Requirements Certification Process
DoDI
4630.8 C
CJCSM
DoDD
5000.1
JROC
FCB
JCPAT-E
ITS & NSS
Registration
DISR Online
LISI InspeQtor J6
Interoperability Requirements
Certification = •
UAM / JCPAT- E System Registration
Technical View (CDD & CPD)
Interoperability & Interconnectivity
Profile (CDD & CPD)
J6I
Stage I, II & III
Assessments
JCPAT
JCPAT
Joint Staff J-6 OASD(NII)

35. DISR and DISRonline Architecture View
VERSION 15
4/22/ :02
Objectives:
Champion DoD’s Re-Engagement of the IT Standards Communities
Online IT standards Registry
Tri-Annual Update of IT Standards Registry
Tied to JCIDS IT Standards Conformance and Compliance Process
Intelligence Community Cross Coordination (ICSR)
Improved DoD Visibility and Participation in IT Standards Development Organizations
Develop and Register PM Standards Profiles (TV)
Standing IT Standards Working Groups Aligned to GIG Portfolio Management
DoD IT Standards Registry (DISRonline)
Lifecycle Tagged: Emerging and Retired Standards
Profile Assistance Software
Organization-Unique Bins
Information /
Guidance (I/G)
Informational Standards
Best Practices
Procedures
Policies
Manuals
Handbooks
Other IT Documents
Change Request Tool Software
PM System IT Standards Profiles
TVs *
Governance
and General Information Area
Policy
FAQs
CM Procedures
User Guides
Links
SOP
POCs
GIG Mission Area Management
Voting Tool Software Collaboration Tool Software
* May Contain Standards from Lifecycle Categories other than Mandated
DISR Mandated Standards
Mandated “Net-Centric” & Mandated Sunset “Interoperability” Standards
DISR Profile Registry Area
Key
Interface Profiles *
(KIPs)
Prescribed
Technology
Profiles *
(IPv6, PKI etc.)
Future
Enhancements
THIS SLIDE IS MORE OR LESS A NOTIONAL MODEL MEANT TO GIVE YOU IDEA OF BOTH THE FUNCTIONAL CAPABILITIES AND THE MANDATED CORE AND PROFILE REGISTRY AREAS WITHIN DISR.
THE AREAS CODED IN BLUE PROVIDE THE MANDATED STANDARDS FROM WHICH PRESCRIBED STANDARDS PROFILES ARE BUILT, SUCH AS TECHNOLOGY PROFILES LIKE IPV6, KEY INTERFACE REFERENCE IMPLEMENTATIONS, AND INDIVIDUAL PM PROFILES MAKING USE OR TAKING ADVANTAGE OF THE OTHER BLUE AREAS.
THE LEFT AND RIGHT WINGS IN THIS MODEL IDENTIFY THE OTHER CAPABILITIES OF DISR AND INFORMATION LINKS SUCH AS THE CHANGE REQUEST TOOL, THE VOTING AND COLLABORATION TOOL, AND STATIC DOCUMENTS SUCH AS THE SOP, USER GUIDE ETC.
UNDER OBJECTIVES, YOU SEE SOME OF THE POINTS I MENTIONED BEFORE BUT I’D ALSO LIKE TO POINT OUT THAT WE RECENTLY HAVE PLACED A GREATER EMPHASIS ON COORDINATING I-T AND INTEL STANDARDS WHERE THEY APPLY TO BOTH COMMUNITIES. IN FACT, WE ARE IN THE PROCESS OF SUPPORTING THE IC CIO ON THE STAND UP OF A DISR LIKE STANDARDS TOOL TO BOTH SUPPORT THEIR UNIQUE INTEL STANDARDS REQUIREMENTS AND THAT LIKE IT STANDARDS ARE CONSIDERED.
I WOULD ALSO NOTE THAT THE MANDATED SET OF STANDARDS STILL NEEDS TO ALLOW FOR A CERTAIN LEVEL OF LEGACY STANDARDS TO EXIST WITHIN THE CORE ALBEIT THEY MAY BE TAGGED AS A SUNSET STANDARD THUS SIGNALING TO OUR WORKING GROUPS THE NEED TO KEEP AN EYE ON EMERGING CANDIDATE STANDARDS.

36. Lifecycle of a Standard
Emerging
Upgradeability Should be a Concern
May be Implemented but Not in Lieu of Mandated Standard
Expected to be Mandated within Three Years
Mandated
Essential for Interoperability and Net-Centric Services in DoD
Minimum Set of Essential Standards for the Acquisition of All DoD Systems that Produce, Use, or Exchange Info, and, When Implemented, Facilitates the Flow of Info in Support of Warfighter
Sunset Tag Identifies an Event and Date to Retire a Standard
Inactive / Retired
New Standards / Technology Now Available and Implemented
Require Waiver and Migration Plan
Remain in the Registry

37. IT Standards Governance Organization Membership
Technical Working Groups

38. IT Standards Review, Approval, and Appeal Process
CIO EB
ASD (NII)/DoD CIO
DAB
USD(AT&L)
Direction
Reviewed Three Times per Year
Appeal
IT Standards Profiles
Acquisition Issues
DISRonline
Approved IT Standards and IT Standards Profiles
IT Standards
IT Standards Oversight Panel (ISOP)
Tri-Chairs: USD(AT&L) / ASD(NII) / JS-J6
Approve IT Standards
IT Standards Committee (ITSC) Chair: DISA
Forward
Approvals
Return/delete
Non-Consensus
Consensus
Polling
14 Days
Approve IT Standards Profiles
Consensus List
Resolve Substantive Issues
Substantive Objection
Substantive Objection
Substantive Objection
KIP Profiles
Scheduled Reviews
IT Sub-Committee Chairs (ISCs)
Technical Working Groups (TWGs)
New IT Standards
New IT Standards Profiles
* Enterprise Information Environment, Business, Warfighting, and DoD Intelligence

39. DISR Configuration Management Scheduled Review of Standards
Standards are Periodically Reviewed
To Reconfirm Status in the Standards Lifecycle
Investigate Alternative Technologies and Follow-Ons
Emerging Standards
Reviewed Annually
Expected to be Mandated within Three Years -- or Replace with New Technology
Mandated Standards
Reconfirmed Every Three Years
Still Support Interoperability and Net-Centric Services?
Identify Replacement Standard?

40. Standards Configuration Management

41. Summary Provide oversight of DoD Standards program.
Provide review and recommendations on DoD Standards and Profiles
Manage review process and operations of the DoD IT Standards Registry
Ensure minimal set of IT and NSS standards to achieve Interoperability and Net-Centric capabilities.
Responsive and Agile Governance Structure
Technical WGs Address Day-to-Day Standards Issues
Organized by GIG Core Enterprise Services
Intelligence Community Participates at All Levels
DNI is integrated into this process - ICSR
DoD and DOJ are building a CTISS Federated Standards Registry (CTISR) for all Federal Departments, State, Local and Tribal Organizations
Information Sharing
PM-ISE

42. Senior Architect Engineer
VERSION 15
4/22/ :02
DoD Architecture Training
Walt Okon
Walt Okon
Senior Architect Engineer
Architecture & Interoperability Directorate Office of the DoD CIO/ASD NII
28 July 2008

43. DoD Architecture Training
VERSION 15
4/22/ :02
DoD Architecture Training
Description
–The DoD Architecture Training effort identifies the core KSAs Architects must have to be able to design, develop, and deliver DoD architectures that enable senior leader decision making and engineering design.
–Analyze and define the types of architecture training at different levels of architecture.
–Define a certification requirement and process.

44. A Competency Framework for the DoD Architect
VERSION 15
4/22/ :02
A Competency Framework for the DoD Architect
Three Levels of Maturity
The framework acts as a standard for the knowledge, skills, and abilities Architects should obtain at varying levels of maturity
Architects are expected to perform the functions of the role represented by each level: Level 1 - development, Level 2 - analysis, and Level 3 - management

45. DOD Architect Levels Level 1 Development Level 2 Analysis
VERSION 15
4/22/ :02
DOD Architect Levels
Level 1 Development
Primary function is to develop architectures based on user requirements and input from subject matter experts
Level 2 Analysis
Primary function is to analyze architectures for the purposes of integration, interoperability, gap analysis, risk assessment, leveragability, compliance, and business decision making
Level 3 Management
Primary function is to lead and manage an architecture effort through its entire lifecycle, from development to execution/implementation
White paper identifies the functions and associated KSAs for each level

46. DOD Architect Core Competencies
VERSION 15
4/22/ :02
DOD Architect Core Competencies
Core Competencies
The core KSAs represent the fundamental competencies of an Architect, regardless of level.
Depth and breadth of each competency, however, depend on level

47. DOD Architect Core KSAs
VERSION 15
4/22/ :02
DOD Architect Core KSAs
Knowledge
Skills
Abilities
A body of information applied directly to the performance of a function.
An observable competence to perform a learned psychomotor act.
Competence to perform an observable behavior or a behavior that results in an observable product.
Architecture development
Architecture analysis
Vertical area of knowledge
Business processes
Information technology
Modeling techniques
Application of frameworks
Application of tools
Requirements gathering
Analysis techniques
Communication (verbal/written/presentation)
Abstract analytical thinking
Quickly grasp concepts
Teamwork
Innovative
Core KSAs
As the framework matures, these core competencies will be further refined, to include definitions and examples

48. Transition Within and Between Levels
VERSION 15
4/22/ :02
Transition Within and Between Levels
Transition
Transitioning within a specific level is an informal transition between beginner and intermediate or between intermediate and advanced
Transitioning between levels varies depending on individual ability, however, prior to entering the next level, individuals should be functioning as an intermediate practitioner at their current level

49. Stratification of Levels
VERSION 15
4/22/ :02
Stratification of Levels
Stratification
Focus Area
Level 1
Development
Level 2
Analysis
Level 3
Management
Data/Information
Data modeling
Relational database systems
Object-oriented, service-oriented, modular open system concepts
Data strategy
Data warehousing
Information flow analysis
Data management
Information sharing environment
Information systems
Systems
Modeling and simulation
Network operations
Systems engineering
Integration and interoperability solutions
Open standards
System to business mapping analysis
Acquisition and resourcing
Information technology
Compliance policies
Business
Process modeling
Business modeling language
Business rules
Process improvement techniques and analysis
Concepts of operation
Requirements analysis
Business mission and vision
Measures of effectiveness
Business cost analysis
Enterprise
Federation
Enterprise architecture terminology
Integration specialist
Guidance and policy (e.g., OMB’s FEA)
Performance analysis
Decision process analysis
Enterprise transformation
Enterprise strategy and goals
Enterprise IT and business process management solutions
Focus Areas
Data/Information, Systems, Business, Enterprise
Additional effort is necessary to refine this portion of the framework

50. Institutionalizing the Framework
VERSION 15
4/22/ :02
Institutionalizing the Framework
Certification and Accreditation
Individual organizations, academic institutions, and private industries will be encouraged to develop certification programs against the final DOD Architect Competency Framework
All certification programs based on the Competency Framework will be accredited by a third party organization representing the interests of the DOD
OPM - Office of Personnel Mngt
Develop an architecture job series or parenthetical
Military Departments
Develop a Military Occupational Specialty around architecture
General Services Administration
Develop a contractual standard for architecture clauses

51. White Paper Formalize a Competency Framework for the DoD Architect
VERSION 15
4/22/ :02
White Paper
Formalize a Competency Framework for the DoD Architect
Provide a centralized web-based site that provides visibility into existing architecture education and training opportunities
Identify an approach to assess the competency baseline of the current architecture workforce
Take appropriate steps to institutionalize the Competency Framework
Encourage academic institutions to develop training targeted toward senior leadership and architecture users
Encourage academic institutions to develop certification programs based on the Competency Framework

52. D0D Architecture Education Current Status
VERSION 15
4/22/ :02
D0D Architecture Education Current Status
COMPLETE
DOD Architecture Training Workshop (I, II, III, IV)
White Paper – Available for Download
Industry Town Hall Meeting
OMB Meeting
Tutorial session (FEAC and NDU)
IN PROGRESS
EA Conference Materials Is available
DoD Architecture Education and Training
Define problem with OPM Series
Define a Career path for Architects
Build a comprehensive DoDAF Course

53. DoD GIG Technical Direction (GTD)
VERSION 15
4/22/ :02
DoD GIG Technical Direction (GTD)
Walt Okon

54. DoD Technical Direction : High-Level Operational Concept
VERSION 15
4/22/ :02
DoD Technical Direction : High-Level Operational Concept
Query &
Retrieve
Identified
Interoperability
Standard,
Specifications,
And Interfaces
Capability
Development Areas
Joint Capability Areas
Standards
Specifications
Mission Area Portfolios
Community Of Interest
GIG Governance Processes
Structured and
Unstructured Sources
for Standards and
(Notional)
DARS
. . .
DKO
CADM
4630
80XX
XML
Metadata
Registry
SFIS
Taxonomy
Detailed
Standards &
Information
DISR
NCID
Technical Direction Query
Technical Direction Query
Capability
GIG
Technical Direction
Standards &
Specifications
For
Interoperability
From the left side of the figure, the Type II Technical Direction detailed standards and specifications information are obtained from Structured and Unstructured sources such as DISR, DARS, DOL, CADM, 4630, etc. which provide the necessary content and references contributes to the Type II Technical Direction. From the right side of the figure, the identified interoperability standards and specifications that are applicable to the capability development area contribute to the Type II Technical Direction. These interoperability standards and specifications will have to be identified by system engineers and functional experts for each.
As indicated by the green arrows in the figure, the “assembling” of the set of interoperability standards and specifications for the capability portfolio area, JCA, COI, and GIG Governance Processes that a developing capability touches becomes the Type II Technical Direction (for that developing capability). The mapping of these comprise the targeted Type II Technical Direction for the user.
A portal for the delivery of Type II Technical Direction will allow a developer to determine the minimum interoperability standards and specifications. By querying on the capability portfolio area/JCA/COI that are drawn on for the capability to be developed, the portal can “assemble” the Type II Technical Direction. For example, A team building a Spend Analysis Capability under the acquisition portfolio needs to implement the following functions:
1) provide financial information to users on the GIG
2) publish the financial reporting service to the GIG
Using the Type II portal, the team can query for the capability portfolio/JCA/GIG Governance process/COI utilized. Based on the identified interoperability standards and specifications within the Business Mission Area portfolio to exchange financial information on the GIG, the portal (portlet, service) retrieves the detailed information from the standards source. Also, within the EIEMA Portfolio, the portal (portlet, can find the publication standards for the Enterprise Service Discovery Service.
XML Schemas/ Components

55. Chief Architect, DoD Information Sharing
VERSION 15
4/22/ :02
DoD Information
Sharing Environment
Walt Okon
Chief Architect, DoD Information Sharing
Architecture & Interoperability Directorate Office of the DoD CIO/ASD NII
28 July 2008

56. DoD is part of this complex, extended information sharing enterprise…
Complexities of Information Sharing
Northeast Power Blackout
Counter Terrorism
Failed States (Haiti)
Terrorist
Actions
Natural Disasters
Warfighter
Operations
Coalition
Humanitarian
Pandemic
Flu
DoD is part of this complex, extended information sharing enterprise…

57. DoD Information Sharing Environment
VERSION 15
4/22/ :02
DoD Information Sharing Environment
Description:
–Provide a DoD Information Sharing architecture and standards capability which will support cross-community, institutional approach to the sharing of information within DoD and across Federal Departments, state, and local governments.
–Provide architecture and engineering guidance to DoD Information Sharing Executive.
–Provide PM-ISE architecture and standard guidance to enable cross-community sharing for identifying, planning, installing, and operating capabilities that will become the ISE.

58. DoD Information Sharing Environment
VERSION 15
4/22/ :02
DoD Information Sharing Environment
Major FY08 Tasks:
–Chief Architect, DoD Information Sharing.
–Represent DoD on PM-ISE Chief Architect Roundtable and the CTISS Committee.
–Design and deliver a CTISS Federated Standards Registry pilot.
–Develop a DoD ISE Shared Space use case and concept capabilities with Net-Centric direction.
–Partner with other ISE architects in the Federal Departments.
–Partnership with DISA on analysis and engineering.

59. PM-ISE Information Sharing On-Going Pilot/Evaluations
VERSION 15
PM-ISE Information Sharing On-Going Pilot/Evaluations
4/22/ :02
Suspicious Activity Reporting (SAR) Pilot/Evaluation
Sharing SAR with Federal Department, State and Locals
Connecting DoD Commands with Fusion Centers post-TALON Options
Pilot team: DoD, PM ISE, DOJ, and DHS
Conduct with State/Local Fusion Centers & Military Installations
Federated Standards Registry (CTISR)
Sharing validated and approved Standards
Functional Standards – Directives, Instructions, Architectures
Technical Standards - Specifications
Connecting all Departments, States, Local and Tribal to one Standards source
Pilot Team: DoD, PM-ISE, and DOJ
CTISR Setup in December 2007; Functional Testing ongoing
TALON = Threat and Local Observation Notice

60. DoD Enterprise Architecture Conference 2009
VERSION 15
4/22/ :02
Bring It All Together
DoD Enterprise Architecture Conference 2009

61. DoD Enterprise Architecture Conference 2009
All DoD Architecture Professionals
Only official Architecture Conference
Enterprise Architecture & Standards
Deliver Interoperability
April 2008 Last Conference Briefings
20-24 April 2009 DoD Enterprise Architecture Conference - Deliverables

62. Chief Architect, DoD Information Sharing
VERSION 15
4/22/ :02
Questions/Wrap-Up
Walt Okon
Chief Architect, DoD Information Sharing
Enterprise Architecture & Standards Directorate Office of the DoD CIO/ASD NII
28 July 2008