1. Enterprise Architecture Planning (EAP)
Office of Information Technology and System Strategy

2. Discussion What is Enterprise Architecture Planning (EAP)?
What is an EA used for?
Why should we do it?
The objective of this meeting is to introduce for discussion, the concept of Enterprise Architecture Planning. During our discussion, the following questions should be considered:
What is EAP?
What is it used for?
Why should we do it?
23 FEB 2001

3. 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.
When we say Enterprise Architecture Planning, the Architecture part is a comprehensive blueprint of an organization.
The planning part is the definition, development and most importantly the implementation and configuration management of the architecture.
23 FEB 2001

4. Source: Federal Conceptual Architecture model
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.
An Enterprise Architecture describes
the information necessary to operate the business,
the technology necessary to support the business operations and,
the processes for implementing new technologies for evolving from the current to the target architecture in response to the changing needs of the business.
Source: Federal Conceptual Architecture model
23 FEB 2001

5. Examples - Entities
A distinguishable - person - about which information is kept.
place,
thing,
event,
concept
This matrix represents a set of Coast Guard enterprise entities likely to be found in our enterprise architecture.
This table was a product of the Coast Guard Information Architecture planning process.
Source: U.S. Coast Guard Information Architecture
23 FEB 2001

6. Architecture Layers PERSONNEL PLATFORMS INFRASTRUCTURE FACILITIES AOR
WMEC
WPB
WLB
PLATFORMS
T1 Lines HQ
FINCEN
MLCP
OSC
ISC
Honolulu
D17
AR&SC
Boston
ISC Ports
TISCOM
ELC
PPC
NOLA
Mia.
ISC St Louis
ISC Cleve.
CAA
MLCA
INFRASTRUCTURE
FACILITIES
This slide provides a graphic example of some of the different categories of enterprise entities captured in an architecture.
There are many individual architecture activities which have occurred, or are currently underway within the Coast Guard.
Some examples include:
C4ISR Baseline and Objective Architectures
Deepwater Architecture
Information Architecture
Each produces a set of information to serve a specific purpose. However there is no enterprise repository to agregate this information.
Common, or compatible methodologies must be employed, and a common set of templates must be provided to make all of the material being produced, useful at an enterprise level,
the right information is collected, in the right format, stored in a robust, easy to access environment. This information must be consolidated in a common enterprise repository to gain the synergy of such an information store.
AOR
23 FEB 2001

7. Some EAP Components A standard methodology A standard set of templates
A repository
A configuration management process
Easy access
Ability to export
To facilitate enterprise architecture development some logical practices must be employed:
A common methodology or approach must be used to promote a repeatable process, reduce training costs, and shorten the life cycle of that process.
A common set of templates must be employed to ensure the right information is collected in a common usable format.
A centrallized repository must be implemented to make the information accessible. This should facilitate collection as well as use of the EA information.
The Architecture configuration must be controlled to maintain its integrity. This requires the implementation of an EA configuration management process. All other processes which cause change to the architecture should feed this CM process.
The EA must be easy to access anytime from anywhere.
The information must be exportable to facilitate its use.
23 FEB 2001

8. Zachman’s Framework for Information Systems Architecture
List of Locations
Important to Business
Node=Major Business
Location
Data
Function
Network
People
Time
Motivation
List of Things
Entity=Class of
Business Thing
List of Processes the
Business Performs
Function=Class of
Business Process
List of Organizations
Agent=Major Org Unit
List of Events
Significant to Business
Time=Major Business
Event
List of Business
Goals/Strategies
End/Means=Major
Business Goal/CSF
e.g., Entity
Relationship
Diagram
Ent=Business Entity
Rel=Business Rule
e.g., Function Flow
Function=Business
Process
e.g., Data Model
Entity=Data Entity
Relationship= Data
e.g., Structure Chart
Funct=Computer Funct
Arg=Screen/Device
Formats
e.g., System
Architecture
Node=Hardware/
System Software
Link=Line Specification
e.g., Logistics Network
Node=Business
Link=Business
Linkage
e.g., Program
Funct=Language Stmts
Arg=Control Blocks
e.g., Network
Node=Addresses
Link=Protocols
e.g., Organization
Chart
Agent=Org Unit
Work=Work Product
e.g., Business Plan
End=Business
Objectives
Means=Business
Strategy
e.g., Human Interface
Agent=Role
Work=Deliverable
e.g., Security
Agent=Identity
Work=Transaction
e.g., Processing
Structure
Time=System Event
Cycle=Processing Cycle
e.g., Control Structure
Time=Execute
Cycle=Component Cycle
e.g., Timing Definition
Time=Interrupt
Cycle=Machine Cycle
e.g., Knowledge
End=Criterion
Means=Option
Design
End=Condition
Means=Action
Definition
End=Subcondition
Means=Step
e.g., Data Definition
Description
Ent=Fields
Rel=Addresses
e.g., Data Design
Entity=Segment/Row
Relationship=Pointer/
Key
e.g., Data Flow Diagram
Funct=Appl Function
Arg=User Views
Analyst
Engineer
Secretary
e.g., Human/
Technology Interface
Agent=User
Work=Job
e.g., Master Schedule
Time= Business Event
Cycle=Business Cycle
e.g., Distributed
System Architecture
Node=Info Sys Funct
Link=Line Char
Planner’s
View
Owner’s
Designer’s
Builder’s
Subcontractor’s
This slide is a framwork example developed by John Zachman.
One can see a structured, comprehensive set of information categories that are collected to define the enterprise, as well as what types of personnel use these types of information.
This framework is described in detail in Steven Spewak's book entitled "Enterprise Architecture Planning" which describes a methodology for conducting EAP using the Zachman Framework.
23 FEB 2001

9. What is an EA used for? Acquisition Investment decisions
Modeling & Simulation
Analysis
Requirements definition
Plan baseline
Describing and understanding baseline
All the work of collecting, maintaining, and employing the information pays off when this information is used for the activities, such as those listed, to make better informed business decisions.
The architecture helps the organization better uderstand what is being managed
23 FEB 2001

10. DoD C4ISR Architecture Framework 2.0
The DoD C4ISR Architecture framework model illustrated here is being used to develop the Deepwater Baseline and objective architectures.
The use of a common methodology and standard templates is critical here. The Coast Guard must provide three industry teams a common Coast Guard baseline architecture to design to. The three industry team must provide their designs in the same common format to facilitate the excruciating analysis and cross-comparisons being conducted by the project team to select the best IDS.
23 FEB 2001

11. DoD C4ISR Architecture Framework 2.0
This slide symbolizes the set of products developed under the DoD C4ISR Architecture framework.
This framework defines four architecture views with a total of 26 different products. This framework defines what information must be collected to fully define the C4ISR Architectrure.
23 FEB 2001

12. 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.
One of the key means for ensuring interoperable and cost-effective systems is to establish comprehensive architectural guidance.
The Framework provides the rules, guidance and product descriptions for developing and presenting architectural descriptions.
This ensures a common denominator for understanding, comparing, and integrating architectures.
Application of the framework will enable architectures to contribute more effectively to engineering interoperable and cost-effective systems.
Architecture provide a mechanism for managing complexity.
23 FEB 2001

13. IT Life Cycle and CM Policy Consolidation
Information Systems
Technical Architecture
COMDTINST A
Planning Approval
for Automated
Information Systems
(AIS)
COMDTINST
Standard Workstation III
Configuration Management
Policy
COMDTINST
USCG Common Operation Environment (USCG COE)
COMDTINST A
Information Technology
Life Cycle and
Configuration Management
Policy
COMDTINST
IT Systems Development Plan (DRAFT)
COMDTINST
Information Resource Management (cancelled)
COMDTINST
One of the requirements of EAP is one single Configuration Management process with a single entry point. Today the Coast Guard references several such directives addressing IT Architecture configuration management. The policies defined conflict, and have redundancies and gaps.
The CIO has committed to a stretch goal to achieve a dramatic improvement in IT configuration management by consolidating and revising this suite of directives into one single process, with one entry point, with a common set of information requirements, and performance measures.
Consolidated IT
Life Cycle Cfg Mgt
Directive
USCG C4ISR Baseline Architecture
COMDTINST
Standard Terminal Application Software DeploymentCOMDTINST
Other Policy
TBD
23 FEB 2001

14. Benefits Facilitates information services that provide: flexibility,
interoperability,
reliability,
survivability,
affordability,
sustainability,
portability,
reusability,
Adaptability,
Compatibility
The benefits of EAP provide a full menu of "ilities" as benefits.
23 FEB 2001

15. 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: Enterprise Architecture Planning
Steven Spewak
23 FEB 2001

16. 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: Enterprise Architecture Planning
Steven Spewak
Steven Spewak further elaborates the benefits in his EAP publication entitled "Developing a blueprint for data, applications and technology."
23 FEB 2001

17. 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
Finally,this slide communicates Zachman's "pay now, or later" concern.
23 FEB 2001

18. 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)
To maintain the integrity of the architecture, a structured, enforced configuration management process needs to be implemented. All changes to any component of the architecture must pass through this CM process to update the architecture.
23 FEB 2001

19. DISCUSSION
23 FEB 2001

20. JCAPS Benefits Primary - to facilitate change
Structure is best way to organize complicated information
More manageable
Easier to understand
Easier to detect omissions and overlaps (can automate)
With structure, learning something about part,
equals learning something about whole.
Easier to update
Promotes/Supports traceability
Increases the speed and credability of information sharing
Creates opportunity to work faster, more reliably, more economically
Enhances decision-making
Meta data is essential to meet report requirements
23 FEB 2001

21. Definition - Mission A sequence of one or more tasks
executed by an (Actor) entity
to achieve a specific objective
or related set of objectives.
23 FEB 2001

22. Definition - Action
The alteration of an entity which produces a change in state or condition
23 FEB 2001

23. Definition - Task The execution of one or more actions by an entity
23 FEB 2001

24. Definition - Interaction
The interface which defines
the flow of entities, and/or actions
between entities executing tasks
23 FEB 2001

25. Definitions - Miscellaneous
Technical Reference Model - A common framework, probably conceptual, to
define a common vocabulary so as to better develop and aquire some level of
support. It would provide you with a representation of the domain showing
commonality and integration and interoperability.
Common Operating Environment - The set of capabilities that would allow you
to address the suite of integration products that you need to ensure a
cohesive framework of systems for development. Like the DII COE address
architecture, standards, software reuse, shared data, interoperability,
portability, configuration management and integration.
Standards Roadmap - It would start with a common set of mandatory standards
and guidelines. It would then be tailored to the development that was
being implemented. So it would be the "building codes" that would be
reviewed and selected to facilitate the development of the system or
systems needed to be built. (A Technical Architecture View for a
particular area (Defense Transportation System) starting from the DOD Joint
Technical Architecture.)
Dick Webb, ASD(C3I)
23 FEB 2001