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.

9The Transit Enterprise Architecture Planning (TEAP) Framework project consisted of two phases. This chapter provides a description of the project tasks, including the methodology used to perform them. Phase I: Development of the TEAP Framework The Phase I research focused on understanding how transit agencies and transportation authorities currently understand, apply, and use each of the five system development methods that compose the TEAP Framework. Building on their meth- ods and best practices, the project fused these practices into a coherent framework that showed the connectedness and flow of each development method. As described above, the project objectives involved describing the Framework for several audi- ences including executives, senior managers, practitioners, and program managers. In addition, detailed guidance would also include a technical audience such as the chief information or technology officers and their staff. Further, the means and channels used to disseminate the findings and Framework had to be collaborative and evolving because the Framework tech- nologies and methods change quickly. A paper report, such as this, may be used as a reference once in a while, but it cannot be used as a tool that facilitates community exchange and extensions. To that end, the means of documenting the Frame- work was also selected as part of the Phase I effort. The first part of this phase consisted of gathering informa- tion from the literature and interviews on the state of the practice related to the five framework planning areas: • Enterprise Architecture and Enterprise Architecture Plan- ning (EA/EAP); • Business Case Methodology (BCM) for identifying, justi- fying, and selecting ITS projects • ITS Funding Implementation, focusing on program invest- ment strategies and their relationship to IT Governance; • Systems Engineering (SE) related to its benefit and role in a project’s success, as well as its relationship to the funding and project approval process; and • Post-Implementation Analysis (PIA) including goals, approaches, and key issues. C H A P T E R 2 Research Approach—Methodology A wiki is a collaborative website where wiki members may edit, review, upload documents, and add their comments. The TEAP wiki is open for anyone to view, but available only to members to edit. During the interviews and literature search, the research team collected examples of performance measures used in post-implementation analyses, highlighted different method- ologies and approaches, and developed an annotated bibliog- raphy of relevant transit publications and tools/resources in the IT industry. The results of the research synthesis are described in Chapter 3. Building on best practices from the transit industry and other industries, a wiki or collaborative website (see sidebar) was developed to document the recommendations for the Frame- work. The resources collected during the synthesis tasks were inserted into the wiki as a portal to find existing resources that explain the multitude of approaches that are available through NTI, APTA, FTA, and other outreach efforts. Another critical product that was developed for the wiki was a high-level sum- mary of the Framework for executive and senior managers (see Appendix A). This guidance document explains the need to implement all or part of the Framework, describes the Execu- tive’s role with respect to IT governance, gives details on how to use the enterprise architecture to justify and measure successful implementations, and identifies and provides links to a rich set of resources that may be used to establish the TEAP Framework.

In addition to the high-level summary, the wiki was divided into sections that highlighted the five planning areas and other pages that contained the synthesis results or provided help for technical and non-technical wiki readers and editors. A site map is also included. Each planning area includes discussions on: • What, why, and benefits; • Best practices; and • Resources about the topic related to transit and other IT communities. Several interviews and webinars were conducted to evalu- ate different aspects of the guidance and wiki site. The research validation effort focused on obtaining stakeholder feedback on multiple facets of the Framework, guidance, and tool con- cept. Much of the feedback is reflected in the organization and material included in the current site. Phase II: Reference Transit Enterprise Architecture Process The Phase II effort focused on refining the guidance, specif- ically the enterprise architecture components. The state of the practice revealed that though many organizations wanted to develop enterprise architecture models, they did not want to expend the huge effort it required. Other industries, particu- larly public sector organizations, deal with this obstacle by developing reference models that may be used as a template. WMATA offered their existing enterprise architecture planning (EAP) model as a starting point for the reference model. So the Phase II effort focused on adapting the WMATA EAP for use as a generic reference enterprise architecture for transit. Part of the development and validation process of the ref- erence TEAP involved convening a peer review panel, com- posed of experts in enterprise architecture and transit IT domains. Through a series of workshops and interviews, the panel selected a segment of the transit enterprise for which to develop detailed solutions (see sidebar). The expert panel selected the fare management architecture segment and four solutions architectures. In addition, the WMATA EAP was updated to reflect a “generic” transit agency. Additional guid- ance was developed for transit staff that explained how to use and customize the reference TEAP and fare management solution architecture models. Detailed examples were also included in the guidance materials. These are described in Chapter 5. One or more transit agencies were solicited for piloting the reference TEAP and addressing how the solution architectures could help them develop “as-is” and “to-be” architecture mod- els. Guidance was developed for most of the agencies, and several of them used the templates to validate the approach. Results from these pilots were solicited and documented in Chapter 6. In addition, several of the expert panel members who attended the workshops and reviewed the reference TEAP and wiki were interviewed about enhancing the wiki. Results of these interviews are also included in Chapter 6. 10 A Solution (or solution architecture) in enterprise architecture is a cross-cutting segment of an architecture that allocates functions, information, applications, and technology in different configu- rations to solve specific problems and develop requirements, usually through the design of specific information systems or applications. For example, there are different commercial tools to implement different approaches to fare management, such as (regional vs. agency) smart cards, mobile devices, and open payment systems. Typically, there will be different types of solutions (approaches for implementing applications and technologies) for every major system in the transit enterprise. Each solution may affect relationships among the business processes and information views.