Module 16: An Introduction to Transit Enterprise Architecture and its Benefits
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
Module 16: An Introduction to Transit Enterprise Architecture and its Benefits
Table of Contents
1. Module Description
This module provides an introduction to Enterprise Architecture and its benefits for transit managers and staff. It describes the four layers commonly seen in transit enterprise architectures, the Business Architecture, Data or Information Architecture, Applications Architecture, and Technology Architecture. Potential architecture drivers, such as goals and standards are described along with their role. In an EA, the identification of connections between components in the different architecture layers and the architecture drivers, provide significant value to a transit agency. This module highlights a wide range of EA uses and benefits to a transit organization and its Intelligent Transportation System efforts.
To support the development of a transit agency EA, this module will briefly discuss some possible tools, resources, needed staff roles, and potential challenges. It will identify known EA efforts in transit. The module will highlight some of the possible beneficial relationships between an agency's EA and its Regional ITS Architecture, standards, systems engineering efforts, and IT/ITS project architectures.
Transit agencies are implementing more and more Intelligent Transportation System (ITS) and Information technology (IT) systems to improve the delivery of transit products and services. Often, the increase in IT/ITS projects also creates design, operations, and maintenance complexities for systems, data, and other technology components within a transit agency. For example, many ITS systems must communicate or share data with other systems. Further, with more ITS systems within an agency, interdependencies between hardware devices increase. As a result, it can become difficult to efficiently plan and troubleshoot business processes and systems given the complex interconnections.
The use of Enterprise Architecture (EA) principles and tools provide managers and staff better visibility into the components of their organization and the overall relationships among their enterprise's people, processes, applications, data and technology components. For example, by providing a system-wide view of aggregate transit ITS elements and their relationships, an EA supports better IT/ITS planning and operations, business process improvements, improved integration throughout the agency including data and systems, the consistent use of standards, and other benefits.
Business Architecture Summary View Example
As a part of the Transit Cooperative Research Project J-09/Task 13, titled Transit Enterprise Architecture and Planning (TEAP) Framework, some EA-related guidance and preliminary tools were developed to assist transit agencies in developing an EA model. In addition to the TCRP report, a website was developed that includes links to general information about EA and some tools to facilitate identifying transit business functions and broad categories of transit data used by applications and processes. (See: http://tcrp-teap.pbworks.com/w/page/19763362/FrontPage)
The following figure is an example of how King County adapted the TEAP Business Architecture Reference Model (a preliminary identification of key transit business processes and functions).
(Extended Text Description: Author's relevant description: Example of how King County adapted the TEAP Business Architecture Reference Model. This figure shows a number of text boxes that are a partial representation of a Summary View of the Business Architecture (BA) developed at King County Metro. This shows that the Functions and Processes in the BA were grouped into three Domains, the Enterprise Administration Domain, Transit Management Domain, and Transit Domain.)
Example of an EA Principle Description (from the Open Group) Name: Interoperability
Statement: Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology.
Rationale: Standards help ensure consistency, thus improving the ability to manage systems, improve user satisfaction, and protect existing IT investments, thus maximizing return on investment and reducing costs. Standards for interoperability also help ensure support from multiple vendors for their products and facilitate supply chain integration.
Implications: Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement a non-standard solution. A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established. The existing IT platforms must be identified and documented.
The source of the EA Principle example shown above is The Open Group on EA Principles: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html
4. Reference to Other Standards
An Enterprise Architecture repository for a transit agency may include both industry and organizational standards used by the agency.
5. Case Studies
Within the transit industry, there are agencies that consciously manage their IT/ITS investments using enterprise-architecture principles; however, there are only a handful of agencies that have invested in enterprise architecture modeling software and have built an EA model. In large part, EA is not well known within transit for a variety of reasons. One reason is because EA is a relatively new field, less than 30 years old. Like many new fields, it was constantly evolving, with a handful of proposed EA frameworks that at first glance looked sufficiently different to be confusing. Further, the EA software modeling tools were initially very expensive. Many of those factors have now changed significantly, with more information in EA available, more skilled practitioners, the development of a transit specific EA framework (TEAP) that makes it much easier for transit to develop an EA model to assist their agency, and some of the EA software modeling tools being much more affordable and easier to use.
The following are some of the transit agencies that have had enterprise architecture initiatives:
Chicago Transit Authority (CTA). In the 2009 - 2011 timeframe, CTA began development of an EA model for the agency as they were interested in a bid for the Olympics. The EA model was intended to help
CTA assess and solve infrastructure issues. After a period of staff turnover, both the Chief Information Officer, who was the project sponsor, and the Enterprise Architect, who was the primary developer/user of the system, left the agency.
King County Metro (KCM). The EA model development project at KCM assessed a variety of EA modeling tools and focused the design of their EA model to support a wide-range of specific business objectives affecting their technology investments. The agency's application inventory needed updating and more information added to address a wide range of business questions. The EA was needed to facilitate a data infrastructure replacement project to make sure that affected applications, databases, and business processes across the agency were identified. The EA modeling tool significantly improved the management of transit servers and helped the IT group to better understand the applications, databases, and work groups affected by their changes. The EA modeling tool has been used to support strategic planning, assist supervisors and managers in understanding the depth of business functions their staff support as well as the applications that they depend on, and other uses.
Transport for London (TFL). The Enterprise Architecture started within London Underground in 2008 as a repository for application information using Avolution's ABACUS EA modeling software. The model was originally used to generate reports about applications and business processes; not for complex system modeling of low-level details. After the merger of IT departments, TFL currently uses Avolution's ABACUS EA modeling software primarily for process analysis, but is looking to expand its use.
Toronto Transit Commission (TTC). The TTC recently began implementing an enterprise architecture model.
Washington Metropolitan Area Transit Authority (WMATA). In 2007, WMATA began development of an EA. It was initially developed to help build a new agency-wide strategic direction to improve customer information across transit systems. Over time, the use of the architecture tool was expanded to assist with some additional issues facing the agency. The Chief Enterprise Architect was the primary owner of the model, with help from a couple staff. When the original Chief Architect and the Champion left the agency, the EA was more lightly used for a few years. Staff turnover has been a factor; however, activity with the model has continued at WMATA.
In a number of cases where the EA initiative stalled due to staff sponsors and/or Enterprise Architects leaving the agency, there has been renewed interest in the topic. When too few individuals within an agency are aware of and use a process or application, it becomes very vulnerable to staffing changes. Modern EA tools allow for permissions and distributed responsibility for data updates and analyses, so knowledge of the EA does not have to reside in one individual.
8. Study Questions
The quiz/poll questions and answer choices as presented in the PowerPoint slide are included here to allow students to either follow along with the recording
1. Which of the following is NOT a typical name of a layer in a Transit Enterprise Architecture?
2. Which of the following is NOT a common benefit of a transit EA?
3. Which of these statements about an EA is NOT correct?
4. Which of the following would be the poorest EA Principle for supporting efficiencies in transit?
9. Icon Guide
The following icons are used throughout the module to visually indicate the corresponding learning concept listed out below and/or to highlight a specific point in the training material.
1) Remember: Used when referencing something already discussed in the module that is necessary to recount.
2) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.
3) Example: Can be real world (case study), hypothetical, a sample of a table, etc.