National Academies Press: OpenBook

Transit Enterprise Architecture and Planning Framework (2011)

Chapter: Chapter 5 - Reference Enterprise Architecture for Transit

« Previous: Chapter 4 - Development of the TEAP Framework
Page 24
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 24
Page 25
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 25
Page 26
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 26
Page 27
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 27
Page 28
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 28
Page 29
Suggested Citation:"Chapter 5 - Reference Enterprise Architecture for Transit." National Academies of Sciences, Engineering, and Medicine. 2011. Transit Enterprise Architecture and Planning Framework. Washington, DC: The National Academies Press. doi: 10.17226/14561.
×
Page 29

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.

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

payment system, and the emerging mobile/branded card pay- ment system. In the final workshop, the discussion centered around how to represent different fare management configurations, and how to generically represent applications and technology com- ponents. The results of these discussions and the workshop recommendations were posted on a private wiki site for which all participants had writer-level access. Several transit agen- cies reviewed the resulting artifacts; some agencies applied their existing systems to the model or solutions to validate them. The results of these pilots are described in Chapter 6. The final reference architecture, the four fare management solutions, streamlined implementation guidance (with tools and templates), and approach for incorporating solutions were included in the Phase I wiki site. What Is in the Reference Enterprise Architecture for Transit? The reference architecture is composed of several sets of entities, including the following: • Metamodel—Model that shows the organization of the Reference Enterprise Architecture for Transit • Reference Enterprise Architecture for Transit—Model that shows the reference architecture, including all the entities and relationships – Diagram of the model – Templates and tools that explicitly define the four EA layers, and the institutional and technical drivers of a Transit Enterprise Architecture • Fare Management Solutions—Four different configurations/ solutions for implementing the fare management segment of the Reference Enterprise Architecture for Transit • Streamlined EA Process—Streamlined approach for col- lecting information to customize the reference architecture to meet a transit agency’s enterprise These topics are overviewed in the sections that follow. The wiki contains the details and in-depth descriptions of the mod- els, tools, and process. TEAP Metamodel Overview As discussed in the beginning of this chapter, an important aspect of the reference architecture, or any EA in general, is the entities that compose the EA and their relationship to each other. The TEAP metamodel (see Figure 5) is a very close replica of WMATA’s EA metamodel; it shows the institu- tional and technical architecture drivers in the vertical box (on the left), and then the four typical enterprise architecture layers (business, information, applications, and technology) in the horizontal boxes on the right side of the diagram. Some entities are fully contained within other entities; for example, a business domain includes several business functions which specializes the functions into business processes. The links between the Information View and Business Process, or Infor- mation View and Measure indicate that there is a connection (perhaps dependency) between the paired entities. The meta- model is the foundation of the enterprise and does not readily change. Perhaps the most important aspect of the metamodel is to describe the general relationships between entities. The reference architecture can then use this model to describe entities and their specific relationship to each other. For exam- ple, an Information View element called ridership may be linked to a Measure called monthly ridership statistics. An Access database and Excel spreadsheets were developed that represent the entities and relationships described by the metamodel diagram. Transit agencies may use these as tem- plates to collect information about their organization. Overview of the Reference Enterprise Architecture for Transit The Reference Enterprise Architecture for Transit is the con- tent that is inserted into the TEAP metamodel. Based on the metamodel, the reference model is divided into several sections: • Architecture Drivers including – Vision/Mission – Transitional Processes – Locations – Standards • Business including – Business Domain – Organization 25 List of Participating Organizations in the Reference TEAP Peer Review Panel Cape Cod Regional Transit Authority C-Tran Dallas Area Rapid Transit (DART) EA Works FTA Headquarters King County Metro Miami-Dade County New Jersey Transit New York City Transit PACE EA Expert (retired) TriMet Utah Transit Authority VIA—San Antonio WMATA Table 5. TEAP peer review panel.

• Information • Applications (and related databases) and Application Families • Technologies related to their ITS System/Center association or Communication Each of these layers includes a model that depicts the enti- ties and relationships and a table with descriptions for each of the entities. The descriptions are contained in a spreadsheet and database. The database describes the relationships between entities (within a layer or between layers). Architecture Driver Layer Overview The architecture drivers are composed of four major areas including mission, transitional processes, locations, and standards. Mission. The mission topic describes the mission, vision, goals, and related objectives. The vision/mission drives the corporate goals, and for each goal there are one or more mea- surable objectives. Performance measures may be categorized by different classification schemes. For example, organizations may classify their (performance) measures based on safety, 26 Figure 5. TEAP metamodel. (Source: Adapted from WMATA Enterprise Architecture, June 2009. Licensed under a Creative Commons Attribution-ShareAlike License [CC BY-SA].)

customer service, and productivity. Each measure is related to one or more objectives (and vice versa; each objective may be related to one or more measures). A typical performance measure may be “monthly ridership statistics.” A corporate goal is to increase ridership while the objective may state: increase ridership on new routes by 2 percent per quarter over the next 2 years. Transitional Processes. The transitional processes entity lists the programs and specific IT projects planned or active that effect change to the architecture. This category may also be seen as a “Project Portfolio” or it may describe areas related to an IT strategic plan. This is the link that connects the TEAP to the TEAP Framework elements (i.e., business case, fund- ing, systems engineering, and PIR). Additionally, the project and/or program models connect to almost every entity. The transitional processes help keep track of “to-be” elements in the architecture. Locations. The locations entity is a means of assigning a “location” to the physical technologies and assets. It is also a means of categorizing these things using the National ITS Architecture centers and system nomenclature by categoriz- ing it by a type—mobile/vehicle, field, center or traveler. The information contained in a locations table may include the following: • ITS Type (Mobile/Vehicle, Field, Center, Traveler) • Grouping (e.g., Facilities, General, Mobile, Offices, Stations) • Location Name • Description • Address • Telephone • Latitude • Longitude A locations table entry is associated with each technology entry. For example, a server is located in a facility such as the agency headquarters and the backup server may be located in a data center located at an offsite facility. Standards. The standards entity is composed of IT and ITS standards; IT policies (such as branding, privacy, security); and other regional agreements that drive business processes, information, applications, or technology. Any regional agree- ments that share networks may include a Level of Service agree- ment. The network would be linked to the Level of Service agreement. Applications that implement a Transit Communi- cations Interface Profile (TCIP) standard dialog would link to the Profile Information Conformance Specification (PICS). Each of the three entities contained in the Standards entity may link to Information, Application, or Technology entities. Business Layer Overview The business layer includes the business processes and organizational structure. These entities are inextricably linked. Business Process. Business process entities are composed of the business domain, functions, and processes. Each business domain, function, and process is described from a high level. The TEAP uses WMATA’s approach for classifying the enter- prise. There are three domains: administration functions, operations and service level functions, and then cross-cutting, executive, and interagency (e.g., security, safety, and customer service) functions. The reference architecture summarizes the enterprise to the business process level; however, many agencies create flow charts that describe business processes to more detailed levels, down to specific operating procedures, sub- processes, decision points, and events (triggers). As mentioned above, the Reference TEAP includes three major Business Domains: • Enterprise Administration Domain—Supports back-office and other administrative functions • Integration Domain—Supports cross-cutting, executive, and customer functions • Transit Management Domain—Supports operations, main- tenance, and support related to providing the service to the customer Organizational Structure. The organizational structure is composed of directorates, directorates are composed of departments, and departments are composed of offices. If the levels of an organization need more than three levels, then offices may be composed of one or more offices. Information Layer Overview The information layer is composed not of specific data- bases and data sets, but of the “data dictionary” clustered into critical data sets. The information layer includes the information domain, subject area, and information views in a hierarchical relationship. Many information domain enti- ties correspond to business functions with the same name, such as: • Enterprise Asset Management • Human Capital Management • Financial Management • Operations Management and Supply Chain • Safety • Enterprise Management • Customer Service • Security 27

The reference architecture also contains aggregated domains where subject areas and information views are logically grouped together including: • Transit Domain Information—aggregates information from the four modes: rail, bus, paratransit, and vertical (elevators/ escalators) • Integration Information—which includes cross-cutting information, executive, and customer information • Core Data—which contains critical information for mul- tiple processes The core data is critical to operations of the business. It con- tains fleet information, transit gazetteer and network informa- tion, service schedules and operational performance, incidents, and more. Applications Layer Overview The applications layer includes three major entities: an appli- cation family, applications, and databases. An application fam- ily contains one or more applications, and applications include one or more databases. A database may be used by one or more applications. Additionally, an application may exchange infor- mation with another application. Because there are many off-the-shelf and custom tools that transit agencies use, the Reference TEAP designates a set of categories and types of tools in lieu of commercial or open software products. The list is based on the TCIP system types as well as common systems that are available off-the-shelf. The list is documented in the wiki at: http://tcrp-teap.pbworks. com/TEAP_Applications. Technology Layer Overview The technology layer contains information on the tech- nologies that store data and software, network equipment, sensors/performance monitoring devices, control equipment, and other devices. The TEAP metadata model creates classes of technology types that are resident in different environments. The environments correspond to the National ITS Architec- ture System and center domains: vehicle/mobile, field, center, and traveler. In addition, communications is a connection among these technology environments. The classes of tech- nologies include the following: • Communications—Network • Center—Data center, other technologies, seat management, storage, route, security • Vehicle—MDT (computer), other technologies (router) • Field—Router, personal computer, other technologies, security, server, storage • Traveler—personal computer, PDA In addition, the router “device” category included in each layer is a way to show which technology entities are connected to each network. This convention provides a way to depict and analyze physical network models. However, the relation- ship between applications and technologies shows the logical relationship among the enterprise elements. This relationship is essential to determine performance, capacity, and critical infrastructures that support corporate business processes. The Reference TEAP does not include a category for each personal computer in an agency. Typically, agencies have stan- dard configurations for their equipment, servers, and other technologies; these can be stored and reused to describe the technology layer using the seat management convention in the model. Seat management is used to describe these types of configurations (and the number of PCs with this configu- ration) and is associated with a location of a “center.” The PC may be used in the same way, but associated with a field loca- tion. The mobile data terminal (MDT) is defined as the on- board computer. To that end, there may be more than one device on-board designated as an MDT. In developing one of the pilots, we reviewed an approach for documenting servers and personal computers located at transit stations. The rela- tionship between the seat management (center) and personal computer (field) is a means of tracking the configurations and software licenses of field equipment. TEAP Solutions for Fare Management Solutions in the fare management segment are described for four alternative configurations. The entities and relation- ships are explicitly defined for the four EA layers—business processes, information, applications, and technologies. In reviewing a number of representative fare management con- figurations, we found that the relationships among TEAP Business Processes and Information Sets are fairly stable from implementation solution to implementation solution, partic- ularly since they revolve around the Financial Management function. On the other hand, the solutions (and connections) for applications and technology may differ greatly depending on bundling of application functions, and adoption of meth- ods, services, and technologies. The term “solution architec- ture” is used in the IT industry to describe different ways of implementing applications and technologies to enable simi- lar business processes and generate comparable information sets. The approach used to generate alternative solutions for the TEAP was to model four configurations that are typical or emerging in the transit industry for the fare management area. The four solutions are: • Closed Fare Management System (with partners) • Closed Fare Management System (used by partners) • Mobile Fare Payment System • Open Fare Payment System 28

The models were developed so that an agency may grab the templates and content of a model, revise the names of processes and information to map to their organization’s terminology, relate the application categories and types to their application products, and assign the specific technology vendor to each of the technology components. Each fare management solution is described by an enterprise model (with the key components of each level and their con- nections) and a spreadsheet with several sheets that describe the entities or the relationships (associations) between entities. The spreadsheet files contain a separate sheet (tab) for business process, information, application, and technology views. In addition, there are sheets that relate the business processes to information sets, another sheet that relates the business processes to application categories and types, and so on. These fare management solution spreadsheets and tem- plates may be used as building blocks to apply to your orga- nization’s EA. Moreover, because emerging fare management solutions are described, an agency migrating from a Closed System to an Open Payment System can use both models and describe the gaps, processes, data flows, and organizational changes that will be affected by the transition. Streamlined EA Process The streamlined process was developed for describing a spe- cific “as-is” (current) EA (see Table 6). It describes how to get started, that is, how to begin to populate an EA that describes a specific organization. The processes to maintain, update, and transition to a future architecture are left as a future research effort. Moreover, the “to-be” or future architecture is typically recommended on a per-project basis since it requires alter- natives and business case analyses to understand costs and impacts. The addition of solutions enables migration to new models, applications, and technologies as they evolve in the industry (e.g., IT, ITS, and transit). Details including templates, purpose, examples, and meth- ods for each step are described in the TEAP Guidance pages. Each step includes a page where practitioners may provide addi- tional guidance, assistance, and tools to address new challenges. 29 Step Streamlined Processes for the TEAP 1 Describe Locations. Identify physical locations of entities owned or used by your organization. This includes passenger facilities, third party fare outlets and information kiosks, transit vehicle and equipment depots, and staff facilities. 2 Describe the Organization. This is a list of the organizational structure and staff of your organization. The positions in the organization chart will be linked to their roles and responsibilities within the business processes. 3 Complete Mission, Vision, Goals. Describe the mission, vision, goals. 4 Review and Edit the Business Process View. At a minimum, search and replace “AGENCY” for the name of your agency. 5 Review and Edit the Information View. At a minimum, search and replace “AGENCY” for the name of your agency. 6 Application Inventory. Collect an inventory of your applications. 7 Technology Equipment Inventory. Collect an inventory of your servers, networks, communications devices, and other technologies. Table 6. Streamlined processes for developing an “as-is” transit enterprise architecture.

Next: Chapter 6 - Evaluation and Next Steps »
Transit Enterprise Architecture and Planning Framework Get This Book
×
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 9, Transit Enterprise Architecture and Planning Framework presents multi-faceted methods, tools, and examples within a framework to help transit agencies successfully implement technologies.

The report describes the connections between a transit agency’s business and the technology, assists with building the business case for specific investments, highlights different financing options, provides guidance on an enterprise-wide approach to create more efficient and effective system deployments, and provides a method to show the benefits of a technology investment.

The report provides a framework that incorporates five systems management disciplines: Enterprise Architecture Planning, Business Case Methodology, Systems Engineering, Financial Implementation Methods, and Post-Implementation Assessment.

The declining costs of communications, data storage, and data retrieval are accelerating the opportunities spawned by the Internet and other information and communications technologies. Choosing and sequencing investments in technologies, processes, and people to reduce costs and increase productivity present challenges to the transit manager, who must weigh the costs, benefits, and risks of changing the ways services are delivered. To assist in meeting such challenges, the TCRP Report 84: e-Transit: Electronic Business Strategies for Public Transportation series documents principles, techniques, and strategies that are used in electronic business for public transportation.

  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!