Guidance for Development and Management of Sustainable Enterprise Information Portals (2018)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

92 PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals A P P E N D I X

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 93 Development and Management of Sustainable Enterprise Information Portals Guidance for Transportation Agencies The purpose of this briefing is to provide content for communicating enterprise information portal concepts & considerations with executives and stakeholders to support a conversation that shifts DOT practices to a sustainable, customer-centric service. The organization of this briefing mirrors the guidance document loosely, offering definitions and examples. Purpose of Briefing

94 Guidance for Development and Management of Sustainable Enterprise Information Portals • What is an Enterprise Information Portal (EIP)? • Achieving Sustainable EIPs using the Microservice Architecture Pattern • Designing for Sustainable EIPs • Technology Recommendations for EIPs • Microservice Creation & Organization – Asset Management Example • Migration Strategy from Monolith to Microservice Architecture • Overcoming Non-Technical EIP Implementation Challenges Briefing Organization Enterprise Information Portals for Departments of Transportation

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 95 • EIPs integrate management information systems, decision support systems, enterprise information systems, and other technologies. • EIPs are tailored or personalized to the intended user or groups of users. • EIPs provide access to a broad range of resources and services through a variety of interfaces. What is an Enterprise Information Portal (EIP)? An EIP, also known as a business portal, is a “web site” that serves as a single gateway to a company's information and knowledge base for employees, customers, business partners, and the general public. Common Services Offered by DOT EIPs, part 1 of 2 DOT EIP noitpircseDsecivreS 1. Asset Management, Engineering and Maintenance Services Services pertaining to the development, deployment, maintenance, and retirement of DOT assets. 2. GIS and Mapping Services Services such as GIS file downloads, GIS web services, mapping of traffic conditions, construction, assets, and chain stations. 3. Operations & Performance Management Services Services pertaining to the operation of DOT systems and measures of their performance/efficiency using indicators such as traffic speed, volume, occupancy. 4. Documents and Library Services Services pertaining to documentation publishing, record keeping, video and image archival, and publication and journal subscriptions. 5. Bid and Contract Services Services pertaining to contracting process information, bid, acquisition, and project tracking.

96 Guidance for Development and Management of Sustainable Enterprise Information Portals Common Services Offered by DOT EIPs, part 2 of 2 DOT EIP noitpircseDsecivreS 6. IT Services Services and topics relevant to portal hardware, software, on premise infrastructure, cloud services, and networking. 7. Environmental Services Services pertaining to environment monitoring and alerts such as extreme weather, flood, earthquake, and air quality. 8. Public Outreach Services Services pertaining to public information sharing, such as 511, projects, performance and weather, and lane closure and construction. 9. Photo and Video Services Services pertaining to the collection, storage, search, and archiving of DOT photo and video of infrastructure from drone, satellite, or ground, as well as operation and asset pictures or video, such as inspection images or incident videos. 10. Financial Services Services pertaining to payroll, budgeting, project funding, and accounting. • DOTs typically have multiple portal platforms with multiple services, some of which are integrated, while others are stand-alone • Internal DOT portals are typically more integrated than externally facing portals • The technology and architecture of portals varies by organization size, budget, and expertise as well as state requirements pertaining to the management of data How are Departments of Transportation Implementing EIPs?

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 97 What is Sustainability in the Context of EIPs? It’s not just about continuity of funding, making EIPs sustainable requires focus on: • Technologies, • Policies, • Procedures, and • Governance. The cornerstones for sustainability are replaceability and resiliency of services and systems within the EIP Sustainability is the ability of the enterprise to meet its present needs without compromising its ability to meet future needs  Moving away from a monolithic and heavily integrated portal application to a modular, service-oriented architecture  Less in-house hardware and data storage, and more distributed hardware and data storage leveraging cloud services  More distributed software portal applications  Less integrated management of individual portal application, more autonomy for applications Trends in Moving toward Sustainable EIPs A service-oriented architecture (SOA) is not just an architecture of services from a technology perspective; it includes the policies, practices, and frameworks by which we ensure the right services are provided and consumed. The basic principles of SOA include independence of vendors, products, and technologies.

98 Guidance for Development and Management of Sustainable Enterprise Information Portals Why Cloud • Shifts the risk of IT infrastructure obsolescence to the cloud provider • Enables a scalable, flexible, and on demand set of IT capabilities • Reduces IT infrastructure operation and maintenance time • Lower cost profile Why a Mix of On Premise & Cloud IT Infrastructure? Why On Premise • To meet government regulations for storing sensitive data • Need for unique/advanced security beyond cloud offerings • Visibility of data “residency” • Bandwidth constraining accessibility at the last mile • More direct control over latency What is a Distributed Software Architecture? A distributed system is one in which the computing power and software is distributed across several servers, connected through a network, communicating and coordinating their actions by passing messages to each other.

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 99 Achieving Sustainable EIPs Brief Introduction to the Microservice Architecture Pattern An SOA variation, microservice architecture is an approach to developing a single application as a suite of small services. Each service: • Runs its own processes • Can be written in any programming language and is platform agnostic • Is independently deployable and replaceable • May use different storage technologies • Requires a minimum of centralized management Large companies, such as Amazon, eBay, and Netflix, have already adopted microservice architecture as their main architecture. What is a Microservices Architecture? Modular Space System Analogy Rather than using a large, complex, single satellite, agencies are migrating to a suite of connected, independent, low-cost, and replaceable small satellites, each with its own function (e.g., communication, imagery, sensors). This decomposition and migration to autonomous modules offers these agencies ease of functionality, ease of replaceability, and ease of modernization with newer modules.

100 Guidance for Development and Management of Sustainable Enterprise Information Portals Visual Interpretation of Architecture Patterns Traditional Monolithic Architecture Pattern Microservice Architecture Pattern “Monoliths and microservices are not a simple binary choice. Both are fuzzy definitions that mean many systems would lie in a blurred boundary area among the two” -Martin Fowler Martinfowler.com Microservice Architecture Advantages • Greater efficiencies as they are typically paired with auto-scalers and load balancers • Easily scalable in three ways: – by decomposition into simple functions (microservices) – by cloning microservices on demand – by partitioning data across a cluster • Services can be cloned or decommissioned based on user requests in real-time Auto-scaling definition A cloud computing service feature that automatically adds or removes compute resources depending upon actual usage Auto-scaling - A cloud computing service feature that automatically adds or removes computing resources based on actual demand Load balancing -The process of distributing workload evenly across computing resources in a cloud computing environment

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 101 Microservice Implementation Example of a DOT EIP on Cloud Infrastructure IT teams shift from actively managing hardware and software to managing service layers in the microservice environment Shifting to microservices architecture means • Reducing code complexity while increasing operational complexity • Distributing data across multiple processes while ensuring data consistency across processes • Simplifying individual services while raising the complexity of coordinating many services Tradeoffs in Adopting a Microservice Architecture Microservice Premium Microservices impose a cost on productivity that can only be made up for in more complex systems.

102 Guidance for Development and Management of Sustainable Enterprise Information Portals When Adopting a Microservice Architecture • Design for failure – applications must be designed and developed to tolerate the failures of other services or applications. • Single lifecycle ownership of the product – “You build it, you run it,” is the motto rather than the traditional practice of a software development team handing off a service to an IT operations team. • Exercise choice in platforms, language, & libraries that best suits the microservice functionality and team expertise rather than a single language or platform for the enterprise. Change in EIP Practices, part 1 of 3 Services Development - You build it AND you run it. Development is Platform and Language Agnostic When Adopting a Microservice Architecture • Decentralized business and messaging rules – complex centralized message handling such as Enterprise Service Bus must give way to simple communications protocols. This is referred to as “smart endpoints, dumb pipes.” • Decentralized governance – minimize top down standards or technology sets and allow in-house open source model for sharing useful, tested code • Decentralized data management to service-level data management, often called polyglot persistence. Change in EIP Practices, part 2 of 3 Microservices Distributed Database Monolithic Database

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 103 • Organize teams around business capabilities not technology layer – cross functional teams by business capability are requisite – traditional technology layer based teams (e.g., a database applications team or a user interface team) means extensive cross-team collaboration and costly delays Change in EIP Practices, part 3 of 3 • Move beyond Continuous Integration to Continuous Delivery – Maintain tight integration requirements within the microservice while easing external integration requirements – Continuous Delivery means development teams build software so that the software can be released to production at any time and by anyone on the team When Adopting a Microservice Architecture Example of a Basic Automated Build Pipeline that Supports Continuous Integration Software changes should be monitored to identify and refine how an application should be decomposed into services • Parts of the system that rarely change should be in a different service, or module, than those that often change • If two services need to be changed together repeatedly, they should be merged into a single module Decomposition of Services for Fast, Frequent, and Well Controlled Continuous Delivery The decomposition of applications into services needs to be based on the notion that services can be independently replaced and upgraded without affecting the other application services with which they interact

104 Guidance for Development and Management of Sustainable Enterprise Information Portals Designing for Sustainable EIPs Requirements Operating Environment Technology Recommendations • Functional requirements – Define the functions, or business needs, of a system or components as seen by a system user. • Performance requirements – Specifies speed or operational effectiveness of the capability that must be delivered. • Design requirements – Detail the plans for the software solution and specify architecture design, methodologies, models, or frameworks by which software is to be developed. • External interface requirements – Specify the hardware, software, communications, user, or database elements to ensure proper communications with external components. • Resource requirements – These include the hardware, software, expertise, and organizational components. Requirements in Designing Sustainable EIPs A requirement is a capability or function that must be delivered by a system or system component

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 105 Examples of High-Level DOT EIP functional requirements include *: • Shall contain a data ingestion service • Shall contain a data visualization service • Shall contain a search service • Shall contain a librarian user interface • Shall contain a vendor procurement user interface • Shall contain a DOT map user interface * actual requirement will have greater context and feature specificity. EIP Functional Requirement Examples Functional requirements specify what a system or service must do, but not how it will be done Examples of High-Level DOT EIP performance requirements include *: • Services shall be able to be started rapidly • Services shall be able to be stopped rapidly • Services shall be able to be duplicated rapidly • Components shall be able to be decommissioned rapidly • Components shall be able to be deployed rapidly * actual requirement will have numerical and context specificity. EIP Performance Requirement Examples Performance Requirements define how well the system performs certain functions under varied conditions using factors such as speed of response, throughput, execution time, and storage capacity

106 Guidance for Development and Management of Sustainable Enterprise Information Portals Examples of High-Level DOT EIP design requirements include *: • Shall use a distributed tracking and logging service • Shall use a centralized logging • Services shall adjust to demand spikes automatically • Shall follow a microservice architecture pattern • Shall use API standards to design and operate its API gateway * actual requirement will have greater context and feature specificity. EIP Design Requirement Examples Design requirements direct the design (internals of the system) by inclusion (build it this way) or exclusion (don't build it this way). Examples of High-Level DOT EIP external interface requirements include * : • Shall be able to connect to live sensor feed services • Shall be able to connect to live video feed services • Components shall rely mostly on HTTP and REST for communication with external services * actual requirement will have greater specificity EIP External Interface Requirement Examples External interface requirements state the required characteristics at a point or region of connection of the system to the outside world (e.g., location, geometry, inputs and outputs by name and specification, allocation of signals to pins, etc.)

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 107 Examples* of High-Level DOT EIP resource requirements include: • Shall be implemented on a commodity cluster infrastructure (cloud like) • Shall be developed using personnel familiar with cloud technology • Shall leverage cross-functional teams over the complete product cycle * actual requirement will have greater context specificity. EIP Resource Requirement Examples Resource requirements limit the usage or consumption by the system of an externally provided resource (e.g., equipment, personnel, facilities, etc.) • Mixed infrastructure (cloud and on premise) allows increased scalability and reliability of the EIP applications while allowing sensitive data to be kept in house. • Application deployment and server configuration can be cloud based or use open-source configuration management service with a containerized architecture. • Implementation of the EIP is recommended using o Open Source continuous integration (CI) tools o Hosted CI service (software as a service), or o Proprietary continuous integration (CI) tools Operating Environment Recommendations for Designing for a Sustainable EIP

108 Guidance for Development and Management of Sustainable Enterprise Information Portals Technology Recommendations for EIPs Technology Recommendations for Services The table lists recommended approaches for the components needed to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners EIP Component Recommended Approach API Gateway Adopt a cloud API framework. Searching Adopt a cloud enterprise search platform. GIS Data Processing and Rendering Adopt an Open Source scale out GIS server framework in combination with the use of cloud storage. Data Stream Processing Adopt a cloud stream processing framework. Messaging Adopt a cloud messaging framework. Content Delivery Adopt either a cloud content delivery network solution or a commercial distributed content delivery solution.

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 109 Technology Recommendations for User Interfaces The table lists recommended approaches for user interfaces to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners EIP Component Recommended Approach Web Applications Adopt a cloud based web framework with an advanced client-side web development framework to support web design capabilities. Similarly, adopt a cloud monitoring service for web monitoring. Mobile Applications For design and monitoring capabilities, adopt a cloud mobile application deployment service. Desktop Applications No desktop application should be developed as part of a sustainable DOT EIP. Rather, use a Content Management Service based web application to provide desktop application like capabilities. EIP Component Recommended Approach Content Archiving Adopt a mixed storage capability using cloud and on premise storage. Content Caching Either adopt a cloud or commercial caching and load balancing solution. Content Tagging Use either a commercial metadata repository, a custom user generated metadata repository, or a semantic web solution. Technology Recommendations for Storage The table lists recommended approaches for storage to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners

110 Guidance for Development and Management of Sustainable Enterprise Information Portals EIP Component Recommended Approach GIS Database Services Adopt a cloud or on premise NoSQL geo capable database. Document Database Services Adopt an Open Source distributed document analysis engine. Image, Video, and Binary Files Database Services Adopt a basic cloud storage solution. Financial Data Database Services Adopt a commercial cloud enterprise solution. Sensor Data Database Services Adopt a cloud streaming framework based solution. GIS Database Services Adopt a cloud or on premise NoSQL geo capable database. Technology Recommendations for Database The table lists recommended database approaches to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners Technology Recommendations for Management Tools The table lists recommended management tool approaches to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners EIP Component Recommended Approach Resources and Application Monitoring Adopt a cloud monitoring solution. Resources Provisioning and Scaling Adopt either a cloud based serverless architecture or a cloud or on premise container based solution. Content Auditing Adopt cloud based commercial or Open Source content auditing and inventory software.

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 111 Technology Recommendations for Security and Identity The table lists recommended security & identity approaches to develop sustainable DOT EIPs based on a microservice architecture. *Based on a survey of industry practitioners EIP Component Recommended Approach Identity and Access Management Adopt a cloud AIM solution (e.g., software as a service). Security Audit There is no single approach. Approaches are tool or human based. Propose Open Source or commercial security evaluation and monitoring tools for network and software layer, internal security audits and assessments, and external party assessments and penetration testing should be used together to provide security audits to sustainable DOT EIP. Microservice Creation and Organization Asset Management Implementation Example

112 Guidance for Development and Management of Sustainable Enterprise Information Portals • UML is a way to visualize user interactions, processes, and system structure for software engineering using a collection of diagrams • Systems modeling language (SysML) is tailored from UML for systems. • Five key diagram types are presented for the asset management DOT EIP service: Use Case Activity Block Definition Sequence Component and Data Flow Unified Modeling Language (UML) Diagrams Types of Diagrams*: • Class (Block Definition) • Component and Data Flow • Deployment • Object • Package • Profile • Composite Structure (Internal Block) • Use Case • Activity • State Machine • Sequence • Communication • Interaction Overview • Timing • (Parametric) *Those in parentheses are modified from UML to SysML or are unique to SysML.Note: diagrams have been modified from strict UML/SysML to accommodate the microservices architecture specificities The Use Case diagrams give a graphic overview of • the actors involved in a system • different functions needed by the actors • how these different functions interact The Use Case diagram for asset management depicts • 5 actors – public entity, state employee, DOT operations personnel, DOT maintenance personnel, and service administrator • 23 actions are enumerated ranging from “add new asset” to “set up alert.” Use Case Diagram for Asset Management Service

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 113 Block Definition Diagram (BDD) for Asset Mgmt. Service • The BDD communicates structural information about the system • Blocks can represent anything, components, services, etc. • The blocks for asset management include interface components, business services, and data services • Note the stacked blocks indicate the ability to scale and duplicate Component & Data Flow (CDF) Diagram for Asset Management • CDF diagrams define the data going through a system and any processing required • Microservices architecture greatly increases the amount of data flowing within an application and the complexity of the data exchanged between components, which makes data flow diagramming challenging • Showing every possible component or data exchange would render the diagram unreadable, therefore only the main data exchanges between the service components involved in the high-level use cases are presented.

114 Guidance for Development and Management of Sustainable Enterprise Information Portals Asset Management Services Activity Diagram • Activity diagrams are designed to represent workflows of stepwise activities and actions that support choice, iteration, and concurrency. • They are intended to model both computational and organizational processes and show the overall flow of control. • This diagram representation focuses on the high-level workflow that would need to be followed to perform the tasks occurring in a session. • The activity diagram design is not intended to be exhaustive. Asset Management Services Sequence Diagram • Sequence diagrams show how objects operate with one another and in what order during a specific scenario. • An important characteristic of a sequence diagram is that time passes from top to bottom • The illustrated scenario is specifically for “DOT maintenance employee archives older asset data”

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 115 Focus on Migration Strategies From a Monolithic to a Microservices Architecture • The process of transforming a monolithic EIP into a series of microservices is a modernization effort for both the application and its governance. • This migration is a perfect fit for incremental refactoring. It should not be approached as a complete application rewrite, often called “big bang.” • Incremental refactoring enables the development team to build experience with microservices • Incremental refactoring allows teams to build experience with the service extraction process Migration Strategy: Use Incremental Refactoring “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure." Martin Fowler

116 Guidance for Development and Management of Sustainable Enterprise Information Portals • Monolithic applications often consist of hundreds of modules • Determine which modules to extract first. Choose modules that are – Easy to extract – change frequently – have significantly different resource requirements compared to other modules – Do not share resource requirements – implement computationally expensive algorithms. Migration – Choose a Few Services to Extract from the Monolithic Application When migrating from monolithic to microservices, using incremental refactoring is akin to safely servicing your car when driving 70mph on the highway, and stopping the car is not an option. • Step 1 – define a coarse-grained interface between the module and the monolith – Consider creating a bidirectional API – Pay close attention to the complexities of business logic refactoring. Significant code changes may be needed to break dependencies • Step 2 – Turn the module into a free-standing service – Write code for the monolith and service to communicate through an API mechanism – Combine module with a microservice framework that handles cross-cutting concerns such as service discovery Migration – How to Extract a Module Over time, as modules continue to be extracted into services, the amount of functionality implemented by the monolithic application shrinks until either it disappears entirely or it becomes just another microservice

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 117 Illustration of Monolithic Module Refactoring Microservice Success Strategies to overcome the non- technical hurdles

118 Guidance for Development and Management of Sustainable Enterprise Information Portals • DOT Agencies vary considerably in their program area priorities, organizational structure, and culture with respect to IT and innovation. • The following sections address strategies to overcome the non-technical hurdles including • Stakeholder buy-in • Changing governance • Developing the workforce • Simplifying procurement • Addressing legal challenges Migration to Microservices is Transformational Making DOT EIPs sustainable will require transformations in equipment, facilities, staff, processes, procedures, organization, and culture. • Cultivate a passionate executive- level sponsor, the champion for this change • Elevate IT presence to the executive level • Plan for continuing outreach cultivating champions within key business units Strategy: Focus on Stakeholder Buy-in A fundamental element to adopting new EIP practices is obtaining buy-in from various levels of the DOT organization. • Formulate the Business Case that tells a compelling story, conveys value and addresses risks, scope, cost, schedule, timeline, and benefits. • Develop concise talking points for each stakeholder group that highlights value that best resonates with their needs

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 119 There is frustration when governing principles are not consistently implemented and enforced throughout the organization • With sustainable EIPs, governance focus shifts away from managing hardware and software resources to managing user access to data and protecting data from unauthorized access. • The key is to establish and practice consistent but flexible governance principles. Strategy: Establish Consistent but Flexible Governance Principles Strategy: Continually Develop the Workforce People are the backbone of any industry • Adopt a proactive approach to recruit, develop, and retain staff. • Recognize the importance of recurring IT training to ensure expertise with emerging solutions and practices • Understand the effects of outsourcing. While outsourcing has perceived cost savings, the nimbleness of experienced staff who have both IT and program area knowledge will be lost. The quality of developers and transportation experts and their effective collaboration and communication is more important to the success of an EIP than the choice of whether to use monolithic, microservice, or blended architecture.

120 Guidance for Development and Management of Sustainable Enterprise Information Portals • Establish a common understanding of IT procurement needs • Identify procurement and purchasing issues that may require new ways of doing business Strategy: Focus on Stakeholder Buy-in Establish ongoing dialogue and collaboration among IT, HR, Legal, and Financial stakeholders in evolving procurement processes prior to any specific procurement. • Some DOT agencies have a separate procurement group for IT/cloud services procurement or a state-level IT cloud procurement entity. • Others will have to champion changes to procurement law to address this need for IT flexibility. • Legal considerations are likely to include data sharing, data storage/location, intellectual property, and backup format requirements • DOTs must begin to recognize that data sharing is becoming a key part of their business Strategy: Recognize Complex Legal Concerns Early As each state has their own data retention, public record, and intellectual property laws; there is no one blanket approach to mitigating legal issues. • Collaborate at the state level to address these concerns • The addition of “Rider Clauses” in contracts has often been used to help state organizations allow other states to access and use their data

PowerPoint Presentation on Development and Management of Sustainable Enterprise Information Portals 121 • Continually educate DOT staff on emerging IT capabilities. • Identify & routinely connect with stakeholders and champions. • Always lead with the business need for IT change. • Recognize and respond to institutional factors that need to be overcome. • Design a persuasive message and tailor it for the stakeholder • Define and implement changes to IT practices. Top 10 Strategies for Implementing Successful EIPs • Establish, maintain, and adhere to policies and processes – Governance – Hiring and Training – Procurement • Evaluate performance and identify lessons learned • Share successes and lessons learned with peers • Evolve based on lessons learned and look forward to offering new, high value DOT EIP services.

Abbreviations and acronyms used without definitions in TRB publications: A4A Airlines for America AAAE American Association of Airport Executives AASHO American Association of State Highway Officials AASHTO American Association of State Highway and Transportation Officials ACI–NA Airports Council International–North America ACRP Airport Cooperative Research Program ADA Americans with Disabilities Act APTA American Public Transportation Association ASCE American Society of Civil Engineers ASME American Society of Mechanical Engineers ASTM American Society for Testing and Materials ATA American Trucking Associations CTAA Community Transportation Association of America CTBSSP Commercial Truck and Bus Safety Synthesis Program DHS Department of Homeland Security DOE Department of Energy EPA Environmental Protection Agency FAA Federal Aviation Administration FAST Fixing America’s Surface Transportation Act (2015) FHWA Federal Highway Administration FMCSA Federal Motor Carrier Safety Administration FRA Federal Railroad Administration FTA Federal Transit Administration HMCRP Hazardous Materials Cooperative Research Program IEEE Institute of Electrical and Electronics Engineers ISTEA Intermodal Surface Transportation Efficiency Act of 1991 ITE Institute of Transportation Engineers MAP-21 Moving Ahead for Progress in the 21st Century Act (2012) NASA National Aeronautics and Space Administration NASAO National Association of State Aviation Officials NCFRP National Cooperative Freight Research Program NCHRP National Cooperative Highway Research Program NHTSA National Highway Traffic Safety Administration NTSB National Transportation Safety Board PHMSA Pipeline and Hazardous Materials Safety Administration RITA Research and Innovative Technology Administration SAE Society of Automotive Engineers SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (2005) TCRP Transit Cooperative Research Program TDC Transit Development Corporation TEA-21 Transportation Equity Act for the 21st Century (1998) TRB Transportation Research Board TSA Transportation Security Administration U.S.DOT United States Department of Transportation

TRA N SPO RTATIO N RESEA RCH BO A RD 500 Fifth Street, N W W ashington, D C 20001 A D D RESS SERV ICE REQ U ESTED N O N -PR O FIT O R G . U .S. PO STA G E PA ID C O LU M B IA , M D PER M IT N O . 88 G uidance for D evelopm ent and M anagem ent of Sustainable Enterprise Inform ation Portals N CH RP Research Report 865 TRB ISBN 978-0-309-44674-7 9 7 8 0 3 0 9 4 4 6 7 4 7 9 0 0 0 0