Concept for an e-Transit Reference Enterprise Architecture (2004)

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.

13 CHAPTER 3 APPROACH: e-TRANSIT REFERENCE ENTERPRISE ARCHITECTURE DEVELOPMENT This chapter explains the proposed approach for the Phase II development of the e-transit reference enterprise architecture, clarifies assumptions within the approach, and addresses potential issues that are known to exist. It also pro- vides a list of potential resources and sources of information that may be used throughout the project and describes in more detail expected products and how they are intended to be used. 3.1 APPROACH As stated in Chapter 1, a need exists to develop an overall context and framework that can be used to quickly assess the impacts and potential opportunities of changes and emerging technologies. An e-transit reference enterprise architecture will provide this context for identifying potential e-transit opportunities and a framework for examining changes trig- gered by government requirements and emerging technol- ogy. Systems engineering principles and practices will be used to help understand the relationships and inputs stored in the reference enterprise architecture. Thus, a simplified out- line of the approach is as follows: 1. Collect information on current and planned transit agency business objectives, people and their roles, processes, technologies, and applications. Also identify existing and emerging e-transit applications and potential e-concepts from other industries. 2. Develop the As Is “Transit Today” base scenario by combining the above information with assumptions that define a “typical” major transit agency operating in a large urban region. Place the information and relation- ships that describe this scenario into an enterprise archi- tecture model. 3. Use systems engineering principles and concepts and forecasts of industry and technology trends to define the To Be “Transit of the Future” scenario business goals, objectives, and concept of operations. 4. Develop the requirements and criteria for the transition from the As Is scenario to the To Be scenario. Use the scenarios for “gap analysis” and for evaluating different system configurations and e-transit applications for reaching the To Be future. Add the information and relationships that describe this To Be “Transit of the Future” scenario into the previous enterprise architec- ture model. 5. Use the resultant e-transit reference enterprise archi- tecture as a tool to assess new e-transit applications and concepts and the impacts of these concepts on the busi- ness requirements, people and roles, processes, and technologies of today and the future. 6. Develop guidance and examples of typical applications of the reference enterprise architecture to help its use by the TCRP e-Transit Project Panel and the transit industry in general. There are many different future scenarios that can be de- veloped based upon different assumptions and priorities (i.e., goals, objectives, and visions of the future). This ap- proach is an e-transit reference enterprise architecture rather than a generic transit enterprise architecture because of its emphasis on incorporating e-transit applications into the To Be “Transit of the Future” scenario. This emphasis will pro- duce an e-transit–centric vision of the future system, with e-transit applied where it is found to be cost-effective, and capture how e-transit might transform the business processes, roles and responsibilities, applications, and technologies as a result. The approach also assumes continual collaboration with the TCRP e-Transit Project Panel and the transit indus- try in order to properly develop and represent both As Is and To Be scenarios. Details and issues associated with the above approach are explained further below. These include further discussion of the relationship between enterprise architecture and systems engineering, the definition of e-transit and how it relates to ITS and other advanced technologies, the assumptions for defining the As Is and To Be scenarios, and ways to address the National ITS Architecture and other efforts that overlap or include e-transit. 3.1.1 Using Systems Engineering within the Enterprise Architecture Framework Again, systems engineering practices and concepts will be used to help determine the needs and goals of today’s transit “business” and how they evolve to meet transit’s

future vision, define the concepts of operation as we move toward the future vision, define the business functions and their requirements, and assess future e-transit opportunities and how they might be implemented. The reference enter- prise architecture is the repository for the information and relationships that result. The reference enterprise architec- ture for transit services would focus on capturing the out- puts of the systems engineering process (e.g., missions, business cases, organizations, flows, functions, and users), including • All transit business processes that support customer ser- vices as well as transit agency operations, • Interface and data flow relationships for all processes, • Who carries out each function and their motivation, • Time requirements, and • Transit and communications security concerns. Both systems engineering and enterprise architecture are needed in order to visualize the complex relationships be- tween people, processes, and technologies and how they re- late to an agency’s overall business requirements and to have the ability to quickly assess the impacts and opportunities of emerging e-transit concepts or other changes to the transit operating environment. Systems engineering is often discussed and applied with respect to the development and implementation of specific projects and complex systems. Consequently, a significant part of traditional systems engineering application deals with determining requirements and design specifications, manag- ing the project as it is implemented (i.e., managing change), and verifying and validating the system to ensure that it meets (or will meet) the original objectives. Our development of a reference enterprise architecture is based on systems engineering applied at a higher conceptual level, which requires evaluating and selecting tools and tech- niques that focus more on the initial steps of the overall process (e.g., stakeholder identification and needs analysis, operational concept, and high-level functional requirements). An example is the creation of a “functional requirements model” (FRM) that maps stakeholders (both internal and ex- ternal to a transit agency) and their operational roles and needs (i.e., business cases) in a three-dimensional frame- work. It captures who is impacted, what must be done, and the connections between them in order to meet each need. Fig- ure 3-1 shows a conceptual FRM framework that Mitretek proposes for developing an e-transit reference architecture. For example, the cell for “Provide Reliable Transit Services (need), Plan Facilities and Services (functional role), for a Transit Agency Service Planner (Stakeholder)” would describe carrying out reliability analysis of existing routes, identifying causes of delays (e.g., recurring congestion, high- accident locations, and train crossing), and developing re- route and other strategies to overcome the delays. A vertical slice would show all of the functional roles, stakeholders that 14 carry them out, and the functions (i.e., cell contents) that address a particular need or business objective. The earlier question posed on how systems engineering is related to enterprise architecture is answered in Figure 3-2. Modeling skills dominate the procedures used to develop, sus- tain, adopt, and use an enterprise architecture that communi- cates to non-engineers and supports agency planning through its integrated view of the important pieces of the enterprise as a whole. Systems engineering practices and principles will first be used to develop the As Is “Transit Today” base scenario con- cept of operations (i.e., constraints, needs, and goals) and business requirements and to identify the functions, people and their roles, and technologies that are used to meet the requirements and concept of operations. Again, the informa- tion and relationships that result will then be stored in the ref- erence enterprise architecture. A similar exercise will also be conducted to define the e-transit–centric To Be “Transit of the future” scenario. Because we are developing a conceptual planning tool, the e-transit reference enterprise architecture will remain at a high level, focusing on the requirements for information needs, functions, and types of applications and technologies needed to implement the e-transit concept of operations and not spe- cific data formats, brands of technology, or software vendors and products. This focus is equivalent to the scope (i.e., con- textual) and enterprise model (i.e., conceptual) layers of the Zachman Framework. This type and level of enterprise archi- tecture can be captured by the following:21 • Business Model. Describes the business organization, requirements, and functions used in conducting the busi- ness (Row 1, “Planner, Conceptual,” perspective of the Zachman Framework). • Information Architecture. Defines the major kinds of information needed to support the business (Column 1, “What, Data,” Rows 1 and 2, of the Zachman Framework). • Applications Architecture. Defines the major kinds of applications needed to manage the information and sup- port the business functions (Column 2, “How, Func- tions,” Row 2, “Owner, Conceptual,” of the Zachman Framework). • Technology Architecture. Defines the technology plat- forms needed to provide the operational environment for the applications that manage the information and support the business functions (Column 3, “Where, Net- work,” Row 2, “Owner, Conceptual,” of the Zachman Framework). The reference enterprise architecture that results should still be able to explore e-transit opportunities under a variety of situations (e.g., single agency or multiple agencies within 21Spewak, Steven H., and Steven C. Hill, Enterprise Architecture Planning: Devel- oping a Blueprint for Data, Applications and Technology, A Wiley-QED Publication, John Wiley & Sons, Inc., New York, New York, 1992.

15 State & Local Government Federal Government Private Sector Transit Agency Cell What each stakeholder’s functional role is to meet each Need/Requirement Transportation & Public Safety Agencies Other Transit Traffic Operations Public Safety Incident Management Transit Board General Manager Senior Staff Facility Planner Service Planner Scheduler/Runcutter Operator Street Supervisor Dispatcher Maintenance Staff Finance/Accounting Staff Information Technology Staff Purchasing Officer Contract Officer Legal Staff Human Relations Public Relations/Customer Service Fu nc tio na l R ol es Business Objectives, Needs Provide Transit Service Ridership Analysis & Market Research Plan Facilities & Services Design and Construct Facilities Schedule Services and Operators Operate and Manage Planned Services Provide Special Services Obtain Revenues Provide Outreach and Marketing Monitor Performance Maintain assets Hire, Fire, and Provide Benefits Provide Legal Services and Contracts Coordinate with Other Agencies & Governments Provide Materials and Supplies Provide and Maintain Information Technologies M ee t R eg ula tio n Le ga l R eq ui re m e n ts O bt ai n fu nd in g Co or di na te w ith O th er A ge nc ie s Pr ov id e Tr a n si t S er vic es R el ia bl e Sa fe & Se cu re Ac ce ss ib le to Al l M ai nt ai n Pu bl ic Su pp or t Co st - Ef fe ct iv e Se rv ice M ax im ize R id e rs hi p Pr ov id e Li fe lin e Se rv ic e s St ak eh ol de rs Fu nc tio na l R ol es M ee t R eg ula tio n Le ga l R eq ui re m e n ts O bt ai n fu nd in g Co or di na te w ith O th er A ge nc ie s Pr ov id e Tr a n si t S er vic es R el ia bl e Sa fe & Se cu re Ac ce ss ib le to Al l M ai nt ai n Pu bl ic Su pp or t Co st - Ef fe ct iv e Se rv ice M ax im ize R id e rs hi p Pr ov id e Li fe lin e Se rv ic e s Figure 3-1. Functional requirements model framework proposed for e-transit. Systems Engineering Procedures Creating models of existing systems, Describing linkages of those systems, Modeling established data and process flows, Modeling future systems, Traditional SE procedures Engineering Modeling Skills Support an Enterprise Architecture Enterprise Architecture e-Transit Repository for information and relationships: - People - Processes - Technology - Business Requirements Figure 3-2. Systems engineering procedures that support e-transit enterprise architecture.

a region; different combinations of bus, rail, or paratransit ser- vices; different levels of legacy technologies and systems; and different local government structures, regional organizations, and statutory mandates). Consequently, where possible the As Is base scenario will include sub-options and systems that may be isolated within the overall scenario to examine these questions. Systems engineering principles and practices will then be used to prepare gap analyses between the two concepts of operation, to define the requirements and criteria for the evo- lution and transition of the system, and to develop and eval- uate alternatives for making the transition. Care will also be taken to incorporate stages of technological development and the transition from one stage to another within the overall framework and evolution to the To Be “Transit of the Future” scenario. Figure 3-3 shows a high-level view of the gap analysis between the two architectures and the transition to a target enterprise architecture. 3.1.2 Defining e-Transit Re-Visited One of the first tasks associated with any systems engi- neering or enterprise architecture effort is clarification of the system and problems being addressed. If this initial “scop- ing” is not carried out, it is likely that the alternatives exam- ined and the potential applications that result may be too nar- row to solve the problem or the issues and boundaries of the system included in the analysis may expand beyond the point that they can be addressed. Consequently, in order to help bound the Phase II development of an e-transit reference enterprise architecture and understand the focus of the over- all TCRP J-09 e-Transit Program in general, additional clar- ification of the definition of e-transit is provided below. As stated in the introduction, the effort will derive its def- inition of e-transit from the broad roles of e-government and e-business as “The use of digital technologies to transform government operations in order to improve effectiveness, efficiency, and service delivery.”22 16 However, if a liberal interpretation of this definition is made, e-transit can quickly expand to include all ITS, IT, advanced communications, and other technology activities within a transit agency. This broad definition is not the intent or focus of the e-transit program or Phase II effort. For exam- ple, upgrading existing autonomous applications and sys- tems that do not change or add either functionality or new channels of communication should not be considered part of e-transit. The definition of e-transit that will be used should therefore be refined to include applications and services that deliver a service to someone externally or internally23 and • Provide additional functionality, integration, or inter- actions to expand the responsiveness or access of the enterprise and/or • Use new channels of communication and information flow provided by advancing digital technologies. For example, implementing a stand-alone spatial database or geographic information system (GIS) within an application (e.g., a scheduling/run-cutting system) is not e-transit, while integrating all spatial database needs and applications within an enterprise GIS that is accessed through the agency’s com- puter network and intranet is. e-Transit is also much more than just e-commerce or the establishment of a transit agency website or intranet. e-Transit includes applications and functions for providing the follow- ing transactions: • Government (i.e., transit agency) to consumer (both ex- isting and potential transit passengers), • Government (i.e., transit agency) to citizen, • Government (i.e., transit agency) to business, • Government (i.e., transit agency) to employee, Figure 3-3. Implementing a target enterprise architecture using gap analysis. 23 “Service delivery is the key for e-government. Without delivery of service to some- one, internally or externally, the process cannot be considered e-government” (“What is e-Government? Gartner’s Definitions,” C. Baum, A. Di Maio, F. Caldwell, Gartner- Group Tutorials, TU-11-6474, Research Note 11 August 2000).22Mark Forman, OMB Associate Director for IT and eGovernment, September 2001.

• Government (i.e., transit agency) to government, • Business to business (in support of transit activities), and • Business to consumer (in support of transit activities). Figure 3-4 shows the existing and potential near-term e-transit applications that resulted from a scan of the past TCRP J-09 e-transit reports and the literature and activities of the transit industry and e-government in general. These applications will be used as the initial potential e-transit applications for assessment in the Phase II effort. However, since the IT is rapidly changing, additional information will also be collected from transit agencies, the literature, and other industries as one of the Phase II tasks in order to ensure that all potential applications are considered. Figure 3-4 also illustrates another important point con- cerning the channels of communication that are part of e-transit. e-Transit is not just limited to applications devel- oped for the Internet or intranets, but includes all channels of communication provided by digital technologies (e.g., com- mercial mobile services, mobile phones, personal digital assis- 17 tants (PDAs), and integrated voice response systems). This expanded view of e-transit and e-government in general is important because new technologies and ways to communi- cate continue to emerge. It is also important to note that none of a transit agency’s business functions and activities are, or are not, intrinsically e-transit. One of the fundamental characteristics of the ex- isting and emerging e-transit applications is that they have the potential to remove existing constraints on where, how, when, and by whom activities are performed. The increasing speed and channels of communications, computing power, and distributed processing capabilities allow many func- tions that must be carried out by transit agency staff on loca- tion during business hours to be outsourced to application service providers or others. These functions can be per- formed in remote locations and carried out 24 hours a day, 7 days a week. Likewise, e-transit applications increase the ability to provide up-to-date and continuous information on system and transaction status that was previously not possible. As stated in the introduction, this structural transformation, Transit Agency Transit Agency To Citizens Internal Operations To Employees To Customers • Training & Certification • Self Service HR • Time & Expense Reporting • Performance Reviews • Security/Access Control • Tele - Working • Human Resource Mgmt. • Enterprise Resource Plng. • Cust . Relationship Mgmt. • Financial Mgmt. / Payment • Knowledge Mgmt. - Data Warehousing - Data Mining/Analysis - Decision Support Systems - Digital Archiving • Inventory/Maintenance Mgmt. • e - Procurement • Enterprise GIS/Spatial Data • Service Operations & Dispatch • e - Authentication & Credentialing To Government To Business • Application Service Providers • Thin Client Computing • Requests for Proposals & Procurement • Billing and Payment • Payment Processing, Verification, Allocation • Project Management and Monitoring • Certification and Clearances • Collaboration and Conferencing • Contract Management • Data and Information Provision (GIS, demographic, network) • Advanced Communications Services • Transportation & Public Safety - Integrated Fare Systems - Integrated Information - Scheduling and Operations Coord. - System Performance & Mgmt. - Project Management - Disaster/Emergency Preparedness & Response • State and Local - Planning & Budgeting - Grants Management • Federal - Grants Management (TEAM) - Federal Reporting (NTD, Title VI, safety, security) - Federal Rules and Regulations - Research and Policy Feedback - Technical Assistance and Info. • Electronic Payment • Event Notification • Itinerary Planning • System Information (static and real time) • Automated Call Centers • Paratransit Requests and Dispatch • Ride Match Programs • Product Sales • Surveys/Data Collection • Public Meeting Broadcasts & Feedback • Plan and Project Participation • Project and System Status • Agency Information • Job Information • Surveys/Data Collection Figure 3-4. e-Transit services and applications.

process re-engineering, and provision of new opportunities, and not just technology, is the true focus of what e-transit is all about. 3.1.3 As Is “Transit Today” Scenario The As Is “Transit Today” scenario provides a basis for assessment of potential e-transit applications. From this sce- nario, the To Be “Transit of the Future” scenario will evolve. The As Is scenario should be defined so that • Typical variations in conditions, situation, and opera- tions experienced by transit agencies across the country are addressed; and • Transit agencies can evolve toward implementing inte- grated ITS, advanced information technologies, e-transit applications, and a new customer-oriented transit para- digm of mobility management.24 The scenario captures the base-case transit agency operat- ing environment, business objectives and functions, staff roles and organization, processes, and technologies. The following assumptions define the type of agency and its operating environment: • The large multijurisdictional metropolitan urban area is supported by an active metropolitan planning organiza- tion (MPO). • The large multimodal transit agency is governed by an independent transit board of directors that operates as the following separate business units: –Fixed-route bus system, –Rail system, –Paratransit system, and –Ride match program. • Other local transit agencies, county and city traffic oper- ations and centers, and commuter rail agencies are oper- ating within the transit agency’s service area. • There is daily fixed-route bus and rail transit service. • There is daily paratransit service that serves elderly pas- sengers and passengers with disabilities and requires scheduling trips 24 hours in advance. • The bus, rail, and paratransit operating departments each have separate operating policies and procedures for un- usual events that can disrupt normal operations, includ- ing inclement weather, special events, or major road or freeway closures. • While each transit agency within the region has a web- site that provides schedule information and the rail sys- tem provides an itinerary planner and has just introduced a new fare card, there are currently no shared transporta- tion information or integrated payment systems. 18 • An agencywide emergency and disaster operations and management plan is coordinated with the regional emer- gency operations and management center. This plan provides for centralized communications and operations of all the region’s transportation agencies in the event of a terrorist act, natural disaster, or other emergency. • There is heavy congestion during the weekday peaks in both the morning and afternoon. • Periodic severe inclement weather conditions of both snow and severe rain can disrupt transit operations. One of the key steps in developing any enterprise archi- tecture is the determination of the enterprise’s business objectives and functions. The As Is “Transit Today” sce- nario will presume that the regional transit agency is still operating under the “public” transit ownership and opera- tion paradigm that evolved in the 1950s and 1960s that treated transit as a public utility. Characteristics of this per- spective of transit’s purpose and business functions include the following:25 • Agency-owned and -operated transit services based upon Industrial Age values and practices, such as –Effective and efficient transit services, –Focus on a small piece of transportation services that are within mandate, –Autonomous and adversarial relationship with other modes, –Command and control of operations and services, and –Management assets (e.g., machines, buildings, and materials). • Efficient transit performance, including –Fixed-route services; –Focus on current passengers and major markets; –Subsidy-dependent public service with “locked” revenues; –Provision of physical infrastructure and services; –Control of costs and operational orientation; –Hierarchical, rigid, autonomous organization structure; and –Separation of labor and management. While it is recognized that many pioneering transit agen- cies already have shifted, or are in the process of shifting, away from this business perspective, others have not. Con- sequently, we will use it as a starting point in order to reflect the full range of points in the evolution to the To Be scenario. The functions that support the above objectives and values can be separated into “value-added” functions that contribute directly to the agency’s primary mission of providing and 24See Section 3.1.4. 25TCRP Research Results Digest 24: Creating a New Future for Public Transpor- tation: TCRP’s Strategic Road Map, Richard Daft, Robert Lingual, Glenn Perdue, April 1998.

19 operating transit services and “support” functions that pro- vide agencywide support or contribute to more than one of the value-added functions.26 The initial value-added and sup- port business functions assumed for the As Is “Transit Today” scenario are shown in Figure 3-5. The value-added chain of functions that move from potential ridership analy- sis to providing on-street transit services is shown by the block arrows in the top of the figure. These high-level func- tions will be further refined, and the sub-functions, processes, staff roles and responsibilities, and technologies to carry them out will be identified as part of the Phase II e-transit enter- prise reference architecture development. Another important set of assumptions within the As Is scenario is the level of ITS, advanced information technologies, and e-transit solu- tions included. As shown in Table 3-1, Gartner, Inc., defines four phases of e-government, and consequently e-transit, as follows: 1. Presence: agency website and basic information. 2. Interaction: e-mail, interactive information access and searching, and public feedback. 3. Transaction: self-service applications, interactive forms, verification, personal business transactions and pay- ments, privacy, and authentication. 4. Transformation: new services and ways of doing busi- ness, new applications, and potentially new enterprise- wide identity and business objectives. Transit agencies across the country are in various stages of making the transition from presence to transformation. The Bay Area Rapid Transit District is in the process of imple- menting a complete business analysis planning effort that includes a cross-cutting assessment of business functions and practices, implementation of enterprise resource planning and other advanced applications, and new ways of offering e-transit services and applications to both the public and employees (e.g., transfer of schedules and maps to PDAs). Table 3-2, derived from the FTA’s 2002 TransitWeb direc- tory of transit agency websites, indicates where the transit industry is today as a whole. Most agencies, however, can now be considered to be at the presence, or interaction, phases of e-transit implementation. Of the 477 websites from transit agencies within urban areas, all have “presence” with basic information, or they would not be in the database. Seventy- four percent provide for e-mail contact, but only 6% have trip planners (18% in the largest agencies) (i.e., interaction). The implementation of services that require transactions, or trans- formation of the business mission and functions, is only beginning to be seen (7% include online purchase of fare media, though this increases to 16% for the largest agencies; Lo ng - R an ge Fa c ili tie s an d In fra st ru c tu re Pl an n in g Fa ci lit y D es ig n & En gi ne er in g Co ns tr u c tio n O pe ra te an d M an a ge Pl an n ed Se rv ic es Sh or t-R an ge Se rv ic e P la nn in g Pr o vi de S pe ci al Se rv ic es M on ito r Pe rfo rm an ce a nd A ss et s M ai n ta in As s et s N on -V eh ic le Ve hi c le G ov e rn a n ce a n d Po lic y M ak in g Tr an s i t B oa rd S up po rt, Pe rfo rm an ce R e po rti ngO bt ai n R e v en u e R id er s hi p An a ly s is & M ar ke t R es ea rc h Sc he du lin g a n d R un cu tti ng Pr o vi de T ra v e le r In fo rm at io n M ar ke t Tr an s po rta tio n Se rv ic es Fi sc a l M an a ge m e n t Pa yr ol l, Pa ym en ts a nd Ac co un tin g, Bu dg et in g, G ra nt s M an ag em e n t Pr o vi de M a te ria ls a n d Su pp lie s Pr oc ur em en t, In ve nt or y, A ss et M an ag em en t, M at er ia l M an ag em en t (D ist rib uti on ) In fo rm at io n Te ch n o lo gy Se rv ic es G ov e rn m en t a n d Co m m u n ity Af fa irs Le gi sla tiv e R ep re se n ta tio n a n d Co m m u n ic at io n, M PO L ia iso n, In te rg ov er nm en ta l R el at io ns , P ub lic In vo lve m en t, Pu bl ic Af fa irs , C us to m er S er vic e Le ga l R isk M an ag em en t, La bo r N eg ot ia tio n s, C on tra ct s, L iti ga tio n, R eg ul a tio n Co m pl ia nc e H um a n R el a tio n s Em pl oy ee R el at io ns , B en ef its , H iri ng , T ra in in g an d Ed uc at io n Cost-Effective Efficient Transit Service Fi gu re 3 -5 . Tr an si t a ge nc y bu sin es s v al ue -a dd ed ch ai n. 26 “Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology,” Spewak, John Wiley and Sons, New York, 1992, and “Competitive Advantage: Creating and Sustaining Superior Performance,” Michael E. Porter, The Free Press, 1985.

4% provide real-time information; and 2% have e-mail alert registration). However, the transit industry is moving further into the electronic age. Transit-focused e-commerce efforts have been initiated by APTA (e.g., Transportmax) and the private sec- tor (e.g., Ibus and Irail). Significant advances in incorporating e-commerce and e-transit into the country’s transit operations have also been made, as reported by the APTA IT surveys: • Internet technologies are becoming transaction oriented (31% of agencies offer services, from online purchasing of passes for customers to online purchasing of office supplies for employees). • Emerging communications technologies are being used (54% use mobile computing such as PDAs and laptops, and 26% use teleconferencing). • Transit ITS is being adopted. (From 1999 to 2002, the following increases took place: computer-aided dis- patch, 36% to 55%; automated vehicle location, 22% to 51%; automated passenger counters, 18% to 34%; pas- senger information systems, 18% to 29%; and fare pay- ment systems, 16% to 20%). Many of these systems also can be considered e-transit. • Use of client/server and Internet applications, COTS, and ERP applications is increasing (e.g., PeopleSoft, SAP, and Oracle). 20 The As Is scenario will therefore assume the web “pres- ence” of the regional transit agency with some interactive and transaction features. However, significant e-procurement and enterprise management applications (e.g., enterprise re- source planning, human resource management, self-service intranets, and knowledge mining) will not be assumed as part of this base scenario. 3.1.4 To Be “Transit of Tomorrow” Scenario The To Be “Transit of Tomorrow” scenario represents the desired future state of the transit agency and its busi- ness objectives and functions, staff roles and responsibil- ities, processes, technologies, and applications. It will use the same overall environmental and system factor assump- tions incorporated into the As Is scenario (e.g., large multi- modal transit agency within large urban area, multiple juris- dictions and other transportation agencies, strong MPO, and congestion and inclement weather events). By defi- nition, the evolution of the To Be scenario is the result of the Phase II systems engineering and enterprise architec- ture efforts and analysis. However, basic assumptions that describe the scenario’s concept of operations—including changes in business objectives and goals, external constraints and trends, and advances in technology—can be defined and are discussed. Public transit in the United States is in the midst of re- inventing itself, as documented by the recently completed Phase Phase 1 Presence Phase 2 Interaction Phase 3 Transaction Phase 4 Transformation Strategy /Policy Public Approval Visibility Information Access and Search Public Feedback E-mail Competition Confidentiality/Privacy Fees for Transaction e-Authentication Funding Stream Allocation Agency Identity & Roles Virtual Agencies Integrated Functions & Services People Existing Content Mgmt. Increased Support Staff Governance Self-Services Skill Set Changes Portfolio Mgmt. Outsourcing Increased Business Staff Job Structures & Roles Relocation /Telecommuting Organization Performance Measures Multiple Programs/Skills Privacy Reductions Process Streamline Processes Knowledge Mgmt. E-mail Best Practices Content Mgmt. Meta Data Synch. Business Process Re-engineering Relationship Mgmt. Online Interfaces Channel Mgmt. Integrated Services Changed Value Chain New Processes/Services Changed Relationships Seamless Integration with Other Agencies Technology Website Markup Search Engine E-mail Legacy System Links Security Information Access 24/7 Infrastructure Outsourcing New Applications New Data Structures Enterprise Integrated Applications TABLE 3-1 Four phases of e-government27 27The Gartner Group, “Four Phases of e-Government Model” Research Note 21, November 2000.

TCRP J-08 New Paradigms for Public Transportation29 project. Initiated in 1998, the New Paradigms project doc- umented the factors and ongoing trends in demographics, technology, and public expectations that are creating a “crisis” in public transportation and the need for a new business paradigm. The research identified key factors from other industries and international experiences that, when combined, create a new vision for transit operations in the 21 United States. The research identified and documented tran- sit agencies around the country that are already reinvent- ing themselves. The To Be “Transit of the Future” scenario will incorporate into its assumptions and business objec- tives the results of the New Paradigms project summarized below. The new paradigm that was described in the J-08 project includes a fundamental shift in how transit agencies view their mission and the functions that they perform from that of owning and operating the transit services and facilities that they are mandated to provide and focusing on their sys- tems effectiveness and performance to that of “mobility managers” focused on meeting the customer’s door-to-door 0 140,001 250,001 600,001 1,000,001 2,500,001 140,000 250,000 600,000 1,000,000 2,500,000 Plus Number of Sites 48 63 96 50 79 141 477 Feature Description System map 40% 48% 60% 38% 58% 60% 54% shows transfer points 23% 32% 46% 28% 43% 49% 40% point and click for detail 10% 11% 23% 10% 20% 30% 20% "you are here" feature 2% 5% 2% 4% 8% 4% 4% Trip Planner 0% 0% 2% 0% 4% 18% 6% Route maps 31% 57% 70% 54% 70% 57% 59% Schedules 81% 86% 93% 76% 86% 87% 86% Download to PDA 0% 0% 2% 0% 3% 2% 1% General fare information 88% 90% 94% 88% 90% 93% 91% Online purchase of fare media 0% 2% 4% 0% 8% 16% 7% Information on where to purchase fare media 38% 40% 50% 52% 56% 60% 52% Traffic (multimodal) info. 0% 0% 0% 2% 0% 1% 0% Park and ride lot info. 8% 10% 14% 24% 32% 25% 20% Bicycles on/with transit info. 20% 26% 27% 20% 32% 38% 30% Link to a car sharing site 0% 0% 0% 0% 1% 1% 0% Rules and tips for using the system 48% 35% 53% 38% 41% 40% 43% Includes information useful to lead tourists 8% 10% 16% 4% 13% 23% 14% Language choice 0% 2% 6% 4% 5% 6% 4% To other transit sites in region 32% 41% 26% 34% 41% 69% 44% To traffic information sites in region 4% 6% 5% 6% 9% 19% 10% To intercity transportation sites 9% 24% 15% 24% 23% 29% 22% To transit-related goverment sites 34% 22% 20% 12% 34% 47% 31% Current info. (reroutings, etc.) 4% 6% 13% 16% 22% 24% 16% Real-time info. (NextBus, etc.) 0% 2% 3% 0% 3% 9% 4% E-mail alerts sign-up 0% 0% 0% 0% 3% 6% 2% E-mail contact 69% 63% 77% 64% 87% 76% 74% Phone contact 90% 94% 90% 94% 95% 92% 92% Outreach to Potential Users Links to Other Traveler Information Sites Current or Real-Time Information Contact Information Route-Choosing Content Route-Specific Detail Fares Multimodal Information Available on Site Population Total % of Sites with This Feature TABLE 3-2 ITS transit website characteristics by size of urban area28 28From the TransitWeb 2002 FTA Transit Agency Website Directory maintained by the Volpe Transportation Systems Center (http://transitweb.volpe.dot.gov). 29TCRP Report 97: Emerging New Paradigms—A Guide to Fundamental Change in Local Public Transportation Organizations, Robert G. Stanley et al., Transportation Research Board, Washington D.C. 2003.

needs for travel. The shift in perspective can be summa- rized as follows: The strategic interest lies in creating an organization whose principal responsibility is to provide the customer with knowl- edge of, and ease of access to, a range of services that can serve individual traveler needs and that has the capacity to continu- ously monitor, evaluate, and ensure the quality of the travel experience.31 A three-tiered organizational model is presented that is made up of a top strategic tier, a middle tactical tier, and a bottom operational tier. Table 3-3 summarizes concepts behind this new organizational approach. The middle tier is built around the use of integrated information technologies and communications, or e-transit. It incorporates many of the fundamental ideas and principles of e-transit and e-business in general, including 22 • Customer orientation, • Separation of ownership and delivery of functions, and • A flexible and responsive process to meet customers’ shifting requirements. The dimensions of fundamental change necessary for tran- sit agencies to evolve toward the new paradigm are also described. These are summarized in Table 3-4. Consequently, the To Be scenario will explore the shift from autonomous operation of the transit agency’s fixed- route, paratransit, and rail systems to integrated management and operation of overall transit service across the region. This shift may require new e-transit connections and appli- cations both within the agency and between agencies. Like- wise, shifts to integrated passenger information, fare sys- tems, transfers, and other services will all be investigated. In addition, the To Be scenario will assume that current trends in technology development and applications continue Tier Key Attributes Key Actions Strategic Interfaces with customers and understands their “full trip” needs and requirements. Monitors performance. Brokers end-to-end trip from operators and service providers. Tactical Integrated systems of routing, dispatching, and tracking. Applies Information Technology. Operational Niche markets and modal services by those that do them best. Involves many suppliers in providing modal capacity and support services and responding flexibly and rapidly to service requests. TABLE 3-3 Three-tiered organizational model for the new transit paradigm TABLE 3-4 Six dimensions of fundamental change leading to a new paradigm30 30Ibid. 31Ibid.

and promising e-transit options become a reality. Some of these trends and options include • Continued implementation of existing e-transit applica- tions and enterprisewide systems for enterprise resource planning, knowledge management, decision support, and other applications; • Further investigation of the virtual transit enterprise being tested in South Carolina; • Use of virtual private networks and the “Internet cloud” to increase opportunities for outsourcing and pooled applications among transit providers; and • Continued evolution of “smart enterprise suites,” web services, and e-authentication and security to enable new applications. Each of these developments will be monitored and con- sidered in the assessment of the final To Be scenario. 3.1.5 Coordination with the National ITS Architecture, Security, and Other Related Efforts One potential concern that has been raised is the coordi- nation of the development of the e-transit reference enter- prise architecture with the National ITS Architecture and applicable standards, the U.S. DOT enterprise architecture, the Transportation Security Administration Transportation Worker ID Card and Card System Architecture, and federal e-government and architecture activities. A basic principle of the Phase II effort will be to coordinate and interface with these other efforts. Special care will be taken to use naming conventions, functional requirements, information flows, and so forth that have already been created by these overlapping efforts. Because of the significant overlap between e-transit and ITS, the coordination with the National ITS Architecture is explored more fully below. The U.S. DOT initiated the creation of the National ITS Architecture to reduce the burden and assist in managing the development and implementation of ITS across the United States. The National ITS Architecture provides the logical and physical architectures for the development of the ITS user services, which capture from a user’s perspective what we would like the ITS in the United States to do. The Na- tional ITS Program Plan first established 29 ITS user services in 1995. New user services have been added since then to address changing needs, increasing the total to 33 (as of July 2004). The Version 5.0 update incorporating security con- cerns arising from September 11, 2001, was released on a CD-ROM in November of 2003. It is also accessible via the Internet at http://www.its.dot.gov/arch/arch.htm. The building blocks that the National ITS Architecture uses to provide assistance in implementing the user services at different levels and configurations are the National ITS 23 Architecture market packages. Each of the market packages describes the subsystems, interfaces, and conceptual equip- ment packages needed to implement a key function used by the user services. A transit agency may be responsible for applications that implement any number of the ITS user ser- vices, from electronic fare collection, to passenger informa- tion, to archived ITS data. The market packages and appli- cations that implement these user services are also often potential e-transit opportunities. Table 3-5 lists the user ser- vices and market packages from Version 5.0 of the National ITS Architecture that may be e-transit and implemented by a transit agency. The National ITS Architecture also provides a general framework for implementing the user services and integrating ITS strategies within and across agencies, modes, and juris- dictional boundaries. Figure 3-6 represents the physical archi- tecture subsystems and the communications between them. In developing and implementing their ITS transit sys- tems, transit agencies may be responsible for the following sub-systems: • Centers –Transit Management –Information Service Provider –Emergency Management –Maintenance and Construction Management –Archived Data Management • Travelers –Remote Traveler Support –Personal Information Access • Vehicles –Transit Vehicle –Maintenance and Construction Vehicle • Field –Roadway –Security Monitoring –Parking Management When applications impacting the above sub-systems or the potential user services and market packages from Table 3-5 are considered in the e-transit reference enterprise architec- ture, the information available from the National ITS Archi- tecture will be used. Again, the National ITS Architecture provides the market packages, functional requirements, and information flows between sub-systems and terminators required to implement the ITS user services. The National ITS Architecture does not address where, how, or by whom each function is performed within the transit agency or the additional functions, information flows, and activities that must be carried out to support the ITS user services that do not directly relate to its provision. Nor does the National ITS Architecture address how each ITS component relates to the overall business objectives and value-added chains of func- tions of the transit agency. This information will be devel- oped and added as part of the Phase II effort.

As an example, Figure 3-7 provides the information flows to and from the transit management and information service provider centers from Version 5.0 of the National ITS Archi- tecture. The figure shows information flows for route, sched- ule, and fare information to and from the transit management center and the information service provider center. The de- 24 tailed performance specifications also provided by the Na- tional ITS Architecture for the pre-trip traveler information user service and transit traveler information market package describe what needs to be transmitted between the two cen- ters. However, the specifications do not address who is re- sponsible for developing and maintaining the information for User Service User Service Name Market Package Traveler Information 1.1 Pre-Trip Travel Information ATIS7 Yellow Pages and Reservation 1.4 Ride Matching and Reservation ATIS8 Dynamic Ridesharing 1.5 Traveler Services Information Traffic Management 1.7 Incident Management ATMS01 Network Surveillance 1.8 Travel Demand Management ATMS02 Probe Surveillance 1.10 Highway Rail Intersection ATMS05 HOV Lane Management 1.10 Highway Rail Intersection ATMS09 Traffic Forecast and Demand Management ATMS13 Standard Railroad Grade Crossing ATMS14 Advanced Railroad Grade Crossing ATMS15 Railroad Operations Coordination ATMS16 Parking Facility Management ATMS17 Regional Parking Management ATMS18 Reversible Lane Management ATMS19 Speed Monitoring Public Transportation 2.1 Public Transportation Management APTS1 Transit Vehicle Tracking 2.2 En-Route Transit Information APTS2 Transit Fixed-Route Operations 2.3 Personalized Public Transit APTS3 Demand Response Transit Operations 2.4 Public Travel Security APTS4 Transit Passenger and Fare Management APTS5 Transit Security APTS6 Transit Maintenance APTS7 Multimodal Coordination APTS8 Transit Traveler Information 3.1 Electronic Payment Services APTS4 Transit Passenger and Fare Management Commercial Vehicle Operations Emergency Management 5.1 Emergency Notification and Personal Security EM01 Emergency Call-Taking and Dispatch 5.2 Emergency Vehicle Management EM02 Emergency Routing 5.3 Disaster Response and Evacuation EM03 Mayday Support EM04 Roadway Service Patrols EM05 Transportation Infrastructure Protection EM08 Disaster Response and Recovery EM09 Evacuation and Reentry Management EM10 Disaster Traveler Information Vehicle Safety Archived Data Management 7.1 Archived Data Function AD1 ITS Data Mart AD2 ITS Data Warehouse AD3 ITS Virtual Data Warehouse Maintenance & Construction 8.1 Maintenance and Construction Operations MC01 Maintenance and Construction Vehicle & Equip. Tracking MC02 Maintenance and Construction Vehicle Maintenance MC03 Road Weather Data Collection MC04 Weather Information Processing and Distribution MC05 Roadway Automated Treatment MC06 Winter Maintenance MC07 Roadway Maintenance and Construction MC08 Work Zone Management MC09 Work Zone Safety Monitoring MC10 Maintenance and Construction Activity Coordination 8 Maintenance and Construction Management 5 Emergency Management 1 Travel and Traffic Management 2 Public Transportation Management 6 Advanced Vehicle Safety Systems 7 Information Management 3 Electronic Payment 4 Commercial Vehicle Operations Market Package Name TABLE 3-5 ITS user services and market packages with potential e-transit intersections

each center, how the information is developed, how and where it is stored, how often it is updated, how it is validated and checked, what channels of communication are used, or how the information is displayed. This additional informa- tion would have to be developed and incorporated into the e-transit reference architecture as part of assessing potential e-transit applications for data integration, website interaction and interfaces, or mobile services. 3.2 POTENTIAL INPUTS AND RESOURCES FOR DEVELOPING THE REFERENCE ENTERPRISE ARCHITECTURE Critical to both successfully applying the systems engi- neering process and building the reference enterprise archi- tecture is the identification and involvement of key stake- holders and system users who are being examined. It will also be important in Phase II to capture the advances made by pioneers in IT practices and e-commerce/e-government in transit- and transportation-related and other industries. This step will be accomplished by doing the following: 1. Carry out a review and assessment of existing literature and ongoing efforts. 25 2. Collect information from transit agencies on current and planned business goals and needs, organization, pro- cesses, technologies, and e-transit applications through email queries and online surveys, telephone interviews, and/or site visits. 3. Establish an advisory group of members both within and outside of the transit community to provide infor- mation and feedback throughout the life of the project. An online forum will be used to share information and facilitate discussion with this group. In addition, work- ing group and/or focus group meetings and conference calls may be held on specific topics. A number of related efforts by professional organizations and the federal government have already been identified. Consequently, during the project special attention will be given to initiating and maintaining the coordination and par- ticipation of these groups, including the following: • The Transportation Research Board (TRB) committees and ongoing research from the Transit Cooperative Research Program (TCRP) and the National Coopera- tive Highway Research Program (NCHRP); • The American Public Transportation Association (APTA; through its IT committee and e-visioning task force, APTA maintains an e-commerce initiative and portal: TransportMax); Figure 3-6. National ITS Architecture 5.0 sub-systems and connections.32 32The National ITS Architecture Version 5.0, U.S. DOT, November 2003.

• ITS America forums (e.g., on public transportation, transportation operations, and planning); • The National ITS Program efforts and products, includ- ing the ITS Transit Program (e.g., electronic payment, passenger information, transit signal priority, transit operations decision support, advanced communications, and intelligent vehicle initiative) and the National ITS Architecture and standards development efforts; • The U.S. DOT e-government enterprise architecture managed by the DOT’s chief information officer (http:// cio.ost.dot.gov/index.html); and • Homeland security activities now part of the Transporta- tion Security Administration. A number of transportation research results reports and sources of information directly related to the Phase II efforts have already been identified. Additional scans and literature reviews will take place early in the Phase II effort. Signifi- cant sources of information and past works that will be incor- porated into the review are shown below: • TCRP Report 84: e-Transit: Electronic Business Strate- gies for Public Transportation (Project J-09 report) 26 –Volume 1, Supply Chain: Parts and Inventory Man- agement (Mitretek Systems and TransTech Manage- ment, Inc., 2002) –Volume 2, Application Service Provider Implementa- tion Guidelines (Mitretek Systems, 2002) –Volume 3, Using the Internet for Transit Training and Certification (Multisystems, Inc., with Brattle Systems, Inc., 2003) –Volume 4, Advanced Features of Transit Websites (Multisystems, Inc., and Matthew Coogan, 2003) • TCRP J-08: New Paradigms for Public Transit Results –TCRP Report 97: Emerging New Paradigms, A Guide to Fundamental Change in Local Public Transporta- tion Organizations (Robert Stanley et al., 2003) –TCRP Research Results Digest 55: Support for Funda- mental Change in Public Transportation (Robert Stan- ley, 2002) –TCRP Report 58: New Paradigms for Local Public Transportation Organizations Task 5 Report: Opening the Door to Fundamental Change (Cambridge Sys- tematics, Inc., et al., 2000) –TCRP Report 53: New Paradigms for Local Public Transportation Organizations Task 1 Report: Forces TRMS Transit Management ISP Information Service Provider threat information transportation system status emergency plan coordination emergency transit schedule information road network probe information traffic control priority request transit demand management response transit system data request transit information road network conditions traffic control priority status transit demand management request demand responsive transit plan transit and fare schedules transit incident information transit request confirmation demand responsive transit request selected routes transit information request transit fare information transit traveler information transit fare and passenger status transit information user request Figure 3-7. National ITS Architecture 5.0 transit management to information service provider information flows.

and Factors That Require Consideration of New Para- digms (Cambridge Systematics, Inc., 1999) –TCRP Research Results Digest 24: Creating a New Future for Public Transportation: TCRP’s Strategic Road Map (Richard Daft et al., 1998) • TCRP and NCHRP IT syntheses –TCRP Synthesis 35: Information Technology Update for Transit (Roger Boldt, 2000) –TCRP Synthesis 5: Management Information Systems (Roger Boldt, 1994) –NCHRP Syntheses 296: Impact of New Information and Communication Technologies on Transportation Agencies (Carol A. Zimmerman et al., 2001) • APTA products –IT surveys for 1999, 2002, and 2004 (pending) –TransportMax transit industry procurement portal (http://www.transportmax.com) –Annual TransITech Conference presentations and papers (2001–2004) • Other transit industry e-business portals –IRail eProcurement Market Place (http://www.irail. com/pre/default.asp) –IBusXChange eProcurement Market Place (http:// www.ibusxchange.com/pre/default.asp) • ITS-related resources and literature –U.S. DOT ITS Joint Program Office Electronic Docu- ment Library for ITS-related reports and documents (http://www.its.dot.gov/itsweb/welcome.htm) –The National ITS Architecture Version 5.0 –U.S. DOT ITS standards development activities for Transit Communications Interface Protocols (TCIP), and National Transportation Communications for ITS Protocol (NTCIP) for center-to-center and center-to- field ITS standards (http://www.standards.its.dot.gov/ standards.htm) • European Commission’s Voyager Project. Its mission is to create a vision and make recommendations for the implementation of attractive, clean, safe, accessible, effective, efficient, and affordable European local and regional public transport systems for the year 2020 (http://www.voyager-network.org). It will also be important to identify, collect information from, and garner participation of public agencies with re- cent or pioneering experience in e-transit, organizational transformation and process re-engineering, enterprise IT plans, or enterprise architectures. The APTA IT and ITS Joint Program Office annual deployment surveys will be used as sources to agencies for surveys and interviews. In addition, a preliminary list of potential candidates that have already been identified with either noteworthy e-transit ap- plications or recent comprehensive re-engineering, IT stra- tegic planning, or enterprise architecture efforts is as follows: 27 • Ann Arbor Transportation Authority (AATA; Ann Arbor, Michigan) • Bay Area Rapid Transit District (BART; San Fran- cisco, California) • Central Ohio Transit Authority (Columbus, Ohio) • Dallas Area Rapid Transit (Dallas, Texas) • Go Transit (Toronto, Ontario) • Hampton Roads Transit (Norfolk, Virginia) • King County Transportation and Pierce Transit of the Puget Sound Region (Seattle, Washington) • Los Angeles County Metropolitan Transit Authority (Los Angeles, California) • Metropolitan Transit Authority of Harris County (Houston, Texas) • New York City Metropolitan Transit Authority (New York City, New York) • Portland Tri-Met (Portland, Oregon) • Road Island Public Transportation Authority (RIPTA) • Utah Transit Authority (Salt Lake City, Utah) • San Diego Metropolitan Transit Development Board and the North County Transit District (San Diego, California) • South Carolina Department of Transportation (South Carolina) • Washington Area Metropolitan Transit Authority (WMATA; Washington, D.C.) All have recently undergone strategic business planning and assessments or have implemented pioneering e-transit applications. For example, BART completed the first-phase tactical planning of its Business Advancement Plan (BAP) in 2002 and has requested proposals for the BAP implementa- tion (deadline 4 January 2004). The BAP was a comprehen- sive assessment of transforming BART’s mission, business objectives, structure, and processes to meet the demands of this century. BART has also implemented many e-transit applications for customer service, maintenance, and procure- ment. WMATA is also currently engaged in a comprehen- sive IT strategic planning initiative that is reshaping the agency’s organization and functions. WMATA is also a pio- neer in implementing electronic payment systems (currently moving to a multi-agency, multi-application system) and passenger information over the Internet. Also, WMATA’s rail passenger e-mail major delay notification system sends out e-mail notices to subscribers based upon their origin and destination when significant delays are expected. AATA was one of the first transit authorities in the country to implement an integrated set of ITS transit services and change the way it does business to account for the new capabilities that these services enable. New e-transit concepts are also being developed. For ex- ample, The South Carolina Department of Transportation, with the support of the Federal Transit Authority, is in the process of developing and testing a “virtual transit enterprise”

that pools the use of many applications that support the busi- ness functions of transit across traditional agency boundaries and organizations. Last, experiences and expertise from other industries will be identified and analyzed in order to explore new opportu- nities for transit. Potential candidates and resources are the following: • e-government resources –The e-Government Act of 2002 (www.whitehouse. gov/omb/egov/index2.html) –Implementation guidance for the e-Government Act of 2002 (http://www.whitehouse.gov/omb/memoranda/ m03-18.pdf) –e-Government Journal (http://www.egovjournal.com) –National Science Foundation Digital Government Re- search Program (http://www.digitalgovernment.org/) –The Gartner Group e-government tracking and reports (by subscription only) • Enterprise architecture resources –The Federal Enterprise Architecture Program Man- agement Office (http://feapmo.gov/) –The U.S. DOT enterprise architecture development and products (http://cio.ost.dot.gov/architecture/index.html) –The Zachman Institute for Framework Advancement (http://www.zifa.com/) –The Enterprise Architecture Community (http://www. eacommunity.com/) 3.3 PROPOSED PHASE II PRODUCTS The three major proposed Phase II products were briefly mentioned in the Chapter 1 introduction: 1. An e-transit reference enterprise architecture and model documentation; 2. Guidance on use of the reference enterprise architec- ture, including examples of typical applications; and 3. An online forum and e-mail exchange for identifying and discussing emerging e-transit opportunities. Technical memorandum and summary reports will also be created to capture specific tasks and milestones as these prod- ucts are created. A more detailed explanation of all of the pro- posed products and how they might be used is provided below. 3.3.1 e-Transit Reference Enterprise Architecture The e-transit reference enterprise architecture will provide the context to evaluate how potential e-transit applications may affect transit’s overall business and operations. The en- terprise architecture provides a repository for information and relationships for business requirements, people, processes, 28 and technologies within the organization and includes the following: • Business Model (Row 1, “Planner, Conceptual,” per- spective of the Zachman Framework). • Information Architecture (Column 1, “What, Data,” Rows 1 and 2, of the Zachman Framework). • Applications Architecture (Column 2, “How, Func- tions,” Row 2, “Owner, Conceptual,” of the Zachman Framework). • Technology Architecture (Column 3, “Where, Net- work,” Row 2, “Owner, Conceptual,” of the Zachman Framework). The enterprise architecture will include • The As Is “Transit Today” base case business require- ments and operations of a typical large transit agency serving a major metropolitan area, • The To Be “Transit of the Future” vision based upon the TCRP J-08 new paradigms project results and the im- plementation of integrated e-transit applications, and • A typical sequence of actions and their impacts for mak- ing the transition from the today to the future vision. Because the enterprise architecture captures all of the information and relationships required to meet the business needs and objectives of a typical transit agency (versus fo- cusing on one functional area or department such as IT, oper- ations, service planning, or maintenance), it can be used to trace the cascading impacts of a new e-transit application throughout the organization and also to unveil new ways enabled by the application of meeting the business objectives and needs of the organization. For example, past system de- ployments have not properly accounted for the cost and effort associated with maintaining accurate schedule and route in- formation (including detours and other modifications) and reliable customer access for Internet-based passenger infor- mation systems. The functions required to provide these services (i.e., the online information maintenance) were pre- viously not continuous and therefore were overlooked or simply did not exist. An online passenger information system may also drastically alter the information requests, functions, daily activities, and processes of a transit agency’s customer service department and call center. The To Be “Transit of The Future” scenario will focus on the identification and incorporation of potential e-transit ap- plications to meet the existing and proposed business objec- tives and requirements described in the concept of operations (e.g., recommendations of the TCRP J-08 new transit para- digms project). Evolution requirements and evaluation crite- ria will be developed based upon inputs from transit agen- cies, domain experts, and the new paradigms project. These requirements and criteria will then be used to analyze alter- native e-transit applications for the To Be scenario, ways in

which they should be integrated with each other and the ex- isting systems and processes, and ways in which they should be implemented. Again, implementation will include organi- zation and process changes, as well as simply the new tech- nologies and applications. The e-transit reference enterprise architecture should be captured and provided using an automated tool. Figure 3-8 shows an example screen shot. The relationships between the business functions, people, processes, and technologies within the As Is and the To Be scenarios and the transition are very complex and very difficult to present in a manner that is understandable and traceable in a paper or static format. Soft- ware tools provide the ability to easily drill down to different layers of the architecture, trace relationships and their evolu- tion between scenarios, and display the information from dif- ferent perspectives. Technical memoranda and summary reports will also be provided documenting task milestones during the develop- 29 ment of the e-transit reference enterprise architecture. These include descriptions of e-transit state of the practices and emerging opportunities, the As Is and To Be scenarios and their concepts of operations, and an overview of the refer- ence architecture itself. 3.3.2 e-Transit Reference Enterprise Architecture User’s Guide The e-transit reference enterprise architecture is a tem- plate-like tool that is meant to be used to identify topics in need of additional research, assess e-transit applications, plan their transition to the future, and develop their situation- specific enterprise architectures. Consequently, a user’s guide that includes directions and examples for typical applications of the reference enterprise architecture is an additional major Phase II product. The user’s guide will include an introduction to enterprise architecture concepts; an overview of what is considered e-transit and how it relates to ITS, security, IT, advanced Figure 3-8. User interface and navigation bars of a commercial enterprise architecture tool.33 33Metis by Computas.

communications, and other specialty areas; and the concepts of operation for the As Is and To Be scenarios. The guide will also provide a general process and criteria for evaluating e-transit options and their impacts using the e-transit refer- ence enterprise architecture, describe how the architecture can be used to assess whether emerging e-concepts and applications are worth pursuing by transit as a whole, and identify topics for additional research. It is likely that independent transit agencies will simulta- neously embark upon capturing their current enterprise archi- tecture. Guidance toward coordinated, compatible e-transit architectures will promote synergy by facilitating sharing of the best e-transit practices and reuse of e-transit applications. Figure 3-9 shows this guided evolution of a transit system’s enterprise architecture. Therefore, another key product of this effort will be guid- ance on how the e-transit reference enterprise architecture can be referenced or used as a starting point by a typical transit agency. The guidance will encompass both the assessment of current conditions and architecture and the development of a target enterprise architecture. The guidance will describe how to use the e-transit evaluation criteria and systems engineer- ing processes to develop the target architecture. The target architecture will facilitate achieving the vision (and business requirements) of a transit agency through the elimination of duplication while increasing interoperability, communica- tion, coordination, and synergy and improving value to cus- tomers. Implementing the target e-transit enterprise architec- ture will support integration of cost-effective technology to provide timely, high-quality transit information and services to customers, suppliers, and stakeholders. We expect to de- velop, in collaboration with domain experts, guidance for each step toward implementation of a transit agency’s target, e-transit enterprise architecture. Representing the transition between the two and sequence of changes in bridging ele- ments for the near term can be the core of the typical transi- tion plan that will be provided as part of the guidance. 30 Supporting technical memoranda will also be provided for review and feedback by the TCRP J-09 Project Panel during the development of the user’s guide. These memo- randa will include draft guidance on using the e-transit ref- erence enterprise architecture to identify national research needs and emerging e-transit opportunities and to apply the architecture to develop an agency-specific enterprise archi- tecture for e-transit planning and assessment. 3.3.3 Online Forum and E-Mail Exchange Because it is anticipated that e-transit opportunities, com- munications and information technologies, and other changes will continue to occur at a rapid rate during the life of this project, a third product will be the creation of an online forum and e-mail exchange. This product will be used to identify emerging issues and to make recommendations to the e-transit panel for additional investigation under the J-09 e-Transit Program. It will also be used to provide collabora- tion between the project team and the members of advisory panels from the transit and other industries participating in the project. Figure 3-10 provides an example of an online forum that was successfully used for the Federal Transit Administration and ITS Joint Program Office project on developing core functional requirements for Transit Opera- tions Decision Support Systems (TODSS) that had very sim- ilar ongoing collaboration and feedback needs (http://www. mitretek.org/ITSTransitForums). The forum will have the ability to control access to discus- sions and documents and actions (e.g., view, download, post new topics, provide feedback, and upload) based upon a user’s membership and access rights. Options for hosting the online board include TRB’s WebBoard (which already has an access-controlled e-transit forum), APTA’s transit forums, Yahoo groups, or a contractor-provided application. Enterprise Architecture eTransit System, “To Be” Repository for information and relationships: - Business Requirements - People - Processes - Technology Enterprise Architecture Transit System, “As Is” Repository for information and relationships: - People - Processes - Technology - Business Requirements Systems Engineering Practices EA Guidance Reference Enterprise Architecture Emerging Technology Business Requirements Figure 3-9. Reference enterprise architecture will guide evolution to e-transit.

31 Figure 3-10. Transportation operations decision support systems online forum.