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?

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 organizations entities.

4.

• 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 .

What is an Enterprise Architecture? Source: Federal Conceptual Architecture model

5. Examples - Entities Source: U.S. Coast Guard Information Architecture A distinguishable - person - about which information is kept. place, thing, event, concept

6. AOR FACILITIES INFRASTRUCTURE PLATFORMS PERSONNEL Architecture Layers T1 Lines HQ FINCEN MLCP OSC ISC Honolulu D17 AR&SC ISC Boston ISC Ports TISCOM ELC PPC ISC NOLA ISC Mia. ISC St Louis ISC Cleve. CAA MLCA WMEC WPB WLB

7. Some EAP Components

• A standard methodology

• A standard set of templates

• A repository

• A configuration management process

• Easy access

• Ability to export

8. Zachmans Framework for Information Systems Architecture List of Locations Important to Business Node=Major Business Location Data Function Network People Time Motivation List of Things Important to Business Entity=Class of Business Thing

• List of Processes the

• Business Performs

• Function=Class of

• Business Process

List of Organizations Important to Business 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 Diagram Function=Business Process e.g., Data Model Entity=Data Entity Relationship= Data Relationship 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 Location Link=Business Linkage e.g., Program Funct=Language Stmts Arg=Control Blocks e.g., Network Architecture 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 Architecture Agent=Role Work=Deliverable e.g., Security Architecture 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 Architecture End=Criterion Means=Option e.g., Knowledge Design End=Condition Means=Action e.g., Knowledge 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 Analyst Engineer e.g., Master Schedule Time= Business Event Cycle=Business Cycle e.g., Distributed System Architecture Node=Info Sys Funct Link=Line Char Secretary Planners View Owners View Designers View Builders View Subcontractors View

9.

• Acquisition

• Investment decisions

• Modeling & Simulation

• Analysis

• Requirements definition

• Plan baseline

• Describing and understanding baseline

What is an EA used for?

10. DoD C4ISR Architecture Framework 2.0

11. DoD C4ISR Architecture Framework 2.0

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 .

13. Information Systems Technical Architecture COMDTINST 5230.45A USCG Common Operation Environment (USCG COE) COMDTINST 5230.59A Standard Workstation III Configuration Management Policy COMDTINST 5200.16 USCG C4ISR Baseline Architecture COMDTINST 3090.6 Planning Approval for Automated Information Systems (AIS) COMDTINST 5231.2 Information Resource Management (cancelled) COMDTINST 5230.41 Standard Terminal Application Software DeploymentCOMDTINST 5234.3 Information Technology Life Cycle and Configuration Management Policy COMDTINST 9999.99 IT Life Cycle and CM Policy Consolidation IT Systems Development Plan (DRAFT) COMDTINST 9999.99 Other Policy TBD

14. Benefits Facilitates information services that provide: flexibility, interoperability, reliability, survivability, affordability, sustainability, portability, reusability, Adaptability, Compatibility

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

16. Benefits to the Business of planned systems

• More responsive to customers 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

17.

• • • "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 thats your assessment

• • • You cant complain that

• • • the systems arent aligned with the enterprise,or

• • • are inflexible,

• • • or cost too much,

• • • or that vital information is not available,

• • • or that the data you get isnt any good, or too late,

• • • or you cant change anything,

• • • or that I/S is slow and unresponsive

• • • and, I am here to tell you

• • • Outsourcing isnt going to fix the problem.

• • • Packages (in themselves) wont fix the problem.

• • • Decentralization wont fix the problem.

• • • And, the Internet isnt 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

Zachman reflections on EA Planning

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)

19. DISCUSSION

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

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.

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

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

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

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)