Click for next page ( 25

The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 24
24 CHAPTER 5 Reference Enterprise Architecture for Transit Purpose of a Transit Enterprise nents include data/processing servers, routers, modems, net- Architecture Process works, and other devices. Reference Model As described previously, the general purpose of an Enterprise Methodology Used to Develop Architecture (EA) is to understand the connections between the Reference Enterprise your organization's business processes and stakeholders (users, Architecture for Transit upstream providers, and downstream recipients); this infor- The Reference Enterprise Architecture for Transit was mation is used to measure performance and make decisions, developed from a comprehensive, albeit high-level, existing as well as develop applications and technology that enable EA model developed by WMATA. The WMATA EA, which the services and generate the information. Most transit agen- includes several modes and references to other transit man- cies support similar business processes, information views, agement systems, presented a starting point that details some applications, and technologies. The relationships between of the complexities of large transit agencies, yet may be scaled the models that represent each layer do not differ greatly either. down to smaller organizations. This provides an opportunity for the industry to describe a To ensure that the WMATA EA represented the diverse generic reference that may be customized based on the par- transit industry, a team of transit IT experts from more than ticular agency, rather than having each transit agency start a dozen transit agencies of varying sizes, including urban/ from scratch. A reference architecture defines the common suburban/rural agencies, and supporting different modes, were elements found in each of the four EA levels and their typical brought together to review and walkthrough the architecture. relationship to each other. In addition, several EA experts from other sectors were included In addition, organizational drivers also contain common ele- in the expert peer review group. (See Table 5 for a list of par- ments. Most transit agencies include a hierarchy of staff and ticipating organizations.) As other agencies heard about the mission/goals/objectives that drive performance measures. The Reference TEAP, they too asked to participate in reviewing, challenge in developing the reference architecture comes in piloting, or commenting on elements of the architecture. describing application and technology models. These change Three workshops were conducted for the participants. The and evolve continuously; different vendors may present vastly first workshop highlighted a presentation by the Chief Archi- different solutions. The reference architecture handles these tect from WMATA, Jamey Harvey, on the WMATA EA. Har- challenges by modeling different solutions at the application vey described the EA organization (metamodel), content, and and technology levels. Together with the business process and general principles he used at WMATA. The second workshop information view elements and relationships, the different solu- focused on how to make the architecture more generic and tions (see sidebar in Chapter 2) using typical application and what segment to select for review and refinement (develop- technology categories and types provide the building blocks for ment of one or more "solutions"). The result of this second developing EA models customized to represent each transit workshop was the selection of the fare management area for agency. The application categories and types may include review. Prior to the final workshop, team members inter- generic systems such as workforce management, financial viewed different agencies that were developing typical and management, customer relationship, customer information, new solutions for fare management. The models included and maintenance management. Typical technology compo- closed systems that most agencies currently implement, open