ITS Transit Standards Professional Capacity Building Program

Module 16: An Introduction to Transit Enterprise Architecture and its Benefits

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Vincent Valdes: ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. Transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry. However, these benefits can only be realized if you know how to write them into your specifications and test them. There are now a series of modules for public transportation providers that cover practical applications for promoting multi-modalism and interoperability in acquiring and testing standards-based ITS Transit systems.

Nancy Neuerburg: Welcome to the training module titled "An Introduction to Transit Enterprise Architecture and Its Benefits".

Nancy Neuerburg: My name is Nancy Neuerburg, and I'm very pleased to have this opportunity to present this introductory course on transit enterprise architecture and its benefits. I've worked for over 27 years in transit, focused primarily on using technology such as IT and intelligent transportation systems to improve transit. Twelve of the years were spent as a senior manager at King County Metro in Seattle, where I was responsible for management information and transit technology. Since then I've supported the transit industry as a consultant, primarily in the areas of IT and ITS. While I have used enterprise architecture principles for many, many years, the use of EA software tools is fairly new to transit. I would have loved to have had an affordable EA software tool earlier in my career to help make my job simpler and for projects and changes to be implemented more quickly. My 27 years in transit have given me an enterprise-wide knowledge of its business processes, data, information needs, technology systems, and integration issues, which helped me realize the immense potential value of EA principles and tools. I've worked on a number of enterprise architecture projects, such as developing an enterprise architecture model using ABACUS software for King County Metro Transit. I helped develop an enterprise architecture and IT/ITS strategic plan based on the EA for Miami Dade Transit, and co-project manager and a lead developer of the Transit Cooperative Program's project to develop a transit enterprise architecture planning framework known as TEAP.

Nancy Neuerburg: This training module has four learning objectives, which are to define an enterprise architecture; review the benefits to a transit organization of having an enterprise architecture; describe the general process for creating a transit enterprise architecture; and articulate how use of EA principles can benefit a transit agency.

Nancy Neuerburg: The first learning objective is to define the enterprise architecture, including being able to understand enterprise architecture from 10 thousand feet, identify architecture layers commonly seen in transit enterprise architectures, such as the business, data, applications, and technology architecture layers; recognize that there are enterprise drivers, such as agency goals and standards, that influence or drive the development of an enterprise architecture; and finally, recognize and understand how defined connections or relationships between architecture layers and components are valuable and might be used.

Nancy Neuerburg: This slide and the next one introduce enterprise architecture at a very high, nontechnical level. What does an enterprise architecture do? It creates efficiencies by providing managers and staff visibility into the overall relationships among their enterprise's people and processes, data, applications, and technologies. Through connections, an EA can be designed to more quickly answer questions that require information from different parts of the organization. For example, think about your agency and how well and how quickly it might answer questions such as the following: Do you know all the systems on which your business areas and/or staff depend? What work groups are affected when a server goes down? When there is a political crisis focused on a business process or system, can you and your agency quickly determine what work groups or systems are involved? Do you know where to look up information about systems, about the business, and about other technology elements? These are but a few examples of the types of questions or issues that can be addressed and supported by an enterprise architecture.

Nancy Neuerburg: So what is an enterprise? An enterprise is any collection of organizations that has a common set of goals. This definition is from the Open Group, which has a website and a lot of valuable, useful information about enterprise architecture. For the purposes of this presentation, an enterprise is a transit agency. So what is architecture? The definition of architecture here is the fundamental organization of a system embodied in its components, the relationships to each other and the environment and the principles governing its design and evolution. This is an ISO definition. How is better visibility into transit achieved? The key to better visibility into a transit agency is the repository and the tools used to access, analyze and display information about the agency's enterprise architecture. Not so long ago, in the early years of EA, the architecture of an enterprise was often described in a tall stack of Word, Excel, and other types of typically paper documents. Now more affordable and very powerful EA software is commercially available. The software facilitates modeling, the reuse of architecture building blocks; it facilitates making connections, as well as conducting searches and analysis of the architecture, and produces information in a variety of pre-structured, nice, visual displays.

Nancy Neuerburg: So the architecture layers that are commonly in an enterprise architecture are the business architecture, the data architecture, the application and technology architectures. In the architecture industry, you will find a range of terms and ways of representing your enterprise and the frameworks for describing the organization. The approach described here in this introductory course is one of the most common for introducing and communicating about an enterprise architecture. Some enterprise architectures have additional layers or domains, but they tend to exist in different industries, or more likely, in industries with longstanding EAs that have evolved over the years to a higher level of maturity. So for example, a performance architecture. We will describe these four layers of the enterprise architecture in more detail in the coming slides.

Nancy Neuerburg: The first layer I'm going to talk about is the business architecture. Business architecture provides a high-level organized view of the business that is hierarchical and mutually exclusive representation of the business. A hierarchical design allows rolling up of descriptions so that the information can be stored and presented at various levels of details for different audiences. So if somebody was deep in a task of looking at a process improvement, it might have a lot of steps, but if it was rolled up for a manager, it might be at a very, very high description of the area of the business architecture. So for example, business functions such as financial management may be broken down into more discrete processes or subprocesses, such as the general ledger process, grants process, or budget process. Functions may also be aggregated upwards by an agency and to larger groups called domains, such as the administration domain. The choice of domain as the descriptor of the higher-level category is arbitrary. It was used in the TEAP model and works sufficiently here. Some agencies choose not to use them. Some agencies use it and ignore it and only use it when they need it or are interested. The next slide will show an example of domains being used to help describe the business architecture. So, again, the component names used here: domains, functions, and processes, are terms used in the Transit Enterprise Architecture and Planning framework, or TEAP, that was developed with the support of the Transit Cooperative Research Program, and the purpose of the project was to review and consolidate a lot of different models and information about enterprise architecture and structure something that is better tailored to transit. So, in general, the high-level descriptions of a transit agency's functions and processes; in other words, what is done are fairly stable. The organization represents who does it. The organization can be represented by divisions or work groups or other terms that an agency uses to hierarchically represent their organizational structure. The business architecture contains information about the relationships or connections between the components of the business architecture as well. Later, we'll talk more about connections or linkages between components of the EA. So for now, the business architecture can help project developers understand the business better and identify stakeholders. New managers and supervisors can study the BA to better understand their scope of responsibility. Further, the business architecture facilitates business process improvement efforts and reorganization efforts. In some organizations, they only use the business architecture because they're very focused on business process improvement. In other organizations, the enterprise architecture might be driven by an IT department and it would have more information on other layers of the architecture as well.

Nancy Neuerburg: This next slide is a partial representation of a summary view of the business architecture developed at King County Metro. A more complete version of this graphic is available in the student supplemental materials. The development of this business architecture summary view and Metro's business architecture was also facilitated by the TEAP, or Transit Enterprise Architecture Planning framework. So looking at the figure here, the right side of the graphic shows the functions and processes in King County Metro that were grouped into three domains: the enterprise administration domain, the transit management domain, and the transit domain. So the domains were felt to be helpful in some circumstances and could be ignored when they did not add value. If you look at the enterprise administration domain, that includes things like the human capital management function, the financial management function, the audit functions, legal functions. Metro chose to have a transit management domain that included things, business functions, that served all of transit but weren't the traditional, classic administrative functions. So in the transit management domain, they included strategic planning process, performance reporting process, market research and analysis process, and others. Again, you can see the full breakdown in your Student Supplement.

Nancy Neuerburg: This next slide talks about how a transit business architecture can be extended. Often it's helpful to extend the organization portion of the business architecture to include external stakeholders that are technically outside of the enterprise. External stakeholders are usually included in an extended enterprise architecture because they play a key role in a business function or process, or they're providers of important data, or they have ownership of a system and/or infrastructure used by transit. This slide shows how the organization component in the business architecture model can be extended. Organization is modeled here with two major subgroups, or subcomponents: the transit and also external stakeholders. The transit portion is shown rolled up to the highest level. The external stakeholders’ portion shows some categories of external stakeholders with the category Other Governance Partners and Regulators further expanded. So examples of types of external stakeholders are transit agency partners-- for example, agencies who may share or co-manage a function, application or data, like, for example, a trip planner application or a landmark data set. External stakeholders can include other government partners and regulators, such as the FTA, state, cities, or a local MPO. For example, a city may partner on a transit signal priority project with transit, or a state may share their fiber optic network with transit so that it also is a part of transit's communication network. Another example is financial organizations such as bands and clearinghouses. They may be represented in an extended architecture because they support the fare collection function. Another possible category that might be added is business customers, which might include a major university that distributes bus passes.

Nancy Neuerburg: This next slide shows another way of representing an extended business architecture. This example shows how elements of the extended business architecture might be represented graphically. The vertical labels on the left side of the graph indicate the two major components of the business architecture: functions and organizations, with the organization being who does the function. Along the top of the business architecture box, you are looking at some of the key stakeholder work groups involved in the fare collection function. The fare collection function at the bottom shows two processes: the fare administration processes, and the fare collection process. So what you see is, to do the fare collection function, finance is involved, marketing and sales is involved; operations helps with the fare collection; customer service helps; information technology has a role in making sure all the systems work. Then on the right, circled in red, are examples of external stakeholders who are part of the extended architecture, and they might be in a fare collection function in a region; other transit agency partners, a regional clearinghouse, or a local bank. In summary, looking at this, you can see the external stakeholders for this fare collection function are important to the function, but they do not reside within the transit organization, so they're identified in the extended business architecture as external stakeholders.

Nancy Neuerburg: I'll now talk briefly about the data or information architecture. Different organizations choose to name this layer of the enterprise architecture as either the data architecture or the information architecture, depending on their past practices. For this presentation, it will be called by the shorter name, data architecture. The data architecture describes the data and the structures used by an agency and its software applications. It can include the meaning and relationship of information categories, information on data integration within the organization, and can answer questions if the information is included related to how data is managed. The graphic at the bottom of the slide shows a relatively straightforward way of organizing data in the data architecture. The three nested components, on the left side of the data diagram; in other words, the information domain, subject area, and information view, help define a potential hierarchical, conceptual data model for transit. The conceptual data model for transit makes it easier to find and understand data in the agency at a high level. So for example, two information domains in transit might be customer service information and security information, both very different domains. Since customer service information is complex, it is very helpful to break it down further. So two subject areas in customer service information might be service status info and accessibility info, and I'll have a more detailed example shown on the next slide. How is this conceptual data model helpful? Well, it can help in a number of ways. Responsibility for data can be defined better because each of these data-related components, whether it's information domain, subject area, information view, each of them can have properties associated with them, such as a definition, who is responsible for it, and other factors. Another benefit for how this conceptual data architecture might be used is when somebody is updating an out-of-date application inventory, the updating can be expedited by looking at the conceptual data architecture for the agency and asking, "Is there an application that processes or uses this data?" During requirements gathering, the conceptual data model can be used to have an ITS project manager prompt stakeholders' memories by asking about data categories. One of the big benefits of starting to define a data architecture in an agency is that it helps drive the agency away from isolated silos of information, which sometimes come in from different vendor products. They architecture helps move the agency down the path of standardization and realizing more efficiencies. Creating the data architecture helps identify areas where the same data might be named differently or where different data is named the same. Circumstances like these slow down troubleshooting and lead to data discrepancies that occasionally the public catches. In addition, in the act of creating data architecture, opportunities for more efficient data maintenance and better troubleshooting are often found, particularly when it is discovered that three variations of an inventory are being maintained separately by three different parts of the organization. Not so much now, but years ago transit agencies had many different bus stop inventories being maintained in their agencies without too much efficiency going on. So there might have been one in facilities management; there was definitely one in the group that did facilities planning; the customer service group that provided next bus information or trip planning information or service information to the public also was very motivated to keep the information about stops up to date. So let's now look at the right side of the diagram at the bottom, which has the nested boxes of database, schema, and table. This right side is a more technical modeling of data at a transit agency, and can give managers and developers an overview of the databases supporting the agency. For some ITS projects, it may be useful to include the schema for the database, and the schema describes the skeletal structure of the database, and perhaps even the names of data tables in the database might be useful to somebody implementing an ITS project. Many agencies, particularly large ones, have specialized software for managing database information. This data architecture repository is a complementary tool to help point the way to more detailed information about the agency's data elsewhere. So the enterprise architecture tends to be at a higher level, although some agencies choose to use it as their primary tool. It varies widely and is mostly driven by the decisions of the IT organization. So here is an example of a small piece of transit's conceptual data architecture. The structure that is being used to describe the elements is on the left; on the right is the example. So within data is customer service information, which is the information domain. Within the information domain, there are two subject areas, service status and accessibility. Because service status is complex, there are two information views shown here, alerts and public announcements, and for all of us that work in transit, we know there are many, many more subject areas and information views within customer service information. This is just an example to show how this model might be used for describing things, and it also shows that you can roll it up to whatever level you want for looking at either just a high-level sense of all the kinds of data being used by transit, which is of interest to people who are fairly new, or new hires, perhaps; and then down at a more detailed level for planning projects, and if somebody were actually to program, they would have to go even to more details, which would never be stored in an enterprise architecture. As an agency matures in its development and its use of an enterprise architecture, the data architecture model may be expanded and become more complex. A decision must be reached with the agency's IT staff about what data-related information best goes into an enterprise architecture model versus more technical database administration software tools.

Nancy Neuerburg: Now let's switch to a discussion of the application architecture.

Nancy Neuerburg: What's an application? An application is a software program, service or tool that processes, stores, or performs a function related to the enterprise. For example, a customer relations management system, the payroll system, and CAD/AVL are considered applications. So what's the application architecture? The application architecture describes the many applications and software services needed to support the operation of an enterprise, such as transit. It can include relationships and connections such as interfaces. A fairly basic application architecture may have the applications defined and organized by three components. First, application grouping may be selected to help categorize and understand the range of applications in the agency. So for example, security-related might be an application grouping. Another possible grouping is customer-facing applications, and the grouping of customer-facing applications would be useful if the agency were striving to achieve a consistent look across all its customer-facing applications, and if it wanted to ensure consistent information across those applications. In assessing an agency's application architecture, I found application groupings to be a useful component for helping highlight issues of interest or concern to the agency. Within application groupings are applications. They're in the smaller blue box. The applications in the architecture can have many properties associated with them, such as the application name, acronym, a description of it, version, its status, such as it's in development, it's up for retirement-- any one of a number-- connections to business processes, the main sponsor of the application, associated standards, embedded applications, service contract information, and many other projects. If the right properties are included for the agency, the applications can be sorted and analyzed many different ways to find answers for different business questions and purposes. Each property that is included creates some level of data gathering and maintenance work. So in prioritizing what properties to include, think about which ones help solve an important ongoing business need. Some of the properties will be core properties that are always maintained, and others may be added for specific analysis of interest. Another common component in application architecture would be application modules. Some applications have modules that a transit agency would want to identify and track as a subset of an application. This may be helpful for contacting vendors, for support in understanding why the modules are not working well together, for negotiating licensing, any one of a number of things. So in summary, the application architecture can help project developers identify stakeholders, find dependencies, and expedite the information-gathering tasks needed to develop requirements. Also, the application architecture can help identify integration opportunities and problems. It can help identify when maintenance contracts expire, what standards are used, what applications are in the ITS architecture, and help ensure that the development enhancements of applications align with the business strategies of the organization. Most transit agencies have inventories of their applications in various states of completeness and accuracy. The act of putting it within an enterprise architecture context allows for connections, additional mechanisms for verifying the quality and improved sharing of the information about the applications.

Nancy Neuerburg: Here is an example of how applications groupings can be created to better visualize the application environment and potentially help identify areas to improve in the application architecture. So, down below at the bottom you see the three-component nested hierarchical groupings for describing applications, is the simple model proposed here, and when it is illustrated, the application grouping might be customer-facing applications. There are several applications in that group: the trip planner, the ride match, and a transit web app with schedule information. These applications do not happen to have any modules associated with them. Other groupings that might help understand something about the applications in a transit agency might be an application grouping called Reporting Tools, and the purpose of putting them in that grouping would be to see how many reporting tools are being paid for by the agency and are requiring different learning curves. Reporting tools can be purchased by the agency as the supposed standard, yet others arrive as part of vendors' business applications and are basically embedded applications with perhaps a different licensing structure, and business groups sometimes go out and acquire their own. So by taking an enterprise-wide perspective, you can see across the whole organization how many you have, is it a proper number, is it the right one, do you want to have a strategy for potentially reducing or migrating to a particular standard. Having the application architecture allows you potentially to identify and group applications that must communicate with a transit vehicle, which may cause network or communication impacts. The application architecture can help identify service contract status. It could answer what applications have service contracts that will expire in the next year. It may answer the question of how many software licenses must the agency keep up to date to meet standards. So for each of these questions, when the properties of the application architecture are developed, the designer needs to make sure that the right properties are there for each of those questions. There is no point in putting properties in where there are no business questions that will query them. They simply would be adding a maintenance burden.

Nancy Neuerburg: The next architecture layer I'm going to talk about is the technology architecture, and it includes infrastructure components such as servers, computers, security and network devices, ITS devices, and network communications. The technology architecture can capture both the information technology and ITS infrastructure components that are required to support the data and applications of the transit agency. This graphic shows potential categories of transit architecture components. The technology architecture is easier to understand. It works pretty well when it is partially organized around concepts from the National ITS Architecture, and includes the categories of center, vehicle, field, traveler, and communications, which help identify or indicate on a broad level where the technology components are located. The center represents the technology elements located in transit offices, bases, or data centers, for example. The vehicle category represents the technology equipment on revenue or non-revenue vehicles. The traveler infrastructure represents the devices that travelers use to receive information, such as smartphones and laptops. Finally, the field includes components that are located at the roadside, such as ITS equipment used for transit signal priority, fare collection, or bus stop signage. Each transit agency decides what technology components that it wants to inventory and connect to other parts of the enterprise architecture. For example, an early enterprise architecture application might be to connect servers in the technology architecture to applications in the application architecture. This is a very popular connection because it helps ensure business continuity. So if a server is going to need maintenance or have to go down or have to be replaced, rather than just blanket the agency with an email, "Oh, we're going to have some servers down," and everybody thinks, "Well, maybe it's not mine," by knowing specifically what applications are on that server or databases are on that server, and then with a connection to who uses those, they can be more targeted in communicating about issues that may arise. The decision on what to include in the technology architecture depends in part on what software and inventory systems the agency already has. It may simply point-- the EA, that is to other inventories. A main benefit is to be able to see and understand at a high level what types of technology components have been purchased and are in use at the transit agency.

Nancy Neuerburg: This next slide is a bit complicated and we have some subsequent slides that bring each piece into a little higher focus. This graphic shows a high-level summary view of a potential transit agency's technology architecture. It's helpful for understanding the categories of technology elements that a transit agency owns, manages, or communicates with, such as servers, radio systems, networks, and an on-vehicle equipment. In this layout, you can see the National ITS Architecture categories of center, vehicle, field, traveler, and communication represented again. Up in the upper left corner is the center. The lower left is the field-- technology components that are located in the field. Those two are connected by communication elements such as WANs, ITS networks, radio systems. Lower right is components that are on vehicles, first the bus and then non-revenue vehicles; and then up in the upper right are examples of technology components that a traveler might use; and again, we'll go into more on subsequent slides here. The challenge in creating this kind of a summary diagram is determining the level of detail that can reasonably fit on one page. This type of diagram pretty much is 11 by 17 for readability, and it is a struggle in dealing with technical staff to come to resolution as to how much detail is there, because every one of these technology components has various levels of information down to highly detailed schematics. So one of the decisions about deciding what to put on here is legibility, who the audience is, and what point you're trying to make. This particular version is simply trying to show high-level people or new people or people who forget what are the basic building blocks, the basic elements that are in their agency's technology architecture.

Nancy Neuerburg: This next graphic shows an expanded view of the center portion of the prior diagram. And it's designed to show number of locations where servers exist and the location of other critical technology components such as radio system consoles. So you can see the servers are shown to exist externally at other agencies, such as their fare collection clearinghouse, at their data center, and at their bus bases. Again, like the other one, it's a balancing act to find the right level of detail in a summary diagram. The graphic design should be guided by a small number of questions that the graphic answers. Key connections between these elements are also shown at a really high level.

Nancy Neuerburg: This graphic shows an expanded view of the field portion of the high-level summary view of an agency's technology architecture. The enterprise architecture can remind developers of the types of devices that are being used by an agency and reference the current asset tracking system for each device. For example, an agency might have transit signal priority equipment at the wayside in ITS cabinets. It might also have real-time information signs at a transit kiosk. Some of those inventories potentially could be stored in the enterprise architecture, but typically most agencies already have a separate inventory. Just not everybody knows where they are or what's in them.

Nancy Neuerburg: This graphic shows an expanded view of the vehicle portion of the summary diagram of a hypothetical transit agency. It is helpful for getting quickly a sense of what the technology elements are on a bus or non-revenue vehicle. Each agency would customize a drawing like this to show what technology components they have. So it shows significant technology architecture components located on vehicles. It happens to have, on the sign, a listing of onboard ITS functions. Those onboard ITS functions would use many of the technology components on the bus. And in the upper right corner there, it shows for a potential agency technology devices that might be on non-revenue vehicles, such as laptops and mobile or portable radios.

Nancy Neuerburg: This summary view shows components used by travelers, and if you look on the right, it can be fare cards, mobile or smartphones, regular telephones, laptops, PCs, tablets. It could also display components used by employees, such as electronic ID cards, portable fare readers, or radios.

Nancy Neuerburg: I'm going to go back to this diagram here, because of the communication potential element to it. Sometimes when transit agencies do these enterprise descriptions of their technology architecture, they find out that different parts of the agency have been using different cellular service providers, and sometimes the use of multiple providers is required, but sometimes the decision can be reviewed to see if they can be consolidated for cost-savings and less administrative issues. Sometimes also in a region there are multiple radio systems that pose interesting issues for emergency response and other events.

Nancy Neuerburg: I'm going to switch gears now and talk about enterprise architecture drivers. Drivers can be included as components of an enterprise architecture, and they can influence or drive all four layers of the architecture. Examples of potential drivers are agency goals and objectives, transitional processes such as new initiatives or ITS projects, and standards. Enterprise architecture drivers are essential for guiding the development of a future or to-be version of an enterprise architecture. I should just say that today most modern enterprise architecture modeling software tools can do scenarios which can be guided by the drivers, such as new goals or projects. As a result, some agencies' enterprise architecture repositories and models include both the current or as-is version of the enterprise architecture as well as one or more future or to-be enterprise architecture models. Drivers can be useful for assessing components of the current EA. For example, how well an application meets the goals or projects of the agency? They can also be necessary for creating efficiencies through standardization. I should also mention that performance measures also drive or influence a transit agency but they are not always included in an enterprise architecture repository in the beginning. It's a little harder and there's a lot more work involved in doing that. Agencies that have a more mature enterprise architecture and good staffing levels for the maintaining of the enterprise architecture may eventually add key performance indicators that are linked to different parts of the enterprise architecture, such as functions or technology infrastructure performance. But I think, having watched a number of agencies, that it's a more advanced feature.

Nancy Neuerburg: So in general, linking drivers to components of the enterprise architecture highlights priorities and weaknesses. By linking goals and objectives to proposed or existing technology investments, the value of the investments are more visible and an agency can improve the alignment of the business and technology environments. By introducing proposed new transitional projects or processes into the enterprise architecture, one can assess impacts and how well they meet goals and objectives. Costly impacts and unexpected dependencies may be caught earlier and possibly avoided. By linking standards and their associated information to components of the enterprise architecture, components such as applications, data and hardware can have standards and with properties associated, the agency can get early warnings as to what enterprise components will be affected when a standard changes or is no longer supported. Regional agreements are another possible driver that influence business processes and technology investments. They're not shown in this model, but each agency adds stuff that the tool helps them with or helps them solve a business problem.

Nancy Neuerburg: We're going to switch now to enterprise architecture connections. Up until this slide, the discussion has primarily been about components, which are entities or objects in the enterprise architecture. Now the focus will be on connections. The goal of the next few slides is to have you recognize and understand how defined connections or relationships between architecture components are valuable and might be used. The components being connected can be within the same architecture layer, such as the business architecture, or they can be connected across different architecture layers, such as the applications architecture and the technology architecture. Adding properties to connections makes them even more informative. So for example, imagine troubleshooting data irregularities in data that moves between systems in your agency. You're trying to find where an error might have been introduced. Having properties on the interface connections would be helpful. An interface connection with a property value of either transport or transform allows you to identify those interfaces that only transport the data between applications without changing it, versus those interfaces that also perform data transformations and something might have occurred there that was unanticipated. Parent-child connections in enterprise architecture also simplify the description of an enterprise architecture. So for example, work unit may be a subset of a division; application modules are a subset of applications. The parent-child relationships also facilitate rolling up components to a more summary level for analysis and display. So for example, subprocesses can roll up to processes, which can then roll up to functions. A transit diagram with functions on it is far less busy than one that has all the associated processes, much less subprocesses. Connections between components in different EA layers inform about relationships and help answer questions such as: What database needs to be available for the application to run? So that's a connection between an application and the application architecture and a specific database and the data architecture. Many other types of connections can be defined between components and the enterprise architecture, particularly between components in different architecture layers. How those connections are labeled is pretty much up to the agency to use terms that make sense for the staff there. There are several enterprise architecture frameworks or models that describe different connection types, and an agency can look through different ones, hunting for ones that resonate for them. So, the connection between business functions and applications might be called "are supported by". So business functions are supported by applications. Similarly, applications are hosted on servers or a sequence flow can occur between processes. EA modeling software really shows its advantages when connections are included in an enterprise architecture. In the old days of paper and Word tables and Excel spreadsheets, you had to flip between different parts of the documentation to find what you needed. With the software, those connections can be identified fairly rapidly and in a pretty pleasing format as well. So the richness of the definitions for the different types of connections and the ease in defining and displaying the relationships are two major reasons why EA modeling software today is significantly better than spreadsheets and tables in describing an agency's architecture.

Nancy Neuerburg: This slide is going to show another benefit of EA modeling software tools, which for the same set of data they facilitate viewing the enterprise architecture and its connections from different perspectives. This perspective I'm going to start with is from the business architecture perspective. So in this example, you can take the perspective of a work group, which is a component in the organization's hierarchy of the business layer. From the work group's perspective, a work group should know what processes it must work on, what applications need to be in place to support the work of the processes, and what data needs to be available and what servers must be operating without issue to support the databases and applications. This same graphic could be viewed from a processes perspective, where one must know, for the process, what work groups needs to be in place to complete the process, what applications need to be functioning properly, etcetera.

Nancy Neuerburg: Because so many enterprise architectures are started and championed from the IT department, it's interesting to look at those same connections that we've been talking about in the prior slide from the technology perspective. So it starts with a focus on the technology architecture from the perspective of someone responsible for servers. They might want to know what databases and applications reside on the servers, what applications and processes might be affected if a change is made to the server. Ideally, if they're going to make a change to the server, they might also want to know who is affected, who should be notified and consulted. So by following the chain of connections in the enterprise architecture you can determine what work groups probably or possibly are using that server at some point. When the graphic gets way too complicated, which it can, because transit is very complex and interconnected, the EA modeling software can produce a diagram that focuses on one perspective, such as in the next diagram, in the next slide.

Nancy Neuerburg: So this graphic, while busy, is still just a subset of the true responsibility of some of the business functions and processes that might be worked on a transit route facilities work group. So this is from the perspective of a transit route facilities work group. A new supervisor would go, "Oh. What are my folks responsible for? What do they work on? Who are they involved with?" So they would be, starting on the upper left-- I won't go through it all-- but they participate in the transit service development function, which has multiple processes. One is multimodal planning; another is the route facilities process; and there is the schedule information provisioning process, trying to find how big, where, and how do you get it filled for the information for a particular facility. Going down to the bottom left corner, they probably work with, hopefully, the facilities maintenance function to make sure that what they design is reasonable to maintain. In the center bottom, they work with the governmental partner relations and contracts process and the community engagement process. If they're going to put in a new facility in front of a business, they are engaged in the community engagement process. So this kind of representation is possible because the following connections were made in the enterprise architecture: parent-child connections between functions and processes, and connections between work groups and processes. You can do this kind of a detailed diagram from quite a wide variety of perspectives. One that I've seen used a fair amount is from the perspective of a system if it's under consideration for being replaced, by looking at a system and seeing all the different stakeholders, the databases, the applications, the interfaces. It helps a project manager figure out who to bring to the table and what kinds of questions to ask.

Nancy Neuerburg: So we're going to put the pieces together now. An EA can present different perspectives and as a result different perspectives on the definition of an enterprise architecture exist. For transit, the definition I'm going to read here is one of the better ones, and that is: "An enterprise architecture is a strategic information asset base which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to changing business needs. It is a representation or blueprint…" And this definition was developed in one of the federal enterprise architecture processes. I believe they have gone on and modified the definition yet again, but at this point in time it was one that worked well.

Nancy Neuerburg: We now have a short activity on the Learning Objective Number 1 materials, which were targeted to have you understand at a high level the general definition of an enterprise architecture.

Nancy Neuerburg: The question for you is: Which of the following is not a typical name of a layer in a transit enterprise architecture? And your answer choices are business, software, technology, or data. Please use your mouse to select the appropriate answer.

Nancy Neuerburg: Let's review the possible answers to the question, "Which of the following is not a typical name of a layer in a transit enterprise architecture?" Software. That is correct. Software is a part of the application layer but it is not a typical EA layer name as it can also reside in however. Business, incorrect because it is a typical name of a layer in the transit enterprise architecture. The business layer shows functions, processes and organizational information. Technology architecture is also incorrect because it is a layer that shows enterprise architecture components such as server, networks, and ITS devices. And data was the incorrect answer because the data layer typically shows databases and key data sets.

Nancy Neuerburg: We're going to start now on Learning Objective Number 2. The second learning objective of this course is to review the benefits to a transit organization of having an enterprise architecture. Key points are to recognize that an enterprise architecture can benefit most parts of transit, including ITS initiatives; understand how an enterprise architecture can support the agency's regional ITS architecture, standards, systems engineering efforts, and project architectures; and recognize the benefits from an enterprise architecture can continue to evolve as the enterprise architecture is developed.

Nancy Neuerburg: An enterprise architecture can provide a wide range of benefits to transit. We've described some of them and I may repeat some of them within the context of this section again. In general, transit managers, staff, and their partners have better visibility into the transit agency via the enterprise architecture. Through better visibility, they can gain a more comprehensive understanding of the transit enterprise; in other words, its people, processes, applications, data, technology infrastructure, and drivers. An EA can help a transit agency reduce risk by better understanding dependencies between components of the enterprise architecture. If the agency has an EA modeling tool that can run scenarios or design a future architecture, risk from changes can be further reduced by exploring those alternatives in advance of implementing them-- potentially implementing them. The well-organized knowledge in the enterprise architecture repository enables a better understanding of the impacts of potential changes and it facilitates a much quicker response to changes through better information being accessible more quickly. Most areas of transit can benefit from an enterprise architecture, and different benefits can be realized from each layer of the architecture. So for example, if we think about the business architecture, it can help project developers understand the business, identify stakeholders, find dependencies and generally expedite the information-gathering tasks needed to develop requirements. Similarly, the business architecture can help new managers and supervisors better understand their scope of responsibility. Business process improvement efforts are facilitated because the business architecture provides a starting point with a high-level identification of stakeholders and processes. It also creates reusable building blocks that describe the agency, and the business architecture can help reorganization efforts to not lose track of business processes when work groups are being restructured.

Nancy Neuerburg: Enterprise architecture also improves alignment between the goals of an organization and its business processes and technology investments. Using an EA approach and an EA modeling tool facilitates linking the goals to processes and technology investments. Once the linkages are understood and gaps are identified between current and desired states, improvements and alignment can occur. Most enterprise architecture modeling software can enable efficiencies by finding duplicative business processes and systems. EA helps minimize redundancies and inconsistencies that occur when IT staff focus on one or two systems and don't see the big picture. Without the big picture, opportunities for leveraging and reusing work are lost. The act of creating an enterprise architecture improves standardization in several ways. The development process finds inconsistencies in naming conventions and definitions used in the agency for components such as locations, data, applications, programming languages, etc. Sometimes when data is loaded the first time an agency might have-- let's see, I'll make up a number-- eight programs but it's entered multiple ways and it may look like they have 24. So it highlights really quickly where standards are needed. So better standardization usually occurs as data is entered, or when it's analyzed and discrepancies are found. Further, the modeling process and software can impose discipline and standards for describing things in the EA. Most EA software has a range of features that support the listing of standards, tracking information about the standards such as version and probable obsolescence data, and linking standards to components. All these features enable efficiencies if they're used.

Nancy Neuerburg: An enterprise architecture model can support transit ITS efforts through the stages of a project's lifecycle. It can inform whether an existing or potential project may be part of the ITS architecture. It can identify standards required or used. A transit EA can help systems engineering efforts. It can improve the quality and timeliness of systems engineering efforts throughout the stage of a project lifecycle. It also can provide context for a project or specific solution architecture. In the conceptual stage, you can research the enterprise architecture for related projects that are part of the ITS architecture. So you're thinking about starting something; what's out there that's related? As you define needs and requirements, the EA can help you find stakeholders and dependencies. When doing design of the project architecture, you can reuse elements of the EA and better fit the new project within the context of the existing architecture environment. In addition, the EA model can develop future scenarios to assess alternatives for potential design and implementation.

Nancy Neuerburg: This graphic will begin to show the relationship between ITS architectures and agency EA and some key systems engineering steps. Not all of the SE steps are included here, nor are all the possible uses of the EA with respect to systems engineering. We have a relatively small slide space available here. So showing on the left of the diagram is the National ITS Architecture, which informs both the regional ITS architectures and ITS standards. The regional ITS architecture can send forward proposed ITS projects that become drivers of the future transit enterprise architecture. ITS standards join other agency IT standards in the drivers’ portion of the architecture which are linked to components in the EA layers. If we look at a few of the key systems engineering steps, the business architecture can facilitate both the concept of operations and the systems requirements by identifying key stakeholders to interview and dependencies and providing high-level process descriptions. The EA may also contain hyperlinks to other related and more detailed information. The existing data architecture can be reviewed for project implications. The application architecture may be used to expedite the development of the high-level design by highlighting needed interfaces and providing information about affected systems, including their developers, users, and maintainers. Finally, the technology architecture and its associated standards can facilitate and/or drive both requirements and design.

Nancy Neuerburg: The benefits of an enterprise architecture can evolve. Transit organizations operate in a constant state of change. Many things can change, such as issues, goals, budgets, staffing and systems. As the awareness and understanding of a transit agency EA grows, often more questions are asked of the EA as expectations rise for additional information. Instead of being happy that standards are finally listed and linked to components, there may be a new expectation for a graphic that shows a timeline for the standard with the timing showing the implementation date, the version number, and the planned date of obsolescence. Increased use of the EA often identifies data and information shortcomings that users or managers want fixed. When the cost-benefit of adding or fixing data in the enterprise architecture is perceived to be good, the model usually evolves to an improved state and new benefits are achieved for the organization. So for example, new inventories are added and connected to an existing inventory. Other rapid or radical changes to the enterprise may trigger a need to update the EA. If the change is too big, it can render some data sets obsolete for a time. The EA may get worse briefly, and then the needed update process may trigger data and design improvements. So as a reminder, the EA provides the greatest benefits when the data being updated is data that helps the agency solve a business problem, such as maintaining business continuity. For example, one I've talked about before, the EA can help minimize business impacts from servers or software changes if connections are known.

Nancy Neuerburg: Now we have another short activity, and the question for you is: Which of the following is not a common benefit of a transit enterprise architecture? Your answer choices are: better visibility into transit's people, processes, and technology; improved standardization; solving employee problems; and understanding dependencies. Please use your mouse to select the appropriate answer.

Nancy Neuerburg: Now let's review the possible answers to the question: Which of the following is not a common benefit of a transit enterprise architecture? Solving employees' problems. It is not commonly used to resolve conflicts between individuals. Better visibility into transit is incorrect because the EA benefits transit by better showing components of transit, such as processes, applications, data, technology, and their relationships. Improved standardization is an incorrect answer because it is a common benefit of a transit EA. It improves standardization by listing standards for use and by detecting inconsistencies. Finally, understanding dependencies is incorrect because an EA documents and displays dependencies.

Nancy Neuerburg: The third learning objective of this course is to describe the general process for creating a transit enterprise architecture. The key points are to recognize importance of preliminary goals and objectives; begin to identify some needed enterprise architecture components and beneficial linkages between them; understand at a high level how different staff groups within a transit agency participate in development of an EA; understand in general how an EA can be scalable for different size agencies and resource levels; and finally, recognize some common challenges to creating and using an enterprise architecture.

Nancy Neuerburg: I'm going to first provide an overview of some key steps in developing enterprise architecture to set a background and context. After the two slides on key steps I will go into more detail about determining goals and identifying needed components and connections using some examples. Enterprise architecture as a field is less than 30 years old, so it is new enough that many individuals don't know exactly what it is. Also, until recently, EA modeling software was not very affordable, further slowing the adoption of EA by organizations, both within and outside of transit. These factors contribute to the need to educate transit staff about EA, To facilitate the gathering of needs and determining the intended goals of usage of the EA, the stakeholders first should receive some basic education on enterprise architecture and enterprise architecture software modeling tools. Basic educational materials and a small amount of training in advance will help stakeholders better articulate their needs and intended usages of the EA. Transit staff that will participate in the design of the model should have some basic modeling skills as well, a good knowledge of transit, and a general understanding of the modeling tools. Based on what is heard from stakeholders, next step in developing an EA is to develop high-level expected usage plan, goals and objectives for the enterprise architecture-- and again, goals will be discussed further on a future slide. You will need to identify the scope and depth of the enterprise architecture. The scope and depth can refer to the size of the enterprise that will be modeled initially. So for example, one version of the enterprise might be the whole agency, or another smaller version of the enterprise might be just one mode, such as fixed route transit. The depth refers to how much detail is added in an area. So some agencies may go from function to process; others may go from function to process to two or three additional layers of subprocesses if they're needed. The Open Group website, which I've mentioned earlier and provided some of the definitions, has a website that describes more dimensions for consideration when scoping an enterprise architecture. Next you need to identify components and connections. Which ones will be needed to meet analysis objectives? In addition, an EA framework must be selected that generally describes the relationships of the components in the EA. The TEAP framework that was developed for transit combined features from several more general existing architecture models, such as the Federal Enterprise Architecture, FEA, model and the TOGAF model, which is described on the Open Group website. Most likely, each transit agency will further modify the selected framework to best meet their specific needs. A development path should be identified that determines the order and dependencies in gathering data to meet goals and achieve important low-hanging fruit.

Nancy Neuerburg: Starting smaller is good, as you develop skills and experience with modeling logic and software tools. Additional key steps in the EA development process are to evaluate and select an EA software modeling tool. You need to collect information. You need to populate the enterprise architecture repository in the software tool. Develop a test plan to improve quality. Errors will become apparent, but there are trickier ones that you will have to have a test plan for to trap, and some of that will come from your knowledge of transit and some will be triggered by seeing odd errors that you go, "Ooh, are there more of those in there?" Time needs to be spent developing common analyses and visualizations of the information in the repository. You have different information views, different reports, analyses, scenarios. Some of these are harder to do than others, so having folks with some skills and training to be able to do that and to set up templates is really helpful. Let's talk a little bit more about the approach for determining goals and objectives. Determining the preliminary goals and objectives of the enterprise architecture is critical. The process is dependent on understanding the needs of the agency and how staff will likely use the enterprise architecture. Transit is a complex business with many parts. Also it has many political and business drivers that can change over time. As a result, the immediate need for quicker, better answers about the enterprise can be different in different transit agencies and can be different at different points in time. One agency may be focused on reorganizing and process improvement. For their agency, their enterprise architecture would likely start with a business architecture that is built out in more detail, and their technology architecture might have relatively little detail. Another transit agency may have an enterprise architecture that's sponsored by the IT department, resulting in a focus on different information, such as application, databases, and their connections relative to the business processes. Today, transit agencies are becoming more interested in a comprehensive view of their asset management procedures, data, applications, so some future transit EAs may have that focus as well.

Nancy Neuerburg: When you identify needed components and linkages, you should build off the enterprise architecture goals and objectives. Select the top priority components and connections to develop that will support meeting the goals and objectives. Create and implement a data-gathering and data definition process to support the needed analyses. This includes defining the types of properties that need to be stored to describe a component or connection. You need to then modify or start modifying early on the enterprise architecture framework that you will use to assist in developing your enterprise architecture model and framework. Terms may need to be adapted to your agency and components may be added or excluded as you are modifying an enterprise architecture framework. Like many projects, you need to know where you want to go with the enterprise architecture to be able to get there. If an objective is to reduce to unscheduled application and work group interruptions due to server changes and upgrades, it dictates in part what data you must gather. You need to know what servers you have, what applications are on them, who uses the applications.

Nancy Neuerburg: This next graph allows us to walk through parts of a small example. When building the EA model, a simple framework graphic like this one can help you get started in assessing what components and connections to add. Enterprise architecture frameworks are plans for organizing data about the enterprise and they facilitate getting meaningful answers. The goals of the EA can influence the framework and a framework can help focus the design and data collection for the enterprise architecture. As a terminology reminder, the components in this future are work group, process, database, application, server, and network. Also represented are connections. Even in a simple model, various connection types might be included. For example, the connection type that describes the relationship between an application and a server might be labeled as "resides on" to indicate the application resides on the server it is connected with. The other connection to an application that is shown in this figure may be called a "supports" connection, indicating that the application supports the process it is connected to. Now let's test a simple framework. We'll use the earlier fare collection example that showed an extended business architecture with external stakeholders. Process A and B in this framework fit nicely with the fare collection process and the fare administration process from the prior example. The regional clearinghouse, which is an important external stakeholder, causes the framework to fail because it only has work groups, and work groups are defined as part of the transit organization. So now the EA designer has a choice. They must decide if the framework gets extended to include a new external stakeholder component, or are they to be left out of the model as a component. Usually the external stakeholders are added as a component and the organization part of the business architecture is extended. That allows an external stakeholder, like the clearinghouse, which might be over roughly where the Group 3 is, to be connected to the fare administration process, which is supported by-- let's say Application A is the fare system and the Application B might be the financial system. So, so far, so good. At some point, linking a work group such as Marketing and Sales, to a broad process like fare administration may not be sufficiently helpful, so a subprocess component might be added to the framework. To keep the EA model flexible and maintainable, recommended limits should be developed as an attempt to set limits on how deep the model can be described. In other words, how many functions, process, subprocess, sub-subprocess-- how far down do you really want to allow this to go? At some point it makes sense to keep it simple. It makes it easier to maintain, going maybe three, possibly four levels. Then if it gets even more detailed, a hyperlink can be made to go to an externally developed diagram.

Nancy Neuerburg: I'll talk briefly now about key staff and roles needed for developing a transit enterprise architecture. Like many technology-related projects, an EA development project needs a strong management sponsor. Because the technology is not widespread yet in transit, it does not have enough advocates, so a knowledgeable sponsor is critical until there's a broader user base of support for the EA in the agency. The assistance of an enterprise architect is critical in the early planning stages as transit staff learn more about modeling and EA tools. An enterprise architect has training in modeling and EA development. The enterprise architect helps with the design of the EA, reinforces some of the basic modeling rules, and can point out tradeoffs to transit staff from different modeling approaches. They can also help transit staff acquire skill with a modeling tool. What they tend not to know as well is the complexity of transit, so they may not know to ask follow-up questions when gathering data. Therefore, someone with a broad transit background should be key in the data-gathering effort. Preferably, the project manager has a broad transit background and is familiar with the agency's business architecture and application architecture as a minimum. Staff groups provide much of the information going into the enterprise architecture repository. Supervisors and budget analysts tend to have the broadest view of a business area and can point to staff with more detailed knowledge of a function. Sometimes it helps to start with them. Key IT and ITS staff tend to be the sources for the data and technology layers, which information about the application architecture tends to come from both the business and IT. The modeling software vendor often provides technical support as the EA model is developed. EA initiatives have failed because only the vendors or consultants worked on the model. When they leave and there's no embedded transit knowledge, it's a real problem, and much of the investment is likely wasted. Transit staff must, must take a significant role in the design and implementation of the EA. Ideally, using the permissions in the EA software, maintenance of the data components can be distributed through the agency to staff that have expertise with those data sets, and they will be motivated to make sure those data sets answer questions that they need answered.

Nancy Neuerburg: This slide introduces several ways a transit agency can begin building an EA that is scalable and delivers benefits early. The size of the enterprise selected can affect the complexity and size of the enterprise architecture repository, not surprisingly. Large transit agencies can start with one or two transportation modes before expanding the EA to additional modes. Other aspects of an EA can also affect scalability. Start small and scale up. There is a learning curve, both for the EA modeling software and for your EA thinking and modeling skills. It's better to start out promising less and maybe over-delivering. The enterprise is what you define it to be. If you start with a smaller enterprise, you can get answers about the enterprise sooner. In other words, you might find duplicative bus stop inventories being maintained separately. As you expand the size of the enterprise described in your EA model, you might find a bigger enterprise; in other words, bus, rail, and paratransit, may get you additional insights about organizational overlaps and duplication. In other words, you might find multiple software licenses or products to do vehicle-related asset management. In reality, so much of transit is connected that significant additional pieces of the architecture may get built out when you are gathering data for a narrower scope. Additional information is often provided in interviews that you can use and put in the model if you have the time and resources to alter the model to accept the additional relevant information. A common need is that you want to link work groups to processes. However, to be clear about the components and their connections, you may have to include three layers of subprocesses. So this is the case where complexity creates a need for more detail. In some cases, the extra detail is needed, but it's not necessary to go to the same depth for all the processes. In general, guidance should be to not gather and store information in the EA model repository unless you need it and are going to use it. Another thing that affects the size and scalability of the enterprise architecture is the number of charts and graphics that are customized. There are some canned reports in many of these tools, but mostly they need to be modified for the agency. So it's helpful to have some templates set up to support ad hoc reporting.

Nancy Neuerburg: Now let's talk about some common challenges for an EA. Some of the challenges and barriers to creating and using an enterprise architecture have diminished over time, such as having inadequate tools. Years ago, because older EA software from ten years ago was expensive, complex, and difficult to use without a really long learning curve, many agencies instead created EAs that were documented in Word or Excel with lots of detail matrices to link layers. The EA for a midsize transit agency might be documenting in a six-inch-thick binder and, no surprise, it's hard to maintain so it gets out of date fairly quickly. Now, relatively easy, more powerful and flexible EA software tools are available. Costs for the EA tools vary widely, with some affordable options now available in the marketplace. Even though EA tools are more easy to use and more affordable, few transit agencies have acquired modeling software. Learning curves are always a challenge with new concepts, such as EA modeling or the new software. However, they can be significantly less so now that better training in the marketplace and more user-friendly tools exist. Despite the challenges listed here to inform and alert agencies, transit now has an opportunity to use EA modeling tools to gain a greater benefit at significantly lower cost with easier-to-use software.

Nancy Neuerburg: An additional challenge to a successful EA is model complexity. Creating a model that's too complex to easily update and modify can create a long-term challenge. Too complex of a model requires more skilled staff, good memories, good documentation, and regular use of the model to keep the memories fresh. Further, an organization needs a good change management process for communicating changes to the model to others and to be able to recover from issues that may be introduced. Staffing issues have posed a challenge for some transit agency enterprise architecture efforts. For example, lack of a dedicated enterprise architect to guide or make design and analysis changes and to assist new users can be a problem. One of the biggest challenges is having too few people knowing how to use the EA modeling software. One form of that challenge is failing to distribute the task of updating inventories. The individuals that rely on the data and need high-quality data will likely take a role in their data sets' data maintenance and will want to be able to query the information. Issues from staff turnover and changing management priorities can be mitigated somewhat by an education program about the EA at multiple levels of the organization so that new supporters and sponsors can be found. Distributed data maintenance and reporting also mitigates impact from staff turnover. Within the Student Supplement there are some very short-- not quite case studies, but descriptions of some transit agencies that have attempted to implement enterprise architecture software and models.

Nancy Neuerburg: Now we have a short activity on Learning Objective 3 materials, which were targeted to have you understand at a high level the general process for creating a transit enterprise architecture.

Nancy Neuerburg: The question for you is: Which of these statements about an EA is not correct? Your answer choices are: many groups help build an EA; B, an EA needs a maintenance plan; C, an EA must solve a business need; and D, only a fully developed EA is useful. Please use your mouse to select the appropriate answer.

Nancy Neuerburg: Let's review possible answers to the question, and I'll repeat it. Which of these statements about an EA is not correct? "Only a fully developed EA is useful" is the correct answer, because the statement is false. An EA can be scalable and useful from the beginning. Many groups help build an EA was an incorrect answer to the question because staff from many groups throughout the agency are needed to provide the knowledge stored in an EA repository. An EA needs a maintenance plan, also incorrect. An EA needs ongoing maintenance just as inventories do. Responsibilities and update approaches must be defined. An EA must solve a business need-- incorrect. An EA must absolutely solve transit business needs to be useful and inspire a desire to maintain it.

Nancy Neuerburg: The fourth learning objective is to be able to articulate how use of EA principles can benefit a transit agency. A couple key points to understand are that even if an agency does not fully implement an EA repository and model, the agency can obtain benefits from incorporating enterprise-wide principles into its business processes. In particular, the integration and standardization of IT and ITS initiatives within transit can be improved by the application of EA principles.

Nancy Neuerburg: What are EA principles? EA principles are general rules or guidelines that inform how an organization sets about fulfilling its mission, and this is another definition derived from the Open Group. It is often designed-- that is, the principle--to maximize the value of technology investments. Even without a modern EA modeling tool, there is great value in taking the enterprise-wide perspective to standards, standardization of naming conventions, consistency of definitions, and improving existing inventories. A large part of the value of creating an EA can be in the learning that occurs in the meetings, during the investigative processes, in the discussion on how to resolve issues, and in the planning to define the future roadmap. The participants in the EA development process learn a lot about the agency as a whole and how it works together. Principles for an EA and an agency can be developed for the EA as a whole or targeted to specific layers of the enterprise architecture. They're designed-- again, I repeat, to maximize the benefits to the enterprise as a whole. The Open Group suggests that each EA principle is described clearly by a name, statement, rationale, and implications.

Nancy Neuerburg: This next slide shows examples of four general EA principles that can benefit many or all parts of an organization, and they are: an enterprise wide perspective, to foster integration, to leverage resources, and to be business results focused. Do it because it will make a difference, not just because it's easy to put together an inventory. So a bus stop inventory is one example where an enterprise-wide perspective is helpful, and where fostering integration is helpful because the various elements can be pulled into one central place and have the aggregate benefits of all the different stakeholders ensuring that the data quality is good. A trip planner in a large metropolitan area might benefit from resources being leveraged and the riders and customers in the area definitely benefit from the foster integration principle if the trip planner is useful and serves across multiple transit agencies and territories. There are many examples of more technology-focused enterprise architecture principles. So these, instead of enterprise-wide, are IT and ITS-focused. For example, the first one is to ensure alignment of IT and ITS strategies with business vision and strategies to maximize the value of technology investments. The second one is to strive for interoperability, both for applications and hardware. And the third one is that implementing the principles require-based change creates results that better meet user needs.

Nancy Neuerburg: This slide shows additional examples of technology-focused EA principles. However, these are specific to a specific layer of the enterprise architecture, and that is the data architecture. So these principles, as samples of many pertaining to data, are that data is an asset, data is shared, data is accessible, and a common vocabulary and data definition should exist in the enterprise. And again, better inventories of key transit components result in better information. They result in inventories that are more logically consistent and complete, and that have more connections or linkages to other inventories.

Nancy Neuerburg: Here is an example of an enterprise architecture principle being described. This is summarized from an example shown by the Open Group, and in the Student Supplement it's included more fully. So, first off, the principle should have a simple, understandable name. It provides a statement that elaborates on the name. So, for interoperability, the statement is that software and hardware should conform to defined standards that promote interoperability for data applications and technology. The rationale is that standards help ensure consistency, help ensure support from multiple vendors, and facilitate supply chain integration. The implications to the agency of having this EA principle in effect is that interoperability standards will be followed unless there is a compelling business reason not to do so. An additional implication is that a process for setting standards, periodically reviewing them, and granting exceptions must be established. Again, a more complete example is included in the Student Supplement.

Nancy Neuerburg: For EA principles to be used and to improve the organization, they must be communicated widely. Key people that should be aware of them and make decisions influenced by them are managers, IT staff, and project managers. EA principles should influence the assessment of the current architecture, for example, decisions and approaches for moving forward, and potentially development of evaluation criteria for new products. One of the key principles is to foster an enterprise-wide perspective throughout the agency. It helps eliminate existing silos and helps prevent new ones from being created. Having an enterprise-wide perspective also helps identify connections and improves standardization on many levels.

Nancy Neuerburg: EA principles improve integration and standardization of ITS Initiatives as well. Five examples of EA principles that support better integration and standardization of ITS initiatives are the following, and some of these are from the general ones that we described earlier. First, foster partnerships. Two, data is shared. Three, common vocabulary and data definitions. Four, interoperability. Five, leveraging the ITS environment. So for example, if these EA principles were applied when an application is being developed or enhanced in transit, much greater benefits could be achieved in many cases. I've talked in the past about a bus stop inventory. It avoids situations with duplicative data entry and maintenance. It helps remove inconsistent information and names across applications. The applications that use the bus stop inventory, as you know, are facilities planning, facilities maintenance, trip planning, safety applications, and many others. So with everyone thinking enterprise-wide, thinking about data sharing and common vocabulary and data definitions, the organization, transit as a whole, definitely does better.

Nancy Neuerburg: We now have a short activity on the Learning Objective Number 4 materials, which covered how the use of EA principles can benefit a transit agency.

Nancy Neuerburg: The question to you is: Which of the following would be the poorest EA principle for supporting efficiencies in transit? Which would be the poorest? A, be focused on creating business results. B, buy the most advanced and complex software. C, control technical diversity. And D, have an enterprise-wide perspective. So you're looking for the poorest of those choices.

Nancy Neuerburg: Let's review the possible answers to the question of which of the following would be the poorest EA principle for supporting efficiencies in transit. The correct answer is to buy the most advanced, complex software. That is the poorest of the choices as an EA principle because the most advanced software application may create inefficiencies because it's difficult to use and maintain. Be focused on creating business results is incorrect. It is a focus that supports efficiencies. Control technical diversity is incorrect because controlling technical diversity, such as through the use of standards, creates efficiencies. Having an enterprise-wide perspective, my favorite, is incorrect because an enterprise-wide perspective promotes efficiencies, it helps find redundancies and other issues.

Nancy Neuerburg: What have we learned about EA? In summary, in this introduction to the transit enterprise architecture and its benefits, you have learned the following about EA, including how to define an enterprise architecture at a high level, review the benefits to a transit organization of having an EA, describe the general process for creating a transit enterprise architecture, and articulate how the use of EA principles can benefit a transit agency. Looking at enterprise architecture from ITS perspective, EA allows for more integration of ITS technologies and applications within an existing and/or planned transit agency network and infrastructure.

Nancy Neuerburg: Thank you so much for completing this training module. The Professional Capacity Building Training Program is interested in your feedback to help improve the program. Please use the feedback link below to provide us with your thoughts and comments about the value of the training. Thank you again.

#### End of 2016_10_03_12.39_Module_16_Final_Recording.mp4 ####