Transit Enterprise Architecture and Planning Framework (2011)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

17 Building on the best practices from the research synthesis and literature survey, plus input from numerous transit agen- cies and workshops, the Transit Enterprise Architecture and Planning Framework project created the TEAP Framework, which includes guidance and tools for transit for successfully implementing IT/ITS projects. The Framework and tools are described in detail on the project’s wiki website at www.tcrp- teap.pbworks.com. For each of the five key elements of the Framework (Enterprise Architecture Planning [EAP], Funding Implementation Methods, Business Case Methodology [BCM], Systems Engineering [SE], and Post-Implementation Analysis [PIA]), the wiki has a section on the “What, Why, and Benefits” of the element, a section on “Best Practices,” and a section on “Additional Resources” such as references, examples, and tools. In addition, the Framework guidance describes the relationship among the Framework areas. As it is defined, the Framework incorporates and supports many aspects of IT governance. The TEAP Framework, as illustrated in Figure 2, shows how the elements flow and relate to each other at a high level. When the Framework elements are used together, the value of the Framework is much greater than individual elements. In par- ticular, the information modeled in the enterprise architecture (EA) improves the speed and validity of the business case and the systems engineering process. It also improves the accuracy of the funding and post-implementation analysis efforts. For example, when a business case is needed to implement an asset management/work order system that includes passen- ger facilities, the EA shows how many applications depend on the current and up-to-date information contained in the bus stop inventory that is managed and continuously updated by the system. The EA shows the critical functionality of the asset management system, payback in productivity, relationship to corporate objectives, and impact on staff resources and business processes. With respect to the SE process, the sys- tem description; needs, roles and responsibilities; interface requirements; key system requirements; and impact on tran- sition may be generated from querying the EA model. With information from the EA, the SE analysis can be completed significantly more quickly and accurately. This chapter is divided into two parts. The first part provides an overview of the TEAP Framework. The second part describes how the TEAP Framework wiki supports transit agencies in learning about the Framework and tools, implementing more successful IT/ITS projects, and finding other agency-related work examples. TEAP Framework Overview The Framework helps transit professionals understand the financial, operational, and management impacts of technolo- gies, to help them better meet their enterprise business process needs and corporate objectives. The Framework will also help guide an agency’s IT/ITS planning process, improve its under- standing of risks, better manage the project implementation effort, validate and verify compliance with its needs, and mea- sure results and benefits. Specifically, the TEAP Framework guides transit in: • Planning how information, services, and technology will connect across an enterprise to support business processes, solve problems, and measure performance; • Promoting information sharing across agency and institu- tional barriers; • Ensuring that IT/ITS projects are defined and staged in a way that ensures best value and supports successful project implementation, operations, and maintenance; • Ensuring that the benefits and costs of proposed IT/ITS projects are understood across the project’s lifecycle (includ- ing operations and maintenance) and that resources are available to support the program; • Specifying IT/ITS projects to maximize the IT/ITS invest- ment decisions across the organization; • Ensuring that IT/ITS projects meet stakeholder needs: requirements are explicitly described, risks are identified C H A P T E R 4 Development of the TEAP Framework

and mitigated, and the system development process is man- aged to ensure that correct operations and requirements are met; and • Describing the leadership and processes that ensure that the organization’s IT group supports and extends corpo- rate strategies and objectives. What are the TEAP Framework elements? The TEAP Framework comprises five elements, shown in Figure 3. They provide tools for planning, developing, deploy- ing, and evaluating the systems and technologies that best meet an organization’s objectives. These key elements of the Framework are: • Enterprise Architecture Planning (EAP) and Enterprise Architecture (EA) development process (developing the blueprints); • Business Case Methodology (BCM) (how well does this project fit into the stated priorities; what are the risks, 18 POST- IMPLEMENTATION ANALYSIS BUSINESS CASE METHODOLOGY Potential Projects Approved Projects Project Flow Supporting Information Flow KEY EAP Enterprise Architecture IT/ITS Strategic Plan • Performance • Business • Data • Applications • Technology SYSTEMS ENGINEERING • Budget Process • Operating & Capital :: Programs FUNDING INPUTS • Vision / Mission / Goals • Internal • External / Regional Figure 2. Transit enterprise architecture and planning framework. Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering Figure 3. TEAP Framework elements.

benefits and costs, and estimated return on investment [ROI]); • Funding (how to pay for IT/ITS projects); • Systems Engineering for helping to design and manage an IT/ITS Project implementation; and • Post-Implementation Analysis (PIA) to assess whether the implementation met project and agency goals and achieved a meaningful (estimated) ROI and to review the project implementation experience for lessons learned. Looking at each element in more detail clarifies the role each plays and how they work together to create a successful TEAP Framework. Enterprise Architecture Planning (EAP) and Enterprise Architecture (EA) Overview The Enterprise Architecture Plan- ning (EAP) process is a set of activi- ties used to develop the Enterprise Architecture (EA) models, diagrams, and descriptions. The process relies on stakeholder input to document the agency’s current performance mea- sures, business processes, data, appli- cations, and technologies, reflecting the organization’s “as-is” architecture. Next, a “to-be” architecture is developed that documents where the organization wants to be with respect to its business in the future. A 4- to 5-year horizon works best here. It consists of the corporate mission, goals, objectives, and the business processes, data, applications, and technolo- gies that are needed to support that vision. The third step describes the gap between the present (“as-is”) and the future (“to-be”) and how to close it. The EAs, both the “as-is” and “to-be” architectures, are composed of four or five models (Business, Data, Applications and Technology, plus in some approaches a Performance model) that are depicted in one or more diagrams, policy statements, procedures, inventories, or other pieces of information. The term used to describe these is “artifact.” Business Case Methodology (BCM) Overview A BCM is a formal analysis used to justify and capture the reasoning for initiating a project. The TEAP Frame- work includes information on how to implement a BCM at a transit agency and guidance on how to build an appropriate business case for a tech- nology project. The business case typically reviews and verifies that: • The proposed investment has value and importance • The project will be properly managed • The organization has an adequate plan and the capability to deliver the benefits • The organization’s resources are working on the highest value opportunities • Projects with inter-dependencies are undertaken in the optimum sequence (2). Funding Implementation Overview IT/ITS Project Funding Implemen- tation discusses approaches for obtain- ing and making use of various sources of funding for IT/ITS projects. Like IT projects in general, transportation IT and ITS projects are delivered through public leveraging options like bond financing, public-private partnerships, co-mingled funding, and a variety of federal, state, and local funding sources. Transit agencies are using many of these financing mecha- nisms to access the various sources of capital for IT/ITS proj- ects. Historically, buy (pay-as-you-go), borrow (issue bonds), or lease were the primary financing mechanisms used by transit agencies. Since the 1990s, there has been more creative use of these traditional mechanisms and the introduction of public-private partnerships. Financing mechanisms, par- ticularly four categories—debt mechanisms, capital leasing financing, equity and partnerships, and credit enhancements— have been important. Based on a modest survey of transit agencies, it was found that no single financing method works for all situations; rather, financing decisions need to be tailored to the specific project, region, and financial circumstance. Systems Engineering (SE) Overview Systems Engineering (SE) is a disci- pline that helps ensure that customer needs are implemented in the system that is developed. Customer needs are defined by those who have a vested interest in the system, such as a user, a manager, or someone impacted by the operations of the system (e.g., recipi- ent of information or process coordination partner). Customer needs drive the system requirements, or what the system should do. For example, if there is a need to measure 19 Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology FundingSystemsEngineering Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering

ridership at stops for each trip and an Automated Passenger Counting (APC) system is being proposed to do the counting, then there must be a corresponding system requirement for the APC system to count boardings and alightings at each stop by trip identifier. The SE process ensures that the requirement is described in the design and consequently implemented in the software and that data is collected, stored, and reported in a format that supports its use as a performance measure. The steps prescribed by the SE process ensure a structured approach to track customer needs throughout the development stages of an IT/ITS project. U.S. DOT recognized the potential benefit of the SE approach for ITS projects and included requirements for the use of the SE process in the FHWA Final Rule 940/FTA Pol- icy on ITS Architecture and Standards that was enacted on January 8, 2001. Post-Implementation Analysis (PIA) Overview Post-Implementation Analysis (PIA) or Post Implementation Review (PIR), as it is commonly called in the IT field, is conducted at the final stages or right after a project has been completed. “The purpose of the PIR is to evaluate how successfully the project objectives have been met and how effective the project management practices were in keeping the project on track” (3). This information can be used to improve project management processes and guide where the next set of invest- ments should be made. The PIR and associated ROI analyses can also help demonstrate how the project made a difference and identify lessons learned. The PIR is not the testing and verification activities that are typically performed in a project acceptance or closeout phase. For example, an Automatic Vehicle Location (AVL) system may have to be accepted from a vendor if it performs accord- ing to the requirements in the Request for Proposals (RFP), passes the test plan, and satisfies the SE verification process. However, the system may not perform the way the users want. Perhaps the business changed or the project was speci- fied ambiguously and/or incorrectly in the RFP and System Requirements. The PIA plan is also sometimes called a Vali- dation Plan. In summary, the PIR occurs after the IT/ITS system has been incorporated into the business and assesses how well the project meets the users’ needs, what needs to be done next, and how well the implementation process went. Developing and sharing lessons learned can continuously improve the agency’s project acquisition and management processes. How do the TEAP Framework elements relate? As illustrated in Figure 2, the TEAP Framework elements build on the models, analysis, and reports generated in the previous stage. The Framework value is greater than the sum of its parts. It also improves the quality and completeness of the downstream products. A well-developed business case helps ensure that a project gets funded and that the funding is at the appropriate level. It also helps ensure that the plan and resources are available to gather baseline data needed to prove that the project made a difference during the PIA. Information from the systems engineering steps can help decision makers advance a project effectively through funding “decision gates.” During the course of this project more transit agencies began focusing on IT project management and governance of these projects. IT staff began to realize the importance of creating a solid foundation on which to make good business decisions on funding, operating, and maintaining technology deploy- ments. In order to show a solid return on investment and measure success, it is essential to understand the connections, bottlenecks, and stresses across the enterprise. The foundation of this information is represented in the EA. Therefore, mak- ing the EA process less costly and time consuming became a need of the TEAP Framework. TEAP Framework Wiki Overview The medium that presented the TEAP Framework needed to address three major areas—audience presentation, inter- activity, and collaborative environment. The specific needs that were addressed included: • Develop guidance on the TEAP that targeted multiple audi- ences (without intimidating any of them by the size of the document). • Present the material using a medium that was logical, easy to use, and allowed for seamlessly showing the relations among the elements (and linking to external resources). • Provide the industry with a site where collaboration and information navigation was intuitive and easy to use while preventing spamming and misuse of the site. The Framework and element descriptions, best practices and resources needed a medium where the relationships between the elements were visible, and the connections to additional resources and tools were seamless. A website by its nature proved to be the best medium to present the information. The materials were accessible and various audiences could easily find guidance that was commensurate with their knowledge and responsibilities. Yet in recognition of the changing nature of the topic, and the need for transit professionals to collab- orate, a user-driven website was needed. A wiki allows users 20 Enterprise Architecture Planning (EAP) Post- Implementation Analysis Business Case Methodology Funding Systems Engineering

with permission to contribute and work together in a loosely connected community. The wiki format provides a means of directly soliciting new and updated guidance from registered users on their questions, recommendations, approaches, and practices. The format enables “trusted” writers to contribute and share information in a transparent environment on best practices and new methods. Also, using a wiki to store the project’s findings allows for ongoing updating and expanding of the content. Target Audience and Wiki Sections There are several open source wiki applications and numer- ous information service providers (ISP) that provide a wiki “in the cloud.” The research team, in order to focus on the content rather than the technology, elected to use an ISP. The site (http://tcrp-teap.pbworks.com) allows cutting and past- ing from word processing documents, uploading of different file formats, display of graphics, and application of several html and Java script functions. All changes are recorded and ascribed to the user who made the change providing robust configuration management functionality. The research team populated the site with the TEAP Frame- work Guidance, tools, and a Transit EA/EAP Guidebook. The site lays out the Framework Guidance in a systematic way with sections targeting different audiences, from executives and senior managers to program managers and technical practi- tioners (see Table 4). TEAP Guidebook Guidebook Purpose and Scope The Transit Enterprise Architecture Planning (TEAP) Guidebook differs from the TEAP Framework in that the Framework describes general benefits, best practices, and 21 with respect to each of the elements. This section includes a self-contained, downloadable version which can be printed and read in hard copy. TEAP Framework Guidance: • Executive Summary • EA/EAP • BCM • Funding • Project SE • Post- Implementation A detailed description of each TEAP Framework element, including: information on the “What, Why and Benefits” of the element; “Best Practices” and streamlined approaches; and “Additional Resources” with references, tools, and examples from the IT and transit industries. Program managers and transit professionals who want to learn more about the topics Transit EAP Guidebook The Transit EAP Guidebook details step-by-step how to develop a transit enterprise architecture (as-is and to-be). The Guidebook shows how to customize the Reference Enterprise Architecture for Transit to represent the drivers, business processes, information, applications, and technologies in your organization. The Guidebook is an interactive and extendable “space” on the wiki to describe a Reference Enterprise Architecture for Transit, and to include related terms and techniques for implementing a Transit Enterprise Architecture. It includes models, templates, examples, and benefits associated with each step. Program managers and transit practitioners who are tasked with implementing an EAP and maintaining the as-is and to-be enterprise architectures State of the Practice Synthesis Results A summary of the State of the Practice Synthesis related to the five elements of the TEAP Framework. All Other Resources How-To Guides Glossary and Acronym List FAQs About the Project and the Wiki Site Map Improvement Page All ecneiduA noitpircseD ikiW krowemarF PAET Guidance for Transit Managers A high-level description of the TEAP Framework, including the purpose and benefits associated with each Framework element and their interrelationships. In addition, the guidance includes a checklist that enumerates the roles and responsibilities of transit managers Transit executive and senior managers Table 4. TEAP Framework wiki sections.

resources for the five system development disciplines, while the TEAP Guidebook describes details related to how to implement a Transit Enterprise Architecture by customizing the Refer- ence Enterprise Architecture for Transit and other resources. The Guidebook describes the terms and techniques used by transit and other architecture experts. The Guidebook may be seen as an evolving process; as more transit agencies develop architectures, concepts, techniques, and resource materials, the resources and guidance in this section will grow. The site allows for extensions and conversations among practitioners as the experience developing TEAP grows in the industry. Guidebook Audience and Prerequisites The TEAP Guidebook targets transit staff who understand both the transit enterprise domain and basic organization of an Enterprise Architecture Process (EAP). (The materials presented in the TEAP Framework section on EAP should provide enough background to the reader to understand the Guidebook method.) Guidebook Organization The Guidebook is inserted into the “Best Practices” page of the TEAP Framework, EA/EAP section of the wiki. The Best Practices page is used as a launch pad into the pages that con- stitute the Guidebook. The need to make the material inter- active and the huge amount of material that is contained in these pages makes it efficient to document the material exclu- sively on a website and not compile it into a voluminous paper document. The Guidebook is divided into two major parts: • Description of the Reference Enterprise Architecture for Transit – Including solutions for different segments of the architecture – Instructions on augmenting or changing the reference architecture – Instructions for customizing the various models in the architecture and changing the relationships between enti- ties in different models (e.g., measures and information) • Streamlined process and guidance on applying the Refer- ence Enterprise Architecture for Transit – Where do you start? – Step by step directions for getting started – How do you drill deeper into the details of your enterprise? The Reference Enterprise Architecture for Transit is described in Chapter 5. The streamlined process is described in further detail in the following sections. Streamlined Process for Developing a Transit Enterprise Architecture A recurring theme during the state of the practice review was the lack of resources needed to create the enterprise archi- tecture. Transit professionals needed a more effective way of collecting and organizing their information without mar- shalling their entire IT staff for the effort. Some transit staff indicated that they did not even know where to start. Based on this feedback, the wiki includes a section on how to get started. The development of the Reference Enterprise Architecture for Transit provides building blocks to accelerate development of a high-level TEAP. The streamlined process uses the Reference Enterprise Architecture for Transit to develop templates (which may be populated) and guidelines on how to collect informa- tion to populate or edit the templates. The Reference Enterprise Architecture for Transit provides transit agencies with a basic starting point that they can use to customize their organization. It contains descriptions of the business processes, information views, types of transit applica- tions, and similar devices and technologies used by the indus- try. It also builds the connections and dependencies between the architecture drivers (goals, measures, standards, regional agreements) and the enterprise architecture. The entities and relationships are captured in a metamodel (see Chapter 5). The metamodel is a way of classifying the enti- ties in transit and showing how they relate. Similar to a data- base, the metamodel is the database schema and the reference model is the content of each table in the model. The streamlined approach describes how to edit or collect/ populate each layer of the Reference Enterprise Architecture for Transit using a template or worksheet included with the instruction. Examples from existing agencies are included with the guidance. Suggestions for additional data collection fields are included in the discussion. Moreover, the streamlined approach includes a section on purpose that describes exam- ples of “what if” scenarios. Additional information about the streamlined approach may be found in Chapter 5. Wiki Site Review and Validation The research team addressed the wiki’s usefulness as a tool for the industry at several stages of the project. As a part of the project’s validation task, a group of transit professionals, some of whom participated in the research synthesis process and others who did not, were asked to participate in up to three webinars to discuss the wiki. During the webinars, team mem- bers walked through the site, asking questions and describing the functionality. Participants consistently found the site intu- itive and useful. The results of these workshops were incorpo- rated into the latest version of the site. The full report may be found in Appendix C. Additional improvements to the wiki 22

were also made based on the pilot results, which are described in Chapter 6. Vision for Augmenting the Wiki (Guidebook and Reference TEAP Artifacts) The wiki site is critical to presenting the research because it provides a forum for transit professionals to share their expe- riences with each other and enhance the Guidebook based on new lessons learned and experiences. During the validation workshops, participants were asked who should be able to update and change the wiki and its content. The participants unanimously agreed that editors of the wiki should monitor and agree on its content (see Figure 4 for description of user roles and access levels). There are two approaches for submitting wiki content and changes: through comments or by adding to/changing a wiki page. Any user may submit a comment at the bottom of most wiki pages. Some pages are locked and may be changed only by someone with administrator-level access. Other pages may be created and/or changed and documents can be uploaded by users with editor- and writer-level access. 23 Access Levels As an Administrator, you can rename or delete anything on the workspace. Administrators can add users, change their permission levels, or remove them. Administrators alone have access to the workspace's Settings page and are also the only ones who can change page- and folder-level security settings. Administrators are the only ones who can see Hidden pages or edit Locked pages. Editors are trusted helpers who are highly privileged Writers. They can rename or delete pages, files, and folders. Editors should be highly trusted, since they can delete your data irrevocably. The recommended default for invited users. Writers can edit pages and revert pages to previous versions. They can also upload new files and create new pages. Writers cannot perform any action that cannot be undone. Readers cannot make any modifications at all to a workspace. They can view pages, RSS feeds, and files. They can also see the history of changes that have been made to a page. By default, readers can make comments on a workspace, without being able to edit the workspace itself. This setting can be modified by going to "Settings" and then "Workspace Security" [from http://usermanual.pbworks.com/w/page/11632102/Inviting-Users]. Figure 4. Wiki access levels.