Appendix B – Synthesis of Survey and In-depth Interviews

B.1. Survey Objective and Approach

The objective of this task was to conduct a targeted survey and in-depth interviews of State DOTs on how they are implementing data ontologies to maximize the use of legacy data. A targeted survey was chosen because data ontology is still relatively new among State DOTs and surveying all 50 states would not be an efficient use of resources.

Following the literature review (Task 2) and additional input from the NCHRP Panel, the research team identified specific state DOTs to participate in the survey and in-depth interviews (Task 3) to develop case studies.

The team designed a survey questionnaire, aligned with important elements of ontology development, to solicit written responses from the selected agencies.

The questionnaire was distributed electronically to 18 DOTs, including:

• Arkansas Department of Transportation (ARDOT)
• California Department of Transportation (Caltrans)
• Florida Department of Transportation (FDOT)
• Georgia Department of Transportation (GDOT)
• Hawaii Department of Transportation (HDOT)
• Iowa Department of Transportation (Iowa DOT)
• Minnesota Department of Transportation (MnDOT)
• Montana Department of Transportation (MDT)
• Ohio Department of Transportation (ODOT)
• Oregon Department of Transportation (ODOT)
• Pennsylvania Department of Transportation (PennDOT)
• South Carolina Department of Transportation (SCDOT)
• Tennessee Department of Transportation (TDOT)
• Texas Department of Transportation (TxDOT)
• Utah Department of Transportation (UDOT)
• Vermont Agency of Transportation (VTrans)
• Virginia Department of Transportation (VDOT)
• Washington State Department of Transportation (WSDOT).

Eight State DOTs (ARDOT, FDOT, MnDOT, TxDOT, UDOT, VTrans, WSDOT, and Iowa DOT) responded to the survey, which was administered from April 1 to April 30. The respondents included data owners, IT staff, and asset managers. The research team compiled and reviewed responses from the responding agencies.

The team held clarification discussions virtually with agency representatives via Teams. These discussions were driven by the agencies’ responses to the survey questionnaire. During the virtual meetings, the research team asked for additional information or clarified responses from the survey questionnaire. The intent was to improve the quality and completeness of the information needed to develop the case studies and ultimately inform the final guide.

B.2. Summary of Survey Results

This section summarizes the results of the survey. Specifically, the sections that follow outline the current state of DOT practices pertaining to data ontology in the following areas:

• How respondents understand data ontologies and their applications.
• How legacy data is transformed, represented, and used across different business units and functions.
• Drivers, benefits, and challenges for implementing data ontologies for decision-making.

B.2.1. Experience with Ontologies

Respondents’ experience levels were wide-ranging, from ontology novices to recognized members of the ontology community. The responses indicate most respondents had limited knowledge of ontologies but were eager to learn about them and their benefits. Respondents from two State DOTs said they were above the “Novice” level, with one indicating they were proficient and had deployed a proof-of-concept in the past to evaluate the feasibility and practicality of data ontologies implementation within their agency. Respondents from two other State DOTs did not complete this section of the survey, so their experience levels were not included. Table 1 contains a summary of the respondents’ experiences and comments. Three competency levels were used to describe respondents’ experience with data ontologies:

• Novice: A beginner with minimal experience or knowledge of data ontologies, requiring guidance and supervision to learn the basics.
• Intermediate: Experienced and can perform tasks with a degree of independence but will benefit from guidance and may encounter challenges in more complex situations.
• Proficient: Possesses a higher skill level and expertise in data ontologies and can independently make decisions and handle complex data ontology tasks within their domain of expertise. May still seek advice in unique or challenging situations.

Table 3. Respondent’s Experience with Ontologies

B.2.2. Legacy Data Representation and System Modernization Efforts

The responding agencies reported several legacy systems modernization efforts, including upgrading financial, engineering, and asset management applications that were either developed in-house or purchased from vendors. These initiatives also involved migrating data from these legacy applications. The following sections summarize ongoing or completed legacy data migration efforts from the responding agencies.

VTrans (STARS)

VTrans (VPINS)

WSDOT (TRIPS/LRS)

WSDOT (Financial Data Mart)

WSDOT (Estimate Bid and Analysis System)

WSDOT (DOTtime)

WSDOT (MS2 to Traffic Data Mart)

Iowa DOT (IBM Mainframe)

Iowa DOT (ePower CME/ERMS)

Iowa DOT (Structure Inventory and Inspection Management System)

Iowa DOT (Deighton Total Infrastructure Management System)

Iowa DOT (Right-of-Way Information Management System)

MnDOT (Transportation Information System)

MnDOT (Program and Project Management System)

MnDOT (HydInfra)

MnDOT (SignTrack Database)

MnDOT (Damage Restitution Database)

ARDOT (Linear Referencing System)

B.2.3. Drivers for Improvement

Respondents indicated that the leading drivers behind migrating their legacy systems included the following:

• Technology Advancement: Respondents believe it is important to anticipate the advancing landscape of technology in the transportation industry. This belief drove the development of VTrans’ Civil Integrated Management (CIM) system. At the core of CIM lies the concept of digital twins: 3D models of assets that serve as a common reference point for information sharing. VTrans believes this will become the standard for developing a centralized repository of transportation network infrastructure.
• Compliance and Integration: FHWA’s All Roads Network of Linear Referenced Data (ARNOLD) required State DOTs to linearly reference all roads, including local roads. State DOTs identified this requirement as a driver to migrate their legacy data into GIS-enabled systems. In general, there were two approaches that State DOTs used to accomplish this. Some agencies, such as ARDOT, migrated their local road data into their existing GIS system and augmented it to handle all roads in their network. Other State DOTs used a vendor solution, such as ESRI Roads and Highways, to meet the requirement.
• Process Efficiency: Respondents revealed that a desire to eliminate risks associated with older systems drove them to complete legacy system migrations. As legacy systems age, staff experienced with using them retire and leave with no one to replace the knowledge. Additionally, many legacy systems mentioned had data gaps, manual process requirements, non-user-friendly interfaces, and issues with access and discoverability. By migrating these legacy systems to more advanced, user-friendly, and centralized systems, agencies noted that they were able to mitigate some of these risks. An example is WSDOT’s DOTTime timekeeping system that required paper timesheets to be manually entered into the system. By eliminating this need, WSDOT was able to mitigate human error, more accurately track time spent on projects, and pay employees more reliably.

B.2.4. Added Value

Respondents were asked to list legacy system migrations performed at their agency and the resulting benefits. They cited the following consensus value adds:

• Single Source of Data: A prevailing benefit across many responses was the movement to a single source of data, allowing for consistent reporting and more uniform data standards. Single data sources also improve the efficiency of business processes and lead to more streamlined data collection and fewer manual processes. For example, WSDOT lacked historic traffic data in its vendor traffic system from Midwest Software Solutions (MS2), called the Traffic Count Database System (TCDS). This led to time-consuming manual work to combine the current data in TCDS with the historic data in WSDOT’s legacy system. From 2019 to 2020, WSDOT migrated the legacy data into TCDS, providing a reliable,

• singular source of traffic data that has streamlined data collection, reduced the number of manual processes, and increased data availability to meet HPMS data reporting requirements. Similarly, MnDOT integrated data from its Program and Project Management System (PPMS) into the new Capital Highway Information Management System (CHIMES). The integration provided the agency with a single system that contains all project funding data, streamlining the project development process.
• Increased Data Opportunities: FHWA published ARNOLD requirements in 2012, mandating that states develop and submit an LRS network for all public roads. To address the requirement, agencies such as VTrans opted to migrate their legacy public road data system into existing LRS systems. Other states chose to migrate their data into vendor systems, such as ESRI Roads and Highways. Meeting ARNOLD requirements provides states with a centralized GIS road database, improves data consistency, reduces time needed to search for data, and leads to collection of more, higher-quality data for modeling and analysis. In many cases it also increases the attention given to local roads, as it is easier to incorporate data from local roads into analyses that lead to data-driven decisions.

B.2.5. Challenges

Respondents noted many challenges with managing and migrating legacy systems and data. The most prominent challenges included:

• Data Quality: The most common challenge was the poor quality of legacy data. Data quality issues include inconsistent field names, incorrectly drawn lines for GIS data, differing data collection standards, a lack of complete inventories, and a lack of quality control (QC). These issues can lead to technical difficulties and necessitate time-consuming manual processes when migrating legacy data.
• Data Access: Some agencies reported data access as a major challenge. Limitations to data access can stem from IT and data security but can also arise when functional groups do not share their data with the rest of the agency. Poor or lacking data access can cause data quality issues and duplication of efforts, as different groups are independently managing and manipulating the same data.
• Knowledge Management: Many agencies cited knowledge management as an issue. Agencies lose a collective understanding of legacy systems when experienced staff members leave or retire, and the agencies hire new staff members lacking legacy system experience.
• Lack of Documentation: Many responding State DOTs stated that there was a lack of documentation around their legacy systems and data, as well as their data governance practices. This can lead to incorrect use of data, exacerbating knowledge management challenges. Additionally, a lack of documentation can cause staff to become frustrated when they don’t know where to find data, in turn leading staff to leave increasing employee turnover.

• System Compatibility: While vendor solutions can be useful, they come with challenges. Agencies often have difficulties integrating both modern and legacy systems with vendors systems. Modifying these systems to accommodate integration can be costly and resource-intensive. Contractual and communication troubles with vendors can create additional challenges with integrating software and systems.

B.3. Potential Case Studies and Use Cases

This section outlines the practices of responding DOTs, which can serve as potential case studies or use cases. It discusses examples and tips related to data representation, knowledge management, and ontology development. The information presented reflects findings from in-depth interviews with respective DOTs.

B.3.1. Vermont Agency of Transportation (VTrans)

B.3.1.1. Current Practices

VTrans does not currently have any intentional or documented ontologies. However, during the development of new systems, ontologies and tools – such as Entity Relationship Diagrams (ERDs) and Unified Modeling Languages (UMLs) – are used throughout the process. For example, the VTrans maintenance management system contains a timekeeping system and a maintenance contract management system, creating a class hierarchy that builds a minor ontology. Their data is established on two separate SQL instances, each serving as an authoritative data source for its respective data. One server is for non-GIS enterprise data and the other is for GIS enterprise data. The department is undergoing a data governance effort, primarily driven by knowledge management and a goal of ensuring that staff can locate and use available data. As part of this, VTrans plans to build a repository or data encyclopedia to house the definitions and metadata of the various data sources used across the agency.

To meet ARNOLD requirements, VTrans’ Mapping unit, which manages the agency’s LRS, augmented its GIS system to accept data from local roads in addition to the National Highway System and interstate roads. The process involved moving the GIS data from other systems, with minor transformations completed by a vendor. VTrans also uses and maintains a Microsoft Access database, Query DB, shown in Figure 1. Query DB allows VTrans staff to search for agency data, including bridge inventories, construction and environmental data, and more. The database contains training slideshows and frequently asked questions (FAQs) to guide users on how to navigate and find the data they are looking for. Many agencies have indicated that they have challenges with employees finding the proper avenues to locate and use data. Making the training PowerPoints and FAQs directly available from the database’s home page helps VTrans to address this challenge.

B.3.1.2. Tip

Consider Defining Data Use Cases: VTrans suggests that an agency should consider interactions with and use cases for data in the new systems and build towards these considerations. VTrans further states that it is important to keep it simple to create achievable goals.

Develop Data Dictionaries and Metadata: To ensure effective knowledge management in the future, VTrans suggests developing a data dictionary and metadata repository. Proper documentation can reduce risk resulting from staff turnover and provide a means for new employees to learn where data is located and what it can be used for.

Garner Leadership Support: VTrans recommends presenting legacy migrations from a business perspective to garner leadership support. Data is often not considered an asset, and leadership often does not see improving data governance and accessibility as a worthy investment. Presenting the need for data migrations and increased data governance efforts regarding cost savings and productivity can garner buy-in from leadership and improve funding sustainability.

B.3.1.3. Practice Example(s)

STARS

VTrans’ State Accounting and Reporting System (STARS) serves as the agency’s mainframe financial system and is used to manage and monitor financial transactions and align finances with federal funding within the agency. A vendor developed this

system in the late 1990s, and it is still in use and maintained by the IT department. Driven by difficulties accessing and using the data housed in its financial systems, VTrans began migrating legacy data into STARS with the goal of improving data access and reporting and facilitating cross-system reconciliation. During this process, VTrans developed data glossaries and dictionaries to increase use and understanding of the data. Enterprise asset management data was integrated with financial data and financial transactions between STARS, and other systems were reconciled to track invoices, payment, and status between systems. Migration led to faster business processes and increased use and access to key data.

VPINS

The agency uses the VTrans Project Information and Navigation System (VPINS) to track its engineering projects throughout the project lifecycle, including financial programming, design, contract awarding, and construction. It was implemented in the late 2000s to replace a mainframe system that performed similar functions but was more limited. VTrans migrated data was migrated from the legacy project management system to VPINS to enhance the functionalities of the project management system, including spatially enabling the project locations and increasing data access and usability. The migration resulted in easier, more direct management of project data and data dictionaries and glossaries, as well as a better general understanding of the data.

B.3.2. Washington State Department of Transportation (WSDOT)

B.3.2.1. Current Practices

The responding staff from WSDOT were experienced in developing and maintaining ontologies. This was evident through their development of the agency-wide data catalog that contains the definitions and relationships of business terms. To build this ontology, along with other ontologies used throughout the agency, WSDOT uses the Stanford-developed WebProtégé², an online ontology-building tool. In addition, WSDOT has used the publicly available GIST upper ontology³, which contains common business definitions as well as added agency-specific terms and definitions. Through its Words Matter initiative, WSDOT is currently working to expand definitions of business terms by specific business unit. For example, the word “project” may mean something different to the IT department than for the Construction department, and WSDOT wishes to capture this difference in the data catalog. This data catalog does not contain

___________________

² WebProtégé (stanford.edu)

³ gist - a minimalist upper ontology - The Semantic Arts Minimalist Upper Ontology

technical metadata. Instead, technical metadata is compiled during the data modeling process using Erwin⁴.

WSDOT is currently focusing on portfolio management to prepare for future needs when managing applications, data, and terminology. As vendor solutions become more common, there is a need to plan for complications when integrating these solutions. Vendor systems may have different ways of defining terms and procedures, creating a need for standardization. In addition, with Building Information Modeling (BIM) and Digital Delivery emerging as the technologies that will determine the direction of the transportation industry, preparing the agency to accept these technologies is important. WSDOT believes ontologies are a practical way to approach these considerations and position the agency for future success.

B.3.2.2. Tip

Include Records Management Teams: WSDOT stressed the importance of including both the records management and business management teams in migration efforts. The two teams should discuss what data will be discarded, what data will be archived (and for how long), and what data will be migrated. Planning for integration in advance allows for a more streamlined migration process. During the migration, WSDOT suggests extracting records to be archived from their physical database and storing them in a content management system.

Use Existing Ontologies as Starting Points: Building an ontology from the ground up is arduous, so WSDOT recommends referencing existing ontologies as a starting point. The agency also recommends dedicated funding and staff for projects that involve developing ontologies. Knowledge management plays a significant role, so retaining experienced staff who can see the ontology development through to completion is important.

B.3.2.3. Practice Example(s)

Practical Solutions Accelerated Innovation Deployment Project (PS AID)/Environmental Ontology

WSDOT’s PS AID project was driven by the desire to improve the accessibility and searchability of the agency’s manuals. WSDOT aimed to accomplish this by developing and managing a platform for staff where they would be able to search manual content, provide feedback, and quickly update manuals accordingly. As part of this effort, WSDOT developed a proof-of-concept environmental ontology to classify

___________________

⁴ Erwin Data Modeler | Industry-Leading Data Modeling Tool | Erwin, Inc.

environmental manuals using Stanford’s WebProtégé ontology-building tool. This ontology is not currently used by the department but serves as proof-of-concept.

Data Catalog/Words Matter

WSDOT has developed and maintained an ontological in-house data catalog using WebProtégé that contains a data dictionary broken down by class hierarchy. It contains business definitions and terms used to define the columns in datasets and show how these terms are related. Figure 2 demonstrates how these are used for the term “culvert.” In addition, WSDOT has begun an initiative titled Words Matter that aims to unify the agency’s vocabulary through metadata, glossaries, taxonomies, and ontologies. The goal is to clearly define terms in the context of the agency and provide staff with the means to access this information to reduce time needed to search for necessary data and information.

The data catalog maintains consistency of definitions between datasets and allows for the development of new database schema and business terms. When first developing the catalog, the primary use case was to help the agency determine what data it had and the data’s condition in terms of documentation, completeness, and manageability. This was a key status check on the progress of WSDOT’s modernization efforts as it begins to adopt new, vendor-provided systems. Other use cases of the catalog include providing a location where staff – especially those who handle data integrations – can look up data definitions, providing the agency with a master dataset and serving as an aid for developing ontologies. While it is not widely used throughout the agency, it serves as a powerful tool for IT staff, data stewards, and data power users when managing different facets of data and implementing data governance efforts.

B.3.3. Texas Department of Transportation (TxDOT)

B.3.3.1. Current Practices

The Texas Department of Transportation (TxDOT) has many ongoing data initiatives. The agency is currently migrating legacy data into TxDOTCONNECT for managing the delivery of transportation programs and projects and importing datasets into Snowflake to serve as a centralized cloud platform. Data dictionaries exist for some systems (but not all) and data definitions are generally consistent across systems. A major challenge for TxDOT is the presence of siloed legacy data systems.

B.3.4. Iowa Department of Transportation (Iowa DOT)

B.3.4.1. Current Practices

Iowa DOT does not have any intentional or documented ontologies but is directing resources and attention to data management and governance. The closest the agency has to an ontology is its LRS, but it is not connected to all systems. A major driver of improvements the department’s management of data systems was the discovery that outdated systems were being used.

Iowa DOT has migrated applications from mainframe-SAS to SQL to spatially enable reporting. The internal roadway data is being reformatted per HPMS to use in the Highway Economic Requirement System State Version (HERS-ST) to support long-range transportation planning. Several other systems have been developed, including urban/metropolitan planning organization and statewide travel demand models. The development of web maps and dashboards also led to the development of the Iowa DOT Infrastructure Condition Evaluation (ICE) tool. Some systems, such as the LRS, have reference relationships. For others, a manual crosswalk is required. The department uses ERDs for its Roadway Aset Management System (RAMS) and has developed individual data dictionaries for various systems, as well as one for its data warehouse.

B.3.4.2. Tip

Determine Acceptable Deviations: Iowa DOT suggested reviewing business processes to determine what deviations are acceptable. Sometimes, migrations require changes to current processes both during and after the migration. These changes are important to consider beforehand and should be addressed such that there is less risk resulting from the change.

Have a Thorough System Selection Process: Iowa DOT stressed the importance of a thorough vendor selection process. Often, State DOTs select products that are not compatible with existing systems. Agencies should conduct extensive outside research, contact other agencies using the system, and know which questions to ask during the acquisition process.

Document Everything: In addition to data dictionaries and metadata, Iowa DOT recommends documenting key decisions, changes to workflows, and processes involved in the legacy migration process. This documentation can be used to justify the work performed, promote strong knowledge management, and enable future stakeholders to understand the migration process and the system itself.

B.3.4.3. Practice Example(s)

Right-of-Way Information Management System (RIMS)

Right-of-way information management was originally a manual process. Conversion to a GIS-based system was part of the department’s Five-Year Business Plan to improve transportation system safety and performance, enhance customer service, and grow innovation. The agency’s internal goal of the conversion was to improve the management and coordination of property assets owned by the department, specifically with a geospatial interface that can query the department’s extensive property data. The conversion was in progress at the time of the survey.

B.3.5. Minnesota Department of Transportation (MnDOT)

B.3.5.1. Current Practices

MnDOT has developed a controlled vocabulary containing drop-down lists and reference data, like an ontology. Additionally, the agency uses a Business Data Catalog (BDC) that contains definitions of data elements but does not contain schema, table, or column names. Beyond those items, MnDOT does not have any documented ontologies or ERDs. Respondents stated that ERDs may be developed and used for a project lifecycle but are not maintained outside the project window.

Many of MnDOT’s data processes are ad hoc, lacking a department-wide standard for data formats across systems. For example, the transactional data loaded into the agency’s warehouse environment is not integrated into an enterprise data model, and the warehouse contains only a portion of the data that the agency maintains. When

migrating data into its warehouse from source systems, MnDOT uses strategic, phased implementation plans; however, the data is typically not standardized.

B.3.5.2. Practice Example(s)

Program and Project Management System (PPMS)

PPMS was MnDOT’s project management system from 2001 to 2018. It tracked planning and funding data for construction projects, included information on project schedules, costs, and locations, and covered state aid, rail, transit, and projects that included federal funding. Driven by MnDOT’s desire to centralize and consolidate its project management systems, the PPMS data was migrated into the agency’s new Capital Highway Information Management System (CHIMES). This migration helped to streamline the project development process by bringing finance, design, planning, and project scheduling data into one place.

B.3.6. Arkansas Department of Transportation (ARDOT)

B.3.6.1. Current Practices

ARDOT is currently working toward developing a fully integrated enterprise system. Its critical databases have been migrated and policies and procedures are in place to ensure the systems are properly maintained. To accomplish this, ARDOT has been migrating databases from Microsoft Access and Excel to more stable network SQL servers connected to live feature services, such as IDrive Arkansas. The agency has also created geodatabases in SQL and works closely with its IT department to ensure the spatial data is properly developed and maintained.

Setting standards on key fields and schemas of datasets has been an important step in the process. Although ARDOT does not have any documented ontologies, ERDs, or UMLs, it maintains data dictionaries to promote consistency across datasets. To meet FHWA’s ARNOLD requirements, ARDOT migrated local road GIS data into the existing LRS system. The transition was straightforward because the agency uses a Route/Log Mile system to identify roads, and there were no significant changes to the methodology of the system. ARDOT continues to take steps to promote data awareness among employees and encourages documentation of processes and datasets. The agency is looking into developing a data governance and business intelligence area in the department to strategically address future data needs and enforce data standards.

B.3.6.2. Tip

Data Consistency Standards: ARDOT stressed the need for data consistency standards. Fragmented, siloed data is a frequently reported challenge when migrating data to new systems. Establishing standards can eliminate the need for manual, time-consuming work, reduce costs, and save resources when performing the migration.

Be Proactive: ARDOT recommends agencies be proactive when preparing systems for migration by making permanent data changes rather than using ad hoc, reactive data changes.

Train Staff: ARDOT states that training staff on data consistency standards and system operations can eliminate or reduce knowledge management risk and ensure a smoother migration process.

B.3.6.3. Practice Example(s)

Linear Referencing System (LRS)

Between April 2014 and December 2017, ARDOT conducted the migration and augmentation of its LRS. Prior to the migration, the LRS consisted only of routes that were eligible for Federal aid and did not include a frontage or ramp system. Driven by ARNOLD requirements and the desire to have a more data-integrated agency, ARDOT migrated local road data into its LRS. In addition, the agency increased the accuracy and usability of data in the LRS by redrawing routes at a consistent scale and within five feet of any asset or event. ARDOT mentioned that the process required trying different use cases and changing the original methodology to achieve a successful migration. The updated system has become the authoritative route network for ARDOT and assists local law enforcement as a crash location system. Data consistency has been improved as all agency staff use the same data source, helping to reduce the siloing of data and processes.

B.3.7. Florida Department of Transportation (FDOT)

B.3.7.1. Current Practices

FDOT strives to be a forward-thinking agency in how it views data and the systems used to house and analyze data. The department recognizes that failure to modernize its systems introduces risk and potentially increases future costs. FDOT undertook the Cloud-First Policy initiative in 2014 to mitigate risk and prepare for future modernization. The initiative aims to develop an enterprise-wide IT strategy, including an assessment of the department’s IT capabilities, personnel, and infrastructure, to align the department’s technology assets with the function of its business units. This initiative includes migrating almost 80 legacy systems from a server-based environment to a cloud-based environment while maintaining access to department data as newer systems are implemented. A key factor of the initiative is promoting data sharing within the enterprise, which increases data consistency and improves knowledge management.

FDOT also developed data dictionaries for enterprise and core applications that are available to staff. Although FDOT does not have any documented ontologies, the agency uses ERDs during the data modeling process to document definitions, formats, and sensitivity of the data attributes and entities. These models are used to cross-

reference legacy data elements when they are migrated to new versions of systems. FDOT increases data accessibility by modeling enterprise data with a centralized view and developing extensive metadata available to staff in data repositories.

B.3.7.2. Tip

Initial Planning and Risk Management: Based on its experiences migrating legacy systems through Florida’s Cloud-First Policy initiative, FDOT recommends that an agency understand the impact changing one system may have on other systems before performing a migration. If dependencies exist, it may introduce risk if one system is changed without updating the other. Because of this, FDOT recommends creating a detailed project plan and understanding that the process is iterative. The project plan must include managing the risks and categorizing them based on likelihood and impact. This approach can help an agency prepare for and understand the potential impacts of migrating legacy systems.

Communication and Stakeholder Engagement: FDOT says cost is a key consideration when migrating legacy systems. The agency also stresses the importance of sharing information in a timely fashion to allow stakeholders to provide feedback. Migrations affect many business units, including leadership, so it is important to consider the perspectives of all those affected.

B.3.7.3. Practice Example(s)

Data Infrastructure Migration and Modernization (DIMM) Program/Florida’s Cloud-First Policy

FDOT’s DIMM program, aligned with Florida’s Cloud-First Policy, is a multi-year initiative designed to modernize FDOT’s systems. This initiative involves migrating from server-based legacy business applications and systems to a cloud solution, as well as modernizing existing systems to ensure continued access to the Department’s data as technology evolves. This initiative began in 2014 and is currently ongoing, driven by the desire to reduce risk around the agency’s technological goals and have more data-driven and optimized processes.

FDOT’s goal for this effort is to provide the agency and staff with more centralized, accessible, and consistent data, as well as set the agency up for future migrations and integrations. As part of this effort, FDOT has identified 79 systems for migration. These systems include core, essential, supporting, and critical applications impacting all department areas and business units. The department has developed and continues to develop data dictionaries, glossaries, catalogs, metadata, semantic data models, and data architecture to increase understanding and consistency of its data. Additionally, FDOT considers transparent communication with the project’s stakeholders as a key pillar to achieving its goals. FDOT has encountered several challenges during this project, including difficulties managing costs and staff time, addressing enterprise

security, ensuring data quality, supporting rapidly increasing data volume, and maintaining a skilled staff knowledgeable with specific legacy systems.

B.3.8. Utah Department of Transportation (UDOT)

B.3.8.1. Current Practices

UDOT currently does not have any ontologies aside from occasional metadata. While the department acknowledges the need for data lineage and ontologies, staff are resistant to change, and IT doesn’t have the authority to change data management processes. The agency must solicit support from executive leadership to make changes but buy-in to implement and enforce data governance continues to be a struggle. Despite this, there are ongoing efforts to improve data practices and processes. UDOT is in the process of defining and standardizing its data. The department is developing an enterprise data dictionary. The development began without ERD or UML, but UDOT plans to incorporate them into more robust and dynamic tools.

The department is also migrating Oracle systems to the Google Cloud Platform (GCP). This migration includes a thorough evaluation of UDOT’s project management business systems. Manual migrations of legacy systems are sometimes performed on an ad hoc basis, which can be error-prone and cumbersome. In one migration example, UDOT noted that data functionality was lost following a migration of ESRI data. The department is currently working with ESRI and Google to resolve the issue. Under the current practices, it is easier for staff to recollect or recreate data if the original data owner has retired or changed positions. UDOT further stated that these challenges could be mitigated with the existence of metadata and ontologies to store the information needed to access, understand, and use the data.

B.3.8.2. Tip

Start Small with Committed Champions: UDOT respondents recommended beginning legacy migration and data improvements with small, willing groups. Agency staff recommend finding people who can see and communicate the vision, including marketing it to stakeholders to solicit buy-in.

Document and Communicate Small Wins: UDOT stressed the importance of documenting the success of any migration or improvement for future use. Having documented, successful practices from previous migrations can help inform procedures for performing future migrations, save time and costs associated with planning, and garner leadership buy-in to gain funding for future data migration and data governance needs. These documented practices can serve as the foundation for data strategy and governance policies, which are becoming more important as technology evolves.

B.3.9. Best Practices, Lessons Learned, and Conclusions

B.3.9.1. Best Practices and Lessons Learned

The development and implementation of data ontologies is crucial for State DOTs to enhance the effective use of all data types, particularly those stored in legacy systems. Although the concept of data ontology is not widely used across State DOTs to improve data-driven decision-making, there are data management and system modernization initiatives that can be leveraged to increase awareness and adoption, thereby improving the broader use of existing and future datasets. These surveys and interviews with State DOTs have informed us about the following best practices and lessons learned.

• Acknowledgement of the importance of data governance and strategic planning to advance data processes. Many agencies indicated a major driver for migrating legacy systems was the need to depart from ad hoc, manual data processes that are time-consuming and significantly impacted by staff turnover. To work toward this, ARDOT plans to develop a business unit specifically dedicated to managing data governance and business intelligence. Iowa DOT has developed a Strategic Data Business Plan and Asset Management Plan to establish governance structures and implementation plans that will foster a more data-mature agency. MnDOT uses strategic, phased implementation plans when performing data migrations and understands that migration processes are iterative and evolving. Other agencies, including VTrans, FDOT, and UDOT, prioritize involving stakeholders early in the process and garnering support from leadership to obtain funding and the resources necessary to establish data initiatives and perform legacy migrations. In some cases, this can help ease aversions to change that may hinder future data migrations and initiatives. UDOT specifically suggested starting with small groups that can effectively communicate the visions for data management changes from a business standpoint and then expanding those groups once they can demonstrate success.
• The lack of intentional or documented enterprise-wide ontologies to support ongoing legacy system migration efforts. FDOT is in the process of migrating 79 legacy systems to create a cohesive, consistent database as part of Florida’s Cloud-First policy. UDOT is currently migrating Oracle systems, some of which are considered outdated, to the Google Cloud Platform, which includes a thorough evaluation of the project management business system data governance. Most agencies are developing or already maintain data dictionaries and business catalogs, whether for enterprise-wide applications or to support a specific project. Additionally, many agencies have developed data repositories that, in tandem with data dictionaries, help keep staff educated on data availability and use. VTrans specifically suggested training staff about the assumptions and accuracy of collected data. Documented ontologies were evident at WSDOT, which uses WebProtégé to develop definitions and relationships of business terms across the agency. WSDOT has used publicly available ontologies such as the GIST upper ontology, which contains common

• business definitions, as a starting part for multiple ontologies. The use of existing ontologies is a strong practice for ontology development, as the process can be arduous and finding a practical starting point can eliminate much of the time and costs need for development.
• Advancement of data standardization and centralization. State DOTs are making noticeable strides in standardizing and centralizing their data. Most of this progress is driven by state and federal compliance efforts. ARDOT uses a RoadID/Log Mile System to log data and ensure consistency across datasets. To meet ARNOLD requirements, ARDOT migrated its LRS to combine local road GIS data with NHS/Interstate GIS data, meaning that all GIS road data now comes from one source. The agency also favors permanent data changes over reactive ones to prepare for future migrations. FDOT promotes data accessibility by modeling enterprise data with a centralized view through its DIMM program and using extensive metadata. MnDOT does not have ontologies, but to keep definitions consistent throughout business units, the agency has a controlled vocabulary with drop-down menus and reference data for its systems. Multiple agencies noted that documentation is paramount for standardization and migration efforts.

B.3.9.2. Conclusions

Because data ontologies are relatively new and developing in the transportation data domain, most of the State DOTs that responded to this survey have little to no experience with them and do not have any formal or intentional ontologies. However, there is evidence that some agencies are developing ontologies during project lifecycles and creating metadata, data dictionaries, and data catalogs. One responding agency reported having proficient experience developing and maintaining ontologies. The agency mentioned using Stanford’s WebProtégé to develop these ontologies, including a data catalog and a proof-of-concept environmental ontology designed to make the agency’s manuals more accessible and searchable. It appears that DOTs are interested in integrating ontologies into their practices and recognize the benefits of implementing data ontologies.

The responding DOTs provided many examples of legacy systems and completed data migrations. The migrations were varied, including financial systems, construction project management systems, LRS, and more. A common driver for legacy system migrations was compliance with federal requirements. Many survey responses cited ARNOLD requirements as a motivation to migrate or upgrade their LRS to include other datasets. Another common driver was the movement among DOTs towards using a centralized database. Many respondents said providing their staff with more straightforward ways to access and use data improved operational efficiency, resulting in time and cost savings. Additional drivers included technological advancements and the removal of costly, error-prone manual processes and outdated practices.

Major challenges encountered by DOTs during their migrations included poor data quality and limited access to data during integrations. These issues often arise from inadequate documentation and knowledge management risks, such as the departure of staff familiar with legacy systems. Additionally, the growing use of vendor solutions has introduced increased system compatibility challenges. Respondents noted that new systems are frequently incompatible with existing systems or other applications, rendering the solutions either non-viable or requiring significant modification costs and resources.