IFSM 301 – IT Decision Paper
twinkletoes
IFSM-Week7ResourcesandCitations.pdf
IFSM 301 – Week 7 Citations
(Chief Information Officer Council, 2001)
(Government Accountabiltiy Office, 2016)
(Government Accountability Office, 2016)
(National Computing Centre, 2005)
(University of Maryland Global Campus)
(University of Maryland Global Campus)
(Pataki, Dillion, & McCormack, 2014)
(Osetskyi, 2018)
Bibliography Chief Information Officer Council. (2001). Federal Enterprise Architecture. Springfield: CIO.
Retrieved February 21, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543097/View
Government Accountability Office. (2016, November 8). Best Practices in Information Securit. Retrieved February 21, 2021, from Government Accountability Office: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543096/View
Government Accountabiltiy Office. (2016, November 8). Best Practices in Enterprise Architecture. Retrieved February 21, 2021, from Government Accountability Office: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543095/View
National Computing Centre. (2005). IT Governance; Developing a Successful Governance Strategy. London: John Wiley & Sons. Retrieved January 12, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543038/View
Osetskyi, V. (2018, August 11). How to Write the System Requirements Specification for Software Development. Retrieved February 21, 2021, from Existek: https://medium.com/existek/how-to-write-the-system-requirements-specification-for- software-development-5290c70b62a8
Pataki, G. E., Dillion, J. T., & McCormack, M. (2014). Section III:2 System Requirements Analysis. In NYS Project Management Guidebook (pp. 31-70). New York: New York State Office for Technology. Retrieved February 21, 2021, from https://its.ny.gov/sites/default/files/documents/systemreq.pdf
University of Maryland Global Campus. (n.d.). Developing Requirements for an IT System. Retrieved February 21, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543100/View
University of Maryland Global Campus. (n.d.). Requirements. Retrieved February 21, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543101/View
A Practical Guide to
Federal Enterprise Architecture
Chief Information Officer Council
Version 1.0
February 2001
iii February 2001
Preface
An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an Agency�s mission through optimal performance of its core business processes within an efficient information technology (IT) environment. Simply stated, enterprise architectures are �blueprints� for systematically and completely defining an organization�s current (baseline) or desired (target) environment. Enterprise architectures are essential for evolving information systems and developing new systems that optimize their mission value. This is accomplished in logical or business terms (e.g., mission, business functions, information flows, and systems environments) and technical terms (e.g., software, hardware, communications), and includes a Sequencing Plan for transitioning from the baseline environment to the target environment.
If defined, maintained, and implemented effectively, these institutional blueprints assist in optimizing the interdependencies and interrelationships among an organization�s business operations and the underlying IT that support operations. The experience of the Office of Management and Budget (OMB) and General Accounting Office (GAO) has shown that without a complete and enforced EA, federal agencies run the risk of buying and building systems that are duplicative, incompatible, and unnecessarily costly to maintain and integrate.
For EAs to be useful and provide business value, their development, maintenance, and implementation should be managed effectively. This step-by-step process guide is intended to assist agencies in defining, maintaining, and implementing EAs by providing a disciplined and rigorous approach to EA life cycle management. It describes major EA program management areas, beginning with suggested organizational structure and management controls, a process for development of a baseline and target architecture, and development of a sequencing plan. The guide also describes EA maintenance and implementation, as well as oversight and control. Collectively, these areas provide a recommended model for effective EA management.
Background
Reflecting the general consensus in industry that large, complex systems development and acquisition efforts should be guided by explicit EAs, Congress required Federal Agency Chief Information Officers to develop, maintain, and facilitate integrated systems architectures with the passage of the Clinger-Cohen Act1in 1996. Additionally, OMB has issued guidance that requires agency information systems investments to be consistent with Federal, Agency, and bureau architectures. Other OMB guidance provides for the content of Agency enterprise architectures.2 Similarly, the Chief Information Officer Council, the Department of the Treasury, the National Institute of Standards Technology (NIST), and GAO, have developed architecture frameworks or models that define the content of enterprise architectures.3
1 Public Law 104-106, section 5125, 110 Stat. 684 (1996). 2 OMB Circular A-130, Management of Federal Information Resources, November 30, 2000. 3 Federal Enterprise Architecture Framework, Version 1.1, Federal Chief Information Officers Council, September 1999; Treasury Enterprise Architecture Framework, Version 1, the Department of the Treasury, July 3, 2000; the National Institute of Standards and Technology�s Enterprise Architectural Model, referenced in NIST Special Publication 500-167, Information Management Directions: the Integration Challenge; and Strategic Information Planning: Framework for Designing and Developing System Architectures (GAO/IMTEC-92-51, June 1992).
A Practical Guide to Federal Enterprise Architecture Preface
iv February 2001
This guide builds upon, complements, and is directly linked to the GAO Information Technology Investment Management (ITIM) framework4 that was developed to provide a common structure for discussing and assessing IT capital planning and investment control (CPIC) practices at Federal Agencies. ITIM enhances earlier Federal IT investment management guidance by extending the Select/Control/Evaluate approach, mandated by the Clinger-Cohen Act, into a growth and maturity framework.5 It is also directly linked to the Federal Enterprise Architecture Framework.
The Need for this Guide
While these frameworks and models provide valuable guidance on the content of enterprise architectures, there is literally no ffeeddeerraall guidance how to successfully manage the process of creating, changing, and using the enterprise architecture. This guidance is crucially important. Without it, it is highly unlikely that an organization can successfully produce a complete and enforceable EA for optimizing its systems� business value and mission performance. For example, effective development of a complete EA needs a corporate commitment with senior management sponsorship. The enterprise architecture development should be managed as a formal project by an organizational entity that is held accountable for success. Since the EA facilitates change based upon the changing business environment of the organization, the architect is the organization�s primary change agent. Effective implementation requires establishment of system compliance with the architecture, as well as continuous assessment and enforcement of compliance. Waiver of these requirements may occur only after careful, thorough, and documented analysis. Without these commitments, responsibilities, and tools, the risk is great that new systems will not meet business needs, will be incompatible, will perform poorly, and will cost more to develop, integrate, and maintain than is warranted.
Conclusion
The processes described in this guide represent fundamental principles of good EA management. Since the guide is not a one-size-fits-all proposition, Agencies or organizations should adapt its recommendations and steps to fit their individual needs. We encourage you to consider these EA processes and best practices carefully before pursuing other approaches.
An electronic version of this guide is available at the following Internet address: http://www.cio.gov.
If you have questions or comments about this guide, please contact Rob C. Thomas II at (703) 921-6425, by email at [email protected], or by mail at:
U.S. Customs Service 7681 Boston Boulevard Springfield, VA 22153
4 Information Technology Investment Management: A Framework for Assessing and Improving Process Maturity (GAO/AIMD-10.1.23, Exposure Draft, 2000). 5 In the Select Phase, the costs and benefits of all available projects are assessed and the optimal portfolio of projects is selected. During the Control Phase, the portfolio is monitored and corrective action is applied where needed. In the Evaluate Phase, implemented projects are reviewed to ensure that they are producing the benefits expected and adjustments are made where appropriate.
A Practical Guide to Federal Enterprise Architecture Preface
v February 2001
Credits
This document was produced by the Federal Architecture Working Group (FAWG) under the strategic direction of the Enterprise Interoperability and Emerging Information Technology Committee (EIEITC) of the Federal Chief Information Officer Council.
The following persons contributed to accomplishing this Guide.
Name Title Agency Rob C. Thomas, II Dir., Tech. & Arch. Group, Chief Architect U.S. Customs Service Randolph C. Hite Dir., Information Technology Systems Issues General Accounting Office Ray Beamer Senior Principal Scientist The MITRE Corporation William H. McVay Senior Policy Analyst Office of Management and Budget Elaine Ward Principal Engineer The MITRE Corporation Keith Rhodes Chief Technologist General Accounting Office Mary Lou Collins Lead Engineer The MITRE Corporation George Brundage Chief Architect U.S. Department of the Treasury Scott Bernard Management Consultant Booz-Allen & Hamilton, Inc. Lester Diamond Assistant Director General Accounting Office Michael A. Tiemann Dir., Arch. & Stnds. Div., Chief Architect U.S. Department of Energy Thomas P. Cullen Policy Analyst U.S. Customs Service William Lew Technical Assistant Director General Accounting Office John Anderson Principal Engineer The MITRE Corporation Daryl Knuth Information Architect U.S. Customs Service Barbara Scott Management Analyst U.S. Department of Education Paul J. Paradis Management Analyst U.S. Department of Energy Naba Barkakati Technical Assistant Director General Accounting Office Kathy Sowell Lead Engineer The MITRE Corporation Wayne Shiveley Senior Computer Scientist Federal Bureau of Investigation
A Practical Guide to Federal Enterprise Architecture Preface
vi February 2001
vii February 2001
Table of Contents
Prefaceiii
1. Introduction......................................................................................................................................... 1
1.1. Purpose........................................................................................................................................ 1
1.2. Scope........................................................................................................................................... 1
1.3. Audience ..................................................................................................................................... 1
1.4. Document Organization .............................................................................................................. 2
1.5. How to Use this Guide................................................................................................................ 3
1.6. Related Documents ..................................................................................................................... 4
2. Definitions, Drivers, and Principles .................................................................................................. 5
2.1. Enterprise Architecture Defined ................................................................................................. 5
2.2. The Uses and Benefits of Enterprise Architecture ...................................................................... 5
2.3. Legislation and other Guidance .................................................................................................. 6
2.4. Architecture Principles................................................................................................................ 7
2.5. The Enterprise Life Cycle ........................................................................................................... 8
2.6. The Enterprise Architecture Process........................................................................................... 9
3. Initiate Enterprise Architecture Program...................................................................................... 11
3.1. Obtain Executive Buy-in and Support ...................................................................................... 11 3.1.1. Ensure Agency Head Buy-in and Support ................................................................... 11 3.1.2. Issue an Executive Enterprise Architecture Policy ...................................................... 11 3.1.3. Obtain Support from Senior Executives and Business Units....................................... 12
3.2. Establish Management Structure and Control........................................................................... 13 3.2.1. Establish a Technical Review Committee ................................................................... 14 3.2.2. Establish a Capital Investment Council ....................................................................... 14 3.2.3. Establish an EA Executive Steering Committee.......................................................... 14 3.2.4. Appoint Chief Architect............................................................................................... 14 3.2.5. Establish an Enterprise Architecture Program Management Office ............................ 15
3.3. Enterprise Architecture Program Activities and Products ........................................................ 17 3.3.1. Develop an EA Marketing Strategy and Communications Plan.................................. 17 3.3.2. Develop an EA Program Management Plan ................................................................ 18 3.3.3. Initiate Development of the Enterprise Architecture ................................................... 18
4. Define an Architecture Process and Approach .............................................................................. 21
4.1. Define the Intended Use of the Architecture............................................................................. 22
4.2. Define the Scope of the Architecture ........................................................................................ 22
4.3. Determine the Depth of the Architecture .................................................................................. 22
4.4. Select Appropriate EA Products ............................................................................................... 23 4.4.1. Select Products that Represent the Business of the Enterprise .................................... 23 4.4.2. Select Products that Represent Agency Technical Assets ........................................... 24
4.5. Evaluate and Select a Framework............................................................................................. 24 4.5.1. Federal Enterprise Architecture Framework................................................................ 25
A Practical Guide to Federal Enterprise Architecture Contents
viii February 2001
4.5.2. DoD C4ISR Architecture Framework.......................................................................... 27 4.5.3. Treasury Enterprise Architecture Framework.............................................................. 28
4.6. Select an EA Toolset................................................................................................................. 30
5. Develop the Enterprise Architecture .............................................................................................. 33
5.1. Collect Information................................................................................................................... 34
5.2. Generate Products and Populate EA Repository....................................................................... 35 5.2.1. Essentials in Building the Baseline Architecture ......................................................... 36 5.2.2. Essentials in Building the Target Architecture ............................................................ 36 5.2.3. Review, Validate, and Refine Models ......................................................................... 38
5.3. Develop the Sequencing Plan ................................................................................................... 38 5.3.1. Identify Gaps................................................................................................................ 39 5.3.2. Define and Differentiate Legacy, Migration, and New Systems ................................. 39 5.3.3. Planning the Migration ................................................................................................ 40
5.4. Approve, Publish, and Disseminate the EA Products ............................................................... 41
6. Use the Enterprise Architecture ...................................................................................................... 43
6.1. Integrate the EA with CPIC and SLC Processes....................................................................... 43 6.1.1. Train Personnel ............................................................................................................ 45 6.1.2. Establish Enforcement Processes and Procedures ....................................................... 45
6.2. Execute the Integrated Process ................................................................................................. 47 6.2.1. Initiate New and Follow-on Projects ........................................................................... 47 6.2.2. Execute the Projects..................................................................................................... 51 6.2.3. Complete the Project.................................................................................................... 52
6.3. Other Uses of the EA ................................................................................................................ 54
7. Maintain the Enterprise Architecture ............................................................................................ 55
Maintain the Enterprise Architecture as the Enterprise Evolves ........................................................ 55 7.1.1. Reassess the Enterprise Architecture Periodically....................................................... 55 7.1.2. Manage Products to Reflect Reality............................................................................. 56
7.2. Continue to Consider Proposals for EA Modifications............................................................. 57
8. Continuously Control and Oversee the Enterprise Architecture Program................................. 59
8.1. Ensure Necessary EA Program Management Controls Are In Place and Functioning............. 59
8.2. Identify Where EA Program Expectations Are Not Being Met................................................ 59
8.3. Take Appropriate Actions to Address Deviations .................................................................... 60
8.4. Ensure Continuous Improvement.............................................................................................. 60
9. Summary ........................................................................................................................................... 63
Appendix A: EA Roles and Responsibilities........................................................................................... 65
Appendix B: Glossary............................................................................................................................... 67
Appendix C: Acronyms ............................................................................................................................ 71
Appendix D: Example Architecture Products........................................................................................ 73
D.1. Mission and Vision Statements................................................................................................. 73
A Practical Guide to Federal Enterprise Architecture Contents
ix February 2001
D.2. Information Dictionary ............................................................................................................. 73
D.3. Concept of Operations (CONOPS) Graphic ............................................................................. 74
D.4. Activity Models and Trees........................................................................................................ 76
D.5. Business Use Case Model ......................................................................................................... 78
D.6. Class Model .............................................................................................................................. 81
D.7. State Model ............................................................................................................................... 82
D.8. Node Connectivity Diagrams.................................................................................................... 83
D.9. Information Exchange Matrix................................................................................................... 86
D.10. Organization Chart.................................................................................................................... 87
D.11. Systems Interface Description and Connectivity Diagram ....................................................... 88
D.12. Standards Profile....................................................................................................................... 89
D.13. Technical Reference Model ...................................................................................................... 90
Appendix E: Sample Architectural Principles ....................................................................................... 93
Appendix F: Bibliography........................................................................................................................ 97
Appendix G: The Zachman Framework .............................................................................................. 101
x February 2001
List of Figures
Figure 1. Role of Architecture Principles .................................................................................................... 7 Figure 2. The Enterprise Life Cycle............................................................................................................. 8 Figure 3. The Enterprise Architecture Process ............................................................................................. 9 Figure 4. Notional EA Organization ........................................................................................................... 13 Figure 5. Depth and Detail of the Architecture........................................................................................... 21 Figure 6. Structure of the FEAF Components ............................................................................................ 26 Figure 7. FEAF Architecture Matrix.......................................................................................................... 26 Figure 8. DoD C4ISR Framework ............................................................................................................. 27 Figure 9. DoD C4ISR Products ................................................................................................................. 28 Figure 10. The Treasury Enterprise Architecture Framework ................................................................... 29 Figure 11. TEAF Products ......................................................................................................................... 30 Figure 12. Example Approach for EA Development................................................................................. 33 Figure 13. Systems Migration Chart .......................................................................................................... 40 Figure 14. IMP/Architecture Project Assessment Framework .................................................................. 44 Figure 15. Architecture Management ......................................................................................................... 45 Figure 16. Define New and Follow-on Programs/Projects ........................................................................ 48 Figure 17. Execute Programs/Projects ........................................................................................................ 51 Figure 18. Evaluate Programs/Projects....................................................................................................... 53 Figure 19. Enterprise Architecture Transition ............................................................................................ 56 Figure 20. Key Success Factors .................................................................................................................. 61 Figure 21. DoD Battlespace Concept of Operations Graphic ..................................................................... 74 Figure 22. U.S. Customs Service Trade Compliance Concept of Operations Graphic............................... 75 Figure 23. Generic IDEF Activity Model ................................................................................................... 77 Figure 24. U.S. Customs, ACS, Activity Tree............................................................................................ 77 Figure 25. U.S. Customs, Trade Compliance, UML Activity Model ......................................................... 78 Figure 26. U.S. Customs, Trade Compliance�External, UML Use Case Diagram .................................. 79 Figure 27. U.S. Customs, Trade Compliance�Internal, UML Use Case Diagram ................................... 79 Figure 28. U.S. Customs, Trade Compliance, Declare Goods, UML Use Case Specification................... 80 Figure 29. U.S. Customs, Trade Compliance, Commercial View, UML Class Diagram........................... 81 Figure 30. U.S. Customs, Trade Compliance, Carrier, UML State Diagram ............................................. 82 Figure 31. U.S. Customs, ACS, Customs Systems, Node Connectivity Diagram...................................... 84 Figure 32. U.S. Customs, ACS, N2 Chart.................................................................................................... 85 Figure 33. U.S. Air Force Node Connectivity Diagram ............................................................................. 86 Figure 34. Generic Organization Chart....................................................................................................... 88 Figure 35. Generic System Interface Description Connectivity Diagram .................................................. 89 Figure 36. Standards Profile Table ............................................................................................................. 90 Figure 37. U.S. Customs Technical Reference Model................................................................................ 90 Figure 38. Generic TRM Domain and Sub-domain Definitions and Components..................................... 91 Figure 39. The Zachman Framework Matrix............................................................................................ 102
xi February 2001
List of Tables
Table 1. EAPMO Roles and Responsibilities ............................................................................................. 17 Table 2. Framework Selection Criteria ...................................................................................................... 25 Table 3. Tool Selection Criteria................................................................................................................. 31 Table 4. Baseline and Target Architecture Differentiators ........................................................................ 35 Table 5. EA Review Goals.......................................................................................................................... 50 Table 6. Example Logical Information Exchange Matrix ......................................................................... 87
1 February 2001
1. Introduction
1.1. Purpose
The purpose of this document is to provide guidance to Federal Agencies in initiating, developing, using, and maintaining an enterprise architecture (EA). This guide offers an end-to- end process to initiate, implement, and sustain an EA program, and describes the necessary roles and associated responsibilities for a successful EA program.
An EA establishes the Agency-wide roadmap to achieve an Agency�s mission through optimal performance of its core business processes within an efficient information technology (IT) environment. Simply stated, enterprise architectures are �blueprints� for systematically and completely defining an organization�s current (baseline) or desired (target) environment. Enterprise architectures are essential for evolving information systems, developing new systems, and inserting emerging technologies that optimize their mission value. While some agencies have enterprise architectures in place, others do not. For agencies that already have an EA in place, this guide should be tailored to fit these Agencies� needs. For smaller agencies, a streamlined version of the guide should be created to support the needs of the Agency.
1.2. Scope
This guide focuses on EA processes, products, and roles and responsibilities. While this guide addresses the enterprise life cycle, it describes in detail how the EA processes relate to enterprise engineering, program management, and capital planning and investment control (CPIC) processes.
The breadth and depth of information presented here should be tailored to your organization. Some examples are presented in the appendices, and references to supplementary material are included in the text or bibliography. Feel free to individualize these examples as needed.
1.3. Audience
This guide is intended primarily for Federal Agency architects tasked with the generation and institutionalization of EAs. This document provides guidance to Agencies that currently do not have EAs and those that can benefit from improvements in their EA methods for development and maintenance. For Agencies without an EA, this document provides useful guidance to the Agency Head and the Chief Information Officer (CIO) for educating and obtaining key stakeholder commitment in establishing an effective EA.
This guide is also aimed at CPIC process participants [e.g., investment review boards, and the Office of Management and Budget (OMB)], as well as enterprise engineering and program management process participants (e.g., program/project managers, systems engineers, application architects, systems developers, configuration managers, risk managers, and security engineers).
Although the guide specifically addresses the roles and responsibilities of major players in the architecture development process, it is also a handbook for anyone who needs to know more about the EA process. Regardless of your role or responsibility�whether you have sole responsibility for EA development or are a member of an architecture team�if you are involved in the enterprise life cycle, this guide is for you.
A Practical Guide to Federal Enterprise Architecture Introduction
2 February 2001
1.4. Document Organization
The document is organized as follows:
Section 1: Introduction Defines the purpose, scope, audience, and organization of the document.
Section 2: Definitions, Drivers, and Principles
Presents the context for the EA process, i.e., principles and legislative drivers, and defines the architecture development, implementation, and maintenance process.
Section 3: Initiate Enterprise Architecture Program
Defines EA program procedural steps to initiate the program, typical EA organization, and products of the EA.
Section 4: Define an Architecture Process and Approach
Defines a process for building an enterprise architecture and describes federally developed frameworks.
Section 5: Develop the Enterprise Architecture
Provides the procedural steps for developing baseline and target architectures and a sequencing plan.
Section 6: Use the Enterprise Architecture
Demonstrates how the EA process interacts with capital planning and investment control and with the Systems Life Cycle.
Section 7: Maintain the Enterprise Architecture
Discusses processes and procedures to maintain EA products throughout the life-cycle process.
Section 8: Continuously Control and Oversee the EA Program
Section 9: Summary
Provides guidelines to ensure EA processes and practices are being followed and remedies and corrective actions applied when warranted.
Presents highlights of the EA guide and provides final recommendations for the initiation and implementation of a successful EA program.
Appendix A: EA Roles and Responsibilities
Provides a concise description of key personnel roles and responsibilities for EA development, implementation, and maintenance.
Appendix B: Glossary Provides a definition of terms used within this document.
Appendix C: Acronyms Provides a list of all acronyms used within this document.
Appendix D: Example Architecture Products
Provides sample EA essential and supporting products.
A Practical Guide to Federal Enterprise Architecture Introduction
3 February 2001
Appendix E: Sample Architectural Principles
Describes samples of the essential architectural principles that are a starting point in the architecture process.
Appendix F: Bibliography Provides a list of key documents used during the development of this guide and other informative source documentation.
Appendix G: The Zachman Framework
Presents a brief background and description of the Zachman Framework and its application to enterprise architecture.
1.5. How to Use this Guide
This guide is a �how-to� manual for Federal Agency architects and stakeholders in the initiation, development, use, and maintenance of EAs. To find an answer to your specific need or question, please consult the following table for frequently asked questions. These and many other questions are answered throughout the guide.
Question Section
1. Why develop an EA? 2.0
2. What are the primary benefits of using an EA? 2.0
3. What are the legislative drivers and mandates for using an EA?
2.0
4. What is the Enterprise Life Cycle? 2.0
5. What is a baseline architecture? 2.0
6. What is a target architecture? 2.0
7. What is a sequencing plan? 2.0
8. How does the EA process relate to the CPIC process? 3.0
9. Who is responsible for architecture policies? 3.0
10. Who is responsible for the EA? 3.0
11. How does one market the selected approach to senior executives?
3.0
12. What are frameworks and how do I select one? 4.0
13. How do I create a baseline or target architecture? 5.0
14. How do I transition from the baseline to the target? 5.0
15. How is the EA used within the CPIC process to justify information technology investments?
6.0
16. How do architecture processes relate to other enterprise engineering activities?
6.0
17. How does a project manager or application architect ensure alignment to the EA when proposing a new project?
6.0
18. How do I maintain the EA in the midst of evolving systems and new business requirements?
7.0
19. What are the organizational roles and responsibilities when Appendix A
A Practical Guide to Federal Enterprise Architecture Introduction
4 February 2001
Question Section developing and maintaining an EA?
20. What do architectural products look like? Appendix D
21. What are EA architectural principles? 2.0 and Appendix E
22. Where can I find more EA information? Appendix F and G
1.6. Related Documents
• Federal Enterprise Architecture Framework (FEAF), issued by the Federal CIO Council, dated September 1999.
The FEAF provides guidance for developing, maintaining, and facilitating enterprise architectures in the Federal government.
• Architecture Alignment and Assessment Guide, produced for the Federal CIO Council by the Federal Architecture Working Group (FAWG), dated October 2000.
• Smart Practices in Capital Planning, produced by the FAWG and the Capital Planning and IT Management Committee, dated October 2000.
Together with GAO and OMB guidance, these documents provide guidance on the interaction and integration of the CPIC and EA processes. Collectively, these documents describe the CPIC and EA processes working as a governance mechanism to ensure successful organizational change and information technology (IT) investments to support that change.
See Appendix F for a complete listing of reference documentation.
5 February 2001
2. Definitions, Drivers, and Principles
2.1. Enterprise Architecture Defined
EA terminology carries many variations within each organization and in the vast array of literature. Therefore, the authors have settled on one consistent set of definitions for key terms used within this guide. The definition for Enterprise Architecture is the endorsed definition from the Federal CIO Council and appears in the September 1999 version of the FEAF. Although the term enterprise is defined in terms of an organization, it must be understood that in many cases, the enterprise may transcend established organizational boundaries (e.g., trade, grant management, financial management, logistics).
Appendix B contains a listing of additional terms, their definitions, and the source authority.
2.2. The Uses and Benefits of Enterprise Architecture
In general, the essential reasons for developing an EA include:
• Alignment�ensuring the reality of the implemented enterprise is aligned with management�s intent
• Integration�realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise
• Change�facilitating and managing change to any aspect of the enterprise
• Time-to-market�reducing systems development, applications generation, modernization timeframes, and resource requirements
• Convergence�striving toward a standard IT product portfolio as contained in the Technical Reference Model (TRM).
Key Definitions
Architecturethe structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.
Enterprisean organization (or cross- organizational entity) supporting a defined business scope and mission. An enterprise includes interdependent resources (people, organizations, and technology) who must coordinate their functions and share information in support of a common mission (or set of related missions).
Baseline architecturethe set of products that portray the existing enterprise, the current business practices, and technical infrastructure. Commonly referred to as the �As-Is� architecture.
Target architecturethe set of products that portray the future or end-state enterprise, generally captured in the organization�s strategic thinking and plans. Commonly referred to as the �To-Be� architecture.
Sequencing Plana document that defines the strategy for changing the enterprise from the current baseline to the target architecture. It schedules multiple, concurrent, interdependent activities, and incremental builds that will evolve the enterprise.
Enterprise Architecture Productsthe graphics, models, and/or narrative that depicts the enterprise environment and design.
Enterprise Architecturea strategic information asset base, which defines the mission, the information necessary to perform the mission and the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. An enterprise architecture includes a baseline architecture, target architecture, and a sequencing plan.
A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles
6 February 2001
An EA offers tangible benefits to the enterprise and those responsible for evolving the enterprise. The EA can:
• Capture facts about the mission, functions, and business foundation in an understandable manner to promote better planning and decision making
• Improve communication among the business organizations and IT organizations within the enterprise through a standardized vocabulary
• Provide architectural views that help communicate the complexity of large systems and facilitate management of extensive, complex environments
• Focus on the strategic use of emerging technologies to better manage the enterprise�s information and consistently insert those technologies into the enterprise
• Improve consistency, accuracy, timeliness, integrity, quality, availability, access, and sharing of IT-managed information across the enterprise
• Support the CPIC processes by providing a tool for assessment of benefits, impacts, and capital investment measurements and supporting analyses of alternatives, risks, and tradeoffs
• Highlight opportunities for building greater quality and flexibility into applications without increasing cost
• Achieve economies of scale by providing mechanisms for sharing services across the enterprise
• Expedite integration of legacy, migration, and new systems
• Ensure legal and regulatory compliance.
The primary purpose of an EA is to inform, guide, and constrain the decisions for the enterprise, especially those related to IT investments. The true challenge of enterprise engineering is to maintain the architecture as a primary authoritative resource for enterprise IT planning. This goal is not met via enforced policy, but by the value and utility of the information provided by the EA.
2.3. Legislation and other Guidance
Within the Federal government, numerous rules and regulations govern the development and execution of IT policy. These guidelines have been established to better manage strategic plans, enhance IT acquisition practices, justify IT expenditures, measure IT performance, report results to Congress, integrate new technologies, and manage information resources.
The Clinger-Cohen Act holds each Agency CIO responsible for developing, maintaining, and facilitating the implementation of an information technical architecture. Executive Order 13011, Federal Information Technology, established the Federal CIO Council as the principal interagency forum for improving practices in the design, modernization, employment, sharing, and performance of Agency information resources. Sections 1 through 3 of the Federal CIO Council�s Architecture Alignment and Assessment Guide describe IT reform and its evolution. The guide highlights OMB guidance directed to the Federal community, which extended IT reform beyond the Clinger-Cohen Act. The Federal CIO Council began developing the Federal Enterprise Architecture Framework in April 1998 in accordance with the priorities enunciated in Clinger-Cohen and issued it in 1999.
A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles
7 February 2001
Additional sources of mandates and drivers for EA include:
• Government Paperwork Elimination Act (GPEA)
• Freedom of Information Act (FOIA) and Amendments
• Government Performance Results Act of 1993 (GPRA)
• OMB Circulars A�130 and A�11
• GAO Guidance, Findings, and Recommendations
• Federal CIO Council documents.
2.4. Architecture Principles
Principles establish the basis for a set of rules and behaviors for an organization. There are principles that govern the EA process and principles that govern the implementation of the architecture. Architectural principles for the EA process affect development, maintenance, and use of the EA. Architectural principles for EA implementation establish the first tenets and related decision-making guidance for designing and developing information systems.
The Chief Architect, in conjunction with the CIO and select Agency business managers, defines the architectural principles that map to the organization�s IT vision and strategic plans. As shown in Figure 1, architectural principles should represent fundamental requirements and practices believed to be good for the organization. These principles should be refined to meet Agency business needs. It should be possible to map specific actions, such as EA development, systems acquisitions, and implementation, to the architectural principles. Deliberate and explicit standards-oriented policies and guidelines for the EA development and implementation are generated in compliance with the principles. Each and every phase of the Systems Life Cycle is supported by the actions necessitated by the architecture principles. CPIC actions are governed by the implications within the principles.
ActionsActions
Business NeedsBusiness NeedsStrategic PlansStrategic Plans
ImplicationsImplications
EA Policies and Guidelines
� EA Development � EA Use � EA Maintenance � EA Compliance
Principles
� EA � Enterprise
IT Vision, Requirements, and Practices
IT Vision, Requirements, and Practices
Systems Life Cycle
� Systems Migration � Technology Insertion � Dual Operations � Deployment Plans
Capital Planning and Investment Control
� Project Selection � Project Control � Project Evaluation � Return on Investment
Figure 1. Role of Architecture Principles
A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles
8 February 2001
Appendix E provides sample EA principles for consideration as a starting point, as well as the rationale for and the impact of implementing each principle. Each Agency should apply, add to, or modify these sample principles. Formulating these supporting statements should be an essential part of an Agency�s effort to define its principles.
2.5. The Enterprise Life Cycle
The enterprise life cycle is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance and disposition of existing elements of the enterprise.
Although the EA process is the primary topic of this guide, it cannot be discussed without consideration of other closely related processes. These include the enterprise engineering and program management cycle (more commonly known as the system development/acquisition life cycle) that aids in the implementation of an EA, and the CPIC process that selects, controls, and evaluates investments. Overlying these processes are human capital management and information security management. When these processes work together effectively, the enterprise can effectively manage IT as a strategic resource and business process enabler. When these processes are properly synchronized, systems migrate efficiently from legacy technology environments through evolutionary and incremental developments, and the Agency is able to demonstrate its return on investment. Figure 2 illustrates the interaction of the dynamic and interactive cycles as they would occur over time.
Enterprise Engineering
and Program
Management
CPIC Process
Modernization
Systems Migration
Operations & Maintenance
EA Process
Security
Management
HumanResources
The Enterprise Life Cycle
Syste ms
Life Cycle
Figure 2. The Enterprise Life Cycle
A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles
9 February 2001
2.6. The Enterprise Architecture Process
As a prerequisite to the development of every enterprise architecture, each Agency should establish the need to develop an EA and formulate a strategy that includes the definition of a vision, objectives, and principles. Figure 3 shows a representation of the EA process. Executive buy-in and support should be established and an architectural team created within the organization. The team defines an approach and process tailored to Agency needs. The architecture team implements the process to build both the baseline and target EAs. The architecture team also generates a sequencing plan for the transition of systems, applications, and associated business practices predicated upon a detailed gap analysis. The architecture is employed in the CPIC and the enterprise engineering and program management processes via prioritized, incremental projects and the insertion of emerging new technologies. Lastly, the architectures are maintained through a continuous modification to reflect the Agency�s current baseline and target business practices, organizational goals, visions, technology, and infrastructure.
Obtain Executive
Buy-In and Support
Establish Management
Structure and Control
Define an Architecture
Process and Approach
Develop Baseline Enterprise
Architecture Develop Target
Enterprise Architecture
Develop the Sequencing Plan
Use the
Enterprise Architecture
Maintain the Enterprise Architecture
Section 3.1
Section 3.2
Section 4
Section 5.2
Section 5.2
Section 5.3
Section 6
Section 7
Control and
Oversight
Control and
Oversight
Figure 3. The Enterprise Architecture Process
A Practical Guide to Federal Enterprise Architecture Definitions, Drivers, and Principles
10 February 2001
11 February 2001
3. Initiate Enterprise Architecture Program
The enterprise architecture is a corporate asset that should be managed as a formal program. Successful execution of the EA process is an Agency-wide endeavor requiring management, allocation of resources, continuity, and coordination. Agency business line executives should work closely with the Agency architecture team to produce a description of the Agency�s operations, a vision of the future, and an investment and technology strategy for accomplishing defined goals.
Experience shows that obtaining the needed cooperation among Agency executives is not an easy task. Creating an EA program calls for sustained leadership and strong commitment. This degree of sponsorship and commitment needs the buy-in of the Agency Head, leadership by the CIO, and early designation of a Chief Architect.
3.1. Obtain Executive Buy-in and Support
Gaining executive commitment to any new initiative requires the development of a strong business case and a communications approach to effectively convey that business case. Since the concept of an EA is not intuitively understood outside the CIO organization, the CIO should create a marketing strategy to communicate the strategic and tactical value for EA development to the Agency Head, other senior Agency executives, and business units.
3.1.1. Ensure Agency Head Buy-in and Support
Without buy-in from the Agency Head, the CIO will find it hard to maintain the necessary sponsorship desired to fund and implement improved systems and processes. The CIO takes the lead to provide understanding and gain the Agency Head�s buy-in. This can be accomplished by:
• Leveraging success stories from other Agency and private sector organizations as well as the experience and knowledge of EA experts
• Using examples to demonstrate how an EA can provide a blueprint and roadmap for desired changes or improvements in mission performance and accountability
• Emphasizing the legislative requirements for developing, maintaining, and implementing an EA within the Federal sector.
Once the CIO is assured the Agency Head understands the need for an EA, it is important to secure the Agency Head�s commitment to pursue the architecture effort. The CIO accomplishes this by mobilizing the Agency Head�s appreciation into the expression of clear, Agency-wide support. This will establish a mandate to business and CIO executives to support the effort by allocating the needed time and resources. The CIO should coordinate with the Agency Head on the selection of an Agency executive to be designated as the Chief Architect. Experience demonstrates that the CIO�s authority alone is insufficient to make the endeavor a success. A clear mandate from the Agency Head is a prerequisite to success.
3.1.2. Issue an Executive Enterprise Architecture Policy
The CIO, in collaboration with the Agency Head, develops a policy based on the Agency�s architecture principles that governs the development, implementation, and maintenance of the EA. The EA policy should be approved by the Agency Head and, at a minimum, should include:
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
12 February 2001
• Description of the purpose and value of an EA
• Description of the relationship of the EA to the Agency�s strategic vision and plans
• Description of the relationship of the EA to capital planning, enterprise engineering, and program management
• Translation of business strategies into EA goals, objectives, and strategies
• Commitment to develop, implement, and maintain an EA
• Identification of EA compliance as one criterion for new and ongoing investments
• Overview of an enforcement policy
• Security practices to include certification and accreditation
• Appointment of the Chief Architect and establishment of an EA core team
• Establishment of the EA Program Management Office (EAPMO)
• Establishment of the EA Executive Steering Committee (EAESC).
3.1.3. Obtain Support from Senior Executives and Business Units
Commitment and participation of the Agency�s senior executive and business teams are vitally important. The CIO should initiate a marketing program to emphasize the value of the architecture and the Agency Head�s support and commitment. The senior executive team and its organizational units are both stakeholders and users of the architecture. Therefore, the CIO invests time and effort in familiarizing the staff with what an EA is and how it can help achieve organizational goals and commitments. Even though the target audience varies among Agencies, the audience for Departments should include the Deputy and Under Secretaries and the Assistant Secretaries and their key staffs. For Agencies, the audience should include the Deputy and Assistant Administrators, Commissioners, or Bureau Chiefs.
The primary goal of educating the Department and Agency senior executives is to obtain their concurrence and commitment to having their organizations as active participants. Participation can involve the executives (or their designees) in attending planning sessions, committing resources (people and funding) for specific tasks, or becoming a champion or spokesperson for the effort. Maintaining the participation and support of key executives is crucial to sustaining a successful effort.
The Chief Architect should create a plan to obtain the support of the enterprise�s business units. It is recommended that the business units establish an "inner circle" of domain owners and subject matter experts (SMEs). This leadership group should consist of business unit managers who �own� specific lines of business. This leadership group should be able to understand and communicate enterprise goals and objectives, and to think creatively, with consideration of budgets and other constraints. This group of managers is responsible for ensuring that the business layers of the architecture are properly documented, and that the sequencing plan makes sense from the perspective of the business strategy, considering both automated and non- automated processes.
Once the EA policy has been disseminated, the CIO and Chief Architect should organize and conduct a program kickoff meeting to explain the EA goals, objectives, processes, products, and interrelationships with activities of the systems development life cycle, capital planning and investment process, and other related activities. The goal of the program kickoff meeting is to
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
13 February 2001
promote buy-in by program participants at middle and lower levels of the organization. After several of the first EA products are developed and analyzed, the products and analysis should be disseminated throughout the Agency and its communities of interest to demonstrate the value of these early results and achieve maximum exposure for the benefits of the EA development effort.
3.2. Establish Management Structure and Control
Figure 4 illustrates a notional program organization to manage, control, and monitor EA activity and progress. The organization shows the desired functional roles, interrelationships, and lines of communication. The organization structure should facilitate and advance the performance of EA roles and responsibilities. The roles of the EAESC, Technical Review Committee (TRC), and the EA Program Management Office are unique to the introduction of the EA process. Other roles, such as Quality Assurance (QA), Configuration Management (CM), Risk Management (RM), Security, and Evaluation are customary IT support roles. These roles are expanded to explicitly include EA-related responsibilities.
EA roles should be evaluated based on the size of the organization, the complexity of the business and architecture, and other factors to effectively determine the correlation of roles assigned to personnel. In a large organization with complex business processes, an individual may be responsible for one specific role. In smaller Agencies or organizations, an individual may be assigned several roles and responsibilities.
Chief Architect
Architecture Core Team
EA Program Management Office
Technical Review
Committee
Risk Management
Configuration Management
Evaluation
Agency Head
Chief Information
Officer
Subject Matter
Experts
Domain Owners
Business Line Organization Staff
Organization
Quality Assurance
Capital Investment
Council
EA Executive Steering
Committee
Figure 4. Notional EA Organization
Establish Management Structure and Control
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
14 February 2001
3.2.1. Establish a Technical Review Committee
The CIO should charter and appoint a Technical Review Committee to manage the review of candidate projects and assess project alignment with the EA. Once the EA has been developed and approved, the TRC assesses each proposed investment for compliance with the architecture. The TRC reports their conclusions and provides recommendations to a Capital Investment Council (CIC).
In all cases, the TRC determines and documents the results and the accompanying rationale for its actions. The TRC reviews a project and assesses if:
• The project completely aligns with the EA
• The project does not align with the EA and an alternate course of action is needed
• The project does not align with the EA and a waiver is approved.
The TRC approves a waiver only if the impacts of the lack of alignment are understood and acceptable. By approving a waiver, the TRC conveys to the CIC that it does not object to the proposed project.
3.2.2. Establish a Capital Investment Council
The Agency Head establishes a CIC to achieve informed decision making regarding costs, benefits, risks of alternative investment options and architectural alignment. The goal of the CIC is to ensure enterprise and application architecture projects are feasible from a cost-benefit standpoint. The CIC reviews proposed IT investments and makes the final investment funding decision. It accepts program and project proposals that have been assessed by the TRC and determines whether these programs/projects fit within the overall budgetary and funding goals for the enterprise. While a project may be technically aligned with the EA, the CIC may reject funding for a project because of other external constraints or budgetary reasons. CIC decisions may necessitate updates to the sequencing plan.
3.2.3. Establish an EA Executive Steering Committee
The Agency Head establishes an EA Executive Steering Committee to direct, oversee, and approve the EA and EA program. The EAESC is responsible for approving the initial EA, approving significant changes to the EA, and approving the EA Program Plan.
The EAESC should be formally chartered, with a designated chair or co-chairs, and empowered to ensure Agency-wide strategic direction, oversight, and decision-making authority for the EA. The EAESC charter should authorize the chair or co-chairs to appoint the membership. By charter, the EAESC membership should consist of active participants that represent and include all major Agency business and technology areas. To perform effectively as a decision-making body, it is crucial that the EAESC members are senior leaders, with the authority to commit resources and make and enforce decisions within their respective organizations.
3.2.4. Appoint Chief Architect
The CIO should appoint, with the Agency Head�s approval, an Agency executive to serve as Chief Architect and EA Program Manager. The Chief Architect is responsible for leading the development of the EA work products and support environment. The Chief Architect serves as the technology and business leader for the development organization, ensuring the integrity of the
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
15 February 2001
architectural development processes and the content of the EA products. The Chief Architect should be friend and liaison to the business line units and ensure that business unit processes are emphasized in the EA. Likewise, the Chief Architect is responsible for ensuring that the EA provides the best possible information and guidance to IT projects and stakeholders, and that systems development efforts are properly aligned with business unit requirements.
In the role of EA Program Manager, the Chief Architect has management responsibility for the EA program, with the authority, responsibility, and accountability for the overall architectural effort. The Program Manager is responsible for the planning, staffing, and ultimate success of the program, including acquisition of sustaining funding, negotiating schedules, timely and accurate delivery of the EA products, and the establishment of an appropriate support environment that ensures proper application of these assets.
The core competencies of the Chief Architect include expertise in strategic and technical planning, policy development, capital planning and investment control, change management, systems engineering and architectural design, business process reengineering, and large-scale program management. In addition, the Chief Architect becomes completely conversant with the Agency�s business and IT environments. As the primary technical leader of this effort, the Chief Architect should be a good communicator who can bridge the cultural differences that often exist between the business and systems organizations, and facilitate interaction and cooperation between these two cultures.
3.2.5. Establish an Enterprise Architecture Program Management Office
The EA effort should be treated as a formal program with full sponsorship through the Agency's CPIC process. An EA Program Management Office should be established to manage, monitor, and control the development and maintenance of the EA. The EAPMO staff includes experienced architects. The EAPMO identifies and performs cost analyses of alternative approaches for developing the EA, and manages in-house or outside contractor EA development work. The EAPMO is also charged with determining needed resources and securing funding and resource commitments.
A primary goal of the EAPMO and the EAESC is to ensure success of the EA program. Each phase of the program (i.e., EA development, use, and maintenance) is subject to the CIC policies and procedures for investment decisions.
3.2.5.1. Appoint Key Personnel
The CIO should make the EA an explicit responsibility for those individuals designated as the organization�s Evaluators, Risk Manager, and Configuration Manager. The Risk Manager identifies, monitors, controls, and mitigates EA program risks in light of environmental factors (e.g., external business constraints, and technical constraints). The Configuration Manager assumes responsibility for configuration management of the EA products in the same way that configuration management is imposed on any other engineering baseline.
The CIO should establish an independent QA organization to perform evaluation of the EA. This team should report to the EAESC and ensure all established program and project standards and processes are met. Potential sources for review include external reference groups, impartial or uninvolved external entities, or by hiring a neutral third party specializing in assessments or validations. Within the Federal government, Agencies can request their Inspector Generals to
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
16 February 2001
conduct an IV&V review or enlist the services of a non-profit entity such as a Federally Funded Research and Development Center (FFRDC).
3.2.5.2. Establish Enterprise Architecture Core Team
At the same time the Agency Head and CIO achieve business line ownership of the effort, a core team of IT experts, business line experts, and technologists should be assigned to develop the desired process and procedures used throughout the development effort. Participants should have an understanding of the current business and technical environment and the strategic business objectives envisioned in the EA. The team includes the Chief Architect; senior business, systems, data, infrastructure and security systems architects. This team should be well grounded in the existing environment and prepared to document and develop the EA that will support evolving business needs.
The architecture core team should include IT representatives from the Agency's applications, data, and infrastructure organizations. The specific core teamwork groups should include business analysts, data analysts, systems designers, security specialists, and systems programmers. As the program gets underway, more resources/team members are typically added to the architecture core team. The architecture core team will include program managers proficient in managing Agency-wide programs as well as interagency initiatives.
The EA core team is responsible for all activities involving the development, implementation, maintenance, and management of the architecture. This includes:
• Developing EA processes, procedures, and standards
• Developing baseline and target architectures
• Developing and maintaining an EA repository
• Performing quality assurance, risk management, and configuration management
• Guiding systems development and acquisition efforts
• Defining EA performance measures.
Table 1 provides a listing of functional roles and the associated responsibilities assigned to EA core team members. In smaller agencies, some of these roles and responsibilities may be shared, doubled up, or contracted out.
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
17 February 2001
Table 1. EAPMO Roles and Responsibilities
Role Responsibilities
Chief Architect Heads the EAPMO, organizes and manages the EA core team; directs development of the baseline and target architecture.
Senior Architecture Consultant Provides architecture strategy and planning consultation to the Chief Architect.
Business Architect Analyzes and documents business processes, scenarios, and information flow.
Applications Architect Analyzes and documents systems, internal and external interfaces, control, and data flow.
Information Architect Analyzes and documents business information (logical and physical) and associated relationships.
Infrastructure Architect Analyzes and documents system environments, including network communications, nodes, operating systems, applications, application servers, web and portal servers, and middleware.
Security Systems Architect Oversees, coordinates, and documents IT security aspects of the EA, including design, operations, encryption, vulnerability, access, and the use of authentication processes.
Technical Writer Ensures that policies, guidebooks, and other documentation within the EA repository are clear, concise, usable, and conform to configuration management standards.
Quality Assurance Ensures that all established program and project standards, processes, and practices are met.
Risk Management Identifies, monitors, and controls risks in light of environmental factors and constraints.
Configuration Control Assures that all changes are identified, tracked, monitored, and appropriately documented.
3.3. Enterprise Architecture Program Activities and Products
3.3.1. Develop an EA Marketing Strategy and Communications Plan
The purpose of the marketing strategy and communications plan is (1) to keep senior executives and business units continually informed, and (2) to disseminate EA information to management teams. The CIO�s staff, in cooperation with the Chief Architect and support staff, defines a marketing and communications plan consisting of (a) constituencies, (b) level of detail, (c) means of communication, (d) participant feedback, (e) schedule for marketing efforts, and (f) method of evaluating progress and buy-in. It is the CIO�s role to interpret the Agency Head�s vision and to recognize innovative ideas (e.g., the creation of a digital government) that can become key drivers within the EA strategy and plan. If resources permit, the Chief Architect should use one or all of the following tools to communicate with the community of interest: seminars and forums, web pages, electronic surveys, and e-mail listservs.
One of the recommended means for marketing the EA is a primer to inform Agency business executives and stakeholders of the EA strategy and plan. The primer can be used to express the Agency Head�s vision for the enterprise and the role of EA in accomplishing that vision�for example, creating the integrated foundation for online government or streamlining business processes and technology.
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
18 February 2001
The primer should describe the tenets of the EA and its many benefits as an agent of change in achieving organizational goals (e.g., integrating business services and initiatives) or as a critical resource to evaluate options for change as business and technology needs evolve. The primer should clearly describe the roles and responsibilities of the senior executives and their organizational units in developing, implementing, and maintaining the EA. It is important that the primer include customized sections that relate directly to specific business line audiences.
The primer should demonstrate the benefits of an EA for the Agency's stakeholders. This is particularly important since many of the stakeholders may be needed to provide skilled resources, support, and time to the effort. Once completed, the primer should be widely distributed throughout the Agency and made available on the Agency's web site. It should be briefed to all personnel impacted by the introduction of the EA. Introductory materials drawn from the primer should be incorporated into local and Agency-wide training programs.
3.3.2. Develop an EA Program Management Plan
A formal plan is desired for sound program management. The EAPMO creates an EA program management plan (PMP) that includes a roadmap to accomplish the goals set by the EAESC and implementation plans to achieve those goals. The plan should include goals for the Chief Architect in setting Agency-wide architectural objectives. These goals should help the architecture team establish and maintain lower-level architectures that comply with the EA.
The PMP delineates plans and a set of actions to develop, use, and maintain the EA, including EA management, control, and oversight. To facilitate the tracking of cost, schedule, and performance data, oversight and control procedures should be developed, documented, and implemented within the PMP. The PMP should also include:
• Requirements for the EA Program Manager to identify all funding requirements, spending timelines/schedules, and links to performance measures
• A Work Breakdown Structure (WBS) detailing the tasks and subtasks necessary to acquire, develop, and maintain the architecture
• Resource estimates for funding, staffing, training, workspace requirements, and equipment needs
• Roadmap for the initiation of project plans
• Requirements for performing quality assurance, risk management, configuration management, and security management
• Requirements for the establishment and maintenance of an EA information repository.
3.3.3. Initiate Development of the Enterprise Architecture
Once the EAPMO is in place and the PMP is produced, the first of the architecture projects is launched. There are several peripheral activities associated with the start of this development. The EAPMO�s initial project will:
• Institute PMP practices
• Establish EA development processes and management practices
• Train EA project participants
• Build baseline EA products
• Build target EA products (as possible)
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
19 February 2001
• Create the sequencing plan
• Populate the EA repository.
Sections 4 and 5 provide discussions on the details of the development of the EA.
A Practical Guide to Federal Enterprise Architecture Initiate Enterprise Architecture Program
20 February 2001
21 February 2001
Goals:
� Build a baseline architecture that represents reality
� Build a target architecture that represents the business vision and IT strategies
� Develop a sequencing plan that describes an incremental strategy for transitioning the baseline to the target
� Publish an approved EA and sequencing plan that are accessible by agency employees
Define an Architecture Process and Approach
4. Define an Architecture Process and Approach
The next step in the EA process is establishing an EA process and approach. The EA will be used as a tool to facilitate and manage change within the Agency organization. The scope and nature of the Agency and the changes to be made will dictate the scope and nature of the architecture to be developed. While the EA is an excellent tool to manage large and complex environments, the depth and detail of the EA needs to be tailored to the individual enterprise. Figure 5 illustrates how the depth and detail in the EA varies not only with the size and complexity of the enterprise, but also the many types of risks associated with change. Regardless, the scope of the enterprise architecture for the strategic planner and business owner views (as defined by the architecture framework selected) needs to encompass the entire enterprise. The agency will understand the relationships and dependencies among its lines-of-business and thus position itself to make informed decisions on how to approach defining EA depth and detail for these lines-of-business.
The first activity in this process is to determine the intended use of the architecture. It drives the rest of the EA development process. The subsequent activities describe how to scope, characterize, select EA products, build, and use the EA.
Before actually developing the EA, an Agency needs to evaluate and select an architectural framework as guidance. This section describes several candidate frameworks currently used within the Federal community. The selection of a framework is contingent on the purpose of the EA and the products to be developed. Additionally, a toolset or repository for the EA development and use should be employed. The chosen tool should be commensurate with the products to be generated.
Size
Complexity
Risk
Depth & Detail
Figure 5. Depth and Detail of the Architecture
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
22 February 2001
4.1. Define the Intended Use of the Architecture
Architectures should be built with a specific purpose in mind. It could be business process reengineering, systems acquisition, system-of-systems migration or integration, user training, interoperability evaluation, or any other intent. The purpose of the architecture is closely tied to the organization�s Strategic Plan(s), legislation such as GPRA and Clinger-Cohen, and support of the capital investment process. Before an architect begins to describe an architecture, the organization determines the changes the architecture is intended to facilitate, the issue(s) the architecture is intended to explore, the questions the architecture is expected to help answer, and the interests and perspectives of the audience and users. One important practical consideration is determining the types of analyses that will be performed; i.e., knowing that the architecture may be used as input to specific models or simulations can affect what to include and how to structure the products.
The purpose of the EA may, and likely will, evolve over time to meet new requirements. The Chief Architect should ensure that any such EA evolution does, in fact, meet the newly determined requirements. This will increase the efficiency of the architecture development and create greater balance in the resulting architecture.
4.2. Define the Scope of the Architecture
It is critically important that EA development be approached in a top-down, incremental manner, consistent with the hierarchical architectural views that are the building blocks of proven EA frameworks, including the ones discussed later in this guide. In doing so, it is equally important that the scope of the higher level business views of the EA span the entire enterprise or agency. By developing this enterprise-wide understanding of business processes and rules, and information needs, flows, and locations, the agency will be positioned to make good decisions about whether the enterprise, and thus the EA, can be appropriately compartmentalized. Without doing so, scoping decisions about the EA run the risk of promoting �stove-piped� operations and systems environments, and ultimately sub-optimizing enterprise performance and accountability. Other considerations relevant to defining the scope of the EA include, but are not limited to:
• Relevance of activities, functions, organizations, timeframes, etc.
• Enterprise scope (intra- and inter-Agency domains)
• Operational scenarios, situations, and geographical areas to be considered
• Projected economic benefits
• Projected business and technical risk areas
• Projected availability and capabilities of specific technologies during the target timeframe (applies to target architecture only).
Defining the scope leads the planners to project management factors that will contribute to these determinations, including the resources available for building the architecture as well as the resources and level of expertise available for analysis and design tasks.
4.3. Determine the Depth of the Architecture
Care should be taken to judge the appropriate level of detail to be captured based on the intended use and scope of the EA and executive decisions to be made using the EA. It is important that a consistent and equal level of depth be completed in each view and perspective. If pertinent characteristics are omitted, the architecture may not be useful. If unnecessary characteristics are
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
23 February 2001
included, the architecture effort may prove infeasible given the time and resources available, or the architecture may be confusing and/or cluttered with details that are superfluous. EA characteristics are influenced by the focus: whether primarily capturing the baseline vs. the target and vice-versa. It is equally important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or reuse. The depth and detail of the EA needs to be sufficient for its purpose.
4.4. Select Appropriate EA Products
Essential products are those required for all architectures, while supporting products may be necessary to fulfill specific informational needs. Only those supporting products that portray the desired characteristics should be built. The required products should help formulate the selection of a framework and associated toolset.
It is essential that the Chief Architect guide the construction of the technical content to meet the needs of the EA, especially in the desired level of detail needed in the work products. If the content is at too high a level of abstraction, it may not be sufficiently useful to guide projects and reviews. If the content is too detailed, it may be difficult to manage.
4.4.1. Select Products that Represent the Business of the Enterprise
As the first step in identifying and creating the business definition, the Chief Architect determines which products can be used to provide an integrated view of the Agency core business. These include functional, informational, and organizational models. Functional or process models may be represented in several forms, including:
• Use Cases
• Activity Models/Trees
• IDEF [Integrated Computer Aided Manufacturing (ICAM) Definition] business process models
• Concept of Operations (CONOPS)
• State Models.
Information models include class models and conceptual data models. Appropriate combinations of these models should be used to represent internal and external organizational participants, activities, inputs, outputs, flow of information, sequencing, interrelationships between data, and external interfaces. The models span the enterprise and represent the enterprise at the strategic level. Additional information and examples of these models are provided in Appendix D.
The business definition should be created in the baseline and target architectures and the sequencing plan. In the baseline architecture, it represents the current state of business operations and information exchange within and across the organization. In the sequencing plan, it
Model�representations of reality: the information, activities, relationships, and constraints.
Essential products�the graphics, models, and/or narratives that every architecture description must include, to support the scope and characteristics of the EA.
Supporting products�the graphics, models, and/or narratives that may be needed to further elaborate on essential products or to address particular domain or scope extensions (e.g., real-time or special performance considerations).
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
24 February 2001
represents business changes and maps to planned systems and business improvements. In the target architecture, it represents planned business operations as expressed in business strategies and visions.
4.4.2. Select Products that Represent Agency Technical Assets
The technical content of the EA represents the technical assets of the Agency. It consists of the logical and physical designs of the baseline and target architectures. At a minimum, this content includes designs of data, applications, and infrastructure (including hardware, software, and communications). These products identify information needs, software applications/programs, middleware, and underlying physical infrastructure supporting the current environment and needed to support the Concept of Operations (CONOPS) for the enterprise in its target state.
EA products created to support business content are often extended to represent the solution space. Thus, many of the models could be reused, extended, and referenced in order to define the technical architecture. The purpose of the technical architecture is to ensure that a conforming system satisfies a specific set of business needs and requirements. It provides the technical systems implementation guidelines for creating engineering specifications and developing products.
4.5. Evaluate and Select a Framework
As each Federal Agency embarks on this stage of the architecture process, it must select an appropriate architectural framework. A number of well-established frameworks are successfully used throughout the Federal sector. Alternatively, an Agency may choose to develop its own framework, although the costs, benefits, and risks of doing so should be weighed against the risks of adopting or tailoring an existing framework. While Federal Agencies vary widely in their approach to architecture development and implementation, established frameworks permit comparisons and analyses across Agencies. Therefore, it is recommended that before an Agency develops a new framework (if an Agency has a mandated framework, it must be employed), it should investigate the use of other existing Federally developed frameworks.
Three Federally sponsored (and commonly accepted) architectural frameworks are used as candidate frameworks and for descriptive purposes within this EA guide. These contain essential and supporting products, and promote development of architectures that are complete, understandable, and integratable. The organizations that developed these frameworks continue to tailor them to ensure parallel precepts, principles, and methodologies. The frameworks are:
• Federal Enterprise Architecture Framework (FEAF)
• Department of Defense (DoD) Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework
• Treasury Enterprise Architecture Framework (TEAF).
Other EA frameworks exist and have been used in Government programs (e.g., Department of Agriculture�s framework and the National Institute of Standards and Technology [NIST] framework). This guide does not address these other frameworks because most organizations have standardized on the FEAF, C4ISR, and TEAF for EA development. In addition to EA frameworks, many processes exist that can be used to support framework development, such as
Framework�a logical structure for classifying and organizing complex information.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
25 February 2001
the Department of Energy�s corporate systems information architecture roadmap for IT systems implementation. Since a notional process is described in this guide, other Federal Agency EA processes are not discussed.
The use of an EA framework ensures uniformity and standardization when migrating and integrating information systems. The selected framework will depend on the intended use, scope, and characteristics of the architecture to be developed. Table 2 lists major factors to consider.
Table 2. Framework Selection Criteria
Areas Factors
Policy
• Regulatory and legislative direction
• Agency policy
• Compatibility needed with another Agency or joint policy
Enterprise
• Context for the enterprise�e.g., subordinate to a larger enterprise, closely related to another enterprise
• Experience with a particular framework
• Mandates and drivers�e.g., emphasis on business versus infrastructure or operational versus technical issues
EA products
• Priorities, intended uses and desired level of detail�e.g., large scale modernization versus stable IT environment
• Resource and schedule constraints on modeling efforts
• Availability of existing architecture products
Frameworks include concepts that drive the types of architecture products being created. The products, both graphical and textual, capture the information prescribed by the framework. Equivalent products may be substituted if the new product has similar or more extensive attributes than the original product. This is often done when specific methods (e.g., object- oriented analysis and design) lend themselves to particular modeling techniques.
Using the FEAF, C4ISR, or TEAF frameworks should substantially reduce the development process and will shorten the time to get an EA in place and put an Agency on a path for success. The following sections provide a brief description of the FEAF, C4ISR, and TEAF frameworks.
4.5.1. Federal Enterprise Architecture Framework
In September 1999, the Federal CIO Council published the Federal Enterprise Architecture Framework, Version 1.1 for developing an EA within any Federal Agency or for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that cross organizational boundaries. The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government. These Federal architectural segments collectively constitute the Federal EA. Currently, the FAWG is sponsoring the development of EA products for trade and grant Federal architecture segments.
Method�a prescribed way of approaching a particular problem.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
26 February 2001
As shown in Figure 6, the FEAF partitions a given architecture into business, data, applications, and technology architectures. The FEAF currently includes the first three columns of the Zachman framework and the Spewak EA planning methodology (see Appendix G).
Figure 6. Structure of the FEAF Components
For the Federal Enterprise, the Federal CIO Council seeks to develop, maintain, and facilitate the implementation of a top-level EA predicated upon the FEAF. This architecture serves as a reference point to facilitate the efficient and effective coordination of common business processes, technology insertion, information flows, systems, and investments among Federal Agencies. The FEAF provides a structure to develop, maintain, and implement top-level operating environments and support implementation of IT systems. As shown in Figure 7, the FEAF is graphically represented as a 3x5 matrix with architecture types (Data, Application, and Technology) on one axis of the matrix, and perspectives (Planner, Owner, Designer, Builder, and Subcontractor) on the other. The corresponding EA products are listed within the cells of the matrix.
Data Architecture
Application Architecture
Technology Architecture
Planner Perspective
Owner Perspective
Designer Perspective
Subcontractor Perspective
Business Logistics System
Data Dictionary
Systems Design
Network Architecture
Logical Data Model
Physical Data Model
Programs
List of Business Locations
System Geographic Deployment Architecture
Technology Architecture
List of Business Objects
Semantic Model Business Process Model
Application Architecture
List of Business Processes
Builder Perspective
Figure 7. FEAF Architecture Matrix
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
27 February 2001
4.5.2. DoD C4ISR Architecture Framework
In December 1997, the DoD published its C4ISR Architecture Framework. This framework applies to all branches of the armed services and includes the numerous major and subordinate commands, field organizations, and task forces within each service.
In the C4ISR Architectural Framework, the operational view describes the tasks and activities, operational elements, and information flows needed to accomplish or to support an operation. It specifies the nature of each needline�s information exchange in sufficient detail to determine the desired degree of interoperability. The systems view identifies which systems support the requirement. It translates the desired degree of interoperability into a set of needed system capabilities, and compares current/postulated implementations with the needed capabilities. The technical view defines the criteria that govern the implementation of each system capability. To be consistent and integrated, an architecture description should provide explicit linkages among its various views. Figure 8 illustrates these three views and their relationships.
Sy st
em s
A ss
oc ia
tio ns
to
N od
es , A
ct iv
iti es
, N ee
dl in
es ,
a nd
R eq
ui re
m en
ts
Identifies Warfighter Relationships and Information Needs
Operational View
Prescribes Standards and Conventions
Technical View
Relates Capabilities and Characteristics to Operational Requirements
Systems View
Technical Criteria Governing Interoperable Implementation/ Procurement of the Selected System Capabilities
Specific Capabilities Identified to Satisfy Information- Exchange Levels and Other Operational Requirements
B asic Technology
Supportability and N ew
C apabilities
Processing and Levels of
Inform ation Exchange
R equirem
ents
Pro ce
ss in
g a nd
In te
rn od
al
Lev el
s of
In fo
rm at
io n
Exc han
ge Req
ui re
m en
ts
Figure 8. DoD C4ISR Framework
Figure 9 depicts the C4ISR essential and supporting architecture products. Appendix D provides examples of C4ISR essential products.
Needline�a requirement that is the logical expression of the need to transfer information among nodes.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
28 February 2001
All Views
Operational View
Systems View
Technical View
Integrated Dictionary
Activity Model
Systems Communications
Description
System Functionality Description
Command Relationship Chart
Systems Information Exchange Matrix
Logical Data Model
Physical Data Model
System Evolution Description
Systems Interface
Description
Operational Rules Model
State Transition Description
Technical Architecture
Profile
Standards Technology
Forecast
Operational Activity to System Function Traceability Matrix
Overview & Summary Information
Node Connectivity Description
High-level Concept of Operations
Graphic
Information Exchange
Matrix
Systems Matrix
Event Trace Diagrams
Systems Event Trace Diagrams
Systems Rules Model
System State Transition
System Technology Forecast
System Performance Parameters Matrix
Supporting Work ProductsEssential Work Products
Figure 9. DoD C4ISR Products
4.5.3. Treasury Enterprise Architecture Framework
In July 2000, the Department of the Treasury published the Treasury Enterprise Architecture Framework. The TEAF provides (1) guidance to Treasury bureaus concerning the development and evolution of information systems architecture; (2) a unifying concept, common principles, technologies, and standards for information systems; and (3) a template for the development of the EA.
The TEAF describes an architectural framework that supports Treasury's business processes in terms of products. This framework guides the development and redesign of the business processes for various bureaus in order to meet the requirements of recent legislation in a rapidly changing technology environment. The TEAF prescribes architectural views and delineates a set of notional products to portray these views. Figure 10 illustrates the TEAF framework.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
29 February 2001
Functional
Information
Organizational
Infrastructure
How, Where, and When
What, How Much, and How Frequently
Who and Why
Enabler
Figure 10. The Treasury Enterprise Architecture Framework
The TEAF�s functional, information and organizational architecture views collectively model the organization�s processes, procedures, and business operations. By grounding the architecture in the business of the organization, the TEAF defines the core business procedures and enterprise processes. Through its explicit models, a TEAF-based architecture enables the identification and reasoning of enterprise- and system-level concerns and investment decisions.
The TEAF provides a unifying concept, common terminology and principles, common standards and formats, a normalized context for strategic planning and budget formulation, and a universal approach for resolving policy and management issues. It describes the enterprise information systems architecture and its components, including the architecture�s purpose, benefits, characteristics, and structure. The TEAF introduces various architectural views and delineates several modeling techniques. Each view is supported with graphics, data repositories, matrices, or reports (i.e., architectural products). Figure 11 shows a matrix with four views and four perspectives. Essential products are shown across the top two rows of the matrix. It is notable that the TEAF includes an Information Assurance Trust model, the Technical Reference Model, and standards profiles as essential work products. These are not often addressed as critical framework components.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
30 February 2001
Functional View
Information View
Organizational View
Infrastructure View
Planner Perspective
Owner Perspective
Designer Perspective
Builder Perspective
Info Assurance Trust Model
Business Process/ System Function
Matrix
State Charts
System Functionality Description
Information Exchange Matrix
(Logical)
Information Exchange Matrix
(Physical)
Logical Data Model
Physical Data Model
Data CRUD Matrices
Organization Charts
Node Connectivity Description
(Logical)
Node Connectivity Description (Physical)
Technical Reference
Model
Standards Profile
Info Assurance Risk Assessment
System Interface Description
(Level 1)
System Interface Description (Level 2 & 3)
System Interface Description
(Level 4)
System Performance Parameters Matrix
Mission & Vision Statements
Activity Model
Information Dictionary
Information Exchange Matrix
(Conceptual)
Node Connectivity Description
(Conceptual)
Event Trace Diagrams
Supporting Work ProductsEssential Work Products
EA Repository Listings
High Level Modeling
Logical Modeling
Physical Modeling
Figure 11. TEAF Products
One of these frameworks should provide a means to logically structure and organize the selected EA products. Now, in order to effectively create and maintain the EA products, a toolset should be selected.
4.6. Select an EA Toolset
To increase the usefulness of any architecture, it is important to maintain the EA within an interactive architectural tool. Fortunately, there are many automated architecture tools available on the market today. The choice of tool should be predicated upon the organization�s needs based on the size and complexity of its architecture. The Chief Architect and architecture core team may use the Office suite of tools (e.g., Microsoft�s PowerPoint and Word) and/or modeling tools (e.g., Rational Rose by Rational Corporation, Systems Architect by Popkin, or Framework by Ptech).
There are toolsets available from leading vendors that can provide alignment with the chosen framework and recommended products. Tool criteria should be determined based on the intended use of the architecture, scope, levels of integration desired, and other factors. Table 3 lists candidate topics to aid in the selection of tools. The list can be tailored to a specific set of requirements for tool selection. One tool will probably not meet all requirements. Therefore, a tool suite or combination of tools will be needed. The work products should be maintained in several different types of media such as hardcopy documentation (briefings and reports), electronic files on CD-ROM, HTML documents on the web, and other EA Computer Aided Software Engineering (CASE) tools and development tools that provide a relational database management system.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
31 February 2001
Table 3. Tool Selection Criteria
Functional Area Criteria
Development of EA products
• Available platforms
• Support for chosen framework
• Support for modeling methods and techniques�e.g., object- oriented analysis and design, IDEF, activity models, class models, information models
• Import/Export capability
• Cost (initial and maintenance) and licensing
• Vendor support (e.g., time, cost)
• Training schedule, cost, length
• Ease of use
• Integration of products generated�ability to integrate baseline and target architectures and enterprise engineering products
• Capacity, expected size, and complexity of models
• Integrated and consolidated repository
• Multi-user support
• Meta-model support (e.g., ability to configure and tailor model elements)
• RM support/issues tracking
• CM support
• QA support
Maintenance of EA products
• Ability to interoperate with other enterprise engineering products and development tools/repositories
• Traceability to requirements and other enterprise engineering artifacts
• RM support/issues tracking
• CM support
• QA support
Dissemination of EA products
• Accessibility (e.g., software needed, access requirements)
• Documentation generation�briefings and reports
• Media supported (e.g., CD-ROM, HTML)
• Levels of Access control (e.g., Read-Only, Read-Write)
• Use of hypertext links
Tool standardization is a recommended best practice. It proves cost-effective when determining architecture quality and alignment with the EA policy from an acquisition cost perspective and for consistent interoperability of models.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
32 February 2001
33 February 2001
5. Develop the Enterprise Architecture
The next step is to build the architecture products based on the purpose of the architecture and the chosen framework. This consists of the essential products, supporting products (if needed), and individually defined products (e.g., briefing charts, interview notes) driven by architecture- specific needs and processes. To facilitate integration with other architectures, it is crucial to include all depictions of relationships with applicable external components, that is, entities outside the Agency.
It may be useful, resources permitting, to conduct some proof-of-principle analyses at various stages of architecture development. For example, one could conduct trial runs of the EA development process using carefully selected subsets of the areas to be analyzed. The architecture core team should ensure that the products are consistent and properly interrelated. If the products are not applied and populated uniformly, the Chief Architect and architecture core team will be unable to compare or contrast the products or perform thorough analyses.
Regardless of the scope and complexity of the views to be developed, the architecture core team should apply a consistent approach to developing the baseline and target architectures. The selected approach should include (1) a data collection phase, (2) preliminary product generation, (3) review and revision stages, and (4) publication and delivery of the architecture products to an appropriate repository. Figure 12 shows a typical process for developing the EA products. Each of these activities is described in more detail in the following subsections.
Literature and
Documentation Review
Familiarization Training
Preliminary Meetings
and Interviews
Hold Group
Brainstorming Sessions
Conduct In-depth
Individual Interviews
Revise Products
As Needed
Generate Preliminary
Products
Generate Briefing
and Present
Publish Architecture
Products
Independent and SME
Review and Validation
Populate Tools and
Repositories
Data Collection
Preliminary Product Generation
Review and Revision
Publication and Delivery
Figure 12. Example Approach for EA Development
Develop Baseline Enterprise Architecture
Develop Target Enterprise Architecture
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
34 February 2001
5.1. Collect Information
The first step in the build approach is to identify and collect existing products that describe the enterprise as it exists today and as it is intended to look and operate in the future. Data collection is the crucial, initial effort involving review of documentation, staging of training sessions, and interviewing SMEs and domain owners.
All appropriate collected information and products should be placed in a centralized electronic EA repository. In the case of the baseline architecture, sample products to be collected include:
• Current business functions and information flows
• Data models
• External interface descriptions
• Existing application and systems documentation
• Technical designs, specifications, and equipment inventories.
In the case of the target architecture, sample products to be collected include:
• Proposed business processes and information flow
• Strategic plans
• Modernization plans
• Requirements documents.
Many of these products may not exist or may not accurately represent the current baseline or proposed target environments. If documentation is missing, the architecture core team should develop a strategy to create the needed documentation or decide whether to make the investment. In this case, the interviewers will have to rely on business or system SMEs concerning the purpose and scope of the activity and the expectations for their participation. After collecting a sufficient amount of this data, work can begin on creating the EA products and populating the EA repository.
Ideally, preliminary, draft architectural products can be generated at this time without in-depth SME involvement. With the development of strawman products, the architects can then conduct a series of stakeholder brainstorming sessions and in-depth SME interviews to solidify the products. The Chief Architect should review and validate the proposed interview list and ensure SME participation via communications with the domain owners. The marketing and buy-in process described in Section 3 should have set the stage for this participation.
It may be useful to record these interviews for future reference. Always follow up to ensure that interview information is interpreted correctly. Once the initial interviews are completed, the architecture core team extracts information from the interviews and then refines the existing products within the EA repository.
Repository�an information system used to store and access architectural information, relationships among the information elements, and work products.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
35 February 2001
5.2. Generate Products and Populate EA Repository
Some products may be created during the first iteration of the EA development process while others may be created during later iterations depending on the framework, process, and chosen methods. In addition, depending on whether the baseline or the target is being created, various factors will affect the approach taken, the focus of the products, and the order in which products are generated. These key differentiators are described in Table 4.
Table 4. Baseline and Target Architecture Differentiators
Baseline Architecture Target Architecture Process Process applies the chosen framework. Process applies the same framework as for
Baseline. Process relies extensively on existing documentation, e.g., process and procedure manuals.
Documentation may not exist or is likely to be inconsistent, e.g., various vision and planning documents.
Generation of products will begin in IT organization, and eventually extend to business SMEs for validation of products.
Generation of products begins with heavy participation by SMEs from business units.
Reverse engineering is likely. Process needs verification that requirement and design documentation reflects reality.
Emphasis is on forward engineering, building on business process reengineering efforts and technology forecasts.
Available information is standardized and normalized as a foundation for change.
Material originally produced for different time frames, e.g., 1-year plans, 5-year plans, strategic plans, is integrated to a single vision.
Products Models are based on reality. Models are based on assumptions, plans, and recognized needs, political environment, future technology.
Products describe the entire current enterprise at a consistent, high level. Additional analysis, detail based on priority areas, e.g., known problems areas.
Products describe a vision for the entire enterprise. Additional analysis, detail based on priority areas, e.g., anticipated modernization.
Describes all significant manual and automated operations.
Explicitly includes legacy, with upgrades if they are planned, or there is an implicit decommission of what exists in the Baseline. Also includes planned transitional components.
Consistency, completeness, correctness can be validated.
Consistency, completeness can be validated.
Products are available and controlled in a repository.
Products are available, linked to the Baseline Architecture, and controlled in the same repository as the Baseline architecture.
The information contained in the EA is usually expressed as a collection of interdependent products. The volume of information, as well as the presentation style of that information is often too great for a user to quickly comprehend. Also, users often focus on their particular area of concern and can easily overlook critical dependencies that their processes or assets may have on other processes and organizations in the enterprise. Therefore, providing electronic links among the interdependent information can highlight the interdependencies and greatly improve the understandability of the information. Change control is also significantly streamlined�by establishing the links among information at its origin, impact analysis is facilitated and change proposals can be evaluated more readily. Some agencies document and distribute their EAs in the form of web sites and CD-ROMs, thus easing readability, access, and distribution.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
36 February 2001
The process of getting the enterprise from where it is today to where it wants to be in the future needs formal thought and that focuses on optimizing enterprise-wide performance and accountability. This thought process is documented with the Agency�s strategic plan. This document defines the mission and long-range objectives of the Agency and relates to plans for business reengineering and systems modernization. Together these products should drive the top- down sequence of EA product development.
5.2.1. Essentials in Building the Baseline Architecture
In building the EA, a logical first step is describing the current or "as is" state. This is an important step because it enables future progress to be measured against a baseline. It has been said that if you don't know where you are it's hard to know if you are on the way to where you are going. Establishing a set of architectural products that describe and document the current state of the enterprise from business functions to technology infrastructure sets the stage for establishing a plan for moving towards and measuring progress against a target architecture.
The scope of the baseline analysis and the resultant documentation is critical. The larger the enterprise, the higher the commitment and cost for a comprehensive, explicit, fully detailed and extremely accurate baseline analysis. For larger Departments, there are methods and techniques, as well as models, that facilitate a sampling approach to yield baselines that are useful and less costly. Medium to small enterprises may choose a comprehensive inventory of business processes, applications, and the technology infrastructure in which they operate. In that case, the baseline architecture is a comprehensive inventory of the business functions, software applications and problems, and the technology/hardware infrastructure of the enterprise.
5.2.2. Essentials in Building the Target Architecture
The target architecture should define a vision of future business operations and supporting technology. A long-term blueprint is absolutely necessary. A key consideration is the determination of the date of the target, how far into the future is the projected target. Realization of an organization�s mission and vision statements needs:
• A focus on business areas or information needs with the greatest potential payoff for the enterprise
• Development of conceptual models and tools to enable decision makers and staff to better recognize, understand, and discuss information requirements
• An enterprise-wide understanding of the �big picture� and the need for shared information
• A recognition of information as a strategic resource that should be managed using architectures as tools
• Periodic assessments of the enterprise�s progress towards its target environment
• Alignment with the enterprise�s strategic plan.
The target architecture describes the desired capability and structure of the enterprise business processes, information needs, and IT infrastructure at some point in the future. Therefore, the target architecture is often referred to as the "To-Be" or �As-Planned� architecture. The target architecture may include alternatives, options, and unknowns�this is acceptable. The EA process is iterative�unknowns are filled in over time.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
37 February 2001
A target architecture represents enhancements to an existing baseline architecture that add new functionality to support business operations and provide enhanced support for existing business operations. The target architecture must be fiscally and technologically achievable while being grounded in the business needs of the organization. The realities of rapid technological changes necessitate flexibility and capacity for change in the target architectures: they should project no more than 3 to 5 years into the future.
Just as the baseline architecture captures the existing business practices, functionality, and information flows, the target architecture reflects what the organization needs to evolve its information resources. The target architecture provides answers to these basic questions:
• What are the strategic business objectives of the organization?
• What information is needed to support the business?
• What applications are needed to provide information?
• What technology is needed to support the applications?
The answers to these questions are grounded in the Agency�s information requirements, and in turn, the information needs are predicated upon the organization�s business practices, functionality, and operations. As business roles change, information content and information flow also change. Technology forecasts and information standards profiling can identify the necessary IT to support these changing business processes. These forecasts and standards profiles are necessary prerequisites to developing the target architecture. Within the target architecture, these products can be reflected in the TRM product.
The development of a picture of the organization�s future business processes and information needs is central to successful target architecture development. This business view consists of a set of architectural products derived from the agency�s strategic plans, business process reengineering results, capital investment plans, and other planning documentation.
The target architecture should:
• Reflect the EA team�s judgment about the future uses and characteristics of information within the enterprise
• Reflect the organization�s business requirements review for focusing on the opportunities to automate aspects of work and/or the access to information needed to perform work
• Incorporate technology forecasts
• Specify the needed level of interoperability needed between the data sources and the users of the data
• Identify the IT needed to support the enterprise�s technical objective
• Reflect budgetary and territorial concerns.
Technology Forecast�a detailed description of emerging technologies and technology standards relevant to the systems and business processes covered in the Agency�s EA.
Standards Profile�a specification of documents, technology standards, protocols, and definitions.
Technical Reference Model (TRM)�a taxonomy that provides a consistent set of service areas, interface categories, and relationships to address interoperability and open systems. The TRM integrates the standards
fil d h l f
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
38 February 2001
Develop the Sequencing
Plan
5.2.3. Review, Validate, and Refine Models
Architecture products are presented for both internal and SME review. After an extensive internal review by the EA core team, the SME and domain owners assess the EA products for accuracy and completeness. This occurs at several points in the process. Prior to SME interviews, senior members of the architecture core team perform a "quick look" review. This review sets the stage for the interviewing process. It helps the interviewers formulate a template to focus the interview sessions. The next review occurs after the team has updated and expanded on the first set of products. There may be additional interview/review cycles before moving on to the SME review.
At the SME review, the review participants (i.e., Chief Architect, architecture core team, QA, Risk Manager, SMEs, domain owners) determine EA product accuracy and completeness. The Risk Manager can provide an early assessment of business, technical, cost, or schedule risks. The products should then be revised as necessary and presented to the TRC and EAESC for validation and final approval. Upon approval, the final architecture (products and models) can be published, briefings and documentation delivered, and the appropriate databases or architecture tools updated.
IV&V reviews should be considered at key milestones within the EA process depending on major enterprise engineering milestones, the CPIC milestones, and other factors. Once the EA model and resultant products are stabilized and validated, it is important to respond to recommendations from the validation team(s). If necessary, the architecture core team should augment, evolve, or expand the EA models, both in scope and detail, in accordance with the recommendations.
5.3. Develop the Sequencing Plan
The changes needed to transition from the current state of the enterprise to the goals and conditions expressed by the target architecture cannot be achieved in a single quantum step. Evolving the enterprise from its baseline to the target architecture needs multiple concurrent interdependent activities and incremental builds. The best way to understand and control this complex evolutionary process is by developing and maintaining a systems migration roadmap or sequencing plan. The sequencing plan should provide a step-by-step process for moving from the baseline architecture to the target architecture.
The sequencing plan may be supported by a set of architecture products, similar to the baseline and target architecture products, generated for several intermediate points in time between the baseline and target environments. The succession from one point in time to the next, and on to the target timeframe, establishes a migration sequence.
Because the sequencing plan represents the current environment, as well as the development programs that are both planned and under way, it becomes a primary tool for program management and investment decisions. To remain current and to support continued coordinated improvements across the enterprise, the sequencing plan should be maintained and updated as time and circumstances dictate.
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
39 February 2001
In addition to specific development requirements for the new components in the target architecture, development of the sequencing plan should consider a wide variety of inputs, including:
• Sustainment of operations during transition
• Existing technical assets and contractual agreements
• Development programs currently underway
• Anticipated management and organizational changes
• Business goals and operational priorities (including legislation and executive directives)
• Budget priorities and constraints.
5.3.1. Identify Gaps
The first step in transition planning is gap analysis�identifying the differences between the baseline and target architectures in all related architecture products. Critical differences are those that affect the successful accomplishment of the enterprise�s mission. Consequently, the gap analysis also develops the user requirements, determines political and technical constraints, and assesses migration risks and feasibility.
Through gap analysis, the architecture core team can determine the components that need to be changed to achieve the desired end-state. The gap between baseline and target architectures is overcome by a series of incremental builds that lead to the target environment. The size of the increments is based upon the overall time between the baseline and target, dependencies among developmental programs and components, critical path analysis for highly dependent activities, business-driven priorities (e.g., legislative mandates and executive directives), limitations in human capital capacity to manage the incremental projects and builds, expected return-on- investment from projects and builds, and risks. Overall, the gap analysis assesses the state of the legacy systems, technology maturity, acquisition opportunities, and fiscal reality of the transition.
5.3.2. Define and Differentiate Legacy, Migration, and New Systems
Legacy, migration, and new systems make up the technical components for the transition to the target environment. Legacy systems and their applications are those in current operation and usually are phased out during the deployment of the target architecture. Migration systems and applications may be in current operation, but certainly will be in operation when the transition begins and for some time into the future. Therefore, they may not be specifically represented in the target architecture. Migration systems also include systems, databases, interfaces, or other components that may be introduced and temporarily used to sustain operations between the current systems (and incremental phase) and the establishment of target architecture components. New systems and applications are those that are being acquired, are under development, or are being deployed. They are expected to be operational as part of the target environment.
The key to prioritizing projects is the sequencing of the termination of systems, the phasing out of functionality, and the timing of systems deployment, technology insertion, and the addition of new functionality into the enterprise. The architecture core team considers dual operation of legacy systems alongside the initial start-up of new systems and account for this potential in the sequencing plan. The uninterrupted flow and management of data, its use by both the legacy and new systems, and its creation and distribution should be outlined in the sequencing plan. The migration should be managed and pursued incrementally so that the impact of unforeseen events
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
40 February 2001
(e.g., technical problems, fiscal delays, etc.) on the efficient operation of the enterprise will be minimized.
Decisions about sequenced investments need to be driven by high-level analyses about respective costs, benefits, and risks, as well as sequential technical and functional dependencies.
A major section of the sequencing plan is the system evolution or migration analysis captured in a set of systems migration tables, diagrams, or charts. Figure 13 illustrates a notional migration chart. This type of chart helps illustrate how systems and applications are expected to evolve between the baseline and target architectures. Generally, a system evolves in one of six ways:
1. Current systems continue in operation (System D)
2. Existing system functionality is absorbed by another system (System A into System B)
3. Legacy system transitions to migration and evolves into a new system (System B into System X)
4. Current system is planned for further evolution (System C into System Y)
5. A new system developed during transition that becomes the permanent final system (System E)
6. A merger of legacy functionality and migration systems (System N into System K and then absorbed into System D).
Today TargetTransition Period
System A
System B
System C
System D
System N
System X
System Y
System D
System B
System E System E
System K
Figure 13. Systems Migration Chart
A sequenced insertion of functionality and a detailed deployment plan for IT systems is developed based upon operational priorities, risk management, and return on investment.
5.3.3. Planning the Migration
The rate of modernization�that is, migration to the target architecture�needs to be planned in convenient, manageable increments to accommodate the organization�s capacity to handle change. Understanding the level of effort is necessary to allocate and manage the work according to a scheduled migration with milestones. This will depend on proposed information systems
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
41 February 2001
development or acquisition, priorities, and the availability of resources, such as budget, people, and time constraints.
The implementation of changed business processes might be expressed as program initiatives with one or more projects. A review of the collection of gaps between the baseline and target architectures determines which enhancements, modifications, and replacements are needed. Dependency analysis determines the alternatives available for sequential and concurrent activities, and helps determine what should be accomplished in which increment or iteration of projects. Projects would then be defined to implement each of the initiatives (or sets thereof). Each project represents a logical division of work that is easier to describe and manage from the overall effort and would be assigned to an individual project manager with clear responsibility for its success.
The next step in the development of the migration path focuses on dependency analysis and consideration for the desired level of effort for each of the projects. The interdependency of systems within the enterprise and the dependencies among projects and initiatives is the primary driving force in determining the sequence for implementing solutions. Estimating the effort and duration for each initiative provides additional information to the dependency analysis that supports critical path analysis. After considering options offered by tradeoffs from critical vs. non-critical changes, prioritizing key enhancements to meet key management priorities (such as legislative mandates or executive directives), and providing for sufficient leeway to reduce schedule risk, a draft sequence plan for the portfolio of projects can be created.
Final refinement of the sequencing plan involves review and refinement to meet the short-term needs and potentially volatile priorities of the business units within the financial constraints of the enterprise. The following are some key issues to consider when refining the strategy:
• What is the potential for commitment of funds for the initial phases of the migration?
• What is the potential for the commitment of funds for the entire transition to the target architecture?
• How soon will the business units see the initial benefits (i.e., operational enhancements or return on investment) from the plan?
• Does the sequencing plan provide incremental improvements to system users to help sustain commitment and support to the program?
• What risks are inherent in the current sequencing plan? How will they be mitigated?
• What alternatives are currently available if funding or resources are delayed?
The modification, enhancement, or development of information may include applications, data integration, and interfaces, as well as systems platform acquisition, staffing, training (or retraining), and systems deployment. Because almost all systems development implies the control and transfer of funds, systems development should be coordinated and integrated with financial management. In addition, interrelationships and interdependencies�whether architectural, organizational, and external�need to be accounted for in the sequencing plan.
5.4. Approve, Publish, and Disseminate the EA Products
Upon verification and validation of the architectural products, the Agency�s management should approve the overall architecture. This step includes approval by the EAESC, the CIO, Chief Architect, and Agency executives up to and including the Agency Head (e.g., Secretary,
A Practical Guide to Federal Enterprise Architecture Define an Architecture Process and Approach
42 February 2001
Commissioner, or Directors). Each Agency incorporates its own approval processes for this cycle.
The Agency executives, managers, and architects should have ready access to the information in the EA. By distributing the information in electronic Read-Only format, executives and managers can use the information directly while the controlled baseline is maintained. Executives and managers should use the information for more than just reference purposes� incorporating it into communications, briefings, and directives. Application architects use the information to analyze artifacts against their own reality and identifying opportunities for improvements. Enterprise architects use the information to apply �what-if� analysis against the baseline. In addition, Read-Only format versions of the EA limit the number of staff able to make changes and modifications to the products, easing the burden of change management on the enterprise as a whole.
The EA documents extensive information about the Agency. Careful consideration must be made to the distribution of that information. Although it is possible that an EA may not have any confidential information, the aggregation of the information may comprise a security risk. In the wrong hands, the compilation of enterprise information in the EA could create a vulnerability to the Agency by providing sufficient information for infiltration and disruption. Some of the information (or combinations thereof) may need to be controlled and accessed on a �need-to- know� basis (e.g., network models, critical performance factors, system interfaces, etc.). The architecture core team considers what classes of EA users will need what information: contractors, management, and Agency staff typically focus on particular areas of the enterprise, and thus may only need particular subsets of the EA. An EA that includes a comprehensive view of the details of the Agency systems and infrastructure could be organized in levels of detail and distributed in a tiered format corresponding to security clearances and the need to know.
Architecting is an ongoing, iterative process requiring regular modification and maintenance. Whenever the EA changes, it is imperative to update the architecture models. A detailed discussion of architecture maintenance is presented in Section 7.
43 January 22, 2002
6. Use the Enterprise Architecture
Using the EA to implement new projects provides a positive impact on the enterprise. If the EA is not successfully used, the entire development effort to this point is for naught. In this section, the emphasis shifts to integrating use of the EA across multiple activities and organizational groups. Success depends on active management, proactive architects, and receptive project personnel. It also depends on integrating the EA process with other enterprise life cycle processes, particularly the CPIC process.
Establishing the EA captures the state of the enterprise and the plan for its future�literally a snapshot of the enterprise and its plans for improvement. For the EA to provide the strategic information asset base as intended, it should become a crucial tool for decision support and communication in the mainstream of daily business operations. Accepting and applying this asset in the Agency�s operational paradigm is a technical and cultural challenge.
The EA is managed as a program that facilitates systematic agency change by continuously aligning technology investments and projects with agency mission needs. The EA is updated continuously to reflect changes in operational and investment priorities that may arise due to legislation, budget constraints, or other business drivers. It is a primary tool for baseline control of complex, interdependent enterprise decisions and communication of those decisions to agency stakeholders. The sequencing plan provides a strong guide for agency decision-makers to use as they consider proposed projects. If a project is not represented in the sequencing plan, it should either be denied funding, since it is not aligned with the agency strategy as embodied in the EA, or it should be granted a waiver if it is a legitimate deviation driven by valid changes in the agency�s environment which have not yet been reflected in the EA. It should be noted that it is crucial that the EA represent the current agency strategies and imperatives as closely as possible, since any lag in the EA may constrain the agency�s ability to effectively execute its mission until a waiver is issued or the EA is adapted. In cases where a waiver is granted, the cause of the waiver should be examined and appropriate changes to the EA considered if the cause represents a valid and ongoing gap in the EA.
6.1. Integrate the EA with CPIC and SLC Processes
Investment management and systems development/acquisition are closely linked with the EA processes.6 The agency should only make investments that move the agency toward the target architecture and these investment decisions should comply with the sequencing plan. The EA, CPIC, and SLC (systems life cycle) processes are integrated to best suit the agency�s particular organization, culture, and internal management practices. Certain basic relationships exist between these functions and they have a common focus: the effective and efficient management of IT investments. The dialogue across CPIC, SLC, and EA processes is continuous, cooperative, and facilitated by agency commitment to an integrated process. Details of this relationship between management processes and the capital planning and investment control process are discussed in the Architecture Alignment and Assessment Guide and the Smart Practices in Capital Planning document. GAO�s Information Technology Investment Management
6 As discussed as the beginning of this guide, these processes are also linked with information security management processes and human capital management processes. Linkages with these latter two processes, however, are not explicitly addressed in this guide.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
44 February 2001
Framework provides a structured approach to IT investment management that is consistent and integrated with the principles of good EA and system life cycle practices.
Each agency designs its own CPIC process for structuring budget formulation and execution to ensure that investments consistently support strategic goals. All IT projects should align with the agency mission and support agency business needs while minimizing risks and maximizing returns throughout the investment�s life cycle. The target architecture and the sequencing plan provide information for the three phases of the CPIC process. In the Select Phase, the agency determines if the proposed investment meets business decision criteria. To assess the business alignment of the proposed investment, decision makers use, for example, the business case, acquisition plan, and the project plan to determine whether the proposed investment aligns with the sequencing plan and target architecture. In the Control Phase, decision makers monitor business and technical compliance as demonstrated in, for example, the updated business case, system architecture, systems design, and test program. In addition, the investment should be monitored to ensure continuing alignment with the agency�s strategic and business goals, which may shift over time. In the Evaluate Phase, the decision makers perform a final assessment to determine technical and strategic compliance with the EA. The results, including findings of noncompliance, should influence strategic planning for new business and IT projects, which could then lead to changes in the EA.
Figures 14 and 15 illustrate one example of a CPIC and architecture management process developed by the U.S. Customs Service (Customs)�the Investment Management Process (IMP). There is a detailed discussion of their IMP in the U.S. Customs Service Enterprise Architecture Blueprint (August 1999). This framework enables compliance with the EA and the necessary governance for application to the Enterprise Life Cycle Management activities.
Projects are managed and executed through the agency�s systems development/acquisition life cycle. Each agency may have its own unique approach to the systems development/acquisition cycle, but certain fundamental elements such as requirements, systems and software architecture, design, and test are common.
Architecture Roles
Architecture Process
Respond to Business Change
Investment Process /Architecture Project Assessment Framework
1
Assess Business Alignment
2
Assess Business Case
Proposal Assess
Technology Compliance
Target IT App.Port /
Infra. Initiatives
Aligned per IT Strategy
Alignment Scorecard
(SELECT) Develop Business
Case
Compliance Assessment
5
(SELECT) Project
Initialization
Assess Waiver/ Exception Request
Enterprise Design
Patterns
Acceptable Alignment
Acceptable
Compliance
Unacceptable Conformance
Unacceptable Alignment
Unacceptable Compliance
Proposed Concept
Report
TRM Standards
4 Evaluate
Architecture Compliance
IRB Report
Audit Reports
(EVALUATE) Evaluation
Disapproved
3
(CONTROL) � Define � Build � Implement � Operate
Figure 14. IMP/Architecture Project Assessment Framework
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
45 February 2001
� Respond to user request (EAPMO)
� Respond to market direction (EAPMO)
� Respond to vendor direction (Domain Owner)
� Annual strategic planning event (EAPMO)
� Track emerging technologies (EAPMO/DO/SME)
Architecture Roles
Architecture Process
Technology Architecture Management
5
Issue Waiver / Exception
6
TRM Waiver Containment
BlockApproved One-Time Exception
Perform Technology
Insertion and Renewal
Unacceptable Conformance
Triggers 7
Conduct Standards Review
TRM Standards
& Strategies
Standards Review Required
TRM Structure
Disapproved
Enterprise Filter
Initiate waiver/exception request per TRC
Report
Assess Technology Compliance
TRM Standards
Events
Figure 15. Architecture Management
In order for an agency to successfully deploy an integrated process as described in this document it needs to train its personnel, define and implement compliance criteria, and conduct integrated reviews. Each of these critical aspects is discussed in the subsections that follow.
6.1.1. Train Personnel
It is the responsibility of agency executive management to institutionalize the control structures for the EA process as well as for the agency CPIC and SLC processes. For each decision-making body, all members should be trained, as appropriate, in the EA, the EA process, and the relationship of the EA to the CPIC and SLC. Specific training, at various levels of detail, should be tailored to the architecture role of the personnel.
Anyone who might bring forward a proposal to the Capital Investment Council (CIC)�such as domain managers and project managers�should understand the requirement for EA assessments. To adequately evaluate an investment proposal, the CIC needs specific information. Individuals creating the investment proposals should be trained, as appropriate, in the criteria and submission requirements. Appropriate training will prepare the staff to assess the compliance and correct any deficiencies that exist prior to submission.
6.1.2. Establish Enforcement Processes and Procedures
The processes and procedures that enforce the application of EA guidance and those that ensure its consistency with the �reality� of the enterprise are critical components in EA institutionalization. The EA processes and procedures implement the Executive EA Policy (see Section 3.1.2). The Enforcement Policy defines the standards and process for determining the compliance of systems or projects with the EA and procedures for resolving the issues of non- compliance. A project�s technical and schedule compliance is typically assessed in terms of how it conforms to the content, intent, and direction set by the EA.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
46 February 2001
The processes and procedures should answer the following questions:
• How and when will projects submit project plans to be reviewed for EA compliance?
• Who will be responsible for compliance assessment and/or justification of waivers?
• How will compliance and non-compliance be documented and reported?
• How will outstanding issues of non-compliance be resolved and/or waivers be processed and approved?
• Who will be responsible for processing, authorizing, and reassessing waivers?
• What will be the content and format of waiver submissions?
• If a waiver is granted, how will projects achieve compliance in the future?
• What are the ramifications if a non-compliant project is not granted a waiver (e.g., funding and/or deployment restrictions)?
The processes and procedures should, of necessity, allow exceptions. In many cases, existing systems in the operations and maintenance phase should be granted exceptions or waivers from the technical standards and constraints of the EA. Alignment of some legacy systems with new standards could be unreasonably costly and introduce additional risk to the business users. Also, it is likely that certain initiatives and innovations, such as investigative efforts and proofs-of- concept, will not comply with the EA.7
6.1.2.1. Define Compliance Criteria and Consequences
Requirements for EA assessments include criteria for compliance, waivers, and corresponding submission requirements. In the event of a non-compliant proposal a request for waiver should be prepared and formally submitted to the Technology Review Committee (TRC). The waiver provides analytical and defendable justification of design changes, budget deviations, and impacts. The waiver request includes identification of the operational, economic, and productivity impacts of any waiver. The corresponding impacts of the waiver not being approved should also be provided to the TRC. The TRC recommends to the CIC approval or denial of requests for waivers. The CIC approves or denies requests for waivers based on this information.
The TRC approves waivers according to the agency�s enforcement process. Each waiver that is approved presents an opportunity for feedback on the EA and the EA process. For example, the need for a waiver may indicate that the target architecture, the transition analysis, and/or the sequencing plan are too constraining or too rigidly defined. In addition, rapidly evolving requirements may necessitate revisiting existing plans outside the normal EA process, since waivers may indicate that the defined target environment does not reflect agency needs. Also the need for reworking proposals may indicate problems in training for compliance.
The CPIC process should respect the integrity of the sequencing plan while considering the strategic and tactical value of all proposals that pass through CPIC checkpoints. Project critical success factors continue to be met. This double check on project proposals ensures that all funded projects meet the conditions necessary for success. These conditions include, but are not limited to:
• Consistency with the EA
7 After a non-compliant investigative or innovative effort is commenced and appropriately controlled during its execution, it may become a candidate project for consideration by the EAESC and TRC. Such a project might well offer proposed changes to the EA.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
47 February 2001
• Satisfaction of project baseline cost, schedule, capability, and business value commitments
• Compliance with agency-published investment management policies and guidance
• Explicit support by executive management.
6.1.2.2. Set Up Integrated Reviews
The CPIC Select, Control, and Evaluate Phases require reviews of proposals and project performance whenever significant change is contemplated or at logical milestones or key decision points (KDPs) in the systems life cycle. KDPs are points where management should take action regarding project scope, approach, funding, etc. EA enforcement should be applied at KDPs, when possible, since it is at those points that senior management will convene to consider investment decisions. Reviews may also occur periodically, for example as part of an integrated capital planning/budget cycle. Since the EA is a major management tool for monitoring and guiding change within the agency, the important outcome is to schedule reviews to ensure that planned investments stay on schedule, within budget, and achieve defined goals. In addition, these reviews provide the opportunity for the EA team to communicate changes in the target architecture and sequencing plan to the agency as a whole, as well as to the specific projects that will be affected. Deviations from compliance may be addressed by implementing changes to the project or by a waiver request.
6.2. Execute the Integrated Process
Progress toward the target architecture is accomplished through programs and projects. New and follow-on projects are (1) initiated and selected, (2) executed and controlled, and (3) completed and evaluated. The following sections show the information flow for each of these three CPIC phases with emphasis on how the EA supports the whole process.
6.2.1. Initiate New and Follow-on Projects
Sponsors propose projects under different circumstances:
• New projects are identified and sponsored based on the domain owner�s interpretation of the sequencing plan. A project to fill the gap may result in business process reengineering, IT development, and/or change to the infrastructure.
• Planned follow-on projects are anticipated, but still need review by the CPIC and an assessment of the completion of dependencies on previous projects.
• A need for an architectural improvement is identified, e.g., to incorporate a new standard or technology identified by the target architecture, gap and transition analysis, and the sequencing plan.
• A sponsor may initiate a project based on a business or technical need that is not identified in the sequencing plan. In this case, a waiver needs to be approved and the EA team should respond by considering modifications to the EA. This is only possible based upon a formal waiver and approval process including the EAESC, CIC, and other executive-level panels.
Figure 16 depicts the information flow when a project is initiated. It serves as a guide through the cycle of proposal preparation, aligning the proposed project with the EA, and making the decision to fund the effort. The information flow ensures that requirements are being addressed and that a proposed implementation meets expectations and requirements.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
48 February 2001
CPIC Process
Investment Council
(CIC) Propose
Programs and
Projects Business Requirements IT Needs
Technology Updates
Program/Project Proposal with EA impact assessment & proposed EA changes
EA Products Program/Project Proposal EA Assessment Approved Waivers Recommendations
Decision to Launch, Conditions
EA Updates
EAESC TRC Architects
Program Managers Domain Owners Architects
EA Repository/Tool
Manage EA Assess/Align
Sel ect
Figure 16. Define New and Follow-on Programs/Projects
6.2.1.1. Prepare Proposal
The sponsor of a project prepares a proposal in accordance with predefined agency requirements. The proposal presents the business case for the project and defines a business solution using information from the EA as well as other sources. Business requirements, IT needs, and technology updates all feed the definition of the effort being planned. Domain owners and program or project leaders prepare the proposal by:
• Mapping objectives to requirements and relationships between high-level requirements to the business objectives
• Documenting a high-level business case
• Providing a cost study
• Defining a business case solution and determining the level of impact introduced into the IT environment
• Ensuring reasonableness of risk, time, and cost
• Ensuring that technical and business implications to the organization are addressed.
The domain owners and program or project leaders should comply with the architecture project reporting requirements and will provide answers to compliance criteria in the proposal documentation. For selection, they will show that the investment supports the agency mission, that the investment meets the business criteria, and that it is consistent with the target architecture and sequencing plan. If an investment deviates from the sequencing plan, the reasoning for the deviation should be documented.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
49 February 2001
The Chief Architect and the architecture team can advise program/project leaders on business case/solution development. They contribute to the development of investment proposals and work to facilitate progress through the CPIC. They have a specific interest in ensuring that projects identified in the sequencing plan are funded, and may actually introduce such projects. For other projects, they will support project leaders in initiating and developing proposals.
6.2.1.2. Align the Project to the EA
The Chief Architect and the architecture group perform proposal assessments. Table 5 describes the types of assessments that occur as projects are subjected to periodic, iterative EA reviews. In the initial phase of defining and selecting a project, the emphasis is on the business alignment, business case solution, sequencing plan, and to a limited degree, technical compliance. As the system concept matures, business and technical compliance are equally addressed. Details of this alignment with business and the CPIC processes are discussed in the Architecture Alignment and Assessment Guide (see Appendix F for a complete reference listing).
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
50 February 2001
Table 5. EA Review Goals
Type of EA Reviews Review Purpose/Goal
Business alignment
Determine if the proposed project aligns with Agency strategic plans, goals, and objectives. The goal of the review is to ensure that the expected business outcomes of the project are aligned to concept and high-level project requirements.
Business case solution
Examine the proposed solution, at a high level, to determine the impact introduced into the organization�s IT environment. The goal of the review is to ensure that the proposed solution supports both the business and technical architecture.
Sequencing plan Determine whether the proposed investment is consistent with the sequence and priorities in the plan. The goal of the review is to ensure progress toward the target architecture.
Technical compliance Determine whether the architecture of the proposed solution complies with the enterprise standards, the various architecture levels, and methodologies. The goal of this review is to ensure technical compliance of IT projects.
Upon assessing the project�s alignment to the EA, the architects may make recommendations and provide support to bring non-compliant proposals into compliance. In cases where a waiver had been requested, the architects may respond with an independent assessment of operational, economic, and productivity impacts of the waiver.
6.2.1.3. Make Investment Decision (CPIC Select Phase)
The CIC is responsible for the evaluation of new proposals and for oversight of ongoing investments. Among other criteria, CIC decisions are based on determinations that the proposed projects submitted by the business managers are aligned with agency strategic plans, goals, and objectives. The business proposal and the results of the architecture assessments, including waivers, are reviewed by the investment decision makers. The same conditions and consequences pertain to follow-on projects and incremental funding.
In certain circumstances, it may be necessary to approve a proposal that does not conform to the target architecture and/or the sequencing plan. The conditions under which a waiver is granted and the operational, economic, and productivity impacts of the waiver are considered in the investment decision. Under most circumstances, any proposal that is not compliant or otherwise does not qualify should be denied a waiver. Non-compliant initiatives may be approved for research, concept development, prototyping, and other purposes. These efforts may challenge assumptions currently accepted in the EA and may lead to breakthroughs that could significantly improve the EA. Nevertheless, the conditions under which a project may proceed should be unambiguous and clearly stated in the EA policy and should be documented in the CIC�s investment decision. Once the project has been acted on, there may be recommended changes to the EA or the requirement for additional detail to enhance the EA. The funding decision will have an impact on the sequencing plan and potentially the target architecture and transition analysis.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
51 February 2001
6.2.2. Execute the Projects
Once funding is received, the project can be initiated. Figure 17 depicts the information flow as the project cycles through the integrated EA, SLC, and CPIC processes. A project will pass through this cycle multiple times. There are continuous interactions between the project implementers and the architecture, with more formal reviews at prescribed milestones.
Manage Programs
and Projects
CPIC Process
Co ntr ol
Manage EA Assess/Align
Business & IT Priorities Dependencies Architecture Design & Constraints
Proposed EA Updates Systems Architecture
Requirements and Design
Program/Project Progress EA Products Program/Project Progress
Systems Architecture Requirements and Design Architecture Assessment Recommendations
Funding decision to continue, conditions, waivers, redirection
EA Updates
Program Managers Domain Owners Architects
EA Repository/Tool
EAESC TRC Architects
Investment Council
(CIC)
Figure 17. Execute Programs/Projects
6.2.2.1. Manage and Perform Project Development
Program/Project Leaders use the EA as guidance and constraints on systems architecture and systems design. The project management goal is to ensure that the proposed solution supports the EA. The project�s requirements, systems and/or software architecture, design, and test program are developed using concepts, constraints, and recommendations from the EA. Systems migration strategies may be found in the sequencing plan.
The Chief Architect and the architecture group contribute to projects as consulting architects. Their role in the requirements and design phases is to provide guidance to the business unit and its project teams on technical architecture-related issues and emerging trends in the industry. They make recommendations for relevant parts of the EA (e.g., business, information, data, application, infrastructure, security, and standards).
Initial requirements, systems and/or software architecture, and design rely heavily on existing artifacts from the EA. As the project progresses, products are produced that enhance and expand the level of detail in the EA. These products, generated according to the SLC requirements, are contributed and incorporated into the EA repository.
6.2.2.2. Evolve EA with Program/Project
It is the responsibility of the Chief Architect and the architecture core team, with direction from the EAESC, to maintain EA alignment with the organization as it evolves. Throughout a project�s development/acquisition phase, the requirement is to maintain the alignment of the
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
52 February 2001
evolving solution with the target architecture and sequencing plan. The architecture team reviews the business and technical solution throughout the life cycle and assures compliance with the EA. In incremental reviews, assessments are performed to determine whether the project�s products and documentation (the functional analysis, general design, and detailed design) comply with the EA products that have been approved through previous review processes. The projects provide additional information as progress is realized. The goal is to maintain alignment of the project with the EA throughout development to avoid construction of systems that do not meet the organization�s needs.
In addition to systems architecture and design specifics that flesh out the EA at the lower levels of detail, the projects provide new ideas to the EA for changes to the target architecture and transition increments. The EA should be reviewed regularly and synchronized with the enterprise life cycle and investment decisions. The Chief Architect and the architecture team incorporate this feedback into the EA maintenance process. See Chapter 7 for more detailed discussion on EA maintenance.
6.2.2.3. Assess Progress (CPIC Control Phase)
The CPIC Control Phase ensures that the investment is being managed within the planned cost, schedule, and design and that the investment will operate effectively within the technical infrastructure. Systems development and acquisition is inherently risky. Managers and architects provide information according to the reporting requirements for architecture assessments, and this information is used as the basis for decisions about continued funding, imposition of development constraints, and possible redirection of technical efforts. This control is imposed to manage and mitigate risk. Investment decisions rely on analysis of progress reports, compliance assessments, and deviations and waivers to arrive at implications on cost, schedule, and performance.
6.2.3. Complete the Project
Most projects are interdependent on other development projects and legacy systems. Many are followed by additional increments of capability or by additional operations and maintenance (O&M) efforts. Almost all are integrated with other systems when they become operational. When the project is complete, there is a final assessment of impacts on the agency, the EA, enterprise operations, future systems, and consequently, future investment and funding decisions. Figure 18 depicts the information flow upon completion of a program or project.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
53 February 2001
Complete Programs
and Projects
CPIC Process
Evaluate
Business & IT Priorities Dependencies Architecture Design & Constraints
Proposed EA Updates System Architecture Requirements Design Test Results
Sequencing Plan EA Products
Systems Architecture Requirements & Design
Architecture Assessment Approved Waivers Design & Recommendations Process Improvements
Evaluation
EA Updates
Program Managers Domain Owners Architects
Manage EA Assess/Align
EAESC TRC Architects
EA Repository/Tool
Investment Council
(CIC)
Figure 18. Evaluate Programs/Projects
6.2.3.1. Deliver Product
At the end of a program or project, system and updated business processes have been integrated into the environment. An O&M support is defined, training is provided, and a complete set of documentation is communicated to the operations and maintenance staff. Material is provided for the EA repository with the delivered product, to the level of detail appropriate to depict the new baseline architecture. A support and deployment strategy is activated for parallel or turnkey operations. There is a transition from the development/acquisition environment and management to O&M environment and management. At this time opportunities for the reuse of work products from this project to other projects should be considered.
6.2.3.2. Assess Architecture
The EAESC performs an ongoing assessment of the EA. There is much to be learned by evaluating the extent to which a project has complied with the sequencing plan, based upon the target architecture. The experience and lessons learned contribute to the ongoing robustness of the EA processes.
The final assessment of the project with respect to the enterprise architecture involves review of the original business case, the implementation of the business and technical solutions, the sequencing plan, and final disposition of waivers. The result of the final assessment is the updating of the baseline architecture with changes implemented in business processes, IT products, deployment, technology, and operations. The sequencing plan, target architecture, and gap/transition analyses are also updated to show completion of the program/project. Waivers will either be permanent or may be accompanied by plans for future work. Other results can influence future priorities and dependencies in the sequencing plan. These results provide lessons learned for process improvement and form the basis of business cases for other new programs or projects.
A Practical Guide to Federal Enterprise Architecture Use the Enterprise Architecture
54 February 2001
6.2.3.3. Evaluate Results
The EAESC and CIC assess program/project results for impact to the EA and the organization�s business processes. The CPIC Evaluate Phase shows that the investment meets the planned performance goals and identifies any reasons for updating the EA. After considering the results of impact to the EA, the conditions that may have necessitated a waiver may prove sufficiently pervasive to justify altering the EA to accommodate future investment proposals with similar requirements.
6.3. Other Uses of the EA
The EA provides guidance and source information for requirements analysts, designers, engineers, and test planners to reference and build upon material executing their responsibilities. The following are examples of uses of the EA outside the normal project cycle:
• Even if an agency is not involved in a major IT upgrade, the EA is a resource for managing inventory, routine maintenance, and queries. Analysis of the baseline architecture can identify opportunities for consolidating network services, floating or site software licenses, and economies of scale for equipment and services.
• The agency can use the EA as a training aid, drawing on its graphics and descriptive material for instruction in the business of the agency or in the technology that is in use or planned.
• Investigative initiatives and proofs-of-concepts should be performed using the EA as a reference. The criteria for EA compliance should be considered, but not mandated, in such efforts. Non-enforcement allows pursuit of innovations that could change the EA, but alignment and impacts of architecture deviations should be included with the results of the experiments.
• Agencies may fund small, low risk projects outside of the CPIC. Program/project managers should still rely on the EA for guidance for the business solution, architectures, requirements, and design of their effort. Compliance with the EA will facilitate integration into the enterprise, and the baseline architecture should be kept current with their products.
• O&M projects rely on the baseline architecture for context. The O&M priorities and decisions may be influenced by the sequencing plan and target architectures. For example, a planner may conclude that soon-to-be-retired IT systems are more economical with minimal O&M support.
55 February 2001
7. Maintain the Enterprise Architecture
The EA is, by definition, a set of models that collectively describe the enterprise and its future. Its value to the business operations is more than just IT investment decision management. The EA is the primary tool to reduce the response time for impact assessment, tradeoff analysis, strategic plan redirection, and tactical reaction. Consequently, the EA must remain current and reflect the reality of the organization�s enterprise. In turn, the EA needs regular upkeep and maintenance�a process as important as its original development.
Maintaining the EA should be accomplished within the enforcement structure and configuration control mechanisms of the organization. EA maintenance is the responsibility of the CIO, Chief Architect, and the EAPMO. Using a system of oversight processes and independent verification, the architecture core team periodically assesses and aligns the EA to the ever-changing business practices, funding profiles, and technology insertion. The EA should remain aligned to the organization�s modernization projects and vice versa. The management controls to accomplish EA maintenance are the same ones established to initiate the program and to develop the EA.
7.1. Maintain the Enterprise Architecture as the Enterprise Evolves
If the EA is not kept current, it will quickly become �shelfware��yet another well- intentioned plan for improving the enterprise. Perhaps even more damaging, if the EA fails to embody the agency�s most current strategy it may limit the organization�s ability to meet its goals and achieve its mission. The EA necessitates a specific organizational and process structure that will ensure the currency of EA content over time. The EA should reflect the impact of ongoing changes in business function and technology on the enterprise, and in turn, support capital planning and investment management in keeping up with those changes. Consequently, each component of the EA�baseline architecture, target architecture, sequencing plan, and all the products that constitute them�need to be maintained and kept accurate and current.
7.1.1. Reassess the Enterprise Architecture Periodically
Periodically, it is necessary to revisit the vision that carried the organization to this point and to re-energize that vision within the Agency. Continually, typically in conjunction with the CPIC, the EA should be reviewed to ensure that:
• The current or baseline architecture accurately reflects the current status of the IT infrastructure
• The target architecture accurately reflects the business vision of the enterprise and appropriate technology advances that have occurred since the last release
• The sequencing plan reflects the prevailing priorities of the enterprise and resources that will realistically be available.
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
56 February 2001
The assessment should generate an update to the EA and corresponding changes in dependent projects. The baseline should continue to reflect actions taken to implement the sequencing plan and actions otherwise taken to upgrade the legacy environment as the organization modernizes. The EA assessment and update should be managed and scheduled to in turn update the Agency strategic plan and process for selecting system investments.
7.1.2. Manage Products to Reflect Reality
An Agency is a business entity that remains responsive to business drivers (including new legislation and executive directives), emerging technologies, and opportunities for improvement. The EA reflects the evolution of the Agency, and should continuously reflect the current state (baseline architecture), the desired state (target architecture), and the long- and short-term strategies for managing the change (the sequencing plan). Figure 19 illustrates the type of continuous changes that should be illustrated by the EA. At no time will a specific target architecture ever be achieved�with each iterative update of the EA, all three components shown in the figure and the timeline are recast. The target architecture is a vision of the future that evolves in advance of it being achieved.
Baseline Transition Target
Im pl
em en
ta ti
on S
ta tu
s
Sequencing Plan
Target Architecture
Baseline Architecture
Figure 19. Enterprise Architecture Transition
7.1.2.1. Ensure Business Direction and Processes Reflect Operations
A critical responsibility for the EA program is to monitor the changes in the business operations that affect the organization, the business processes, and the strategic direction of the business. Changes in business processes that were initiated by process improvement, organizational change, or mandate, may be reflected in the business artifacts of the baseline architecture. Business unit management and their SMEs should report changes in their organizations and initiatives to the Chief Architect and architecture core team. Correspondingly, the Chief Architect ensures that the architecture core team is gaining sufficient insight into the evolution of the operations. Plans and expectations may change as priorities shift over time�these may need to be reflected in modifications to the target architecture. Priority shifts and the realities of
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
57 February 2001
budget constraints may need to be reflected in the sequencing plan. Thus, EA maintenance will be both reactive and proactive.
7.1.2.2. Ensure Current Architecture Reflects System Evolution
Despite the best operational management and systems maintenance planning, the current architecture and infrastructure may need unanticipated changes. As each new system is deployed and each legacy system reaches a maintenance milestone (e.g., renewal of maintenance contracts), the baseline for the current architecture changes. In addition, system patches should be introduced frequently or system design changes implemented to respond to high-priority requests. These changes should be reflected in the current architecture artifacts.
7.1.2.3. Evaluate Legacy System Maintenance Requirements Against the Sequencing Plan
As the current architecture evolves to reflect the reality of the legacy systems, new information may emerge that will change the maintenance plans and subsequent organizational and systems transition. For example, system vendors may unexpectedly cease supporting critical components of the Agency�s infrastructure. Alternative actions should be weighed and decisions made regarding replacing the components, paying for additional specialized contractor support, or changing the strategy for phasing in other components in the target architecture. The total cost of ownership of the system versus alternative systems, as well as outsourcing, may need to be considered. All of these considerations, alternatives, and decisions may dramatically alter the sequencing plan.
7.1.2.4. Maintain the Sequencing Plan as an Integrated Program Plan
The development of the sequencing plan is linked to the acquisition and enterprise engineering processes. The architect works in partnership with managers who understand the evolving business objectives, as well as the individual program management offices that oversee the acquisition and development of new IT systems. The sequencing plan should be maintained, reviewed and validated, and approved to continually reflect the organization�s mission and vision just as any product in the architecture package and plan. The sequencing plan delineates the IT management scheme for systems insertion in support of the organization�s long-term business strategies.
7.2. Continue to Consider Proposals for EA Modifications
While the enforcement process helps to ensure that the EA guidance is followed, it is unreasonable to assume that new business priorities and technologies, funding issues, or project challenges will not require modification to the plans, baselines, and products incorporated in the EA. Emerging technologies continue to necessitate changes to the enterprise. Many of the considerations for changes to the EA are the same considerations that needed to be addressed during its development. Also, the architectural principles need to be continuously addressed.
Proposals for modifying the architecture should address the following questions among others:
• How does the proposed modification support the organization in exploiting IT to increase the effectiveness of its organizational components?
• How does it impact information sharing and interoperability among organizational components?
• What are the security implications? For example, will the modifications need certification of enhanced systems?
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
58 February 2001
• Does the proposed modification use proven technologies and conforming COTS products to satisfy requirements and deliver IT services? Are these technologies and related standards in the industry mainstream, thereby reducing the risk of premature obsolescence?
• Does the acceptance of this proposal position other standards or products for obsolescence? If so, identify them.
• What is the impact on the organization and sub-organizations if the proposal is not accepted? What is the result of the cost-benefit analysis?
• What external organizations or systems will be affected? What action will they have to take?
• What is the estimated overall programmatic cost of the proposed changes including changes to the EA and/or redirection of dependent projects?
• What alternatives have been considered and why were they not recommended?
• What testing, and by whom, should be completed for implementations that will result from acceptance of the proposal?
• What is the recommendation of the enterprise change control board?
Proposals requesting modifications to the EA need to explicitly address these issues. The proposal should be presented to and reviewed by the TRC (for review by architectural team and SMEs) and passed to the EAESC with a recommendation. In cases where the EAESC cannot reach a consensus, a working group may be tasked to investigate and propose recommended actions.
59 February 2001
8. Continuously Control and Oversee the Enterprise Architecture Program
The purpose of EA control and oversight is to ensure that the EA development, implementation, and maintenance practices defined in this practical guide and the related EA guidance referenced in this guide (e.g., EA frameworks) are being followed, and to remedy any situations or circumstances where they are not and action is warranted. Control and oversight is a continuous, ongoing function performed throughout the EA life cycle process.
Effective control and oversight is a key to ensuring EA program success. Through it, information is gathered for accountable decision makers to permit awareness of whether effective EA development, implementation, and maintenance activities are being performed and EA program goals are being met on schedule and within budgets. To do so, the EAESC, the CIO, and the Chief Architect should be vigilant in measuring and validating that the EA process and product standards defined and referenced in this guide are being performed. To do less, diminishes the probability of program success.
8.1. Ensure Necessary EA Program Management Controls Are In Place and Functioning
In Section 3 of this guide, accountability for the EA program was assigned to the EAESC, the CIO, and the Chief Architect. Also, throughout this guide, EA process and product standards or controls that should be used to produce a complete, well-defined, and useful EA have either been defined or referenced. (For example, the guide specified the need for a program management plan to detail what will be done, when, and at what cost, as well as the need to establish management support functions, such as configuration management, risk management, quality assurance, change control, etc. Also, the guide references EA frameworks and tools that help define the content of the EA.)
Knowing the extent to which these controls are being implemented on a continuous basis is crucial to keeping the program on track. To do this, EAESC, the CIO, and the Chief Architect will respectively seek reports (oral and written, routine and ad hoc, formal and informal) and conduct first hand reviews to obtain the appropriate level of visibility into what is occurring on the program vis-à-vis what is expected. It is the responsibility of these accountable entities to define what information they need, when and how often they need it, what the form and content of the information should be, whether it should independently validated or not, etc. Through such information, the EAESC, the CIO, and the Chief Architect can position themselves to know whether established program management controls are in place and functioning.
8.2. Identify Where EA Program Expectations Are Not Being Met
Through their respective reports and review activities, the EAESC, the CIO, and the Chief Architect will be able to identify what, if any, EA program expectations are not being met. For example, if risk management has been effectively implemented, program risk lists should be regularly generated that assign a risk level based on impact and probability, define risk mitigation strategies, report on progress in implementing these strategies, and whether the progress being made is successfully addressing the risk item. Also, periodic configuration audits should be conducted to ensure that EA configuration items are being defined, controlled, and reported. The EAESC, CIO, and Chief Architect can also rely on independent reviews by the quality assurance function or a verification and validation agent to advise them of deviations from expectations.
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
60 February 2001
These deviations may be program management plan-related, such as omission of work tasks, delays in the completion of work tasks, or additional costs to complete work tasks; or they may be management function-related, such as not following change control procedures, not adhering to the selected EA framework, or not engaging SMEs and domain owners within business and technical areas.
8.3. Take Appropriate Actions to Address Deviations
Management should take quick and decisive actions to correct problems in light of established priorities. Examples of actions include infusion of additional resources (people, tools, or money), establishment of contingency plans, and redefinition of EA purpose and scope, introduction of missing or strengthening of existing control mechanisms, and increased oversight.
Any changes to the plans, projects, and/or architecture content to address deviations should be captured in an appropriate documentation trail, and should be justified on the basis of costs, benefits, and risks. Changes should be processed through established change control processes and board authority. The change documentation should characterize the problem, solution, and alternatives chosen and rejected in light of established priorities.
8.4. Ensure Continuous Improvement
Figure 20 is adapted from a traditional representation of the key success factors of Total Quality Management (TQM). This figure represents the same key success factors for enterprise architecting:
• The EA process should be a key support element of the operations of the Agency, and should assist the operations function in performance of its customer-focused mission.
• Successful enterprise architecting is not simply a function of the IT organization, but needs the total enterprise participation.
• Effective enterprise architecting needs �societal networking,� that is, internal and external communication and sharing of lessons learned.
The optimum EA process is not a single, one-time event, but is continuous and thus offers the opportunity for continuous improvement. This necessitates ongoing control with monitoring, reassessment, and refinement. As the discipline of enterprise architecting enters the mainstream of Agency operations, lessons can be learned from processes that worked and those that did not work, and from external organizations.
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
61 February 2001
Enterprise Architecting
Operations & Customer
Focus
Continuous Improvement
Total Participation
Societal Networking
Figure 20. Key Success Factors
Total participation makes continuous improvement everyone�s responsibility. The EA�s central role in enterprise evolution provides an excellent opportunity to solicit feedback. Lessons learned should be collected from the operational business owners, EA teams, project development teams, and investment management teams. Once the baseline EA has been developed, the architecture team should take stock of the lessons learned and communicate them to their colleagues and participating senior management in order to utilize them in improving the process or the EA itself. In addition, feedback and lessons learned should be sought from other Agencies, professional organizations, commercial corporations, and consultants.
A Practical Guide to Federal Enterprise Architecture Maintain the Enterprise Architecture
62 February 2001
63 February 2001
9. Summary
This Federal Guide to Enterprise Architecture development, maintenance, and use offers a practical �how-to� manual that will assist any Federal Agency in initiating, developing, and maintaining an EA in conjunction with other management processes. Through an illustrative set of �how-to� guidelines and directions, the EA process appears in the context of the Enterprise Life Cycle Management process, which consists of such integrated processes as strategic planning, system development/acquisition, Capital Planning and Investment Control, human capital management, and information security management. While intended primarily for Federal Agency architects, the guide is structured to meet the needs of all Agency staff, from the Agency Head to the CIO and line organization personnel.
The EA is, by definition, a model of the Agency�s enterprise and its future direction. Its value to the business operations should be more than simply IT investment decision management. The dynamic changes in technology and business practices impose greater pressure on an Agency to respond more rapidly to these stimuli than ever before. The EA is the main tool to reduce the response time for impact assessment, tradeoff analysis, strategic plan redirection, and tactical reaction.
Although EAs are required by legislative and regulatory direction, they should be developed and used for other reasons, too. Along with their importance in the capital planning and investment management arena, EAs provide a snapshot in time of the Agency�s business and technology assets. They are the blueprint to build upon�the roadmap to systems and business migration. They help mitigate risk factors in enterprise modernization, identify opportunities for innovative technology insertion, and aid executives and managers in key decision making at all levels of the organization. And these are but a few of the benefits of maintaining a thorough EA.
The EA process is a long-term, continuous effort. Once developed, the EA is a �living� entity with many parts, whether in the form of a document, database or repository, or web page. To remain current and of optimal value, this �living architecture� needs continual care and maintenance. This, in turn, demands an organizational commitment from top to bottom, since Agency resources in time, money, and people should be dedicated to the architecture�s maintenance for the long term.
As an Agency begins its EA efforts, its architecture proponents should secure corporate commitment and buy-in from senior executives and all levels of the organization. Without engaging the entire Agency from the top down, the architecture effort will face an uphill struggle during much of its existence. Thus, the initial stages of the architecture effort will need extensive work�obtaining commitment and backing, grounding the EA in an approved framework, and establishing a functioning architecture structure within the Agency organization.
As one of the first steps, the Agency�s Chief Architect should ground the architecture effort in an established framework, if at all possible, as discussed in Section 4 of this guide. The leading frameworks offer suitable examples, like the FEAF, TEAF, and DoD C4ISR Architecture Framework discussed in this guide, for frameworks and methodologies. As noted, a number of agencies use variations on these frameworks. If these existing frameworks do not meet your Agency�s requirements, develop your own framework; however, consider well the resources and time needed to do so.
A Practical Guide to Federal Enterprise Architecture Summary
64 February 2001
It must be emphasized again that you should tailor the contents of this guide to your own organization�s needs: �one-size does not fit all� is the rule for EA development and maintenance. The guidance of this document can be used by all Federal Agencies regardless of size and resources, but this guidance should be tailored appropriately. This guide is not intended as the �one and only way� all organizations should accomplish EA development, but rather as a synopsis of the �best practices� currently employed in several Federal Agencies and private corporations. For example, in smaller organizations, multiple roles and responsibilities may have to be assumed by one individual, some of the committees and groups will have smaller memberships, and in general, participation will be on a more modest scale. The EA itself, the architecture products, and the associated data repository should be developed as appropriate for that individual organization. Not all Agencies will need the same level of detail, nor the same graphical representations. However, all Agencies will need to ensure that they follow a top-down approach to defining their respective architectures, and that at a minimum the business views of their architectures provide an enterprise-wide understanding of operations.
Lastly, do not suffer alone! Take advantage of the architecture community�s available resources. A vast array of resources is at your disposal. This guide and several of the other references discussed in the document can be found on the Federal CIO Council�s web site at http://www.cio.gov. Many architecture frameworks are documented in an extensive body of literature and web sites. Standing working groups meet on a regular basis, and there are numerous annual conferences and seminars on the topic. See Appendix F for a reference list of related documents and web sites.
65 February 2001
Appendix A: EA Roles and Responsibilities
The following matrix summarizes the functional roles and responsibilities needed to support EA development, use, and maintenance.
Role Members
(If composite) Responsibilities
Agency Head N/A Establishes EA as an Agency-wide priority; charters an EA Executive Steering Committee (EAESC); issues policy governing the development, implementation, and maintenance of the EA.
Capital Investment Council (CIC)
• Agency/Department Heads and their Deputies
• Division/Business Unit Heads
• Senior Budget Official • Senior Procurement
Official • Legal Counsel • CIO • CFO
Reviews the final proposed major information technology investments and makes the final funding decision, selects projects, monitors progress, and evaluates results for investment decision making.
Chief Architect N/A Selects the EA project team; works with CIO to develop EA Primer and architecture policy. Oversees EA product development, use, and refinement. Serves as owner of EA repository and is responsible for architecture sequencing plan. Reports directly to the CIO.
Chief Information Officer (CIO)
N/A Engages and provides strategic direction to EA Executive Steering Committee (EAESC); enhances the Agency Head�s understanding and appreciation for EA; appoints a Chief Architect; markets the benefits of an Agency-wide EA to other Agency executives and stakeholders via collaborative forums; obtains participatory commitment from senior executives; and introduces enforcement measures.
Configuration Control Board (CCB)
• Chief Architect
• Domain Owners
Responsible for monitoring and controlling changes to the EA after initial development.
Configuration Manager N/A Responsible for maintenance and configuration control of all EA products.
Domain Owners • Business Unit Managers Provides senior-level stakeholder and sponsor participation; works with architecture team on standards insertion and renewal, assigns business line resources (subject matter experts [SMEs]) and oversees review of business architecture products.
Enterprise Architecture Executive Steering Committee
Senior representatives from all organizations and
Decides strategy, planning, and resource allocation related to the development and
A Practical Guide to Federal Enterprise Architecture Appendix A: EA Roles and Responsibilities
66 February 2001
Role Members
(If composite) Responsibilities
(EAESC) operational missions within the agency; may include senior executives (e.g., CIOs) within the business community
maintenance of the EA products; approves the initial EA; provides strategic direction and ensures corporate support; sponsors, reviews, and approves an overarching architecture management strategy; approves significant changes to the EA.
Enterprise Architecture Program Management Office (EAPMO)
• Chief Architect
• Architecture Core Team
Provides for management and control of EA activities as a formal program; creates and maintains the EA program plan and associated EA project plans; defines tasks, resources, and schedules; provides for program management, monitoring, and control of EA product development and maintenance.
Enterprise Architecture Core Team
• Chief Architect • Business Architect • Systems Architect • Data Architect • Infrastructure Architect • Security Architect • Senior architecture
consultants • Technical writer
Responsible for development and refinement of enterprise and application architectures and for populating the EA repository. Develops formal standards requirements and manages the architecture processes; provides guidance to other teams. Provides for administration of the EA processes; influences agency officials so that project resources are obtained/retained, objections are properly handled, progress is maintained, and a high-quality, usable architecture framework is established. Monitors and measures the architecture�s effect on projects via process and product measurements.
Independent Validation and Verification (IV&V) Team
Neutral third party from the Agency, external Agency, or a contractor
Conducts architecture compliance evaluations; provides quality assurance checking on program information (cost, schedule, and performance data), as well as the proper implementation of the architecture methodology.
Quality Assurance Manager N/A Ensures quality of all architecture products; participates in architecture product working sessions and reviews. Reports directly to CIO.
Risk Manager N/A Identifies, monitors, controls, and takes action to mitigate EA program risks. Reports directly to CIO.
Subject Matter Expert (SME) Domain experts from within the organization (one from each business unit); may be supplemented with outside consultants
Supports Chief Architect and staff in documenting the defined mission or business requirements and related objectives; supports definition of policies that impact business goals; reviews EA repository products.
Technical Review Committee (TRC)
• Domain Owners • Senior Architectural
consultants • Chief Architect • Agency/Department
Business and Technical representatives
Assesses business alignment, solution proposals, and technical compliance; evaluates architecture compliance; assesses waiver/exception requests; and conducts standards review.
67 February 2001
Appendix B: Glossary
Term Source Definition �As-Is� Architecture TEAF The current state of an enterprise�s architecture (see
baseline architecture). �To-Be� Architecture TEAF The target state of an enterprise�s architecture (see
target architecture). Architectural Artifacts FEAF The relevant documentation, models, diagrams,
depictions, and analyses, including a baseline repository and standards and security profiles.
Architecture Product IEEE STD 610.12 The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.
Architecture DoD Joint Pub 1-02 A framework or structure that portrays relationships among all the elements of the subject force, system, or activity.
Architecture John Zachman A set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).
Architecture Repository TEAF An information system used to store and access architectural information, relationships among the information elements, and work products.
Artifact TEAF An abstract representation of some aspect of an existing or to-be-built system, component, or view. Examples of individual artifacts are a graphical model, structured model, tabular data, and structured or unstructured narrative. Individual artifacts may be aggregated.
Baseline Architecture The set of products that portray the existing enterprise, the current business practices, and technical infrastructure. Commonly referred to as the �As-Is� architecture.
Baseline Architecture FEAF Representation of the cumulative �as- built� or baseline of the existing architecture. The current architecture has two parts: • The current business architecture, which defines
the current business needs being met by the current technology
• The current design architecture, which defines the implemented data, applications, and technology used to support the current business needs.
Business Architecture FEAF A component of the current and target architectures and relates to the Federal mission and goals. It contains the content of the business models and focuses on the Federal business areas and processes responding to business drivers. The business architecture defines Federal business processes, Federal information flows, and information needed to perform business functions.
Capital Planning and Investment Control (CPIC) Process
OMB A process to structure budget formulation and execution and to ensure that investments consistently support the strategic goals of the Agency.
A Practical Guide to Federal Enterprise Architecture Appendix B: Glossary
68 February 2001
Term Source Definition Enterprise TEAF An organization supporting a defined business scope
and mission. An enterprise is comprised of interdependent resources (people, organizations, and technology) that should coordinate their functions and share information in support of a common mission (or set of related missions).
Enterprise Architecture (EA)
FEAF/TEAF A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs. It is a representation or blueprint.
Enterprise Architecture John Zachman The set of primitive, descriptive artifacts that constitute the knowledge infrastructure of the enterprise.
Enterprise Architecture Policy
A statement governing the development, implementation, and maintenance of the enterprise architecture.
Enterprise Architecture Products
The graphics, models, and/or narrative that depict the enterprise environment and design.
Enterprise Engineering A multidisciplinary approach to defining and developing a system design and architecture for the organization.
Enterprise Life Cycle TEAF The integration of management, business, and engineering life cycle processes that span the enterprise to align IT with the business.
Federal Enterprise Architecture Framework (FEAF)
FEAF An organizing mechanism for managing development, maintenance, and facilitated decision making of a Federal EA. The Framework provides a structure for organizing Federal resources and for describing and managing Federal EA activities.
Framework FEAF A logical structure for classifying and organizing complex information.
Legacy Systems TEAF Those systems in existence and either deployed or under development at the start of a modernization program. All legacy systems will be affected by modernization to a greater or lesser extent. Some systems will become transition systems before they are retired. Other systems will simply be retired as their functions are assumed by modernization systems. Still others will be abandoned when they become obsolete.
Methodology TEAF A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner.
Model TEAF Representations of information, activities, relationships, and constraints.
Principle TEAF A statement of preferred direction or practice. Principles constitute the rules, constraints, and behaviors that a bureau will abide by in its daily activities over a long period of time.
Principles FEAF A component of the strategic direction. In terms of the Federal Enterprise Architecture, the principles are statements that provide strategic direction to support the Federal vision, guide design decisions, serve as a
A Practical Guide to Federal Enterprise Architecture Appendix B: Glossary
69 February 2001
Term Source Definition tie breaker in settling disputes, and provide a basis for dispersed, but integrated, decision making.
Repository TEAF An information system used to store and access architectural information, relationships among the information elements, and work products.
Sequencing Plan A document that defines the strategy for changing the enterprise from the current baseline to the target architecture. It schedules multiple, concurrent, and interdependent activities and incremental builds that will evolve the enterprise.
Spewak EA Planning Methodology
Enterprise Architecture Planning, S.H. Spewak
Formal methodology for defining architectures for the use of information in support of the business and the plan for implementing those architectures developed and published by Steven H. Spewak.
Standards FEAF A component of the FEAF. Standards are a set of criteria (some of which may be mandatory), voluntary guidelines, and best practices. Examples include: • Application development • Project management • Vendor management • Production operation • User support • Asset management • Technology evaluation • Architecture governance • Configuration management • Problem resolution.
System IEEE STD 610.12 A collection of components organized to accomplish a specific function or set of functions.
Systems Development Life Cycle (SDLC)
TEAF Guidance, policies, and procedures for developing systems throughout their life cycle, including requirements, design, implementation, testing, deployment, operations, and maintenance.
Target Architecture FEAF Representation of a desired future state or �to be built� for the enterprise within the context of the strategic direction. The target architecture is in two parts: • Target Business Architecture�defines the
enterprise future business needs addressed through new or emerging technologies
• Target Design Architecture�defines the future designs used to support future business needs.
Transitional EA Components
Representation of a desired state for all or part of the enterprise for an interim milestone between the baseline architecture and the target architecture. A time-sliced set of models that represent the increments in the sequence plan.
Zachman Framework John Zachman, 1987 IBM Journal Article
Classic work on the concepts of information systems architecture that defined the concept of a framework and provided a 6x6 matrix of architecture views and perspectives with products.
A Practical Guide to Federal Enterprise Architecture Appendix B: Glossary
70 February 2001
71 February 2001
Appendix C: Acronyms
BPR Business Process Reengineering
C4ISR Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance Architecture Framework
CASE Computer Aided Software Engineering
CBA Cost-Benefit Analysis
CCB Change Control Board and Configuration Control Board
CD-ROM Compact Disk-Read Only Memory
CIC Capital Investment Council
CIO Chief Information Officer
CM Configuration Management
CMM® Capability Maturity Model®
COE Common Operating Environment
CONOPS Concept of Operations
COTS Commercial-off-the-shelf
CPIC Capital Planning and Investment Control
CRUD Create, Read, Update, Delete
DoD Department of Defense
DOT Department of Transportation
EA Enterprise Architecture
EAESC Enterprise Architecture Executive Steering Committee
EAPMO Enterprise Architecture Program Management Office
EIEITC Enterprise Interoperability and Emerging Information Technology Committee
FAWG Federal Architecture Working Group
FEAF Federal Enterprise Architecture Framework
FFRDC Federally Funded Research and Development Center
FOIA Freedom of Information Act
GAO Government Accounting Office
GPEA Government Paperwork Elimination Act
GPRA Government Performance Results Act of 1993
HTML Hypertext Markup Language
ICAM Integrated Computer Aided Manufacturing
ICOM Inputs, Controls, Outputs, and Mechanisms
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
72 February 2001
IDEF Integrated Computer Aided Manufacturing Definition Language
IEM Information Exchange Matrix
IER Information Exchange Requirement
IT Information Technology
IV&V Independent Verification and Validation
KDP Key Decision Point(s)
NIST National Institute of Standards and Technology
O&M Operations and Maintenance
OMB Office of Management and Budget
PMP Program Management Plan
PRA Paperwork Reduction Act
QA Quality Assurance
RM Risk Management
SDLC System Development Life Cycle
SID System Interface Description
SME Subject Matter Expert(s)
TEAF Treasury Enterprise Architecture Framework
TISAF Treasury Information Systems Architecture Framework
TQM Total Quality Management
TRC Technical Review Committee
TRM Technical Reference Model
UML Unified Modeling Language
USAF United States Air Force
WBS Work Breakdown Structure
73 February 2001
Appendix D: Example Architecture Products
D.1. Mission and Vision Statements
The Mission Statement describes the charter of the enterprise and the scope of work the enterprise needs to perform. The Vision Statement describes critical success factors for achieving the enterprise�s mission, including the resolution of key issues involving current performance of the mission. Vision Statements cover both business process aspects of the enterprise and IT aspects.
A sample outline for this work product includes:
• Organizational Mission Statement
• Customer Needs
• Business Goals and Objectives
• Business Vision
• Critical Business Issues
• Critical Success Factors.
D.2. Information Dictionary
Many of the architectural products have a graphical representation. However, there is textual information in the form of definitions and metadata (i.e., data about an item) associated with these graphical representations. The Information Dictionary provides a central source for all definitions and metadata, including those that may be provided for convenience within another product as well.
At a minimum, the Information Dictionary is a glossary with definitions of terms used in the given architecture description. The Information Dictionary consists of the attribute table information for all the other work products. The Information Dictionary makes the set of architecture products stand-alone so that it may be read and understood as a standalone document without reference to other documents.
Each labeled graphical item (e.g., icon, box, or connecting line) in the graphical representation of an architectural product should have a corresponding entry in the Information Dictionary. The type of metadata included in the Information Dictionary for each type of item will depend on the type of architectural product from which the item is taken.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
74 February 2001
D.3. Concept of Operations (CONOPS) Graphic
The high-level Concept of Operations (CONOPS) Graphic is the most general of the architecture products and the most flexible in format. It is intended to portray the operational activities of the agency (the enterprise) in a single graphic. This work product graphic provides a concise illustration of the business of the enterprise.
The CONOPS Graphic employs generic icons that can be tailored, as needed, and used to represent various classes of players in the architecture. The icons are used to represent nodes (players), missions, activity or tasks, facilities, equipment, etc. The CONOPS Graphic shows the sequencing of activities and illustrates the flow of information. The graphic can also portray the geographic distribution of architectural elements.
Figure 21 illustrates the three-dimensional nature of the military battlespace and the various players in the ground, sea, air, and space components of the environment. Components include naval ships, ground troops and equipment, airbases, missile batteries, aircraft, satellites; and their respective lines of communications can also be portrayed.
S T A T E V E C T O R
Figure 21. DoD Battlespace Concept of Operations Graphic
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
75 February 2001
Figure 22 captures the operational environment of the U.S. Customs Service for performance of its Trade Compliance mission. The figure shows the import of goods and merchandise into the U.S. via sea, air, and ground modes of transportation. It also shows the inspection of those goods and the rejection of invalid or illegal shipments. The graphic portrays the movement of those goods to the eventual consumers. The graphic depicts the collection of duties, fees, and taxes and the flow of those monies into the U.S. Treasury. Customs also captures and collects a large volume of statistical information at its 300-plus ports of entry. The Trade Compliance CONOPS Graphic shows the flow of that information to the Customs Data Center and to over 100 other government agencies.
Rules and Regulations
Goods at the Port
Targeting and Selectivity
Exam and Inspection Warehoused Destroyed Forfeited Returned Rejected Goods
Cleared Goods Consumers
Consignees
USCS NDC
Other Government Agencies
Federal Reserve Bank
Statistical Data
Importer/Broker
Figure 22. U.S. Customs Service Trade Compliance Concept of Operations Graphic
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
76 February 2001
D.4. Activity Models and Trees
The Activity Model (also called a Business Process Model) describes the applicable functions associated with the enterprise�s business activities, the data and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other activities that are outside the scope of the model (external exchanges). Activity Models are hierarchical in nature. They begin with a single box that represents the overall activity and proceed successively to decompose the activity to the level required for the architecture.
The Activity Model captures the activities performed in a business process or mission and the inputs, controls, outputs, and mechanisms (ICOMs) of those activities. Mechanisms are the resources that are involved in the performance of an activity. Controls, such as legislation or a business rule, represent constraints on an activity. The ICOMS are called activity constraints because each in some way constrains the business processes being modeled. The Activity Model can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs.
The Activity Model identifies the mission domain of the model and the viewpoint reflected by the model. Textual descriptions of activity definitions and business flows should be provided, as needed. Annotations to the model may identify the nodes (business locations) where the activities take place or the costs (actual or estimated) associated with performing each activity.
Certain Activity Models are created using the IDEF (Integrated Computer-Aided Manufacturing (ICAM) Definition) modeling technique. In this technique, activities are chronologically related as information flows through the process. Inputs are shown entering the activity from the left, while outputs or results of the activity are shown exiting on the right. Figure 23 provides an example of an IDEF Activity Model. The mechanisms (who or what performs the activity) are shown as arrows into the bottom of the activity. These can be people, roles, systems, computer programs, etc. The arrows entering from the top of the activity boxes are controls. Controls are the parameters that direct the activity, such as guidance or regulations from superior organizations, and physical, time, or other resource limitations.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
77 February 2001
Collect Data
Process Data
Disseminate Data
Use Data
External Inputs
Decision or Action
Mechanisms (Who or What
performs the activity) Mechanisms
(Who or What performs the activity)
Constraints on the Activity
Input(s) Output(s)
Figure 23. Generic IDEF Activity Model
An Activity Model may also be represented in a tree format. As shown in Figure 24, the highest level activity is represented as the first node in the tree. The lowest level activities called leaves are activities that are not further decomposed.
1.0 ACS
1.2.3 Liquidation Processing
1.2.2 File Entry Summary
1.4 Protest Processing
1.7 IPR Processing 1.5 Drawback Processing
1.9 Perform Special Projects
1.2 Importation
1.2.4 Statement Processing
1.2.1 Making Entry
1.2.6 Reconciliation Processing
1.8 MEWS Processing
1.2.5 Collections
1.2.5.1 Manual Payment Processing
1.2.5.2 Electronic Payment Processing
1.1.1 Define User Profiles
1.1.1.1 Manage non-Customs Participation 1.1.1.2 Manage Customs
Participation
1.1.3 Initiate a Bond
1.1 Maintain System Information
1.1.2 Service ACS Reference Information
1.2.1.1 Entry Data Processing
1.2.1.3 Cargo Release Processing
1.2.1.4 In-Bond Processing
1.6 Surety Processing1.3.1 Ocean Manifest
Processing
1.3 Manifest Processing
1.3.2 Air Manifest Processing
1.3.3 Rail Manifest Processing
1.3.4 Passenger Manifest Processing
1.2.2.1 Entry Summary Processing
1.2.2.2 Quota Processing
1.2.2.3 Visa Processing
1.2.2.4 AD/CVD Processing
1.2.1.2 Border Release Processing
1.10 Query
Figure 24. U.S. Customs, ACS, Activity Tree
The Activity Model can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
78 February 2001
Activity Models can be represented in Unified Modeling Language (UML), a standard modeling language adopted by the Object Management Group to support object-oriented analysis, design, and development. Figure 25 depicts an activity diagram represented in UML.
Review and Validate Entry/Manifest
entry/ Review Entry event Carrier files Manifest/ Review Manifest
Apply Selectivity Criteria
2nd Review and Validate Entry/Manifest
Importer Declares Entry
entry or manifest rejected
accepted
action required
Inspector stamps paper release
no problems[ entry and manifest OK ]
Notice to Importer and Carrier
Inspects Goods
random or selectivity criteria met Port Inspector stamps release
Notice to Importer and Carrier
release[ goods OK ]
seize
reject
release[ on arrival ]
inspect[ on arrival ]
hold
Port InspectorInspector (Office)Import SpecialistEntry Specialist
Figure 25. U.S. Customs, Trade Compliance, UML Activity Model
D.5. Business Use Case Model
A Use Case Model can describe either business processes or systems functions depending on the focus of the modeling effort. A Business Use Case Model describes the business processes of an enterprise in terms of business use cases and business actors corresponding to business processes and organizational participants (people, organizations, etc.). The Business Use Case Model is described in Use Case Diagrams and Use Case Specifications. In addition to representing business participation and process, the Use Case Diagram can also depict interrelationships among use cases such as Includes and Extends Relationships. An Includes Relationship represents inclusion or containment of use cases. An Extends Relationship depicts variations or alternative sequences or paths beyond the normal course of action.
The following figures show Use Case Diagrams and Specifications for Customs Trade Compliance Processing. Figure 26 and Figure 27 depict UML Use Case Diagrams and Figure 28 shows a Use Case Specification.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
79 February 2001
TC_UC_8: Declare Goods
TC_UC_2: Estimate/Pay Duties, Fees, and Taxes
TC_UC_37: Establish Account with Customs
TC_UC_38: Query Customs
TC_UC_10: File Protest
TC_UC_11: Make Drawback Request
TC_A1: Importer of Record
Decision to Import
Figure 26. U.S. Customs, Trade Compliance�External, UML Use Case Diagram
TC_A13: Entry Clerk
TC_A14: Import Specialist
TC_A16: OGA Inspector
TC_UC_62: Inspect Goods/Shipment
TC_A15: Customs Inpector
TC_UC_61: Capture and Review Importation Information
<<extend>>
TC_A3: US Customs
TC_UC_67: Process Protest from Importer
TC_UC_60: Process Entry
<<include>>Goods Declared
TC_UC_65: Process Drawback Request from Importer
TC_UC_66: Liquidate Entry
<<extend>>
TC_UC_63: Collect Duties, Fees, and Taxes
<<extend>>
<<extend>>
<<ex tend>>
TC_UC_64: Classify/Value Goods
<<include>> TC_A14: Import
Specialist
Figure 27. U.S. Customs, Trade Compliance�Internal, UML Use Case Diagram
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
80 February 2001
TC_A_1.0: Declare Goods
1. Overview: The Importer of Record provides information about an intended importation to Customs. Customs will process the information and respond with notices that determines what the Importer of Record will do next. The Importer of Record corrects or completes the transaction until it is known that the items will or will not be released.
2. Characteristic Information
Use Case Name: Declare Goods Owner: Mary Lou Collins Version Creation Date: December 13, 2000 Date Last Updated: December 19, 2000 Scope: Trade compliance Level: Strategic Primary Actor: Importer of Record Secondary Actors: Customs Focus Classes: Goods, Entry, Entry docs, License, Permit, Visa, Release Notification Trigger Event: The Importer of Record decides to import goods. Goal: Receive notification that the goods have been released.
3. Pre-conditions:
1 Importer of Record has made transportation arrangements for the items. 2 Importer of Record is in good standing with Customs, e.g., registered, licensed, bo
4. Main Scenario (Normative Path)
Step Action Description 1 Compile the information required for an entry (CF 3461 or 7501) 2 Collect documentation required by Customs to accompany the entry.
5. Post-conditions:
1 Customs records entry information 2 Importer of Record�s payment due or 10-day clock for payment tarts. 3 Goods available for carrier to move them into the U.S.
6. Scenario Exceptions / Variations
Step Variable Possible Variations 1 Information needed Query Customs for tariffs, currency rates, AD/CVD case numbers, 4 Method of filing Broad range of manual to highly automated alternatives
7. Related Information
Priority: Performance Target: Frequency: Once for each set of items that can be released at one ti
determined by the Importer or Record Super Use Case: Sub Use Case(s): Dependent Use Cases: Process Entry
8. Target Architecture Differences
Baseline Architecture Target Architecture Declaration is for a single import transaction Declarations will be associated with an account for pay
duties, fees, and taxes.
9. Open Issues
Issue ID Issue Description
Figure 28. U.S. Customs, Trade Compliance, Declare Goods, UML Use Case Specification
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
81 February 2001
D.6. Class Model
A Class Model is similar to a logical data model. It describes static information and relationships between information. A Class Model also describes informational behaviors. Like many of the other models, it also can be used to model various levels of granularity. Depending on the intent of the model, a Class Model can represent business domain entities or systems implementation classes. A business domain model represents key business information (domain classes), their characteristics (attributes), their behaviors (methods or operations), and relationships (often referred to as multiplicity, describing how many classes typically participate in the relationship), and cardinality (describes required or optional participation in the relationship). Each class, attribute, and relationship appearing in the Class Diagram is specified or defined in a class, attribute, or relationship specification. In the case of a relationship, the specification describes how each class participates in the relationship. Specifications further elaborate and detail information that cannot be represented in the class diagram. Figure 29 illustrates a Customs UML Business Class Diagram.
First Draft Complete - 12/14/00 TC_A1: Importer of
Record (from Owner/Planner
Trade Use Cases)
T_BC_01: ImporterOfRecord
role licenseNbr registrationNbr
isLicensed() isRegistered()
T_BC_05: Invoice
T_BC_06: PurchaseOrder
T_BC_07: BlanketPurchaseAgreement
T_BC_04: CommercialContract
T_BC_08: Consignee
TC_A3: US Customs
(from Owner/Planner Trade Use Cases)
T_BC_02: TradeAgent
name ID address phone
1n 1n
is realized by
Figure 29. U.S. Customs, Trade Compliance, Commercial View, UML Class Diagram
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
82 February 2001
D.7. State Model
State Models are useful in understanding and representing complicated business or system behaviors over time. A State Model can be used to describe the behavior of a specific business process, systems function, business class, or system class. State modeling is not a good technique to describe interactions among business processes or classes. Other techniques such as activity modeling or interaction modeling should be used for this purpose.
A UML State Model begins with a start state represented as a solid dot. Middle states are represented as ovals. The ending state is represented as a solid dot within a circle. State transitions are represented as arrows between states. Figure 30 presents a sample Customs UML State Diagram.
Transporting Goods
Awaiting Clearance
In Transit
arrived
Awaiting Transport
[ Bonded, Hired by Importer ] P̂icks up goods
Conveyance /Goods Seized
cleared
illegal activity / forfeiture determined
Figure 30. U.S. Customs, Trade Compliance, Carrier, UML State Diagram
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
83 February 2001
D.8. Node Connectivity Diagrams
The Node Connectivity Diagram illustrates and describes the business locations (nodes), the needlines between them, and the characteristics of the information exchanged.
The Node Connectivity Description can be produced at three levels:
• Conceptual Node Connectivity Description�an essential work product that describes the prominent, high-level nodes
• Logical Node Connectivity Description�a supporting work product that describes the design that details all categories and classes of nodes, but does not describe the physical implementation or locations of nodes
• Physical Node Connectivity Description�a supporting work product that describes the physical implementation and locations of nodes.
Each needline is represented by an arrow (indicating the direction of information flow), which is annotated to describe the characteristics of the data or information. Examples of characteristics include its substantive content; media (voice, imagery, text and message format, etc.); volume requirements; security or classification level; timeliness; and requirements for information system interoperability. Information exchange characteristics are shown selectively, or in summarized form, on this diagram and more comprehensively in the Information Exchange Matrix.
It is important to note that the arrows on the diagram represent needlines only. Each arrow indicates that there is a need for some kind of information transfer between the two connected nodes. There is a one-to-many relationship between needlines and information exchanges; that is, a single needline arrow on the Node Connectivity Description is a rollup of multiple individual information exchanges. The individual information exchanges are shown on the Information Exchange Matrix.
The diagram should illustrate connectivity with external nodes, i.e., nodes that are not strictly within the scope of the architecture but that act as important sources of information needed by nodes within the architecture or important destinations for information produced by nodes within the architecture. These external needlines should be labeled to show the external source or destination, as well as the information exchanged.
Functional/Operational views are not required to name real physical facilities as nodes. Functional/Operational views can instead focus on �virtual� nodes, which could be based on business �roles.� These �virtual� nodes will not always be capable of directly integrating with real (physical) nodes from other architectures, but they could provide insight concerning which physical nodes might be able to assume the roles portrayed.
A node can represent a role (e.g., a Bureau Chief Information Officer); an organization (e.g., U.S. Secret Service); a business facility (e.g., a specific IRS Service Center); and so on. The notion of �node� will also vary depending on the level of detail addressed by the architecture effort.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
84 February 2001
Organizations may choose to represent some nodes in physical terms (i.e., geographic location) if these nodes are intended to remain �constant� in the architecture analysis, e.g., an effort to determine the most cost-effective communications options between two facilities. On the other hand, organizations may choose to represent nodes much more generically, or notionally, if the entire business practice is being analyzed without constraints imposed by the existing architecture.
To emphasize the focus of the analysis and to ensure comparability and integration across efforts, it is important that each organization carefully document its use of the �node" concept.
The activities associated with a given information exchange should be noted in some way to provide linkages between each node and the activities performed, and to link the Node Connectivity Diagram with the Activity Model. When more than one Node Connectivity Description is included in an EA description, the architecture team should perform the appropriate mapping of conceptual to logical and/or logical to physical levels.
Figure 31, Figure 32, and Figure 33 present examples of Node Connectivity Diagrams.
TAP
NCAP
AES
CAPPS
ATS
ACS
AAT
MATS ESFAS
NIPS
SEACATS
AIMS
APIS TECS
Figure 31. U.S. Customs, ACS, Customs Systems, Node Connectivity Diagram
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
85 February 2001
Internal ACS Interfaces
Doc Ret
Collect
Statement
In Bond
Quota
Reconcil
ACH
Protest
ELVIS
SumSel
Liquid
BOND
AD/CVD
Drawback
Entry
Ent Sum/ EIP
BRASS
ABI AMS
Manifest
Cargo Select
Legend: Read N2 Chart in Clockwise Direction
Surety
1a 2a 3a 4a 5a 6a 7a
8a 9a
10a 11a 12a 13a 14a 15a 16a 17a 18a 19a
20a
21a 22a
23a 24a 25a
26a
1b
2b
3b
4b
27b
28b
30b
29b
32b14b
15b
6b
7b
36b
8b
9b 25b
34b
35b
17b
23b
31b
33b
Rev 3 as of: 29 June/1500
Figure 32. U.S. Customs, ACS, N2 Chart
The N2 Chart simply represents an alternative method to portray the connectivity between operational nodes of an enterprise. The nodes of the enterprise are shown as boxes on the diagonal of the chart. Information flow between the nodes is captured as numbered intersections at the vertical and horizontal axes. The chart is read in the clockwise direction. For example, the information flow from the ABI system to the ACH system is annotated at the intersection labeled 2a (above the diagonal). The other side of that interface�the flow of information from the ACH system to the ABI system�is annotated at the intersection labeled 2b (below the diagonal).
The details or characteristics of each of these information flows are presented in the accompanying Information Exchange Matrix (IEM). Each numbered interface in the Node Connectivity N2 Chart becomes a row in the IEM. The information exchange is thoroughly defined and described in the IEM.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
86 February 2001
The Node Connectivity Diagram depicted in Figure 33 illustrates high-level information exchanges between major operational nodes of the U.S. Air Force (USAF). At this level of detail, only the minimum essential, mission connectivities are illustrated. This graphic is color coded to show the connectivity required for the various USAF mission areas. These mission areas and the color code are presented as a legend in the lower right corner of the chart.
To: AFSOC,
Deployed
AFSOC,
USSTRATCOM
& JSOTF
To: Deployed SOFs, JTFs,
JICs, & Theater Cmd Ctrs
To: Theater
Commands
& JTFs
Non-DOD
DOD
Air Force
AFSCNICBM LCCs
Deployed SOF Forces
Force Mgmt Ops Centers
Logistics
Agencies
C o n t r a c t o r s
To: NMCC, FAA RCCs, Unified Cmds, JTFs, JICs,
WOC/SOCs,AOC, MAJCOM & Theater Cmd Ctrs
User Agencies
TALCE
C o m m e r c i a l
A i r C a r r i e r s
NAVSPOC
Satellite SystemsAFSPOC
ADOC
To:
Transport Ops
Maint Ctrs
NASA
USTRANSCOM Cmd Ctr
To: Trans
Ctrl Ctrs
To: JTF
Cmd Ctr
RAMCC
FEMA
To: JTF Cmd
Ctr , & Theater
Cmd Ctrs
To: Multiple
Users JICs
To
NASA
NCA
NAIC AFIWC
To: Theater
Cmd Ctrs &
Nat'l Agencies
USSOCOM Cmd Ctr
SATELLITE
LAUNCH
RANGES
To:
Supply
Ctrs
ARSPOC
352 SOG
353 SOG
AFFOR R/F
16th SOW
To: AOC
To: FAA RCCs
To SOC, AIA OSC, AFSOC Cmd Ctr, & JTF Cmd Ctrs
To: Satellite Launch
Ranges, NU/CC,
AFSPOC & SPADOC
WOC/ SOC
To: AF MAJCOM Ops
Ctrs, AIA OSC &
USTRANSCOM Cmd Ctrs
ABCCC
AWACS ASOS/ TACP
Medical Facilities
To: NMCC
To:
CRC/
FACP
Service Land & Maritime Forces
CRE/ FACP
TACC
FAA RCCs
To R0CCs/SOCCs
& AIA OSC
Allied Gvt's
USSTRATCOM Cmd Ctr
NSA
Wx Sources
AF MAJCOM Ops Ctrs
Supply Ctrs
Trans Control Ctrs
To: TACC
ROCC/ SOCC
N/U CC
Transport Ops
Combat
A/C JSTARS
NMCC
Mission Support DOD & External Agencies
Integrated Air Force C4I Systems Combat Operations
Joint or Combined (operated by AF)
Intel Support
Mobility Operations
Space Operations
Special Operations Rev 3R, 24 July 95
Sensors
MWC
To
NASA
SPADOC
SOC
Deployed AFSOC Cmd Ctr
SOF A/C Units
(USAF/USA)
To: AOC
To: AOC
& AFSOC
Cmd Ctr
Mobility A/C
IWSM Ctrs
To:
FMO Ctrs
To: Trans Cont. Ctrs
AFSOC Cmd Ctr
To: 352 &
353 SOG,
USSOCOM,
TACC
A l l i e d F o r c e s
O p s C t r s To: Service Air
Defense & Service
Land & Maritime
Forces
To: AFIWC
NDOC
To: AF MAJCOMs
CIA
AIA OSC
DMA
DIA
CIO
National Agencies
To: NSA & Other
Nat'l Agencies
To: CIO
To: CIA
To: DIA & DMA
To: AIA OSC
To: AFSOC Cmd CtrTheater Cmd Ctrs
To: Multi
Users
Service Air
Defense Units
To:
TACC
To:
AOC
To: AFFOR R/F &
ROCC/SOCC
AOC
AFAC
JSOTF
JTF Cmd Ctr
Figure 33. U.S. Air Force Node Connectivity Diagram
D.9. Information Exchange Matrix
The Information Exchange Matrix documents the Information Exchange Requirements (IERs) for an EA. IERs express the relationships across three basic entities (activities, business nodes and their elements, and information flow) and focus on characteristics of the information exchange, such as performance and security. IERs identify who exchanges what information with whom, why the information is necessary, and in what manner. IERs identify the elements of information exchanged between nodes in support of a particular activity. Relevant attributes of the exchange are noted. The specific attributes included are dependent on the objectives of the specific architecture effort, but may include the type of information media (e.g., data, voice, and video), quality (e.g., frequency, timeliness, and security), and quantity (e.g., volume and speed).
The IEM can be produced at three levels:
• Conceptual Information Exchange Matrix�an essential work product that describes the prominent, high-level information exchanges between prominent nodes
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
87 February 2001
• Logical Information Exchange Matrix�a supporting work product that describes the design that details all categories and classes of information exchanges, but does not describe the physical implementation of them
• Physical Information Exchange Matrix� a supporting work product that describes the physical characteristics of the implementation of information exchanges.
Particular capabilities such as security level of communications may also be captured for each exchange. This work product emphasizes the logical and operational characteristics of the information, namely, what information is needed by whom, from whom, and when. Table 6 illustrates an example of an entry in the Logical IEM of the US Customs Service EA. In the table, AIS is the automated information system at the source and destination that sends and receives the information exchange and LISI is the Level of Information System Interoperability. LISI is scaled from zero for a totally manual interface to five for a fully electronic connection.
Table 6. Example Logical Information Exchange Matrix
208a
Source Destination Information Associated Activity
Media LISISource AIS
Destination AIS
Event Trigger
Frequency of Transmission
Interoperability Issues
No.
Customs DOT
(NHTSA)
Vehicle Declaration (Form HS-7)
Cargo Release
Processing ACS MVII electronic 3 Import of
Vehicle Daily
Two data fields missing from transmission
208b Customs DOT
(NHTSA) Tariff Data
Data Updates
Maintain Systems
Information ACSMVII electronic 3
Data Update
Required As needed None
The IEM is not intended to be an exhaustive listing of all the details contained in every IER of every node associated with the architecture. That would be too much detail for an architecture description. Rather, this work product is intended to capture the most important aspects of selected information exchanges. Selecting the important details of the information exchanges depends on the purpose of the architecture description.
The number of information exchanges associated with an architecture may be quite large, even though the matrix may not contain all details about all IERs. To aid in understanding the nature of the information exchanges, developers and users of the architecture may want to view the IER data sorted in multiple ways, such as by task, by node, or by attribute. Consequently, using a matrix to present that information is limiting and frequently not practical. A spreadsheet or relational database is well suited to the highly structured format of the IEM. In practice, hardcopy versions of this product should be limited to high-level summaries or highlighted subsets of particular interest.
D.10. Organization Chart
The Organization Chart illustrates the relationships among organizations or resources. These relationships can include oversight, coordination relationships (influences and connectivity), and many others, depending on the purpose of the architecture. It is important to show these fundamental roles and management relationships in an architecture. For example, oversight relationships may differ under various circumstances, which will affect the activities that may be performed differently or by different organizations. Different coordination relationships may mean that connectivity requirements are changed. Figure 34 shows a generic example of an Organization Chart.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
88 February 2001
Top-Level Organization
Hierarchical Relationship
Second-Level Organization
Second-Level Organization
Third-Level Organization
Third-Level Organization
Coordination or Other Specified Relationship
Figure 34. Generic Organization Chart
D.11. Systems Interface Description and Connectivity Diagram
The System Interface Description (SID) depicts the assignments of systems and their interfaces to the nodes and needlines described in the Node Connectivity Diagram. The Node Connectivity Description for a given architecture shows nodes (not always defined in physical terms), while the SID depicts the systems corresponding to the system nodes.
The SID identifies the interfaces between nodes, between systems, and between the components of a system, depending on the needs of a particular architecture. A system interface is a simplified or generalized representation of a communications pathway or network, usually depicted graphically as a straight line, with a descriptive label. Pairs of connected systems or system components often have multiple interfaces between them. The SID depicts all interfaces between systems and/or system components that are of interest to the architect.
The graphic descriptions and/or supporting text for the SID should provide details concerning the capabilities of each system. For example, descriptions of information systems should include details concerning the applications present within the system, the infrastructure services that support the applications, and the means by which the system processes, manipulates, stores, and exchanges data. Figure 35 depicts a sample SID Connectivity Diagram.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
89 February 2001
NODES COMMUNICATIONS
NETWORK TO OTHER
COMMUNICATIONS SYSTEM
1
COMMUNICATIONS SYSTEM
2
SYSTEM 2
NODE A
PROCESSING
SYSTEM 1
PROCESSING
C O
M M
U N
IC A
T IO
N S
N
E T
W O
R K
F R
O M
O T
H E
R
N O
D E
S
Interface
CS1/PS2
Inter fac
e P S1/PS2
Interface PS2/C S2
SYSTEM 1
Component 1 FROM OTHER SYSTEM
Component 2
Component 4 Component 3
Component 5
TO OTHER
SYSTEM
Internodal Perspective System-to-System
Intranodal Perspective Intrasystem Perspective
Internodal Perspective Node Edge-to-Node Edge
NODE A NODE B
NODE C
SYSTEM 2
SYSTEM 1
EXTERNAL CONNECTION
SYSTEM 1
COMMS In terf
ace
COM M
S In ter
fac e
COMMS Interface One-way SATCOM
Interface
SYSTEM 2
SYSTEM 3
SYSTEM 1
SYSTEM 4
NODE A NODE B
NODE C
SYSTEM 2
SYSTEM 1
EXTERNAL CONNECTION
SYSTEM 1
COMMS In terf
ace
COM M
S In ter
fac e
COMMS Interface One-way SATCOM
Interface
SYSTEM 2
SYSTEM 3
SYSTEM 1
SYSTEM 4
Figure 35. Generic System Interface Description Connectivity Diagram
D.12. Standards Profile
An architecture Standards Profile is the set of rules that governs system implementation and operation. In most cases, especially in describing architectures with less than a department-wide scope, building a Standards Profile will consist of identifying the applicable portions of existing standards guidance documentation, tailoring those portions in accordance within the latitude allowed, and filling in any gaps.
This architecture product references the technical standards that apply to the architecture and how they need to be, or have been, implemented. The profile is time-phased to facilitate a structured, disciplined process of system development and evolution. Time phasing also promotes the consideration of emerging technologies and the likelihood of current technologies and standards becoming obsolete.
A Standards Profile table (see Figure 36) documents the use of the following items within an enterprise:
• Industry standards or technologies
• Federal, department, or bureau standards or technologies
• Commercial products
• Federal, department, or bureau products.
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
90 February 2001
. . .
Service Area Service Standard Operating System
Software Engineering Services
User Interface
Data Management
Data Interchange
Graphics
Client Server Operations Object Definition and Management
Data Management
Window Management
Dialogue Support
Kernel Shell and Utilities Programming Languages
Data Interchange
Electronic Data Interchange
Graphics
FIPS Pub 151-1 (POSIX.1) IEEE P1003.2
FIPS Pub 119 (ADA)
FIPS Pub 158 (X-Window System) DoD Human Computer Interface Style Guide FIPS Pub 158 (X-Window System) Project Standard FIPS Pub 127-2 (SQL)
FIPS Pub 152 (SGML)
FIPS Pub 161 (EDI)
FIPS Pub 153 (PHIGS)
Figure 36. Standards Profile Table
D.13. Technical Reference Model
A Technical Reference Model (TRM) is a taxonomy that provides:
• A consistent set of service areas, interface categories, and relationships used to address interoperability and open-system issues
• Conceptual entities that establish a common vocabulary to better describe, compare, and contrast systems and components
• A basis (an aid) for the identification, comparison, and selection of existing and emerging standards and their relationships.
The TRM organizes the Standards Profile and any standards or technology forecast documents. It can also organize technology infrastructure documentation. Frequently, some combination of the documents organized using the TRM are presented in a single document. Figure 37 depicts the service areas of the U.S. Customs Service TRM.
Workstation Productivity
Tools Analysis
Tools
User Environment
App Dev Env
Web App Services
Document Mgmt.
Application Services
Middleware Workflow
Integration Services
Data Services
Communications
Common Services
Email Infrastructure
Mgmt.Storage
Interchange
Voice Power Mgmt. Technologies
Service Area
Domain
Databases Data
Warehouse Data
Mgmt.
Operating Systems Network Security
Distributed Computing
Application Servers
Workstation Productivity
Tools Analysis
Tools
User Environment
App Dev Env
Web App Services
Document Mgmt.
Application Services
Middleware Workflow
Integration Services
Data Services
Communications
Common Services
Email Infrastructure
Mgmt.Storage
Interchange
Voice Power Mgmt. Technologies
Service Area
Domain
Databases Data
Warehouse Data
Mgmt.
Operating Systems Network Security
Distributed Computing
Application Servers
Figure 37. U.S. Customs Technical Reference Model
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
91 February 2001
Technology domains and sub-domains are defined along with key roles and points of contacts. A Technical Architecture Strategy is established for each sub-domain, with specifications and selection criteria, outlining how the products and technologies are going to be utilized. Figure 38 illustrates the domain and sub-domain definition being used in the planning strategy and as building blocks to aid project planning. Components are constructed to represent a set of sub- domains that are used together to build a functional component of the architecture.
Common Services
Operating Systems
Desktop/Client OS
Mainframe OS
Network OS
App/Data Server OS
Service Area
Domain
Sub-Domains
Product Strategies
App/Data Server OS Planning Strategy
Baseline Tactical Strategic
Sub-Domain Products
Components: Database Server
App/Data Server OS NT, Solaris...
Enterprise DBMS CA-Datacom, Oracle...
DBMS Gateways Oracle APPC...
Oracle Toolset...Database Mgmt. Tools
Message Oriented Middleware MQ Series...
Example Components (Functional Collection of Sub-Domains)
Sub-Domain Planning Strategy
Example
Domain and Sub-domain �Definitions �Key Roles & POCs �Specifications �Criteria �Benefits
Figure 38. Generic TRM Domain and Sub-domain Definitions and Components
A Practical Guide to Federal Enterprise Architecture Appendix D: Example Architecture Products
92 February 2001
93 January 22, 2002
Appendix E: Sample Architectural Principles
The following architecture principles derive from the many architectural principles identified throughout the available architecture literature. They are presented as a starting point in the architecture process. Each individual Agency, with unique needs and requirements, should first consider these, then modify, add to, or replace this list as appropriate to its purposes.
1. Architectures must be appropriately scoped, planned, and defined based on the intended use of the architecture.
Rationale: The architecture development effort needs direction and guidance to meet expectations for specific uses of the architecture end products. Detailed models may not be needed for high-level decision making; similarly, simple, descriptive architectures may not provide enough information to support engineering choices.
Implications: The architecture must be generated with a specific purpose and for a specific audience to ensure it meets the expectations of its intended stakeholders.
2. Architectures must be compliant with the law as expressed in legislative mandates, executive orders, Federal regulations, and other Federal guidelines.
Rationale: Federal Agencies must abide by laws, policies, and regulations. However, this does not preclude business process improvements that lead to changes in policies and regulations.
Implications: Federal Agencies should be aware of laws, regulations, and external policies regarding the development of architectures and the collection, retention, management, and security of data. Changes in the law (Clinger-Cohen Act) and changes in policy (OMB Circular A�130) may drive changes in architectural processes or applications.
3. Architectures facilitate change.
Rationale: In the rapidly changing IT environment, organizations need tools to manage and control their business and technical growth and change. As the technical development life cycle shortens, with new technologies replacing older systems every 18 months, organizations require an overarching architecture to capture their systems design and operating environment.
Implications: The systems developer and the chief architect should ensure the coordination between technology investments and business practices. Architectures must be used in the evaluation function of the Capital Planning and Investment Control process.
4. Enterprise architectures must reflect the Agency�s strategic plan.
Rationale: The target architecture has maximum value when it is most closely aligned with the organization�s strategic plan and other corporate-level direction, concepts, and planning.
Implications: The target architecture must be developed in concert with strategic planners as well as the operational staff. As the strategic plan changes, so do the future environment and the target architecture.
A Practical Guide to Federal Enterprise Architecture Appendix E: Sample Architectural Principles
94 February 2001
5. Architectures continuously change and require transition.
Rationale: The organization is constantly evolving towards its future. As today�s architecture transitions to the target architecture, the target becomes the organization�s baseline architecture at some point in the future. The baseline architecture continuously moves and transitions toward the target architecture.
Implications: The target architecture is a rolling set of products, continually portraying the out-year environment. As a component of strategic planning and change management, the target architecture captures the future environment including data requirements and systems transitions. The sequencing plan is the organization�s roadmap to systems migration.
6. Target architectures should project no more than 3 to 5 years into the future.
Rationale: Technology life cycles currently are in the neighborhood of 18 months, and new IT products appear on the market every 18 months. Federal acquisition practices are aligning to these rapid changes, which means that an organization�s future information needs and technical infrastructure requirements are changing just as rapidly. Consequently, no one can accurately predict what business practices will prevail 10 to 20 years into the future and what type of IT capabilities and resources will be available.
Implications: Target architectures will need to be revised and updated regularly. The sequencing plan, illustrating intermediate points in time, may become more valuable than the target architectures.
7. Architectures provide standardized business processes and common operating environments (COEs).
Rationale: Commonality improves interoperability, cost avoidance, and convergence. For example, the integration of architectural Activity Models and Operational Sequence Diagrams (on the business side) and the Technical Reference Model and technology forecasts (on the technical side) helps establish a COE within the organization�s logical and physical infrastructures.
Implications: The systems architect and the chief architect must ensure the coordination between technology investments and business practices. A COE grounded on standard business practices yields improved data structures.
8. Architecture products are only as good as the data collected from subject matter experts and domain owners.
Rationale: The architect is not vested with the organizational information. It is incumbent upon the architect to collect the needed architectural information from the members of the organization who possess the knowledge of the business processes and associated information. These subject matter experts tend to be operational staff, field representatives, systems developers, software designers, etc. The domain owners are the responsible managers of specific business areas.
Implications: The development of the architecture can be a slow process, dependent on the architect�s access to subject matter experts and domain owners. The validity of the architecture can be limited by the accuracy of the collected data. Development of the
A Practical Guide to Federal Enterprise Architecture Appendix E: Sample Architectural Principles
95 February 2001
architecture is an iterative process of data gathering and interviewing to obtain verification and validity checks of the architectural products.
9. Architectures minimize the burden of data collection, streamline data storage, and enhance data access.
Rationale: Data, as a corporate asset, is key to an organization�s vision, mission, goals, and daily work routine. The more efficiently an Agency gathers data, stores and retrieves that data, and uses the data, the more productive the Agency. Information is power.
Implications: Business processes are best improved by streamlining the flow and use of data and information. The development of architectural Node Connectivity Descriptions, Information Exchange Matrices, and other information models will aid in the design of improved data management systems.
10. Target architectures should be used to control the growth of technical diversity.
Rationale: The rapid adoption of new and innovative IT products can easily lead to introducing a diverse set of IT products that may not always be fully compatible within the existing enterprise infrastructure. This necessitates the selection and implementation of proven market technologies.
Implications: The target architecture must be used in conjunction with the organization�s investment review process and technology insertion plans. Relying on the architecture as an integral component of IT decision making helps control the introduction of incompatible products.
A Practical Guide to Federal Enterprise Architecture Appendix E: Sample Architectural Principles
96 February 2001
97 January 22, 2002
Appendix F: Bibliography
Beckner, S. G., & S. T. Norman, Air Force Architecture Development Guide. MITRE Technical Report 98B0000074. Colorado Springs, CO, 1998.
Boar, B. H. Constructing Blueprints for Enterprise IT Architectures. Wiley Computer Press. New York, NY, 1999.
Cook, M. A., Building Enterprise Information Architectures: Reengineering Information Systems. Prentice Hall. Upper Saddle River, NJ, 1996.
Department of Defense, C4ISR Architecture Working Group, DoD C4ISR Architecture Framework, Version 2.0, 18 December 1997.
Department of the Treasury, Chief Information Officer Council, Treasury Enterprise Architecture Framework (TEAF), Version 1.0, 3 July 2000.
Department of the Treasury, Treasury Information Systems Architecture Framework (TISAF), Office of the Deputy Assistant Secretary for Information Systems and Chief Information Officer, 3 January 1997.
Executive Guide: Measuring Performance and Demonstrating Results of IT Investments. GAO/AIMD- 98-89. March 1998.
Federal Chief Information Officer (CIO) Council, Federal Architecture Working Group, Architecture Alignment and Assessment Guide, October 2000.
Federal Chief Information Officer (CIO) Council, Federal Enterprise Architecture Framework (FEAF). Version 1.1, September 1999.
Federal Chief Information Officer (CIO) Council, Capital Planning and IT Management Committee, Smart Practices in Capital Planning, October 2000.
Clinger-Cohen Act of 1996 (formerly, Information Technology Management Reform Act [ITMRA]), Public Law 104-106. 10 Feb 1996.
Freedom of Information Act (FOIA). 5 U.S.C. §552, as amended by Public Law 104-231, 110 Stat. 3048 (1996).
Government Paperwork Elimination Act (GPEA) of 1998. Public Law 105-277, Title XVII. 21 Oct 1998.
Government Paperwork Reduction Act (PRA) of 1980, amended 1996. Public Law 104-13, 44 USC Chapter 35.
Government Performance Results Act (GPRA) of 1993. Public Law 103-58. 16 June 1993.
Information Technology Investment Evaluation Guide: Assessing Risks and Returns. A Guide for Evaluating Federal Agencies� IT Investment Decision-making. GAO/AIMD-10.1.13. February 1997.
A Practical Guide to Federal Enterprise Architecture Appendix F: Bibliography
98 February 2001
Information Technology Investment Management: A Framework for Assessing and Improving Maturity. GAO/AIMD-10.1.23. Exposure Draft.
OMB Circular A�11. Preparation and Submission of Budget Estimates. 19 July 2000.
OMB Circular A�130. Management of Federal Information Resources. 30 November 2000.
Rechtin, E., & M. W. Maier, The Art of Systems Architecting. CRC Press. New York, NY, 1997.
Sowa, J. F., & J. A. Zachman, Extending and Formalizing the Framework for Information Systems Architecture. IBM Publication G321-5488. IBM Journal, Vol. 31(3). 1992.
Spewak, S. H., Enterprise Architecture Planning. Wiley and Sons, New York, NY, 1992.
Systems Development Life Cycle, CIS Handbook 5500�07, U.S. Customs Service, October 1998.
Thomas, R, II, R. A. Beamer, & P. K. Sowell, Civilian Application of the DoD C4ISR Architecture Framework: A Treasury Department Case Study. Proceedings of 5th International Command and Control Research and Technology Symposium, Canberra, Australia. October 2000.
U.S. Customs Service, Enterprise Architecture Blueprint, August 1999.
Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26(3). 1987.
Zachman, J. A. The Framework for Enterprise Architecture: Background, Description and Utility. 1996.
Internet/WEB Links
Federal Chief Information Officer Council www.cio.gov
Federal Architecture Working Group www.cio.gov/docs/interopeability.html
ArchitecturePlus www.itpolicy.gsa.gov/mke/archplus/archhome.htm
Clinger-Cohen Act www.itpolicy.gsa.gov/mks/regs-leg/s1124_en.htm
The Clinton Administration's Policy on Critical Infrastructure Protection: Presidential Decision Directive 63, May 1998. www.ciao.gov/CIAO_Document_Library/paper598.html
Department of Defense Technical Reference Model, Version 1.0, November 5, 1999. www-trm.itsi.disa.mil
Department of the Treasury CIO www.treas.gov/cio/
A Practical Guide to Federal Enterprise Architecture Appendix F: Bibliography
99 February 2001
Digital Consulting, Inc (DCI) www.dci.com
Enterprise-wide Information Technology Architectures (EWITA) www.ewita.com
Federal Enterprise Architecture Framework, Version 1, September 1999. www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf
General Accounting Office, Assessing Risks and Returns: A Guide for Evaluating Federal Agencies' IT Investment Decision-making, Version 1, GAO/AIMD-10.1.13, February 1997. www.gao.gov/policy/itguide/
General Accounting Office, Information Technology Investment Management: A Framework for Assessing and Improving Process Maturity, Exposure Draft, Version 1, GAO/AIMD-10.1.23, May 2000. www.gao.gov/special.pubs/10_1_23.pdf
General Accounting Office, Measuring Performance and Demonstrating Results of Information Technology Investments, AIMD-98-89, March 1998. www.gao.gov/special.pubs/ai98089.pdf
General Services Administration, Office of Information Technology www.itpolicy.gsa.gov
IEEE 1471, Recommended Practice for Architectural Description, DRAFT Information Assurance Technical Framework Forum www.iatf.net
Information Technology Investment Portfolio System (I-TIPS) www.itips.gov
International Enterprise Architects Consortium and Architecture Center www.ieac.org
MetaGroup, Inc. Stamford, CT www.metagroup.com
Object Management Group www.omg.org
OMB Circular A�130, Management of Federal Information Resources, Revised, November 30, 2000. www.whitehouse.gov/OMB/circulars/a130/a130.html
OMB Memorandum M-97-16, Information Technology Architectures, June 18, 1997. www.whitehouse.gov/OMB/memoranda/m97-16.html
OMB Memorandum M-00-07, Incorporating and Funding Security in Information Systems Investments, 28 February 2000. www.whitehouse.gov/OMB/memoranda/m00-07.html
A Practical Guide to Federal Enterprise Architecture Appendix F: Bibliography
100 February 2001
OMB, Proposed revision of OMB Circular No. A�130, in Federal Register, Vol. 65, No. 72, April 13, 2000, pages 19933-19939 www.whitehouse.gov/omb/fedreg/rev-a130.pdf
Software Engineering Institute (SEI) Architecture Technology Page www.sei.cmu.edu
Steven Spewak Enterprise Architecture Planning Home Page www.eap.com
Stanford University, Enterprise Architecture Home Page www.standford.edu/group/APS/arch/index.html
The Open Group Architecture Framework (TOGAF) Technical Reference Model, version 5, 1999. www.opengroup.org/togaf
U. S. Customs Service, Enterprise Architecture Blueprint, October 1999. www.itpolicy.gsa.gov/mke/archplus/eab.pdf
U.S. Customs Service, Technical Reference Model Introductory Guide, August 1999. www.itpolicy.gsa.gov/mke/archplus/trm.pdf
UML � Unified Modeling Language www.omg.org/uml
Zachman Institute for Framework Advancement www.zifa.com
101 February 2001
Appendix G: The Zachman Framework
In September 1987, John Zachman published an important article in the IBM Systems Journal identifying what he called �A Framework for Information Systems Architecture,� sometimes simply referred to as �The Zachman Framework.� This article has grown to become a de facto standard for enterprise architecture development. In fact, the Zachman Framework provides much of the foundation for the FEAF and the frameworks of several Federal Departments and Agencies.
Two key ideas are illustrated in the Zachman Framework:
1. There is a set of architectural representations produced over the process of building a complex engineering product representing the different perspectives of the different participants.
2. The same product can be described, for different purposes, in different ways, resulting in different types of descriptions.
The Zachman Framework provides the necessary detailed and robust views of the enterprise information architecture. It outlines six increasingly detailed views or levels of abstraction for six architecture descriptions. The levels of abstractions are:
1. The Planner or Ballpark View
2. The Owner�s or Enterprise Model View
3. The Designer�s or Systems Model View
4. The Builder�s or Technology Model View
5. The Subcontractor�s or Detailed Representation View
6. The Functioning Enterprise or Actual System View.
And the six architecture descriptions�and the interrogatives that they answer�are:
1. The Data Description�What
2. The Function Description�How
3. The Network Description�Where
4. The People Description�Who
5. The Time Description�When
6. The Motivation Description�Why.
In Zachman�s opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations�different in context, meaning, motivation, and use. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell.
Figure 39 illustrates the Zachman Framework in a 6x6 matrix format. The six views or levels of abstraction are the rows of the matrix, while the architectural descriptions�the answers to the
A Practical Guide to Federal Enterprise Architecture Appendix G: The Zachman Framework
102 February 2001
enterprise interrogatives�are the columns. Each of the 36 cells of the matrix represents a descriptive model or architecture product that form the building blocks of the EA.
e.g.
Builde
SCOP (CONTEXTUA
MODE (CONCEPTUA
ENTERPRIS
Designe
SYSTE MODE (LOGICAL
TECHNOLOG MODE (PHYSICAL
DETAILE REPRESEN
(OUT-
Sub- Contracto
FUNCTIONIN ENTERPRIS
DATA FUNCTIO NETWOR
e.g. Data
Ent = Reln =
e.g. Physical Data
Ent =
Reln =
e.g. Logical Data
Ent = Data Reln = Data
e.g. Semantic
Ent = Business Reln = Business
List of Things to the
ENTITY = Class Business
List of Processes Business
Function = Class Business
e.g. Application
I/O = User Proc .= Application
e.g. System
I/O = Data
Proc.= Computer
e.g.
I/O = Control Proc.= Language
e.g.
e.g. Business Process
Proc. = Business I/O = Business
List of Locations in the Business
Node = Major Locatio
e.g. Business
Node = Business Link = Business
e.g. Distributed
Node = I/S (Processor, Storage, Link = Line
e.g. Technology
Node = Softwar
Link = Line
e.g. Network
Node = Link =
e.g.
Architectur
Planne
Owne
Builde
ENTERPRIS MODE
(CONCEPTUAL
Designe
SYSTE MODE
(LOGICAL)
TECHNOLOG MODE
(PHYSICAL
DETAILE REPRESEN
TATIONS (OUT-OF
CONTEXT
Sub- Contracto
FUNCTIONIN
MOTIVATIOTIMEPEOPL
e.g. Rule
End = Sub-
Means =
e.g. Rule
End =
Means =
e.g., Business Rule
End = Structural Means =Action
End = Business Means = Business
List of Business
Ends/Means=Major Bus. Critical Success
List of Events
Time = Major Business
e.g. Processing
Cycle = Processing Time = System Event
e.g. Control
Cycle = Component Time =
e.g. Timing
Cycle = Machine Time =
e.g.
e.g. Master
Time = Business Cycle = Business
List of
People = Major
e.g. Work Flow
People = Organization Work = Work
e.g. Human
People = Work =
e.g. Presentation
People = Work = Screen
e.g. Security
People = Work =
e.g.
Planne
Owne
to theImportant to the
What How Where Who When Why
John A. Zachman, Zachman International (810) 231-0531
SCOP (CONTEXTUA
Architectur
e.g. ENTERPRIS
e.g. Business
Figure 39. The Zachman Framework Matrix
For further readings and more detailed information on the Zachman Framework, please refer to any of John Zachman�s publications, the Zachman Institute for Framework Advancement (ZIFA) web site (http://www.zifa.com), and a number of publications by other authors such as Melissa A. Cook �s text, Building Enterprise Information Architectures: Reengineering Information Systems, Prentice Hall, Upper Saddle River, NJ, 1996. See Appendix F for a listing of related resources.
Best Practices in Enterprise Architecture
Downloaded 11/8/2016 from: http://www.gao.gov/key_issues/leading_practices_information_technology_management/issue_summary#t=0 Source document, a U.S. government resource, has been modified for general applicability, clarity, and relevance to the course.
The Government Accountability Office (GAO) has identified a set of essential and complementary management disciplines that provide a sound foundation for information technology (IT) management. These include: IT Strategic Planning, Enterprise Architecture, IT Investment Management, and Information Security. Although these best practices are discussed as they apply to the federal government, they apply equally to any organization.
Enterprise Architecture
An enterprise architecture (EA) is an integral part of the IT investment management process. An EA provides a clear and comprehensive picture of the structure of an entity. This picture consists of snapshots of its current and proposed technical environments, and a roadmap for transitioning from the current to the target environment. When properly managed, an EA can help optimize the relationships among an organization's business operations and the IT infrastructure and applications supporting them. In creating its EA, organizations should follow the steps in these five stages:
• Stage 1: Create EA Awareness o Raise awareness about the value of an EA.
• Stage 2: Build a foundation for managing EA o Commit the necessary resources, including people, processes and tools. o Select a framework or methodology as the basis for developing EA products and
select a tool for managing EA activities. • Stage 3: Develop the EA
o Develop EA products according to the selected framework, methodology, tools, and established management plans. Products should describe the organization in terms of business, performance, information, service, and technology. Terms should be described as-is and to-be.
o Track and measure progress against plans, identifying and addressing variances, as appropriate, and report on progress.
• Stage 4: Complete the EA o Obtain approval for the completed EA product from the EA steering committee
and the head of the organization. o Have an independent agent assess the quality (i.e. completeness and accuracy)
of the EA products. • Stage 5: Leverage the EA to manage change
o Write and approve an organization policy for IT investment compliance with EA.
o Institute a process to formally manage EA change, and periodically update EA products.
o Ensure that IT investments comply with EA. o Measure and report return on EA investments. o Measure and report compliance with EA.
Best Practices in Information Security
Downloaded 11/8/2016 from: http://www.gao.gov/key_issues/leading_practices_information_technology_management/issue_summary#t=0 Source document, a U.S. government resource, has been modified for general applicability, clarity, and relevance to the course.
The Government Accountability Office (GAO) has identified a set of essential and complementary management disciplines that provide a sound foundation for information technology (IT) management. These include: IT Strategic Planning, Enterprise Architecture, IT Investment Management, and Information Security. Although these best practices are discussed as they apply to the federal government, they apply equally to any organization.
Information Security
Organizations rely extensively on IT systems and electronic data to carry out their missions. Effective security for these systems and data is essential to prevent data tampering, disruptions in critical operations, fraud, and inappropriate disclosure of sensitive information. To create an effective information security program, organizations should:
• Periodically assess the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of their information and information systems.
• Develop risk-based policies and procedures that cost-effectively reduce information security risks throughout the life cycle of each information system in their information security programs.
• Develop system security plans for providing adequate security for networks, facilities, and systems or groups of information systems (as appropriate).
• Provide appropriate security awareness training to personnel, including contractors and other users of information systems that support the operations and assets of the organization.
• Test and evaluate the effectiveness of information security policies, procedures, and practices with a risk-based frequency, but no less than annually.
• Create a process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in information security policies, procedures, and practices.
• Have procedures for detecting, reporting, and responding to security incidents; mitigating risks associated with such incidents before substantial damage is done; and notifying and consulting with the information security incident center and other entities, as appropriate, including law enforcement agencies and other relevant officials.
• Have plans and procedures to ensure continuity of operations for information systems that support the operations and assets of the organization. Test plans to ensure they work.
• Develop, maintain, and annually update an inventory of major information systems.
�
THE UK’S LEADING PROVIDER OF EXPERT SERVICES FOR IT PROFESSIONALS
NATIONAL COMPUTING CENTRE
IT Governance Developing a successful governance strategy
A Best Practice guide for decision makers in IT
IT Governance Developing a successful governance strategy A Best Practice guide for decision makers in IT
The effective use of information technology is now an accepted organisational imperative - for
all businesses, across all sectors - and the primary motivation; improved communications and
commercial effectiveness. The swift pace of change in these technologies has consigned many
established best practice approaches to the past. Today's IT decision makers and business
managers face uncertainty - characterised by a lack of relevant, practical, advice and standards
to guide them through this new business revolution.
Recognising the lack of available best practice guidance, the National Computing Centre has
created the Best Practice Series to capture and define best practice across the key aspects of
successful business.
Other Titles in the NCC Best Practice series:
IT Skills - Recruitment and Retention ISBN 0-85012-867-6
The New UK Data Protection Law ISBN 0-85012-868-4
Open Source - the UK opportunity ISBN 0-85012-874-9
Intellectual Property Rights - protecting your intellectual assets ISBN 0-85012-872-2
Aligning IT with Business Strategy ISBN 0-85012-889-7
Enterprise Architecture - understanding the bigger picture ISBN 0-85012-884-6
IT Governance - developing a successful governance strategy ISBN 0-85012-897-8
Security Management - implementing ISO 27000 ISBN 0-85012-885-4
All title are available from NCC see the website for further details www.ncc.co.uk
The National Computing Centre - generating best practice
1
IT Governance Developing a Successful Governance Strategy A Best Practice Guide for Decision Makers in IT
IT Governance Developing a Successful Governance Strategy
2 3
Foreword For organisational investment in IT to deliver full value, it is recognised that IT has to be fully aligned to business strategies and direction, key risks have to be identified and controlled, and legislative and regulatory compliance demonstrated. IT Governance covers this and more, and in light of recent corporate failures, scandals and failure, enjoys a higher profile today than ever before.
Back in 2003, IMPACT launched an IT Governance Specialist Development Group (SDG) to identify the issues that need to be addressed and to share and further develop the practical approaches to IT governance used in their organisations.
Over the past two years, heads of IT governance from Abbey, Aon, Avis, Barclays, BOC, DfES, Eli Lilly, Learning & Skills Council, Legal & General, NOMS, Royal Mail and TUI Group have examined what they identified as the key topics and, with the guidance of IT governance expert Gary Hardy, have defined the good practices captured in this guide.
For further information on the IMPACT Programme, its Professional Development Programme and the IT Governance and CobiT Specialist Development Group, please contact Elisabetta Bucciarelli on 0207 842 7900 or email elisabetta.bucciarelli@ impact-sharing.com. The IMPACT Programme is a division of the National Computing Centre.
The IMPACT Programme International Press Centre 76 Shoe Lane London EC4A 3JB
IT Governance Developing a successful governance strategy A Best Practice Guide for decision makers in IT
Published by The National Computing Centre Oxford House Oxford Road Manchester M1 7ED
Website: www.ncc.co.uk Tel: 0161 242 2121 Fax: 0161 242 2499
First published November 2005
Copyright © National Computing Centre 2005
ISBN: 0-85012-877-8
British Cataloguing in Publication A CIP catalogue record for this book is available from the British Library
Printed and bound in the UK
All rights reserved: no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise without either the prior written permission of the authors and Publisher or as permitted by the Copyright, Designs and Patents Act 1988. Enquiries for such permissions should be made to the Publisher.
Disclaimer Every care has been taken by the authors, and by the National Computing Centre, and associated working groups, in the preparation of this publication, but no liability whatsoever can be accepted by the authors or by National Computing Centre, or associated NCC working groups, for actions taken based on information contained in this document.
All trademarks acknowledged.
IT Governance Developing a Successful Governance Strategy
2 3
1 IT Governance – The Business Case . . . . . . . . . . . 4 1.1 Why is IT Governance important? . . . . . . . . . . 5 1.2 What does IT Governance cover? . . . . . . . . . . 6 1.3 What are the benef i ts? . . . . . . . . . . . . . . . . . 6 1.4 What is IT Governance best pract ice? . . . . . . . 7
2 Performance Measurement . . . . . . . . . . . . . . . . . . 9 2.1 Why is performance measurement important? . 9 2.2 What does performance measurement cover? . 10 2.3 Who are the stakeholders and what are
their requirements? . . . . . . . . . . . . . . . . . . . . 11 2.4 What should we measure? . . . . . . . . . . . . . . . 12 2.5 What is best pract ice? . . . . . . . . . . . . . . . . . . 12
3 Implementation Roadmap . . . . . . . . . . . . . . . . . . . 14 3.1 Goals and success cr i ter ia . . . . . . . . . . . . . . . 14 3.2 How to get started . . . . . . . . . . . . . . . . . . . . 15 3.3 Who needs to be involved and what are their
ro les and responsibi l i t ies? . . . . . . . . . . . . . . . 16
4 Communication Strategy & Culture . . . . . . . . . . . . . 18 4.1 Who do we need to inf luence? . . . . . . . . . . . . 18 4.2 What are the key messages? . . . . . . . . . . . . . 19 4.3 Communicat ion best pract ices . . . . . . . . . . . . 20 4.4 Developing an inf luencing strategy . . . . . . . . . 20 4.5 Change roadmap . . . . . . . . . . . . . . . . . . . . . 22
5 Capability Maturity & Assessment . . . . . . . . . . . . . . 23 5.1 Why IT capabi l i ty is important . . . . . . . . . . . . 23 5.2 How to measure IT capabi l i ty . . . . . . . . . . . . . 24 5.3 Sett ing matur i ty targets and consider ing
improvements . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4 Roadmap for sustaining the approach . . . . . . . 25 5.5 Sel f assessment tool . . . . . . . . . . . . . . . . . . . 26
6 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1 What are the r isks? . . . . . . . . . . . . . . . . . . . . 28 6.2 What is the best approach for r isk analysis
and management? . . . . . . . . . . . . . . . . . . . . 29 6.3 Using standards and best pract ices –
is cert i f icat ion useful? . . . . . . . . . . . . . . . . . . 30 6.4 What are the roles of management, staf f
and audi tors? . . . . . . . . . . . . . . . . . . . . . . . . 31 6.5 Who needs to be competent? . . . . . . . . . . . . . 31 6.6 What competence is required? . . . . . . . . . . . . 32 6.7 How to obtain, develop, retain and ver i fy
competence . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.8 When to source competence from outside . . . . 35 6.9 Key learning points . . . . . . . . . . . . . . . . . . . . 35
7 Supplier Governance . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1 Why is suppl ier governance important? . . . . . . 37 7.2 The customer ’s role . . . . . . . . . . . . . . . . . . . 38 7.3 How best to select a suppl ier . . . . . . . . . . . . . 40 7.4 The customer/suppl ier re lat ionship . . . . . . . . . 40 7.5 Service management techniques and SLAS . . . 41 7.6 The suppl ier /outsourcing governance l i fecycle . 42
8 IT & Audit Working Together and Using CobiT . . . . . 43 8.1 Introduct ion to CobiT . . . . . . . . . . . . . . . . . . 43 8.2 How is CobiT being used? . . . . . . . . . . . . . . . 44 8.3 What are the roles of IT and audi t for
IT Governance? . . . . . . . . . . . . . . . . . . . . . . 45 8.4 How can IT and internal audi t work better
together? . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9 Information Security Governance . . . . . . . . . . . . . . 48 9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.2 What is informat ion secur i ty? . . . . . . . . . . . . . 49 9.3 Where to focus . . . . . . . . . . . . . . . . . . . . . . . 50 9.4 Roles and responsibi l i t ies . . . . . . . . . . . . . . . 50 9.5 Act ion planning and best pract ice . . . . . . . . . . 52
10 Legal & Regulatory Aspects of IT Governance . . . . . 53 10.1 Legal and regulatory factors af fect ing
IT Governance . . . . . . . . . . . . . . . . . . . . . . . 53 10.2 Roles and responsibi l i t ies . . . . . . . . . . . . . . . 54 10.3 Best approach to compl iance . . . . . . . . . . . . . 55 10.4 What IT has to do . . . . . . . . . . . . . . . . . . . . . 56 10.5 Deal ing wi th th i rd part ies . . . . . . . . . . . . . . . . 58 10.6 Cr i t ical success factors . . . . . . . . . . . . . . . . . 59
11 Architecture Governance . . . . . . . . . . . . . . . . . . . . 60 11.1 Why is archi tecture governance important? . . . 60 11.2 What are the object ives of archi tecture
governance? . . . . . . . . . . . . . . . . . . . . . . . . 61
12 Managing the IT Investment . . . . . . . . . . . . . . . . . . 63 12.1 Why is managing the IT investment important? 63 12.2 Port fo l io management . . . . . . . . . . . . . . . . . . 64 12.3 Benef i ts management . . . . . . . . . . . . . . . . . . 65 12.4 Measur ing investment performance . . . . . . . . 65 12.5 Improve value del ivery and ROI . . . . . . . . . . . 66 12.6 Measur ing and control l ing IT operat ional costs 66 12.7 Project r isk management . . . . . . . . . . . . . . . . 66
13 Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Contents
IT Governance Developing a Successful Governance Strategy
4 5
1 IT Governance – The Business Case
1.1 Why is IT Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 1.2 What does IT Governance cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1.3 What are the benefits? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 1.4 What is IT Governance best practice? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
The guide focuses on 12 key topics selected by the group because of their importance to effective IT governance:
The business case – The organisat ion needs to understand the value proposi t ion Performance measurement – Is the ship “on course”? Implementat ion roadmap – How to start – What path to fo l low Communicat ions – How to explain the object ives and change the cul ture Capabi l i ty assessment – Finding out the t rue current state of IT governance Risk management – What r isks exist and how to make sure they are deal t wi th Suppl ier governance – External part ies play a big role and must be included IT and audi t working together – How to co-operate for a common goal Informat ion secur i ty – A key topic in today’s networked environment Legal and regulatory aspects –Compl iance is a global concern Archi tectures – The foundat ion for ef fect ive technical solut ions Managing investments – Ensur ing value is del ivered and benef i ts real ised
Implementation of this guidance, or indeed any IT best practice, should be consistent with your organisation’s management style and the way your organisation deals with risk management and delivery of IT value. Please share these ideas with your business users, external service providers, and auditors, since to realise their full value, all stakeholders of IT services should be involved.
All analysts currently agree that probably the biggest risk and concern to top management today is failing to align IT to real business needs, and a failure to deliver, or be seen to be delivering, value to the business. Since IT can have such a dramatic effect on business performance and competitiveness, a failure to manage IT effectively can have a very serious impact on the business as a whole.
Corporate Governance generally has taken on even greater significance. It is being recognised that IT has a pivotal role to play in improving corporate governance practices, because critical business processes are usually automated and directors rely on information provided by IT systems for their decision making. With the growth of direct connection between organisations and their suppliers and customers, and more and more focus on how IT can be used to add value to business strategy, the need to effectively manage IT resources and avoid IT failures and poor performance has never been greater.
The current climate of cost reduction and budget restriction has resulted in new norm – there is an expectation that IT resources should always be used as efficiently as possible and that steps are taken to organise these IT resources ready for the next cycle of growth and new IT developments. A key aspect of these factors is the increasing use of third party service providers and the need to manage these suppliers properly to avoid costly and damaging service failures.
This briefing provides a high level set of business arguments for IT Governance. It also explains how an IT Governance initiative can enable business and IT executives to:
Be sure that that they are aware of a l l IT related r isks l ikely to have an impact on their organisat ion;
Know how to improve the management processes within IT to manage these r isks; Ensure there are manageable relat ionships wi th suppl iers, service providers and
with the business (customers); Ensure there is a t ransparent and understandable communicat ion of these IT
act iv i t ies and management processes to sat isfy the Board and other interested stakeholders.
IT Governance Developing a Successful Governance Strategy
4 5
IT Governance covers the culture, organisation, policies and practices that provide this kind of oversight and transparency of IT – IT Governance is part of a wider Corporate Governance activity but with its own specific focus. The benefits of good IT risk management, oversight and clear communication not only reduce the cost and damage caused by IT failures – but also engenders greater trust, teamwork and confidence in the use of IT itself and the people trusted with IT services.
1.1 Why is IT Governance important? IT Governance has become very topical for a number of reasons:
In the wake of Enron and other corporate scandals, “Governance” general ly has taken on even greater s igni f icance. IT has a pivotal ro le to play in improving corporate governance pract ices.
Management ’s awareness of IT related r isks has increased. There is a focus on IT costs in al l organisat ions. There is a growing real isat ion that more management commitment is needed to
improve the management and control of IT act iv i t ies.
IMPACT’s IT Governance Special Interest Group (SIG) has examined these trends and found that the following issues drive the need for IT Governance:
There is a general lack of accountabi l i ty and not enough shared ownership and clar i ty of responsibi l i t ies for IT services and projects. The communicat ion between customers ( IT users) and providers has to improve and be based on jo int accountabi l i ty for IT in i t iat ives.
There is a potent ia l ly widening gap between what IT departments th ink the business requires and what the business thinks the IT department is able to del iver.
Organisat ions need to obtain a better understanding of the value del ivered by IT, both internal ly and from external suppl iers. Measures are required in business ( the customer ’s) terms to achieve this end.
Top management wants to understand “how is my organisat ion doing with IT in comparison with other peer groups?”
Management needs to understand whether the infrastructure underpinning today’s and tomorrow’s IT ( technology, people, processes) is capable of support ing expected business needs.
Because organisat ions are rely ing more and more on IT, management needs to be more aware of cr i t ical IT r isks and whether they are being managed. Furthermore, i f there is a lack of c lar i ty and transparency when taking signi f icant IT decis ions, th is can lead to reluctance to take r isks and a fa i lure to seize technology opportuni t ies.
And f inal ly, there is a real isat ion that because IT is complex and has i ts own fast changing and unique condi t ions, the need to apply sound management discipl ines and controls is even greater.
Stakeholders include:
Top level business leaders such as the Board, Execut ive, non-Execs, and especial ly heads of Finance, Operat ions and IT.
Those that have a responsibi l i ty for investor and publ ic relat ions. Internal and external audi tors and regulators. Middle level business and IT management. Key business partners and suppl iers. Shareholders. Customers.
Concerns they typically have include:
Avai labi l i ty, secur i ty and cont inui ty of IT services. Costs and measurable returns on investments. Qual i ty and rel iabi l i ty of service – no embarrassments. IT not appear ing to respond to the real needs of the business. Ident i f icat ion and management of IT related r isks to the business.
IT Governance – The Business Case1
IT Governance Developing a Successful Governance Strategy
6 7
Capabi l i ty and ski l ls of human resources. Compl iance to legal , regulatory and contractual requirements. Responsiveness and nimbleness to changing condi t ions.
1.2 What does IT Governance cover? IT Governance is a relatively new concept as a defined discipline and is still evolving.
IT Governance is not just an IT issue or only of interest to the IT function. In its broadest sense it is a part of the overall governance of an entity, but with a specific focus on improving the management and control of Information Technology for the benefit of the primary stakeholders. Ultimately it is the responsibility of the Board of Directors to ensure that IT along with other critical activities is adequately governed. Although the principles are not new, actual implementation requires new thinking because of the special nature of IT.
IT Governance spans the culture, organisation, policy and practices that provide for IT management and control across five key areas1:
Alignment – Provide for strategic direct ion of IT and the al ignment of IT and the business with respect to services and projects.
Value Delivery – Conf i rm that the IT/Business organisat ion is designed to dr ive maximum business value from IT. Oversee the del ivery of value by IT to the business, and assess ROI.
Risk Management – Ascertain that processes are in place to ensure that r isks have been adequately managed. Include assessment of the r isk aspects of IT investments.
Resource Management – Provide high- level d i rect ion for sourcing and use of IT resources. Oversee the aggregate funding of IT at enterpr ise level . Ensure there is an adequate IT capabi l i ty and infrastructure to support current and expected future business requirements.
Performance Measurement – Ver i fy strategic compl iance, i .e. achievement of strategic IT object ives. Review the measurement of IT performance and the contr ibut ion of IT to the business ( i .e. del ivery of promised business value).
IT Governance is not a one-time exercise or something achieved by a mandate or setting of rules. It requires a commitment from the top of the organisation to instil a better way of dealing with the management and control of IT. IT Governance is an ongoing activity that requires a continuous improvement mentality and responsiveness to the fast changing IT environment. IT Governance can be integrated within a wider Enterprise Governance approach, and support the increasing legal and regulatory requirements of Corporate Governance.
1.3 What are the benefits?
Investments are likely to be needed to improve and develop the IT Governance areas that need attention. It is important therefore, to begin with as good a definition as possible of the potential benefits from such an initiative to help build a viable business case. The expected benefits can then become the project success criteria and be subsequently monitored.
The IMPACT IT Governance SIG has identified the following main areas of benefit likely to arise from good IT Governance:
Transparency and Accountability
Improved transparency of IT costs, IT process, IT port fo l io (projects and services). Clar i f ied decis ion-making accountabi l i t ies and def in i t ion of user and provider
relat ionships.
Return on Investment/Stakeholder Value
Improved understanding of overal l IT costs and their input to ROI cases. Combining focused cost-cut t ing wi th an abi l i ty to reason for investment. Stakeholders al lowed to see IT r isk/returns. Improved contr ibut ion to stakeholder returns.
1. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
6 7
Enhancement and protect ion of reputat ion and image.
Opportunities and Partnerships
Provide route to real ise opportuni t ies that might not receive at tent ion or sponsorship.
Posi t ioning of IT as a business partner (and clar i fy ing what sort of business partner IT is) .
Faci l i tate jo int ventures wi th other companies. Faci l i tate more businessl ike relat ionships wi th key IT partners (vendors and
suppl iers) . Achieve a consistent approach to taking r isks. Enables IT part ic ipat ion in business strategy (which is then ref lected in IT strategy)
and vice versa. Improve responsiveness to market chal lenges and opportuni t ies.
Performance Improvement
Achieve clear ident i f icat ion of whether an IT service or project supports “business as usual” or is intended to provide future added value.
Increased transparency wi l l ra ise the bar for performance, and advert ise that the bar should be cont inuously raised.
A focus on performance improvement wi l l lead to at ta inment of best pract ices. Avoid unnecessary expendi tures – expendi tures are demonstrably matched to
business goals. Increase abi l i ty to benchmark.
External Compliance
Enables an integrated approach to meet ing external legal and regulatory requirements.
1.4 What is IT Governance best practice?
Experiences gained by IMPACT SIG members have identified a number of practical organisational and process issues that need to be addressed when implementing IT Governance. This has enabled the Group to recommend the following best practices (critical success factors) when planning IT Governance initiatives:
An enterprise wide approach should be adopted
The business and IT must work together to def ine and control requirements. IT wi l l need to develop a control model appl icable to al l business uni ts/div is ions. A commit tee approach is recommended for set t ing, agreeing, and monitor ing
direct ion/pol icy etc. A shared, cohesive v iew of IT Governance is needed across the enterpr ise based on
a common language. There should be a c lear understanding (and approval) by stakeholders of what is
wi th in the scope of IT Governance.
Top level commitment backed up by clear accountability is a necessity
IT Governance needs a mandate and direct ion f rom Board/Execut ive level management i f i t is to succeed in pract ice.
Make sure management responsibi l i t ies and accountabi l i t ies in the business as wel l as IT have been def ined.
An agreed IT Governance and control framework is required
IT Governance – The Business Case1
IT Governance Developing a Successful Governance Strategy
8 9
Al though i t may generate chal lenges and pushback, and wi l l require a consensus, an agreed framework for def in ing IT processes and the controls required to manage them must be def ined for IT Governance to funct ion ef fect ively.
The processes for IT Governance need to be integrated with other enterpr ise wide governance pract ices so that IT Governance does not become just an IT owned process.
The framework needs to be supported by an ef fect ive communicat ion and awareness campaign so that object ives are understood and the pract ices are compl ied wi th.
Incent ives should be considered to mot ivate adherence to the f ramework. Pay at tent ion to devolved decentral ised IT organisat ions to ensure a good balance
between central ly dr iven pol icy and local ly implemented pract ices. Avoid too much bureaucracy.
Trust needs to be gained for the IT function (in house and/or external)
For IT Governance to work the suppl iers of IT services and know-how need to be seen as professional , expert and al igned to customer requirements. Trust has to be developed by whatever means including awareness programmes, jo int workshops, and the IT Director act ing as a br idge between the business and IT.
Measurement systems will ensure objectives are owned and monitored
Creat ion of an IT scorecard wi l l underpin and reinforce achievement of IT Governance object ives.
Creat ion of an in i t ia l set of measures can be a very good way to raise awareness and in i t iate an IT Governance programme.
The measures used must be in business terms and be approved by stakeholders.
Focus on costs
I t is l ikely that there wi l l be opportuni t ies to make f inancial savings as a consequence of implement ing improved IT Governance. These wi l l help to gain support for improvement in i t iat ives.
IT Governance Developing a Successful Governance Strategy
8 9
2 Performance Measurement
2.1 Why is performance measurement important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 2.2 What does performance measurement cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 2.3 Who are the stakeholders and what are their requirements? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 2.4 What should we measure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 2.5 What’s best practice? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
One of the greatest challenges faced by those trying to manage IT in today’s fast moving economy and complex technical environment is knowing whether the “ship is on course” and being able to predict and anticipate failures before it is too
late. Like driving a car or steering a ship, good instruments are essential. The use of measures to help steer the IT function has for many years been a challenge that few appear to have successfully addressed, which is why the expression “it’s like driving a car with a blacked out windscreen and no instruments” is often used. If it is difficult for those literate in technology and relatively close the IT function, then it is even worse for the end customer who finds technical jargon a smokescreen and lack of information relevant to his business a major headache.
There is no doubt that a practical and effective way to measure IT performance is an essential part of any IT Governance programme, just as transparency and reliability of financial results is a Corporate Governance necessity. Performance management is important because it verifies the achievement of strategic IT objectives and provides for a review of IT performance and the contribution of IT to the business (i.e. delivery of promised business value). It is also important in providing a transparent assessment of IT’s capability and an early warning system for risks and pitfalls that might otherwise have been missed. Performance measurement provides transparency of IT related costs, which increasingly account for a very significant proportion of most organisations’ operating expenses.
Stakeholders play a key part in IT Governance, since at the heart of the governance responsibilities of setting strategy, managing risks, allocating resources, delivering value and measuring performance, are the stakeholder values, which drive the enterprise and IT strategy.
For performance measurement to be successful, it is important to understand who the stakeholders are and what their specific requirements and drivers are so that the performance measurements will be meaningful to them. An IT Governance best practice is the approval of measures by stakeholders. A performance measurement system is only effective if it serves to communicate to all who need to know what is important and then motivates positive action and alignment to common objectives. The measures are not an end in themselves but a means to take corrective action and to learn from real experiences. Concise and understandable communication and clear accountabilities are therefore critical success factors if measures are to be turned into effective actions.
“If you can’t measure it, you can’t manage it”
2.1 Why is performance measurement important?
“Teams that don’t keep score are only practising.” Tom Malone, President Milliken & Company
Performance measurement is a key component of IT Governance. It verifies the achievement of strategic IT objectives and provides for a review of IT performance and the contribution of IT to the business (i.e. delivery of promised business value).
Performance measurement supports the other key elements2 of IT Governance by:
Al ignment – monitor ing the strategic direct ion of IT and the al ignment of IT and the business.
Value Del ivery – assessing whether the IT/Business organisat ion is providing business value from IT and assessing ROI.
Risk Management – monitor ing whether r isks are being ident i f ied and managed and measur ing the cost and benef i t of r isk management investments.
Performance Measurement2
2. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
10 11
Resource Management – measur ing the ef fect iveness of sourcing and use of IT resources, the aggregate funding of IT at enterpr ise level , and measur ing IT capabi l i ty and infrastructure compared to current and expected future business requirements.
Performance measures are required to ensure that the outcomes of IT activities are aligned to the customer’s goals. Internal IT process measures are required to ensure that the processes are capable of delivering the intended outcomes cost-effectively. Advanced performance measurement enables the measurement of key aspects of IT capability such as creativity and agility (new ideas, speed of delivery and success of a change programme), development of new solutions, ability to operate reliable and secure services in an increasingly demanding IT technical environment, and the development of human resources and skills.
Performance measurement may also be a vital tool when assessing mergers and acquisitions to allow earlier insight into IT strengths and gaps. The introduction of a performance measurement system focused on a few key measures can be an excellent way to kick-start an IT Governance initiative, providing, perhaps for the first time, transparency of critical activities and a way to bridge the communication gap between IT and its customers.
2.2 What does performance measurement cover? Performance measures are the “vital signs” of an organisation. They quantify how well the activities within a process or the outputs of a process achieve a specific goal. The measures tell people what and how they’re doing as part of the whole. They communicate what’s important throughout the organisation: strategy from top management down, process results from the lower levels up, and control and improvement within the process. Only with a consistent view of the “vital signs” can everyone work toward implementing the strategy, achieving the goals, and improving the organisation (Vital Signs, by Steven M. Hronec).
An IT performance measurement system should help to:
Focus on the customer to increase customer sat isfact ion Improve processes so problems are ant ic ipated and prevented Understand and reduce costs Encourage and faci l i tate change by obtaining facts about current state, desired
state and the gap that needs to be met Set real ist ic benchmarks for comparison
Effective performance measurement of IT will enable management and other stakeholders to know whether or not IT is meeting its objectives. It provides a transparent and objective communication mechanism, as long as the measures are understandable by both the customers and the service providers. The measures should address two aspects (The IT Governance Institute’s CobiT Management Guidelines provides example metrics for all IT processes and explains the difference between Goal Indicators (KGIs) and Process Indicators (KPIs)):
Outcome focused – is IT meet ing the object ives set by the customer? Process focused – are the IT processes operat ing ef fect ively and l ikely to lead to
the customer object ives being met?
The IT Governance SIG recommends that performance measures meet the following requirements to be successful:
Def ined using a common language appropr iate and understandable for the audience
Approved by the stakeholders In keeping with the cul ture and sty le of the organisat ion Based on targets der ived from IT’s object ives Contain a mix of object ive and subject ive measures Flexible and responsive to changing pr ior i t ies and requirements Based on easy to col lect actual measurement resul ts Include both posi t ive measures ( to mot ivate) and negat ive measures ( to correct) Balanced, i .e. measur ing more than just f inancial resul ts. The Balance Scorecard is
recommended as an ef fect ive approach providing f inancial , customer, internal and learning dimensions (The Balanced Scorecard, Kaplan & Norton)
Limited in number and focused only on pr ior i ty areas but suf f ic ient to support decis ion making (passes the “so-what?” test)
IT Governance Developing a Successful Governance Strategy
10 11
Easy to interpret (e.g. report ing should be visual using RAG or heat map techniques) and permit dr i l l ing down for more detai l and examinat ion of root causes. A scorecard is somet imes not appropr iate, e.g. for project review and pr ior i t isat ion or detai led analysis (where aggregat ion distorts or confuses)
Show trends to enable backward examinat ion and forward extrapolat ion Consol idated for hierarchical report ing Support benchmarking internal ly between peer groups and external ly wi th best
pract ice Integrated i f possible wi th any exist ing business level performance measurement
system
2.3 Who are the stakeholders and what are their requirements? Stakeholders play a key part in IT Governance. At the heart of the governance responsibilities of setting strategy, managing risks, allocating resources, delivering value and measuring performance, are the stakeholder values, which drive the enterprise and IT strategy. For performance measurement to be successful, it is important to understand who the stakeholders are and what their specific requirements and drivers are so that the performance measurements will be meaningful to them. An IT Governance best practice is the approval of measures by stakeholders (IT Governance Institute – Board Briefing on IT Governance).
For the purposes of performance measurement, we have classified stakeholders into three groups: investors, controllers and deliverers/providers with specific measurement interests and requirements as follows:
Investors – (business management, business partners and IT management)
Interests – they provide the funding and want to see a return on their investment and al ignment wi th their strategic object ives
Requirements
- Financial – ROI, cost v. budget, product iv i ty, benef i ts real isat ion - Customer – surveys and feedback (subject ive as wel l as object ive), strategic
object ives v. actual projects/act iv i t ies - Process – capabi l i ty benchmark, performance except ions, t ransformat ion
capabi l i ty and tact ical agi l i ty - Learning – at t r i t ion, retent ion, ski l l prof i le, resource short fa l l , t ra in ing and
development
Controllers – (internal and external audit, risk and compliance officers, finance, human resources, industry specific regulators)
Interests – they monitor r isk and compl iance and have an interest in due process, regulatory and legal requirements, evidence of governance and r isk management, amount of rework/repeat ef for t , and compl iance with strategy
Requirements
- Financial – losses, investments in control improvements - Customer – except ions/breaches, r isk management, compl iance with legis lat ion
and regulat ions - Process – control ef fect iveness, compl iance - Learning – r isk ident i f icat ion, r isk prevent ion
Deliverers/Providers – (IT service and product suppliers, in-house and outsourced, contract and procurement management and staff involved in IT delivery and support)
Interests – they need to meet customer expectat ions, and del iver in an ef f ic ient and ef fect ive way, preserving and enhancing reputat ion
Requirements
- Financial – operat ional and project costs, cost a l locat ion/recovery, service credi ts, cost opt imisat ion
- Customer – performance against SLAs, sat isfact ion feedback e.g. survey responses, customer retent ion and growth stat ist ics, ef fect iveness of deal ing wi th business churn
Performance Measurement2
IT Governance Developing a Successful Governance Strategy
12 13
- Process – internal improvement in ef f ic iency and r isk reduct ion, internal v. outsource decis ion support
- Learning – capabi l i ty to del iver, readiness for new requirements, t ime to market for new in i t iat ives
2.4 What should we measure? The ownership of measures and accountability for achieving targets should be clear. Furthermore, ownership and the collection of measurement data will not always be an IT responsibility, e.g. measurement of customer-focused outcomes. It should therefore also be clear whose responsibility collection is. Where appropriate, measures should be formalised in Service Level Agreements (SLAs) based on service descriptions written in a language and using terms meaningful to the customer. For third party service providers an SLA should form part of the contractual agreement so that performance measurement can be backed up with contractual recourse in the event of performance failure. To support IT Governance the following top fifteen areas to measure are recommended, with an indication of who has a primary interest and therefore who should approve the measures (figure 2.4)
2.5 What is best practice? Experiences gained by the IMPACT SIG members have identified a number of enablers and inhibitors that will assist in the achievement of Performance Measurement best practices when supporting IT Governance. Since the Interest Group is not primarily focused on performance measurement techniques we are not attempting to provide best practice guidance on measurement methods and/or tools.
In general, performance measurement should support this classic control model (figure 2.5)
Area Investors Controllers Providers
Business & IT alignment √
Major project delivery performance (objectives, time and budget) √ √
Overall financial performance (costs v. budgets) √ √ √
ROI for IT investments (business benefit) √
Status of critical risks √ √ √
Performance with respect to reliability and availability of critical services
√ √
Complaints (QOS) and customer perception √
Number of significant reactive fixes to errors √
SLA performance by third parties √ √
Relationships with suppliers (quality & value) √ √
Capability e.g. process maturity √
HR measures for people involved in IT activities √
Internal and external benchmarks √ √
Audit weaknesses √ √
Business continuity status √ √ √
Figure 2.4
IT Governance Developing a Successful Governance Strategy
12 13
Enablers
Support and ownership of performance measurement by Stakeholders Measures that are approved by and meaningful to the Stakeholders Measures that al ign wi th agreed IT object ives Measures that focus on processes cr i t ical to the success of IT object ives Measures that are easy to col lect and understand Targets that are chal lenging but also achievable Measures that are balanced e.g. based on the Balanced Scorecard technique Measurement reports and scorecards that are easy to interpret , wi th explanat ions
of except ions Where possible, measures should be automated
Inhibitors
Too much focus on technical measures (especial ly i f they are not al igned to IT object ives)
Lack of ownership and accountabi l i ty Measures which are not straightforward to interpret or encourage counter-product ive
behaviour (cf . Nat ional Heal th Wait ing List targets) Measures which are expensive to col lect or not focused on pr ior i ty areas Too many measures obscur ing relevant and important informat ion
Performance Measurement2
Figure 2.5 3
3. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
14 15
3 Implementation Roadmap
3.1 What are the goals and success criteria? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 3.2 How to get started – the key initial activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 3.3 Who needs to be involved and what are their roles and responsibilities? . . . . . . . . . . . . . . . . . . . . . . . . . . .16
This chapter describes an “Implementation Roadmap” for activating an effective IT Governance programme to deliver the above benefits, and is based on the practical implementation experiences gained by the IMPACT IT Governance SIG
members.
The roadmap begins with establishing clear goals and objectives in order to align effort with the real needs of the enterprise, to manage expectations, and to ensure continual focus. The roadmap then consists of activities to get started, followed by the key implementation tasks with suggested roles and responsibilities. IT Governance is an ongoing task and therefore this roadmap is only the initial phase of what needs to become an iterative sustainable approach.
3.1 What are the goals and success criteria? Implementing IT Governance for many organisations will mean major changes. It is important therefore to not only have high- level sponsorship but also the active involvement of key stakeholders. The roadmap is an iterative lifecycle that begins with an initial phase to define overall goals and to gain the support and commitment of top management which then leads to the ongoing effective governance of IT activities.
A generic set of initial objectives has been identified by the SIG and is shown in Figure 3.1. Figure 3.1.1 suggests some success criteria for this initial phase of IT Governance.
Typical objectives of the initial implementation phase “Agreed” √
Define the meaning of governance in your organisation and where/if IT Governance fits
Identify any organisational/environmental/cultural constraints and enablers
Achieve a broad understanding of IT Governance issues and benefits across all stakeholders
Agree, publish and gain acceptance of an initial IT Governance framework, tools and processes
Completion of an initial gap analysis against best practice – to demonstrate where IT Governance is already in place and to highlight areas of focus for the roadmap
Creation of a Project Initiation Document (PID) and/or Terms of Reference (ToR) that has the support of stakeholders
Creation of a Project Plan with definition and prioritisation of the initial ITG project deliverables
Identification and commitment of the resources required to deliver this initial project
Identification and sign-off of Key Performance Indicators and Critical Success Factors for this project
Documented estimated timescales and resource (£s and FTE) implications as well as expected ROI
Alignment of the ITG Initiative with business objectives/strategy
Figure 3.1
IT Governance Developing a Successful Governance Strategy
14 15
3.2 How to get started – the key initial activities Having set the goals, and gained support, activation consists of two steps – planning, based on analysis of the current environment, followed by implementation itself.
Planning These are recommended implementation planning activities together with some critical success factors:
Activities CSFs • Identify champions - Stakeholders (including partners), Input providers, IT strategy committee
(council) members • Establish IT strategy committee (council) • Identify IT “hotspots” in the organisation, and where governance could enable
‘hotspot’ resolution: - Strategy? Delivery? IT Cost? Architecture? - Where current approaches have not worked or caused serious failures • Identify skill set and capabilities needed from people involved • Identify existing good practice (‘pseudo governance’) or successes that could be
built on or shared • Identify cost/benefit arguments – why do we need to do anything? • Identify inconsistencies in process/practice • Identify opportunities for “rest of business” to get involved in IT • Explore opportunity to adopt industry best practice model, or standards
framework • Utilise external influences • Create a measurement approach for an area or activity to expose actual evidence
of problems • Do some gap analysis against industry best practice
√ Authoritative and articulate champions
√ Available skills and capabilities
√ Well prepared business cases approved by stakeholders
√ Real opportunities for the business to see the benefit of participating
√ Practical and useful governance approaches
√ Effective and useful measures
√ Expose the truth /whole picture, warts and all, about project success /failure, showing how governance can be helpful
Implementation Roadmap3 Success criteria for the initial implementation phase “Done” √
Key stakeholders identified, engaged and actively involved
Key stakeholders contributing towards and able to explain and support the business case for ITG
Stakeholders have an understanding of the expectations of the IT Governance initiative
Some initial ‘quick wins’ have been identified and implemented – to make governance “real”
Acceptance of the published IT Governance framework by those responsible for implementation
An effective communication plan – who to, what, when etc. to overcome any barriers and to motivate change
Current key IT projects mapped against ITG plan, to look for easy fit/implications
Changes are sustainable and institutionalised, i.e. they become Business as Usual practices
Figure 3.1.1
IT Governance Developing a Successful Governance Strategy
16 17
Implementation These are the recommended activities to start up the implementation roadmap, together with some critical success factors:
Activities CSFs • Create a sound project structure - Define scope (what is included/excluded) and deliverables - Agree success criteria/quality criteria - Set realistic timeframes - Allocate suitable resources and roles - Identify risks and a risk mitigation strategy • Gain approval from Senior Management (the higher the better within the
Enterprise) • Find reference site, or external examples to learn from • Build communication plan to gain buy-in, and break down barriers - Who/what/how frequent/purpose • Do a pilot activity (demonstrate the business case) to show how it would work and
demonstrate potential benefits • Follow a phased introduction, e.g. - Focus on critical but easier to address areas - Assess projects first - Build up operational performance improvement progressively based on
prioritising maximum return for lowest cost - Consider one business area first, others later - Aim to establish some successes while learning how to be effective
√ Good project management (set the governance tone)
√ Expectations set correctly √ Approved business case √ Manage IT like you manage
the rest of the business √ Convincing reference sites √ Successful pilot √ Address quick wins first to
demonstrate results and realise benefits before attempting any major changes
3.3 Who needs to be involved and what are their roles and responsibilities?
All three generic groups of stakeholders, and their interests, should be involved in an IT Governance initiative. A key characteristic of any successful IT Governance initiative is the establishment of an enterprise-wide approach that clearly sets out roles and responsibilities, emphasising that everyone has a part to play in enabling successful IT outcomes.
Figure 3.3: This timeline is generic and intended only to be an example – it is based on the SIG’s experience. Thanks to Legal and General for the concept.
IT Governance Developing a Successful Governance Strategy
16 17
It may also be helpful to include an external, or internal, facilitator to provide an objective and neutral position. The suggested generic roles and responsibilities of the three main groups are shown in Figure 3.3.1.
Implementation Roadmap3
Investors Providers Controllers
Management board (authority to make things happen)
• Give direction backed up with adequate support and sponsorship
• Balance requirements with available resources, making available additional resources if required
• Insist on and seek measurable benefit realisation
• Coordinate overseas/satellite parts of the enterprise to ensure their interests and constraints have been considered
• Create organisation and structure to ensure board involvement in the governance process – by forming committees, establishing reporting processes
• Monitor performance, monitor risks, correct deviations
Business and IT senior managers, business partners and project sponsors
• Implement organisation and necessary infrastructure
• Take ownership of requirements • Champion and collaborate in IT
governance activities • Ensure business strategy and objectives
are set and communicated and aligned with IT
• Assess business risks and impacts • Establish reporting processes meaningful
to stakeholders • Communicate any business concerns in
a balanced and reasoned way • Provide project champions, creating the
seeds of change
User representatives • Take responsibility for Quality Assurance
programme (design and output) • Regularly check actual results against
original (or changed) goals • Provide service feedback to providers
IT management (internal and external), with support from business management
• Take ownership and set direction of IT Governance activities
• Build and achieve a pilot business case
IT management • Set IT objectives • Define IT governance and control
framework • Identify critical IT processes • Assess risks, identify concerns • Assess IT capability, identify gaps • Initiate a continuous improvement
programme • Develop business cases for
improvements • Design and implement solutions • Commit skilled resources • Establish performance measurement
system • Report to senior management • Respond to QA feedback from customers
Suppliers/business partners • Integrate any own existing or planned
governance practices with customer’s • Support and contribute to customer’s
governance approach • Agree service definitions, incentives,
measures and contracts/agreements
Training and Development • Ensure adequate education and
communication
HR function • Incorporate governance principles into
induction and performance measurement process
Core team • Define plan and deliverables • Organise team and roles (architects,
senior responsible officer, facilitator, project manager, process owners)
• Undertake core tasks • Report progress to plan
Internal and External Audit • Scope audits in coordination with
governance strategy • Provide assurance on the control over IT • Provide assurance on the control over
the IT performance management system
Risk Management • Ensure that new risks are timely
identified, provide advice
Compliance officers • Ensure that IT complies with policy, laws
and regulations
Finance • Advise on and monitor IT costs and
benefits • Provide support for management
information reporting • Incorporate governance requirements
into purchasing/contract process
Figure 3.3.1
IT Governance Developing a Successful Governance Strategy
18 19
4 Communication Strategy & Culture
4.1 Who do we need to influence? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 4.2 What are the key messages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 4.3 Communication best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 4.4 Developing an influencing strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 4.5 Change roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
IT Governance and risk management is about improving the management and control of IT activities and enabling top management to exercise proper oversight. To achieve this, better processes, controls, best practices and management
techniques are required. However all of these improvements will only have a chance of succeeding in a sustainable way if the culture of the organisation is changed to drive and support the desired new management approach.
Effective communications are a key enabler of these changes, just as poor communications can create a legacy of misunderstanding, lack of trust, and technical mystique and hype in many organisations. As we said earlier, if it is difficult for those literate in technology and relatively close to the IT function, then it is even worse for the end customer who finds technical jargon a smokescreen and lack of information relevant to his business a major headache. Communication and cultural behaviour, based on appropriate influencing strategies are therefore key ingredients of any IT Governance improvement programme. In order to best influence stakeholders, and communicate the major objectives and benefits of IT Governance throughout the organisation, the right language must be used. Given the significance of IT both in terms of investment and potential impact on the business – the risks of IT and of failing to exploit IT for strategic advantage must be stressed in any communication about IT Governance. Wake-up calls are sometimes required at the highest levels. Stakeholders must understand and feel responsible for safeguarding against IT risks.
Effective communications will ensure that “everyone is on the same page” – that key issues have been grasped, objectives have been positively accepted by management and staff, and everyone understands their role. Every organisation will have its own existing culture and choice of IT Governance approach that it wishes to adopt. The roadmap to follow for cultural change and effective communication will therefore be unique to each organisation, however there may be common elements.
4.1 Who do we need to influence? A fundamental element of IT Governance is change. When considering who needs to be influenced for successful IT Governance, it is important to remember that different messages are needed for different stakeholders. Whatever the topic is about, the language used must be understandable, relevant to the intended audience, and motivate positive attitudes towards change.
Identifying and gaining the support of key influencers of success and failure help enable successful communications strategies. It is also vital to recognise the main stakeholders impacted by the change, identify why we want to influence a particular stakeholder, and identify any resistance that needs to be overcome. Positive attitudes need to be promoted and used to influence others.
All three generic groups of stakeholders, and their interests, should be involved in an IT Governance initiative. It is critical to influence these groups positively so that they understand the objectives and benefits of IT Governance and are able to communicate consistently to each other and within their groups (Figure 4.1).
IT Governance Developing a Successful Governance Strategy
18 19
4.2 What are the key messages? In order to best influence stakeholders, and communicate the major objectives and benefits of IT Governance, the right language must be used. An inability to communicate effectively has been one of the major causes of IT failures, with too much technical jargon, lack of business understanding and poor appreciation of the other party’s requirements and issues. Ideally, a common language is required, and a balance has to be found between the business trying to understand IT and IT trying to understand the business. Communications will improve if the business views the technology provider not as a simple enabler but as a valued business partner and if IT presents benefits in the language that the business understands. The following are examples of some of the key messages that need to be communicated, based on three primary IT Governance objectives and the related benefits that can be realised (Figure 4.2).
Communication Strategy & Culture4 Who needs to be influenced?
Investors Providers Controllers • The Board • IT Council/Management Team • Senior business unit managers e.g. key
customers of IT services • Business Partners • External investors/shareholders – as part
of corporate governance
• Project and change managers (IT and Business)
• Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. business sponsors,
project champions • Relationship managers and internal
communications teams • Suppliers (especially outsourced service
providers) • Contract and procurement management • Peripheral players/influencers/policy
owners e.g. HR, Facilities Management, Legal
• Internal audit and external audit (due diligence)
• External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and
business managers – reviewers of benefits/ROI
• Post investment appraisal/post project review teams
Key Messages • Benefits of governance • Why we need to do it • Impact on the business strategy • Commitment to support action plans
• Benefits of governance • Why we need to change • Your role and responsibility • How you need to change
• Need for independent assessment and assurance
• Relate to real business risks and impacts • Work positively with management to
address control needs
Figure 4.1
Ability to address these Objectives will realise these Benefits IT and Business strategic and operational alignment • IT and business working towards the same corporate goals • Architecture and other technology approaches seen as relevant
and value adding to the business
RoI/Stakeholder Value, Transparency and Accountability + Shareholder Value + Leveraging investments for greatest return + Better use of IT capabilities + Cost effective IT solutions
Effective Relationship Management (internal and external) • Mutual understanding of goals • Shared language and terminology • Working in partnership – equal investment and responsibility • Clear accountabilities
Opportunities and Partnerships + Increased synergies + Improved speed to market + Improved efficiencies, particularly with third parties + Agility to respond to change
Management Control/Quality Management • Standardised processes • Consistent approaches • Comparison/adoption of external best practices (e.g. ISO, CMMi,
CobiT, ITIL) • Professional IT services • Management of risks
Performance Improvement + Risk mitigation + Continuous efficiency and quality improvements + Increased assurance that controls are working + Transparency and confidence about measures
Figure 4.2
IT Governance Developing a Successful Governance Strategy
20 21
4.3 Communication best practices The experiences of the IT Governance SIG have shown that it is best practice to emphasise the importance of controlling IT related risks when communicating the need for IT Governance. In particular, make sure stakeholders understand and feel responsible for safeguarding against risks that would not exist if they had put in place effective IT Governance controls:
a) The “downside” business risks associated with the use and function of IT, i.e. financial losses, damage to reputation, loss of service etc.
b) The “upside” business risks of not exploiting IT effectively, i.e. loss of competitive advantage, inefficiencies, failure to respond to changing markets etc.
Recommended approaches If IT risks are not communicated effectively, and instead are surrounded by hype and complexity, then stakeholders will not appreciate their real impact, take the issues seriously, or be motivated to insist on better controls. The following approaches are recommended to ensure risks have been properly appreciated:
Emphasise the business impact of r isks associated with misal igned IT strategies, misuse of technology, badly managed operat ions and inef fect ive project management. Show how these r isks can be mit igated by ef fect ive controls.
- Use case studies that have impacted the business or other businesses (e.g. v i rus at tacks, cr i t ical service outages, projects wi th “unexpected outcomes”) to i l lustrate how issues might ar ise.
Ident i fy relevant examples of governance providing business benef i ts beyond the basic requirement of evidencing control .
- Use case studies to i l lustrate how effect ive governance has ident i f ied r isk to the business, i ts object ives and strategy, and brokered an al ternat ive solut ion.
- Use case studies to i l lustrate business benef i ts as a direct resul t of ef fect ive governance, e.g. reduced costs, improved qual i ty, product iv i ty, reputat ion and market ing advantages.
Scenar io model l ing wi th r isk assessment and mit igat ion: - Consider known and new r isks across both business and IT (e.g. external audi t
requirements) - How governance can help mit igate the r isk - Calculate a r isk factor = l ikel ihood x impact - Consider opt ions – accept, mit igate or assign
Using common business language: - Technological r isk in f inancial /economic/business terms - Legal / regulatory, contractual impl icat ions
Critical Success Factors
Involve al l re levant stakeholders in a faci l i tated workshop environment Get c lear ownership and funding commitment for r isk mit igat ing act ions Monitor/ t rack al l act ions
4.4 Developing an influencing strategy Critical to the success of any IT Governance initiative is an effective communications plan. The communications plan should be based on a well-defined influencing strategy. Behaviours will need to be changed and care should therefore be taken to ensure that participants will be motivated and see the benefits of the new approaches, as well as understanding the consequences of accepting responsibility. If this is not positively communicated, then IT Governance will not be perceived as part of the corporate mission with Board level support. Management will resist it as a barrier to getting the job done, a deviation from current priorities, or another management fad.
The strategy should identify opportunities for the active involvement of stakeholders in developing the governance approach, planning and implementing IT management changes, and ideally building specific change objectives/targets into personal performance plans. The stakeholders are likely themselves to be the targets of change and should be involved in discussing/ evolving responses to the change via collaborative workshops, focus groups etc.
IT Governance Developing a Successful Governance Strategy
20 21
The influencing strategies need to be designed to work in specific situations with the individual influence targets identified. The following table shows four typical influencing styles, examples of the communications involved and the associated leadership styles. It is important to select the most appropriate style taking into account who needs to be influenced and on what topic.
Focus on Roles and Responsibilities
Ident i fy an overal l sponsor and steer ing group with speci f ic tasks and responsibi l i t ies for leading the change
Ensure there is a complete structure of cascaded sponsorship down to team/l ine manager level
Focus on individual situations
Ident i fy champions ( those high on interest and/or inf luence) Use successes as benchmarks Disseminate across teams and support format ion of new teams
Figure 4.4.1 shows different change approaches that can be used. For IT Governance initiatives experience shows that the best approach is incremental change evolving and adapting of current practices to a new collaborative IT management approach.
Communication Strategy & Culture4 Influencing style examples
Asserting Persuading Bridging Attracting • Stating expectations of
improved IT Governance and consequences of not adopting the new control model
• Evaluating current capability, risk management, delivery quality etc. and exposing unacceptable performance
• Creating incentives by setting clear IT Governance objectives, based on business priorities, backed up by the personal reward scheme
• Proposing new management approaches, best practices, standards for IT activities, based on development workshops
• Reasoning that changes are needed, by educating top management about the key IT issues and the benefits IT Governance can provide, e.g. more ownership in the business of IT projects
• Involving the business in IT decision making, by breaking down technical barriers and encouraging shared responsibility for IT outcomes
• Listening to user feedback about IT services and encouraging suggestions via satisfaction surveys
• Disclosing IT problems and incidents seeking workable solutions instead of covering them up
• Finding Common Ground by developing corporate mission statements and policies about IT Governance with support from the Board
• Visioning by IT and the business developing shared strategies and action plans, backed up by measurable and accountable objectives and targets
Push Pull
Figure 4.4
Figure 4.4.1
IT Governance Developing a Successful Governance Strategy
22 23
4.5 Change roadmap Every organisation will have its own existing culture and choice of IT Governance paradigm that it wishes to adopt. The roadmap to follow for cultural change and effective communication will therefore be unique to your specific situation.
The following techniques (Exploring Strategic, Change Veronica Hope-Hailey, Julia Balogun, Gerry Johnson, Kevan Scholes, Cranfield University) can help guide the best path to follow, and can be used to assess how your organisational culture and management style currently deals with the governance of its IT activities and what cultural style it desires. To do this you must:
Analyse the exist ing state Def ine the desired state
Cultural style and paradigms are formed from several characterictics which can generally be illustrated as shown in Figure 4.5.
Figure 4.5.1 illustrates some of the typical current and desired IT Governance behaviours found in many organisations today.
Figure 4.5
Characteristic Current Desired Myths and Stories Poor business and IT alignment:
Project failures; budget overruns; poor service, failure to meet business needs.
Effective business and IT alignment: Demonstrable RoI, project success stories, user satisfaction, business driving IT.
Symbols Mystique and technical jargon, lack of business terms.
Common language based on customer needs. Business literate in IT issues and opportunities.
Power Structures Them and us attitudes. Collaboration. Organisational Structures Divisive. IT seen as overhead function. Partnerships. IT seen as business enabler. Control System Based on departmental units and who knows
the most. Based on defined processes, standards and best practices owned by the organisation.
Routines and Rituals Hidden agendas, measures in provider’s terms and a general lack of transparency leaving top management in the dark.
Joint forums for monitoring progress, measures in customer’s terms, transparent reporting to top management.
Figure 4.5.1
IT Governance Developing a Successful Governance Strategy
22 23
5 Capability Maturity Assessment
5.1 Why IT capability is important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 5.2 How to measure IT capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 5.3 Setting maturity targets and considering improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 5.4 Roadmap for sustaining the approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 5.5 Self-assessment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Monitoring and assessing the adequacy of IT Resources (people, applications, technology, facilities, data) to ensure that they are capable of supporting the current and proposed IT strategy is a key aspect of IT Governance. In many
organisations board level management have a very unclear view of their IT capability, and find it very difficult to understand the technical and organisational IT environment upon which they increasingly depend. Often inadequacies only manifest themselves when projects fail, costs spiral, operational systems crash, or service providers fail to deliver the value promised. To exercise sufficient governance and oversight, senior management should insist on objective and regular assessments of their internal and externally provided IT services to ensure any inadequate capabilities are exposed before serious problems occur, and then take the necessary action to rectify weaknesses. In recent years, surveys and assessments carried out around the world have shown that in general IT capabilities have not kept pace with increasing IT complexities and the growing demands for reliable, secure and flexible services. Cost control and reducing inefficiencies are also important reasons for reviewing technical and organisational capability.
Improving the maturity of IT capability both reduces risks and increases efficiency – cost saving is often a justification.
Capability Maturity Modelling (CMM) techniques (CMM was created by the Software Engineering Institute with Carnegie Mellon) are increasingly being adopted by many organisations for assessing IT capability. This technique focuses on the IT management processes that control IT resources, and assessments usually reveal significant weaknesses and an IT capability disproportionate to the high dependency organisations have on their IT service providers. Using the CMM scale it is rare to find even a defined (level 3) process in many organisations.
Management should insist on objective and transparent assessments, and carry out these analyses as part of any due diligence review, or request third party certifications when considering outsourcing or during mergers and acquisitions. Agreement then must be reached regarding where and how to address inadequacies, by either investing in the internal infrastructure or seeking externally provided outsourced resources, or accepting the risks.
5.1 Why IT capability is important A key to successful IT performance is the optimal investment, use and allocation of IT resources (people, applications, technology, facilities, data) in servicing the needs of the enterprise. Most enterprises fail to maximise the efficiency of their IT assets and optimise the costs relating to these assets. In addition, the biggest challenge in recent years has been to know where and how to outsource and then to know how to manage the outsourced services in a way that delivers the values promised at an acceptable price.
Boards need to address appropriate investments in infrastructure and capabilities by ensuring that:
The responsibi l i t ies wi th respect to IT system and services procurement are understood and appl ied.
Appropr iate methods and adequate ski l ls exist to manage and support IT projects and systems.
Improved workforce planning and investment to ensure recrui tment and more important ly, retent ion, of ski l led IT staf f .
IT educat ion, t ra in ing and development needs are fu l ly ident i f ied and addressed for al l staf f .
Appropr iate faci l i t ies are provided and t ime is avai lable for staf f to develop the ski l ls they need.
Capability Maturity Assessment5
IT Governance Developing a Successful Governance Strategy
24 25
Boards needs to ensure that IT resources are used and managed wisely by ensuring that:
Appropr iate methods and adequate ski l ls exist in the organisat ion to manage IT projects.
The benef i ts accruing from any service procurement are real and achievable.
IT assets are complex to manage and continually change due to the nature of technology, and changing business requirements. Effective management of the lifecycle of hardware, software licences, service contracts, and permanent and contracted human resources is a critical success factor in not only optimising the IT cost base, but also for managing changes, minimising service incidents, and assuring a reliable quality of service.
Of all the IT assets, human resources represent the biggest part of the cost base and on a unit basis the one most likely to increase. Identifying and anticipating the required core competencies in the workforce is essential. When these are understood, an effective recruitment, retention and training programme is necessary to ensure that the organisation has the skills to utilise IT effectively to achieve the stated objectives.”8
5.2 How to measure IT capability To ensure IT resources are managed effectively, IT capability should be assessed on a regular basis and whenever resources are critical to strategic IT decisions. The capability assessment should be:
Based on al ignment of IT goals wi th business goals Targeted at the IT processes cr i t ical to business success by,
- Assessing the current capabi l i ty of these IT processes - Determining the required capabi l i ty - Analysing any gaps in capabi l i ty - Providing transparent v is ib i l i ty of the capabi l i ty posi t ion - Def in ing and just i fy ing necessary improvement projects or - Re-adjust ing the IT strategy Adjust ing goals Improving capabi l i ty Outsourcing when cost-ef fect ive
The measurement of IT capability should be an objective assessment oriented towards business requirements. This will ensure that the current “as-is” and required “to-be” capabilities are realistic and measurable enabling any gaps to be identified and a plan to be drawn up to rectify any shortcomings.
The Capability Maturity Model (CMM) approach first developed by the Software Engineering Institute for measuring software delivery capability is increasingly being adopted as the basis for assessing overall IT capability. This model provides a standard scale for assessing the maturity of any IT process on a five-point scale (figure 5.2).
The following principles are recommended when carrying out an assessment:
Set Scope Select a reference model based on standards and best pract ices most sui table
for your business, e.g. CobiT, ITIL, SEI-CCM, SixSigma, ISO9000/9001, PMBOK – perhaps consider ing weight ing measures
Use an acceptable measurement methodology agreed with the stakeholders which is def ined and transparent
Set a basel ine in the context of 1 and 2 above and present the current state assessment using a scale or rat ing system
Set reasonable object ives for the targeted level of capabi l i ty Def ine measures which relate both to “ the journey” as wel l as the “end goal” (e.g.
the KPIs and KGIs recommended by CobiT) Ensure s impl ic i ty and f lexibi l i ty L imit the number of measures, minimise measurement overhead, and avoid
informat ion over load
Consider the following critical success factors:
Appropr iate level of ownership Avoid complexi ty and be f lexible
IT Governance Developing a Successful Governance Strategy
24 25
Embed measures into business as usual processes Ensure staf f have adequate ski l ls , t ra in ing and tools Create a repeatable process and agree frequency of report ing Where possible automate measurement and report ing Assess achievement against targets alongside other business as usual targets
5.3 Setting maturity targets and considering improvements The real value of a capability assessment comes from the identification and implementation of cost effective improvements. A realistic and practical approach is required to ensure that the proposed improvements are based on business priorities, will be supported and funded by management, and will be successfully implemented.
The following approach is recommended:
1. Understand the environment 2. Establ ish capabi l i ty improvement f ramework 3. Set real ist ic targets and respond to environment changes 4. Ident i fy gaps – pr ior i t ise improvements 5. Propose achievable solut ions
5.4 Roadmap for sustaining the approach Having initiated a capability assessment approach, and perhaps performed a pilot project, a capability assessment process needs to be implemented as part of normal business procedures.
The following practices are recommended to help ensure the process is sustainable
Art iculate current capabi l i t ies in relat ion to an adopted framework Set current levels of capabi l i ty in the context of external comparisons
Capability Maturity Assessment5
Figure 5.2
IT Governance Developing a Successful Governance Strategy
26 27
State the ef fect on the business of the current IT capabi l i ty state of af fa i rs. Descr ibe the ramif icat ions of NOT improving capabi l i ty e.g. addi t ional costs or r isks, inabi l i ty to real ise opportuni t ies, late or non-del ivery of the strategic development programme, redundant ef for t
Descr ibe the benef i ts of implement ing improvements in speci f ic areas Descr ibe the projected ef fect on the business af ter del ivery of enhancements
Initiating and sustaining capability enhancements
Agree steer ing and review mechanism, sponsorship etc. Agree on pr ior i t ised programme of improvements Look for cont inuous improvement opportuni t ies where improvement is relevant or
necessary Fol low the 80:20 rule, i .e. don’ t implement more than is necessary Embed al l improvements as “business as usual” , not a one-of f in i t iat ive Al l improvements should be achievable, sustainable, re levant Mot ivate everyone involved by publ ishing and celebrat ing successes Agree key measures around implementat ion of improvements and measures of
resul tant business benef i t – make part of a wider IT balanced scorecard Agree communicat ion to targets, stakeholders and sponsors as wel l as the wider
community where there is l ikely to be a general interest in outcomes Per iodical ly review the object ives and reset goals i f necessary, checking val id i ty of
goals against business strategy
5.5 Self-assessment tool The simple self-assessment diagnostic in figure 5.5 can be used to help show overall capability at a high level. It is based on the four domains of CobiT, broken down into the 34 CobiT sub-processes. The extent of the analysis depends on how precise you wish to be. A management workshop can be used to arrive at an approximate initial assessment without extensive analysis.
IT Governance Developing a Successful Governance Strategy
26 27
Capability Maturity Assessment5
IT Process/Maturity Im po
rt an
ce
A d
ho c
R ep
ea ta
bl e
D efi
ne d
M an
ag ed
O pt
im is
ed
Planning & Organisation
PO1 Define a Strategic Information Technology Plan H
PO2 Define the Information Architecture M
PO3 Determine the Technology Direction M
PO4 Define the IT Organisation and Relationships M
PO5 Manage the Investment in Information Technology M
PO6 Communicate Management Aims and Direction L
PO7 Manage Human Resources L
PO8 Ensure Compliance with External Requirements M
PO9 Assess Risks M
PO10 Manage Projects L
PO11 Manage Quality L
Acquisition & Implementation
AI1 Identify Solutions L
AI2 Acquire and Maintain Application Software M
AI3 Acquire and Maintain Technology Architecture M
AI4 Develop and Maintain Information Technology Procedures M
AI5 Install and Accredit Systems L
AI6 Manage Changes M
Delivery & Support
DS1 Define Service Levels M
DS2 Manage Third-Party Services H
DS3 Manage Performance and Capacity M
DS4 Ensure Continuous Service L
DS5 Ensure Systems Security M
DS6 Identify and Allocate Costs L
DS7 Educate and Train Users L
DS8 Assist and Advise Information Technology Customers L
DS9 Manage the Configuration M
DS10 Manage Problems and Incidents H
DS11 Manage Data H
DS12 Manage Facilities L
DS13 Manage Operations M
Monitoring
M1 Monitor the Process M
M2 Assess Internal Control Adequacy M
M3 Obtain Independent Assurance M
M4 Provide for Independent Audit M
Figure 5.5
IT Governance Developing a Successful Governance Strategy
28 29
6 Risk Management
6.1 What are the risks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 6.2 What is the best approach for risk analysis and management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 6.3 How can standards and best practices be used – is certification useful? . . . . . . . . . . . . . . . . . . . . . . . . . . .30 6.4 What are the roles of management, staff and auditors? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 6.5 Who needs to be competent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 6.6 What competence is required? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 6.7 How to obtain, develop, retain and verify competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 6.8 When to source competence from outside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 6.9 Key learning points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
The management of risks is a cornerstone of IT Governance, ensuring that the strategic objectives of the business are not jeopardised by IT failures. IT related risks are increasingly a Board level issue as the impact on the business of
an IT failure, be it an operational crash, security breach or a failed project, can have devastating consequences. However, managing IT risks and exercising proper governance is a challenging experience for business managers faced with technical complexity, a dependence on an increasing number of service providers, and limited reliable risk monitoring information. As a consequence, management are often concerned whether risks are being cost effectively addressed, and they need assurance that risks are under control.
The universal need to demonstrate good enterprise governance to shareholders and customers is the driver for increased risk management activities in large organisations. Enterprise risk comes in many varieties, not only financial risk. Regulators are specifically concerned about operational and systemic risk, within which technology risk and information security issues are prominent. The Bank for International Settlements, for example, supports that view because all major past risk issues studied in the financial industry were caused by breakdowns in internal control, oversight and IT. Infrastructure protection initiatives in the US and the UK point to the utter dependence of all enterprises on IT infrastructures and the vulnerability to new technology risks. The first recommendation these initiatives make is for risk awareness of senior corporate officers.
Therefore, the board should manage enterprise risk by4:
Ascertaining that there is t ransparency about the s igni f icant r isks to the enterpr ise and clar i fy ing the r isk-taking or r isk-avoidance pol ic ies of the enterpr ise.
Being aware that the f inal responsibi l i ty for r isk management rests wi th the board so, when delegat ing to execut ive management, making sure the constraints of that delegat ion are communicated and clear ly understood.
Being conscious that the system of internal control put in place to manage r isks of ten has the capaci ty to generate cost-ef f ic iency.
Consider ing that a t ransparent and proact ive r isk management approach can create compet i t ive advantage that can be exploi ted.
Insist ing that r isk management is embedded in the operat ion of the enterpr ise, responds quickly to changing r isks and reports immediately to appropr iate levels of management, supported by agreed pr inciples of escalat ion (what to report , when, where and how).
We must be conscious though that risk taking is an essential element of business today. Success will come to those organisations that identify and manage risks most effectively. Risk is as much about failing to grasp an opportunity as it is about doing something badly or incorrectly.
6.1 What are the risks? To enable effective Governance, IT risks should always be expressed in the business context rather than in the technical language favoured by IT risk experts. The following generic structure for expressing IT risks in any organisation is suggested:
Business specific risk (e.g. Operational risk of orders not being received)
4. Board Briefing on IT Governance, 2nd Edition, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
28 29
Generic common IT risk (e.g. IT availability risk)
Specific IT risk (e.g. Denial of service attack on Internet customer order system)
Business risks are affected by the business environment (management style, culture, risk appetite, industry sector factors such as competition, reputation etc., national and international regulations). IT risks can be similarly affected.
There is no single accepted set of generic IT risk definitions, but these headings can be used as a guide (Taken from a global study by the Economist Intelligence Unit in 2002):
Investment or expense r isk Access or secur i ty r isk Integr i ty r isk Relevance r isk Avai labi l i ty r isk Infrastructure r isk Project ownership r isk
The OGC’s M_o_R framework visualises four levels of risks in a pyramid with appropriate escalation to higher levels for significant risks (Figure 6.1).
For IT to be effectively governed, top management must be able to recognise IT risks and ensure that significant risks are managed. Significance of an IT risk is based on the combination of impact (what effect the risk would have on the organisation if it occurred) and likelihood (the probability of the risk occurring). Because of the complexity and fast changing nature of IT, education and awareness is essential to ensure risks are recognised – not just at the top management level but at all levels throughout the organisation. It is increasingly common for a dedicated risk management function to be established or for external advice to be obtained on a regular basis to ensure that risks are monitored and the rest of the organisation is kept informed. Maintenance of a risk catalogue or risk register can be helpful to ensure that a thorough review of all IT related risks takes place on a periodic basis and for providing assurance to management that risks are being addressed.
6.2 What is the best approach for risk analysis and management? Risk management consists of two main elements:
Risk Analysis Risk Management
Having defined risk appetite and identified risk exposure, strategies for managing risk can be set and responsibilities clarified. Dependent on the type of risk and its significance to the business, management and the board may choose to:
Risk Management6
Figure 6.1
IT Governance Developing a Successful Governance Strategy
30 31
Mit igate, by implement ing controls Transfer, by shar ing r isk Accept, by formal ly acknowledging that the r isk exists and monitor ing i t
The following framework for managing risk in Figure 6.2 is suggested by the OGC (OGC Risk Management Framework www.ogc.gov.uk).
The analysis of IT risks can be very time-consuming and there is a danger of “analysis paralysis”. To ensure effective and timely identification of risk, management workshops involving knowledgeable and interested representatives from the business, IT, audit and, if necessary external advisors, can help to rapidly pinpoint key risks requiring attention, as well as prioritising risk management actions. It is also important to identify the benefits of managing a risk as they can help to justify the business case for taking action. Benefits can include financial savings such as reduced losses and improved efficiencies as well as intangibles such as improved reputation and image.
Risk management checklists are useful for raising awareness and reminding everyone of typical risk related issues. Regular self-assessments, internal audits and external audits/assessments are also helpful to ensure objectivity, and a thorough approach. For technical areas such as Internet security, the advice of an expert is likely to be required to ensure any technical vulnerabilities have been identified.
6.3 Using standards and best practices – is certification useful? There is no doubt that effective management policies and procedures help to ensure that risks are identified and managed as a routine part of everyday activities. Adoption of standards and best practices will help to enable quick implementation of good procedures and avoid lengthy delays re-inventing wheels and agreeing approaches.
The best practices adopted have, however, to be consistent with the risk management framework and be appropriate for the organisation, and be integrated with other methods and practices that are being used. Standards and best practices are not a panacea and their effectiveness will depend on how they have been actually implemented and kept up to date. They are most useful when applied as a set of principles and as a starting point for tailoring specific procedures. To avoid practices becoming “shelf-ware”, change enablement is required, so that management and staff understand what to do, how to do it, and why it is important. For risk management to be effective, the use of a common language and a standardised approach oriented towards real business requirements is best – making sure everyone follows the same set of objectives, issues and priorities.
Benchmarking is another very useful way to compare how risk management is being addressed within the organisation in relation to best practice, industry peer groups and other organisations. Conformance to generally accepted standards and practices can be very helpful when managing risks relating to outsourced services and third party suppliers. Certification
Figure 6.2
IT Governance Developing a Successful Governance Strategy
30 31
against a standard may be important for helping to establish trust with trading partners, or for raising significance within the organisation. However, there is a danger that acquiring a certificate becomes more important as a marketing tool, than operating effective management itself. Certification may also only mean conformance with a baseline and may in itself not be sufficient to address all the risks in the organisation. In the IT environment there is no specific standard relating to risk management, but there are standards and best practices covering specific areas. Of these CobiT, ISO17799, ITIL, ISO9000, PMBOK and Prince2 are the most widely used.
6.4 What are the roles of management, staff and auditors? The ownership of IT risks, and giving direction for managing key risks is a fundamental aspect of IT Governance. An absence of top management responsibility and accountability for risk management can result in serious risks being ignored, potentially misguided actions, and even costly investments being wasted. Ultimately it is the business – the user of IT services – who must own business related risks including those related to the use of IT. They should set the mandate for risk management, provide the resources and funding to support any necessary risk management plan designed to protect their business interests, and monitor whether risks are being managed. In practice, due to the complex and technical nature of IT, the IT service provider will need to provide guidance and work with business management to ensure adequate safeguards are in place. IT management will then have a responsibility to endorse, establish and monitor the agreed risk management framework including key principles and mitigation strategies. IT and user staff have a responsibility to implement the framework, assessing, escalating and delivering mitigating actions.
Auditors can provide initial momentum by highlighting to senior management inadequate risk management practices or specific risks that are not being adequately addressed. Audit should also align audits with key business risks and known areas of weakness, and provide independent assurance to management, make sure that appropriate risk management plans are in place and are being followed in all key areas or provide improvement recommendations.
The OGC make the following suggestions regarding risk ownership:
Al locate responsibi l i ty at a senior level for managing key r isks Ensure that every r isk has an owner; there may be separate owners for the act ions
to mit igate the r isks Ensure anyone al located ownership has the author i ty to take on the responsibi l i ty
and that they are aware that they are the designated owner Adopt a mechanism for report ing issues – ul t imately to the indiv idual who has to
retain overal l responsibi l i ty
6.5 Who needs to be competent? A key characteristic of any successful IT Governance initiative is the establishment of an enterprise-wide approach that clearly sets out roles and responsibilities, emphasising that everyone has a part to play in enabling successful IT outcomes. Implementation of effective IT Governance therefore depends on everyone having adequate and appropriate skills to fulfil their specific role. In most organisations, Investors and Controllers will have a good understanding of governance principles but they usually have a very poor understanding of how to apply these principles in the world of IT. Providers, who are usually IT specialists, conversely understand IT but have a poor appreciation of governance and control principles.
Most IT Governance initiatives begin with the establishment of an IT Governance project team and the appointment of an IT Governance project manager. The team is likely to be made up of people with some existing skills and relevant experiences, sometimes supported by external advisors, but usually even these teams will require training to improve their competence in IT Governance concepts and implementation approaches. Over time the project team will become the specialists, guiding and mentoring all role players. For IT Governance to be successful and sustainable, skills must be transferred from the specialists to the rest of the organisation.
Risk Management6
IT Governance Developing a Successful Governance Strategy
32 33
6.6 What competence is required? Each group of role players will require different sets of skills to support IT Governance effectively (Figures 6.6-6.6.2).
Investors Role & Responsibilities Competence Required Management board (authority to make things happen) • Give direction backed up with adequate support and sponsorship • Balance requirements with available resources, making available
additional resources if required • Insist on and seek measurable benefit realisation • Coordinate overseas/satellite parts of the enterprise to ensure
their interests and constraints have been considered • Create organisation and structure to ensure board involvement
in the governance process – by forming committees, establishing reporting processes
• Monitor performance, monitor risks, correct deviations Business and IT senior managers, business partners and
project sponsors: • Implement organisation and necessary infrastructure • Take ownership of requirements • Champion and collaborate in IT governance activities • Ensure business strategy and objectives are set and communicated
and aligned with IT • Assess business risks and impacts • Establish reporting processes meaningful to stakeholders • Communicate any business concerns in a balanced and reasoned
way • Provide project champions, creating the seeds of change User representatives • Take responsibility for Quality Assurance programme (design and
output) • Regularly check actual results against original (or changed) goals • Provide service feedback to providers
General executive leadership skills: - Ability to understand the big picture and how IT plays a part - Ability to think strategically – how can IT make a positive difference
to enterprise strategy? - Ability to make strong decisions relating to IT, and be able to direct
and challenge IT approaches Ability to challenge: - Uncover IT related issues - Probe business cases - Assess concerns - Assess performance IT awareness and understanding: - Ability to demonstrate value of IT to the business, including return
on investment - Ability to understand how the business can use IT profitably - Ability to appreciate the impact of IT on the business, from a value
perspective but also from a risk perspective - Be able to link the IT and business strategy, and show how IT
supports and enables the overall strategic approach Ability to challenge: - Uncover IT related issues - Assess accuracy of requirements - Assess and prioritise concerns - Assess performance - Assess impacts of risks and poor performance Ability to articulate requirements and monitor delivery: - Understand how to express IT related requirements, test
deliverables and provide constructive feedback
Figure 6.6
Providers Role & Responsibilities Competence Required IT management (internal and external), with support from business management • Take ownership and set direction of IT Governance activities • Build and achieve a pilot business case IT management • Set IT objectives • Define IT governance and control framework • Identify critical IT processes • Assess risks, identify concerns • Assess IT capability, identify gaps • Initiate a continuous improvement programme • Develop business cases for improvements • Design and implement solutions • Commit skilled resources • Establish performance measurement system • Report to senior management • Respond to QA feedback from customers
Ability to manage overall IT activities: - Ability to communicate well in business language - Influencing skills – particularly, able to influence the Investors - Knowledge of the IT organisation and the wider business
organisation - Awareness of overall business and IT strategy - Ability to take a high level view and understand the rationales - Aggregate assessment – be able to appreciate the whole IT
picture, identify and prioritise key issues and actions - Ability to justify improvement actions - Understand the principles of regulation Supplier management skills: - Contract and commercial management - Risk management - Stakeholder management – who should be involved and why - Portfolio management - Budget management
IT Governance Developing a Successful Governance Strategy
32 33
6.7 How to obtain, develop, retain and verify competence
Recruitment When considering who to place in IT Governance lead positions, especially when creating an initial project team, staff in a number of existing positions may be excellent candidates. The IMPACT IT Governance SIG members have found that the following roles often provide people who would be effective in IT Governance roles.
Audi tors Project Managers Risk Managers Business Analysts Infrastructure Management Procurement/Contract Management IS Strategy – al ignment wi th the business Qual i ty Management Business Relat ionship Management Programme Managers
However, there is a need for breadth of business and IT knowledge rather than too narrow a specialisation.
Risk Management6 Suppliers/business partners • Integrate any own existing or planned governance practices with
customer • Support and contribute to customer’s governance approach • Agree service definitions, incentives, measures and contracts/
agreements Training and Development • Ensure adequate education and communication HR function • Incorporate governance principles into induction and performance
measurement process Core team • Define plan and deliverables • Organise team and roles (architects, senior responsible officer,
facilitator, project manager, process owners) • Undertake core tasks • Report progress to plan
People related IT Governance skills: - Understanding of roles - Understanding of competencies required - Understanding of sources of expertise Delivery management skills: - Familiarity with best practices - Understanding of IT processes, how they should be controlled,
and how to monitor performance - Knowledge of corporate standards and policies affecting IT - Ability to provide cost estimates - Engagement and project management
Figure 6.6.1
Controllers Role & Responsibilities Competence Required Internal and external audit • Scope audits in coordination with governance strategy • Provide assurance on the control over IT • Provide assurance on the control over the IT performance
management system Risk management • Ensure that new risks are identified in a timely manner, provide
advice Compliance officers • Ensure that IT complies with policy, laws and regulations Finance • Advise on and monitor IT costs and benefits • Provide support for management information reporting • Incorporate governance requirements into purchasing/contract
process
How to apply good Governance practices effectively in IT: - Understand the business environment and its impact on IT - Awareness of the business impact, the need for and justification of
IT control - Ability to be practical and pragmatic - Ability to communicate and explain the context of need for control,
regulations etc. and the benefits of taking action - Analysis ability – root cause determination - Able to put theory into practice, be knowledgeable of real world
examples - Objectivity and independence - Coaching, mentoring and skills transfer competence so that others
learn control theory - Negotiating skills to persuade others
Figure 6.6.2
IT Governance Developing a Successful Governance Strategy
34 35
Developing Skills Demonstrating commitment by senior management for the importance of IT Governance and the value of being competent, removing cultural barriers and improving communications are all critical success factors for improving competence. Suggested techniques for improving skills by each group of role players are shown below:
Investors
Obtain external exper iences to help posi t ion and chal lenge internal act iv i t ies Obtain “360 degree feedback” Consider appoint ing Execut ive mentor ing advisors Obtain and read Execut ive br ief ings Seek non-execut ive chal lenges to the Board Consider external Execut ive IT awareness courses Foster cul tural change act iv i t ies Foster col laborat ive working and co- locat ion Enable job exchanges to improve awareness
Providers
Formal ise documentat ion of governance, standards and best pract ices When training, focus on special ised and relevant areas Organise internal events to raise awareness Rotate involvement in governance meet ings to improve understanding Use the resul ts of assessments and matur i ty model l ing to raise awareness
of governance issues, gaps in capabi l i ty, and impact on the business of IT weaknesses
Ensure management and control of IT is taken ser iously Manage the transfer of ski l ls f rom the special ists to the organisat ion
The sequence of events should be:
1. Training 2. Establ ish an environment which fosters governance 3 . Rol l out the processes and ski l ls 4. Measure compl iance with standards and reinforce
Controllers
Ski l ls development is of ten more about learning on the job than about t ra in ing courses
Understand the business, how IT af fects the business, the IT related business r isks, and why IT needs to be control led
Focus on Professional t ra in ing in IT Governance and consider cert i f icat ion in relevant ski l ls
Maintain cont inuing professional development Consider `sof t ` ski l ls t ra in ing to improve communicat ion and inf luencing ski l ls
Retention of Skills The most effective way to retain IT Governance skills is by establishing standards and practices within the organisation rather than only within individuals. This reduces reliance on key individuals and ensures sustainable processes are put into place. In addition:
At a l l levels there wi l l be a need to refresh ski l ls cont inual ly because of the changing nature of IT
Ski l ls t ransfer should always be encouraged, especial ly f rom experts to operat ional staf f
Providers must be valued for their governance ski l ls and encouraged to invest in them. This is especial ly t rue of external service providers.
Induct ion t ra in ing is required for new jo iners, especial ly those holding key posi t ions in control ler funct ions.
IT Governance Developing a Successful Governance Strategy
34 35
If there is institutionalised, sustained implementation of IT governance then the environment will support continual skills growth.
Verifying Skills The best way to verify competence is to include governance skills in the appraisal process. This should be based on performance on the job:
Clear job object ives and role def in i t ion for IT Governance IT Governance competencies required for role Review of competency performance
In addition, surveys can be carried out periodically to measure the level of awareness in key competencies. This technique can also be a valuable awareness raising and reinforcing technique. Another approach to verifying competence is to measure the maturity of IT Processes, focusing on competency aspects. The chart below shows generically how this could be done based on guidance from CobiT’s Management Guidelines (Figure 6.7).
6.8 When to source competence from outside Acquiring IT Governance competence from outside the organisation will be driven by two different objectives:
When i t is more cost-ef fect ive to outsource ski l ls that are not avai lable in-house When outside input of expert ise is benef ic ia l in i ts own r ight
However, if implementation of IT Governance is to be successful and sustainable, competence will have to be developed within the organisation, since management of IT must be owned within the organisation. In many organisations where all or significant parts of the IT service have been outsourced, responsibility and competence for controlling use of these services should still be retained internally. It is essential to retain sufficient skills internally to be able to sustain the business – and to understand and manage what is being outsourced.
6.9 Key learning points The following list of key points have been identified by the IMPACT IT Governance SIG and should be considered when developing IT Governance skills:
Ski l ls opt imisat ion Governance ski l ls are normal ly found at the top level , but are typical ly not
understood in the context of IT The appointment of an IT Governance manager and team should not be permanent
because governance pract ice should become business as usual
Risk Management6
Generic Maturity Model for Governance Competence (CobiT)
Understanding & Awareness Training & Communication Expertise
1 Initial/Ad Hoc Recognition Sporadic communication on issues
2 Repeatable but Intuitive Awareness Communication on the overall issues and needs
3 Defined Process Understanding of need to act Informal training supports individual initiatives
IT Governance expertise exists within the Process owner and team
4 Managed & Measurable Understand full requirements Formal training supports a managed programme
IT Governance expertise is monitored and measured outside the Process
5 Optimised Advanced, forward-looking, understanding
Training and communications support external best practices and use leading edge concepts
Use of external experts and industry leaders for guidance, comparison to best practices
Figure 6.7
IT Governance Developing a Successful Governance Strategy
36 37
People must understand why governance is important Governance ski l ls need to be transferred from the special ists to the organisat ion as
a whole The best approach to t ra in ing is learning by doing and being part of the process
The sequence of events should be:
1. Special ised training 2. Establ ish an environment which fosters governance 3. Rol l out the processes and ski l ls 4. Measure compl iance with standards and re-enforce
IT Governance Developing a Successful Governance Strategy
36 37
7 Supplier Governance
7.1 Why is Supplier Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 7.2 The customer’s role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 7.3 How best to select a supplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 7.4 The customer/supplier relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 7.5 Service management techniques and SLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 7.6 The supplier/outsourcing governance lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Every organisation relies on numerous suppliers to support their business and IT strategy. It is not unusual for external organisations to provide critical IT infrastructure (such as telecommunications networks, hosted data centres, and
software applications) used by critical business processes, and increasingly the trend is to outsource significant parts of the internal IT function.
Effective governance of IT suppliers is therefore a key component of IT Governance, to make sure that risks are managed and value is delivered from the investment in supplier products and services. Most organisations are highly dependent on a limited number of key suppliers, and so governance should be focused on those relationships with the greatest risk and investment. For supplier governance to be effective the role of the customer is crucial. The customer should take ownership of the whole transaction from defining requirements and selection all the way through to engagement, operation and termination. Even when the bulk of IT is outsourced, several key functions should be retained because they supply continuity for clients of IT, provide for the oversight of the outsourcer, are highly specific to the way the business operates, and are strategic to the organisation. To some extent, the mix will vary with the reason(s) for outsourcing and which functions have been outsourced. However, all organisations will need to retain some expertise in strategic functions, such as project oversight, architecture, planning, vendor management, and security.
One of the best ways to establish effective supplier governance is to focus on the relationship
The correct form of the relat ionship (commodity provis ion, ‘market relat ionship’ a l lows clear ly def inable boundar ies between cl ient and suppl ier, whi le the ‘partnership’ end of the scale requires an ongoing and close cooperat ion)
How both part ies engage with each other Commitment by both part ies at a senior level Responsibi l i ty and accountabi l i ty by senior decis ion makers on both s ides Speci f icat ion of governance responsibi l i t ies in a “governance schedule” wi th in the
contract
Try to create a win/win partnership so that both parties are motivated for success – beating down the supplier is generally seen as poor practice, while cooperation, considered openness and mutuality of benefit defines the basis for better working relationships.
Underpinning the customer/supplier relationship should be formal service level agreements which define objectives and measures in customer relevant terms, managed according to service management best practices such as ITIL.
7.1 Why is Supplier Governance important? “Because organisations are relying more and more on IT, management needs to be more aware of critical IT risks and whether they are being managed. Furthermore, if there is a lack of clarity and transparency when taking significant IT decisions, this can lead to reluctance to take risks and a failure to seize technology opportunities. There is a realisation that because IT is complex and has its own fast changing and unique conditions, the need to apply sound management disciplines and controls is even greater.” (IT Governance – The Business Case)
Most organisations are highly dependent on a limited number of key suppliers, and so governance should to be focused on those relationships with the greatest risk and investment. The outsourcing of a function or service is likely to be a major
Supplier Governance7
IT Governance Developing a Successful Governance Strategy
38 39
strategic decision which should be governed carefully. Outsourcing is also a huge global commercial business opportunity for the service providers who will compete fiercely for market share. In such a complex technical and commercial situation, proper governance is crucial to help avoid potential service failures and large financial losses.
7.2 The customer’s role For supplier governance to be effective, the role of the customer is crucial. The customer should take ownership of the whole transaction from defining requirements and selection all the way through to engagement, operation and termination. It is essential that what is outsourced by the customer is NOT its core competency as this is what defines what the organisation is, how customers perceive it and how it retains its position in the marketplace. Only under a limited set of circumstances, one example being technology catch-up, should core competencies be outsourced. The supplier is of course also a stakeholder and will want to ensure the relationship is properly managed, and that the financial and operational requirements are acceptable. It will be in the customer’s interest to balance the supplier’s needs with his own in order to arrive at a solution that provides reasonable incentives for the supplier while properly meeting the customer’s needs.
If the relationship is critical in support of the customer’s business strategy (which will be the case if significant outsourcing is planned, or if critical infrastructure needs to be supported), then the customer’s role in ensuring effective governance will be particularly important and should address:
Unclear buyer expectations 23%
Misaligned interests 15%
Poor Governance 13%
Not mutually beneficial 11%
Other 11%
Poor communication
11%
Provider's poor performance 8%
Poor cultural fit 5%
Buyer's multi-buyer environment
3%
Figure 7.1: Causes of outsourcing failures – source Outsourcing Center 2004
IT Governance Developing a Successful Governance Strategy
38 39
Discipl ine over managing the transact ion and transparency of the resul ts Independence from the suppl ier Accountabi l i ty and responsibi l i ty for key decis ions Increasing stakeholder value (both internal and for the suppl ier) Key governance steps at each stage, best def ined in a governance schedule in
the contract , and in a shared procedure manual where key responsibi l i t ies and escalat ion procedures are def ined.
How to be an effective customer
Organisation
Focus on what ’s cr i t ical Have the r ight capabi l i ty to manage IT suppl iers Ensure there are c lear roles and responsibi l i t ies on the customer ’s s ide of the
relat ionship Ensure there is an Execut ive level sponsor who wi l l be responsible and accountable
for a l l s igni f icant decis ions regarding key suppl iers Commit long-term Establ ish relat ionships at mult ip le levels Organise suppl iers according to cr i t ical i ty and roles
Technical
Manage technical IT issues to ensure conformance where necessary and compat ib i l i ty wi th in-house technical standards
Ensure al l re levant legal and regulatory requirements have been considered Standardise and commodit ise solut ions wherever possible Set real ist ic expectat ions regarding service del ivery Take t ime to understand product and service of fer ings Understand how your own IT assets may be af fected by supply of external products
or service Ensure there is good control of the internal environment af fected by the external
supply
Project Approach
Take care to manage al l staf f re lated issues Set up a co-ordinat ion commit tee of senior customer representat ives Make sure there is a process for both part ies to fo l low Bui ld into the requirements and contract p lans for t ransi t ion/ t ransformat ion f rom the
current state to an outsourced service Approach contracts and relat ionships in a balanced way ensur ing r isks have been
considered in the context of the value expected from the suppl ier Avoid the danger of mixed messages coming from di f ferent parts of the customer
organisat ion Make sure there is top-down management commitment to support a l l key decis ions
How to monitor and measure
1. Identify a limited range of meaningful and measurable key measures e.g.: Performance Financial Risks Compl iance Relat ionship Value added Del ivery
2. Take ownership and define and obtain agreement for all measures
3. Supplier senior management should:
Supplier Governance7
IT Governance Developing a Successful Governance Strategy
40 41
Provide data for a l l measures he is responsible for Monitor del ivery performance Agree remedial act ion wi th customer Commit remedial act ions
4. Customer IT service management should: Be responsible for monitor ing and report ing Pr ior i t ise and recommend act ions
5. Customer should: Provide customer sat isfact ion measurement data Consider benchmarking to other organisat ions and other services
What functions should be retained by the customer? (Reference Forrester Research “Functions to Retain when Outsourcing, July 2004)
Even when the bulk of IT is outsourced, several key functions should be retained because they supply continuity for clients of IT, provide for the oversight of the outsourcer, are highly specific to the way the business operates, and are strategic to the organisation. To some extent, the mix will vary with the reason for outsourcing. However, all organisations will need to retain some expertise in strategic functions.
7.3 How best to select a supplier The following steps are suggested:
1. Research the markets to ident i fy preferred suppl iers 2. Consider the s ize of suppl ier compared to your organisat ion and your
requirements 3. Consider the need to integrate several suppl iers 4. Do due di l igence reviews 5 . Prepare an ef fect ive RFP 6. See key people 7. Consider pi lots and pre-project t r ia ls 8. Check track record 9. Consider impact of any of f -shore s i tuat ions
7.4 The customer/supplier relationship One of the best ways to establish effective supplier governance is to focus on the relationship:
How both part ies engage with each other Commitment by both part ies at a senior level Responsibi l i ty and accountabi l i ty by senior decis ion makers on both s ides Speci f icat ion of governance responsibi l i t ies in a “governance schedule” wi th in the
contract
Make sure each party understands its role. Figure 7.4 summarises how IMPACT SIG members believe each group of stakeholders should focus in the customer/supplier relationship.
IT Governance Developing a Successful Governance Strategy
40 41
7.5 Service management techniques and SLAs Underpinning the customer/supplier relationship should be formal service level agreements, managed according to service management best practices. ITIL is recommended as the best source of guidance in this area, and the IMPACT SIG members recommended the following techniques:
Use a suppl ier governance framework to dr ive service management pract ices ( f igure 7.5).
Create a service management board to oversee service del ivery Create a service code of pract ice “how to engage” Adopt standard processes for managing the services Develop a common language and common understanding of service object ives Ensure there is a c lear def in i t ion of service scope Def ine the scope of the retained IT funct ion Maintain the contract as a resul t of service changes Create a pol icy and procedure manual for both part ies to fo l low Where possible def ine a service credi t regime – th is descr ibes how ‘overs and
unders’ on the service provis ion are handled without recourse to hard, f ixed penal t ies
Supplier Governance7 Party Stakeholder Focus
Customer
Investors
Define outsourcing and procurement strategy
Define supplier governance framework
Provide supplier with strategic direction
Approve contracts and any changes
Consider future business requirements
Define business objectives
Evaluate performance
Providers
Specify architecture
Define business requirements
Manage relationship
Manage projects
Monitor service
Controllers
Verify financial ROI
Manage contract
Assess and monitor risk
Ensure legal/regulatory compliance
Perform financial analysis
Ensure supplier service audit
Establish security policy
Supplier
Investors
Define business objectives
Protect supplier and customer investments
Commit resources for delivery
Define service strategy
Define governance framework
Providers Define services
Define service levels
Monitor service quality
Controllers Measure financial performance
Monitor risk management
Manage contracts
Figure 7.4
IT Governance Developing a Successful Governance Strategy
42 43
7.6 The supplier/outsourcing governance lifecycle The outsourcing lifecycle is useful in determining major points for governance throughout the contract, but more importantly ensures a common understanding of the major processes (Figure 7.6).
Figure 7.5
Figure 7.6
IT Governance Developing a Successful Governance Strategy
42 43
8 IT & Audit Working Together & Using CobiT
8.1 Introduction to CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 8.2 How is CobiT being used? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 8.3 What are the roles of IT and Audit for IT Governance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 8.4 How can IT and internal audit work better together? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
The growing interest in IT Governance and increasing pressure to deal with regulatory compliance (e.g. Sarbanes Oxley), and a continuing focus on security, has made IT management much more involved in risk management and control
activities. There is therefore a need for IT management to work more closely with IT auditors.
For many years there have been barriers between auditors (both internal and external) and auditees (IT functions and business units). This can be due to communication gaps, hidden checklists, and a failure to collaborate on control assessment and control improvement. A more effective approach requires better recognition of one another’s role and alignment to a mutually accepted and understood control framework, so that everyone is “on the same page”.
CobiT is an IT Control and Governance Framework that is increasingly being adopted by organisations around the world as a common reference model for IT Control. CobiT has historically been mostly used by IT auditors but the trend now is for IT management to use CobiT as a basis for IT process ownership, a reference model for good controls and as a way to integrate other best practices under one “umbrella” aligned to business needs. More advanced users make use of CobiT’s maturity modelling and metrics to measure performance and drive improvement initiatives.
As a consequence, many IT functions and IT service providers are adopting CobiT as part of their operational control framework.
8.1 Introduction to CobiT Business orientation is the main theme of CobiT. It is designed to be employed not only by users 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 organisation 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 organisation, 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.
IT Governance guidance is also provided in the CobiT framework. IT Governance provides the structure that links IT processes, IT resources and information to enterprise strategies and objectives. IT Governance integrates optimal ways of planning and organising, acquiring and implementing, delivering and supporting, and monitoring IT performance. IT Governance enables the enterprise to take full advantage of its information, thereby maximising benefits, capitalising on opportunities and gaining competitive advantage.
In addition, corresponding to each of the 34 high-level control objectives is an Audit Guideline to enable the review of IT processes against CobiT’s 318 recommended detailed control objectives to provide management assurance and/or advice for improvement.
IT & Audit Working Together & Using CobiT8
IT Governance Developing a Successful Governance Strategy
44 45
The Management Guidelines further enhances and enables enterprise management to deal more effectively with the needs and requirements of IT governance. The guidelines are action oriented and generic and provide management direction for getting the enterprise’s information and related processes under control, for monitoring achievement of organisational goals, for monitoring performance within each IT process and for benchmarking organisational achievement. CobiT’s Management Guidelines are generic and action oriented for the purpose of answering the following types of management questions: How far should we go, and is the cost justified by the benefit? What are the indicators of good performance? What are the critical success factors? What are the risks of not achieving our objectives? What do others do? How do we measure and compare?” (CobiT Framework 2000, www.itgi.org)
ISACA recognised in the early 1990’s that auditors, who had their own checklists for assessing IT controls, were talking a different language to business managers and IT practitioners. In response to this communication gap, CobiT was created as an IT control framework for business managers, IT managers and auditors, based on a generic set of IT processes meaningful to IT people. The best practices in CobiT are a common approach to good IT control – implemented by business and IT managers, and assessed on the same basis by auditors. Over the years CobiT has been developed as an open standard and is now increasingly being adopted as the control model for implementing and demonstrating effective IT Governance.
Today, as every organisation tries to deliver value from IT while managing an increasingly complex range of IT related risks, the effective use of best practices can help to avoid re-inventing wheels, optimise use of scarce IT resources, and reduce the occurrence of major IT risks such as:
Project fa i lures Wasted investments Secur i ty breaches System crashes Fai lures by service providers to understand and meet customer requirements
Due to its high level and broad coverage, and because it has been based on many existing practices, CobiT is often referred to as the “integrator”, bringing disparate practices under one “umbrella” and just as importantly, helping to link these various IT practices to business requirements.
8.2 How is CobiT being used? Although the long-term aim of CobiT was to be a common framework used by management and auditors, it began as an Audit reference. This was largely due to its origins within ISACA and its early adoption by ISACA members who are mostly from the computer audit profession. Over the years its usage has widened out into the IT community and nowadays this is the fastest growing user segment. Whereas auditors have been using CobiT mostly as a controls checklist, IT managers see it more as a “best practice” framework for performance measurement and improvement planning. With increasing regulatory requirements such as Sarbanes-Oxley in the US, both auditors and IT managers are adopting CobiT as the compliance framework for IT controls. The CobiT IT Process model has helped convey a view of IT understandable to business management, auditors and IT, and at the same time provide a basis for IT functions to organise themselves into a process structure with accountable process owners.
The maturity modelling and metrics concepts within CobiT are probably the most popular for IT managers, providing an easy and powerful technique for positioning IT control gaps in the context of business requirements. The profiles and scorecards that results are a powerful tool for communicating with senior management and demonstrating the reality of current IT capability in relation to what the business might have expected.
As organisations have adopted the CobiT approach, it has driven the professional Audit firms to follow similar approaches, and to integrate CobiT into their internal proprietary methodologies. This has helped to break down communication barriers and improve the mutual understanding of IT controls. There is also a trend among service providers to use CobiT and other best practices to improve their market image and quality of service. This is also helping to improve communication of control issues and make it easier to manage and audit IT activities against a commonly accepted basis. Because CobiT is open and independent of any specific vendor all parties can use it freely. It is not a “standard” as such but a “best practice” framework and set of guidance materials to be tailored for each specific situation.
There is currently a great deal of focus on the Sarbanes-Oxley Act in the US, and the reporting requirements that this legislation requires for Company Directors. Many companies are using CobiT as the framework for reporting the status of IT systems and controls, and consequently a massive CobiT-based controls documentation effort is underway. While Sarbanes- Oxley has been very useful for putting IT governance and control on the Board’s agenda, there is a danger that the effort will be limited to a documentation exercise to achieve compliance. The real value from any control evaluation, especially when based on CobiT, is the identification of control gaps and the implementation of a sustainable improvement programme. There
IT Governance Developing a Successful Governance Strategy
44 45
is an analogy with the Y2K experience in that Sarbanes-Oxley should not be a one off exercise but an ongoing programme for improving management control and establishing governance.
8.3 What are the roles of IT and Audit for IT Governance?
Role of IT Audit IT Governance is a management responsibi l i ty, and therefore not the sole
responsibi l i ty of an Audi t funct ion. The Audi t funct ion should remain independent, but th is can provide an excel lent posi t ion to inf luence and recommend change. Independence should not inhibi t provis ion of advice, so long as management take ful l responsibi l i ty and accountabi l i ty for implementat ion and operat ion of controls. Taking responsibi l i ty for enabl ing an IT Governance in i t iat ive or for in i t iat ing governance projects should not compromise Audi t .
IT Governance requires management commitment and ownership wi th in IT and the business in order to make i t happen. Audi t can then determine i f i t is happening, and provide assurance to the board.
When reviewing Governance, Audi t must do more than just ident i fy problems. They need to ident i fy root causes and make construct ive recommendat ions.
Audi t can test controls especial ly where control is cr i t ical and assurance is required. But increasingly there is a t rend for IT to “ test themselves” by performing sel f -assessments.
Audi t can play a part in set t ing standards, and providing control cr i ter ia and control benchmarks, part icular ly in respect of external regulat ion.
Given the speed of IT change and the high cost of development projects, i t makes sense to involve audi tors in projects. To be ef fect ive audi tors must:
- Be credible and conf ident to gain the respect of IT
- Not wai t unt i l the end of a phase to cr i t ique – but give pro-act ive guidance on what should be done
Role of IT IT has to be responsible for changing the cul ture of the IT organisat ion, for
managing the IT processes, and adopt ing a focus on controls. IT professionals of ten have a poor understanding of what controls are and why they
are needed. Educat ion in control pr inciples may be needed, and audi t can help wi th th is by working together wi th IT, and by providing training, workshops and staf f secondments.
A common framework and understanding is needed in order to ensure that IT Management is exercis ing IT Governance. Using a common framework for control such as CobiT, wi l l help to ensure that everyone is “on the same page”.
The CIO and Head of Internal Audi t should work together to dr ive change. IT should take a lead on governance; audi t can “sow the seeds”. I f IT (as so of ten) is in ` f i re f ight ing` mode i t is harder for them to dr ive
governance. Execut ive management may point to histor ic data as showing no problems- so
why should they worry about governance? However, the problems can usual ly be ident i f ied by IT digging into process fai lures – e.g. project delay and excess cost. IT management have to be conf ident of their posi t ion to draw at tent ion to internal weaknesses.
8.4 How can IT and internal audit work better together? Increasingly, control self-assessments are being performed by IT functions because it is more efficient than relying on limited IT audit resources, and more likely to motivate corrective action.
Typical examples using self-assessments are: Risk assessments Compl iance with speci f ic standards ( ISO 17799) Compl iance with regulatory requirements such as Sarbanes-Oxley Qual i ty of service assessments
IT & Audit Working Together & Using CobiT8
IT Governance Developing a Successful Governance Strategy
46 47
IT Process Matur i ty assessments (e.g. CobiT)
The methods used vary from formal schemes, perhaps based on IIA (Institute of Internal Auditors) or Internal Audit guidance to less formal approaches. All approaches can provide value e.g.:
Quest ionnaires – based on pol icy (e.g. secur i ty) How do you consider you have addressed each object ive?
Sel f cert i f icat ion by management e.g. Sarbanes-Oxley Face-to-face interviews and workshops Pre-def ined checkl ists
IT contribution Governance Phase Audit contribution
Common approach – culture, charter, communication and language, clear ownership
• Get CIO commitment. • Know your audience when explaining IT
Governance, controls adoption and CobiT. • Get ownership from the business side, using
business language, RAG charts and scorecards. Demonstrate strengths and weaknesses.
• Influence the business and the board about IT management issues (use ITGI Board Briefing) (www.itgi.org).
• Achieve a balance between regulation and improvement planning. Leverage regulations for positive effect.
• Coordinate with service providers who may be a trigger and may be using CobiT.
Building Awareness & Ownership
• Provide thought leadership. • Influence the Board and Audit Committee to take
issues seriously and mandate change. • Use objective and independent position to
recommend organisational change. • Don’t just make general recommendations – point
to root causes. • Provide independent view of the risk profile. • Regulations like Sarbanes-Oxley can be an
enabler of change – encourage response to be more than just a documentation exercise.
• Demonstrate benefits.
• Adopt a Framework e.g. CobiT. • Appoint process owners. • Liaise with 3rd parties and service providers. • Integrate existing and other best practices.
Framework Approaches
• Provide thought leadership on available techniques.
• Perform “open book” audits (no hidden checklists or issues).
• Ensure business and IT orientation to audit approach and recommendations.
• Share audit information and documentation. • Perform risk self assessment. • Perform business impact analysis with business
units. • Define business requirements for IT Governance
together with business units. • Understand impact of regulatory and compliance
issues. • Perform a maturity self assessment on critical IT
processes. • Understand risk appetite.
Focus
• Ensure scope alignment (audits versus governance).
• Identify key risks. • Analyse audit history and use to prioritise. • Share planning approach. • Identify key control weaknesses. • Define regulatory compliance requirements. • Coordinate with external auditors.
• Do internal/external benchmarking. • Internal/external analysis. • Perform controls self-assessments. • Perform detailed self maturity assessments.
Assess
• Provide assurance of IT self –assessments. • Provide positive statements where appropriate. • Provide independent control evaluations for critical
areas.
• Produce scorecards and RAG charts for IT performance in business terms.
• Provide explanations for deviations, successes and significant trends.
Scorecard
• Review and assure measures. • Provide “Audit scorecards” showing performance
against past audit reports. • Provide where appropriate independent
scorecards of IT performance. • Define HOW improvements can be made. • Create business case for changes. • Create implementation action plan. • Provide Project Control and QA. • Facilitate job rotation/secondees.
Improvement
• Advise on WHAT should be improved. • Provide training in controls. • Provide workshops to improve understanding. • Organise shared events. • Facilitate job rotation/secondees.
Figure 8.5
IT Governance Developing a Successful Governance Strategy
46 47
The effectiveness of a self-assessment depends on the quality, objectivity, skill and experience of the people performing the review. Using an alternative means of checking to supplement the questionnaire can help as can obtaining Internal audit input in an educating/reviewing role.
There are a number of constraints and challenges relating to self-assessments: Level of matur i ty Number/volume of test ing Rel iance on the resul ts
- Object iv i ty - Completeness and Rigour
Resources – IT is typical ly over loaded with day to day pressures Pol i t ical issues need to be addressed – how to get management buy- in, and there
may be a ret icence to ident i fy and quant i fy r isks Cul tural aspects should be considered – e.g. the need to balance posi t ive messages
with weaknesses Avoid rout ine t ick ing boxes exercises which are much less valuable
The following are some practical requirements for self-assessments: Indiv iduals performing assessments recognise accountabi l i ty There wi l l be a need framework/object ives/pol icy to sel f assess against (e.g. based
on CobiT) Wel l designed quest ionnaires – keep them simple wi th no ambigui ty, and examples
to aid interpretat ion Coaching/training may be needed i f using a web-based quest ionnaire Require support ing evidence to be documented Training may be needed on r isk ident i f icat ion, def in i t ion, and quant i f icat ion
IT & Audit Working Together & Using CobiT8
IT Governance Developing a Successful Governance Strategy
48 49
9 Information Security Governance
9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 9.2 What is information security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 9.3 Where to focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 9.4 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 9.5 Action planning and best practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Executive management has a responsibility to ensure that the organisation provides all users with a secure information systems environment. Sound security is fundamental to achieving this assurance.
Information systems can generate many direct and indirect benefits, and as many direct and indirect risks. These risks have led to a gap between the need to protect systems and the degree of protection applied. Although awareness of these security issues has increased significantly at board levels, most senior business managers are uncertain about actions they should take and rely heavily on technical advisors. Proper governance of security, like any other aspect of IT, requires top management to be more involved in setting direction and overseeing the management of risk. Faced with the fear of unknown risks, and uncertainty regarding the effectiveness of existing controls, top management naturally wonder where to focus attention and set priorities. A risk assessment is usually the best place to start. A complimentary approach is to focus on establishing a security baseline irrespective of the risks – i.e. ensure that all the basic measures are in place.
Managing investments in the implementation and operation of controls is critical, since security can be an expensive and time-consuming task, and experience has shown that large sums of money can be wasted on ineffective or inadequately implemented technical solutions. However, proving security ROI can be difficult since actual reductions in losses or incidents must be shown, and it is sometimes impossible to know if a risk has been prevented.
There is no doubt though, that the easiest way to demonstrate cash return is by showing the cost of incidents and wherever possible this should be done even if the examples are based on assumptions rather than actual figures. Increasingly, the benefits of good security are being recognised by management who understand that security is needed to enable e-business and that a reputation for good security can enhance customer loyalty, sales and ultimately share price. These benefits should be considered when building the business case for security investments. Given that IT security is a specialised topic and there is a shortage of skills, organisations will often seek support from third parties. Information security specialists can play a key role although governance and final decision-making must remain in-house.
9.1 Background “In a global information society, where information travels through cyberspace on a routine basis, the significance of information is widely accepted. In addition, information and the information systems and communications that deliver the information are truly pervasive throughout organisations—from the user’s platform to local and wide area networks to servers to mainframe computers. Accordingly, executive management has a responsibility to ensure that the organisation provides all users with a secure information systems environment. Furthermore, there is a need for organisations to protect themselves against the risks inherent with the use of information systems while simultaneously recognising the benefits that can accrue from having secure information systems. Thus, as dependence on information systems increases, security is universally recognised as a pervasive, critically needed, quality.” (International Federation of Accounts (IFAC) Statement on Managing Security of Information 1998)
Because new technology provides the potential for dramatically enhanced business performance, improved and demonstrated information security can add real value to the organisation by contributing to interaction with trading partners, closer customer relationships, improved competitive advantage and protected reputation. It can also enable new and easier ways to process electronic transactions and generate trust.” 5
The view of the IMPACT IT Governance SIG is that Information security concerns have increased due to:
5. Information Security Governance: Guidance for Boards of Directors and Executive Management, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
48 49
Technical complexi ty Hackers and virus spreaders Increasing ease of use, and the accessibi l i ty of IT systems Anywhere/anyt ime access
Although awareness of these security issues has increased significantly at board levels, most senior business managers are uncertain about actions they should take and rely heavily on technical advisors. Proper governance of security, like any other aspect of IT, requires top management to be more involved in setting direction and overseeing the management of risk.
It is essential therefore for executive management to understand why information security is important and take action to ensure that:
The importance of informat ion secur i ty is communicated to al l and that a pol icy exists to underpin act iv i t ies in a changing environment.
The ownership and responsibi l i ty for informat ion secur i ty is accepted by senior management in the business as wel l as in IT.
Everyone understands that secur i ty wi l l not be sat isf ied s imply by the appointment of a secur i ty manager – the secur i ty funct ion is there to assist management and secur i ty is ul t imately the responsibi l i ty of everyone.
Any shortage of ski l led resource in th is area is addressed, as i t may be impossible to retain al l the necessary ski l ls and funct ions in-house.
Responsibi l i ty for any secur i ty aspects of corporate compl iance is accepted by the Board.
Management concerns are focused on: Gaps – what and where are the s igni f icant and speci f ic weaknesses in secur i ty? Are these weaknesses being addressed? Are resources and money being wisely invested and are the r ight controls being
implemented in the areas most vulnerable to threat?
9.2 What is information security? One of the causes of poor information security and ineffective governance of information security is a misunderstanding of what it actually covers and how it should be addressed. The ITGI publication, Information Security Governance: Guidance for Boards of Directors and Executive Management, describes information security as follows:
“Security relates to the protection of valuable assets against loss, misuse, disclosure or damage. In this context, “valuable assets” are the information recorded on, processed by, stored in, shared by, transmitted or retrieved from an electronic medium. The information must be protected against harm from threats leading to different types of vulnerabilities such as loss, inaccessibility, alteration or wrongful disclosure. Threats include errors and omissions, fraud, accidents and intentional damage. The objective of information security is “protecting the interests of those relying on information, and the systems and communications that deliver the information, from harm resulting from failures of availability, confidentiality and integrity.
Information Security Governance9
Policy Development The security objective and core principles provide a framework for the first critical step for any organisation – developing a security policy.
Roles & Responsibilities For security to be effective, it is imperative that individual roles, responsibilities, and authority are clearly communicated and understood by all.
Design Once a policy has been approved by the governing body of the organisation and related roles and responsibilities assigned, it is necessary to develop a security and control framework that consists of standards, measures, practices, and procedures.
Implementation Once the design of the security standards, measures, practices, and procedures has been approved, the solution should be implemented on a timely basis, and then maintained.
Monitoring Monitoring measures need to be established to detect and ensure correction of security breaches, such that all actual and suspected breaches are promptly identified, investigated, and acted upon, and to ensure ongoing compliance with policy, standards, and minimum acceptable security practices.
Awareness, Training, & Education
Awareness of the need to protect information, training in the skills needed to operate information systems securely, and education in security measures and practices are of critical importance for the success of an organisation’s security program.
Figure 9.2
IT Governance Developing a Successful Governance Strategy
50 51
According to the IFAC guidance, the major activities associated with Information Security management relate to the items in Figure 9.2.
9.3 Where to focus Faced with the fear of unknown risks, and uncertainty regarding the effectiveness of existing controls, top management naturally wonder where to focus attention and set priorities. A risk assessment is usually the best place to start and this should be based on analysis of the likelihood of different threats, vulnerability and impact. Consideration of the impact of security threats should always be the responsibility of business management, who should ultimately sign-off acceptance of the risk management plan. In practice, this is an area where the business needs to be more involved.
It will be helpful if the risk assessment can be converted to a financial value derived from the impact – even if this is only approximate and based on rough estimates or scales – since decisions to improve security will usually be made based on financial parameters.
A complimentary approach is to focus on establishing a security baseline irrespective of the risks – i.e. ensure that all the basic measures are in place. This can be based on standard guidance such as the ISO17799 (www.iso.org) standard or freely available guidance such as the CobiT Security Baseline (www.itgi.org). A key element of this approach is to create security within the infrastructure, rather than on a piecemeal basis.
9.4 Roles and Responsibilities “Executive management, information systems security professionals, data owners, process owners, technology providers, users, and information systems auditors all have roles and responsibilities in ensuring the effectiveness of information security. Due diligence must be exercised by all individuals involved in the management, use, design, development, maintenance, operation, or monitoring of information systems.” (International Federation of Accounts (IFAC) Statement on Managing Security of Information, 1998)
“Too often information security has been dealt with as a technology issue only, with little consideration given to enterprise priorities and requirements. Responsibility for governing and managing the improvement of security has consequently been limited to operational and technical managers.
However, for information security to be properly addressed, greater involvement of boards of directors, executive management and business process owners is required. For information security to be properly implemented, skilled resources such as information systems auditors, security professionals and technology providers need to be utilised. All interested parties should be involved in the process.” 6
Specific roles: A Forum or Council should be established to set policy, ensure that consensus is reached on where security investments should be made, and for approving and overseeing execution of the risk management plan. The Forum should share knowledge of IT and risks, be focused on business objectives not technical solutions and include representatives from key business units, IT, internal audit and outsource suppliers. It should report into a governance board (or group IT board).
An IT Security Manager should be in place as an advisor to management and the project owner of security action plan. However, care must be taken to avoid implying that security has now been dealt with by hiring such a person (when it is everyone’s responsibility) or that this role relieves top management of their overall governance responsibilities. The role can be part time and is often supported by external advisors. It is often part of a Risk Management function.
An Operational Team will be needed to maintain and monitor security processes and operate administrative procedures. This is usually a technical function and it is increasingly being outsourced.
The Audit Function plays a key independent role in monitoring and assessing the adequacy of security within the organisation.
A useful approach to improving the understanding, awareness and ownership of security within the business is to appoint Information Security Coordinators.
It is critical to influence the Investors, Providers & Controllers positively so that they understand the objectives and benefits of IT Governance and are able to communicate consistently to each other and within their groups. The table below
6. Information Security Governance: Guidance for Boards of Directors and Executive Management, the IT Governance Institute®.
IT Governance Developing a Successful Governance Strategy
50 51
summarises how IMPACT SIG members believe each group of stakeholders should focus on their security responsibilities (Figure 9.4).
Third party security providers Given that IT security is a specialised topic and there is a shortage of skills, organisations will often seek support from third parties.
Information security specialists can play a key advisory role although governance and final decision-making must remain in-house. There is also an opportunity for cost reduction compared with permanent in-house staff. Examples of outsourced security activities include:
Test ing (e.g. fo l lowing patches) Vulnerabi l i ty test ing (note: Penetrat ion test ing must be performed with care as i t
may crash the system) Incident management
Special care should be taken when dealing with outsourced suppliers: Contractors need to be vetted for secur i ty purposes Suppl iers do have a responsibi l i ty to manage secur i ty wi th in their own act iv i t ies
– make sure th is happens Al though the suppl ier has to be trusted to carry out checks, the c l ient must ensure
that the necessary checks are in place Regulat ions such as Sarbanes-Oxley requires that governance responsibi l i ty
remains in-house
Information Security Governance9
Who needs to be involved?
Investors Providers Controllers • The Board • IT Council/Management Team • Senior business unit managers e.g. key
customers of IT services • Business Partners • External investors/shareholders – as part
of corporate governance
• Project and change managers (IT and Business)
• Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. Business sponsors,
Project champions • Relationship managers and internal
communications teams • Suppliers (especially outsourced service
providers) • Contract and procurement management • Peripheral players/influencers/Policy
owners e.g. HR, Facilities Management, Legal
• Internal audit and external audit (due diligence)
• External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and
business managers – reviewers of benefits/ROI
• Post investment appraisal/Post project review teams
Key Security Responsibilities • Risk sign-off • Own the business case • Set policy • Define expectations and requirements • Ensure legal and regulatory compliance • Review performance • Monitor delivery • Quantify impact of risk • Challenge the risk management plan • Approve proposals and metrics • Prioritise actions and investments • Supply necessary resources • Set culture and environment
• Risk analysis • Design and implementation • Creation of business cases – cost and
solution • Security operations • Security administration • Monitoring security incidents • Education and training (both IT and HR) • Creation and maintenance of scorecards
for performance measurement
• Understand impact of regulations • Monitor adequacy and performance of
controls (assessments and audits) • Test actual performance of controls • Monitor performance (execution of
improvements) • Provide independent assurance to
management
Figure 9.4
IT Governance Developing a Successful Governance Strategy
52 53
9.5 Action planning and best practice IMPACT SIG members suggest the following action steps be considered:
1. Classify objectives and actions into technical and non-technical areas 2. Ensure that an effective security policy is in place 3. Establish a security baseline 4. Cover key vulnerabilities 5. Communicate management concerns for security to ensure staff awareness 6. Focus on changes – evaluate and test for security exposures 7. Ensure that Board presentations emphasise security as an enabler and not as a disabler
IT Governance Developing a Successful Governance Strategy
52 53
10 Legal & Regulatory Aspects of IT Governance
10.1 Legal and regulatory factors affecting IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 10.2 Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 10.3 Best approach to compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 10.4 What IT has to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 10.5 Dealing with third parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 10.6 Critical success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
In recent years there has been a general increase in the number of regulations affecting the use of IT and also the number of situations where legal measures need to be considered. This is due to the need to guard against a wide range of new IT
related risks and from a general increase in corporate regulations.
The impact of not taking sufficient care over legal or regulatory requirements can be considerable including:
Loss of reputat ion Inabi l i ty to t rade Financial penal t ies and losses Loss of compet i t ive advantage Loss of opportuni ty
On the other hand the benefit of complying with regulatory requirements and using legal measures to protect commercial interests can be considerable, including:
General improvement in overal l control of IT related act iv i t ies Reduced losses and administrat ive costs More ef f ic ient and ef fect ive negot iat ion of commercial t ransact ions A greater abi l i ty and conf idence to take r isks – because senior management feel
more in control
There are a wide range of laws and regulations, some specific to industry sectors that can have an impact on IT. Every organisation must identify the specific regulations affecting them and respond accordingly, and ensure that the roles and responsibilities for understanding legal and regulatory matters are properly defined for each group of stakeholder so that each group can apply its specific expertise effectively. External advice must be sought whenever the issues are sufficiently risky or complex.
Every organisation relies on a growing number of third parties for support of IT services. From a legal and regulatory perspective this means that there is potentially a complex hierarchy of responsibilities that combine to meet the legal and regulatory needs of the customer. Ultimately it is the customer’s responsibility to ensure that all the right controls are in place with any third party that is relied upon for legal and regulatory compliance.
10.1 Legal and regulatory factors affecting IT Governance The recent increase in the number of regulations affecting the use of IT is due to a number of factors, including:
Legal & Regulatory Aspects of IT Governance10
IT Governance Developing a Successful Governance Strategy
54 55
A greater interest by regulators in the operat ions of a l l organisat ions caused by major corporate f inancial fa i lures and scandals, which is resul t ing in regulat ions l ike the US Sarbanes- Oxley Act forc ing Boards of Directors to express opinions about their systems of control .
Concerns about secur i ty and pr ivacy fueled by the overal l increase in use of computers and networks and the impact of the Internet.
Laws to protect personal informat ion and i ts potent ia l misuse in electronic form.
A growth in the use of computer systems and networks for cr iminal act iv i ty and terror ism, including viruses, hacking, money launder ing and pornography etc.
A growth in complex contractual re lat ionships for IT services and products (outsourcing, managed services, product l icenses etc.) .
The growth in al l forms of e lectronic media and the potent ia l for misuse of valuable informat ion assets, resul t ing in copyr ight and intel lectual property issues of concern to both vendors and users.
What might appear to be an initial regulatory burden can become an opportunity to transform to better managed practices if the rules are used positively and applied productively. Corporate regulations like the Sarbanes-Oxley Act can be just a minimalist compliance procedure with no potential benefit to the business or be used as an opportunity to invest in better IT controls. Compliance with IT-related legal and regulatory requirements and the effective use of legal contracts are clearly part of the effective control and oversight of IT activities by senior management and therefore key aspects of IT Governance.
There are a wide range of laws and regulations, some specific to industry sectors, that can have an impact on IT. Every organisation must identify the specific regulations affecting them and respond accordingly.
The IMPACT SIG has identified the following areas that ought to be considered:
Personal data and pr ivacy Corporate Governance, f inancial report ing, stock market
requirements Money launder ing, and other cr iminal acts Intel lectual Property, Trademarks and Copyr ight Electronic communicat ion, s ignatures etc. Electronic commerce Emai l monitor ing, appropr iate use and conf ident ia l i ty Emai l defamat ion Document and record retent ion IT products and services contracts Sector speci f ic regulat ions e.g. f inancial , heal th, pharmaceut ical
etc.
10.2 Roles and Responsibilities Dealing with legal and regulatory requirements and knowing how best to use legal contracts can be challenging for IT experts who are not knowledgeable about legal matters, and for business managers who may not appreciate all the legal risks and issues associated with the use of advanced technology.
Organisations should therefore ensure that the roles and responsibilities for understanding legal and regulatory matters are properly defined for each group of stakeholder so that each group can apply its specific expertise effectively. External advice must be sought whenever the issues are sufficiently risky or complex.
IT Governance Developing a Successful Governance Strategy
54 55
10.3 Best approach to compliance Ideally organisations should deal with legal and regulatory requirements on a “business as usual” basis instead of reacting on a case-by-case basis.
In practice, it is recommended that a framework for dealing with legal and regulatory issues be established. Because IT is fast changing and new regulations are also emerging, any such framework must be flexible and responsive to new requirements.
Legal & Regulatory Aspects of IT Governance10 Who needs to be involved?
Investors Providers Controllers
• The Board • IT Council/Management Team • Senior business unit managers e.g. key
customers of IT services • Business Partners • External investors/shareholders – as part of
corporate governance
• Project and change managers (IT and Business) • Project and change managers (IT and
Business) • Programme managers • Business managers and users • Technical delivery and support teams • Key players e.g. Business sponsors, Project
champions • Relationship managers and internal
communications teams • Suppliers (especially outsourced service
providers) • Contract and procurement management • Peripheral players/influencers/Policy owners
e.g. HR, Facilities Management, Legal
• Internal audit and external audit (due diligence) • External regulators • Corporate governance coordinator • Risk managers • Compliance – regulatory and internal • Finance/Project Managers/IT and business
managers – reviewers of benefits/ROI • Post investment appraisal/Post project
review teams
Legal and Regulatory Responsibilities
• Understand requirements (what regulations are to be complied with)
• Set the mandate • Set priorities and expectations • Establish and ensure the expected degree of
compliance • Based on advice concerning risk and cost: • Assess impact on business • Provide resource and funding to ensure
issues are addressed • Define who is accountable • Obtain internal or external assurance as
required that issues have been addressed and controls established
• Monitor and evaluate compliance programmes and significant commercial contracts
• Sign off specific compliance programmes • Provide approvals when required for
significant legal or regulatory decisions
• Advise on IT related technical and commercial risks that could impact legal and regulatory requirements
• Provide proposals and business cases for legal and regulatory programmes, projects or action plans
• Formulate solutions for compliance or commercial contracts
• Identify best practices for ongoing good control of legal and regulatory requirements
• Exploit technology and tools where appropriate for ensuring compliance (e.g. asset registers)
• Execution of compliance and contractual processes, and operation of elated controls
• Provide compliance framework to ensure a sustainable “business as usual” approach to compliance
• Provide evidence of compliance • Provide information relating to the cost of
compliance and also cost of any incidents • Evaluate impact on business environment
together with business units • Ensure vendors, service providers, and
subcontractors are involved properly and integrated within the overall compliance approach
• Maintain awareness of current and emerging laws, and regulations affecting IT to assess their impact on the organisation’s business
• Develop an understanding of their impact on the organisation and advise accordingly on “what is needed” - not necessarily “how”
• Monitor adequacy of controls and compliance processes
• Monitor the business and IT functions for performance in meeting legal and regulatory requirements and report back to management with advice regarding any shortcomings
• Provide independent assurance to management that adequate controls are in place to deal with legal and regulatory requirements
Table 10.2
IT Governance Developing a Successful Governance Strategy
56 57
Figure 10.3 illustrates a common problem when new regulatory requirements are imposed. To be effectively handled the decisions concerning the regulation should be taken at the level at which business objectives are set and within the group or business risk framework. This is the necessary level at which priorities can be determined and the standards framework can be applied.
However, as illustrated, a special programme is frequently set up outside the remit of existing standards and governance in the hope that the new regulatory environment can be incorporated. This is usually unsuccessful or inefficient because outside of existing governance it is very difficult to allocate and establish responsibilities for monitoring and testing. Similarly, there can be no clear prioritisation or co-ordination among different regulatory requirements. Conversely, when the left-hand route is followed and a new regulation comes into force, it is possible to identify where there are already procedures in place that enable the new requirements to be met.
For complex IT environments, the importance of the framework is emphasised by the need to understand which standards affect which systems. Then it becomes possible to address all the relevant systems when standards have to change:
Consider regulatory issues together Do not set up separate projects which may conf l ic t wi th the standard approach Decis ion making must rest wi th the business in terms of the extent and nature of
compl iance
10.4 What IT has to do Historically, most IT people did not think about compliance- except in terms of good practice, because regulations rarely impacted the technical environment. Gradually this has changed, first with IT specific legislation like the Data Protection act, and most recently by the realisation that corporate level regulations like Sarbanes-Oxley must be inextricably linked to the IT systems because corporate information and financial reporting has become so automated.
Figure 10.3
IT Governance Developing a Successful Governance Strategy
56 57
In addition, due to the very significant cost of IT investments, and the complexity of customer and supplier relationships, legal contracts for IT services are being given much more careful attention. These contracts in turn demand greater controls be demonstrated by the parties to the contract, over many issues such as security, intellectual property, service availability, ownership of deliverables, support of products etc.
As a consequence, IT service providers, vendors, and internal IT functions are all realising that they must be better organised from a control and compliance perspective. It is only a relatively recent realisation that IT related controls should be documented and monitored by IT functions, increasingly driven by regulatory pressure.
Business objectives and processes should drive the system of internal control and therefore the documentation process. The flow should be:
For an efficient and effective compliance process, the documentation should be in a language that auditors would use, and therefore it is best to work with the audit community and adopt a common language and approach such as CobiT.
IT functions increasingly need to be more involved in legal and regulatory requirements and should:
Work wi th the business users and r isk management groups to ident i fy cr i t ical systems and compl iance pr ior i t ies.
Document archi tectures so that the overal l environment is understood on a cont inuous basis.
Def ine processes in IT in a logical wel l ordered fashion, meaningful to audi tors and management (e.g. based on CobiT).
Appoint process owners so there is accountabi l i ty and responsibi l i ty. Understand control concepts, the need for IT controls, and how they relate to
business level controls. Document these processes and controls (especial ly for compl iance cr i t ical systems),
and maintain the documentat ion as changes occur.
Legal & Regulatory Aspects of IT Governance10
Figure 10.4
IT Governance Developing a Successful Governance Strategy
58 59
Standardise wherever possible to avoid dupl icat ion of ef for t . Maintain evidence of controls being exercised to be better able to demonstrate
compl iance. Generate business benef i ts f rom the control and compl iance projects by performing
gap analyses to dr ive improvements and ef f ic iencies as wel l as bui ld ing good controls.
Consider the whole infrastructure rather than tackl ing i tems on a piecemeal basis. Be responsible for d i l igent procurement and proper control and management of th i rd
part ies.
To achieve these objectives:
IT should seek advice f rom HR, Legal , and Audi t , and i f necessary external experts.
Adopt standard approaches and best pract ices – don’ t at tempt to reinvent the wheel as i t wastes t ime and makes working with partners and audi tors much less ef fect ive (compare with account ing- standard procedures are essent ia l ) .
Bui ld in the need for th i rd party test ing as required.
10.5 Dealing with third parties Every organisation relies on a growing number of third parties for support of IT services. From a legal and regulatory perspective this means that there is potentially a complex hierarchy of responsibilities that combine to meet the legal and regulatory needs of the customer. Ultimately it is the customer’s responsibility to ensure that all the right controls are in place with any third party that is relied upon for legal and regulatory compliance.
Conversely, service providers have their own corporate governance agenda, combined with the pressures of their business models – usually to provide a better service at a lower cost than the customer had previously experienced:
They have to work wi th di f fer ing governance models of business partners and cl ients.
In theory they might use a standard model across al l but in pract ice th is is unl ikely.
- Large cl ients, in part icular, are unwi l l ing to change their own model. - Cl ients cannot be obl iged to do business in a way speci f ied by the provider.
The outsourcer or provider may not ensure full coverage of legal and regulatory requirements:
The customer may go to the provider and speci fy what is required or provide a quest ionnaire, but the provider may st i l l not have taken act ion himsel f or know what is required.
People who negot iate outsourcing contracts are usual ly at a commercial business level , not dr iven by controls and compl iance issues.
In order for both sides to be clear on responsibilities it is essential that sufficient in-house capability is retained. Most organisations actually get more rigour when they outsource but most contracts are built around existing operations with all their limitations. The onus should be on the provider to spell out the risks – but the provider will not improve controls unless paid to do so, or can see a commercial benefit in making the necessary investment.
Legally there is a standard reasonable expectation of basic service, and ultimately it is a question of negligence if controls were not operated properly.
The provider is unlikely to provide a higher level of control in specific situations (such as security) than the client had originally operated himself – but must have nevertheless an adequate set of controls. Special requirements such as vulnerability testing will not normally be seen as part of a contract unless formally requested and paid for.
IT Governance Developing a Successful Governance Strategy
58 59
10.6 Critical success factors The IMPACT SIG identified the following success factors to enable effective ongoing legal and regulatory compliance and proper control of legal contracts:
Establ ish the r ight cul ture to encourage di l igence and good controls Communicat ion throughout the organisat ion based on a Board level mandate is
essent ia l to make sure everyone takes the issues ser iously and uni formly Involve the r ight people as advisors but do not abdicate responsibi l i ty Retaining responsibi l i ty for control and compl iance when using service providers Standardisat ion and a common approach is the most ef fect ive and ef f ic ient way to
meet compl iance requirements Use frameworks and accepted compl iance models especial ly those accepted by
audi tors Integrate compl iance object ives into the IT strategy Ensure management are act ively involved – not just performing a s ign-of f at the
end - Set the tone at the top
Inst i tut ional ise compl iance behaviour - Engage the governance and r isk management groups ( those who own the
framework) as soon as possible - Provide a posi t ive spin – good controls can be very benef ic ia l - Make compl iance normal business pract ice rather than a project
Make compl iance meaningful and relevant - Translate into normal language - Explain business context - Carry out awareness training
Establ ish mechanisms for evidence and documentat ion Establ ish metr ics for monitor ing performance Create incent ives and/or penal t ies as part of personal object ives Do regular compl iance checking and tests Do regular review of r isks ( include 3rd part ies) Have good incident management procedures to learn f rom legal and regulatory
incidents
Legal & Regulatory Aspects of IT Governance10
IT Governance Developing a Successful Governance Strategy
60 61
11 Architecture Governance
11.1 Why is Architecture Governance important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 11.2 What are the objectives of Architecture Governance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Given the complexity and fast-changing nature of IT, architectures are important for defining technical direction, captured in a formal design that will support evolution and change, based on generally accepted standards as well as specific
design standards. Architecture governance is therefore to do with ensuring that the principles of architectures are properly applied to the design and maintenance of information systems, meeting technical design standards as well as the business purpose and strategic objectives for IT.
There are generally three overall end goals with respect to architecture governance: Business and IT Al ignment ( f i t for purpose) Risk Management (reduced l ikel ihood of design fai lures) Resource Management (cost ef fect iveness and value for money)
The process of determining technological direction via an IT Architecture satisfies the business requirement to take advantage of available and emerging technology to drive and make possible the business strategy. This is enabled by creation and maintenance of a technological infrastructure plan that sets and manages clear and realistic expectations and standards, of what technology can offer in terms of products, services and delivery mechanisms. Given the significant amount of outsourcing of IT services, the effective governance of architectures in these situations is a key consideration. The business strategy may depend on an effective IT architecture, but who defines the architecture in the outsourced situation? The customer should always take control of his own requirements including architectural decisions even if the provider offers existing solutions and approaches. Senior management may assume that providers will develop technology to improve productivity – this is not always the case. A capability for setting the direction for technology improvement should be retained in house and often contracts will call for customers to control their own technical direction. Cost will usually be the driving factor in contractual arrangements – who will pay for architectural upgrades?
The group identified the following critical success factors for achieving architectural governance: Ensure that the Archi tecture process and i ts governance is adequately funded Ensure good communicat ions among al l the groups concerned Al ign the archi tecture wi th the business strategy and the cul ture of the
organisat ion Recognise that persuasion is always needed for compl iance and that th is can be
enhanced by act ive project involvement, technical consul tancy, provis ion of readi ly- avai lable, cost-ef fect ive tool-k i ts and components
Share al l ar tefacts wi th outsource providers
11.1 Why is Architecture Governance important? Architecture (in Greek αρχή = first and τέχνη = craftsmanship) is the art and science of designing structures. In the context of computers, the term architecture is used to describe the technical design and interoperability of components that together make up the information system i.e. hardware, software and network components.
Given the complexity and fast-changing nature of IT, architectures are important for defining technical direction, captured in a formal design that will support evolution and change, based on generally accepted standards as well as specific design standards. There is an analogy with the original use of architectures for defining the design of buildings – providing the blueprint that demonstrates what the end product should look like, that it is formed on a solid foundation, that it is built according to defined design standards, and that it meets the purpose for which it was intended.
Architecture governance is therefore to do with ensuring that the principles of architectures are properly applied to the design and maintenance of information systems, meeting technical design standards as well as the business purpose and strategic objectives for IT. The IT Governance and Technical Architecture SIG members believe that in many organisations the
IT Governance Developing a Successful Governance Strategy
60 61
challenge is to commit to a properly funded and business driven architectural approach. Often it is treated as too technical an activity, with inadequate or insufficiently skilled resources, and with limited business and top management direction.
The group assessed the maturity of Architectural activities based on the CobiT® maturity model (see Appendix). This assesses maturity on a scale from 0 to 5. An analysis of the maturity level of the organisations represented showed the following:
Current matur i ty ranged from 1+ to 4 - In larger organisat ions there was a spread (e.g. f rom 2 to 4) across the di f ferent
parts of the organisat ion - The lowest matur i ty was in a business where IT had recent ly been outsourced
The matur i ty level aspired to was between 3+ and 4 - No organisat ion saw level 5 as necessary
11.2 What are the objectives of Architecture Governance? The definitions CobiT® provides for setting technical direction were used to help define the purpose of Architecture Governance:
The process of determining technological direction via an IT Architecture satisfies the business requirement to take advantage of available and emerging technology to drive and make possible the business strategy. This is enabled by creation and maintenance of a technological infrastructure plan that sets and manages clear and realistic expectations and standards of what technology can offer in terms of products, services and delivery mechanisms.
It considers: Capabi l i ty of current infrastructure Monitor ing technology developments v ia rel iable sources Conduct ing proof-of-concepts Risk, constraints and opportuni t ies Acquis i t ion plans Migrat ion strategy and roadmaps Vendor relat ionships Independent technology reassessment Hardware and software pr ice/performance changes
Covering the following activities: Technological infrastructure planning Monitor ing future t rends and regulat ions Assessing technological cont ingency Planning hardware and software acquis i t ions Def in ing technology standards
The group believe that measurement of these activities is difficult and may often rely on perception of trends.
CobiT® suggests focusing on these key measurable outcomes: Number of technology solut ions that are not al igned with the business strategy Percent of non-compl iant technology projects planned Number of non-compat ib le technologies and plat forms Decreased number of technology plat forms to maintain Reduced appl icat ions deployment ef for t and t ime-to-market Increased interoperabi l i ty between systems and appl icat ions
And these performance measures: Percent of IT budget assigned to technology infrastructure and research Number of months s ince the last technology infrastructure review Business funct ions’ sat isfact ion wi th the t imely ident i f icat ion and analysis of
technological opportuni t ies Percent of technological domains wi th in the technology infrastructure plan that have
sub-plans speci fy ing current state, v is ion state and implementat ion roadmaps Average length of t ime between the ident i f icat ion of potent ia l ly re levant new
technology and the decis ion as to what to do with that technology
The Open Group (www.opengroup.org) defines an Architecture Governance Framework which covers:
Architecture Governance11
IT Governance Developing a Successful Governance Strategy
62 63
Governance processes Pol icy management Compl iance assessments Dispensat ion procedures Monitor ing and report ing Business control (compl iance with the organisat ion’s business pol ic ies) Environment management ( the physical and logical reposi tory management) and
governance environment (administrat ive processes).
Given the significant amount of outsourcing of IT services, the effective governance of architectures in these situations is a key consideration. The business strategy may depend on an effective IT architecture, but who defines the architecture in the outsourced situation? The customer should always take control of his own requirements including architectural decisions even if the provider offers existing solutions and approaches. Unfortunately, weaknesses and bad practices in outsourcing arrangements can lead to architectural misunderstandings or restrictions that can be costly or damaging to business performance. On the other hand the provider may enable a customer to adopt a proven, reliable architecture at much lower cost and in much faster timescales than agreeing and developing a solution in house (for example hosting services).
Senior management may assume that providers will develop technology to improve productivity – this is not always the case. A capability for setting the direction for technology improvement should be retained in house and often contracts will call for customers to control their own technical direction. Cost will usually be the driving factor in contractual arrangements – who will pay for architectural upgrades? Even when improvements are called for by the contract, they may not be provided.
IT Governance Developing a Successful Governance Strategy
62 63
12 Managing the IT investment
12.1 Why is managing the IT investment important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 12.2 Portfolio management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 12.3 Benefits management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 12.4 Measuring investment performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 12.5 Improving value delivery and ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 12.6 Measuring and controlling IT operational costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 12.7 Project risk managment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Ensuring that value is obtained from investment in information technology is an essential component of IT governance. No investment, whether IT-related or not, should be undertaken without full knowledge of the expected cost and the
anticipated return. Expected return should always be related to risk as, given the higher likelihood of failure, high-risk projects should always have an anticipation of a higher return. Ensuring that the right projects are approved in the first place implies a need for accurate predictive costing of the total project across its lifetime and robust predictions of the potential return, including quantification of the direct and indirect benefits. To ensure that the total process works and becomes part of the culture of the organisation, it is essential to establish proper tracking mechanisms to determine the actual value delivered and enable accountability.
Given the volatility of a portfolio of IT-related business projects, it is essential to embed active portfolio management into the organisation to maximise value creation and minimise the risk of value destruction. As with any aspect of IT governance, the process needs visibility, leadership and commitment from the top.
12.1 Why is managing the IT investment important? “The basic principles of IT value are the on-time and within-budget delivery of appropriate quality, which achieves the benefits that were promised. In business terms, this is often translated into: competitive advantage, elapsed time for order/service fulfilment, customer satisfaction, customer wait time, employee productivity and profitability. Several of these elements are either subjective or difficult to measure, something all stakeholders need to understand. Often, top management and boards fear to start major IT investments because of the size of investment and the uncertainty of the outcome. For effective IT value delivery to be achieved, both the actual costs and the return on investment need to be managed” (ITGI Board Briefing V2 2004).
20% of all expenditure on IT is wasted7, representing, on a global basis, annual value destruction of US$500bn according to a 2002 Gartner paper (Gartner, ‘The Elusive Business Value of IT’, August 2002). It is then no surprise that there is an increasing demand from boards and executive management for generally accepted guidelines for investment decision-making and benefit realisation. While particularly applicable to IT-enabled business investments, where IT is a means to an end, the need is equally applicable to all investment decisions. In the case of IT, the ‘’end” is to contribute to the process of value creation in the enterprise.
IT-enabled business investments, when managed well within an effective governance framework, provide organisations with significant opportunities to create value. Without effective governance and good management, they provide an equally significant opportunity to destroy value. Horror stories abound around the value destruction suffered by major organisations through the failed implementation of IT enabled business investments. Nike reportedly lost more than US$200m through difficulties experienced in implementing its supply chain software, failures in IT enabled logistics systems at MFI and Sainsbury in the UK led to multi-million pound write-offs, profit warnings and erosion of share price. Other organisations have suffered in a similar fashion.
On the other hand, many successful organisations have created value through selection of the right investments, and successfully managing them through implementation to realising the expected value. Examples include IBM who reportedly was able to save more than US$12bn over two years by linking disparate pieces of its supply chain and thereby reducing inventory levels, and Southwest Airlines who were able to reduce procurement costs and increase service levels through their supply chain transformation project.
Managing the IT Investment12
7. IT Governance Institute® research on IT Value.
IT Governance Developing a Successful Governance Strategy
64 65
The message is clear. IT-enabled business investments can bring huge rewards with the right governance and management processes and full commitment from all management levels. The process for managing IT investments can be summarised as developing, implementing, operating and maintaining financial controls over IT investments and expenditures in line with the IT strategic and tactical plans. Essential elements in this process are benefit and cost justification, budget ownership and accountability and control of actual spending. The process should enable the effective and efficient use of IT resources and provides transparency and accountability into the benefit realisation, total cost of ownership and return on investment of IT.
The role of IT Councils Organisations should establish an IT Council (or Strategy Committee or similar group) at board level to ensure that IT governance, as part of corporate governance, is adequately addressed. This committee reviews major investments on behalf of the full board and advises on strategic direction. Below this committee an IT steering committee (or equivalent) should be established to oversee the IT function and its activities and developing IT plans. The committee should determine prioritisation of IT resources and projects in line with business needs and should be composed of executive management, business and IT representatives. This committee structure will provide the oversight and direction of IT investments, ensuring accountability at senior level and proper involvement of all stakeholders.
12.2 Portfolio management Portfolio management is a good practice for coordinating any group of investments and can be effectively applied to IT investments. It consists of:
Working with the business to establ ish and maintain a port fo l io of new and exist ing IT-enabled investment programmes that are needed to achieve business goals and which, together wi th exist ing IT services and assets, form the basis of the IT budget.
Bui ld ing a port fo l io that recognises that there wi l l be a var iety of categor ies of investment which wi l l d i f fer both in complexi ty and in the degree of f reedom in al locat ing funds.
Al igning the port fo l io wi th the strategic direct ion of the enterpr ise in order to achieve the r ight balance of investments.
Having evaluat ion cr i ter ia in place that should include, at a minimum: al ignment wi th the enterpr ise’s strategic object ives; f inancial worth (as determined by the pract ices of each enterpr ise); and r isk, both del ivery r isk ( the r isk of not del iver ing a capabi l i ty) and benef i ts r isk ( the r isk of not real is ing the expected benef i t f rom the capabi l i ty) .
Implement ing a decis ion-making process to pr ior i t ise the al locat ion of resources for IT operat ions, maintenance and systems development in order to manage and del iver an opt imal return on the IT port fo l io.
Portfolio management is needed to balance and prioritise between new projects and the operating costs of existing systems. It can lead to possible savings on operating costs – e.g. via outsourcing or establishing shared services. Real portfolio management implies a group at the top with an overview of priorities and what is needed – otherwise decisions will be based on relationships and sometimes “who shouts loudest” rather than an objective analysis. Portfolio management should focus on the total ongoing commitment not only the cost of the initial implementation. Managing portfolios can be difficult and requires sound business judgment as well as disciplined management otherwise projects that may be significant to the business may be overlooked or missed in the detailed management processes. For example, projects that are significant to aligning with the business strategy or small initiatives that are critical opportunities may be overlooked. Like all governance activities decisions made at the top level regarding the portfolio investment approach must be communicated down to individual programmes and projects and be monitored.
Portfolio Monitoring Having created an investment portfolio approach, and approved individual investment programmes, there is a need to monitor (post sign-off) all active programmes, just as one would a financial investment portfolio of for example, equities or properties. Costs need to be monitored as well as cost reduction in business areas and revenue generating potential in the business. The portfolio should also be monitored to ensure continuous alignment with strategic business drivers which may be changing with time and with risk factors – both internal to projects and externally. Projects can be very hard to stop, although it is a good practice to review projects on a regular basis and cancel those that are not likely to deliver value. It is recommended that a project office be established working at the programme level, monitoring standards, targets and deliverables. It can be difficult to find and keep the appropriate people in place for this kind of work. Experience has shown that it can be effective to use bright, temporary people or contractors who will also be more likely to give objective assessments.
IT Governance Developing a Successful Governance Strategy
64 65
Acquisition programmes and procurement projects in the UK central civil government are subject to OGC Gateway Reviews. The OGC Gateway Process examines a programme or project at critical stages in its lifecycle to provide assurance that it can progress successfully to the next stage; the process is based on well-proven techniques that lead to more effective delivery of benefits together with more predictable costs and outcomes. It is designed to be applied to delivery programmes and procurement projects, including those that procure IT-enabled business change. The OGC Gateway Process provides assurance and support for Senior Responsible Owners (SROs) in discharging their responsibilities to achieve their business aims. For more guidance refer to www.ogc.gov.uk.
12.3 Benefits management Monitoring whether or not benefits are being delivered is a key aspect of investment management. Without it, it will be impossible to know whether a return on the investment has been realised. In practice though, it seems this is rarely done for IT investments.
The objectives of benefits management should include: Implementat ion of a benef i t monitor ing process. Ident i f icat ion of IT’s expected contr ibut ion to business resul ts, e i ther as a
component of IT-enabled investment programmes, or as part of regular operat ional support and then agreed, monitored and reported on.
Report ing opportuni t ies to improve IT’s contr ibut ion, appropr iate act ions should be def ined and taken.
Updat ing the programme business case where changes in IT’s contr ibut ion impact the programme, or where changes to other related projects impact the programme
The IMPACT IT Governance SIG members believe that seldom does true benefit monitoring take place. Business sponsors should manage benefits but usually they do not. This may be because of job movement in the business, or because the business owner of change is often not the operational owner of the benefits. The main reason though is probably a lack of willingness for the senior business sponsor to take ownership and accountability for monitoring benefits. Investment oversight and the drive to apply discipline to the monitoring process should be directed by the IT Council or management team via a standard process.
12.4 Measuring investment performance Management should establish a general monitoring framework and approach that defines the scope, the methodology and the process to be followed for monitoring IT’s contribution to the results of the enterprise’s portfolio management and programme management processes. The framework should be integrated with the corporate performance management system. The objective is to assess the overall performance of the portfolio of investments. Investment performance assessment should review how the products of IT activities are performing – not just IT as such but the whole process. Many lessons can be
Managing the IT Investment12
Figure 12.4
IT Governance Developing a Successful Governance Strategy
66 67
learnt from analysing why projects are successful or not successful. Setting actual targets and metrics should be driven by the stakeholders who should also approve and monitor them.
12.5 Improving value delivery and ROI To optimise the business value realised from IT-enabled investments it is recommended that8 :
IT-enabled investments are managed as a port fo l io of investments. IT-enabled investments include the ful l scope of act iv i t ies that are required to
achieve business value. IT-enabled investments are managed through their fu l l economic l i fe-cycle. Value del ivery pract ices def ine and monitor key metr ics and respond quickly to any
changes or deviat ions. Value del ivery pract ices engage the business and assign appropr iate accountabi l i ty
for the del ivery of capabi l i t ies and the real isat ion of business benef i ts. Value del ivery pract ices are cont inual ly monitored, evaluated and improved. A discipl ined approach is enforced to port fo l io, programme and project management,
insist ing that the business takes ownership of a l l IT-enabled investments and that IT ensures opt imisat ion of the costs of del iver ing IT capabi l i t ies and services.
Technology investments are standardised to the greatest extent possible to avoid the increased cost and complexi ty of a prol i ferat ion of technical solut ions.
12.6 Measuring and controlling IT operational costs When managing IT investments, there is a tendency to concentrate on new projects rather than ongoing operations. The operational budget is likely to be a much larger financial amount than new investments, and there are often opportunities to optimise these ongoing costs. It is therefore recommended that a cost management process be implemented comparing actual costs to budgets. Costs should be monitored and reported. Where there are deviations, these should be identified in a timely manner and the impact of those deviations on programmes should be assessed and, together with the business sponsor of those programmes, appropriate remedial action should be taken and, if necessary, the programme business case should be updated. If the costs are recorded and analysed down to the lowest “service” level, then the business can decide whether to use the service. Doing this may be costly – especially if carried to too low a level, so it is most effective to focus on significant services and cost areas.
12.7 Project risk management Project risk management is a very valuable process, providing an independent monitoring function. Its purpose is to eliminate or minimise specific risks associated with individual projects through a systematic process of planning, identifying, analysing, responding to, monitoring and controlling the areas or events that have the potential to cause unwanted change. It can include a focus on costs and benefit realisation. In this context project risk management should focus on the following:
Risk assessments that look beyond the internals of the project Ident i fy ing the factors to be considered in advance in a “r isk register” Tracking these i tems on a cont inuous basis Understanding the proximity of the r isk – when might i t h i t? Evaluat ing the sever i ty of the r isk to determine the frequency of monitor ing
needed Risks considered to be high should be closely monitored – by the steer ing commit tee
i f appropr iate – and feedback should be obtained Project r isks that re late to execut ion and del ivery; examples of external business-
related r isk include: - Wi l l the customer want i t? - Need for market test ing - Proof of concept needed?
8. IT Governance Institute®, ValIT Framework.
IT Governance Developing a Successful Governance Strategy
66 67
13 Success Factors
Focus on the following success factors:
Treat IT governance in i t iat ives as a project not a ‘one-of f ’ step. The goal is to make governance “business as usual” .
Obtain top management buy- in and ownership. This needs to be based on the pr inciples of best managing the IT investment.
Remember that implementat ion involves cul tural change as wel l as new processes. Make sure you enable and mot ivate these changes.
Manage expectat ions. In most enterpr ises, achieving successful oversight of IT takes some t ime and wi l l involve cont inuous improvement.
Success Factors13
�NATIONAL COMPUTING CENTRE
IT Governance Developing a successful governance strategy A Best Practice guide for decision makers in IT
Throughout the past five years, we have witnessed unparalleled corporate scandals and
failures in global businesses. The result; heightened focus on corporate governance, stricter
regulations and new directors’ responsibilities, all adding to the pressure on IT Directors and
CIOs. They must now demonstrate to auditors that IT systems which support financial reporting,
as well as monitor and manage business performance are based on sound management
systems and controls.
Against this background, it has never been more important to ensure your organisation
governs the use of IT properly. With corporate governance on every boardroom agenda -
and increasing scrutiny of IT’s performance - IT governance has become a hot topic around
the world. For some many businesses, IT governance initiatives are already transforming the
way their organisations take responsibility for IT. For others, it is a challenge just knowing
where to start.
Recognising the challenges faced by CIOs in establishing effective IT governance, the NCCs
IMPACT Programme launched an IT Governance Special Interest Group (SIG). Its aim was
to identify not just the issues that need to be addressed, but also practical approaches for
organisations to follow. Over the past two years, heads of IT governance from Abbey, Aon,
Avis, Barclays, BOC, DfES, Eli Lilly, Learning & Skills Council, Legal & General, Marsh, NOMS,
Royal Mail, and TUI Group examined the key challenges. They shared successful approaches
and defined best practice.
This IT Governance Best Practice Guide is a comprehensive insight of the principles and
practices that the group put together. It is presented in a form that should help you to
understand better how to guide successful IT governance initiatives and make effective
management and control of IT resources “business as usual”.
This Guide forms part of the NCC ‘Best Practice’ Guides series and is intended to be of
practical use for decision makers in IT. This guidance is achieved through industry consensus,
managed by NCC, across the broadest range of professionals and experts.
National Computing Centre
Oxford House,
Oxford Road,
Manchester M1 7ED
Tel: 0161 242 2121
Fax: 0161 242 2499
The IMPACT Programme
International Press Centre,
76 Shoe Lane,
London EC4A 3JB
Tel: 0207 842 7900
Fax: 0207 842 7979
ISBN 0-85012-897-8
£35.00 NCC Members
£50.00 Non NCC Members
1
Requirements What are "Requirements"? For purposes of this class, we will focus on what the end user needs or expects the system to do. These needs and expectations are documented as requirements for the system. They fall into two general categories: user requirements (sometimes referred to as functional requirements) and system performance requirements (sometimes referred to non-functional requirements). 1. User Requirements describe the tasks the user needs the system to perform, such as:
o What data the system is expected to collect o What the system is expected to do with the data that is input o What the system is expected to provide as output (reports, results, etc.)
Some example user requirements for an online shopping site might be:
o The system must calculate the total of all items in the online or website shopping cart. o The system must display to the user similar items that the online shopper may be interested in. o The system must require the user to provide a shipping address. o The system must automatically fill in the State portion of the shipping address based on the zip
code entered by the user. o The system must provide the user with a report of all purchases made via the website.
2. System Performance Requirements are sometimes referred to as system quality attributes, since
they define how the system is designed, how it will perform when used, and what the user experience will be. (Microsoft, 2009)
They describe how the system will perform, or its quality, in areas such as: o Usability – The ability for new users to quickly adapt to the software, including how easy the
system is to use and how help is provided for the users o Scalability – The ability of the system to accommodate additional users and/or additional
records/transactions o Availability – The amount or periods of time the system is to be operational and useable o Reliability – The ability of the system to create and maintain the data correctly o Maintainability – The ability of the system to be easily maintained, corrected and updated o Performance – The ability of the system to meet time or volume requirements (respond to user
inquiry, update a database, or handle the workload) o Portability – The ability of the system to run/operate on a variety of end-user devices or with
multiple operating systems o Interoperability - The ability of the system to interact with other existing or legacy systems System performance requirements also describe security requirements for the system and data, such as: o Protection of the system from malicious or accidental actions o Protection of data as it is transmitted and when it is stored o User authentication; prevention of unauthorized access o Authorization of users to perform specific functions; prevention of unauthorized changes to
data o Data backup and recovery
2
Some example system performance requirements are: o The system must encrypt the user's payment information when it is transmitted. o The system must require a retinal scan for login purposes. o The system must be capable of handling 5,000,000 transactions per hour. o The system must operate using Motorola handheld scanners. o The system must be able to accept financial data directly from the company’s financial system.
To differentiate between user and system performance requirements, the business analyst determines whether each requirement describes a task that the system must perform (user requirement) or describes system quality or security (system performance requirement). How are the Requirements Used? Requirements can be used to develop a system from scratch, in which case many detailed requirements for every step of every process need to be clearly laid out. For example, if an accounting system is to be developed, the developers will need to incorporate all the financial and legal aspects of the process. They will need to know exactly how each accounting function is to be performed in order to program the system to carry out the function. However, if the intent is to acquire a commercial off-the-shelf (COTS) accounting system or to use a software-as-a-service (SaaS) system, then the requirements may be stated at much higher level, such as: "the system must implement the Generally Accepted Accounting Principles (GAAP)" or "the system must produce a monthly expense statement." In these cases, the end user is not so concerned about each step in performing those functions, as long as the system provides them. Once the requirements are listed, they can be used to:
● Develop a system and test it to be sure it meets the requirements ● Identify one or more COTS or SaaS systems that appear to meet the requirements ● Test the COTS or SaaS systems to determine which one meets the most requirements and select
one for use ● Identify requirements that are not met that may need be added to the system or may require a
separate or additional system(s) or processes to be implemented
According to Mitre (2018) requirements "can be tested, verified, and/or validated, and are unique, complete, unambiguous, consistent, and obtainable, and [can be traced] to original business and mission needs." Documented requirements can be traced through an entire system development and implementation process. For example:
● They form the need for a system and define its scope (all the functions that are to be included). ● They form the basis for estimating the time and cost of developing or acquiring the system. ● They are used to develop the system. ● They are used to negotiate any requirements changes that are proposed by helping to
determine how significant the change is. ● They are used to develop test cases to test the system to see if it functions as needed. ● They are used when modifications or enhancements are proposed to ensure that the new
change does not unintentionally replace previous functionality, and that the new requirement fits within the scope of the system's overall functionality.
3
● They are used to test a modified system to ensure all previous functions, as well as the new functions, perform as needed.
References
Microsoft. (2009). Microsoft application architecture guide, 2009. Retrieved from
https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658094(v=pandp.10)
Mitre (2018) Systems Engineering Guide - Analyzing and Defining Requirements. Retrieved from https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building- blocks/requirements-engineering/analyzing-and-defining-requirements
This document was created by Karen Hogan for IFSM 300 and reposted in IFSM 301 with her permission.
Modifications to the content will be made by the IFSM 301 Course Chair, if needed, for the Fall 2019
semester.
1
Developing Requirements for an IT System
Where do the Requirements Come From?
Let's assume that someone in the organization identifies one or more problems with the way a process is working. Whether the current process is supported by an IT system or not, the analyst might ask people with different roles in the process two questions:
(1) What problems are you having in performing the task today? (2) How do you see an IT system helping to improve things?
These questions should elicit a variety of responses from multiple perspectives. The executives might answer with how the organizational strategies and objectives could be better supported with an IT system. Managers may answer the questions with how an IT system would help them manage the people and processes better. Front-line employees will likely focus on their tasks and which steps could be done more easily and quickly if they had a system. The analyst will use information gathered during the process analysis phase to help stakeholders identify and clarify what the system needs to do for them. If there is organizational agreement that a new system is probably needed, then a determination should be made as to whether a system will need to be developed or if a pre-built commercial off-the-shelf (COTS) solution might work. This would include answering the following types of questions:
● For what major functions or tasks is the user seeking an IT solution? ● Is there any part of that task that is likely to be unique to this organization? ● Would it be possible to find a COTS solution, since those are already created, are ready to be
used, and are often much less costly to implement?
If the organization does not employ any significantly unique functions to accomplish a standard business process, then it is likely that a COTS solution exists that could meet the needs. The determination of whether a system is to be built or bought drives the level of detail needed in the requirements. Many more requirements with much more detail are needed for building a system than for buying one. Regardless of whether a system is to be built or bought, the next step is to identify the high level user requirements (or “functional” requirements) . This is done by interviewing the expected users of the system. Users very often know some of what they need the system to do, but are unable to list all the functions they need. One way the analyst elicits the requirements is by asking a variety of users at different levels of the organization and with different responsibilities how the processes are currently being done and what it is that the current system or process does or does not do efficiently. The manager's perspective and needs are quite different from the front-line employee trying to perform specific tasks, and the executive's perspectives and needs are unique to that level of the organization. After a series of interviews, the analyst can categorize and document the requirements that are emerging. Some of these will likely be at a very high level (e.g., "I need annual financial reports") to very low level detailed items (e.g., "the zip code must include all 9 digits"). For an accounting system, the high level requirements might include "the system must implement the Generally Accepted Accounting Principles (GAAP)" or "the system must produce a monthly expense statement," along with many other functions identified by the users. One of the biggest challenges for the analyst is to differentiate between a "must have" (essential) requirement and a "nice to have" feature. When requirements are
2
collected and documented they are often put into these two categories. The analyst asks the end user to determine whether each requirement is a "must have" or a "nice to have" item, and documents accordingly. Some users may identify requirements that they believe the system must perform, but that the analyst does not believe should be part of the specification for the system in question. At this point in the process, all of the requirements identified by any of the participants should be listed. Eventually, the full list of requirements will be reviewed, modified as necessary and approved by the system "owner" and major stakeholders. During that part of the process, final determinations will be made about which requirements are essential, which are "nice to have," and which should be eliminated. The list of essential requirements will be used to identify whether there are COTS products available that should be considered; "nice to have" requirements will be used to compare solutions that meet the essential requirements. In a system development environment, the essential requirements will be used to determine the scope of the project. It is often easier and less costly to include "nice to have" items in systems being developed in-house, but the overall cost of developing and maintaining IT systems must be considered in making that decision. In the systems development life cycle (SDLC) analysis phase the project sponsor signs off on the requirements document. In later SDLC phases, the requirements are used to design, develop and test the system. A separate set of system performance (system quality and security) requirements comes from the combination of end user needs as well as technical specifications developed by the IT department. The answers, again, are elicited via interviews with expected system users and managers. Below are example questions that the analyst might ask to develop system performance requirements in each of the system quality and security categories:
● Usability – Do you want the system user to have access to an online help manual? Do you
want the user to be able to access context-specific help while entering each data field on the screen?
● Scalability – How many users and how many records/transactions do you need the system to be able to accommodate? How much might those increase over time?
● Availability – Are there any time blocks where access to the system is not needed (e.g., no one would use the system between midnight to 4 a.m. daily)?
● Reliability – Can you provide examples of tasks where the system needs to create and maintain accurate/correct data?
● Maintainability – Are system security updates applied within 24 hours? (While end users are affected by the maintainability of the system, it is usually up to the IT department to determine whether the process used accommodates changes as needed and whether updates are made in a timely manner.)
● Portability – What devices do you want the users of the system to be able to use? Is it likely that they would use a smartphone, tablet, etc., to either query or use the system?
● Interoperability - Are there any systems with which the new system will need to directly exchange data?
● Security – This is another area where users are affected, but need assistance from technical specialists to determine the requirements. The analyst might ask: How sensitive is the data – are there any regulations concerning protecting the type of data in this system (personally identifiable information, healthcare or other data protected by law, etc.)? Do you want users to be restricted as to what they can do with the system or what data they can access?
3
Should this be based on their role in the organization? How often does the data change? How long could you continue to operate if the system were unavailable?
➢ The User’s Role – Identifying Requirements As discussed above, it is the responsibility of the system users to identify the need for a solution to a problem or to identify processes that could be improved and performed more effectively or efficiently. The user is familiar with the business process to be accomplished and with how it is currently performed, and can identify any issues that exist. Previous work completed on process analysis is an important precursor to defining requirements. It is not unusual for the business person to look around and find potential IT solutions to their problems, and some want to jump immediately into acquiring a specific solution. However, without a set of requirements that has been approved by the organization, a solution that fits one set of problems may not fit the needs of other users of the system. ➢ The Analyst's Role – Documenting Requirements One of the business analyst's biggest challenges is to get the users to identify their requirements, rather than focusing on a specific solution. The analyst conducts interviews and observes the process as it exists and documents the process. Using the process analysis work done previously and by asking the types of questions discussed above, the analyst gathers the requirements for the new or updated IT system and begins to document them. How are Requirements Statements Written? There are a number of "rules" for writing requirements statements. These rules help to ensure that the requirements can be clearly understood and that it is possible to determine whether or not the new system meets each of the requirements. Poorly written requirements lead to misunderstanding and misinterpretation and can lead to a system that does not do what the users need it to do. The analyst uses the list of requirements that the users identified and re-writes each requirement to meet the criteria listed below. Each requirement statement:
● Either describes a task that the user needs the system to perform, or states a system performance expectation
● Identifies only one requirement; avoids the words "and," "also," "with," and "or" ● Is a complete sentence, with a subject (usually "the system") and predicate (intended result,
action or condition) ● Uses "must" (not "may" or "should" or "will" or "shall"); written as “The system must…..” ● Is generally stated in positive terms (i.e., "the system must xxxx" vs. "the system must not
xxx"); however, there are times when "must not" is the more appropriate way to express the requirement
● Is measurable; includes a measure or metric that can be used to determine whether the requirement is met (e.g., time or quantity), where appropriate; avoids the use of terms that cannot be defined and measured, such as "approximately," "robust," "user friendly," etc.
● Is achievable and realistic; avoids terms such as "100% uptime," or "no failures" ● Is complete; it can stand alone and be understood
4
● Must be testable; that is, there must be some way to test the system to determine whether the requirement is met.
Below are some examples of poorly written and well-written requirements, with explanations of what is wrong with the poorly written requirements statements.
Poorly Written Requirement What is Wrong Well Written Requirement
Users must have access to their personal data, which will be transmitted in a secure manner.
Two requirements (in this case, one user and one system performance) are expressed; each statement should express only one requirement.
1. The system must provide a user with access to their personal data.
2. The system must transmit personal data in a secure manner.
The system must calculate the total of all items in the online or website shopping cart and display the total to the user.
Two requirements are expressed; each statement should express only one requirement.
1. The system must calculate the total of all items in the online or website shopping cart.
2. The system must display the total of all items in the online or website shopping cart to the user.
Report must be provided within 5 seconds of the user clicking on "submit."
Not a complete sentence; and should be stated as "The system must….."
The system must provide the report within 5 seconds of the user clicking on "submit."
The system should require the user to provide a shipping address.
Avoid the use of "should"; use "must."
The system must require the user to provide a shipping address.
The system must be easy to use.
"Easy to use" is not measurable or testable.
The system must provide on- screen prompts to guide the user through the correct steps to place an order.
The Requirements Document
Once the requirements statements are written correctly they should be grouped into categories. The first categorization is whether a requirement is essential or nice to have. As stated above, this is done by asking the individual who identified it as a requirement, rather than using the analyst's judgment. Then, the requirements are grouped by the function or process involved so that the user community can understand them. Using the accounting system example, the requirements might be grouped under headings like: accounts receivable, accounts payable, payroll processing, financial reports, etc. Arranging the requirements in a sequence that follows the steps in a task is also helpful. For example, in establishing a receivable account, there are specific steps taken; if the requirements are listed in the order that is generally used, it allows the end user to ascertain whether the list of requirements is
5
complete and accurate. Each requirement statement will be assigned a unique identifier so that it can be referred to with ease and clarity. A full requirements document or "requirements specification" may contain many hundreds, or even thousands, of requirements. Again, more detailed requirements are needed for systems being built in-house or under contract. In the case of selecting a COTS product, only the higher level essential user requirements and the system performance requirements need to be developed. Otherwise, if too many specifics are identified, it may be impossible to find a COTS solution. If all this documentation of requirements seems like it is very time-consuming, it is! Identifying and documenting the requirements is the basis upon which all further system decisions will be made, so it is a valuable investment of time and human resources. The later in the process that requirements changes are introduced, the more costly they become to implement. In developing a system, it would require the developers to go back and re-do portions of the system and re-test all the possible outcomes; and, depending on the severity and impact of the change, it may prove to be extremely costly. For COTS solutions, a significant change to one or more essential requirements may impact which systems should even be considered. The upfront investment in defining the requirements helps prevent downstream costs and delays.
This document was created by Karen Hogan for IFSM 300 and reposted in IFSM 301 with her permission.
Modifications to the content will be made by the IFSM 301 Course Chair, if needed, for the Fall 2019
semester.
Section III:2 System Requirements Analysis 31 NYS Project Management Guidebook
2 SYSTEM REQUIREMENTS ANALYSIS
Purpose
The purpose of System Requirements Analysis is to obtain a thorough and detailed understanding of the business need as defined in Project Origination and captured in the Business Case, and to break it down into discrete requirements, which are then clearly defined, reviewed and agreed upon with the Customer Decision-Makers. During System Requirements Analysis, the framework for the application is developed, pro- viding the foundation for all future design and development efforts.
System Requirements Analysis can be a challenging phase, because all of the major Customers and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effective- ness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it is of the utmost importance that the Project Team create a complete and accurate representation of all requirements that the system must accommodate. Accurately identified require- ments result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully satisfies the needs of the Customers.
The primary goal of this phase is to create a detailed Functional Specification defining the full set of system capabilities to be implemented, along with accompanying data and process mod- els illustrating the information to be managed and the process- es to be supported by the new system. The Functional Speci- fication will evolve throughout this phase of the SDLC as detailed business requirements are captured, and as support- ing process and data models are created, ensuring that the eventual solution provides the Customers with the functionali- ty they need to meet their stated business objectives.
List of Processes
This phase consists of the following processes:
� Prepare for System Requirements Analysis, where steps are taken to ensure that the project environment and Project Team members are adequately prepared to both capture and analyze the system requirements;
� Determine Business Requirements, where in-scope and out-of-scope business requirements are identified, business rules are defined and documented, and interfaces to and from the new application are discussed;
� Define Process Model, where a pictorial top-down representation of the major business processes that interact with the system is diagrammed and decomposed into manageable functions and sub-functions until no further breakdown is feasible;
� Define Logical Data Model, where data that supports the processes and business rules is logically modeled, identifying entities and their relationships to other entities, and defining attributes with their business definitions;
� Reconcile Business Requirements With Models, where the Project Team ensures that the Process and Logical Data Models accommodate all requirements and business rules;
� Produce Functional Specification, where interfaces, processes and data are merged to describe systematically how the Consumer will use the application, and how data will be retrieved, processed and stored.
The following chart illustrates all of the processes and deliver- ables of this phase in the context of the system development lifecycle.
32 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Section III:2 System Requirements Analysis 33 NYS Project Management Guidebook
Figure 2-1
System Initiation
Prepare for System
Initiation
Validate Proposed Solution
Develop System
Schedule
Validated Solution
System Requirements Analysis Schedule
High-Level System Development Schedule
Validated Business Requirements and Models
Functional Specification
Iterative and Concurrent
System Requirements Analysis
Prepare for System
Requirements Analysis
Determine Business
Requirements
Define Process Model
Define Logical Data
Model
Reconcile Business
Requirements with Models
Produce Functional
Specification
Prepare for System Design
Define Technical
Architecture
Define System
Standards
Create Physical Database
Prototype System
Components
Produce Technical
Specifications
System Design
Logical Data Model
Process Model
Business Requirements
34 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
List of Roles
The following roles are involved in carrying out the processes of this phase. Detailed descriptions of these roles can be found in the Introductions to Sections I and III.
� Project Manager
� Project Sponsor
� Facilitator
� Business Analyst
� Database Administrator
� Data/Process Modeler
� Technical Lead/Architect
� Software Quality Assurance (SQA) Analyst
� Technical Services (HW/SW, LAN/WAN, TelCom)
� Information Security Officer (ISO)
� Technical Support (Help Desk, Documentation, Trainers)
� Customer Decision-Maker
� Customer Representative
� Consumer
� Performing Organization
� Stakeholders
List of Deliverables
The following table lists all System Requirements Analysis processes, some techniques available for use in executing these processes, and process outcomes and deliverables.
Section III:2 System Requirements Analysis 35 NYS Project Management Guidebook
Figure 2-2
Processes Techniques Process Deliverables (Outcomes)
Prepare for System Team Skills Assessment Established Team and Requirements Site Walk-throughs Environment for Analysis Technology Needs Assessment Requirements Analysis
Tool Needs Assessment
Determine Business Interviews Business Requirements Requirements JAD Sessions
Brainstorming Storyboarding Critical Success Factor
Interviewing Context Diagramming Use Case Diagramming Prototyping Walk-throughs Potential Problem Analysis Expressing Logic: Pseudo Code,
Structured English, Object Oriented Logic
Define Process Work Flow Diagramming Process Model Model Flow Chart Diagramming
Process Modeling Customer Event Diagramming Use Case Diagramming Decision Trees Prototyping
Define Logical Data Entity Relationship Diagramming Logical Data Model Model Data Normalization/
De-Normalization
Reconcile Business CRUD Matrices Analysis Assessment Requirements Gap Analysis Validated Business With Models Requirements and
Models
Produce Functional Process Association and Grouping Functional Specification Specification Logical Organization
Work Flow Clustering Expressing Logic: Pseudo Code,
Structured English, Object Oriented Logic
36 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
2.1 PREPARE FOR SYSTEM REQUIREMENTS ANALYSIS
Purpose
The purpose of Prepare for System Requirements Analysis is to position the Project Team and their working environment to ensure successful completion of System Requirements Analysis. This is the point at which the Project Team prepares to capture the detailed functional, technical, operational, and transitional requirements of the system.
Description
In preparing for this phase, the Project Manager must focus on the Project Team and the environment in which the team will work.
With each new project phase comes the need for new skills, experience, and, potentially, new Project Team members. The team needed during this phase must possess analytical skills that allow them to continually “peel the onion”, driving to con- tinuously deeper levels of requirements definition. Experience
in effective interviewing, facilitation, various modeling techniques, requirements gathering, and gap analysis will be extremely beneficial.
In reviewing the Validated Solution all team members must share a clear and common understanding of the scope of this phase of the project, the Project Schedule, the deliver- ables to be produced, and their individual responsibilities relating to the creation of these deliverables.
Regardless of the size of the development effort being undertaken, System Require-
ments Analysis may place the greatest demand upon Customers in terms of resources and the extent of their required partici- pation. During the preparation for this phase, the Project Manager should continue to manage the Customer’s expecta- tions surrounding this participation. Less involvement typically leads to a less acceptable finished product. In addition, many
Roles
� Project Manager
� Project Sponsor
� Business Analyst
� Facilitator
� Data/Process Modeler
� Technical Lead/Architect
� Customer Decision-Maker
� Customer Representative
Section III:2 System Requirements Analysis 37 NYS Project Management Guidebook
individuals earmarked to participate in the requirements gath- ering sessions may not have been privy to earlier project scope- setting sessions. This can lead to the possible perception of these upcoming sessions as opportunities to identify or request functionality and features that are beyond the original intent of the project. Since management of scope creep is an essential role of the Project Manager, this may be an appropriate time to review the established change management processes with the Customer.
At the start of the System Requirements Analysis phase, it is the Project Manager’s responsibility to ensure that the environ- ment in which the Project Team will work is properly estab- lished. Beyond the obvious need to ensure that team members have adequate equipment to perform their duties, there are additional elements of the environment that should not be over- looked. The project repository, a secure area for maintaining work products and deliverables that was established during Project Initiation, continues to evolve over subsequent phases of the project. Although the establishment of the repository itself is important, it is equally necessary to define the mecha- nisms and processes to be followed for creating and maintain- ing all System Requirements Analysis related materials.
2.2 DETERMINE BUSINESS REQUIREMENTS
Purpose
In Determine Business Requirements, information is gath- ered from a variety of project participants relating to the vision and scope of the system. From this, specific detailed require- ments are identified and documented so that they address the stated business need. These requirements are then decom- posed into a set of business rules.
Description
While this process specifically addresses the capturing of Business Requirements for the new system, the reality is that it may be necessary, and is often beneficial, for the Project Team to determine these requirements while simultaneously defining the supporting process and data models. By conducting these three processes (Determine Business Requirements, Define Process Model, and Define Logical Data Model) concurrently, as opposed to sequentially, the team can develop the process
and data models as information and require- ments are defined, and can update these mod- els as a result of gathering new or changed information.
Because the three processes are performed not only concurrently, but also often iterative- ly, it is important for the Project Team to tight- ly manage the documentation for each process so that requirements are not lost, misunder- stood or overlooked. The Project Manager may need to utilize techniques and/or tools to help document requirements and ensure that they are not missed. The Glossary contains a brief description of some of the techniques available to the Project Manager; examples include storyboarding, interviews, joint appli- cation design sessions (JAD), Unified
Modeling Language (UML), prototyping, data flow diagram- ming, process modeling, and entity-relationship diagramming.
38 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Roles
� Project Manager
� Project Sponsor
� Business Analyst
� Facilitator
� Data/Process Modeler
� Technical Lead/Architect
� Technical Services
� Information Security Officer
� Technical Support
� Customer Decision-Maker
� Customer Representative
� Stakeholders
Determining Business Requirements requires eliciting, analyz- ing, specifying, prioritizing, verifying and negotiating business functions that the system must deliver and support. The results are captured in a Business Requirements deliverable (use Figure 2-5, Business Requirements template, as a guide). During this process it is important to have all of the Stakeholders involved. Since this is the process in which all business and processing requirements are determined and agreed to, it is critical that all parties understand the ramifica- tions of including or excluding requirements from scope. This is an opportunity to work out business process issues as a group, in order to reach optimal performance and efficiency within an organization or even across organizations or func- tional areas. Decisions made will impact remaining phases, so all parties involved in the project lifecycle should be heard, and all areas of concern or question should be thoroughly addressed. Reaching consensus and agreement on the final deliverable from this phase will help to ensure that everyone gets the product to which they agreed.
As stated in the SDLC Overview, requirements fall into multiple categories that, while related, are themselves separate and dis- tinct. These categories are:
Section III:2 System Requirements Analysis 39 NYS Project Management Guidebook
Don’t hesitate to use one of the commercially available tools to assist the Project Team
in their documentation efforts. Through use of these tools, changes made to a process
are automatically carried through to all other associated processes or business rules.
40 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-3
Category Description
Functional Requirements that define those features of the system that Requirements will specifically satisfy a Consumer need, or with which the
Consumer will directly interact.
Technical Requirements that identify the technical constraints or Requirements define conditions under which the system must perform.
Operational Requirements that define those “behind the scenes” Requirements functions that are needed to keep the system operational
over time.
Transitional Requirements that define those aspects of the system that Requirements must be addressed in order for the system to be successful-
ly implemented in the production environment, and to relegate support responsibilities to the Performing Organization.
When capturing Business Requirements, the Project Manager must ensure that the Project Team addresses all of the cate- gories above. Figure 2-4 illustrates the types of considerations and requirements that the Project Team must capture specific to System Requirements Analysis.
Section III:2 System
Requirem ents Analysis
4 1
N YS Project M
anagem ent G
uidebook
System Development Lifecycle
System Initiation
Prepare for Systems Requirements
Analysis
Functional Requirements
Typical Considerations Representative Requirements To Be Captured • Common Functions • GUI Functions • Reporting Functions • Interface Functions • Batch Functions • Security Functions
Technical Requirements
• Accessibility • Encryption • Hosting • Environment • Disaster Recovery
• System Performance • Data Archival • Audit and Controls • System Administration • SQA • Business Continuity
• Data Conversion • Release Validation • Documentation • Training • Deployment
�Common features and functions. �Screen layout, report characteristics, and navigational requirements. �Data exchange between this system and others. �Off-hours processing requirements. �Authorizations, roles, and access privileges.
�Technology guidelines, regulations, and constraints. �Environment for system operation and maintenance (geography,
internal/external hosting). �Strategies for long-term protection and operation of the system/data.
�System performance and responsiveness expectations. �Activities related to administration and maintenance of
system/data. �Organizational procedures involving audits, data archival/retrieval,
and quality assurance.
�Historical data cleansing, conversion, and import into the new system. �Requirements associated with validation of the system prior to
release. �Expectations for user/technical documentation, and supporting
training materials. �Mechanics of physically deploying/transitioning the application.
Operational Requirements
Transitional Requirements
Determine Business Requirements
System Requirements
Analysis
System Design
System Construction
System Acceptance
System Implementation
Impacts the Business Process
Impacts the System
Infrastructure
Impacts Operations and
Support
Impacts Implementation
Define Process Model
Define Logical Data Model
Reconcile Business Requirements With Models
Produce Functional Specification
Figure 2-4 System Requirements Analysis Considerations
One approach to eliciting requirements from the Customer is to hold one or more JAD sessions. For these sessions, assem- bling individuals from both the program areas and IT into cross- functional groups can help clarify how proposed changes to a business process may impact operations. The benefit of having a session with multiple representatives from the program areas is that the pros and cons of business process changes are heard and discussed by all involved.
Requirements gathering, when properly facilitated, establishes a forum for everyone to be heard, for issues to be worked through, and for resolutions to be defined that meet the needs of all parties. Through this forum, multiple opinions may enhance the team’s understanding of how certain processes are current- ly being performed, better defining how they should be struc- tured within the context of the new application. This approach may also result in negotiations of functionality. There may need to be some trade-offs, and as a result processes may be reex- amined and redefined. As the sessions progress, the Project Team must constantly assess and analyze the requirements.
It is not unrealistic to assume that there may come a point at which negotiation or consensus building activities will break down, and that resolution of an issue may require insight or information not available to the Project Team. Ultimately, there must be a single decision making body responsible for resolv- ing such issues. A key role of the Project Sponsor or Customer Decision-Maker is to make the final determination regarding these issues, and to communicate the decision to the Project Team. The Project Sponsor may or may not choose to share the
42 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
A common mistake when coordinating the logistics of interviews or group requirements
definition sessions is to hold these meetings where the majority of the participants rep-
resent only the Customer and Consumer populations. Doing so may set the stage for the
Project Team to form a type of tunnel vision in which business requirements that focus prima-
rily, or even exclusively, on the functional aspects of the system are captured. Just by the nature
of their day-to-day responsibilities, Customers will often approach these requirements definition
sessions from the perspective of, “What do I need this system to do in order for me to perform
my duties?” Many operational, technical, and transitional requirements do not fall within the
answers to that question. It is up to the Project Team member running these sessions (typical-
ly a Business Analyst or Facilitator) to make certain that these aspects of the system are also dis-
cussed, and that the individuals best positioned to provide this information are represented at
the requirements definition meetings.
rationale for such decisions with the entire team, nor is it guar- anteed that the team will agree with determinations that are made. The Project Manager should encourage the team to sup- port the decisions and move forward.
The following steps should assist the team in building a useful and comprehensive Business Requirements document:
Absorb the requirements. Before the requirements can be analyzed, they must first be collected. Team members need to be sponges and take everything in, no matter how unimportant or inconsequential it may seem. There are many approaches to gathering these requirements, but all start with effective lis- tening. Regardless of the technique used, the Project Team must remember that the goal of this process is to understand what the Customers need – not what the team members think they need.
Interpret the requirements. Now that the requirements have been captured, the Project Team must think about them. What have they heard? What was missed? Look for unanswered questions or contradictions. The requirements must be stated as clearly and concisely as possible, avoiding combining requirements and eliminating subjective wording. If the system must do A and B and C and D, there should be four distinct and verifiable requirements that can each be approved or rejected on its own merits. Avoid ambiguities and opinions. If the requirement is that some process should be “easy”, the team should go back and find out exactly what that means. What would make something about that process difficult or more complex than it should be?
Bind the requirements. While defining what the business requirements are, it is also necessary to determine what they are not! This is done to establish consensus on the Project Scope and to clarify any scope issues. At least some require- ments that were captured will be labeled “out of scope.”
Categorize the requirements. Even for a relatively small sys- tem, you are likely to end up with scores of requirements. To understand how they relate to each other, and to effectively deal with them later on in the process, it is necessary to sepa- rate them into categories, logically grouping the requirements according to related business functions or organizational boundaries.
Section III:2 System Requirements Analysis 43 NYS Project Management Guidebook
Prioritize the requirements. Regardless of how accurately the business requirements reflect the business need, it may not be feasible to implement them all at once (or even at all). In finalizing the requirements to be implemented, it will be neces- sary to prioritize them according to their criticality to the busi- ness. This classification into core, essential, and desirable will very likely involve both the Project Sponsor and Customer Decision-Makers.
The following guidelines may be used: “Core” requirements are the ones without which the system may as well not be devel- oped at all; it will be of no use to most Customers without these. “Essential” requirements are those for which a short- term work-around could be developed (or for which an old process can hobble along for a little while longer) but over the long run, they have to be there. “Desirable” requirements are the “bells and whistles” that may be precious to certain con- stituencies, but without which the system will function just fine.
To put it another way, the system must go into production with all Core and a good portion of Essential requirements repre- sented, and with a plan to implement the remaining Essential requirements in the subsequent phase.
Deliverable
� Business Requirements – A document containing detailed requirements for the system being developed. These requirements define the functional, technical, operational, and transitional capabilities, restrictions, and features that must be provided by the new system.
44 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-5 Business Requirements Document
Section III:2 System Requirements Analysis 45 NYS Project Management Guidebook
< Name of Agency >
Business Requirements Document < System Name >
Agency
Project Name
Project Sponsor
Project Manager
Document Date
Prepared By
Enter the name of the Agency for which the system is being developed. Enter the Project Name, and the names of the Project Manager and the Project Sponsor. Enter the Date as of which this document is current. Enter the names of the Project Team members by whom the document was Prepared.
Business Requirements Document
TABLE OF CONTENTS
The Table of Contents should be at least two levels deep.
1.0 DOCUMENT SCOPE
Document Scope describes the goal of this document in a narrative. Example:
To define a consistent set of business requirements for the <XYZ> system and to identify what is in and out of scope.
The narrative should also provide an overview of the efforts conducted to gather business requirements. Example:
This document summarizes the requirements gathered in a series of <X> Joint Application Design (JAD) sessions that were conducted by <members of the Project Team> with <DEF> and <GHI> business units between <date> and <date>.
2.0 GENERAL REQUIREMENTS
The General Requirements section lists high-level business requirements that apply to the whole system. Example:
This system will provide a central repository for all <XYZ> data.
It should also include those requirements that are common to all Customer groups. Example:
This system will provide ad hoc reporting capabilities to each Consumer business unit.
NOTE: By default, all requirements listed in this section are deemed to be Core to the system. Those general requirements that do not meet these criteria should be listed below under “4.0, Business Requirements Not Being Implemented”.
46 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-5 (Continued)
Figure 2-5 (Continued)
Business Requirements Document
3.0 SPECIFIC REQUIREMENTS
The Specific Requirements section lists business requirements specific to each Customer group. A concise and specific listing of Business Requirements by Business Function should be provided. Requirements should be categorized, bulleted, detailed, and prioritized. These requirements should encompass the multi-dimensional aspects of the system (i.e., the functional, technical, operational, and transitional requirements).
3.1 Business Unit
Description
The Description identifies the purpose and main functions of the Business Unit.
3.1.1 Business Function 1
Description
In addition to Business Function Description, the narrative focuses on the desired business processes that will be in place when the new system is implemented as opposed to the current state of the business function, which can be documented, if necessary, in the Appendix.
� Business Requirement 1 (Priority) � Business Requirement 2 (Priority) � Etc.
3.1.2 Business Function 2
Description
� Business Requirement 1 (Priority) � Business Requirement 2 (Priority) � Etc.
This format is repeated for all Customer and Consumer groups and their respective functions that require interaction with the system.
Example: <XYZ> Unit
Description: This unit is responsible for developing the <ABC> deliverable, maintaining the <DEF> function and executing the <GHI> process.
Business Function: Developing the <ABC> Deliverable Description: The <XYZ> unit personnel will utilize the system reports to compile and produce the <ABC> deliverable (see attached).
Business Requirements (Priority) 1. The System will provide a report detailing <JKL> expenditures that
will be used for Page 2 of the <ABC> Deliverable. (Essential) 2. Etc.
Section III:2 System Requirements Analysis 47 NYS Project Management Guidebook
Figure 2-5 (Continued)
Business Requirements Document
4.0 BUSINESS REQUIREMENTS NOT BEING IMPLEMENTED
This section specifies requirements that will NOT be part of the new system.
Example: Director of Contracts and Director of Claims have determined that the following functions are outside the scope of this system:
1. <ABC> Process 2. <DEF> Deliverable 3. Etc.
APPENDIX A – Requirements Definition Supporting Details
All published work products (meeting notes, session results, etc.) of individual interviews and group facilitated sessions held to determine business requirements should be included in this section.
A table detailing dates, times, topics and participants of all interviews and sessions should precede the compilation.
48 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
2.3 DEFINE PROCESS MODEL
Purpose
The purpose of the Define Process Model process is to create a pictorial representation of the functions and operations (i.e., the processes) that will eventually be performed by the system being developed.
Description
The second of the three concurrent processes within System Requirements Analysis, Define the Process Model may begin at any time after the Project Team has started collecting specific
business requirements. The resulting Process Model of the system, also often referred to as the “To Be” model, illustrates the system processes as they are envisioned for the new system. Over time, this pictorial top-down representation of the major busi- ness processes will be decomposed into manageable functions and sub-functions until no further breakdown is possible. When combined with the detailed set of Business Requirements and the supporting Logical Data Model, this Process Model should com- pletely address not only the full list of busi- ness needs to be satisfied by the new system, but also the vision for how the new system will provide and support this functionality.
During the Determine Business Requirements process, a picture of the current business processes and practices will begin to evolve. This can be a useful tool in confirming that all current processes have been identified, and can be used by the Project Team as a means of ensuring that their Process Model has not neglected any existing functionality. There is a risk, however, that too much focus on current business processes may cause Customers to take a myopic view of the their true business needs, ultimately defining a system that provides little value over the system that is already in place.
Section III:2 System Requirements Analysis 49 NYS Project Management Guidebook
Roles
� Project Manager
� Business Analyst
� Facilitator
� Data/Process Modeler
� Technical Lead/Architect
� Technical Services
� Information Security Officer
� Technical Support
� Customer Decision-Maker
� Customer Representative
� Stakeholders
Remembering that much of System Requirements Analysis is iterative, the Project Manager must ensure that as require- ments are updated as a result of continued efforts to Determine Business Requirements, the Project Team also refines the Process Model to accommodate those changes.
The Project Manager must ensure that the Stakeholders and Customers periodically validate the Process Model as it is being developed. It is important that they understand that the Process Model is a representation of the proposed business solution, an attempt to meet everyone’s needs. As part of vali- dating the final Process Model deliverable with the Customer, it may be beneficial to conduct walk-throughs to map the defined business requirements to the diagrammed Process Model. A walk-through helps to identify any requirements missed by both the Project Team and the Customer, and helps to further vali- date that the requirements and processes are accurately decomposed.
50 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
A key to successful process modeling is to find a way to get your Customers to look
beyond “what they do and how they do it”, and to instead describe “what they need
and how it could best be accomplished” if they were not forced to perform their duties within
the constraints or limitations of existing systems and processes. One of the most common mis-
takes made during this phase of the development lifecycle is to automate a bad process, sim-
ply because that’s the way the business has always operated.
Before the Customer accepts the final deliverable for this process, ensure that he or she
understands the ramifications of acceptance. For instance, if a process critical to the appli-
cation was overlooked in a JAD session, and therefore not modeled, and the deliverable has
been approved, change control may be necessary. Ensuring that the processes have been iden-
tified and decomposed will make it more likely that the data model built to support the process
is adequate. If a process has been overlooked, there will most likely be an impact to the design
of the data model, and therefore to the database itself. This could definitely warrant change con-
trol downstream. This applies to the Business Requirements and Logical Data Model deliverables
as well as the Process Model. You may need to validate these three deliverables incrementally
during this phase, and provide the Customer with a final walk-through at the conclusion of this
process, before proceeding to the development of the Functional Specification.
Deliverable
� Process Model – A graphical representation of the decom- position of all business processes that interact with the system.
2.4 DEFINE LOGICAL DATA MODEL
Purpose
The purpose of Define Logical Data Model is to identify all uniquely distinguishable objects either used or produced by the system (the data entities), to capture all of the characteristics that help define those objects (the data attributes), and to describe the relationships between the entities.
Description
Like process modeling, definition of the data model can start as soon as the interviews or JAD sessions begin. A Data Modeler is most often responsible for designing the logical rep-
resentation of the data to support the business need. Typically, this model will evolve throughout the iterations of capturing and documenting the business requirements.
The Data Modeler may begin to work on one of two paths: the first assumes that the application is brand new, and that the Data Modeler is working from a blank slate. In this case, informational requirements are captured as they are identified during the JAD sessions or interviews. As sessions are held, a view of potential entities and attributes is constructed and organized.
The second path assumes that the new application is going to replace an existing system. In this case, the Data Modeler may work with the current Data
Base Administrator (DBA) to reverse engineer the existing database or file structures, often using a modeling tool. This enables the Project Team to use the existing structures as a starting point for the new Logical Data Model, and as a means
Section III:2 System Requirements Analysis 51 NYS Project Management Guidebook
Roles
� Project Manager
� Business Analyst
� Facilitator
� Database Administrator
� Data/Process Modeler
� Technical Lead/Architect
� Technical Services
� Information Security Officer
� Technical Support
� Customer Decision-Maker
� Customer Representative
� Stakeholders
of validating that all informational needs of the system are being accommodated for in the Process Model.
It is important to define the entities and attributes in business English to facilitate Customer consensus and to ensure consis- tency with the organizational nomenclature forming the frame- work for the design of the application and the database. As additional requirements are flushed out during the interviews or sessions, the informational needs of the system are continu- ally re-analyzed and re-applied to the data model. It is impor- tant to keep in mind, when identifying data sources, that con- sideration must be given to enterprise data and standard data that may be maintained in external systems (e.g., County Code Table, OSC code tables, etc.)
Defining the data model also helps to define the business rules by establishing the data entities (tables) and identifying attrib- utes (fields). With the requirements and business rules known, and the Process Model outlined, the Project Team can begin to establish relationships between the data entities. This becomes the foundation of the data repository (or physical data model). As attributes are identified, the Data Modeler begins to build the Data Dictionary – again, in business English. Data normalization, a process in which complex relationships are simplified, is important once the Data Dictionary has been established. This eliminates redundancy, creates stable data structures, prevents anomalies, and simplifies data mainte- nance. The Logical Data Model is the basis for the DBA to cre- ate the physical database, so it is important that the Data Dictionary is clear in its definitions, and that all the data has been modeled appropriately.
52 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
A key to successful data modeling is to ensure that the logical data model is not
dependent on how the system processes the data. This ensures that data is grouped
and organized based strictly on the informational needs of the system, and not based on an
implied or assumed usage of the data by the system. The benefit is that the integrity of the data
model will remain intact even if future business needs change the functionality of the system.
The Project Manager’s goal for this process is to ensure that the Project Team accurately reflects the data requirements as they are defined, and as they relate to the Business Requirements and Process Model. The Project Manager should ensure that a process exists for the various Project Team members to share information and refine the requirements and models without risk of losing information, or jeopardizing the consistency and inter-dependencies of these deliverables.
The evolution of the Logical Data Model is analogous to the cre- ation and confirmation of the Process Model in that it requires frequent interaction and validation by the Customer. While many of the deliverables in System Requirements Analysis pres- ent information in formats and terminology with which the Customer is familiar, this may not always be the case with data models. As a result, the Project Manager should anticipate the need for additional interaction during these reviews to ensure that the Customer can accurately interpret the output of this process. In addition, walk-throughs must be conducted in con- junction with, or in close proximity to, the reviews of the Process Model to be most effective.
Deliverable
� Logical Data Model – Diagrams and Data Dictionary information defining data elements, their attributes, and logical relationships as they align within a business area, with no consideration yet given to how data will be physically stored in actual databases.
Section III:2 System Requirements Analysis 53 NYS Project Management Guidebook
The experience that a seasoned Data Modeler can bring to the Project Team can often
make the difference between a successful project and one that encounters multiple
setbacks or surprises. Understanding how to identify entities and attributes, establish relation-
ships between the entities, normalize the attributes and define the Data Dictionary are impor-
tant to developing a high performing application. These activities lay the groundwork for the
technical team to build the physical database.
2.5 RECONCILE BUSINESS REQUIREMENTS WITH MODELS
Purpose
The purpose of Reconcile Business Requirements With Models is to ensure that all business requirements and rules that have been captured have been accurately reflected and accommodated for in the Process Model and the Logical Data Model.
Description
Since the Process and Logical Data Models will ultimately form the basis of the system design, it is critical to invest the time here in System Requirements Analysis to ensure that these mod- els are complete and accurate. If business requirements have been identified that are not reflected in these models, or if discrepancies exist between these models, then it is almost certain that this step will be revisited at some point later in the project. As Figure 2-6 indi- cates, the further out in the project that deficiencies in the business requirements are identified, the more costly the effort required to correct these deficiencies.
Figure 2-6 Impact of Change on Project Costs
54 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Roles
� Project Manager
� Business Analyst
� Facilitator
� Database Administrator
� Data/Process Modeler
� Technical Lead/Architect
� SQA Analyst
� Technical Services
� Information Security Officer
� Technical Support
� Customer Decision-Maker
� Customer Representative
� Stakeholders
Requirements Design Construction Acceptance Implementation Analysis
Co st
o f C
ha ng
e
Timing of Change
A typical technique at this point in the SDLC is to perform an analysis assessment, which validates and cross-references all requirements to the process and data models, and which con- tinues until all gaps have been identified, resolved, or recog- nized as an out of scope item.
One technique to reconcile the Business Requirements, Process Model and Logical Data Model is for the Business Analyst to create a gap analysis checklist or matrix that may be used to display the interactions among the requirements, data entities and the processes. This will help to ensure that all the requirements have been captured and modeled appropriately.
It is helpful to walk Customers through this exercise so that they understand how all requirements have been captured and modeled. These reviews are often iterative, and any gaps iden- tified are corrected through subsequent revisions to the Business Requirements, the Process Model, or the Logical Data Model. It may be necessary to hold several review sessions to go over the reconciliation with different sets of Customers, remembering that the more people who review the output, the less likely it will be that key elements have been missed.
The Project Manager must ensure that the Customer under- stands the ramifications of overlooking a process, or of failing to decompose and model data appropriately. By understanding the potential impacts on both schedule and cost, the Customer is more likely to dedicate the appropriate staff to participate in these reviews.
Deliverable
� Validated Business Requirements and Models – An updated set of Business Requirements, Process and Logical Data Models that have been modified to address any gaps or weaknesses identified as a result of a gap assessment performed on these documents as a single unit.
Section III:2 System Requirements Analysis 55 NYS Project Management Guidebook
2.6 PRODUCE FUNCTIONAL SPECIFICATION
Purpose
Produce Functional Specification maps the Logical Data Model and Process Model to the organizations and locations of the business. This process also produces the final deliverable for the phase – the Functional Specification.
Description
The ultimate goal of this process is to derive a comprehensive representation of the application that logically organizes relat- ed business processes, functions, data, and workflows. This provides a detailed roadmap from which the Customer Representatives can fully envision the final solution, and from which the Project Team can progress into the Design and Construction phases of the project lifecy- cle. Whereas all System Requirements Analysis efforts up to this point have been focused on continually decomposing information into discrete requirements or processes that can each be reviewed and validated on their own merits, this final process now builds a broad- er view of the system that groups the individual pieces of the solution into logically related business functions. The final result, the Functional Specification, defines and illustrates how each requirement of the system will eventually be satisfied in terms of business processes (or transactions).
Deliverables resulting from this phase of the lifecycle must cap- ture the full set of requirements for the new system in a way that is completely independent of any development approach, methodology, or organizational constraints. Much like System
56 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Roles
� Project Manager
� Project Sponsor
� Business Analyst
� Facilitator
� Data/Process Modeler
� Technical Lead/Architect
� SQA Analyst
� Technical Services
� Information Security Officer
� Technical Support
� Customer Decision-Maker
� Customer Representative
� Stakeholders
Initiation defined why the new system was needed, the System Requirements Analysis deliverables must define what the sys- tem must do without making any assumptions regarding how the system will be built.
The Functional Specification will present many views of the sys- tem, from different perspectives and at different levels of detail. For example, the System Context Diagram shows how the new system fits into the larger picture of the performing organiza- tion’s application portfolio. The Business Flow Diagram shows how Customer and Consumer business units will interact with the new system from the business process and data flow per- spectives. And the System Interface Diagram will present a view of the system from a perspective of Consumer interface, depicting menu structures and navigation paths of online sys- tem components, and organization and distribution of reports and other batch interfaces.
Within the Functional Specification, each business process or transaction will correlate to the set of Business Requirements that it satisfies and a representation of the corresponding data elements. The reports associated with each process, business constraints (such as related security or controls), interfaces to other systems and business functions, and any related admin- istrative operations required to support the system should also be identified.
As discussed in Determine Business Requirements, require- ments gathering sessions frequently result in features or func- tions above and beyond those initially envisioned during Project Origination being identified. One advantage of a well-defined
Section III:2 System Requirements Analysis 57 NYS Project Management Guidebook
When identifying the new vision of the system with its proposed sets of related
processes and functions, organizational or operational changes may be introduced.
Ultimately, the Customer must be comfortable with these changes, and be willing and able to
institute them. The Project Team must take this into account when establishing this framework .
Both the Project Manager and the Stakeholders must find the appropriate balance between the
potential need for the change, and the likelihood that it will be embraced throughout the
organization.
Functional Specification is that it provides the Project Team with a vehicle to assist the Customer with decisions on trade- offs in functionality and scope, should the situation arise that sufficient budget is not available to support the development of the full set of capabilities.
To ensure that the Customer agrees with the final deliverable, the Project Manager should schedule a walk-through to review the concepts and flow of the Functional Specification, and to achieve consensus that the proposed grouping of processes defines a solution that will satisfy the Customer’s needs.
Deliverable
� Functional Specification – Document describing the logi- cal grouping of related processes and functions within the new system, along with the mapping of these processes to both the business requirements that they satisfy and the data items with which they interact.
58 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-7 Functional Specification Template
Section III:2 System Requirements Analysis 59 NYS Project Management Guidebook
< Name of Agency >
Functional Specification < System Name >
Agency
Project Name
Project Sponsor
Project Manager
Document Date
Prepared By
Enter the name of the Agency for which the system is being developed. Enter the Project Name, and the names of the Project Manager and the Project Sponsor. Enter the Date as of which this document is current. Enter the names of the Project Team members by whom the document was Prepared.
60 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-7 (Continued)
Functional Specification
TABLE OF CONTENTS
The Table of Contents should be at least two levels deep.
1.0 DOCUMENT SCOPE
Document Scope describes the goal of this document in a narrative. Example:
To define a comprehensive set of functional specifications for the <XYZ> system and to identify what is in and out of scope.
The narrative also provides an overview of the efforts conducted to gather business require- ments, derive process and logical data models, and to reconcile business requirements with these models.
2.0 GENERAL FUNCTIONAL SPECIFICATIONS
The General Functional Specifications section details those specifications that are common to all aspects of the system (e.g., the menu structure, security, accessibility, overall perform- ance requirements, etc.).
Three graphical representations of the overall system should be included: � a System Context Diagram, showing how this system will interact with other existing systems, � a Business Flow Diagram, showing how Customer and Consumer business units will interact
with the system; and � a System Interface Diagram, showing the application structure (menu structure and naviga-
tion of online components), organization of reports and other batch interfaces, and utilities.
3.0 DETAILED FUNCTIONAL SPECIFICATIONS
The Detailed Functional Specifications section lists functional specifications for each aspect of the system. The structure of this section is dependent on system organization. For example, if the system is organized to follow the business unit structure, with each sub-system supporting a specific Customer or Consumer group, then each Sub-system Description should list main characteristics and functions of that group; on the other hand, if the system is organized by type of interface (data entry, reporting, etc.), then the Sub-system Description should outline common characteristics of those system components.
It may also be useful to provide more detailed versions of the Business Flow and System Interface diagrams for each sub-system.
Section III:2 System Requirements Analysis 61 NYS Project Management Guidebook
Figure 2-7 (Continued)
Functional Specification 3.1 Sub-system
The Sub-system Description describes the sub-system in a narrative.
3.1.1 Component Type
Depending on system structure (and Functional Specification document), it may be useful to organize system components by type (such as screens vs. reports, or tracking vs. auditing). If that is the case, Component Type Description would provide a rationale for such structural breakdown, and describe common elements of all components within that type.
Component Type Description
3.1.1.1 Component 1
� Component Description � Component Mockup (where appropriate) � Component Business Flow
• Cross-reference to Business Requirement(s), Logical Data and Process Models
• Flowchart • Detailed Business Rules for each Flowchart element
The Component Description should identify the appropriate Customer or Consumer group, and provide a description of how their needs are being met by this component. Where appropriate, a mockup of the component should be included in the document. Component Business Flow details how the system supports the business process.
A Cross-Reference is provided to all prior deliverables. A Flowchart details the system component’s interaction with the business process. Every shape and arrow on the Flowchart is annotated with detailed descriptions of Business Rules governing that particular interaction or transformation.
3.1.1.2 Component 2
� Component Description � Component Mockup (where appropriate) � Component Business Flow
• Cross-reference to Business Requirement(s), Logical Data and Process Models
• Flowchart • Detailed Business Rules for each Flowchart element
62 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Figure 2-7 (Continued)
Functional Specification
4.0 OTHER SPECIFICATIONS
Besides functional aspects of the Business Requirements, the specifications for the system should also enumerate technical, operational and transitional aspects of the system.
4.1 Technical Specifications
This section documents in detail the technical specifications, regulations and existing con- straints that must be considered in relation to business requirements. These include considera- tions such as accessibility, encryption, security, disaster recovery, and other technical areas.
4.2 Operational Specifications
This section should document in detail the operational specifications that must be considered in relation to business requirements. These include considerations such as system perform- ance, data archival, audit and controls, system administration, software quality assurance and business continuity. The narrative should specify how these operational requirements may affect the organization and its current business processes.
4.3 Transitional Specifications
This section documents in detail the transitional specifications that must be considered in relation to business requirements. These include considerations such as data conversion, system testing, documentation, training and deployment. The narrative should describe how historical data will be cleansed, converted and imported into the new system, how expectations must be set for the deployment of and support of user and technical documentation and training, and what approach may be employed to physically deploy and transition the system into the organization.
5.0 BUSINESS REQUIREMENTS NOT BEING IMPLEMENTED
This section specifies those requirements that will NOT be part of the new system. If this list is identical to the one published in the Business Requirements document, a simple reference to the prior document may be substituted.
APPENDICES – SUPPORTING DOCUMENTS
The Appendices should contain all relevant documents provided by Customers and Consumers during System Requirements Analysis, as well as documents supporting decisions made while compiling the Functional Specification.
Measurements of Success
The immediate measurement of success for System Require- ments Analysis is the acceptance of all deliverables by the Customer, while the ultimate measurement is whether or not the Project Team has created solid groundwork for the upcom- ing design and development of the application. Each process in this phase builds towards the final deliverable: Functional Specification. It is necessary to validate that certain steps have been successfully executed to ensure that the Functional Specification has been derived appropriately.
The Project Manager can assess how successfully this phase is proceeding by utilizing the measurement criteria outlined below. More than one “No” answer indicates you may have seri- ous risk to the Project.
Figure 2-8
Process Measurements of Success Yes No
Prepare for System Have all new team members participated in project Requirements Analysis orientation sessions?
Is the team comfortable with the process defined for managing the deliverable repository?
Do all team members have experience with (or training on) the tools that will be used in this phase?
Determine Business Do the business requirements state what is in scope Requirements as well as what is out of scope?
Have the business requirements been reviewed and approved by the Customer?
Are the requirements stated in such a way as to allow for easy validation of their existence in the final solution (i.e., a Yes/No determination of whether or not the requirement has been satisfied by the new system)?
Are requirements prioritized within the Business Requirements deliverable?
Do the requirements consider the technical, operational and transitional aspects of the system, including elements such as: • Security/access needs; • Existing technical standards (accessibility,
encryption, etc.); • Application hosting;
Section III:2 System Requirements Analysis 63 NYS Project Management Guidebook
Figure 2-8 (Continued)
Process Measurements of Success Yes No
Determine Business • Disaster recovery; Requirements • Archiving, audit and regulatory needs; (Continued) • Performance requirements by all Customers and
Consumers for all aspects of the system; • Business continuity; • Data conversion?
Define Process Model Have all known business requirements and associated business rules been mapped and accommodated for in the Process Model?
Has the Process Model deliverable been reviewed and approved by the Customer?
Define Logical Data Have all known business requirements and Model associated business rules been mapped and
accommodated for in the Logical Data Model?
Has the data model been normalized?
Has the Logical Data Model deliverable been reviewed and approved by the Customer?
Reconcile Business Does the Customer agree that all aspects of the Requirements With requirements and rules have been accommodated Models for in the process and data models?
Produce Functional Has the Functional Specification deliverable been Specification reviewed and approved by the Customer?
Has a system validation and testing approach been formulated?
Have training needs been identified?
Has an approach for the implementation and transition of the application been developed?
Phase Risks / Ways to Avoid Pitfalls
PITFALL #1 – IF YOU BUILD IT (TOO SOON), WILL THEY COME?
Your Project Team is top-notch and you can’t believe your luck in securing their stellar capabilities. You have the guru of gurus as your development lead. After the first JAD session he tells you he already has envisioned the application – it’s a finan- cial module and similar to one he has previously developed. He convinces you that he needs to skip the rest of the JAD sessions so he can begin to prototype immediately. He is so enthusias- tic and convincing in his argument to you, that you bless him to go off and start creating. You have already re-forecast your
64 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
Project Schedule mentally and foresee an early delivery date. How sweet it is!
Four weeks into the JAD sessions, you haven’t yet seen any out- put from him. He tells you he’s almost there, just a few more tweaks … you remind him it is just a prototype, not a full- fledged construction effort yet. He assures you it is just what the Customer wants. But you realize that the Customer hasn’t been involved in the prototyping exercise. How can your lead developer be creating anything without the Customer vision?
You arrange a meeting with the developer and the Customer to review the prototype as it is so far, and to elicit feedback. Your developer is giddy with anticipation, convinced that what he has already built will make their dreams come true. Then, the moment of truth: the developer begins to walk the Customer through the first screen, and it is already apparent that there is a huge disconnect between the developer’s and the Customer’s visions of the application. Productive dialogue quickly turns into heated debate.
It all could have been avoided if the developer’s vision really was the Customer’s vision. If only he had gone to the interviews and JAD sessions and heard the requirements, instead of mak- ing assumptions as to what HE thought the Customer should have. If you build it, you’d better make sure they can see it, or they won’t come…..
PITFALL #2 – LET’S CROSS THAT BRIDGE WHEN WE COME TO IT
During your JAD sessions the Project Team has collected and prioritized a set of issues that need to be resolved by Customer Decision-Makers or a Steering Committee. However, some of the issues appear to be so huge that no one thinks they’ll be able to resolve them. Instead of using the defined escalation process outlined in your Communication Plan, group consensus based on speculation and gut feeling is that by the time the Project Team is ready to start development, the issue will have been resolved by the ‘higher ups’. Thus, the old saying, “Let’s cross that bridge when we come to it.”
Unfortunately, everyone’s crystal ball that day was cloudy and/or cracked, and assumptions were proven wrong. The issue did not go away and it has suddenly become a high prior- ity need because legislation was passed to ‘make it so’.
Section III:2 System Requirements Analysis 65 NYS Project Management Guidebook
Because the team did not address or resolve the issue, a major piece of functionality for the application is missing, and has a negative downstream effect on other modules. Why oh why didn’t you escalate the issue when it arose, so you wouldn’t be in the boat you’re in now?
Taking the time NOW, during those JAD sessions, to address all issues, assess their impact and develop resolutions to them, is critical to achieving success in the ultimate design and devel- opment of the application. You will also save yourself hours of regret and heartache later.
PITFALL #3 – DESIGNING ON THE FLY
By nature, most technicians – including system developers – are natural problem-solvers. They are the kind of folks that disdain reading the twenty pages of directions, but immediate- ly start fitting the parts together by eye; the kind of people who never read the manual, but just start pushing the buttons to see what happens.
When you sit with them at a requirements gathering session, you may see their eyes glaze over and their faces assume this far-away look. This is by no means due to a lack of interest, but because they are already designing – and may be even pro- gramming – the new system in their heads, based on some ini- tial snatches of conversation.
Tell them to “Snap out of it!”
If the system requirements are not sufficiently defined and understood, the Project Team may experience “expectation gaps” – for example, the developers may build a Taj Mahal, while the Customer wanted a simple privy. At best, this may result in frustration and friction between the Project Team and the Customers – at worst, it can mean significant cost and schedule overruns that can impact many aspects of the Customer’s business operations.
The trick to successfully capturing business requirements is to make sure that the Project Team does not get ahead of itself. The Business Requirements deliverable is a detailed and con- cise list that, without passing judgment and without in any way
66 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
indicating a solution, identifies the full set of business require- ments that must be met by the system. If the list has been done correctly, the Project Team should be able to walk through it at any future point in the lifecycle and determine whether the emerging solution satisfies each requirement.
PITFALL #4 – GOT PICTURES?
Contrary to what the SDLC preaches, the wording used in Business Requirements can end up high-level, leaving many of the actual requirements open to interpretation. As this chapter has discussed, the decomposition of these requirements involves translating the business need into discrete, well- defined components that collectively provide the desired func- tionality. Therefore, you need to be creative in the ways in which these requirements are captured. Whenever possible, do not limit your understanding and representation of the require- ments strictly to the written word.
As we all know, the English language is open to misinterpreta- tion. How many of us have walked in for a haircut, described exactly what we’re looking for, and walked out 30 minutes later wondering how “Take a little off the sides” turned into “I’d like you to make me as physically repulsive as possible, so that young children cry at the sight of me, and junkyard dogs turn and flee for safety”? In this case, a picture would have been worth more than a thousand words (at least to the children and junkyard dogs of the world).
The same is true when capturing system requirements. Words like “automate”, “process”, and “calculate” may mean different things to different people, and it is essential that everyone involved in the project share the same view of these require- ments. Moving forward with an incomplete or incorrect vision of the system can be more terrifying than the haircut, except that this time, the ones running away will be your Customers. Never underestimate the power of prototyping, diagrams, illus- trations, and modeling when trying to fully represent and vali- date the requirements that your Customer is communicating to you. These techniques, and the pictures that result from them, can be worth 1000 words, and many times that in dollars.
Section III:2 System Requirements Analysis 67 NYS Project Management Guidebook
Frequently Asked Questions
What do you do if you don’t have a Project Team schooled in the art of early life cycle techniques?
The skills required for the requirements definition and analysis activities are very different from those utilized in other phases of the System Development Lifecycle. The best strategy is to get an experienced Facilitator, if only for a few initial sessions, to transfer the skills to the team. However, if no early life cycle expert is available, you need to identify candidates among your team who are best suited to an interactive mode of communi- cations, get them into some training, and have them study all available materials (including this chapter of the Guidebook). Then, make sure the team follows the SDLC methodology, and you, the Project Manager, follow the PM methodology to the let- ter, and rely on Project Sponsor and Customer Decision-Maker feedback to make sure your team is doing the right things.
How does your Project Team know when done is done?
In the normal course of events, if you have identified ALL Customers, Consumers and Stakeholders, gathered ALL their requirements as they relate to this system, built your Process and Logical Data Models, and then validated, cross-checked and verified everything, obtaining Customer and Project Sponsor approvals all along the way – then you are done! However, you are probably talking about cases when Customers keep changing their minds and you are trapped in an endless cycle of revisions and clarifications. Or cases when you keep chasing Customers who just won’t spare a moment to talk to you. In either instance, think Time Box. With the help of your Project Sponsor, declare a deadline, communicate it to all par- ticipants, and end the game there.
What if you don’t know which tools to select to help you through this phase?
While many tools exist that can simplify the creation of docu- ments, illustrations, and other materials that support require- ments analysis efforts, it should be stated that a pretty chart does not a good system make. People used to draw flowcharts by hand – and their systems did not come out any worse. The important thing is to get all the requirements, understand how
68 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
?
they relate to each other and to current and proposed business processes, and to get agreement and consensus on what will be delivered and when. And if in the process you can use some nifty tool and generate some neat documents – great!
What is the risk of just compiling all the process deliver- ables into one big deliverable, and foregoing the final deliverable: Functional Specification?
The Functional Specification deliverable has many aspects to it that its constituent parts miss (look at the annotated templates earlier in this chapter to see what they are). It is not enough to slap a bunch of work products together, tie them with a rub- ber band, and declare victory. “The whole is greater than the sum of its parts.” The Functional Specification is a document that supplies the background for the effort and organizes the work products in a logical sequence that makes it easy to understand the process and verify the result.
How do I deal with a Customer who is afraid to commit?
We’ve all dealt with folks who believe that putting their signature on that acceptance form will forever doom them to dealing with an inadequate and cumbersome system; and whether that atti- tude comes from having such forms flung back into their faces in the past in response to reasonable requests or from genuine personality disorders is beside the point: you need to get the Customer OK, and he won’t have any part of it! What to do?
For starters, don’t say, “Just trust me!” (or equivalent). Like love, trust takes a while to form, and you can’t really force it. Try to figure out what the underlying concern is. Is it fear of being locked into a particular design? Mistrust of the process used to gather the requirements? Lack of confidence in the players? Misunderstanding of the nature or purpose of the deliverable? Lack of knowledge about what will come next?
Education is the key here. Try to have a reasonable, calm con- versation with the Customer Decision-Makers. Go over the process used to gather the requirements and prepare the deliv- erable. Explain the methodology, and the intent behind it: to support the Customer’s business process with the best darn system a bunch of chip-heads can come up with.
Section III:2 System Requirements Analysis 69 NYS Project Management Guidebook
And if they are still holding up the process without a good rea- son, pull out your big gun – the Project Sponsor – and have him earn his keep.
Where in the lifecycle do I define that a phone number is ten digits with dashes and parentheses?
Yes, it’s a lot easier to record vague functionality requests (“the system should produce the required reports accurately and on time”) than to get to brass tacks and figure out exactly what is going to happen, when and how.
When you are gathering business requirements, you should document every data source the Customer mentions, and mock up every interface the Customer requests. The data elements thus captured are formalized in the Data Dictionary (part of the Logical Data Model deliverable), and then further refined dur- ing requirements reconciliation, development of the Functional Specification deliverable, and creation of the prototype. By the time technical specifications are created, your data definitions should be set in concrete.
70 Section III:2 System Requirements Analysis
NYS Project Management Guidebook
2/12/2021 How to Write the System Requirements Specification for Software Development | by Victor Osetskyi | EXISTEK | Medium
https://medium.com/existek/how-to-write-the-system-requirements-specification-for-software-development-5290c70b62a8 1/2
How to Write the System Requirements Specification for Software Development
Victor Osetskyi Follow
Aug 11, 2018 · 2 min read
As an experienced software development company, we know that writing good system requirements specification is pivotal to the success of any software project. Working with dozens of different requests from various industries we have accumulated knowledge and created a vision of how ideal SRS documentation should look like.
Existek is a custom software development company helping our customers to solve their business challenges with best in its class software. Contact us to get an instant and free expert consultation about your project.
In this article, we share our best practices for creating outstanding SRS documentation which will be both very comprehensive for the software developers and protect your project from some of the challenges you and your business may face without having well-outlined system functionality and requirements to the final software.
2/12/2021 How to Write the System Requirements Specification for Software Development | by Victor Osetskyi | EXISTEK | Medium
https://medium.com/existek/how-to-write-the-system-requirements-specification-for-software-development-5290c70b62a8 2/2
List of the Contents
What is the system requirements specification
Why SRS is an important part of the software development process
How to write a specification for your project
What to avoid writing a requirements specification
A practical example of the good and bad SRS
In conclusion
………………………………………………………………….
Read the full article about How to Write the System Requirements Specification for Software Development and share your thoughts on it.
Having difficulties creating the specification requirements or define user workflow and experience for your custom software project? Existek is an innovative offshore software development company experienced in the creation of the custom software solutions for the small, medium and large-scale enterprises. Fill in the form or contact us directly at the live chat at our website and we will provide you with a free consultation, help you to set goals for your project, pick up best technologies and engagement model, outline specification requirements and give an estimation of the budget and time needed to complete your project.
- IFSM 301 – Week 7 Citations
- Bibliography
- Practical Guide to Federal Enterprise Architecture
- Best Practices in Enterprise Architecture - GAO
- Best Practices in Enterprise Architecture
- Best Practices in Information Security - GAO
- Best Practices in Information Security
- THE_UKS_LEADING_PROVIDER_OF_EXPERT_SERVICE6
- Requirements
- Developing Requirements for an IT System
- systemreq
- How to Write the System Requirements Specification for Software Development _ by Victor Osetskyi _ EXISTEK _ Medium
