Integration efforts began in 1993 with a redesign of MDOT's core and support business processes. Initial efforts focused on the existing software and on processes that supported project and program development. MDOT discovered that four large data files contained essentially the same information but were stored and accessed in different ways. Reconciling these different storage methods and definitions would allow MDOT to eliminate several legacy applications and reduce multiple procedures to two major applications and one database. This integration would also significantly improve data quality.
The second step was to develop prototypes for the various internal management systems including those for bridges and pavements. The next phase, starting in 1994, was system and database design. Final development and rollout of the systems occurred through 1996. The development process combined top-down and bottom-up approaches simultaneously to create a new business culture within MDOT. The process was designed to identify, review, and re-engineer existing business processes, establish the overall data needs of internal stakeholders, and facilitate a fully decentralized but coordinated planning and programming strategy. This new process facilitated a less complicated organizational decision-making and project delivery structure.
MDOT also identified external users of the system. By engaging its partners in the cities, counties, metropolitan planning organizations, FHWA division office, and transit properties in the prototype development, MDOT set the groundwork for extending the capabilities and benefits of the Asset Management data integration effort beyond the MDOT environment.
Immediately it became clear that establishment of an open system, client-server architecture would facilitate decision making and that this architecture would be critical to the overall success of the agency-wide restructuring.
MDOT's first business plan, completed in 1997, formalized the need to develop the Transportation Management System (TMS) and tied the system directly to the agency's business processes and other information technology systems, as shown in the diagram below. The TMS was designed as one integrated application with one integrated database. This design reflected MDOT's view that the organization would now function as a single entity with common requirements for data and analysis, rather than as many competing components with independent missions, needs, products, and constituencies.
The development process was a joint effort between the consultant community and various business and process owners at MDOT. Over the life of the project, and especially during the prototyping phase, more than 500 department employees became part of the empowerment process.
For data to be a "corporate asset" instead of a source of conflict and misinformation, it must be managed systematically. In addition, standards for data timeliness, quality, and collection must be agreed to by the business process owners. All data integration efforts at MDOT were driven by business needs, not the other way around. A key to making this happen was the Michigan Architecture Project (MAP). This effort did not address process relationships, but examined the data needed for day-to-day operations. The MAP study found that 75 to 80 percent of MDOT data were duplicated across four application areas.
In moving toward its integrated Asset Management process, MDOT adopted four of the guiding principles identified by the National Performance Review1 for gathering data. The four principles are that data gathering must be focused, flexible, meaningful, and consistent.
The standard established was to collect data once, store it once, and use it many times. The most critical and difficult activity of the data integration process was identifying and defining which data should continue to be collected, which should be dropped, and what new data might be important. The guideline for this process was that every piece of data must have some owner who could not possibly function without it.
MDOT used four methods to establish its corporate data standards:
The Michigan DOT data integration effort was guided by the best-practice principle of collecting data once, storing it once, and using it many times.
The combination of TMS and MAP efforts resulted in the reduction of approximately 20,000 files into five major databases to be maintained and populated by MDOT. The MAP activity resulted in an enterprise data model, naming standards, quality assurance techniques, and a set of functional requirements necessary to ensure that decision makers had access to current and accurate data. MDOT decided to develop a new application in-house after it determined that no existing nonproprietary product could satisfy these requirements.
MDOT's ability to integrate the various asset databases was facilitated by the decision to abandon all existing linear referencing systems and adopt a single, statewide system. The single referencing system allowed consistency among many key data components and enabled sharing both within the agency and among county and city road agencies and the State Police.
To implement this new referencing system, MDOT worked with the Michigan Center for Geographic Information to fund the development of a statewide geographic information system (GIS) capability. This relationship leveraged the latest GIS and global positioning system (GPS) technology to develop a statewide, GIS basemap for use by all State agencies. The collaboration also produced a complete referencing system to which all transportation features could be tagged. On a statewide basis, this multi-agency partnership eliminated many of the processing steps that occur between data capture, integration into appropriate shared databases, and final dissemination across State government.
The scope of MDOT's data integration efforts involved the migration of all key planning and programming data from the mainframe to a clientserver/open-system environment. The efforts also established direct support and linkage to MDOT's Financial Obligation System and Project Information System. These two packages support the planning, monitoring, scheduling, and funding of projects through construction contract lettings.
TMS operates in a client-server environment using UNIX servers and Oracle databases. The system was programmed using the PowerBuilder development software. Each of the component databases is supported by ad hoc queries using the Sybase InfoMaker tool, although any tool supporting open database connectivity connections could have been used. The Maptitude software supports GIS queries. Other software is used in business areas to support lower level data preparation tasks. For example, FoxPro is used to prepare data for exchange between the traffic data information system and TMS.
The TMS was intended to be a single integrated application. The final product requires MDOT staff and remote users to access TMS to run all asset management or analysis programs available. This has created a strong awareness among various business areas of the information available to all users and has facilitated an integrated data analysis process across the following management systems:
TMS data and analysis results can be displayed using the statewide GIS basemap, which allows the following additional functions:
1 Serving The American Public: Best Practices In Performance Measurement, National Performance Review (June 1997), http://govinfo.library.unt.edu/npr/library/papers/ benchmrk/nprbook.html.