Transcript Enterprise Architecture Planning (EAP) Office of Information Technology and

Enterprise Architecture
Planning
(EAP)
Office of Information Technology and
System Strategy
Discussion
•
What is Enterprise Architecture Planning (EAP)?
•
What is an EA used for?
•
Why should we do it?
23 FEB 2001
2
What is an Enterprise Architecture?
A comprehensive blueprint of an organization.
The structure of (Enterprise) components and their
relationships, as well as principles and guidelines governing
their evolution over time.
A common understanding by all, of the names and definitions
of an organization’s entities.
23 FEB 2001
3
What is an Enterprise Architecture?
The EA is a strategic asset repository which
defines the current and target architecture
environments, including:
• the business,
• the information,
• the technology, and
• the transitional processes.
Source: Federal Conceptual Architecture model
23 FEB 2001
4
Examples - Entities
A distinguishable - person - about which information is kept.
place,
thing,
event,
concept
PERSON
CG MEMBER
AUXILIARIST
MARINER
RECREATIONAL BOATERS
CONTRACTORS
GOVERNMENT CONTACTS
REGULATED MANUFACTURERS
CASUALTY
PLACE
CG ORGANIZATION
NAVIGABLE WATERS
GOVERNMENT FACILITIES
AIR
BRIDGES
REGULATED MANUFACTURERS
THING
COAST GUARD ASSET
ATON
COMMERCIAL VESSEL
RECREATIONAL BOAT
PORT FACILITY
ICEBERG
HAZARDOUS MATERIAL
CUSTOMER ASSET
BUDGET
RADIO FREQUENCY SPECTRUM
SUPPORT ASSETS
TRAINING/EDUCATION PROGRAMS
CASE
META DATA
FUNDS
EVENT
MARITIME ACCIDENT
COASTAL INTRUSION
RESPONSE ACTIVITIES
ATON DISCREPENCY
PREVENTION ACTIVITIES
DEFENSE OPERATIONS
ACQUISITION
SUPPORT OPERATIONS
BUDGET BUILD
CASE
CONCEPT
REGULATION
LAW
STANDARDS
DIRECTIVE
PLAN
MISSION
LEGAL REQUIREMENT
INTERNATIONAL AGREEMENT
POLITICS
Source: U.S. Coast Guard Information Architecture
23 FEB 2001
5
Architecture Layers
PERSONNEL
WLB
PLATFORMS
WPB
T1 Lines
OSC
HQ
FINCEN
WMEC
MLCP
ISC
Honolulu
ISC
NOLA
PPC
ELC
TISCOM
ISC Ports
CAA
MLCA
ISC
Boston
D17
ISC St Louis ISC Cleve.
ISC
Mia.
INFRASTRUCTURE
AR&SC
FACILITIES
AOR
23 FEB 2001
6
Some EAP Components
• A standard methodology
• A standard set of templates
• A repository
• A configuration management process
• Easy access
• Ability to export
23 FEB 2001
7
Zachman’s Framework for
Information Systems Architecture
Planner’s
View
Owner’s
View
Data
Function
Network
People
Time
Motivation
List of Things
Important to Business
List of Processes the
Business Performs
List of Locations
Important to Business
List of Organizations
Important to Business
List of Events
Significant to Business
List of Business
Goals/Strategies
Entity=Class of
Business Thing
Function=Class of
Business Process
Node=Major Business
Location
Agent=Major Org Unit
Time=Major Business
Event
End/Means=Major
Business Goal/CSF
e.g., Function Flow
Diagram
e.g., Logistics Network
e.g., Entity
Relationship
Diagram
Ent=Business Entity
Rel=Business Rule
e.g., Data Model
Designer’s
View
Builder’s
View
Subcontractor’s
View
23 FEB 2001
Function=Business
Process
e.g., Data Flow Diagram
Node=Business
Location
Link=Business
Linkage
e.g., Distributed
System Architecture
Entity=Data Entity
Relationship= Data
Relationship
Funct=Appl Function
Arg=User Views
Node=Info Sys Funct
Link=Line Char
e.g., Data Design
e.g., Structure Chart
e.g., System
Architecture
e.g., Organization
Chart
e.g., Master Schedule
Agent=Org Unit
Work=Work Product
Time= Business Event
Cycle=Business Cycle
e.g., Human Interface
Architecture
Analyst
Engineer
e.g., Human/
Technology Interface
Engineer
End=Business
Objectives
Means=Business
Strategy
e.g., Processing
Structure
e.g., Knowledge
Architecture
Time=System Event
Cycle=Processing Cycle
End=Criterion
Means=Option
Secretary
Agent=Role
Work=Deliverable
Analyst
e.g., Business Plan
e.g., Control Structure
Secretary
e.g., Knowledge
Design
Entity=Segment/Row
Relationship=Pointer/
Key
Funct=Computer Funct
Arg=Screen/Device
Formats
Node=Hardware/
System Software
Link=Line Specification
e.g., Data Definition
Description
e.g., Program
e.g., Network
Architecture
e.g., Security
Architecture
e.g., Timing Definition
e.g., Knowledge
Definition
Ent=Fields
Rel=Addresses
Funct=Language Stmts
Arg=Control Blocks
Node=Addresses
Link=Protocols
Agent=Identity
Work=Transaction
Time=Interrupt
Cycle=Machine Cycle
End=Subcondition
Means=Step
Agent=User
Work=Job
Time=Execute
Cycle=Component Cycle
End=Condition
Means=Action
8
What is an EA used for?
• Acquisition
• Investment decisions
• Modeling & Simulation
• Analysis
• Requirements definition
• Plan baseline
• Describing and understanding baseline
23 FEB 2001
9
DoD C4ISR Architecture Framework 2.0
23 FEB 2001
10
DoD C4ISR Architecture Framework 2.0
Table 4-1. Essential and Supporting Framework Products
Applicable
Product
Architecture Reference
View
Essential
or
Supporting
General Nature
All Views
(Context)
AV-1
Overview and Summary
Information
Essential
Scope, purpose, intended users, environment depicted,analytical
findings, if applicable
(4.2.1.1)
All Views
(Terms)
AV-2
Integrated Dictionary
Essential
Definitions of all terms used in all products
(4.2.1.2)
Operational
OV-1
High-level Operational
Concept Graphic
Essential
High-level graphical description of operational concept (high-level
organizations, missions, geographic configuration, connectivity, etc.) (4.2.1.3)
Operational
OV-2
Operational Node
Connectivity Description
Essential
Operational
OV-3
Operational Information
Exchange Matrix
Essential
Operational
OV-4
Operational
Operational nodes, activities performed at each node,
connectivities & information flow between nodes
(4.2.1.4)
Information exchanged between nodes and the relevant attributes of
that exchange such as media, quality, quantity, and the level of
interoperability required.
(4.2.1.5)
Command Relationships
Chart
Supporting Command, control, coordination relationships among organizations
(4.2.2.1)
OV-5
Activity Model
Activities, relationships among activities, I/Os, constraints (e.g., policy,
Supporting guidance), and mechanisms that perform those activities. In addition to
showing mechanisms, overlays can show other pertinent information. (4.2.2.2)
Operational
OV-6a
Operational Rules Model
Supporting
One of the three products used to describe operational activity sequence and
timing that identifies the business rules that constrain the operation (4.2.2.3.1)
Operational
OV-6b
Operational
OV-6c
Operational State Transition Supporting
Description
Operational Event/Trace
Supporting
Description
Operational
OV-7
Logical Data Model
One of the three products used to describe operational activity sequence and
timing that identifies responses of a business process to events
(4.2.2.3.2)
One of the three products used to describe operational activity sequence and
timing that traces the actions in a scenario or critical sequence of events
(4.2.2.3.3)
Documentation of the data requirements and structural business
process rules of the Operational View.
(4.2.2.4)
Supporting
Identification of systems and system components and their
interfaces, within and between nodes
SV-1
System Interface
Description
Essential
Systems
SV-2
Systems Communications
Description
Supporting Physical nodes and their related communications laydowns
Systems
SV-3
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems2 Matrix
(4.2.1.6)
(4.2.2.5)
Relationships among systems in a given architecture; can be designed to show
Supporting relationships of interest, e.g., system-type interfaces, planned vs.
(4.2.2.6)
existing interfaces, etc.
Functions performed by systems and the information flow among
Supporting system functions
(4.2.2.7)
Systems Functionality
Description
Operational Activity to System
Mapping of system functions back to operational activities
SV-5 Function Traceability Matrix Supporting
(4.2.2.8)
Detailing of information exchanges among system elements,
System Information
Supporting
SV-6
applications and H/W allocated to system elements
Exchange Matrix
(4.2.2.9)
System Performance
Performance characteristics of each system(s) hardware and software
SV-7
Supporting elements, for the appropriate timeframe(s)
Parameters Matrix
(4.2.2.10)
Planned incremental steps toward migrating a suite of systems to a more
System Evolution
Supporting efficient suite, or toward evolving a current system to a future
SV-8
Description
(4.2.2.11)
implementation
Emerging technologies and software/hardware products that are expected to
System Technology
Supporting
SV-9
be available in a given set of timeframes, and that will affect future
Forecast
development of the architecture
(4.2.2.12)
of three products used to describe systems activity sequence and
Supporting One
SV-10a Systems Rules Model
timing -- Constraints that are imposed on systems functionality due to
some aspect of systems design or implementation
(4.2.2.13.1)
SV- 10b Systems State Transition
Supporting One of three products used to describe systems activity
Description
sequence and timing -- Responses of a system to events
(4.2.2.13.2)
Systems Event/Trace
One of three products used to describe systems activity sequence and
Supporting timing -- System-specific refinements of critical sequences of events
SV -10c Description
described in the operational view
(4.2.2.13.3)
SV-4
SV-11
Physical Data Model
Technical
TV-1
Technical Architecture
Profile
Essential
Technical
TV-2
Standards Technology
Forecast
Supporting
Systems
23 FEB 2001
Architecture
Product
Supporting
Physical implementation of the information of the Logical Data
Model, e.g., message formats, file structures, physical schema
(4.2.2.14)
Extraction of standards that apply to the given architecture
(4.2.1.7)
Description of emerging standards that are expected to apply to the
given architecture, within an appropriate set of timeframes
(4.2.2.15)
11
What is an EA used for?
•
Promote interoperable and cost-effective systems
•
Provide the rules, guidance and product descriptions
for developing and presenting architectural
descriptions
•
Ensure a common denominator for understanding,
comparing, and integrating architectures.
•
Enable architectures to contribute more effectively
to engineering interoperable and cost-effective
systems.
•
Provide a mechanism for managing complexity.
23 FEB 2001
12
IT Life Cycle and CM Policy Consolidation
USCG
Common
Operation
Environment
(USCG COE)
Standard Workstation III
Configuration Management
Policy
COMDTINST
5200.16
Planning Approval
for Automated
Information Systems
(AIS)
Information Systems
Technical Architecture
COMDTINST
5230.45A
COMDTINST
5231.2
COMDTINST
5230.59A
Information Technology
Life Cycle and
Configuration Management
Policy
IT
Systems Development
Plan
(DRAFT)
COMDTINST
9999.99
COMDTINST 9999.99
Information
Resource
Management
(cancelled)
COMDTINST
5230.41
USCG
C4ISR
Baseline Architecture
COMDTINST
3090.6
23 FEB 2001
Standard Terminal
Application Software
DeploymentCOMDTINST
5234.3
Other Policy
TBD
13
Benefits
Facilitates information services that provide:
flexibility,
interoperability,
reliability,
survivability,
affordability,
sustainability,
portability,
reusability,
Adaptability,
Compatibility
23 FEB 2001
14
Business Benefits of EAP
•
•
•
•
•
•
•
•
•
•
•
•
•
Focus on strategic use of technology for managing data as an asset
Standard vocabulary facilitates communication and reduces inconsistency and
data redundancy
Documentation increases understanding of the business
Models can be used to explain the business and assess the impact of business
changes
Decision making policies can be reviewed
Integration of current systems with new systems is considered.
It allows for a comprehensive, objective and impartial approach
The long range systems plan compliments the business plan
A cost-effective long term solution considers rate of return
It involves a feasible migration strategy with short term achievements
it is easier to assess the benefits of impact of new systems and software
it allows easier accommodation of dynamic business changes such as mergers,
acquisitions, new products, lines of business.etc.
Management participation provides a business prospective, credibility,
confidence,
and demystifies system development.
Source:
23 FEB 2001
Enterprise Architecture Planning
Steven Spewak
15
Benefits to the Business of planned systems
•
•
•
•
•
•
•
•
•
•
•
•
More responsive to customer’s needs
Reduced data-entry costs
Head-count is reduced
Increased productivity of personnel permits increased level of business
and containment of costs
Improved skills raise enthusiasm and loyalty
Efficient systems maintenance means improved service.
Architectures eliminate complex costly interfaces incongruent systems
Management decisions in all functional areas will be based on more accurate
and timely data,
leading to various improvements and cost-saving measures
End user has direct access to shared data
New systems are developed faster and at less cost due to common data,
common code, and
a shortened requirements phase
Easier to evaluate and select vendor SW packages
Effective use of repository and CASE products
Source:
23 FEB 2001
Enterprise Architecture Planning
Steven Spewak
16
Zachman reflections on EA Planning
"You may think this is too much work…
Or, it takes too long
And it costs too much
Or is too theoretical
Or too high risk
Or too whatever.
However, if that’s your assessment…
You can’t complain that
the systems aren’t “aligned” with the enterprise,or
are inflexible,
or cost too much,
or that vital information is not available,
or that the data you get isn’t any good, or too late,
or you can’t change anything,
or that I/S is slow and unresponsive…
and, I am here to tell you
Outsourcing isn’t going to fix the problem.
Packages (in themselves) won’t fix the problem.
Decentralization won’t fix the problem.
And, the Internet isn’t going to fix the problem.
No amount of money, Or
technology is going to fix the problem!
It is NOT a technical problem,
it is an ENTERPRISE problem.
Only ACTUAL WORK is going to fix the problem, and
“Someday, you are going to wish you had all those models,
Enterprise wide,
horizontally and vertically integrated,
at excruciating level of detail.”
You might as well start working on them TODAY!!!
John Zachman
23 FEB 2001
17
Next Steps
• CKO Charter an Enterprise Architecture Configuration
Control Board (EACCB)
• Identify goals, objective, principles
• Establish membership
• Identify a methodology
• Identify a framework
• Identify resources
• Define deliverables
• Establish a timeline
• CKO Charter an Enterprise Data Dictionary
Configuration Control Board (EDDCCB)
23 FEB 2001
18
DISCUSSION
23 FEB 2001
19