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? 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

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

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

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

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

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

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

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

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

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

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

IT Life Cycle and CM Policy Consolidation Information Systems Technical Architecture COMDTINST 5230.45A Planning Approval for Automated Information Systems (AIS) COMDTINST 5231.2 Standard Workstation III Configuration Management Policy COMDTINST 5200.16 USCG Common Operation Environment (USCG COE) COMDTINST 5230.59A Information Technology Life Cycle and Configuration Management Policy COMDTINST 9999.99 IT Systems Development Plan (DRAFT) COMDTINST 9999.99 Information Resource Management (cancelled) COMDTINST 5230.41 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 3090.6 Standard Terminal Application Software DeploymentCOMDTINST 5234.3 Other Policy TBD 23 FEB 2001

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

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

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

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

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

DISCUSSION 23 FEB 2001

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

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

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

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

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

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