National Academies Press: OpenBook

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

Chapter: Chapter 1 - Introduction

« Previous: Front Matter
Page 1
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2004. Concept for an e-Transit Reference Enterprise Architecture. Washington, DC: The National Academies Press. doi: 10.17226/23351.
×
Page 1
Page 2
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2004. Concept for an e-Transit Reference Enterprise Architecture. Washington, DC: The National Academies Press. doi: 10.17226/23351.
×
Page 2
Page 3
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2004. Concept for an e-Transit Reference Enterprise Architecture. Washington, DC: The National Academies Press. doi: 10.17226/23351.
×
Page 3
Page 4
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2004. Concept for an e-Transit Reference Enterprise Architecture. Washington, DC: The National Academies Press. doi: 10.17226/23351.
×
Page 4

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.

1CHAPTER 1 INTRODUCTION The declining costs of information processing, data stor- age, communications, and data retrieval, combined with the Internet and other new communications technologies, are re- volutionizing the way services are delivered and organiza- tions are structured throughout U.S. society. They also can enhance the services that transit agencies deliver, the ways in which these services are delivered, and the expectations and perceptions of transit patrons and business partners. Ready or not, transit agencies must address the forces that are pushing them into the age of e-commerce and e-government. These changes in technologies, potential services, and customer expectations present significant challenges to transit agency managers who must make decisions regarding investments in technologies, processes, and people to reduce costs and in- crease productivity while weighing the costs, benefits, and risks of changing the way services are delivered.1 Recognizing the rapidly changing technological environ- ment within which transit agencies must operate and the chal- lenges it presents, TCRP initiated the e-transit research in 2001 to identify, develop, and promote research to maximize the benefits of e-commerce and other new technology appli- cations for public transportation and mobility management, with the objective to provide flexible, ongoing, quick-response research designed to bring electronic business strategies to public transportation and mobility management.2 Since the start of the e-transit effort, the application of new transit technologies and services has continued to advance at a rapid rate, while significant changes in the overall fields of information technologies (IT), communications, and electro- nic business have also occurred. Some business models have not worked out. Many companies have gone out of business, merged, or drastically changed their services in order to sur- vive. Peregrine Systems, Inc., a company offering enterprise- wide asset management solutions to transportation firms, expe- rienced accounting irregularities. The company’s subsequent bankruptcy may be the most highly visible transit-related default that took place in 2002. Smart Traveler, an independent service provider (ISP) of multimodal traveler information, also closed the doors of its Washington, D.C., operations in 2003, and the business model behind using ISPs for provision of trav- eler information has been widely questioned. Likewise, many of the en vogue approaches of the past, including the use of application service providers (ASPs), are no longer viable options for most applications. Along with ongoing realign- ment, new technologies and services also continue to emerge. New telecom services and devices appear every day to process and display information. For example, it is expected that the new next-generation (2.5G and 3G) services may provide up to a tenfold increase in the data that can be exchanged with transit vehicles and mobile individuals. These new capabilities offer new opportunities for e-transit that are only beginning to be explored. Because of the increase in data that can be ex- changed, concepts and potential options for e-transit that were considered promising as little as 2 years ago are loosing via- bility, and concepts and options that were not even conceived of at the start of the effort are now becoming a reality. Conse- quently, while the e-transit project has produced excellent products,3 the issues that these products address and the infor- mation included within them is often dated by the time that they have been officially reviewed and published. Simply monitoring the IT, transit, and e-commerce/ e-government trends and developments and initiating new J-09 e-transit investigations can only result in continuing to pro- viding today’s answers to yesterday’s questions. Conse- quently, there is a need to provide an overall context and a reference framework that can be used to quickly assess the impacts and potential opportunities of changes and new developments in order to do the following: • Examine e-transit opportunities and impacts for further investigation in the J-09 e-Transit Program with respect to –Their impact on the services provided, –The business processes and functions that are carried out within transit agencies, –The organizational structure of the agency and employee responsibilities within it, –Relationships to the customer and other organiza- tions, and –Other issues (e.g., sustainability, liability, life cycle, and potential obsolescence). • Monitor current and future developments in the IT and other industries for potential transfer to transit applications. • Assist transit operators in assessing the potential appli- cation of e-transit options to meet the particular needs and situation of the operators. 1Transit Cooperative Research Program, “Research Project Statement Project J-09, FY 2000—e-Transit: Electronic Business Strategies for Public Transportation,” page 1 (Transportation Research Board, Washington D.C., January 2001). 2 Ibid. 3TCRP Report 84: e-Transit: Electronic Business Strategies for Public Transportation: Volume 1, “Supply Chain: Parts and Inventory Management”; Volume 2, “Application Service Provider Implementation Guidelines”; Volume 3, “Using the Internet for Tran- sit Training and Certification”; and Volume 4, “Advanced Features of Transit Websites.”

An e-transit reference enterprise architecture developed at a level of detail that both captures the business objectives, functions, and processes and yet can still be easily explored and updated to assess potential e-transit applications meets this need. This concept paper is the result of Phase I of the develop- ment of a transit business model and e-transit reference enter- prise architecture for assessing e-transit options. This Phase I work was proposed in Mitretek’s 2003 “Proposal for Task 8: A Systems Engineering Approach to e-Transit: A Concept Paper.” This paper includes a discussion of what e-transit is and how it fits into the overall operation and business of tran- sit agencies. An overview of the basic concepts behind sys- tems engineering and enterprise architecture and their use in the development of an e-transit reference enterprise architecture is also provided. Finally, this paper describes the tasks, approach, and products of Phase II in which an e-transit reference enterprise architecture will be developed. 1.1 DEFINING e-TRANSIT To develop and apply a framework for assessing emerging e-transit technologies and services, we must come to a general agreement on what e-transit is. e-Transit is more than just simply the implementation of e-commerce and e-purchasing within transit agencies. The initial TCRP e-transit statement of work included the following subject areas within e-transit: • Supply Chain: Parts Management/ Inventory Management, • Regulatory Issues of e-Business within Transit, • Application Service Providers, • Customer Information, • Electronic Payment and Receipts, • Training and Certification, and • Outreach (e-Zine). As seen from the above, e-transit is much more than the e-commerce business-to-business (B2B) and business-to- customer (B2C) functions of transactional processing and relationships (e.g., purchasing, contracting, and information provision). It also extends into the e-government functions of government-to-citizen (G2C), government-to-employee (G2E), and government-to-government (G2G). The public nature of transit service also changes the focus and measures of suc- cess for e-transit. Public Technology, Inc., lists the goals of e-government as promote democracy, encourage economic activity, and enhance service delivery to citizens.4 The focus of e-transit shifts to one of service to customers, collaboration, and efficient service delivery, not competitive advantage and market share. G2E services are becoming increasingly impor- tant as transit agencies compete for employees with needed technical skills and work to train existing employees in a 2 rapidly changing environment. The importance of providing an information portal and forum for citizen input also be- comes a critical e-transit function, especially when major in- vestment or New Start projects are underway. Applying the broad roles of e-government and e-business to transit, e-transit should therefore be considered “The use of digital technolo- gies to transform government operations in order to improve effectiveness, efficiency, and service delivery.”5 In the book e-Business: Roadmap for Success, Ravi Kalakota and Marcia Robinson equate e-business with “struc- tural transformation.”6 The same principle applies to e-tran- sit. e-Transit is not a simple set of functions and services that can be readily implemented and transferred from one agency to another. The Gartner Group cautions that moving to an e-world is as much about process re-engineering and devel- oping new ways of doing things as it is about technology. Simply moving old processes to the Internet is bound to fail. Gartner defines four phases of e-government that also apply to e-transit: 1. Presence, 2. Interaction, 3. Transaction, and 4. Transformation. Evolving through these phases requires a strategy for change (though a single agency may be at different phases for dif- ferent functions and may skip phases in its deployment). The need to assess the overall impacts on the transit agency’s organization and business functions and provide paths of development is one of the central principles behind the pro- posed use of systems engineering and enterprise architecture to develop the e-transit reference framework. 1.2 SYSTEMS ENGINEERING AND ENTERPRISE ARCHITECTURE Systems engineering and enterprise architecture concepts are at the core of the proposed approach to develop a transit busi- ness model and reference framework for assessing e-transit. Systems engineering provides the principles and process for defining the fully integrated e-transit agency of the future. However, systems engineering for the most part focuses on the systems and functions required to meet a particular sys- tem’s goals and objectives. Enterprise architectures provide the means to capture and document the overall impacts of a new technology or service on the transit agency as a whole, including its people, processes, technologies, and business requirements. Using a reference architecture to capture tran- sit agencies of today and the envisioned transit agencies of the future creates a foundation for assessing all the impacts of e-transit (on people, on processes, on technologies, and on systems) and how they might be transformed. 5Mark Forman, OMB Associate Director for IT and eGovernment, September 2001. 6Ravi Kalakota and Marcia Robinson, e-Business: Roadmap for Success, Addison- Wesley, Reading, MA, 1999.4Public Technology, Inc., website 6 January 2003, http:/pti.nw.dc.us.

Systems engineering as a discipline and process evolved dur- ing the 1960s and 1970s to assist the developers of the defense program and other complex high-technology systems in iden- tifying and tracing requirements, examining tradeoffs, and evaluating risks to ensure that once the systems were imple- mented they worked as planned. Systems engineering provides a disciplined environment to design quality into complex sys- tems from the very beginning. Key to the success of systems engineering is the involvement of all the stakeholders and users of the system throughout the process to correctly identify what the system is supposed to do. This collective involvement pro- vides a mechanism to view the provision of transit services as a business practice, focusing on needs and goals, addressing operational requirements and ways to accomplish them, exam- ining alternatives, and tracing impacts through the system to see the results. Systems engineering becomes increasingly impor- tant as provision of transit service shifts from independent oper- ation within a single transit agency to dependence on coordi- nated operation of complex systems (e.g., automatic vehicle location/computer-aided dispatch, communications, automatic passenger counters, and signal priority) across numerous pro- viders and modes (e.g., multiple local transit agencies, trains, intelligent transportation systems [ITS], traffic networks, and information providers) using computerized procurement, main- tenance, asset management, and delivery systems to provide mobility management to customers.7 The steps found in the overall systems engineering process are as follows: 1. Identify the concept of operations (through users and stakeholders), including a. Needs and goals, b. External factors (e.g., environment, constraints, and policies), c. Initial operational concepts, and d. Initial operational scenarios (e.g., peak, off-peak, inclement weather, and emergency/disaster). 2. Develop operational requirements (e.g., functions, pro- cess, performance, and verification). 3. Identify and evaluate alternatives (e.g., according to feasibility risk, uncertainty, reliability, and costs). 4. Trace impacts on existing organizations and processes. 5. Integrate and implement system components. 6. Provide for verification and validation. 7. Incorporate feedback and iteration into development and design (i.e., refine). 8. Manage the implementation and operation of the inte- grated system, and incorporate changes as they occur. Enterprise architectures evolved out of the business process re-engineering and IT strategic planning of the late 1980s and early 1990s. John Zachman originally proposed the idea of an enterprise architecture in 1987. Since then, the “Zachman Framework” has been refined and variants have emerged (e.g., the Popkin Process, the Federal Enterprise Architecture 3 Process, and the National Institute of Standards and Technol- ogy [NIST] Five-Layered Architecture Structure). All vari- ants, however, are multilayered strategic representations of an organization or organizations that capture the mission and business practices. Enterprise architectures go beyond systems engineering by linking mission needs, strategic plans, busi- ness processes, information content, information technology, people, and infrastructure across the agency or organization as a whole. Thus, a well-structured and comprehensive enterprise architecture provides a means of developing and maintaining documentation of a business’s operations, technologies, and decision making from different levels and perspectives and tracing them back to the organization’s mission and goals. More importantly, it provides the capability to quickly identify how changes or the impacts of proposed decisions propagate throughout the system (e.g., processes, practices, and organi- zation). Consequently, enterprise architectures are becoming more and more central to helping managers and business/ government leaders in general answer questions: How? When? Where? Why? Who does what? What tools do they need to do it? And how can business and government leaders manage change in an increasingly integrated and complex world? For example, enterprise architectures have become a key compo- nent of the federal e-government initiative.8 Figure 1-1 shows how systems engineering and enter- prise architecture will work together in the development of a transit business model and reference framework for assess- ing e-transit. The transit today (base case) and transit future (e-transit vision) business requirements and relationships between people, processes, and technology/systems for a typical large urban transit agency will be captured and rep- resented within an enterprise architecture. As this reference enterprise architecture is developed, systems engineering will be used to help determine the needs and goals of today’s tran- sit “business” and how they evolve to meet transit’s future vision; the concepts of operation as we move toward the future vision; the associated business functions and their requirements; and future e-transit opportunities and how they might be implemented. The effort will focus on cap- turing the incorporation of emerging technology in support of integrated G2G, G2B, and G2C e-commerce in the tran- sition to the transit future vision. The development of the future e-transit architecture will be based on sound systems engineering practices and, once complete, should help guide the future activities of the e-transit panel. This is explained more fully in Chapter 2. Special attention will also be given to developing the architecture at the level of detail that is general enough to apply to the industry as a whole but specific enough that potential e-transit applications can be quickly incorporated and their implications assessed. If the architecture is developed at too general a level, it will not capture enough of the oper- ations and interrelationships to be useful. If it is developed at too specific a level, it will become too tied to the technologies, software applications, and processes associated with a partic- 7See TCRP Research Results Digest 55, December 2002. 8Mark Forman, OMB Associate Director for IT and eGovernment, September 2001.

ular situation or agency to be generally applicable to others, and assessing new potential e-transit applications will become unwieldy and time consuming. 1.3 PROPOSED ENTERPRISE ARCHITECTURE PRODUCTS Three major products are envisioned for this effort. First, as discussed above, is the creation of an e-transit reference enterprise architecture that captures the following: • 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 for Public Transit results and the implementation of integrated e-transit applications. • A typical sequence of actions and their impacts for mak- ing the transition from the today base case to the future vision. The second envisioned product, since the reference enter- prise architecture is meant to help analyze, plan, and imple- ment potential e-transit applications, is the preparation of guidance on its use. The guidance will include both docu- mentation of the reference enterprise architecture and devel- opment of a user’s guide and example applications. The user’s guide will include specific guidance on how to use the reference enterprise architecture at the national level to iden- tify research needs and emerging opportunities and on how to use the architecture at the local level to analyze potential 4 e-transit applications or to develop an agency-specific enter- prise architecture for e-transit planning and implementation. The last envisioned product is the creation of an online collaboration forum and e-mail exchange that will be used to identify emerging issues and make recommendations to the J-09 e-Transit Project Panel for additional investigations under the e-transit program. It will also be used as a reposi- tory for e-transit–related literature and news articles and as a feedback forum for draft products and results. 1.4 DOCUMENT OVERVIEW This introductory section briefly discussed the following: why it is important to develop a business model and reference enterprise architecture for assessing potential e-transit oppor- tunities, the proposed approach and its use of systems engi- neering and enterprise architecture, and the products that will result. Chapter 2 summarizes systems engineering procedures and enterprise architecture concepts as they support a con- trolled, coordinated transition to e-transit by transit agencies. Chapter 3 provides a more detailed overview of the approach that will be used during the development of an architecture ref- erence model for a transit agency and how specific issues such as the coordination with the National ITS Architecture and ongoing homeland security efforts will be addressed. Chap- ter 4 presents the proposed Phase II research plan to develop the e-transit reference enterprise architecture and produce its associated guidance. The appendix provides an overview of the enterprise architecture tool assessment and recommenda- tions for this effort. Figure 1-1. A reference transit framework using systems engineering and enterprise architecture. Enterprise Architecture Repository for Information and Relationships • Needs Analysis • Concept of Operations • Functional Requirements Transit Today Transit Future Transit Today (Base) • Business Requirements • People • Processes • Technology Transit Future (Vision) • Business Requirements • People • Processes • Technology Transformation • Evaluate Alternatives • Manage Implementation • Feedback & Iteration Systems Engineering Sequence & Impacts Services, Customers Organization, Operations Services, Customers Organization, Operations Goals & Objectives, Future Vision e-Transit Options, Operating Concepts, System Requirements System Impacts

Next: Chapter 2 - Summary of Systems Engineering and Enterprise Architecture Concepts »
Concept for an e-Transit Reference Enterprise Architecture Get This Book
×
 Concept for an e-Transit Reference Enterprise Architecture
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Report 84: e-Transit: Electronic Business Strategies for Public Transportation, Volume 5 - Concept for an e-Transit Reference Enterprise Architecture examines the need for and uses of a reference enterprise architecture; the process for its development based on using systems engineering concepts and practices; the basic concepts behind systems engineering and enterprise architecture; and the transit-specific tasks associated with creating an e-transit reference enterprise architecture.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!