IT Governance & EA Standards 2011 Sep 11 Gold

Technology Services IT Standards Document

IT Governance Enterprise Architecture Architecture Modeling

Technology Services keeping you informed

KH ETP/JEA Page 1 of 58

EXECUTIVE SUMMARY - TECHNOLOGY SERVICES GOVERNANCE, ARCHITECTURE & STANDARDS................4 MANAGEMENT DIRECTIVES..................................................................................................................................................................4 COBIT GOVERNANCE ANALYSIS............................................................................................................................................5 COBIT BACKGROUND JEA CURRENT STATE....................................................................................................................5 COBIT OVERVIEW.......................................................................................................................................................................6 COBIT EXECUTIVE SUMMARY...............................................................................................................................................................6 COBIT FRAMEWORK...........................................................................................................................................................................6 COBIT CONTROL OBJECTIVES...............................................................................................................................................................6 COBIT IMPLEMENTATION TOOL SET.......................................................................................................................................................6 COBIT MANAGEMENT GUIDELINES........................................................................................................................................................6 COBIT AUDIT GUIDELINES...................................................................................................................................................................7 COBIT MAPPING...............................................................................................................................................................................7 JEA MAPPING..................................................................................................................................................................................7 CASE STUDY..................................................................................................................................................................................8 CASE STUDY..................................................................................................................................................................................9 IT GOVERNANCE RECOMMENDATIONS JEA FUTURE STATE....................................................................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA BEST PRACTICES............................................................................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA COBIT DOMAINS...........................................................................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA PLANNING & ORGANIZATION HL CONTROL OBJECTIVES........................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA ACQUISITION & IMPLEMENT HL CONTROL OBJECTIVE...........................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA MONITOR & EVALUATE HL CONTROL OBJECTIVES..............................................10 IT GOVERNANCE STANDARD RECOMMENDATIONS FOR JEA DELIVERY & SUPPORT HL CONTROL OBJECTIVES................................................11 IT GOVERNANCE ALTERNATIVES........................................................................................................................................11 TOGAF ENTERPRISE ARCHITECTURE ANALYSIS............................................................................................................12 ENTERPRISE ARCHITECTURE BACKGROUND JEA CURRENT STATE.....................................................................12 ENTERPRISE ARCHITECT.....................................................................................................................................................................13 SOFTWARE/APPLICATION ARCHITECT....................................................................................................................................................13 SYSTEM ARCHITECT..........................................................................................................................................................................13 DATA ARCHITECT............................................................................................................................................................................13 SECURITY ARCHITECT.......................................................................................................................................................................13 JEA ARCHITECTURE PROCESS REPOSITORY ARCHITECTURE PROCESSES...................................................................................................15 JEA ARCHITECTURE REPOSITORY TS ARCHITECTURES.......................................................................................................................16 JEA ENTERPRISE ARCHITECTURE REPOSITORY ENTERPRISE ARCHITECTURE COMPONENTS............................................................................16 JEA SECURITY ARCHITECTURE REPOSITORY SECURITY ARCHITECTURE COMPONENTS..................................................................................16 JEA APPLICATION ARCHITECTURE REPOSITORY APPLICATION ARCHITECTURE COMPONENTS.........................................................................16 JEA DATA ARCHITECTURE REPOSITORY DATA ARCHITECTURE COMPONENTS............................................................................................17 JEA SYSTEM ARCHITECTURE REPOSITORY SYSTEM ARCHITECTURE COMPONENTS......................................................................................17 TOGAF OVERVIEW...................................................................................................................................................................17 TOGAF AND ARCHITECTURE GOVERNANCE.........................................................................................................................................18 THE ENTERPRISE ARCHITECTURE CONTINUUM........................................................................................................................................18 ENTERPRISE ARCHITECTURE RECOMMENDATION JEA FUTURE STATE..............................................................18 JEA ARCHITECTURE PROCESS REPOSITORY ARCHITECTURE PROCESSES...................................................................................................19 THE RECOMMENDED FUTURE STATE TOGAF BASED JEA ENTERPRISE ARCHITECTURE FRAMEWORK (JEAF):....................................................19 ENTERPRISE ARCHITECTURE FRAMEWORK PRINCIPLES:.............................................................................................................................21 THE JEA ENTERPRISE ARCHITECTURE PRINCIPLES SHALL CONTAIN THE FOLLOWING COMPONENTS:......................................................................22 EXAMPLE SET OF ARCHITECTURE PRINCIPLES.........................................................................................................................................23 Technology Services keeping you informed KH ETP/JEA Page 2 of 58

CURRENT JEA EA GUIDING PRINCIPLES..............................................................................................................................................28 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES REUSE BEFORE BUY...................................................................28 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES BUY BEFORE BUILD...................................................................28 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES BUILD REUSABLE COMPONENTS....................................................28 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES BUILD USING N-TIER MODELS....................................................28 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES USE STANDARD BASED SOLUTIONS...............................................29 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES STANDARD SET OF USER SERVICES................................................29 ENTERPRISE ARCHITECTURE FOUNDATIONAL PILLAR GUIDING PRINCIPLES EA INITIATIVES ARE BUSINESS DRIVEN..........................................29 JEA BUSINESS ARCHITECTURE REPOSITORY TS BUSINESS ARCHITECTURE COMPONENTS...........................................................................32 JEA GOVERNANCE ARCHITECTURE REPOSITORY GOVERNANCE ARCHITECTURE COMPONENTS.......................................................................32 JEA ENTERPRISE ARCHITECTURE REPOSITORY ENTERPRISE ARCHITECTURE COMPONENTS............................................................................32 JEA APPLICATION ARCHITECTURE REPOSITORY APPLICATION ARCHITECTURE COMPONENTS.........................................................................32 JEA DATA ARCHITECTURE REPOSITORY DATA ARCHITECTURE COMPONENTS............................................................................................33 JEA SYSTEM ARCHITECTURE REPOSITORY SYSTEM ARCHITECTURE COMPONENTS......................................................................................33 JEA SECURITY ARCHITECTURE REPOSITORY SECURITY ARCHITECTURE COMPONENTS..................................................................................33 JEA SOLUTION ARCHITECTURE REPOSITORY SOLUTION ARCHITECTURE COMPONENTS.................................................................................33 JEA ENTERPRISE CONTINUUM ENTERPRISE ARCHITECTURE BEST PRACTICES................................................................................................34 ENTERPRISE ARCHITECTURE ALTERNATIVES................................................................................................................34 UNIFIED MODELING LANGUAGE ANALYSIS .....................................................................................................................36 UML BACKGROUND JEA CURRENT STATE.....................................................................................................................36 JEA TECHNOLOGY SERVICES ENTERPRISE VISION COMPONENTS................................................................................................................36 JEA SIX PROBLEM STATEMENTS.........................................................................................................................................................36 UML OVERVIEW........................................................................................................................................................................37 GOALS OF UML.............................................................................................................................................................................37 WHY USE UML?...........................................................................................................................................................................37 SCOPE OF THE UML........................................................................................................................................................................39 OUTSIDE THE SCOPE OF THE UML......................................................................................................................................................40 UML SUMMARY.............................................................................................................................................................................40 UML RECOMMENDATIONS JEA FUTURE STATE...........................................................................................................41 USER MODELING LANGUAGE PRINCIPLES:.............................................................................................................................................42 UML GUIDING PRINCIPLES: MODEL SELECTION..................................................................................................................................42 UML GUIDING PRINCIPLES: MODEL FIDELITY....................................................................................................................................42 UML GUIDING PRINCIPLES: MODEL CONNECTION TO REALITY..............................................................................................................42 UML GUIDING PRINCIPLES: MULTIPLE MODEL VIEWS.........................................................................................................................42 USE CASE PATTERNS FRAMEWORKS AND ARCHITECTURES:.......................................................................................................................43 USE CASE STANDARD BRIEF USE CASE PATTERN FOR TREASURY APPLICATION........................................................................................43 USE CASE STANDARD CASUAL USE CASE PATTERN FOR TREASURY APPLICATION.....................................................................................43 USE CASE STANDARD FULLY DRESSED USE CASE PATTERN FOR TREASURY APPLICATION..........................................................................44 USE CASE SCENARIOS:......................................................................................................................................................................45 USE CASE STANDARD SUCCESS SCENARIO FOR TREASURY APPLICATION..................................................................................................45 USE CASE STANDARD SCENARIO FOR COMPUTER BASED TRAINING........................................................................................................45 USE CASE STANDARD SCENARIO FOR NORTH-SIDE GENERATING STATION................................................................................................45 USE CASE STANDARD SCENARIO FOR CAIR SYSTEM..........................................................................................................................45 USE CASE MODEL PATTERN: TREASURY BUSINESS SYSTEM:.....................................................................................................................46 USE CASE MODEL PATTERN: COMPUTER BASED TRAINING:.....................................................................................................................51 USE CASE MODEL PATTERN: NORTH-SIDE GENERATING STATION..............................................................................................................52 USE CASE MODEL PATTERN: CAIR SYSTEMS......................................................................................................................................53 UML ALTERNATIVES................................................................................................................................................................57 EXECUTIVE CONCLUSION......................................................................................................................................................57 REFERENCE SHEET:...............................................................................................................................................................58



JEA IT Governance, Enterprise Architecture & Modeling StandardsExecutive Summary - Technology Services Governance, Architecture & StandardsThe Technology Services 5 Year IT Strategic Business Plan provides for an Enterprise Architecture Initiative whose primary purpose is to align Technology Services with JEA Corporate Business strategies, goals and objectives. The Technical Services (TS) business plan includes the JEA Six Problem Statements and the corresponding Mitigation Strategies, which will be implemented by the processes of the executable Enterprise Architecture. JEA TS Business Plan provides an IT Governance Framework to measure the benefits and mange the risk of the IT Enterprise Architecture processes. JEA IT governance is all about the Quality, Fiduciary and Security information business requirements. The beneficiaries & primary stakeholders of the IT Governance Framework include, but it is not limited to:

Business & IT Management Business Process Owners

External & Internal Auditors Users of the Technology Services

The JEA Executive Management including the VP of Technology Services, who owns the TS 5 Year Business Plan, has documented their commitment for the execution of an Enterprise Architecture Initiative, Security Initiative and the adaptation of the Control Objective for Information and other Related Technology (CobiT) by the TS Business Plan and these Management Directives: Management Directives Information Technology Governance

The Vice President of Technology Services (TS) will maintain the JEA Information Technology portfolio of assets and services. The JEA IT portfolio will be acquired, managed, maintained and retired in compliance with: JEAs Purchasing Code, ISO 17799, CobiT and CMM/CMMI. JEA shall provide an internal auditing function to examine and evaluate the effectiveness of established controls of all organization operations. The Director of Audit Services shall assist management by analyzing and appraising JEA activities and offering recommendations and information. The Director of Distribution Information Services is responsible for developing and maintaining current procedures for the classification, accessibility/availability and safeguard of JEA information assets including long distance communication capability networks. Data owners are responsible for the classification of their assigned applications. The Director of Talent Acquisition & Development is responsible for providing basic and refresher training to employees regarding responsibility for data. Every employee is responsible for data they handle. JEA shall diligently apply efforts in the implementation of all the auditors recommendations. In this regard, JEA shall provide a central point of record for the auditors recommendations that can be updated by managers during the implementation process. This record shall be closely monitored until all of the auditors recommendations have been implemented. A progress report shall be periodically submitted to the Executive Management Team until the recommendations have been implemented. The Director of Audit Services is responsible for providing the required central storage of auditors recommendations, programs and/or related procedures. All managers are responsible for the implementation of auditors recommendations pertaining to their areas and for maintaining a current status update in the central storage area.

Internal Auditing

Information Resources

Auditors Recommendations



CobiT Governance AnalysisInformation Technology Governance has been identified by the Industry as a necessary discipline for a successful Business Enterprise. CobiT, which stands for the Control Objective for Information and other related Technology, is the defacto standard for IT Governance. JEA has standardized on CobiT for its IT Governance framework and is now ready to take the next steps, the implementation and institutionalization of CobiT. The purpose of this CobiT IT Governance Analysis is to research CobiT IT Governance as it relates to the JEA Technology Services Business Plan and its associated Management Directives. The output of this Analysis shall be a CobiT recommendation for JEAs IT Governance implementation and subsequently the institutionalization of CobiT.

CobiT Background JEA Current StateJEA has implemented key components of the Enterprise Architecture using the CobiT IT Governance. The JEA System Security Plan (SSP) and each Application System Security Plan has conformed to the Ten Domains of Security based on the CobiT framework as well as other standards and regulations which CobiT has adopted (See CobiT Mapping). The JEA Security GAP Analysis performed by the JEA Security Team was also in conformance with the CobiT framework. The JEA IT Governance is all about the business. Other JEA Key initiatives subject to CobiT also include PMO and TII. The JEA Technology Services Business Plan has scoped the CobiT IT Governance to include all four CobiT Domains and all thirty-four CobiT processes or high-level control objectives as documented in the CoBIT IT Governance framework document. JEAs Technology Service Five Year Business Plan has authorized and initialized the implementation and institutionalization of CobIT as the standard for the JEA IT governance framework. CobIT is also the international de-facto standard for IT governance. CobiT also defines its process improvement methodology as an IT Maturity Model (ITMM). JEA has adopted the CobiT methodology for standard measurements of Quality using Critical Success Factors, Key Goal Indicators and Key Performance Indicators. These metrics and the ITMM provides a basis for Management Guidelines. The CobiT audience and primary stakeholders includes JEA Management, Business Process Owners, Technology Users and Auditors. CobiT is focused on the JEA Technology Services Business Strategy and vision and is executed by meeting the following category of Technology Services (TS) business requirements:

Quality Fiduciary Security

The common link between the JEA Business Enterprise and the TS Technical Architecture will be the information. The information requirements have the following attributes:

Effectiveness Efficiency Confidentiality Integrity Availability Compliance Reliability

CobiT Standards provide an uniform method for Risk Assessment based on how information is measured in terms of meeting the Quality, Fiduciary and Security requirements posed on information in terms of effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability. The JEA business depends on this information for business processes. CobiT measures the benefits and manages the risk of the information to be processed at JEA. Technology Services keeping you informed KH ETP/JEA Page 5 of 58

CobiT OverviewBusiness orientation is the main theme of COBIT. The design is to be deployed, not only by users of Technology Services and auditors. but also, and more importantly, as comprehensive guidance for management and business process owners. Increasingly, business practice involves the full empowerment of business process owners so they have total responsibility for all aspects of the business process. In particular, this includes providing adequate controls. The COBIT Framework provides a tool for the business process owner that facilitates the discharge of this responsibility. The Framework starts from a simple and pragmatic premise: In order to provide the information that the organization needs to achieve its objectives, IT resources need to be managed by a set of naturally grouped processes. The Framework continues with a set of 34 high-level Control Objectives, one for each of the IT processes, grouped into four domains: planning and organization, acquisition and implementation, delivery and support, and monitoring. This structure covers all aspects of information and the technology that supports it. By addressing these 34 high-level control objectives, the business process owner can ensure that an adequate control system is provided for the IT environment. The CobiT standard for IT Governance is packaged and delivered as seven separate documents. The seven document names and a description of their contents have been captured in the tables below: CobiT Executive Summary Sound business decision is based on timely, relevant and concise information. Specifically designed for time-pressed senior executives and managers, the COBIT Executive Summary explains COBITs key concepts and principles.

CobiT Framework A successful organization is built on a solid framework of data and information. The Framework explains how IT processes deliver the information that the business needs to achieve its objectives. This delivery is controlled through 34 high-level control objectives, one for each IT process, contained in the four domains. The Framework identifies which of the seven information criteria (effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability), as well as which IT resources (people, applications, technology, facilities and data) are important for the IT processes to fully support the business objective.

CobiT Control Objectives The key to maintaining profitability in a technologically changing environment is how well you maintain control. COBITs Control Objectives provides the critical insight needed to delineate a clear policy and good practice for IT controls. Included are the statements of desired results or purposes to be achieved by implementing the 318 specific, detailed control objectives throughout the 34 high-level control objectives.

CobiT Implementation Tool Set The Implementation Tool Set contains management awareness and IT control diagnostics, implementation guide, frequently asked questions, case studies from organizations currently using COBIT and slide presentations that can be used to introduce COBIT into organizations. The tool set is designed to facilitate the implementation of C OBIT, relate lessons learned from organizations that quickly and successfully applied COBIT in their work environments and assist management in choosing implementation options. CobiT Management Guidelines To ensure a successful enterprise, you must effectively manage the union between business processes and information systems. The new Management Guidelines is composed of maturity models, critical success factors, key goal indicators and key performance indicators. These Management Guidelines will help answer the questions of immediate concern to all those who have a stake in enterprise success. Technology Services keeping you informed KH ETP/JEA Page 6 of 58

CobiT Audit Guidelines Analyze, assess, interpret, react, implement. To achieve your desired goals and objectives you must constantly and consistently audit your procedures. Audit Guidelines outlines and suggests actual activities to be performed corresponding to each of the 34 high-level IT control objectives, while substantiating the risk of control objectives not being met.

CobiT Mapping This is the first deliverable of the COBIT Mapping research project, which focuses on the business drivers for implementing the guidance, as well as the risks of noncompliance with the guidance. Furthermore, it contains a classification of the guidance publications, a short overview of their content, and how they align or map to COBIT. Although most of these questions can be addressed using the openly available COBIT guidance, several have remained unresolved, until now. As a result, this project was initiated to map the most important and commonly used standards and guidance to the COBIT processes and control objectives. The term standard is used in this document to encompass guidance publications. This document does not contain the result of detailed mappings; it merely gives an overview of the most popular guidance for managing IT, or at least parts of the tasks and duties of IT. In 2004, the IT Governance Institute will publish the results of the second phase of the project, a detailed mapping of common guidance with the COBIT framework, beginning with ISO/IEC 17799:2000. This research is limited to the publications in the following list, which is not exhaustive, as there are other documents and information sources available. The following is a brief overview of the guidance discussed in this research:

COBIT Control Objectives for Information and related Technology was originally released as an IT process andcontrol framework linking IT to business requirements. It was initially used mainly by the assurance community in conjunction with business and IT process owners. Beginning with the addition of Management Guidelines in 1998, COBIT is now being used more and more as a framework for IT governance, providing management tools such as metrics and maturity models to complement the control framework.

ITILThe IT Infrastructure Library is a collection of best practices in IT service management. It is focused on theservice processes of the IT and considers the central role of the user.

ISO/IEC 17799:2000The Code of Practice for Information Security Management is an international standard,based on BS 7799-1. It is presented as best practice for implementing information security management.

NIST 800-14The special publication Generally Accepted Principles and Practices for Securing InformationTechnology Systems contains information for establishing a comprehensive IT security program. COSOIntegrated Framework defines a framework that initiates an integrated process of internal control.

JEA Mapping

COBIT ITIL

JEA TS 5-Year Business Plan instantiation of Cobit provides for the IT Governance Framework. JEA IT Services Model will benefit from the best practices in services management from ITIL.

ISO/IEC 17799 The JEA TS SSP & Essential Business Systems Application SSP primary Standard is ISO-1779. NIST 800-14 COSO The NIST 800 Standard served as a Pattern for the SSP & Essential Business Systems SSP. JEA Adaptation of COSO is supported through the TS IT Governance Standardization on Cobit.



Case Study

JOHN BEVERIDGE, CISAFOR BOSTON GAS COMPANY

USAABSTRACT COBIT was carefully studied to learn its benefits and determine how it would most benefit Boston Gas. Consistent with the Internal Audit departments strategy to provide value-added auditing services, COBIT has served as a benchmark for best practices of control and criteria for review. BACKGROUND Boston Gas Company, a public utility, employs 1,400 and generates US $700 million per year. It serves 74 cities and towns in the greater Boston, MA, USA, area. Its IT environment is primarily driven by IBM mainframe, UNIX, Novell and NT platforms and networks. PROCESS The Internal Audit Manager and an IS auditor obtained COBIT when it was published in 1996 and soon after participated in a COBIT presentation sponsored by the New England Chapter of ISACA. Convinced that COBIT could benefit Boston Gas in developing IT related policies and procedures and performing IT audits, the managers introduced COBITs principles to the Vice President of IS and members of the IS staff. As a result of this presentation, several customized, successful uses of COBIT were identified, including: The Director of Internal Audit indicated that the department would adopt COBIT as a review standard so goal posts for review would be clearly communicated. The IS department adopted COBIT as a benchmark and set of control objectives and guidelines against which to measure current and future IS functions and projects. CONCLUSION The success of introducing COBIT and having Internal Audit and the IT departments adopt it rested on their becoming familiar with the control framework, obtaining training and focusing their time on implementing its principles. COBIT has provided added value to the utility by focusing on the overall business objective while strengthening IT controls.



Case StudyOFFICE OF THE STATE AUDITOR OF MASSACHUSETTS UNITED STATES ABSTRACT The Office of the State Auditor is the principal governmental audit entity for state government in Massachusetts. We have used COBIT extensively in audit selection, on individual engagements and for substantiating results. COBIT assists our teams in identifying IT audits and framing them to one or more domains or sets of control objectives. BACKGROUND Our audits provide the governor, legislature, auditees, oversight entities and the public with an independent evaluation of state functions and activities. The IT audit division performs integrated, financial-related, operational and IT audits in a multi-platform environment which includes 20 large data centers and more than 150 small to medium facilities in more than 600 audit entities. PROCESS Our IT audit management team used a phased approach where some members of our IT audit staff were introduced to the Framework, Control Objectives and Audit Guidelines for use on their audits. The team selected audits where IT facility examinations would be included in the scope and for a system under development audit of a particular application system. Once the management team and selected senior auditors were familiar enough with COBIT to assist other staff, the entire IT audit staff was given a two-day training session on the control model and related products. Using COBIT on a pilot basis provided an excellent insight into its application and appropriate experiences upon which to develop the training. In pre-audit work COBIT helps identify high risk IT processes and assess the IT control environment. By reviewing organizational and IT policies against COBITs high-level and detailed control objectives, the team quickly focuses on areas to be included in the audit scope or potential management advisory services work. During pre-audits, our team uses the COBIT framework and control objectives to facilitate interview discussions. Identification of data and information requirements and sources are referenced to COBITs business requirements for information. This assists audit teams and auditees in discussions on control objectives and control policy, procedures and standards. COBITs focus on control objectives and their related purpose to the business organization has supported audit managements efforts to move away from checklist auditing. We continue to strengthen our audit planning process and understanding of fundamental control objectives for IT by implementing COBITs principles. CONCLUSION At the start of the engagement, the audit team references COBIT during entrance conferences as one of their primary audit criteria. It is an authoritative source that lends credibility to the review criteria, and when shared with the auditee, provides excellent opportunities for constructive audit work. This has helped auditees understand the basis of the review from the start. Furthermore, our team found that COBITs use dovetails with the Committee of Sponsoring Organizations (COSO) and current changes to auditing standards (e.g., implementation of SAS 70 and 78). COBITs audit guidelines also can be used to develop audit work programs. COBIT also is useful in helping auditees evaluate and strengthen internal controls. There is a tremendous benefit for them to be better prepared for upcoming audits. Being aware of the review criteria means that auditees are aware of the control practices recommended for the IT processes. COBITs organization makes it easy for the auditee to relate to and interpret auditors requests for information and subsequent recommendations. Our experience with COBIT also has assisted entry level auditors gain an understanding of IT processes and detailed control objectives, and to frame that to the auditee organization and IT environment. By implementing COBIT we identified the need to enhance and amend generic audit guidelines, audit procedure manuals and quality assurance reviews. Across the board we have achieved increased consistency of discussions regarding IT domains, control objectives and IT



IT Governance Recommendations JEA Future StateThe recommendations of this IT Governance analysis includes the following CobiT IT components for implementation into the JEA IT Governance Standard: IT Governance Standard Recommendations for JEA Best Practices CobiT Executive Summary CobiT Management Guidelines CobiT Framework CobiT Control Objectives CobiT Implementation Tool Set CobiT Audit Guidelines CobiT Mapping CobiT CD ROM with Power Point Presentations & Case Studies

IT Governance Standard Recommendations for JEA CobiT Domains Planning & Organizations PO1 PO11 Delivery & Support DS1 - DS13 Acquisition & Implementation AI1 AI6 Monitoring M1 M4

IT Governance Standard Recommendations for JEA Planning & Organization HL Control Objectives PO1 Define a Strategic Information Technology Plan PO7 Manage Human Resources PO2 PO3 PO4 PO5 PO6 Define the Information Architecture Determine the Technological Direction Define the IT Organization and Relationships Manage the investment in Information Technology Communicate Management Aims & Directions PO8 PO9 PO10 PO11 Ensure Compliance with External Requirements Assess Risk Manage Projects Manage Quality

IT Governance Standard Recommendations for JEA Acquisition & Implement HL Control Objective AI1 Identify Automated Solutions AI4 Develop & Maintain IT Procedures AI2 AI3 Acquire & Maintain Application Software Acquire & Maintain Technology Infrastructure AI5 AI6 Install & Accredit Systems Manage Changes

IT Governance Standard Recommendations for JEA Monitor & Evaluate HL Control Objectives M1 Monitor the Process M3 Obtain Independent Assurance M2 Assess Internal Control Adequacy M4 Provide for Independent Audit



IT Governance Standard Recommendations for JEA Delivery & Support HL Control Objectives DS1 Define & Manage Service Levels DS7 Educate & Train Users DS2 DS3 DS4 DS5 DS6 Manage Third Party Services Ensure Continuous Service Ensure Continuous Service Ensure Systems Security Identify & Allocate Cost DS8 DS9 DS10 DS11 DS12 DS13 Assist & Advise Customers Manage the Configuration Manage Problems & Incidents Manage Data Manage Facilities Manage Operations

The seven CobiT IT Governance Best Practice documents and the thirty-four high-level control objectives have been scoped to be included in the JEA IT Governance standard. The JEA Technology Services 5 Year Business Plan explicitly maps all thirty-four high-level control objectives for the JEA IT Governance Framework. However each high-level control objective has several low-level control objectives associated with it. The JEA IT Governance Framework Standard will adapt all 318 low-level IT Control Objectives. The JEA standard will also support the models, methods and concepts of assuring quality and measuring benefits:

Process Enablers Critical Success Factors Key Goal Indicators Key Performance Indicators IT Maturity Model (CMMI/ITMM)

IT Governance AlternativesJEA has selected CobiT and all 318 of its lowlevel control objectives to be within the scope of the JEA IT Governance standard, however all 318 low-level processes may not be needed. Alternatively the JEA Enterprise Architects and Business Process owners may determine which of the 318 low-level objectives are required by the business. The method for making this determination would be to perform a Risk Assessment of the current IT processes. The overall cost of implementing CobiT across the JEA organization may incur Capitol cost as well as O&M cost. A cost benefit analysis may be needed to cost justify a separate risk analysis since the likely hood that the business requirements will justify most of the 318 control objectives is monumental. After saying that, we must also adhere to CobiT IT Governance principles of having clearly defined goals and control objectives to meet JEA business requirements. Alternatively, as a cost savings innovation, a previous recommendation from an outside consulting firm selected 25 of the 34 high level control objectives that TS should focus on. These priorities are exposed in the working Strategy document. The end result of the CobiT Control Objectives is that each member of the IT organization understanding of authority must be clear & concise. Each member must also understand their unique role in relationship to the Roles and Responsibilities of the Business Thought Leaders, as well as key stakeholders in the IT community. The Boston Gas Company Case Study presented above can also be a success scenario for JEA. The fact that this case study involves a successful implementation of Cobit within a public utility, with similar IT internal controls as JEAs Internal Auditing process, serves as proof of concept for JEAs Technology Services IT Governance initiative.



TOGAF Enterprise Architecture AnalysisEnterprise Architecture has been identified by the Industry as a necessary discipline for a successful Business Enterprise. While there are several best practice Enterprise Architecture Frameworks, The Open Group Architecture Framework is in a category by itself. TOGAF is not limited to being yet another static Enterprise Architecture Framework, but it is an Enterprise Architecture development framework that can and should include other best practice Enterprise Architecture Framework components. JEA has standardized on TOGAF. The results of this document will be a recommendation of the specification for the JEA Enterprise Architecture using TOGAF as the Architecture Framework development methodology.

Enterprise Architecture Background JEA Current StateThe JEA Enterprise Architecture has been one of the target Initiatives of the Technology Services 5 Year Business Plan. This Enterprise Architecture Initiative is part of the Technology Services strategy of meeting the JEA business goals and objectives. The JEA Enterprise Architecture initiative is charged with aligning Technology Services with the JEA Enterprise business strategy, goals and objectives. The JEA Executive Management including the VP of Technology Services has documented their Due Diligence and support of the JEA Enterprise Architecture Initiative within the Business Plan and the supporting Management Directives. The JEA Enterprise Architecture Team has partnered with the JEA Project Management Office (PMO) to deliver the Enterprise Architecture (EA) Initiative. The PMO has developed Role and Responsibilities for the EA organization:

Enterprise Architecture OrganizationVP, Technolgoy VP, Technolgoy Services Services

Enterprise Enterprise Architect Architect

Applications Applications Architect Architect

Data Data Architect Architect

Systems Systems Architect Architect

Security Security Architect Architect

The EA organizations ability to meet the JEA TS business requirements will be measured in consideration of Critical Success Factors (CSF), Key Performance Goal Indicators (KGI), Key Performance Indicators (KPI) and the Enterprise Architecture Maturity Model (EAMM) within the scope of CMMI. The JEA Enterprise Architecture development program is in the Initialization stage of its Enterprise Architecture Development Life Cycle (EADLC). It has been developed to date using various structured components and processes. The individuals performing the EA processes will be accountable based on the PMO defined Enterprise Architecture Roles and Responsibilities:



Enterprise Architect Enterprise Architects are focused at the IT enterprise level and connectivity between multiple applications. Enterprise Architects are geared to be more proactive, less reactive; more strategic, less tactical. Enterprise Architects provide guidance to the Software/Application Architects who apply enterprise standards and guidelines at the project level. Enterprise Architects focus on the interfaces, information flow and application software compatibility with enterprise standards. Enterprise Architect builds the architecture framework to support the enterprise business model. Software/Application Architect Selects the paradigm and technology for application program-to-program communication (APPC) among the components. Responsible for defining the application tiers, frameworks, components types and interfaces. Creates the first-draft graphical template of UML design models used by the Business Analyst. Oversees the requirements management process as it relates to the generation of use cases and the UML overall. Oversees the UML process used by the Project Team to model the application system. Specifies and provides ownership of reusable application components or reusable application code. System Architect

Focuses on the standards and technologies for enabling systems performance qualities, such as availability, scalability, recoverability, etc. Evaluates and selects the enterprises server hardware, operating system, job control. Supports the Software/Applications architect in selecting the application framework.

Balances the quality issues cost vs. robustness, and hardware architecture, such as share-nothing ntier vs. share-all symmetric multi-processing (SMP). Monitors performance benchmarks provided by the Transaction Processing Council (TPC). In conjunction with the Software/Application Architect sizes the application and selects the hardware and configuration to use. Participates in the drafting of Service Level Agreements (SLA: platinum, Gold, Bronze). Establishes a process to monitor existing systems for performance problems and drafts system migration plan when necessary.Data Architect

Sets Data Policy and the technical solution for the management, storage, access, navigation, movement, and transformation of data. Specifies recommended DBMS and ETL tools and technologies for structured and unstructured content. Creates and maintains the Metadata Repository. Creates a semantically rich business model of the enterprise problem domain that: Is independent of any technology solution Defines the Content of the business Compiles and maintains the Enterprise Schema across all applications. Enforces principles of good canonical data design. Examines and enforces opportunities to provide data reuse, balancing the issues of centralization and replication. Ensures the preservation of strategic data assets as applications and technologies de jure come and go. Reviews the policies and work of the Data Base Administrators.Security Architect

Monitors security guidelines, such as CobiT. Establishes and enforces the Security Policy and Trust Model for Administrators to follow in delegating and granting application privileges.Technology Services keeping you informed KH ETP/JEA Page 13 of 58

Establishes and enforces the Security Model, technologies and standards for system architects and designers. Tracks warnings of new security threats and assures that the systems in place guard against these threats. Establishes the systems for discovering, tracking and convicting abusers of security and system integrity. Performs periodic security audits on existing systems.The Enterprise Architecture organization has formed the Enterprise Architecture Team, which is led by the Director of Enterprise Architecture and includes JEA internal and external Architects. The weekly EA meetings facilitate Enterprise Architecture processes, activities and tasks. The team has developed the JEA Enterprise Architecture Framework (JEAF):



JEA Enterprise Architecture FrameworkJEA Enterprise Architecture Framework TS Governance Architecture TS Governance Architecture CObIT, Management Directive CObIT, Management Directive TS Buisness Architecture PMO, SEG, NT, Core Apps Enterprise Architecture Foundational Pillars EA Guiding Principles Reuse Before Buy Buy Before Build Build Reusable Components Build Using N-Tier Models Use Standards Based Solutions Standard Set of User Services EA Initiatives are Business Driven Domain Blueprints EA Standards TOGAF OMB FEA NIST EAM GAO Best Practice AEAF C4ISR EAMM FEAF MAEA TEAF Zachman Product Blueprints Regulations The ClingerCohen Act EA Policies Lifecycle Policy

Discipline Blueprints

Compliance Blueprints

Application Architecture Principles, Standards, Best Practices, Regulations, Policies

Data Architecture Principles, Standards, Best Practices, Regulations, Policies

Enterprise Architecture Repository & Artifacts System Architecture Principles, Standards, Best Practices, Regulations, Policies Security Architecture Principles, Standards, Best Practices, Regulations, Policies

Enterprise Architecture Tools

Emerging Technology

Current Technology

Twilighting Technology

Sunseting Technology

Processes B1028, B1028.Enterprise, B1028.Apps, B1028.Data, B1028.Systems, B1028.Security Procedures Deliverables Services, Products, Initiatives

The JEA Enterprise Architecture Team has developed several EA processes, repositories, artifacts, blueprints and technical reference models. This table is a non-exhaustive list of JEAs current Enterprise Architecture components: JEA Architecture Process Repository Architecture Processes JEA Architecture Lifecycle Processes ASP4, Metrics, Educate, Assessment, Improvements Technology Services keeping you informed KH ETP/JEA Page 15 of 58

TS Business Architecture Processes TS Governance Architecture Processes Enterprise Architecture Processes Application Architecture Processes

Data Architecture Processes Systems Architecture Processes Security Architecture Processes

JEA Architecture Repository TS Architectures JEA Governance Architecture Project Charter Template TS Business Architecture TS Governance Architecture Enterprise Architecture Application Architecture Data Architecture Systems Architecture Security Architecture

JEA Enterprise Architecture Repository Enterprise Architecture Components JEA Enterprise Architecture Project Charter Template EA Initiative & Project Charter EA Solutions EA Project Management EA Foundational Pillars EA Policies EA Blue Prints EA Artifacts EA Tools

JEA Security Architecture Repository Security Architecture Components JEA Security Architecture Project Charter Template Security Initiative & Project Charter Security Architecture Blue Prints Security Architecture Project Management Security Architecture Foundational Pillars Security Architecture Principles Security Architecture Governance Security Architecture Standards Security Architecture Regulations Security Architecture Best Practices Security Architecture Methodologies Security Architecture Policies Security Architecture Processes & Procedures

JEA Application Architecture Repository Application Architecture Components JEA System Architecture Project Charter Template TII Initiative & Project Charter Application Solutions Technology Services keeping you informed Application Foundational Pillars Application Policies KH ETP/JEA Page 16 of 58

Application Project Management

Application Blue Prints & Artifacts

JEA Data Architecture Repository Data Architecture Components JEA Data Architecture Project Charter Template TII Initiative & Project Charter Data Solutions Data Project Management Data Foundational Pillars Data Policies Data Blue Prints & Artifacts

JEA System Architecture Repository System Architecture Components JEA System Architecture Project Charter Template TII Initiative & Project Charter System Solutions System Project Management System Foundational Pillars System Policies System Blue Prints & Artifacts

The Enterprise Architecture repositories above contain many Application, System, Data, Security & Enterprise Architecture components, including Application System Blueprints and artifacts such as those in the short list below:

CAIR & other Essential Business Systems Applications System Security Blue Prints The CAIR Role Based Access Control Security Reference Model The Architecture Life Cycle Process: 1. Establish ASP4: 2. Metrics 3. Educate 4. Assessment 5. Improvement s

Authorit y

Standard s

Policy, Plans, Processes & Procedures

Enterprise Architecture at JEA has got off to a great start, however the EA processes must be improved and the capability must mature. The JEA Enterprise Architecture Team has standardized on TOGAF as the standard for its Enterprise Architecture Development Methodology. Understanding TOGAF will be the key to developing the JEAF.

TOGAF OverviewThe key to TOGAF remains a reliable, practical method - the TOGAF Architecture Development Method (ADM) - for defining business needs and developing an architecture that meets those needs, utilizing the elements of TOGAF and other architectural assets available to the organization. Technology Services keeping you informed KH ETP/JEA Page 17 of 58

A number of enterprise architecture frameworks already exist and are widely recognized, each of which has its particular advantages and disadvantages, and relevance, for enterprise architecture. Although a number of enterprise frameworks exist, there is no accepted industry standard method for developing enterprise architecture. The Open Group's goal with TOGAF is to work towards making the TOGAF architecture development method just such an industry standard method, which is neutral towards tools and technologies, and can be used for developing the products associated with any recognized enterprise framework, such as the Zachman Framework, FEAF, TEAF, MAEA & C4ISR/DoD Framework, that the architect feels is appropriate for a particular architecture. The TOGAF Architecture Development Method therefore does not prescribe any specific set of enterprise architecture deliverables - although it does describe a set, by way of example. Rather, TOGAF is designed to be used with whatever set of deliverables the TOGAF user feels is most appropriate. That may be the set of deliverables described in TOGAF itself; or it may be the set associated with another framework, such as Zachman, Federal Enterprise Architecture Framework (FEAF) and the Missouri Adaptive Enterprise Architecture (MAEA). In fact, TOGAF has always done this: it does not prescribe a specific set of "Architecture Views", but describes an example taxonomy of the kinds of views that an architect might consider developing. TOGAF and Architecture Governance As governance has become an increasingly visible requirement for organizational management, the adoption of governance into TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations. The benefits of Architectural Governance include: Increased transparency of accountability, and informed delegation of authority Controlled risk management Protection of existing asset base through maximizing re-use of existing architectural components Proactive control, monitoring and management mechanisms Process, concept, and component reuse across all organizational business units Value creation through monitoring, measuring, evaluation, and feedback Increased visibility supporting internal processes and external parties' requirements o In particular, increased visibility of decision -making at lower levels - ensuring oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization Greater shareholder value o Enterprise Architecture increasingly represents the core Intellectual Property of the enterprise. o Studies have demonstrated a correlation between increased shareholder value and well-governed enterprises. Integrates with existing processes and methodologies and complements functionality by adding control. The Enterprise Architecture Continuum TOGAF embodies the concept of the Enterprise Architecture Continuum, to reflect different levels of abstraction in an architecture development process. In this way TOGAF facilitates understanding and co-operation between actors at different levels. It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF ADM. By means of the Enterprise Architecture Continuum, architects are encouraged to leverage all other relevant architectural resources and assets, in addition to the TOGAF Foundation Architecture, in developing an organization-specific IT architecture. In this context, the TOGAF ADM can be regarded as describing the process of moving from the TOGAF Foundation Architecture to an organization-specific architecture (or set of architectures). TOGAF leverages the contents of the Enterprise Architecture Continuum along the way, including the TOGAF Foundation Architecture. TOGAF includes other relevant architectural frameworks, models, components and building blocks such as Zachman, FEAF, MAEA and the NASCIO EA Development Tool-Kit that was used to develop the Missouri Adaptive Enterprise Architecture.

Enterprise Architecture Recommendation JEA Future State

The recommended JEA Enterprise Architecture includes the JEA implementation of TOGAF Architecture Development Method (ADM) and the ADM Enterprise Architecture life cycle. Technology Services keeping you informed KH ETP/JEA Page 18 of 58

While executing the TOGAF Architecture Development Method (ADM), the JEA Enterprise Architecture (EA) team is not only developing the JEA Enterprise Architecture, but is also populating the JEA Enterprise Architecture Continuum. The JEA Architecture Continuum includes all the architectural assets identified and leveraged along the way -- including, but not limited to, the resultant enterprise-specific architecture. The JEA Enterprise Architecture Team will develop several EA processes, repositories, artifacts, blueprints and technical reference models based on the TOGAF Architecture Development Method (ADM) Enterprise Architecture life cycle. While the current JEA Architecture Process Repository uses the ASP4, Metrics, Educate, Assessment & Improvements process for its life cycle process, this recommended TOGAF based life cycle process will be implemented as using JEA specific ADM enterprise life cycle processes:

JEA Architecture Process Repository Architecture Processes ADM Enterprise Architecture Lifecycle Process Enterprise Architecture Framework & Principles Governance Architecture Process (CobiT) Enterprise Architecture Process Data Architecture Process Security Architecture Process EA Migration Strategy Process Enterprise Architecture Vision TS Business Architecture Process Application Architecture Process Systems Architecture Process Solution Architecture Process EA Change Management Process

IT Strategy & Business Requirements Management Process

The current state of the JEA Enterprise Architecture Continuum includes many of the components recommended by the TOGAF ADM and EA life cycle process. The JEA original EA Framework has been updated to include the TOGAF components selected as part of the EA strategy for on going development of the enterprise. The additional TOGAF related Enterprise Architecture Framework components include the following: TOGAF Architecture Development Method TOGAF Enterprise Architecture Life Cycle Process TOGAF Enterprise Continuum Repository TOGAF Resource Base TOGAF Architecture Foundation TOGAF related Enterprise Architecture Building Blocks: FEAF, MAEA, the NASCIO Enterprise Architecture Development Tool-Kit that was used to develop the Missouri Adaptive Enterprise Architecture and UML Models (See JEA UML Analysis section).

The recommended future state TOGAF based JEA Enterprise Architecture Framework (JEAF):





JEA Enterprise Architecture FrameworkJEA Enterprise Architecture Framework TS IT Governance Architecture CobIT, 5 year Business Plan, Management Directive, Enterprise Continuum

TS Buisness Architecture EMT, PMO, SEG, NT, Core Apps Enterprise Architecture Foundational Pillars EA Guiding Principles Reuse Before Buy Buy Before Build Build Reusable Components Build Using N-Tier Models Use Standards Based Solutions Standard Set of User Services EA Initiatives are Business Driven Domain Blueprints EA Standards TOGAF NASCIO AEA OMB FEA NIST EA Model GAO EA Best Practice TOGAF ADM NASCIO Adaptive EAF Federal EAF Treasury EAF Zachman EAF EA Maturity Model Missouri Adaptive EA Product Blueprints Regulations The ClingerCohen Act EA Policies TOGAF Enterprise Architecure Developement Lifecycle Policy

Discipline Blueprints

Compliance Blueprints

Application Architecture Principles, Standards, Best Practices, Regulations, Policies

Data Architecture Principles, Standards, Best Practices, Regulations, Policies

Enterprise Architecture Continuum Repository & Resource Base System Architecture Principles, Standards, Best Practices, Regulations, Policies Security Architecture Principles, Standards, Best Practices, Regulations, Policies

Enterprise Architecture Tools

Emerging Technology

Current Technology

Twilighting Technology

Sunseting Technology

Processes B1028, B1028.Enterprise, B1028.Apps, B1028.Data, B1028.Systems, B1028.Security Procedures Deliverables Services, Products, Initiatives

The JEA Enterprise Architecture Framework is part of the initial Preliminary EA Framework for the TOGAF based life cycle process. It is important to note that TOGAF is not an EA deliverable but a methodology for developing Architectures. The other part of the preliminary Enterprise Architecture Framework recommendation is the Enterprise Architecture Principles.

Enterprise Architecture Framework Principles: Architecture principles should be developed by JEA Enterprise Architecture Team, Technology Services CIO, EA Architecture Board (JEA principle Enterprise Architects), other key business stakeholders and EBS process owners. Technology Services keeping you informed KH ETP/JEA Page 21 of 58

Appropriate policies and procedures shall support the implementation of the principles. Architecture principles will be informed by overall IT principles and principles at the enterprise level, if they exist. They are chosen as to ensure alignment of IT strategies with business strategies and visions. JEA architecture principles are influenced by the following: Enterprise Mission and Plans Enterprise Strategic Initiatives External Constraints: - Current Systems and Technology - Computer Industry Trends The JEA Enterprise Architecture principles must be based upon the beliefs and values of the organization. These principles have to be expressed in a language that the business and target audience understands and uses. Principles will be few in number, future oriented, endorsed and championed by senior management and the JEA. They will provide a firm foundation for making architecture and planning decisions, framing policies, procedures, standards, and supporting resolution of contradictory situations. A poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility. Essentially, principles drive behavior. There are five criteria that distinguish a good set of principles: Understandable Robust Complete Consistent Stable

The JEA Enterprise Architecture principles shall contain the following components: Name: Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support," "open," "consider," and for lack of good measure the word "avoid," itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff). Statement: Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous. Rationale: Should highlight the business benefits of adhering to the principle, using business terminology. Rational should also Point to the similarity of information and technology principles to the principles governing business operations, describe the relationship to other principles and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

Implications: Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.



Example Set of Architecture Principles Too many principles can reduce the flexibility of the architecture. Many organizations prefer to define only high level principles, and to limit the number to between 10 and 20. The following example illustrates both the typical content of a set of architecture principles, and the recommended format for defining them, as explained above. Another example of architecture principles is contained in the U.S. government's Federal Enterprise Architecture Framework. 1. Principle: Primacy of Principles Statement: These principles of information management apply to all organizations within the enterprise. Rationale: The only way we can provide a consistent and measurable level of quality information to decision makers is if all organizations abide by the principles. Implications: Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information. Information management initiatives will not begin until they are examined for compliance with the principles. A conflict with a principle will be resolved by changing the framework of the initiative.

2. Principle: Maximize Benefit to the Enterprise Statement: Information management decisions are made to provide maximum benefit to the Enterprise as a whole. Rationale: This principle embodies "Service above self." Decisions made from an Enterprise-wide perspective have greater long term value than decisions made from any particular organizational perspective. Maximum return on investment requires information management decisions to adhere to Enterprise-wide drivers and priorities. No minority group will detract from the benefit of the whole. However, this principle will not preclude any minority group from getting its job done. Implications: Achieving maximum Enterprise-wide benefit will require changes in the way we plan and manage information. Technology alone will not bring about this change. Some organizations may have to concede their own preferences for the greater benefit of the entire Enterprise. Application development priorities must be established by the entire Enterprise for the entire Enterprise. Applications components should be shared across organizational boundaries. Information management initiatives should be conducted in accordance with the Enterprise plan. Individual.

organizations should pursue information management initiatives which conform to the blueprints and priorities established by the Enterprise. We will change the plan as we need to.

As needs arise, priorities must be adjusted. A forum with comprehensive Enterprise representation should make these decisions. 3. Principle: Information Management is Everybody's Business Statement: All organizations in the Enterprise participate in information management decisions needed to accomplish business objectives. Rationale: Information users are the key stakeholders, or customers, in the application of technology to address a business need. In order to ensure information management is aligned with the business, all organizations in the Enterprise must be involved in all aspects of the information environment. The business experts from across the Enterprise and the technical staff responsible for developing and sustaining the information environment need to come together as a team to jointly define the goals and objectives of information technology. Implications: To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the information environment. Commitment of resources will be required to implement this principle. 4. Principle: Business Continuity Technology Services keeping you informed KH ETP/JEA Page 23 of 58

Statement: Enterprise operations are maintained in spite of system interruptions. Rationale: As system operations become more pervasive, we become more dependent on them, therefore, we must consider the reliability of such systems throughout their design and use. Business premises throughout the Enterprise must be provided the capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop Enterprise activities. The Enterprise business functions must be capable of operating on alternative information delivery mechanisms. Implications: Dependency on shared system applications mandates that the risks of business interruption must be established in advance and managed. Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designing mission-critical services to assure business function continuity through redundant or alternative capabilities.

Recoverability, redundancy and maintainability should be addressed at the time of design.

Applications must be assessed for criticality and impact on the Enterprise mission, in order to determine what level of continuity is required and what corresponding recovery plan is necessary.

5. Principle: Common Use Applications Statement: Development of applications used across the Enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization. Rationale: Duplicative capability is expensive and proliferates conflicting data. Implications: Organizations which depend on a capability which does not serve the entire Enterprise must change over to the replacement Enterprise-wide capability. This will require establishment of and adherence to a policy requiring this. Organizations will not be allowed to develop capabilities for their own use which are similar/duplicative of Enterprisewide capabilities. In this way, expenditures of scarce resources to develop essentially the same capability in marginally different ways will be reduced. Data and information used to support Enterprise decision making will be standardized to a much greater extent than previously. This is because the smaller, organizational capabilities which produced different data (which was not shared among other organizations) will be replaced by Enterprise-wide capabilities. The impetus for adding to the set of Enterprise-wide capabilities may well come from an organization making a convincing case for the value of the data/information previously produced by its organizational capability, but the resulting capability will become part of the Enterprise-wide system, and the data it produces will be shared across the Enterprise. 6. Principle: Compliance with Law Statement: Enterprise information management processes comply with all relevant laws, policies, and regulations Rationale: Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements that lead to changes in policies and regulations. Implications: The Enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection retention, and management of data.

Education and access to the rules. Efficiency, need and common sense are not the only drivers. Changes in the law and changes in regulations may drive changes in our processes or applications.

7. Principle: IT Responsibility Statement: The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user defined requirements for functionality, service levels, cost, and delivery timing. Rationale: Effectively align expectations with capabilities and costs so that all projects are cost effective. Efficient and effective solutions have reasonable costs and clear benefits. Technology Services keeping you informed KH ETP/JEA Page 24 of 58

Implications: A process must be created to prioritize projects The IT function must define processes to manage business unit expectations Data, application, and technology models must be created to enable integrated quality solutions maximum results.

8. Principle: Protection of Intellectual Property Statement: The enterprise's IP must be protected. This protection must be reflected in the IT Architecture, Implementation, and Governance processes. Rationale: A major part of an enterprise's Intellectual Property is hosted in the IT domain. Implications: While protection of IP assets is everybody's business, much of the actual protection is implemented in the IT domain. Even trust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.).

A Security Policy, governing human and IT actors, will be required that can substantially improve protection of IP. This must be capable of both avoiding compromises and reducing liabilities.

9. Principle: Data Trustee Statement: Each data element has a trustee accountable for data quality. Rationale: One of the benefits of an architecture environment is the ability to share data (e.g., text, video, sound, etc.) across the Enterprise. As the degree of data sharing grows and business units rely upon common information, it becomes essential that only the data trustee make decisions about the content of data. Since data can lose its integrity when it is entered multiple times, the data trustee will have sole responsibility for data entry which eliminates redundant human effort and data storage resources. (Note that a trustee is different than steward - trustee is responsible for accuracy and currency of the data while responsibilities of a steward may be broader and include data standardization and definition tasks.) Implications: Real trusteeship dissolves the data "ownership" issues and allows the data to be available to meet all users' needs. This implies that a cultural change from data "ownership" to data "trusteeship" may be required. The data trustee will be responsible for meeting quality requirements levied upon the data for which the trustee is accountable. It is essential that the trustee has the ability to provide user confidence in the data based upon attributes such as 'data source.' It is essential to identify the true source of the data in order that the data authority can be assigned this trustee responsibility. This does not mean that classified sources will be revealed nor does it mean the source will be the trustee. Information should be captured electronically once and immediately validated as close to the source as possible. Quality control measures must be implemented to ensure the integrity of the data. As a result of sharing data across the Enterprise, the trustee is accountable and responsible for the accuracy and currency of their designated data element(s) and subsequently, must then recognize the importance of this trusteeship responsibility.

10. Principle: Common Vocabulary and Data Definitions Statement: Data is defined consistently throughout the Enterprise, and the definitions are understandable and available to all users. Rationale: The data that will be used in the development of applications must have a common definition throughout the Headquarters to enable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective. In addition, it is required to interface systems and exchange data. Implications: Technology Services keeping you informed KH ETP/JEA Page 25 of 58

We are lulled into thinking that this issue is adequately addressed because there are people with "data administration" job titles and forums with charters implying responsibility. Significant additional energy and resources must be committed to this task. It is a key to the success of efforts to improve the information environment. This is separate from but related to the issue of data element definition, which is addressed by a broad community - this is more like a common vocabulary and definition. The Enterprise must establish the initial common vocabulary for the business. The definitions will be used uniformly throughout the Enterprise. Whenever a new data definition is required, the definition effort will be coordinated and reconciled with the corporate "glossary" of data descriptions. The Enterprise Data Administrator will provide this co-ordination. Ambiguities resulting from multiple parochial definitions of data must give way to accepted Enterprise wide definitions and understanding. Multiple data standardization initiatives need to be coordinated. Functional data administration responsibilities must be assigned.

11. Principle: Data Security Statement: Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection sensitive, and proprietary information. Rationale: Open sharing of information and the release of information via relevant legislation must be balanced against the need to restrict the availability of classified, proprietary, and sensitive information. Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting free and open access. Pre-decisional (work-inprogress, not yet authorized for release) information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use. Implications: Aggregation of data, both classified and not, will create a large target requiring review and declassification procedures to maintain appropriate control. Data owners and/or functional users must determine if the aggregation results in an increased classification level. We will need appropriate policy and procedures to handle this review and declassification. Access to information based on a need-to-know policy will force regular reviews of the body of information.

The current practice of having separate systems to contain different classifications needs to be rethought. Is there a software solution to separating classified and unclassified data? The current hardware solution is unwieldy, inefficient, and costly. It is more expensive to manage unclassified data on a classified system. Currently, the only way to combine the two is to place the unclassified data on the classified system, where it must remain.

In order to adequately provide access to open information while maintaining secure information, security needs must be identified and developed at the data level, not the application level.

Data security safeguards can be put in place to restrict access to "view only", or "never see". Sensitivity labeling for access to pre-decisional, decisional, classified, sensitive, or proprietary information must be determined.

Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies must be protected from unauthorized access and manipulation. Headquarters information must be safeguarded against inadvertent or unauthorized alteration, sabotage, disaster, or disclosure.

The need for new policies to manage the duration of protection for pre-decisional information and other works-inprogress. This is in consideration of content freshness.

12. Principle: Technology Independence Statement: Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms. Rationale: Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in the most cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependence, becomes the driver rather than the user requirements themselves. Technology Services keeping you informed KH ETP/JEA Page 26 of 58

Realizing that every decision made respect to information technology makes us dependent on that technology, the intent of this principle is to ensure that applications software is not dependent on specific hardware and operating systems software. Implications: This principle will require standards which support portability. For COTS and GOTS applications, there may be limited current choices, as many of these applications are technology and platform dependent. Application Programming Interfaces (APIs) will need to be developed to enable legacy applications to interoperate with applications and operating environments developed under the Enterprise architecture. Middle-ware should be used to de-couple applications from specific software solutions. As an example, this principle could lead to use of JAVA, and future JAVA-like protocols, which give a high degree of priority to platform independence.

13. Principle: Ease of Use Statement: Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand. Rationale: The more a user has to understand the underlying technology the less productive that user is. Ease of use is a positive incentive for use of applications. It encourages users to work within the integrated information environment instead of developing isolated systems to accomplish the task outside of the Enterprise's integrated information environment. Most of the knowledge required to operate one system will be similar to others. Training is kept to a minimum, and the risk of using a system improperly is low. Using an application should be as intuitive as driving a different car. Implications: Applications will be required to have a common "look and feel" and support ergonomic requirements. Hence, the common look and feel standard must be designed and usability test criteria must be developed. Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training, or physical capability. Factors such as linguistics, customer physical infirmities (visual acuity, ability to use keyboard/mouse) and proficiency in the use of technology have broad ramifications in determining the ease of use of an application.

14. Principle: Requirements-Based Change Statement: Only in response to business needs are changes to applications and technology made. Rationale: This principle will foster an atmosphere where the information environment changes in response to the needs of the business, rather than having the business change in response to information technology changes. This is to ensure that the purpose of the information support -- the transaction of business -- is the basis for any proposed change. Unintended effects on business due to information technology changes will be minimized. A change in technology may provide an opportunity to improve the business process and hence, change business needs. Implications:

Changes in implementation will follow full examination of the proposed changes using the Enterprise architecture.

We don't fund a technical improvement or system development unless a documented business need exists. Change management processes conforming to this principle will be developed and implemented. This principle may bump up against the responsive change principle. We must ensure the requirements documentation process does not hinder responsive change to meet legitimate business needs. Purpose of this principle is to keep us focused on business, not technology, needs--responsive change is also a business need.

15. Principle: Interoperability Statement: Software and hardware should conform to defined standards that promote interoperability for data, applications and technology.



Rationale: Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protect existing IT investments, thus maximizing return on investment and reducing costs. Standards for interoperability additionally help ensure support from multiple vendors for their products, and facilitate supply chain integration. Implications: Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement a non-standard solution. A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established. The existing IT platforms must be identified and documented.

Current JEA EA Guiding Principles The list of example EA principles above will be considered for implementation into the pillars of the JEA Enterprise Architecture framework. The tables below describe the current EA Guiding Principles and the need for development. Enterprise Architecture Foundational Pillar Guiding Principles Reuse Before Buy Principle: Reuse Before Buy Statement: Rational: Implications: TBD TBD TBD

Enterprise Architecture Foundational Pillar Guiding Principles Buy Before Build Principle: Buy Before Build Statement: Rational: Implications: TBD TBD TBD

Enterprise Architecture Foundational Pillar Guiding Principles Build Reusable Components Principle: Build Reusable Components Statement: Rational: Implications: TBD TBD TBD

Enterprise Architecture Foundational Pillar Guiding Principles Build Using N-Tier Models Principle: Build Using N-Tier Models Statement: Rational: Implications: TBD TBD TBD



Enterprise Architecture Foundational Pillar Guiding Principles Use Standard Based Solutions Principle: Use Standard Based Solutions Statement: Rational: Implications: TBD TBD TBD

Enterprise Architecture Foundational Pillar Guiding Principles Standard Set of User Services Principle: Standard Set of User Services Statement: Rational: Implications: TBD TBD TBD

Enterprise Architecture Foundational Pillar Guiding Principles EA Initiatives are Business Driven Principle: All EA Initiatives are Business Driven Statement: Rational: Implications: TBD TBD TBD

Preliminary EA Framework & Principles have been specified. In the tradition of TOGAF, examples of EA principles that JEA might consider and the existing Guiding Principles have been recommended within the TOGAF life cycle process:





JEA ENTERPRISE ARCHITECTURE LIFE CYCLE PROCESSENTERPRISE ARCHITECTURE FRAMEWORK & PRINCIPLES

CHANGE MANAGEMENT

ENTERPRISE ARCHITECTURE VISION

BUSINESS ARCHITECTURE

TS BUSINESS STRATEGY

EA MIGRATION STRATEGY

REQUIREMENTS MANGEMENT ITIL SERVICES MANAGEMENT JEA IT SERVICE MODEL: CUSTOMER MGMT. SERVICES CONSULTING SERVICES IMPLEMENTATION SERVICES SYSTEMS & APPL. DEVELOPEMENT SERVICES RESEARCH & DEVELOPEMENT SERVICES SYSTEMS & APPLICATION SUPPORT SERVICES INVESTMENT MANAGEMENT SERVICES CONTRACTOR MANAGEMENT SERVICES RESEARCH & DEVELOPEMENT SERVICES SERVICE LEVEL AGREEMENTS (SLA) OPERATIONAL LEVEL AGREEMENTS (OLA)

GOVERANCE ARCHITECTURE (COBIT)

SOLUTIONS ARCHITECTURE

APPLICATIO

Documents

IT Governance & EA Standards 2011 Sep 11 Gold