Step 1: Determine Intended Use
1
Determine the intended use of the architecture
•  Purpose
•  Critical issues
•  Target objectives
•  Key tradeoffs
•  Probable analysis methods
116
11
6
Purpose: Problem Statement
•  What questions need to be answered?
•  Are there specific strategic objectives to be
satisfied?
•  Are there specific trade offs to be considered?
•  What critical issues need to be addressed?
•  How is the EA used to support key decisionmaking processes?
•  What types of analysis need to be supported?
117
11
7
Why Is Purpose Important?
•  Architecture is a tool to support decision
making
–  If you don’t know what you are going to use
it for, there is a good chance it won’t be
useful
–  You need to identify and understand the
different purposes of different stakeholders
•  Architectures can be expensive to build
–  Doesn’t make sense to build one if you
118
don’t plan to use it!
11
8
Why Is Purpose Important?
PURPOSE
VIEWS
DETAIL
COMPLETION
119
11
9
Step 2: Determine Scope
2
Determine scope
of architecture
•  Geographical,
operational, & functional
bounds
•  Technological bounds • Time Frames
•  Architecture resources &
schedule constraints
120
12
0
Scope
DoD
Joint Capability Area
Component
Solution
•  Operational bounds
–  What’s the enterprise, what level of architecture
–  What mission(s), functions, and organizations
–  What geographical context
•  Constraints on technology to be considered
•  Timeframes
–  As-Is, To-Be, phasing and evolution
•  Specific project schedule and resource constraints
121
12
1
Step 3: Determine Data Required to Support Architecture
Development
3
Determine data required
to support architecture
development •  Required
architectural
characteristics •  Architectural data entities •  Levels of detail
•  Units of measure
•  Associated Metadata
122
12
2
Think About Architecture Primitives
(DoDAF Conceptual and Logical Data Model Entities)
•  Performers
•  Activities
•  Information
elements
•  Events/triggers
•  Capabilities
•  Goals
•
•
•
•
•
•
•
Systems
Services
Rules
Standards
Locations
Measures
Projects
123
12
3
DoDAF Conceptual Data Model
124
12
4
Step 4: Collect, Organize, Correlate,
and Store Architecture Data
4
Collect, Organize,
Correlate, and Store
Architecture Data
•  Automated
repositories
•  Activity Models
•  Data Models
•  Dynamic Models
•  Organizational Models
•  Metadata registration
•  Emphasis in planning is how
data will be organized
•  That is, what DoDAF views
will eventually be used,
including options and
tailoring
•  This tells us what the meta-data
should be and identifies
repository requirements
•  This tells us what needs to be
collected and how it should be
correlated
125
12
5
Not a Simple Step
•  Selecting Viewpoints
•  Selecting Views
•  Selecting Options and Tailoring
•  How to present the required data
126
12
6
Viewpoints Relationships
WHICH PROJECTS IMPLEMENT
CAPABILITIES
CAPABILITY
VIEWPOINT
HOW SYSTEMS SUPPORT
OPERATIONS
OPERATIONAL
VIEWPOINT
PROJECT
VIEWPOINT
SERVICES/SYSTEMS
VIEWPOINT
DATA/INFORMATION
VIEWPOINT
OPERATIONAL
DRIVERS FOR STANDARDS
WHERE STANDARDS
APPLY
STANDARDS
VIEWPOINT
127
12
7
All Viewpoint Views Capture Information
That Applies to the Architecture Overall
Overview and Summary Information (AV-1)
Integrated Dictionary (AV-2)
•  Identification
-  Name
-  Architect
-  Organizations Involved
-  When Developed
•  Purpose
-  Analysis Needs
-  Decision Support Needs
•  Scope
-  Views and Products Used
-  Time Frames Addressed
•  Context
-  Mission
-  Geographical
-  Rules, Criteria, and Conventions
Followed
•  Findings: Results, Recommendations
•  Tools and File Formats
At a minimum, the integrated Dictionary
is a glossary with definitions of terms
used in the given architecture
description. Each labeled graphical item
in the graphical representations should
have a corresponding entry in the
Integrated Dictionary.
128
12
8
Examples: Enterprise Level Architecture
129
12
9
Example Capability Management
Questions
Question
Required Data Types
Views
How do the capabilities relate to Vision
enterprise strategy and goals?
Goals
Desired Effects
Capabilities
Relationship between capabilities
and goals
Are there dependencies among Capabilities
the capabilities?
Relationships among capabilities,
including dependencies
Vision (CV-1)
How will capability
performance be measured?
Capability
Taxonomy
(CV-2)
Capabilities
Performance Measures
Relationships of capabilities to
performance measures
130
Capability
Dependencies
(CV-4)
13
0
Example Capability Management Questions (continued)
Question
Required Data Types
Views
When will the capabilities be
available and what projects
will provide them?
Capabilities
Projects
Timeframes
Relationships among the above
Capability
Phasing
(CV-3)
What organizations will use the
capabilities?
Capabilities
Organizations
Relationships among capabilities
and organizations
Capability to
Organizational
Development
Mapping
(CV-5)
131
13
1
Vision (CV-1) - Example
Defines the strategic context for a set of capabilities. Usually text.
Can include relationship of capabilities to goals and metrics for goals.
Example from MODAF.
132
132
13
2
Capability Dependencies (CV-4) – Example
Can show both
specialization
relationships and
dependencies.
Example from
MODAF.
133
13
3
Capability Taxonomy (CV-2) - Example
Specialization hierarchy with metrics for lowest level. Example from MODAF
134
13
4
Capability Taxonomy (CV-2) - Data
CV-2
CV-6
Performer
CV-1
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
135
13
5
Capability Phasing (CV-3) - Example
Shows when new/upgraded capabilities become available and
the projects that provide the capability. Example from
MODAF.
136
13
6
Capability Phasing (CV-3) - Data
PV-2
CV-3
CV-2
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
137
13
7
Capability to Organizational Development Mapping (CV-5) - Example
Shows planned (by phase) capability deployment to organizations and
138from MODAF
relationships among the capability implementations. Example
13
8
Capability to Organizational Development Mapping (CV-5)
PV-2
CV-5
CV-2
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
139
13
9
Example Portfolio Management
Questions
Question
Required Data Types
Views
What organizations are in
change of which projects?
Organizations
Projects
Relationships between
organizations and projects
Project
Portfolio
Relationships
(PV-1)
What are the timelines for the
projects and are there
dependencies among them?
Projects
Timeframes
Dependencies among projects
Project
Timelines
(PV-2)
140
140
14
0
Project Portfolio Mapping (PV-1) - Example
How acquisition
projects are grouped
in organizational
terms.
Example from
MODAF
141
14
1
Project Timelines (PV-2) - Example
Shows project start and stop dates and how project
durations relate to each other. Example from MODAF.142
14
2
Project Timelines (PV-2) - Data
PV-2
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
143
14
3
Examples – Solution Level Architecture
Some Basic Products
144
14
4
Example Basic Solution
Architecture Questions
Question
Required Data Types
Views
What are the key elements of
Abstractions of:
the Operational Concept for this Key mission process/activities
architecture?
Key performers
Key resource exchanges
High-level
Operational
Concept
Description
(OV-1)
How are mission operations
performed (now or in the
future)?
Activity Model
(OV-5)
Operational
Resource
Flow
Description
(OV-2)
Operational
Resource
Flow Matrix
(OV-3)
Mission process/activities
Resources exchanged/inputs &
outputs
Performers
145
14
5
Basic Operational Views Capture the Critical
Mission Relationships and Resource Exchanges
High-level graphical
description of the
operational concept
of interest
To
External
Node
Operational activities
performed and their
input/output
relationships
Performers,
Activities for each
performers and
resource needlines 146
INFORMATION
EXCHANGE
ATTRIBUTES
FREQUENCY,
INTEROPERTIMELINESS, SECURITY
ABILITY
THROUGHPUT
REQUIREMENTS
OPERATIONAL
ELEMENT &
ACTIVITY
OPERATIONAL
ELEMENT &
ACTIVITY
UNITS
IDENTIFIER PRODUCING IDENTIFIER CONSUMING
DIGITAL, RANGE FEET,
OF
VOICE, LIMITS LITERS, OF
ACTIVITY
ACTIVITY
INCHES, PRODUCING
CONSUMING
TEXT,
OE
ETC.
OE
IMAGE,
ETC.
Activity 1Performer
Activity 2
A
NAME/IDENTIFIER DEFINITION
Activity 3
SIZE
Performer
C
DESCRIPTION MEDIA
Activity 2
Activity 3
OPERATIONAL
INFORMATION
ELEMENT
Performer
B
INFORMATION
DESTINATION
From
External
Performer
INFORMATION
SOURCE
High-Level
Operational
Concept Description
Operational
Resource Flows
Matrix
INFORMATION
DESCRIPTION
Activity Model
Operational
Resource Flow
Description
Resources exchanged
between performers
and the
relevant attributes of
the exchanges 14
6
Example Basic Solution Architecture
Questions (continued)
Question
Required Data Types
Views
What systems/services and
what are their interfaces
(internal and external)?
Systems/services
System/service interfaces
Standards
System Interface
Description (SV-1)
or Services Context
Description (SvcV-1)
Standards Profile
(StdV-1)
How do the systems/services
support operations?
Relationship of systems/
services to performers
Relationship of systems/
services interfaces to
needlines
Relationship of systems/
services to activities
OV-2
SV-1/SvcV-1
Operational Activity
to Systems Function
Traceability Matrix
(SV-5) or
Operational Activity
to Services
Traceability Matrix
(SvcV-5)
147
14
7
Relationships Between OV-2 and SV-1(SvcV-1) Put IT in
Context with Mission Operations
Location B
Location A
Location C
Performer
Activity 1
Activity 2
B
Activity 2
Activity 3
A
Performer
To
External
Node
Performer
C
Activity 3
148
14
8
Systems Interface Description SV-1
Four Perspectives – Varying Levels of System Information Detail
Location-to-Location
Intralocation
System-to-System
Intrasystem
FROM/TO
OTHER
SYSTEMS
SYSTEM 1
Component 1
Component 2
Component 4
Component 3
FROM/TO
OTHER
SYSTEMS
Component 5
149
14
9
Other Things You Can Show on SV-1
•  Key Interfaces
•  Interfaces Via the
Internet
•  Other?
Applications & Shared Data
SYSTEM
1
LOCATION C
SHARED
DATABASE
G
SYSTEM
4
APP X
APP Y
APP Z
LOCATION B
SYSTEM
1
SYSTEM
3
Sys Func L
Sys Func M
Sys Func N
System Functions
150
15
0
SvcV-1 Example
151
15
1
Standards Profile Identifies Implementation Criteria That Govern the Given
Architecture
LOCATION B
LOCATION A
LOCATION C
152
15
2
Standards Profile (StdV-1)
Notional Example (Fragment)
Service Area: Service Access & Delivery
Service Category
Service Standard
Standard Description
Access Channels
Web Browser
MicroSoft Internet Explorer version x.xx (Product Standard)
Service Transport
Supporting Network
Services
Internet Message Access Protocol (IMAP) version x.xx (Interface
Standard)
Multipurpose Internet Mail Extensions (MIME) version x.ss (Interface
Standard)
Simple Mail Transfer Protocol (SMTP) version x.ss (Interface
Standard)
Service Transport
Transport Control Protocol (TCP) version x.ss (Interface
Standard)
Internet Protocol (IP) version x.ss (Interface
Standard)
Hyper Text Transfer Protocol (HTTP) version x.ss (Interface
Standard)
Service Area: Service Platform & Infrastructure
Service Category
Service Standard
Support Platforms
Platform Dependent
Standard Description
MicroSoft Windows XP Professional version x.xx (Product Standard)
StdV-1 provides a structured list of enterprise-wide standards to which
systems and their interfaces must comply.
153
15
3
Operational Activity/Systems Traceability Matrix
(SV-5b) Example - Legacy Systems
154
15
4
These Basic Products Link to Each Other
STANDARDS PROFILE (StdV-1)
HIGH-LEVEL OPERATIONALCONCEPT DESCRIPTION
(OV-1)
VALUE ADDED: SUMMARY
LEVEL REPRESENTATION OF
ORGANIZATIONS/ROLES,
MISSION, AND CONTEXT FOR
THE ARCHITECTURE
STATE
VECTOR
SERVICE AREA
Support Applications
SERVICE
Web Applications
Data Management
Business Data
Standards
Data Interchange
Document
Interchange
Communications
World Wide Web
Services
Electronic Mail
STANDARD
Internet Explorer Version 4.X or better
Netscape Version 3.X or better
Data Universal Numbering System (DUNS)
ZIP Code Directory
Congressional District Identifier
ISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codes
for the Representation of Names of Countries and Their Subdivisions)
U.S. State Codes and Territory Codes
Catalogue for Federal Domestic Assistance Program
Electronic Grants Data Elements
XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (Extensible
Markup Language)
HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html4019980424 (Hypertext Markup Language)
ANSI ASC X12 (Electronic Data Interchange)
IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999
IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol
(SMTP) Service Extensions, November 1995
IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA Internet
Text Messages, 13 August 1982
IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November
1996
OPERATIONAL CONCEPT
ROLES & MISSIONS SET
SCOPE FOR ACTIVITY
MODEL
OPERATIONAL ACTIVITY MODEL (OV-5)
A1
A2
•  ACTIVITIES MAP TO OV-2
PERFORMERS
•  I/OS MAP TO NEEDLINES
•  PERFORMERS OF ACTIVITIES,
IF SHOWN ON 0V-5, MAP TO OV-2
PERFORMERS
A3
VALUE ADDED: BUSINESS/MISSION PROCESS &
RELATIONSHIPS AMONG ACTIVITIES AND
RESOURCE EXCHANGES
INPUT/OUTPUT
LABELS MAP TO
OPERATIONAL
RESOURCE
EXCHANGES (NOT
ALWAYS ONE-TOONE)
OPERATIONAL CONCEPT
CONNECTIVITY & RESOURCE
EXCHANGES, IF SHOWN ON 0V-1,
MAP TO OV-2 NEEDLINES &
RESOURCE EXCHANGES
Information
Destination
Recipient
Recipient Recipient
OPFAC
Performing
(or functional Owning
Activity
node, as Organization/
(e.g.,
Unit
appropriate)
UJTL ID)
UJTL ID)
1
2
...
n
e.g., 1-a
.
..
1-n
e.g., 2-a
.
..
... 2-n ...
...
...
...
...
... ... ... ...
...
... ... ... ... ... ...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
STANDARDS APPLY AT
SYSTEM TO SYSTEM
INTERFACES
SYSTEMS INTERFACE DESCRIPTION
(SV-1)
RESOURCE EXCHANGES
ASSOCIATED WITH EACH
NEEDLINE ARE DETAILED IN
OV-3
OPERATIONAL RESSOURCE FLOW
DESCRIPTION (OV-2)
VALUE ADDED: STATEMENT OF LOCATIONS, SYSTEMS
& INTERFACES
•  PERFORMERS ARE
ASSOCIATEAD WITH SYSTEMS AND
LOCATIONS
OPERATIONAL RESOURCE FLOW MATRIX
(OV-3)
Nature
IER
Information
Identifier/
of
Source
Name of Information
Transaction
Purpose/
Operational Element
CollaboTriggering Sender Sender Sender
Needline (Identifier/
rative
Language
OPFAC
Event
Owning Performing
Supported Name of Scenario (For Multi- Description Size Units
or
(or functional
LISI
Media
Organization/ Activity
One- Level
(from OV-2) Information or National (Content)
node,
as
(e.g.,
Unit
Exchange) Mission Operations)
Way? Req’d
appropriate)
VALUE ADDED: COMPLETE LIST
OF RELEVANT STANDARDS
WITH OPTIONS & PARAMETERS
VALUE ADDED: INDIVIDUAL
RESOURCE EXCHANGES
ASSOCIATED WITH EACH
NEEDLINE &
PERFORMANCE
REQUIREMENTS
•  EACH OPERATIONAL NEEDLINE MAPS
TO ONE OR MORE SYSTEM
INTERFACES
VALUE ADDED: STATEMENT OF
OPERATIONAL PERFORMERS,
ACTIVITIES, AND CRITICAL RESOURCE
EXCHANGE NEEDS
155
15
5
Examples – Solution Level Architecture
Additional Views
156
15
6
Example Dynamic Behavior (Timing &
Sequencing) Questions
Question
Required Data Types
Views
What key scenarios
explain the concept of
operation or key
performance or security
issues?
What are the states/
statuses that key
elements of the
architecture have and
how do they change?
Events
Messages
Performers/systems/services
Relationship among the above
Event/Trace
Descriptions:
Operational (0V-6c)
Systems (SV-10c)
Services (SvcV-10c)
States for a given element of the
architecture
Transitions
Events
Relationships among the above
State Transition
Descriptions:
Operational (OV-6b)
Systems (SV-10b)
Services (SvcV-10b)
What are the rules that
constrain operations,
systems and/or
services?
Rules
Relationships of rules to other
elements of the architecture
Rules Models:
Operational (OV-6a)
Systems (SV-10a)
Services (SvcV-10a)
157
15
7
Example OV-6c - Graphic Only
Scenario: Flight Maneuver Request from Data
Performers
Events
Flight
Vehicle
Download
Schedule
Ground
Station
Downlink
Mission Control
Telemetry
Telemetry
Processing
Complete
Planning
Complete
Upload
Schedule
Mission
Control
Check
Telemetry
Analyze
Telemetry
Command
Plan Flt
Vehicle
Ops
Execute
Schedule
Uplink
158
15
8
State Transition Description Example (OV-6b)
WORKING
REPORT
DISAPPROVED
REASSIGNMENT
REQUESTED
WORK
COMPLETED
AWAITING
ASSIGNMENT
QUERY
REJECTED
QUERY
SUBMITTED
ASSIGNMENT
MADE
REJECTED
The query/response unit of work
is the architectural item that has
state.
Each state may be associated
with an activity or set of
activities from OV-5.
DECISION TO
CANCEL
CANCELLED
WORK
APPROVED
IN
REVIEW
IN
DISTRIBUTION
DISTRIBUTION
COMPLETE
CLOSED
159
15
9
Examples of Types of Rules
•  Operational Rules
–  Rules of Engagement
•  System Rules
•  Service Rules
–  Criteria for judging when a service implementation
is overloaded
–  Criteria for instantiating a new implementation of a
service
No set notation for rules.
160
16
0
Example Domain Data Questions
Question
What are the shared
mission/business
concepts and their
relationships?
Required Data Types
Entities
Attributes
Relationships among the above
Views
Conceptual Data
Model
(DIV-1)
What is the logical
Entities
structure of the key
Attributes
structured shared data in Relationships among the above
the architecture?
Logical Data Model
(DIV-2)
What is the physical
structure of the key
structured shared data in
the architecture?
Physical Data Model
(DIV-3)
Entities, Attributes, and
Relationship among the above or
File Structures or
Message Structures or ?
161
16
1
Data Models
Operational
DIV-1, DIV-2
Data Model
Physical
Data Model/Schema
Relationship
MESSAGE FORMAT
･ STANDARDS REFERENCE
･ MESSAGE TYPE(S)
･ MESSAGE FIELDS WITH REPRESENTATIONS
･ MAP FROM LDM TO MESSAGE FIELDS
Entity
Name
Attributes
• .....
• .....
• .....
DIV-3
Relationship
Name
PHYSICAL
DATA
MODEL
OPTIONS
FILE STRUCTURE
AND/OR
･ STANDARDS REFERENCE
･ RECORD AND FILE DESCRIPTIONS
･ MAP FROM LIM TO RECORD FIELDS
PHYSICAL SCHEMA
･ DDL OR ERA NOTATION (WITH
SUFFICIENT DETAIL TO GENERATE THE
SCHEMA)
･ MAP FROM LDM TO PDM WITH RATIONALE
OTHER OPTIONS
･
･
･
Data/Information Viewpoint views model shared structured
enterprise concepts and data.
162
16
2
Example Transition Planning Questions
Question
Required Data Types
Views
When will new systems/
services be available?
Systems/Services
Timeframes
Relationship among the above
Systems Evolution
Description (SV-8)/
Services Evolution
Description (SvcV-8)
What IT performance
improvements should be
expected at key
transition milestones?
Systems/Services
Performance measures
Relationships among the above
Systems Measures
Matrix (SV-7)/
Services Measures
Matrix SvcV-7)
What are the trends in
systems/services and
standards and
associated personnel
skills that may impact IT
during the transition
period?
Systems/Services Areas,
Categories, and Standards
Timeframes
Forecasts
Systems Technology
and Skills Forecast
(SV-9)/ Services
Technology and Skills
Forecast (SvcV-9)
Standards Forecast
(StdV-2)
163
16
3
Systems/Services Evolution
Description (SV-8/SvcV-8) Notional Example
NEW FUNCTION 2 &
UNIQUE DATA IMPLEMENTED
ON CLIENT SERVER (& INTEGRATED WITH
COMMON DATA ON MAINFRAME)
NEW FUNCTION 1 &
UNIQUE DATA IMPLEMENTED
ON CLIENT SERVER (& INTEGRATED WITH
COMMON DATA ON MAINFRAME)
LEGACY
MAINFRAME
SYSTEM
+6 MO.
+12 MO.
V
1.0
+18 MO.
V
1.1
+24 MO.
V
1.2
+36 MO.
V
1.3
+48 MO.
V
1.4
+60 MO.
FEDERATED
DISTRIBUTED
SYSTEM
V
2.0
CLIENT/SERVER
PLATFORMS, LAN, &
MIDDLEWARE INSTALLED
SEGMENT 1 APPLICATIONS
& UNIQUE DATA CONVERTED
TO CLIENT/SERVER
SEGMENT 2 APPLICATIONS
& UNIQUE DATA CONVERTED
TO CLIENT/SERVER
SEGMENT 3 APPLICATIONS,
& UNIQUE DATA CONVERTED
TO CLIENT/SERVER
COMMON DATA CONVERTED
TO SHARED DATA SERVER
Documents the planned evolution of enterprise systems/services
over time and provides a visual representation of scheduling and
dependencies.
164
16
4
Systems Evolution Description
(SV-8) - Data
PV-2
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
165
16
5
Systems/Services Performance Parameters Matrix (SV-7/
SvcV-7)
Performance Thresholds/Measures
Systems Location A
Time
0
(Baseline)
Time
1
Time
n
(Objective)
Database 1
Capacity
Availability
Average Seek Time
Data Transfer Rate
System 1
Average processing time for transaction type 1
Worst case processing time for transaction type 1
Availability
Mean Time Between S/W Failures
System 2
Average processing time for transaction type 2
Worst case processing time for transaction type 1
SV-7: Focus is on systems performance goals – current (baseline)
values and required/goal values at key future milestones for selected
measures.
SvcV-7: Focus on performance of services and service level
agreements
166
16
6
Systems/Services Technology & Skills Forecast (SV-9/SvcV-9) Notional
Example (Fragment)
Service Area: Service Platform & Infrastructure
Technology Forecast
Service Category
Hardware/
Infrastructure
Service Standard
Embedded
Technology
Devices
Short Term
(0-1 Yr.)
Wearable
computers still
uncommon
Near Term
(1-3 Yrs.)
Long Term
(3-5 Yrs.)
Wearable
computers become
widely available
and popular
All personal
computing services
available through
wearable units
All platform
components
become wireless
and physically
separable
User integration of
wireless platform
units from multiple
vendors common.
Service Area: Component Framework
Technology Forecast
Service Category
Service Standard
Presentation/
Interface
Wireless/ Mobile/
Voice
Short Term
(0-1 Yr.)
Spoken interface
support widely
available
Near Term
(1-3 Yrs.)
Long Term
(3-5 Yrs.)
Spoken (subvocal)
user interface
becomes the
standard user
interface
Tracks expected trends, availability, and impact of new
technology and skills in areas of interest with respect to
selected timeframes.
167
16
7
Systems Technology & Skills Forecast (SV-9) Data
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
168
16
8
Standards Technology Forecast
(StdV-2)
Notional Example (Fragment)
Service Area: Service Access & Delivery
Standards Forecast
Service Category
Service
Transport
Service Standard
Service Transport
Short Term
(0-1 Yr.)
Near Term
(1-3 Yrs.)
Long Term
(3-5 Yrs.)
IETF – RFC 2818
HTTP Over TLS
accepted, replaces
RFC 2616
IETF – RFC XXX
Common Gateway
Interface (CGI) 1.2
accepted, replaces
CGI 1.1 as de facto
standard
Service Area: Component Framework
Standards Forecast
Service Category
Service Standard
Security
Supporting
Security Services
Short Term
(0-1 Yr.)
Near Term
(1-3 Yrs.)
Long Term
(3-5 Yrs.)
Security marking
standards in DTD
accepted by CAPCO
as Intelligence
Community Standard
Tracks emerging and evolving standards in areas of interest with respect
to selected timeframes.
169
16
9
Example Matrix/Mapping Questions
Question
Required Data Types
Which systems/services
interface with which
other systems/services?
Systems/services
Systems/services interfaces
How do operational
activities relate to
capabilities?
Operational activities
Capabilities
Relationships among the above
How do services relate
to capabilities?
Services
Capabilities
Relationships among the above
What are the key attributes System/Service Interfaces
(such as throughput) of the System/Services Resource Flows
system/services resources Attributes of Resource Flows
flows?
Views
Systems2 Matrix
(SV-3)
Systems-Services
Matrix (SvcV-3a)
Services2 Matrix
(SvcV-3b)
Capability to
Operational Activity
Mapping (CV-6)
Capability to Services
Mapping (CV-7)
Systems Resource
Flow Matrix (SV-6)/
Services Resource
Flow Matrix (SvcV-6)
170
17
0
Mapping Summary
PV-1
Project
Organization
SV-3
PV-3
Capability
CV-6
Operational
Activity
CV-7
SV-5
SvcV-5
Systems/
Services
SvcV-3
Mappings help check for architecture consistency.
171
17
1
Systems/Services Resource Flow Matrix
(SV-6/SvcV=6)
Identifier/
Identifier/Name of Identifier/Name of
Name of Operational
Operational
Corresponding
Information Exchange
NeedlineSupported System Interface(s)
Supported
(from OV-2)
(from SV-1)
(from OV-3)
e.g., 1-a
Needline 1
e.g., Interface 1
Identifier/
System Data
Exchange
e.g., 1-a. (1)
..
e.g.,
1-a (n)
Nature of Transaction
Data Destination
Data Source
Receiving
Source System Receiving
Other LISI Level
Source
Content Size Format Protocols Achievable System Name Function
System Name System Function
e.g., 1-b
e.g., 1-c
e.g., 1-d
e.g., Interface 2
...
e.g., Interface n
Needline 2
Needline n
...
Performance Attributes
Information Assurance Attributes
FrequencyTimelinessThroughputOther Classification
Continued
Threats
Physical Environment
Political/
Criticality/ Encryption Authentication
Physical Electronic Economic Aerospace Land
Priority
Sea
..
.
Not identical to V 1.5 columns
Documents data/resource exchanges among systems and how information
exchanges are implemented. For services, the focus is the resource flows
produced and consumed by each services. Column headings are no longer
specified.
172
17
2
Other Example Questions
Question
Required Data Types
Views
What organizations are
included in the architecture
and how do they relate to
the performers or other
elements of the
architecture?
What are the key
communications IT that
support the systems/
services interfaces?
Organizations
Reporting/management
relationships
Relationships of organizations
to other elements of the
architecture
Systems/services
Communications systems,
technologies & protocols
Relationships among the
above
Organizational
Relationships Chart
(OV-4)
What are the systems
functions/services and
the data flow among
them?
Systems functions/services
Data flows among the systems
functions/producer-consumer
flows among the services
System Functionality
Description (SV-4)/
Services Functionality
Description (SvcV-4)
Systems Resource
Flow Description
(SV-2)/ Services
Resource Flow
Description (SvcV-2)
173
17
3
Organizational Relationships
Chart (OV-4)
Top-Level
Organization
Working
Group
Coordination or
Other Specified
Relationship
Second-
Level
Organization
Third-
Level
Organization
Reporting
Relationship
Second-
Level
Organization
OV-4 captures organization
roles, responsibilities, and
relationships.
It shows organizations and
relationships that may not
appear on the official org
chart.
Third-
Level
Organization
174
17
4
Systems Resource Flow
Description
(SV-2) – SvcV-2 Similar
DETAILED
PERSPECTIVE
HIGH LEVEL
PERSPECTIVE
CONNECTION
TO LOCATION B
LOCATION A
DETAILS OF COMMS
INTERFACE 1
LOCATION B
System
1
Two-Way
Communications
Paths
LOCATION A
COMMUNICATIONS
PATHS, AND NETWORKS
EXTERNAL CONNECTION
(OUTSIDE THE
LOCATIONS OF INTEREST)
System
2
LOCATION C
SV-2 documents the communications
network details, decomposing the interfaces
from the System Interface Description
One-Way
Communi-
cations
Path
System
4
System
3
Local Area Net
CONNECTION
TO LOCATION B
System
5
EXTERNAL
CONNECTION
(OUTSIDE THE
LOCATIONS OF INTEREST)
CONNECTION
TO LOCATION C
175
175
17
5
Systems Resource
Flow Description
(SV-2) - Data
DIV-3
Concept diagram from MODAF – slightly modified.
WARNING: Terminology is not identical to DoDAF 2.0.
176
17
6
Systems Functionality Description
(SV-4) Hierarchy
SV-4 is the system equivalent of the Activity Model. It
documents the flow of data among system functions and has
both hierarchy and flow versions.
177
17
7
Systems Functionality Description (SV-4a)
Flow Diagram – Context Diagram
EXTERNAL!
SOURCE
1
DATA!
FLOW 1!
DATA!
FLOW 3!
EXTERNAL!
SINK!
1!
System !
Function!
1
EXTERNAL!
SOURCE
2
DATA!
FLOW 2!
DATA!
FLOW 4!
EXTERNAL!
SINK!
2!
178
17
8
Systems Functionality Description (SV-4a)
Flow Diagram – 1st Level Decomposition
EXTERNAL!
SOURCE
1
DATA!
FLOW 1!
EXTERNAL!
SINK!
1!
System !
Sub=Function!
11
DATA!
FLOW 3!
DATA!
FLOW 5!
EXTERNAL!
SOURCE
2
System !
Sub-Function!
12
DATA!
FLOW 2!
DATA!
FLOW 6!
DATA!
FLOW 7!
DATA!
REPOSITORY
DATA!
FLOW 8
System !
Sub-Function!
13
DATA!
FLOW 4!
179
EXTERNAL!
SINK!
2!
17
9
Services Functionality Hierarchy
(ScvV-4) - Example
Shows Services’ Specialization Hierarchy
180
18
0
Services Functionality Description (SvcV-4) - Example
Service D
App A
Service Request/
Response 1
App B
Service C
Service Request/
Response 2
Service Request/
Response 3
Service Request/
Response 4
Service E
SV-4b documents the producer/consumer relationships among services and among
services and applications. These are dependency relationships by type of service.
It also documents the standard service ports (interfaces).
181
18
1
Planning Example
182
18
2
•  Document As-Is process for project financial
management for Company X
–  Basis for business process standardization
•  Reference for Project Managers (PMs)
•  Training for new PMs
–  Basis for process improvement and upgraded
automation
Purpose
183
18
3
•  Project Managers
–  What actions are required to initiate a contract?
–  What actions are required to complete the mid-month and
end-of-month direct charge amount checks?
–  What actions are required to complete invoice approval?
–  What information needs to be provided to Accounting?
–  How is that information provided (i.e., what mechanism is
used)?
Stakeholders and Issues (1)
184
18
4
•  Accounting
–  What information is required from the PM prior to
initiating a contract?
–  What information do PMs require to ensure accurate
invoices?
–  How does Accounting receive and provide this
information?
–  What are the information and reporting requirements for an
integrated financial system?
Stakeholders and Issues (2)
185
18
5
•  Group Managers
–  Are all the PMs following the same procedures to initiate
contracts and approve invoices?
–  Are the system(s) used by PMs to manage financial
information adequate?
–  [Are the system(s) used by the PMs to manage financial
information support easy and accurate assessment of
project status?]
Stakeholders and Issues (3)
186
18
6
•  Executive Management
–  Are there opportunities to simplify the contract
initiation process?
–  What activities would a new, integrated financial
system have to support?
–  What is the set of projects and internal
organizations involved?
Stakeholders and Issues (4)
187
18
7
•  Mission/function/organizational bounds: Normal interactions
between PMs and Accounting in the execution of a single,
prime contract
–  Normal bi-monthly interaction
•  Geographic bounds: Activities are all performed at Company
X HQ for projects in the U.S.
•  Timeframe: As-Is
•  Constraints: Application level analysis; no infrastructure to
be examined; systems to be treated as “black boxes”
•  Expected Analysis: Opportunities for improvement
Scope
188
18
8
Data & Views – Processes (1)
•
•
•
•
•
Related Issues
What actions are required to initiate a contract?
What actions are required to complete the mid-month and
end-of-month direct charge amount checks?
What actions are required to complete invoice approval?
Are all the PMs following the same procedures to initiate
contracts and approve invoices?
Are there opportunities to simplify the contract initiation
process?
189
18
9
Data & Views – Processes (2)
Needed Data & Views
•  As-Is Business Process descriptions, including systems
used, organizations involved, and where policies are
implemented – Activity Model (OV-5) with IDEF0,
activities decomposed to show interactions between PMs
and Accounting; OV-1
•  Policies – Operational Rules Model (OV-6a) with
structured English; rules mapped to controls on OV-5
•  Scenarios showing differences between individual PM’s
processes and showing opportunities for improvement –
Operational Event/Trace Descriptions (OV-6c), specific
scenarios TBD
190
19
0
Example with Tables
(instead of text - still need to include options &
tailoring)
Question
Stakeholder
Required Data
Views
What actions are
required to initiate a
contract?
PM
Policies
As-Is Business Process descriptions
What actions are
required to complete the
mid-month and end-ofmonth direct charge
amount checks?
PM
Policies
As-Is Business Process descriptions
OV-6a
OV-5
OV-1
What actions are
required to complete
invoice approval?
PM
Policies
As-Is Business Process descriptions
OV-6a
OV-5
OV-1
191
OV-6a
OV-5
OV-1
19
1
Example with Tables
(instead of text) - continued
Question
Stakeholder
Required Data
Views
Are all the PMs following
the same procedures to
initiate contracts and
approve invoices?
GM
As-Is Business Process descriptions
Scenarios showing differences
between individual PM’s processes
OV-5
OV-6c
Are there opportunities
to simplify the contract
initiation process?
EM
As-Is Business Process descriptions
Scenarios showing opportunities for
improvement
OV-5
OV-6c
192
19
2
Data & Views – Information (1)
Related Issues
•  What information needs to be provided to
Accounting?
•  What information is required from the PM
prior to initiating a contract?
•  What information do PMs require to ensure
accurate invoices?
193
19
3
Data & Views – Information (2)
Needed Data & Views
•  Inputs and outputs from business process activities
that go between PMs and Accounting
–  Activity Model (OV-5)
–  Operational Resource Flow Description (OV-2) with
organizations as nodes
–  Operational Resource Flow Matrix (OV-3) with
following columns: Needline ID, Information Exchange
ID, Description, Media, Triggering Event, Producing
Node and Activity, Receiving Node and Activity; may
potentially need format standards for information
exchanges
194
19
4
Data & Views –
Information Mechanisms (1)
Related Issues
•  How is that information provided (i.e., what
mechanism is used)?
•  How does Accounting receive and provide
this information?
195
19
5
Data & Views –
Information Mechanisms (2)
Needed Data & Views
•  Form and format of the information – Operational
Resource Flow Matrix with media and format
columns
•  Systems and system interfaces used to automate
information exchanges – Systems Interface
Description (SV-1), system-to-system perspective,
showing applications and databases on graphic
196
19
6
Data & Views –
Process Improvement (1)
•
•
•
•
Related Issues
What is the set of projects and internal
organizations involved?
Are the system(s) used by PMs to manage
financial information adequate?
What are the information and reporting
requirements for an integrated financial system?
What activities would a new, integrated financial
system have to support?
197
19
7
Data & Views –
Process Improvement (2)
Needed Data & Views
•  Company X organizations and reporting relationships –
Organizational Relationships Chart (OV-4) showing
existing project organizations; color code to show
relationships to operational nodes
•  Mapping of systems to business processes and information
exchanges – Systems Interface Description (SV-1);
Operational Activity to Systems Function Traceability
Matrix (SV-5) with applications instead of systems
functions
•  Current standards in support of interoperability Standards Profile (StdV-1) with FEA TRM and service
areas of interest TBD
198
19
8
Modeling Elements •  The Bricks of the Founda4on •  Core Architecture Components 19
9
Essential elements?
- start from the business
questions
(once you know what questions you
need to answer, you’ll know what
elements to use to answer it)
EA should add value to business
operations and support decisionmakers. Value can be defined
through an understanding of the
intended use by constructing an
outline addressing the following
questions:
●  Who’s going to use it?
●  Why do they need it?
●  What’s it going to mean to
them?
●  What key and critical questions
can’t they answer today?
●  Who should be brought
together to work this situation?
FEAC Institute – Defining the Essential Elements
20
0
Essential
Elements
As defined by one
bureau view
(FEAF/TEAF mix)
•
•
•
•
•
•
•
•
•
•
•
•
Strategy: Vision, Mission, Goals, Objective,
Performance Indicator, Business Needs
Information Dictionary: Work Product Glossary,
Model Object Dictionary, Business Object Dictionary
Organization: Organization Charts, Roles, Skills
Location: Locations, Location Type
Business Process: Activity, Event, Information
Exchange
Data & Information Exchange: Entities &
Relationships, Information Exchange Diagram
Operational Connectivity: Node Connectivity Diagram
Application Connectivity: System Interface
Description (diagram), Information Assurance Risk
Model
Operations Views: Based on scope and priority
Technology Reference Model: Service Areas,
Domains, Services, Products
Standards: Standards & Security Profile, Service
Levels, Uniform Products
Performance Management, Direction and
Operations: CIO Top Ten, Services, Project
Portfolios, CPIC Business Cases, IT Business Plans,
and Balanced Scorecard Performance Measures
FEAC Institute – Common Architecture Elements - Selected
20
1
New Capability Enterprise Architecture for Eagle Eye Golf Club FEAC Cer4fica4on Program Winter 09 20
2
Products •
Overview and Summary (AV-­‐1) -­‐ Excerpt •
High Level Opera4onal Graphic (OV-­‐1) •
Opera4onal Ac4vity Model – Ac4vity Tree Node (OV-­‐5) •
Opera4onal Node Connec4vity (OV-­‐2) •
Organiza4onal Rela4onships Chart (OV-­‐4) •
Opera4onal Informa4on Exchange (OV-­‐3) -­‐ Excerpt •
Opera4onal Ac4vity Model – Context Diagram (OV-­‐5) March 16, 2009 "
Operational Activity Mode – Activity
Decomposition Models (OV-5)
"
Operational Event Trace Description
(OV-6c)
"
Systems Interface Description (SV-1)
"
Systems Communications Description
(SV-2)
"
Operational Activities to Systems
Traceability Matrix (SV-5b)
"
Technical Standards Profile (TV-1)
"
Integrated Dictionary (AV-2) - Excerpt
"
Conclusion
New Capability Enterprise Architecture for EEGC by Team ACIS 203 20
3
Overview and Summary (AV-­‐1) Excerpt •
The Professional Golf Associa4on (PGA) has offered Mr. Chipi4n, owner/operator of Eagle Eye Golf Course, an opportunity to host a celebrity charity golf event in April 2012. •
Purpose: To create a To-­‐Be enterprise architecture that provides informa4on on the ac4vi4es, organiza4ons, and systems necessary to support a new capability (e.g. host a celebrity charity golf event). –  In doing so, the architecture also iden4fies new as well as exis4ng primi4ves (e.g. op nodes, system nodes, etc.) that remain func4onal as they are today or that may need to be modified in support of the To-­‐Be scenario. –  This enterprise architecture is the first in a series of tasks that need to be performed as part of the overall decision making process for accep4ng or rejec4ng the PGA’s proposal to host the celebrity charity golf event at EEGC in April of 2012. •
Viewpoint: Owner/Operator EEGC •
Timeframes: To-­‐Be –  Timeframe for making decision to host or not is 6 months –  Timeframe for event is April 2012 March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 204 20
4
High Level Opera4onal Graphic (OV-­‐1) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 205 20
5
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Tree Node March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 206 20
6
Opera4onal Node Connec4vity (OV-­‐2) Excerpt -­‐ EEGC Central March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 207 20
7
Opera4onal Node Connec4vity (OV-­‐2) Excerpt -­‐ Course and Landscape Management March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 208 20
8
Opera4onal Node Connec4vity (OV-­‐2) Excerpt -­‐ Marke4ng & Media Rela4ons March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 209 20
9
Organiza4onal Rela4onships Chart (OV-­‐4) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 210 21
0
Opera4onal Informa4on Exchange (OV-­‐3) -­‐ Excerpt March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 211 21
1
Opera4onal Ac4vity Model (OV-­‐5) Context Diagram March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 212 21
2
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Decomposi4on Model (A0) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 213 21
3
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Decomposi4on Model (A1) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 214 21
4
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Decomposi4on Model (A2) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 215 21
5
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Decomposi4on Model (A3) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 216 21
6
Opera4onal Ac4vity Model (OV-­‐5) Ac4vity Decomposi4on Model (A4) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 217 21
7
Opera4onal Event Trace Descrip4on (OV-­‐6c) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 218 21
8
Systems Interface Descrip4on (SV-­‐1) Excerpt -­‐ EEGC Clubhouse
March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 219 21
9
Systems Interface Descrip4on (SV-­‐1) Excerpt -­‐ Superintendent Sta4on
March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 220 22
0
Systems Interface Descrip4on (SV-­‐1) Excerpt -­‐ Public Informa4on & Media Rela4ons Village
March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 221 22
1
Systems Communica4ons Descrip4on (SV-­‐2) Excerpt -­‐ EEGC Central (1 of 2) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 222 22
2
Systems Communica4ons Descrip4on (SV-­‐2) Excerpt -­‐ EEGC Central (2 of 2) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 223 22
3
Systems Communica4ons Descrip4on (SV-­‐2) Excerpt -­‐ Superintendent Sta4on March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 224 22
4
Systems Communica4ons Descrip4on (SV-­‐2) Excerpt -­‐ Public Informa4on & Media Rela4ons Village March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 225 22
5
Opera4onal Ac4vi4es to Systems Traceability Matrix (SV-­‐5b) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 226 22
6
Technical Standards Profile (StdV1) March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 227 22
7
Integrated Dic4onary (AV-­‐2) Excerpt March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 228 22
8
Integrated Dic4onary (AV-­‐2) – cont’d Excerpt March 16, 2009 New Capability Enterprise Architecture for EEGC by Team ACIS 229 22
9
Considera4ons about Modeling Complex Systems •  Making sure models contain just enough elements and no more •  Models are like stone carving – “the art is removing what you don’t need.” •  It is easy to recognize a well formulated model awer the fact because it has intui4ve appeal •  Gelng to this point is a combina4on of skill, prac4ce, effort, revision and art •  The first step in acquiring this skills is apprecia4ng the elegance of seminal models •  Great ar4st study the masters; so too must great modelers See Miller and Page, Complex Adaptive Systems
Page 230
23
0
The Enterprise Architecture of the IRS Page 231
23
1