Best Practices for Integrated Data and Information Management Approach, Study notes of Data Communication Systems and Computer Networks

Download Best Practices for Integrated Data and Information Management Approach and more Study notes Data Communication Systems and Computer Networks in PDF only on Docsity! Synthesis of Best Practices for  the Development of an  Integrated Data and Information  Management Approach  Project 03-02 September 2008 Midwest Regional University Transportation Center College of Engineering Department of Civil and Environmental Engineering University of Wisconsin, Madison Author: Teresa M. Adams Department of Civil & Environmental Engineering, University of Wisconsin-Madison Principal Investigator: Teresa M. Adams Professor, Civil & Environmental Engineering, University of Wisconsin-Madison Co-Principal Investigator: Raphael Lazimy Associate Professor, School of Business i Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach DISCLAIMER This research was funded by the Wisconsin Department of Transportation. The contents of this report reflect the views of the authors, who are responsible for the facts and the accuracy of the information presented herein. The contents do not necessarily reflect the official views of the University of Wisconsin, the Wisconsin Department of Transportation or the Federal Highway Administration at the time of publication. The United States Government assumes no liability for its contents or use thereof. This report does not constitute a standard, specification, or regulation. The United States Government does not endorse products or manufacturers. Trade and manufacturers' names appear in this report only because they are considered essential to the object of the document. i Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 4.  Organizational, Political and Executive Management Structures ................. 50  4.1.  Business Cases for Data and System Integration Initiatives ................................. 50  4.1.1  Strategic Initiatives ............................................................................................... 50  4.1.2  Impact of Federal and State Mandates .................................................................. 50  4.1.3  Prioritization of System Integration Initiatives ..................................................... 51  4.1.4  Project Scoping ..................................................................................................... 51  4.1.5  Business Imperatives ............................................................................................ 52  4.1.6  Commitment and Support of Top Management ................................................... 52  4.2.  Organizational Structures...................................................................................... 53  4.2.1  Technology Management ...................................................................................... 53  4.2.2  Continuity through Administrative Changes and Employee Turnover ................ 54  4.2.3  Organizational Structure ....................................................................................... 55  4.2.4  Funding Structure.................................................................................................. 55  4.2.5  Centralized versus Decentralized IT Services ...................................................... 56  4.3.  Role of the CIO and Executive Management ....................................................... 56  4.4.  Additional Observations ....................................................................................... 57  4.5.  Thinking Ahead .................................................................................................... 57  4.6.  Key Success Factors, Best Practices in Systematic Application Integration ........ 58  4.6.1  Top Executive Level ............................................................................................. 58  4.6.2  Operational and Technological Levels ................................................................. 58  4.6.3  Implementation Level ........................................................................................... 61  Chapter 5.  IT Management and Planning ........................................................................... 67  5.1.  Planning, Managing and Executing Integration Initiatives and Projects .............. 67  5.1.1  Process for Identifying and Prioritizing System Development Projects ............... 67  5.1.2  Experience with ISP/Information Framework Development ............................... 68  5.2.  Role of The IT Department ................................................................................... 68  5.2.1  Organization of IT Services .................................................................................. 68  5.2.2  Responsibility for Business Analysis.................................................................... 69  5.2.3  Facilitating Data Sharing Across Bureaus and Divisions ..................................... 69  5.2.4  System Procurement and Working with Consultants ........................................... 70  5.2.5  Metadata Management .......................................................................................... 71  5.3.  Technology Investment and Adoption .................................................................. 71  5.4.  Integrating Location-Based Data .......................................................................... 72  iv Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach 5.4.1  Managing Spatial Data .......................................................................................... 73  5.4.2  Technical Challenges ............................................................................................ 74  Chapter 6.  Managing Data Integration Efforts for Systems Development ...................... 75  6.1.  Business Case/Drivers for the Project................................................................... 75  6.2.  Project Planning, Control and Management ......................................................... 75  6.2.1  Professional Project Management ......................................................................... 75  6.2.2  Cross-functional Project Team ............................................................................. 76  6.2.3  End-User Involvement .......................................................................................... 76  6.2.4  Resource Allocation .............................................................................................. 77  6.2.5  Managing the Project Scope and Expectations ..................................................... 77  6.2.6  Measures the Success ............................................................................................ 78  6.2.7  Using Standards and Formal Documentation ....................................................... 78  6.2.8  Location Referencing Methods ............................................................................. 78  6.3.  System Development and Deployment ................................................................. 79  6.3.1  Use of Prototyping Tools ...................................................................................... 79  6.3.2  Incremental Development Approach .................................................................... 80  6.3.3  Deployment and Adoption .................................................................................... 80  6.4.  Working Across Organizational Boundaries ........................................................ 80  6.5.  Managing Data Quality ......................................................................................... 81  6.5.1  Data Quality Issues ............................................................................................... 81  6.5.2  QA/QC, Metadata Practices and Policies ............................................................. 81  6.5.3  Data Quality Requirements and Evaluating Data Quality .................................... 82  Chapter 7.  Conclusions .......................................................................................................... 83  7.1.  Recommendations for Upper Management .......................................................... 83  7.2.  Recommendations for IT Project Management .................................................... 84  7.3.  Recommendations for Systems Development Team ............................................ 85  7.4.  Summary ............................................................................................................... 87  References ............................................................................................................................... 88  Appendix A Interview Questions .............................................................................................. 90  A.1.  Executive Management Perspective and Organizational Strategies ..................... 90  A.2.  IT Personnel, Information Processes, Methodology and Data Quality ................ 92  A.3.  Business and Project Managers and Integration Case Studies .............................. 94  Appendix B Acronyms ............................................................................................................... 97  v Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach vi List of Figures Figure 1. Overview of Transportation Asset Management (FHWA, 1999) ................................... 1  Figure 2. State Technology Management Structure (Kost 2003) ................................................. 54  List of Tables Table 1. Dates and Participants for Case Study Interviews ............................................................ 7  Table 2. Matrix Summary: MDOT Top Management (MDOT-1) ............................................... 24  Table 3. Matrix Summary: Michigan Transportation Management System (TMS) Application Development Team (MDOT-2) ............................................................................................ 26  Table 4. Matrix Summary: Michigan DOT IT Department (MDOT-3) ....................................... 29  Table 5. Matrix Summary: Ohio DOT Top Management (ODOT-1) .......................................... 31  Table 6. Matrix Summary: BRTS Development Team (ODOT-2) .............................................. 33  Table 7. Matrix Summary: ELLIS Application Development Team (ODOT-3) ......................... 37  Table 8. Matrix Summary: Wisconsin DOT Top Management (WisDOT-1) .............................. 40  Table 9. Matrix Summary: Meta Manager Application Development Team (WisDOT-2) ........ 44  Table 10. Matrix Summary: WISLR Application and Database Development Team (WisDOT-3) ............................................................................................................................................... 47  Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 1. Introduction This Chapter provides an introduction to the research documented in this report. A description of asset management is provided along with why data integration is important for asset management. A statement of the problem being address is provided in addition to the scope, objectives and methodology of this research. Next brief descriptions of the issues impacting the planning, development, implementation, maintenance and acceptance of asset management systems and data integration are provided. This chapter concludes with an organization of the report. 1.1. ASSET MANAGEMENT Transportation Asset Management is a strategic approach to managing transportation infrastructure assets. The goal of Asset Management is better decision-making based on using quality information and well-defined objectives (Cambridge Systematics 2002). Figure 1 shows the asset management process as defined by FHWA (1999). The following is a definition of asset management seen from a transportation perspective: “….. asset management is defined as a systematic process of operating, maintaining, and upgrading transportation assets cost-effectively. It combines engineering and mathematical analyses with sound business practice and economic theory. The total asset management concept expands the scope of conventional infrastructure management systems by addressing the human element and other support assets as well as the physical plant (e.g., highway, transit systems, airports, etc.). Asset management systems are goal driven and, like the traditional planning process, include components for data collection, strategy evaluation, program development, and feedback. The asset management model explicitly addresses integration of decisions made across all program areas. Its purpose is simple—to maximize benefits of a transportation program to its customers and users, based on well-defined goals and with available resources..”(FHWA 1999). Figure 1. Overview of Transportation Asset Management (FHWA, 1999) Chapter 1 Introduction 1 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach The key principles of asset management represent a way of doing business. Asset Management requires agencies to look current procedures to find way for better decision-making with better information. The following are basic principles of asset management (Cambridge Systematics 2002). • Asset Management is a Strategic Approach: A strategic perspective takes a long view of infrastructure performance and cost, and considering options in a comprehensive, proactive, and informed way. It is driven by policy goals and objectives and relies on systematic assessments of asset performance and cost in making decisions on future actions. • Asset Management Encompasses Multiple Business Processes: Asset management encompasses a number of business processes related to infrastructure management in DOTs, including those related to planning, program development and recommendation, engineering of projects and services, and program delivery. Decisions on allocating resources are policy driven and performance-based, consider a range of alternatives, have clear criteria for decision making, and investigate the most cost-effective solutions through analyses of tradeoffs. The business processes are managed to elicit effective contributions from all levels of the organization, and to foster communications on asset management needs and accomplishments both within and outside the agency. • Asset Management Relies on Good Information and Analytic Capabilities: Quality information – accurate, complete, timely – is important at all stages of asset management. Information technology is a practical necessity in supporting asset management. 1.2. DATA INTEGRATION FOR ASSET MANAGEMENT Asset Management involves the gathering, retrieval, storage, analysis, and communicating enormous quantities of data. Data are required to evaluate and monitor the condition and performance of the asset inventory, develop performance objectives and measures, identify cost- effective investment strategies, and conduct asset value assessments. Information is also required to monitor the effectiveness of the Asset Management business process. Data integration and data sharing are vital components of Asset Management (FHWA 2001, Vandervalk 2003). It is not necessary to store all the transportation system’s data in a single repository, it is critical that data be readily accessible and comparable. States and local agencies know that without an integrated set of data they can never make strategic and comprehensive transportation investment decisions. The goal of data integration is to consolidate or link the data that exist in separate files or database systems so they can be used to make decisions within and across asset types. Good information and analytic capabilities are a direct result of an integrated database. For an agency, effective data integration and data sharing result in improved information processing and decision-making capabilities to support Asset Management. Compared with autonomous databases, integrated databases offer many advantages (FHWA 2001): • Availability/Accessibility: Data is easily retrieved, viewed, queried, and analyzed by anyone • Timeliness: Data can be quickly updated and therefore is generally current. Chapter 1 Introduction 2 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach • Accuracy, Correctness, and Integrity: Integrity of the databases is upheld in an integrated environment. Process also exist for automated error checking and verification • Consistency and Clarity: Specified data have a clear and unique definition throughout the agency • Completeness: All available information associated with the assets, including historical and recently collected data, can be found in the database. • Reduced Duplication: Integration reduces the need for multiple updating and ensures that everyone has access to the same data. • Faster Processing and Turnaround Time: Less time is spent on consolidating and transmitting data to various users in the agency. • Lower Data Acquisition and Storage Cost: Data are not collected or processed twice, and are consolidated and stored at locations in the agency that provide optimal convenience and ease of maintenance. • Informed and Defensible Decisions: Highly organized, comprehensive databases allow users to drill down through successive levels of detail for any given asset. • Integrated Decision-Making: data integration permits decision-support analysis throughout the transportation system, 1.3. MOTIVATION, OBJECTIVES, AND METHODOLOGY In the past, many projects were inventory based, i.e., how many roads or bridges and their condition. Now most projects support decision making such as taking data from several locations and put them in a warehouse. Data that did not co-exist is brought together to help make decisions on managing projects and setting priorities. State transportation agencies (as well as other public transportation agencies, corporations, and other organizations) struggle with numerous problems and challenges in building integrated data and information systems that provide high-quality information for the effective execution and management of operations and for supporting analysis, control, and decision making activities. The problems are both technical and organizational. Among them are the barriers that departments go through to get new systems up and running. Many departments complain about how hard it is to get the IT shop to respond to changing needs. At the same time, IT shops often feel criticized for enforcing the information strategy plans, which may not be updated to reflect changing needs. Another major problem facing organizations is the so-called “information gap.” The organization has “mountains of data” but very little information to support changing business needs, and intra- and inter-agency collaboration. State transportation agencies are shifting focus away from constructing new highways and facilities toward improving operations, safety, and performance- based maintenance of existing facilities. Now more than ever, state transportation agencies must interface with external organizations to address issues concerning environmental sustainability, safety, and most recently, homeland security. Two primary reasons for the information gap problem are the fragmented ways in which organizations have developed legacy information systems and databases, and the fact that most systems have been developed to support routine business processes, with little or no attention to Chapter 1 Introduction 3 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach • Working across organizational boundaries developing data/system integration initiatives/projects • System deployment, evolution, and maintenance • Best practices, lessons learned, long-term challenges or guidelines The interviews with IT department at the DOTs aimed at gathering lessons learned and best practices from the perspective of the information systems experts the about integrating/interfacing existing information systems to support asset management decision- making. The scope of the interview included prioritization and development processes; technological strategies for data sharing, system integration and interfacing, managing data quality, integrating location-based data; and the role of the IT department in the agency’s strategic planning process. Following were the broad questions asked to the participants: • Experience with ISP/Information framework development • Role of the IT/IS unit and the CIO in the agency • Role of IT/IS unit in Asset Management Systems and other systems development projects • Technological strategies for cross-functional systems • Managing data quality • Strategies for integrating location-based data • Best practices, lessons learned, long-term challenges or guidelines Appendix A contains the detailed questions for each interview. Table 1 lists the participants for each of the interviews. In addition to the interviews listed, the Research Team had an informal meeting with Rick Lilly, Transportation Management Asset Coordinator regarding the Michigan Transportation Asset Management Council (TAMC). 1.5. BACKGROUND AND RELATED WORK This research effort builds upon related efforts. The objective is to take the “next step”. In 2001, FHWA Office of Asset Management published a “Data Integration Primer” (Primer 2001) and Data Integration Glossary (Glossary 2001) to help state transportation agencies understand the importance and benefits of data integration for accomplishing asset management, and to explain options for developing and expanding data integration effort. The primer provides a high-level overview of how to integrate data and the associated challenges. The FHWA Office of Asset Management and AASHTO sponsored a Peer Exchange on Data Integration in Chicago IL in December 2001 (Peer Exchange 2001, Proceedings 2002). Nearly one hundred transportation professionals from across the country including representatives from 26 State DOT's had the opportunity to learn more about integrating and data sharing. The forum highlighted ongoing data integration efforts and individual experiences in seven State agencies (Florida, Maine, Michigan, Mississippi, Ohio, Tennessee, and Virginia). Key presentation and discussion areas included integration requirements, legacy databases, alternative tools and technologies, data standards, reference systems, and technical/organizational challenges. Participants at the peer exchange identified the following Data Integration Issues: • Location Reference System • Use of GIS • Dealing with Legacy Data • Implementation Chapter 1 Introduction 6 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach • Change Management (e.g. People) • Software, and • Use of outside help (contractors) Table 1. Dates and Participants for Case Study Interviews Interview Perspective Participants MDOT-1 Top Management Leon Hank, Chief Administrative Officer John Polasek, Director, Bur. of Highway Development John Friend, Director, Bur. of Highway Delivery Ron Vibbert, Manager, Asset Management Section MDOT-2 Transportation Management System (TMS) Development Team Bill Tansil, Administrator Asset Management Division Ron Vibbert, Manager Asset Management Section Marsha Small, Manager Statewide Planning Section MDOT-3 IT Department Doug Couto, Chief Information Officer, Department of Information Technology Ron Vibbert, Manager Asset Management Sect., Bur. of Transp. Planning ODOT-1 Top Management Gordon Proctor, Director ODOT Leonard Evans, Systems Analysis Planning Cash Misel, Planning and Production Management Matt Selhorst, Planning Shobna Varma, Information Technology ODOT-2 BRTS Development Team David Blackstone and Jim McQuirt, Technical Services Leonard Evans, Systems Analysis Planning Monique Evans, Research & Development Suzann Gad, Corridor & Urban Planning Bill Pucket and Chris Yodzis, Information Technology Kirk Slusher, District 1 Planning ODOT-3 ELLIS Development Team Chris Yodzis, Randy Kirsch, and Bill Puckett, Information Technology Leonard Evans and Robert Tugend, Systems Analysis Planning Tony Goddard and Joe Hausman, Technical Services Tim Keller, Structural Engineering Emil Marginfan, Pavement Engineering James Young, Traffic Engineering Dianna Rouan, Production, District 5 WisDOT-1 Top Management Ruben Anthony, Deputy Secretary, WisDOT Kevin Chesnik, Administrator, Div. of Transp. Infrastructure Development Mark Wolfgram, Administrator, Div. of Transp. Investment Management Brenda Brown, Administrator, Div. of Business Management Joyce Gelderman, Director Bur. of Automation Services Chapter 1 Introduction 7 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach WisDOT-2 Meta Manager Development Team Mark Wolfgram, Administrator Div. of Transp. Investment Management Brad Javenkoski, Dawn Krahn, Darren Schoer, and Mike Schumacher, Div. of Transp. Investment Management WisDOT-3 WISLR Development Team Susie Forde, Michael Krueger and Kelly Schieldt, Div. of Transp. Investment Management The participants identified the following technical and organizational challenges that can impede data integration efforts: • Data Conversion/Migration • Conversion to Linear Reference System • Changes in Technology/Systems • Data Heterogeneity/Quality • Knowing the current situation and direction • Time needed to develop system • Time needed to adopt by agency • Changes in agency requirements • User Involvement At the Chicago Peer Exchange, state agency participants expressed the need for technical assistance. Examples given were case studies of agency experiences, a best practices document describing how to overcome the various challenges, and application benefits assessment studied. Among the next steps identified at the peer exchange was the need for a Data Integration State of the Practice Survey (Planning, ITS, etc.) As a result of the Chicago Peer Exchange, Federal Highway Administration Office of Asset Management sponsored a Review of Data Integration Practices (Vandervalk 2003) and initiatives across the county. That study reviewed and synthesized data integration practices among transportation agencies at the state and local levels. The researchers selected transportation agencies based on the literature review and carried out detailed reviews describing the data being integrated and purpose, software and tools used, problems encountered, lessons learned, and the agency’s future plans. Innovative software, tools and methods applied by transportation agencies were identified and their advantages and disadvantages were highlighted. The final report (Vandervalk 2003) includes brief summaries of relevant reference documents indicating which aspects of data integration are being addressed by each. The Review of Data Integration Practices report summaries the finding from the agency reviews. The study identified common considerations for data integration including functionality, legacy data and location referencing. The most common architecture used by transportation agencies to integrate data is a centralized data warehouse system. The lessons learned include the following (Vandervalk 2003): • Upper management support, • Role of Information Technology (IT) Department, • Business Process Reengineering, • User Needs, • Buy-in, • Off the shelf versus custom applications, • Metadata, Chapter 1 Introduction 8 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach Chapter 2. Asset Management System Case Studies This chapter presents a brief overview of each state’s story about data integration for developing an asset management system. The primary source of this information is from the interviews. Additional information was obtained from the sources as cited. The description of each case study focuses on the business case in terms of motivation, objectives and expected outcomes of the integration effort(s). The case studies include a description of the project development effort, results and current status. , None of the agencies used formal approaches for evaluating the outcome of the systems. 2.1. MICHIGAN DOT Michigan DOT (MDOT) is decentralized. In addition to the central office, the agency has seven regional offices and 26 Transportation Service Centers (TSCs) throughout the regions. The Transportation Service Centers (TSCs) were created with the purpose of moving MDOT closer to customers. Each TSC services 2 to 4 counties depending on population. They have five functions: maintenance, road design, construction, traffic, safety, and permits. (MDOT contracts with about two thirds of the Michigan counties to do maintenance including snowplowing.) As a result of MDOT being decentralized, IT people now work for the Michigan Department of Information Technology. It was identified that after decentralization, when people get together they are more focused, so there is a better understanding and definition of a project and that MDOT may be more disciplined than other state departments in managing IT. MDOT takes a strategic business to IT. The agency regards IT systems and infrastructure as assets rather than business expenses. This approach has been valuable in quieting concerns about spending too much money on technology and updates. MDOT began its data integration effort by building the Transportation Management System (TMS) in early 1990s. MDOT’s realignment of business practices for asset management provided the impetus for building the TMS. With TMS, the department migrated key planning, programming, and project delivery system data from the mainframe to a user-friendly integrated environment. This major task involved fusion of more than 20,000 separate files into five major databases. TMS has enables MDOT staff and remote users to access to the agency’s asset management programs available and facilitated integrated analysis across pavement, bridge, congestion, safety, public transit, and inter modal information systems. TMS supports inventories and analysis. Budgeting and programming are done differently with other programs. TMS provides the platform for consistent and collaborative decision support and resource allocation processes that support Asset Management. MDOT also adopted a single, statewide linear referencing system. TMS data and analysis results can be displayed using statewide GIS base map. Another major data integration initiative is the Michigan Geographic Framework by the Michigan Center for Geographic Information (CGI). TMS query results are shown as tables on a screen; a GIS viewer is not built into TMS. The Michigan Geographic Framework (MGF) program is designed to solve this data and communication problem by creating and maintain a single “official” state base map for state business needs. The map contains all of the themes most commonly used in applications Chapter 2 Asset Management System Case Studies 11 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach including transportation, hydrography, government boundaries, pubic land survey sections and geodetic control. TMS results can be displayed on a map using the framework. The Michigan Geographic Framework Network (MGFN) is a natural extension of the MGF program. MGFN represents a formal relationship between state agencies that involves data maintenance, education/coordination or software/application development. The network focuses on formally maintaining an up-to-date and relevant centralized geographic base map that references state, local and federal business data (Surber 2004). 2.1.1 Business Case for the Transportation Management System (TMS) The initial version of ISTEA required state DOTs to have various management systems (e.g., safety, congestion, public transit, pavement, etc.). In 1991, MDOT decided to satisfy the requirements using a single integrated database because all of the systems essentially use the same information. MDOT’s ISTEA systems using a single database became known collectively as the Transportation Management System (TMS). Besides the mandate from ISTEA to develop management systems, MDOT’s mainframe was at the end of its’ useful life. A new mainframe would not provide users with current information and interactive capabilities. Additionally, MDOT’s referencing systems did not allow easy data sharing and integration. IT staff could not patch management systems and make them work. As a result, MDOT decided to abandon the mainframe, go to client server, and rewrite the applications. There was pressure from the press and legislators for a better decision making process. Because all departments were using different databases, the public got different answers from different people at different times. Consequently news reports gave contradictory stories. This played a key role as an impetus for TMS. TMS was designed to be a decision support system that presents a snapshot in time. Needs based performance indicators were developed and documented as part of the business case for the system. 2.1.2 TMS Project Development TMS development started in 1995 and continued through 1996. When the ISTEA requirements were rescinded, MDOT had already developed the business case, direction, and committed significant time and money to TMS; portions of TMS were in the testing phase. MDOT continued the development of TMS based on the original requirements and design. Buy-in to the system was essentially top-down. Agency leadership was committed to the system from beginning and directed the development through participation on the steering committee. The TMS development teams reported to the central steering committee. There was good buy-in on the development teams because they had total department support. The TMS development teams comprised people from different parts of the agency that represented of the individual ISTEA management systems to be integrated. The TMS teams worked with an on-board consultant to identify the TMS requirements, functionality, look-and- feel, and development process. The requirements guided technical design, prototyping, testing and deployment. The TMS teams did modeling, design and developed migration plans in addition to managing certification and definitions. End users were brought into the project for testing interfaces and databases through scenarios. The directions from the executive level was to keep TMS simple and make it such that Chapter 2 Asset Management System Case Studies 12 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach management could use it to do basic queries (instead of having a “technocrat” run a scenario for them). TMS has two interface levels: one for general information queries and one for complex manipulation. System, data and data quality problems and solutions were documented. Considerable effort in the development of TMS was spent moving systems from the mainframe to the client server architecture. TMS is implemented as an Oracle database (i.e., not a data warehouse) with each ISTEA system area having a schema. A component for each system rolled out every six months. 2.1.3 TMS Results As a result of TMS, business processes were streamlined; data is easier to get and the agency decisions are based on consistent data. TMS has causes the turn around time for some business processes to go from weeks to minutes. TMS is viewed as an enterprise-wide resource. The business areas still have their own silos for analysis but the data in TMS is a corporate asset available to anyone in the agency with few restrictions. 2.1.4 Status of TMS Limitations of technology kept MDOT from totally achieving the original vision for TMS. If TMS were developed today, it would be vastly improved, be built differently, and have more functionality because the technology is available. The overarching view of TMS has not been implemented. Administration changes at MDOT (new governor and administrators) affected the ongoing development of TMS. Now many of the original TMS team members are no longer with MDOT due to an early retirement program. TMS has been out for 10 years and is currently being re-evaluated to look at mechanisms, implementation and results from using TMS on projects. The bridge management module has been refashioned based on the Pontis model. Pavement and maintenance business areas are not included in TMS. The safety area is in TMS but a few applications (i.e., high crash listings and high crash fatalities) are still running on mainframes but are being looked at for migration. TMS presents a snapshot in time; the system does not provide analysis support to identify highway projects, though it contains information on existing and forecasted conditions. Managers and engineers in geographic areas make project decisions. Future plans for TMS are to: • Incorporate pavement management. • Update TMS to reflect the new organizational structures at MDOT. • Develop an internet-based bridge inspection module to replace Pontis-lite. • Develop internet-based public transportation components. • Implementing Oracle Spatial to manage spatial data with GIS functions. 2.2. OHIO DOT ODOT takes a practical approach to asset management concentrating on inventories, tracking conditions, and having the business processes to get inventories upgraded. There is no basic assumption that data integration is critical for asset management. From a strategic business point of view, ODOT stresses that everything should be business driven. At ODOT rather than looking Chapter 2 Asset Management System Case Studies 13 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach were managed by continually referring back to the initial project charter containing the goals and expected products of the initiative. After the initial project startup, the steering committee was kept informed about progress and resources spent through quarterly reports. There was no on-going, formal comparison of actual to estimated cost. The development process was generally kept on schedule. 2.2.3 ELLIS and BTRS Results BTRS provides the underlying framework for managing inventory condition and making that data available through location referencing. The Ellis asset management planning tool could not achieved without BTRS. As a result of BTRS, the 12 districts are able to pull the information they want and take command of the information without going to a central office for outputs. The BTRS mapping tool has been useful for validating information and the districts are able to get immediate benefits from maps of their projects now and through 10 years into the future. The information provided by ELLIS and BTRS are used to assess performance of the agency’s asset management program. The overall condition of highway facilities reflects the districts’ performance. Highway performance is then tied to employee performance evaluation. Likewise, information in ELLIS and BTRS helps improves ODOT’s accountability to public. A key success factor in getting district buy-in was that the steering committee of agency leaders participated in presenting ELLIS and BTRS to the districts. Everyone at the district offices was invited to give feedback on the system. System adoption required the districts to change the straight line mileage for their projects. In some cases, manual re-coding was required. After the districts understood the benefits and end results, change was a little less painful. In the end, the districts were able to achieve what was promised and more. The lesson learned is in being able to motivate change in a decentralized organization by communicating benefits. 2.2.4 Status of BTRS BTRS was completed in 2000 after one year of effort. Of the 11 applications prioritized, all but one was integrated. Additional applications are being integrated into the BTRS model. One remaining challenge is to keep the BTRS system current with regard to changes in business processes from year to year. The design of BTRS for integrating data follows a brute-force approach. BTRS takes the roadway network and breaks it into 0.01-mile segments. All asset inventories are then assigned to the segments. The BRTS database has 10 million records. There are data management problems particularly for updating and for monitoring change at the segment level. If there are changes in the underlying roadway network, the 0.01-mile segments change the next time the roadway network is segmented. Future enhancements and a new strategic initiative for updating BTRS are in the works. It is planned that the BTRS data layers would be stored in an Oracle Spatial database with GIS on top of it. The system would be able to do routing, make logical decisions about data, and be able to update itself on the fly. 2.3. WISCONSIN DOT 2.3.1 WisDOT IT Project Planning Chapter 2 Asset Management System Case Studies 16 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach Technology projects at Wisconsin Department of Transportation (WisDOT) normally fall into two categories; Application Projects (technology business solutions e.g. Wisconsin Information System for Local Roads (WISLR)) and Infrastructure Projects (technology projects for improved data management, network management, telecommunications, hardware and software projects, etc.). The process for selecting business application and IT projects at WisDOT begins in each division. Employees identify the needs and benefits of an automation solution for a business activity. The division managers prioritize the business requirements for their own division. The Technology Management Council (TMC), comprising management representatives from each division, reviews all prioritized lists and prepares a final departmental prioritization. The TMC works together with Bureau of Automation Services (BAS) to create a departmental IT project plan (known as Page 1). BAS manages the Page 1 priority projects for the entire department. WisDOT is a decentralized organization. As such, the divisions can not mandate changes that impact business processes in another division and there is no mandate requiring that all IT projects be submitted for prioritization in the agency-wide IT plan. BAS is responsible for the planning, procurement, installation and support of WisDOT’s infrastructure technology. BAS maintains knowledge submits of new, efficient and cost effective technologies in the marketplace. This knowledge is used for setting the future direction of technology for the department. BAS tracks and responds to technologies used within WisDOT that are at risk and require replacement. BAS reviews the divisions’ IT plans to determine needs for infrastructure technology and prepares a prioritized infrastructure project list. The TMC determines the final priority for infrastructure projects to be included in the Page 1 plan. Infrastructure projects are usually funded by rates that are charged to each division. The TMC determines the rates for infrastructure projects. Page 1 is the 18 month BAS project priority plan created by the TMC and BAS that lists those departmental IT (application and infrastructure) projects that are managed by BAS and are fully staffed and funded. Because all available staff hours are assigned to Page 1 projects, additional projects get added only if the TMC agrees that allocated staff or funding can be reassigned or if additional staff or funding becomes available. Each month, BAS distributes status reports on the Page 1 projects. Every 12 months, the divisions, TMC, and BAS create a new 18 month plan. BAS seeks input from the divisions via the Technical Advisory Group (TAG) and the Information Management Group (IMG). Knowledgeable business area experts familiar with IT sit on these committees and are charged with providing division input to the infrastructure project priority setting process. These groups also contribute to creating policy and setting standards infrastructure activities. 2.3.2 WisDOT Location Control Model (LCM) The Link-Site linear referencing framework, a topological linear link-node network of the state highway system, was developed during the 1990’s as a result of WisDOT’s ISP plan. Along with this framework a set of Location Control Method (LCM) tools were developed. One of these tools converts linear attributes based on Reference-Point referencing to Link-Site referencing. Over the years, WisDOT has modified and enhanced the LCM tools. They are routinely used to convert spatial data layers to Link-Site referencing. 2.3.3 WisDOT Asset Management Systems Chapter 2 Asset Management System Case Studies 17 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach There are two predominant asset management systems at WisDOT: Meta-Manager and the Wisconsin Information System for Local Roads (WISLR). Meta-Manager is used for budget allocation and performance evaluation for the state roadway system. WISLR is used for inventory, certification and budget allocation for local roads and county trunk lines. The purposes of Meta-Manager are to support decision making at the district level for highway performance modeling, development of mid-range program, and long-range planning. Meta- Manager was the first effort at WisDOT to use the agency’s LCM tools to integrate asset data from the agency’s specialized ISTEA management systems (e.g. pavement, safety, etc.) through location referencing. Because the LCM tools were available, WisDOT was the first state to have an Asset Management System like Meta-Manager. On a quarterly basis, the system integrates data from the bridge, pavement, safety, congestion, traffic, and six year program. Meta-Manager helps develop alternative treatments for each highway segment and bridge and estimates cost and performance impact of each alternative at the project level. For planning purposes it suggests a set of project treatments based on policy goals, priorities and available funding. Once the projects are selected, the Meta-Manager system allows prioritization based on performance and costs (StClair 2001). The Wisconsin Information System for Local Roads (WISLR) is an Internet-accessible system that helps local governments meet state statute requirements for inventory reporting and certification and supports decision-making for local roads management. Using GIS, WISLR combines local road data with interactive mapping functionality. The result is a system that allows users to display their data in a tabular format, on a map, or both. Users can see trends in data and produce custom maps (Nestler et. al. 2003). 2.3.4 Business Case for WisDOT’s Meta-Manager Meta-Manager was created to provide supporting rationale first for division budget proposals including justification of a gas tax increases and then for the state highway plan. Analysis and presentation of alternative budget proposals required a tool to measure short-term system improvements given various changes in budgets. The state highway plan, a central office function performed by DTIM, identifies and prioritizes needs in the long term. Meta-Manager allocates funding in two categories: district allocation and backbone rehabilitation. • For district allocation is for 6 years of projects. The distribution is based on a biannual needs analysis done in Meta-Manager. For example, if Meta-Manager identifies a district as having 20% of state-wide needs, ideally that district receives 20% of available funds. To prevent disruptions, shifts in fund distribution are phased. • Backbone rehabilitation is for improving and maintaining the core 2020 backbone system, composed of interstates and multi-lane divided highways. For backbone systems, districts have almost 100% autonomy in what they do; they must stay within their budget. Projects that are in FIPS become inputs to Meta-Manager. Meta-Manager’s budget allocation model uses needs analysis based on statewide policies of prioritized performance thresholds constrained by budget (i.e., $550 million) and miles generated (450 miles/year). A low-priority bridge need has higher priority than a high-priority pavement need. However, to be a need it has to go beyond a threshold, set by the state and rely on federal Chapter 2 Asset Management System Case Studies 18 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach scheduling/funding) and HPMS inventory files to be used as input to see how well projects are satisfying needs and to refine the allocation models. An additional planned enhancement to Meta-Manager is a scenario builder that will allow users to add/change various scenarios/projects onto a program timeline and see the net change or impact. 2.3.8 Business Case for Wisconsin Information System for Local Roads (WISLR) The Wisconsin Information System for Local Roads (WISLR) helps local governments and WisDOT manage local roads data and meet state statute requirements. The main driver for WISLR was to reduce redundancy in the General Transportation Aid (GTA) inventory and certification process. In the GTA program, the WisDOT is responsible for paying out funds (about $400 million annually) to 1922 municipalities and county entities for public roads. Money allocation is based on WisDOT’s mileage certification of the local roads. The goal for WISLR was to have local governments enter and continuously update GTA certification data via the Internet. Prior to WISLR, the GTA certification process involved considerable interaction between WisDOT and local governments. WisDOT sent out CVT maps, general report forms, construction reports, and instructions to all local government each August. Each municipality would write out what they have done over the past construction year on the sheets of paper (hard copy) and returns them to WisDOT districts. Having local governments enter data over the internet eliminates the paperwork and reduce the time for updates. Another motivation for developing WISLR was to reduce duplication of mapping efforts. Prior to WISLR, there were numerous separate mapping applications for CVT (County Village Town) maps and virtually none at the county-level. WISLR was intended to be a single application that allowed mapping and analysis at local and county levels. 2.3.9 WISLR Project Development WISLR’s development was a result of a partnership between WisDOT and local roads and streets councils. WISLR was championed by the Division of Transportation Investment Management (DTIM). WISLR began in 1997, was sponsored by WisDOT and approved through its’ Page 1 funding process. WisDOT’s organizational culture had an impact on the development of WISLR. WisDOT’s districts are for the most part autonomous; thus WISLR’s development, functionality and updating had to be minimally invasive. Requirement and process modeling for WISLR involved districts, other state agencies, local governments and WisDOT’s central office including BAS. WISLR became envisioned as WisDOT’s corporate data model. The project charter document identified 15 key improvements. Many of the improvements were non-WISLR functions. Several challenges arose in developing WISLR including lack of resources, technical issues, changing organizational priorities, and upper management support. Little in-house resources and technical expertise were available for this project; the agency used consultants for project management and development. The agency changed contractors during the development process. Continuity between project management teams and lack of project documentation slowed the development process. Consequently, many deadlines were not met. Finally, some functionality included in the original data model was cut and an incremental approach was adopted. WISLR was designed to be a client server application that connected to other databases in real time. Some connections are dynamic links, while others are not. WISLR uses 14 WisDOT legacy Chapter 2 Asset Management System Case Studies 21 Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach Chapter 2 Asset Management System Case Studies 22 and non-legacy servers that all have to be running for WISLR to work properly. Due to unreliability of some legacy servers, point-in-time copies are made. Copies of WISLR data are produced and distributed to users every quarter. Updates on WISLR’s road geometry and mileage (additions/ subtractions) are performed annually. The WISLR application brings together multiple hardware and software technologies. WISLR uses Oracle and DB2 for the database management, ESRI’s SDE for GIS functions, and Java for the programming language. Specialized tools were built using PL/SQL to work directly on top of WISLR’s 140 Oracle tables. WISLR also uses internet technologies (i.e., extranet) for output functions. The quality of spatial data in WISLR uses varies. As a general rule, the developers use the best available cartography from the local governments. Over two and a half years were spent in preparing the spatial data. The cartography varies in scale, quality, currency and ownership. Attribute data is stored on topologic links, not cartography. A user survey found that training requirements for WISLR’s end-users would be much greater than anticipated. As a result, efforts in deploying WISLR were slowed down and WisDOT’s districts and central office are more involved. 2.3.10 WISLR Outcome Measures, Evaluation and Results A brief study looked at functionality, performance and intended value delivered for WISLR but costs weren’t included. No formal cost/benefit analysis or time-in-motion studies were performed. 2.3.11 Status of WISLR WISLR is operational and available to many local governments and all WisDOT districts have full access. It is being used for inventory and administrative data, reporting and mapping. Most of the improvements outlined in WISLR’s project charter have been accomplished. Future plans for WISLR include linking with Meta-Manager and 18 other WisDOT databases. WISLR’s data model was designed to link with these databases, but schedule is set. With the incorporation of pavement ratings into WISLR, it is anticipated that performance of local roads expenditures can be evaluated. WisDOT and local governments will be able to download data into PASERware to perform pavement analysis and forecasting. Synthesis of Accepted Practices for the Development of an Integrated Data and Information Management Approach 9/30/08 Chapter 3. Matrix Results of Case Study and Interviews This Chapter summarized finding from the agency interviews. As the Research Team reviewed the notes and transcripts from each interview, findings were organized into a matrix. Each matrix has 4 rows as follows: • Accepted Practices: practices that work well for each agency. • Lessons Learned: unexpected problems that arose along with suggestions for how to avoid them. • Critical Success Factors: practices or circumstances that can be attributed to the success of the project • Gaps/ Thinking Beyond: next step, directions or opportunities for the agencies related to the applications The information regarding Accepted Practices, Lessons Learned, Critical Success Factors and Gaps/Thinking Beyond gathered from the interviews were organized according to three perspectives: top management, IT department, and business manger. Accordingly, each matrix summary has 3 columns; one for each perspective: • Strategic (Top Management) • Information systems and technology planning and management (IT Department) • Application Developer (Business Manager) The Summary matrices are in Table 2 through Table 10 on the following pages The findings in the summary matrices, along with accepted practices and key success factors found from a literature review, are organized into three chapters; one for each perspective: strategic (Chapter 4), IT management (Chapter 5); and application development (Chapter 6). Chapter 3 Matrix Results of Case Study and Interviews 23 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Table 3. Matrix Summary: Michigan Transportation Management System (TMS) Application Development Team (MDOT-2) Strategic IT Application Accepted Practices • Maintain executive management support changes in technology and re- engineering of processes. MDOT followed through on the planned commitments, requirements and design of TMS despite changes in ISTEA mandates. • Have executive management provide general directives. MDOT top management gave the direction for development and asked the team to keep the system simple and development time short. • Direct best practices in system development. Upper management insisted on checking on research and lessons learned from previous data integration efforts to make sure new development is not isolated and duplicates what exists. • Leverage business mandates and hardware replacement cycles to undertake major IT data integration projects. • Perform formal process and data modeling. MDOT strongly believes in formal modeling for all systems. • Create an in-house data team of core, main and peripheral users to identify and document business functions. • Manage databases, systems and changes through teams. Team from different venues that were representative of the management systems was used for TMS development. • Prevent data misuse/legal issues by letting data owners control the security and views of their data. • Develop consensus through team communication on core data and functions to be supported. (Non-core data and functions can be included in future development efforts.) • Create an Information Technology Operation Group (ITOG) that reviews IT proposals. The ITOG at MDOT works to make sure the proposals are compatible with existing systems and infrastructure. • Using prototyping techniques to overcome communication barriers with contractors. • Re-engineer processes based on data • Develop a single integrated management system that is usable to everyone instead of building stovepipe silo systems. • Build a database system so that people can go to the source, not store it twice. Have management systems query the same data. Currency of the data is maintained with interactive capabilities from mainframe to client- server. • Select data owners from business areas that are responsible for data correctness and currency, so that people talk with those who know their data, not database administrators. • Integrate business and technical teams on developmental efforts. Having business and technical work together as a single team result in better understanding and better decisions. Chapter 3 Matrix Results of Case Study and Interviews 26 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application needs, improved performance and anticipating staff reductions. Have a quality control office that helps with re-engineering efforts. Lessons Learned • Anticipate problems with data ownership from user groups. Organizational and personal issues may prevent sharing data with the belief that data may be misused. • Letting end users define goals and directions may leads to systems that do not satisfy strategic business needs. Many of the things that were asked or included in pilots for TMS didn’t get built. Add reality to visionary efforts because not everything can be built. • Avoid “flavor of the month” strategic directives from upper management. Identify strategic initiatives and commit. Avoid changing employees focus and assignments based on priorities for that moment. • Being ahead of current technology in system design and development can lead to serious gaps that affect system acceptance, use and expandability. Critical components such as GIS were left out of original TMS development • Include in-house technical staff in system development along side contractors. Because in-house staff did not have the knowledge of client server technology, contracts with consultants had to be extended for training. In house staff should be capable of maintaining the system. • Depending on the scope of the IT project, significant time would be spent in user interaction in deciding what to do, what should be done and how it should be developed as a single integrated system. • Anticipate resistance and participant drop-outs due to not wanting to give up existing referencing systems that they are comfortable with. For maintenance of multiple LRSs additional compromises have to be made and conversion tools have to be developed. Critical Success Factors • Select and standardize on a linear referencing system that is applicable to all federal aid roads is critical in getting different systems integrated. • View data as a corporate asset that anyone can get at with few restrictions. Think about data integration as business issue not a data or IT issue. Chapter 3 Matrix Results of Case Study and Interviews 27 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application Gaps / Thinking Beyond • TMS supports inventories and analysis. Budgeting and programming are done differently with other programs. Link these systems for better decision making. • Update management systems to reflect business models (e.g., Pontus), new technology (e.g., Oracle Spatial and web forms), and new organizational structures. Also reevaluate management system mechanisms, implementation and results. • Include pavement management function in TMS. Chapter 3 Matrix Results of Case Study and Interviews 28 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Table 5. Matrix Summary: Ohio DOT Top Management (ODOT-1) Strategic IT Application Accepted Practices • All systems are regarded as agency- wide strategic initiatives. • Systems are driven by business needs. • Strong business imperatives provide incentive for employees to participate in development and use of the system – e.g. system output is used by ODOT to measure progress in asset management program. Employee evaluations (and raises) are tied to facility performance as determined by the asset management system output. • CIO and staff function as business analysts. • Tie technology decisions to business processes. • IT Department focuses first on business process solutions then on technology solutions. • IT Staff takes care of IT infrastructure (i.e. software /hardware / technology) and the business processes for the entire department. • IT Department views agency as a business to be supported; change in perspective from focus on managing and maintaining agency’s technology and data. • IT Department organizes interface metadata through user advocates. • IT Department has responsibility to examine relationships between strategic initiatives and existing and proposed business processes to identify impacts. • Cross-organizational teams of users, data owners, and IT staff work together to analyze business processes (then look at existing systems involved). • System development starts with Charter or protocols specific to the project including outcomes and team members. • Standardized project documents. • Incremental development approach for large projects. • At each incremental stage, have sign- offs, status sheets, and milestones with inflexible dates. Lessons Learned • The underlying location referencing system (BTRS) that provides structure for integrating asset management systems should have been a strategic initiative instead of an off-shoot. • Central office had to become • Evolution of IT Department’s strategy for system development is expected to take 4-5 years. Change from focus on solution to focus on business process requires operational changes in money and staff and cultural changes. Chapter 3 Matrix Results of Case Study and Interviews 31 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application autocratic to unify dissimilar district business processes for project planning. Dissimilarities prevented accomplishment of strategic initiative. • Recognize that strategic initiative for asset management impact multiple organizational units. Critical Success Factors • Asset management system outputs are measurable and explainable to the public and legislature. • Executive level management has ongoing involvement in strategic initiatives. Staff understands that management is fully committed. • Communication to keep everyone in sync and informed. Frequent meetings. • Clear message that executive management has no tolerance for silos and territoriality. • Employees become advocates, take ownership and train users. • Get “designated owner-users” to champion systems so that IT Department can be in the background facilitating. • IT Department has it own funds to work on project. • CIO has good relationship with Executive Management so that there is not a great deal of “selling” strategic initiatives. The question is more of prioritizing. • Dedicated staff time to being a team member on strategic initiatives. Requirement is to be hands-on “designated owner-user” not just oversight or awareness. • Designated owner-user has responsibility to populate databases and for operational quality control. Gaps / Thinking Beyond • Evaluation of development project performance is measured by change (improvement) in infrastructure system performance. Chapter 3 Matrix Results of Case Study and Interviews 32 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Table 6. Matrix Summary: BRTS Development Team (ODOT-2) Strategic IT Application Accepted Practices • BTRS started out with a charter drafted by senior leadership on what they wanted to get from the system (i.e., expectations) along with a strategic initiative defining what the department was going to do. The charter helped get the project going. • Senior leadership sponsors the effort, gets involved early on and gives guidance. Quarterly progress reports keep senior management aware of progress and resources expenditures. • Initially when the project started there was more involvement from top management to make sure the project went right. • ODOT wanted a central location for storage that everybody could access. Most cost effective choice was data warehousing approach. Two reasons: 1) ODOT already had the technical environment for a data warehouse; 2) ODOT had data in many difference sources (back systems, on-line systems, mainframe, UNIX, legacy systems were not eliminated). • Technical choices were a matter of compromise - not dictated. • IT Department was brought on board purposely from the beginning as an equal partner in planning for BTRS. IT was involved in the steering committee and all aspects of planning, managing and execution. • The IT Department manages the data model for the warehouse repository and the interface metadata between systems. For new projects, the IT Department looks at the databases in place for data integration points with other systems, i.e., people database, money database, highways database. ODOT keep a list of 25-30 common integration points between application systems. • Besides accepted metadata standards across the organization and collecting • Projects have a cross-functional Steering Committee that drives the day-to-day project operations based on the executive mandate. • At the start, focus on determining the business case, business rules, and system requirements. • People on project development team share the project work. It is clear up front that everyone buys-in to the project and that the project work is their job responsibility. Make sure everyone is aware that there is a lot of work. • Steering Committee identifies cross- functional business needs. Additional information was gathered from user surveys or by sub-committees that do analysis of areas (e.g., referencing). The Steering Committee has the final approval of detailed work by the sub- committees. • IT Department did a preliminary gap analysis. Departmental Tech Services surveyed users on what they needed from the system and accuracy requirements. • Steering Committee determined standards for integration (tables, attribute names, sizes, domains, and links). Chapter 3 Matrix Results of Case Study and Interviews 33 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application process opened the lines of communication where in the past the groups worked independently. Both groups realized they had a common mission and cooperated in the development. • “User champions” in each particular area are critical since IT Department and Departmental Tech Services don’t have complete knowledge of the data. referencing systems, but all had problems with data integrity, domains and consistency. • Also have a formal process for updating the LRS. • Communication and participation are critical-get people who are using the data to have input in making decisions. Gaps / Thinking Beyond • Metadata requires a tremendous effort in maintenance. ODOT is looking into tools that allow integration of metadata. Chapter 3 Matrix Results of Case Study and Interviews 36 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Table 7. Matrix Summary: ELLIS Application Development Team (ODOT-3) Strategic IT Application Accepted Practices • Systems reflect organizational alignment. The old project management system was built to support a centralized project development approach (e.g. districts submitted projects to the central office and central office would pick the program). Now, program development is decentralized; districts make more decision and are accountable for performance. Each district has their own allocation and develops their own program. ELLIS supports the decentralized project management through system performance measures. Each district delivers a program in certain parameters, maintains certain condition levels, and meets expected OPI levels. • Use of consultants: (1) Do system analysis/ requirements in house with user/owner involvement. 2) Build relationship with consultants. • Create and post “readme” files to explain the meaning of data when users ask for clarification. • BTRS was kept simple so that all can understand it and it could be maintained in-house. • Data quality and consistency. Create a cross referencing database (look-up table) to manage the numerous linkages and integration points so all applications share data. Instead of building a reference table for each system, one referencing table is used that is common to all systems. • Metadata: document all attributes, data types and embedded business rules. • Measure success of system development project by ability to better manage highway assets (ability to measure success of highway program development). • Measure success of system development project by user’s ability to adapt to business process changes. ELLIS was identified as being easier to work with given the flexibility in data entry and reporting compared to the previous standard project templates. • Often users don’t know what the information means, resulting in potentially misreporting information. A workaround is to use of standard Chapter 3 Matrix Results of Case Study and Interviews 37 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application reports and directly using data versus using cuts of data. Lessons Learned • BRTS should have been a strategic initiative. BRTS was to be an interim solution to get legacy data correct and as a mechanism for yearly updates. (BTRS cost little and was done in- house.) Before BTRS, ODOT could not translate latitude/longitude coordinate to a roadway location. BTRS was not designed for production, though most of the data linked to BTRS is updated daily. Now a major problem with BTRS is database management. Any type of new enhancement is anticipated to take significant time and effort. • Need to establish set success criteria, measuring costs and benefits, and holding people accountable. If Cost benefit analysis is not enforced, Costs are not measured all the time. • ELLIS is a desktop application with no restrictions to access. Business rules were needed (and are being developed) to check queries to prevent bad data from being entered and to ensure correct use of data. • If consultants are used for specific knowledge, arrange for consultants to hand off and train in-house people so that the consultants are out the door in 24 months. In-house staff should work side-by-side with consultants. • Do a time and cost analyses of effort and money needed to use consultants versus training and using in-house staff. • As a result of using contractors for ELLIS, ODOT is tied to technology and consulting services that are very expensive. ELLIS could become a single point of failure that only consultants know how to solve. • Until ELLIS, prior attempt at redoing the project management system failed because scope was too broad and comprehensive. They had over 70 meetings and 15 groups, none of which worked together. ELLIS was developed incrementally, having one team and with district involvement. • With hard deadlines for project completion, “user-owners” get forced to prioritize and make data quality concessions. Critical Success Factors • Upper management support. DOT director announced ELLIS as a priority and freed people physically from their current jobs to work on it. • OPI measures have been critical in getting data accurate. The view was that if it gets measured, it gets more accurate. Someone is getting evaluated on it. • When using consultants, agency IT group must act as constant “watch dogs” over internal and external standards choices, data types, naming convention, integration points, etc. Agency IT group must have the final say. • Geographic Query Language (GQL) is used for queries and reports in ELLIS. The GQL tool has all the attributes and attributes metadata built • Instead of trying to tweak software, ODOT took a step back and tried to identify the business processes first and were able to determine what they really needed. The approach was to think process, not solutions. • Involve all key users in defining system requirements. • District involvement was a key factor for success. The districts were integral in the whole process. District Chapter 3 Matrix Results of Case Study and Interviews 38 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application resources. • Development through BAS (without Page 1 funding) has disincentives since division or bureau with the business need must fund data integration costs for other participating divisions and bureaus. Consequently, the divisions and bureaus tend hire consultants to develop warehouse solutions, described as trials, test cases or “pilot projects”. The pilot projects are described as a means to build the business case for an agency-wide Page 1 project. • End users also drive the need. They see technology out there and say if we can’t do this in a big step, why don’t we take a bite of it, try it here, put the parameters together and work towards a Page 1. • COTS (one-size fits all) works better for engineering tools because engineering work has some uniformity, but not applications with business rules governed by legislature (e.g. DMV). • Business managers perceive the ITOG/TMC review and Page 1 approval processes as slow and frustrating. End users do not want to wait for the decision makers to get a perfect system. Business managers are satisfied with intermediate technology with BAS. For example, to use GIS you had to be classified as a master GIS user. Now GIS people are spread out into the organization and GIS is slowly emerging to become a common desktop workstation application. • Impact of technology fundamentally changes workforce and work processes (employee classifications, IT access). The classification and staffing have fundamentally transitioned from a labor-intensive organization to a technology smart organization. Bottom line, the agency increases technology investment through positions. • Bad points about decentralizing IT operations: 1) causes redundant and incompatible IT infrastructure and maintenance, 2) causes need for more people with IT skills. • Good points about decentralizing IT operations: 1) freedom of choice, 2) avoiding obsolescence and can make system advance without barriers. • Technology is moving so fast that if you try to invest in the big system, before you could get it implemented, it is obsolete. • Strategic planning effort (ISP) 12 years ago created master plan and enterprise model and lead to the • In-house developed systems tend to have better acceptance because they are compatible with the business culture. Contractors do not understand the business or business culture. • Hidden costs of proprietary systems. When a COTS product is bought and modified, staff spends as much time modifying as would have spend developing and benefits of upgrades cannot be realized because system was modified, thus additional maintenance is required for each upgrade. • People hate doing data modeling. But when they have used the model for a while, they wished they had spent more time on it. Chapter 3 Matrix Results of Case Study and Interviews 41 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application solutions as a basis for getting to the next level. creation of agency’s link-site model to integration linear location referencing methods (photo-log, mile points, reference points) and cartographic representations. Much of what WisDOT can do now is a result of the time spent in the 90’s through the ISP to create link-site. • BAS does not have base-funding for new initiatives; BAS needs to find sponsors within the agency (central office or districts). • Page 1 process and the use of technical oversight committees (i.e., TMC and ITOG) are critical in getting projects approved. Critical Success Factors • Managers must have the ability to see the big picture and long-term benefits of data integration. • Do not outsource an entire project. • Having a corporate standard for location control is essential for integration. Establish control to make sure everyone adheres to the referencing system. • Developers of Meta-Manager experienced frustration with districts having data that could not be integrated. The referencing system has to be flexible to meet a wide range of users needs. Gaps / Thinking Beyond • WisDOT administrators say the agency is past the point of getting information and data. They have struggled with how to collect data, get • The ISP became labor intensive to keep up and has partially fallen by the wayside. BAS feels the need to do a new mega kind of architecture. • In the past, many project were inventory based, i.e., how many roads or bridges and their condition. Now most projects support decision Chapter 3 Matrix Results of Case Study and Interviews 42 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application it right, put it together and support it. Now the agency is taking the next step to make decisions based on that data. • It’s another decision-making layer in thinking about how to use integrated data in the context of a transportation community across different government organizations. • There is a Page 1 proposal to assess alternative ways to link photo-log miles to the link-site model. making such as taking data from several locations and put them in a warehouse. Data that didn’t co-exist is brought together to help make decisions on managing projects and setting priorities. Chapter 3 Matrix Results of Case Study and Interviews 43 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application components include needs analysis tools that will allow states to say, “If we invest this level of resource in our pavements or bridges, here is what our pavements or bridges will look like in the future.” Chapter 3 Matrix Results of Case Study and Interviews 46 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Table 10. Matrix Summary: WISLR Application and Database Development Team (WisDOT-3) Strategic IT Application Accepted Practices • Clear tie to current management needs (e.g. GTA inventory and certification process) • Consider complementary relationships with other business systems, (e.g. Meta- manager for state roads and WISLR for local roads) • Data modeling done by centralized data management unit to ensure that application data model fits with corporate enterprise model. • Establish project scope at the onset by involving all stakeholders to identify key improvements to existing data procedures. Use accomplishment of key requirements to measure success of the project. • Establish project benchmarks. • Plan for incremental/phase project development. • Employ a professional project management team for system development. Lessons Learned • WISLR’s business area was inventory and certification but scope of WISLR grew to defining corporate data model. Resource allocation is different on a project level than on a corporate or enterprise-wide level. A challenge was to make WISLR more corporate usable with limited resources and time without hurting core functionality. • Deteriorated performance of client server application that connects to multiple databases in real time. • Problems with proprietary spatial data sets: licenses restricted or prohibited data sharing and proprietary data models impede the ability to update/correct cartography on the fly. • Identify bigger ticket items (i.e., software environment, network, and infrastructure) upfront and address those head on results in fewer headaches. • When possible, use prototyping tools. • Plan for transitioning when changing project manager • Contacting other states for best practices. • Use incremental development approach • Outsourcing of system development leaves agency without in-house expertise to make modifications and/or enhancements. • After training, users didn’t touch the application since they had to do other work. Newsletters to keep users informed didn’t work. • Lack of basic computer skills among end users was a significant barrier to system adoption. End-user over a certain age and who do not use computers in daily work preferred the paper-based system and resisted adoption of web-enabled GIS with ad- hoc query capabilities. • Project staff had multiple other responsibilities; requirements to reconcile, certify, answer questions, Chapter 3 Matrix Results of Case Study and Interviews 47 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Strategic IT Application to show progress. attend meetings, and do presentations in addition to existing responsibilities in the same amount of time, become a major challenge. • Major challenge was to keep the project team focused and stabilized while transitioning through multiple contractors. • To manage scope creep and prioritize outcomes, look at time, money and resources. Avoid spending time and energy to develop data definitions and integration points that will not be immediately used since they may not be applicable then. It was recommended to look at the big vision and identify small pieces to invest time into that one knows are going to be used. • The project team had no ability to allocate budget priorities to meet changing needs. • Don’t try to build business data and location referencing system at the same time you build the application to use them. Critical Success Factors • Upper management support is essential. Unless upper management to mandates the project people are not willing to give, compromise or do a little extra work so that others could use their data set. An example given was a failed effort to get divisions to agree on corporate tables for CVTs • To better manage resource allocation (people and money), resource modeling should include time commitments of staff, districts and central office • including data acquisition and cleaning, data management, and the funding sources. • Slow down aggressive deployment and support development of a formal training program when dealing with resistant end-users. • GIS with web interface allow centralized development and maintenance for distributed users. Chapter 3 Matrix Results of Case Study and Interviews 48 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach the ISTEA systems is a low priority. The agencies realize low return on investment for enhancing the asset management capabilities of the individual systems. Instead, the agencies are going beyond minimizing long term costs at the individual asset level to optimizing system wide investment. In making system and technology choices when the catalyst is compliance with legislative mandates, agencies usually can purchase and customize COTS (“commercial off the shelf” or one-size fits all) tools or develop a customized system. COTS tools are usually easily adaptable for engineering applications because engineering work has analytical uniformity. However COTS tools do not work as well for applications with business rules governed by legislature (e.g. DMV). The custom modifications are expense and because the tool is modified, that agency cannot take advantage of standardized software updates. 4.1.3 Prioritization of System Integration Initiatives Agency divisions may have different ideas about what data integration initiatives are important. A major challenge is for top management to narrow down and prioritize strategic systems initiatives. Too many strategic initiatives, especially if they are not aligned, may actually be fixes to perceived gaps. Upper management should avoid confusing strategic initiatives with the busy work of problem solving. Another reason to limit the number of concurrent initiatives is that business managers and staff employees must participate on strategic initiatives in addition to their regular business responsibilities. In addition, IT staff gets pulled in too many directions. Without knowing what is really important employees loose sight of direction. It is clear that multiple concurrent efforts lead to incomplete and less satisfying results. Having a formal and structured project identification and prioritization process leads to initiatives with high return and lasting value, but the process has to be quick and efficient. Business managers perceive these reviews and approval processes as meddling, slow and frustrating. The situation is exhausting if the approval process is lengthy and time consuming, the project scope and duration get expanded to satisfy related corporate needs and the proposing business area is required to pick up the check. Business managers do not want to wait for the perfect corporate system; they are satisfied with intermediate solutions as a basis for getting to the next level. 4.1.4 Project Scoping Successful initiatives start with high-level project documents that clearly define the motivation, goals, objectives, expected benefits, and system use. At ODOT, strategic initiatives start out with a charter drafted during management retreats by senior leadership and describing what they wanted to get from the system and how it will be used. Senior management in transportation agencies have to be careful about biting off too much. The agencies recommend initiatives that can be accomplished within 2-3 years as the right scope. The project charter guides and grounds the development. By sticking with the charter the development teams sticks to the scope as envisioned by upper management. The charter reinforces the objective to build a business system not a corporate database. Without a clear charter mandate from upper management, it’s easy to get bogged down with all sorts of extra baggage. WisDOT says it well, “Technology is moving so fast that if you try to invest in the big system, before you could get it implemented, it is obsolete.” Chapter 4 Organizational, Political and Executive Structures 51 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach 4.1.5 Business Imperatives A business imperative is a stronger driver than a business need. There are alternative ways to satisfy a business need while an imperative obligates a particular way that is system usage. Agencies have buy-in for a strategic initiative when employees become advocates, take ownership, use the system, and train users. A strong business imperative includes an incentive and evaluation structure. At ODOT, the business case for outcomes was articulated by tying pay raises and careers to meeting those outcomes. Employee evaluations are tied to facility performance. At ODOT, each district has a certain allocation of money, with broad latitude to save and invest. The central office gives them very clear outcomes that mist be achieved with their money. In other words, ODOT central office says, “We want pavements and bridges, etc. in this condition; want it done with a certain amount of money, and want quarterly reports on how you are doing to get there.” Each district is compared with others on 70 performance measures. The cost accounting system indicates what it costs each district to achieve that level of condition. If the agency uses the system to measure performance, there is an incentive for employees to use the system. If districts don’t populate the equipment management system correctly, their costs look high and they get dinged every quarter. Sooner or later, the districts get adept at using the equipment management system. If you are an employee and the agency is going to measure your performance, you want to make sure the information being used is correct. District directors have a big incentive to adjust business processes to make sure their roadway and project information gets entered correctly and on time. At ODOT, facility performance is tied to employee evaluations and raises. This has had a tremendous psychological effect; no one wants to get the low end raise. As a result, employees are involved in the system development and use. It has worked so well, ODOT will not invest in a strategic initiative unless there is a clear business imperative to use the system. Without a business imperative for a system, there is no point in developing it. If there is no incentive to use the system once it is created, then the agency runs the risk of system atrophy. High-level project documents must clearly identify business imperatives that will ensure the system gets used after it is created. Identifying and communicating the business imperative upfront is also a good way to get stakeholders and end users to cooperate and participate in system development. As soon as employees recognize the impact on their job they become more interested in providing input. 4.1.6 Commitment and Support of Top Management Senior leadership must be able to see the big picture and long-term benefits of data integration. Leadership’s ability to view IT systems and infrastructure as assets, not costs is critical to realizing their importance to the organization. Leadership must be able to envision the agency’s future as a result of the strategic initiative and to actively support the initiatives by communicating that future. Executives and business managers need to support IT initiatives and act as catalysts for change. Staff needs to understand that the initiative is an agency priority and communicating that message is important. Executive management explains major initiatives by saying, “this is the goal we are trying to accomplish and this is how we are going to do it.” Implicitly staff understands that top management is fully committed. At ODOT, the Director announced ELLIS as a priority and freed people physically from their current jobs to work on it. Chapter 4 Organizational, Political and Executive Structures 52 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Upper management’s involvement is essential for success. Senior leadership needs to get involved early and give ongoing feedback. Early involvement of top management ensures the development team understands the charter and gets off to a good start. Agency leadership has to stay aware of progress and the resources being put into the effort. Executive managers at ODOT meet bi-weekly with team leaders of the strategic initiatives for briefing updates and division directors track the progress details on a weekly basis. While the project is underway, executive management has to be willing to step in to address issues, and if necessary send a clear message of no tolerance for silos and territoriality. At one agency senior management had to get involved when the project team could not agreed on corporate data tables and when one organizational unit would not compromise data needs while another was unwilling to take on extra data management. 4.2. ORGANIZATIONAL STRUCTURES 4.2.1 Technology Management Executive management of state transportation agencies should understand the impact that technology can have on delivery of services. The agency’s technology management structure drives the ability to leverage technology across the enterprise. The influence may be explained by the example in Figure 1 which categorizes the technology management structure in state governments as of December 2002 (Kost 2003). The Breadth of Influence axis shows the degree of influence that the CIO has over operations. Key variables for measuring Breadth of Influence include the CIO ’s reporting relationship, authority to create the enterprise architecture and set standards, involvement in IT procurement process, and ability to manage major projects. The Depth of Support axis indicates the CIO’s ability to manage the execution of IT with key variables including ownership of the infrastructure, ability to develop applications, and role in creating the portal (the interface and technology to tie together multiple related, but independent, content pieces or transactional applications). The quadrants in Figure 1 indicate the various technology management positions of the CIO (Kost 2003). In the Strategic quadrant, the CIO is has considerable influence and capability. For the example of state government, the CIO reports directly to the governor, chief financial officer, or chief administrative officer. A strategic CIO has direct responsibility for operations of the data center, capability and authority to create and enforce architecture and standards, capability to provide application development, and management authority for the content and operation of the portal. The CIO in the Influencer quadrant reports to executive management and has approval authority over IT procurement and standards, but has little operational authority or responsibility for application development or the information portal. The CIO in the Utility quadrant is technologically skilled and provides services but lacks the clout or responsibility influence operations. The CIO’s role in the Transitional quadrant is evolving. The CIO provides some oversight and services but not integral to day-to-day operations. The Transitional CIO lacks clout and responsibility to influence operations as well as authority to control and create architecture, standards, and infrastructure. Organizational structure is one of two significant factors in determining the success of IT management (Kost 2003). First, the structure of the CIO’s position must support the goals and objectives for IT management. The other factor is the attributes of the CIO. A talented individual may not be successful if the organizational structure is not enabling. Chapter 4 Organizational, Political and Executive Structures 53 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach test cases or “pilot projects”. The pilot projects are described as a means to build the business case. MDOT’s IT budget is about $26 million annually. Five million is for development of small projects, the rest is for ongoing costs of hardware, software, and maintenance. Major projects (e.g., project accounting and billing system) get separate funds. 4.2.5 Centralized versus Decentralized IT Services The provision of IT services may be organized as centralized or decentralized. Within a single state transportation agency, IT services may be coordinated through a single unit or each business unit may have their own IT staff. In Wisconsin, the highway patrol and motor vehicles are departments in the DOT, which makes access to safety data, especially accident data, and citations easier. Among agencies in a state government, IT services may be coordinated through a single agency or each agency may manage its own IT services in a centralized or decentralized manner. Whether within or among agencies, the tradeoffs of centralized versus decentralizing technology are similar, but at different scope of impact. Decentralization can lead to limitations in the IT infrastructure and integration across systems because each agency or business unit establishes and supports their own without consideration for development or compatibility with other agencies or business units. The result may be both redundancy and incompatibility but the advantages for some agencies or business units is freedom of choice and ability to make advances as new technologies become available. MDOT’s IT services were moved to the Michigan Department of Information Technology (MDIT). After the centralization, development engineers from MDOT work with system managers at MDIT on project initiatives. The development engineers no longer represent an individual or business unit at MDOT; they represent the agency as a whole. Participants notice a better understanding and definition of projects and a group ownership for projects. 4.3. ROLE OF THE CIO AND EXECUTIVE MANAGEMENT The role of the CIO depends upon the technology management structure. For all management structures, some best practices include: The CIO functions as a business analyst. The staff focuses on engaging business authors to help them understand the business functions and processes. The IT staff’s primary objective is to solve business process problems not create applications. Teams of business and technology people meet regularly and work together across organizational units. The CIO empowers them to make all decisions on the data issues for their databases. The CIO acts as the final arbiter. Communication and frequent meetings keep everyone in sync and informed. The CIO acts as a “champion” for systems integration and data sharing in the organization. The CIO updates top management on IT opportunities and limitations. On many projects the Director of DOIT works with the department director to articulate or understand the motivation for these projects. The CIO participates in committees of AASHTO, TRB and other national organizations to keep aware of national trends and gain ideas to help formulate goals. Through those committees, the agency gets the ability to influence national development projects. Chapter 4 Organizational, Political and Executive Structures 56 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach 4.4. ADDITIONAL OBSERVATIONS The agencies asset management systems provide the structure and decision framework using performance measures. Examples include BTRS at ODOTs. Asset management programs are based on performance measures. Performance measures are needed to measure costs and benefits and to determine the criteria by which success is measured. These factors are also essential to establishing accountability. Managers need to be able to look at spending and calculate returns and determine who is accountable for results. Outcomes must be measurable and explainable to the public and legislature. Returns based on the system condition are tracked. Need to establish set success criteria, measuring costs and benefits, and holding people accountable. If Cost benefit analysis is not enforced, Costs are not measured all the time. • An essential part of asset management is performance and being able to look at where you spent your money and see if you got a return. ODOT does not do complex cost/benefit analysis. ODOT ranks projects based on precursors of benefit/cost analysis (e.g., v/c ratios, accident rates, ADT, etc.). Those precursors are very measurable and explainable to the public and legislature. • Measures of success: ability to monitor highway programs better and at a detailed level and to adapt to changes quicker. • As a result of ELLIS, ODOT observed that they have fewer people and still get things done. It was believed that much of that was due to internal optimization at each district. Now it was the districts’ money, they needed to determine how to best use their resources and what they want to commit their resources on. It was believed that much of the optimization was due to districts finding better ways to manage their processes. 4.5. THINKING AHEAD The agencies are past the point of getting inventories, tracking condition, identifying performance measures; they are using integrated information to make planning decisions. The next step is to think beyond planning to operations and prediction with analysis tools that will allow states to say, “If we invest this level of resource in our pavements or bridges, here is what our pavements or bridges will look like in the future.” The agencies have asset management systems but hooks and feedback loops to maintenance management, traffic operations, and emergency response management systems are missing and are desperately needed so that agencies can link cost, condition, level of service and performance. The agencies’ asset management systems use performance measures to provide a structure and decision-making framework. The framework concentrates on inventories, condition tracking, identifying performance measures, having business processes to get inventories upgraded, and business processes that improve performance. Once the framework has been established, asset management programs can move from planning and operations to prediction. This can lead to new strategic initiatives and complimentary relationships between systems such as Meta- manager and WISLR in Wisconsin. In Ohio, the success of BTRS led to an unexpected Chapter 4 Organizational, Political and Executive Structures 57 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach opportunity to create a new crash reporting system for entering crash locations immediately eliminating a four month lag between when a crash happens to when it is recorded. It’s another decision-making layer in thinking how we use integrated data in the context of a transportation community across different government organizations. 4.6. KEY SUCCESS FACTORS, BEST PRACTICES IN SYSTEMATIC APPLICATION INTEGRATION In this section, we provide a summary of success factors and best practices in systematic application integration that have been identified so far. 4.6.1 Top Executive Level • Critical role of enterprise-wide view of information • Critical role of information systems plan/architecture (ISP) • Understanding the benefits of data sharing and systems integration • Data integration and data sharing as an important objective, principle in developing new systems • Commitment and support of top management; allocation of adequate resources • A top-level manager acting as a “champion.” The CIO? • Strategy on integration metadata and centralized integration competency center (see below) • Establishing standards for data sharing and integration 4.6.2 Operational and Technological Levels Metadata: The core of enterprise integration architecture (Schulte et al. 2002a, b). • Benefits of integration metadata: Systematic integration strategies aim to reduce the time, cost and complexity of building interactions among disparate and heterogeneous application systems. They accomplish this by using a highly functional middleware integration infrastructure, documenting the application interfaces thoroughly to enable change-impact analysis and by reusing the interface definitions and messages, where possible. • Integration metadata is required for the following purposes. Integration broker suites need metadata to route and transform data between systems. Business process management tools need additional metadata (process definitions) to optimize business processes. Developers need metadata to analyze how to add to or modify the connections among application systems in response to changing business requirements. Finally, metadata enables reuse, probably the benefit that is hardest to achieve • Build an application integration repository that covers all forms of inter application communication, including: XML documents; MOM messages; e-mail messages; method signatures, including Component Object Model (COM), CORBA and Java Remote Method Invocation (RMI) calls; remote procedure calls (RPCs), including those using SOAP; database tables; files; HTML pages; display screen formats; paper forms; and even report print images. Develop a metadata management strategy and implement a centralized integration competency center. Government organizations that are willing to join up services and integrate applications must focus on an effective metadata management strategy. A comprehensive tool for collecting Chapter 4 Organizational, Political and Executive Structures 58 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach restricted. We recommend that the integration competency center move opportunistically and incrementally, gradually expanding the variety of external metadata sources encompassed by the virtual repository. Integration repository projects should be scaled to bring a positive return on investment within one year of completion. This whole process is a learning experience, not just for an individual enterprise, but for an industry. An integration competency center must expect to use multiple software tools and do some custom design and development. Bottom Line: Government organizations that are willing to join up services and integrate applications must focus on an effective metadata management strategy. This must be based on creating a relatively small repository of integration metadata not already held by individual repositories, and on incremental development of an exchange information model and metadata. The establishment of a government wide integration competency center as part of the e- government program office will help. The center should liaise with competency centers owned by larger departments and agencies, as well as with staff involved with e-government initiatives in smaller departments. Integration repository projects should be scaled to provide a positive return on investment within one year of completion, by reducing data duplication, conflicts and errors. • Enterprises should try to minimize the individually designed point-to-point application interfaces that impose a significant maintenance burden, particularly in large enterprises with many applications (James 2002). • Adopt an industry standard for building and maintaining the integration links among heterogeneous systems, such as XML and Simple Object Access Protocol (SOAP) • Develop a strategy on using specific integration-related software technologies, such as message-oriented middleware (MOM); business process management (BPM) tools; extraction, transformation and loading (ETL) tools; and integration broker suites (e.g., IBM’s WebSphere MQI, Microsoft’s BizTalk, SeeBeyond’s e*gate, Tibco Software’s ActiveEnterprise, Vitria Technology’s BusinessWare and WebMethods’ Enterprise). 4.6.3 Implementation Level The task of collecting and maintaining integration metadata is difficult, but it can be done successfully. Enterprises that have a central integration competency center will be able to implement some form of central application integration repository. Their development times and costs will be lower than those of enterprises that do not manage any integration metadata centrally (Schulte et al 2002b). Key Issue: What will be the most successful ways to integrate new, purchased and legacy applications? Chapter 4 Organizational, Political and Executive Structures 61 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Tactical Guidelines: Enterprises should manage the metadata for application integration using some form of enterprise wide repository, under the direction of a centralized integration competency center. Systematic integration reduces the need to develop redundant touchpoints with similar purposes. Like other IT reuse strategies, interface and message reuse is hard to achieve for many reasons as listed below. Development Readiness To achieve integration and develop an application integration repository, developers must: • Be motivated to document and make available to others the touchpoints they implement. • Be motivated to reuse touchpoints, rather than build their own new entry or exit mechanisms. • Be able to find previously developed touchpoints without much effort. This is one reason there must be an organized, widely available repository containing interface metadata. Modeling Methodology Integration content metadata can be prepared using simple, traditional approaches to application development (e.g., records and fields) or it can leverage sophisticated approaches that use formal information modeling techniques, such as object-oriented (OO) Unified Modeling Language (UML) models or the ontologies, vocabularies and grammars now sometimes associated with XML. Messages themselves are generally hierarchies, for which ontologies can be useful. A formal ontology may begin by modeling a set of concepts and defining a set of unique terms that correspond to those concepts. It can then involve concrete vocabularies (“dialects”) that provide alternative labels (synonyms) for each of the terms from the conceptual vocabulary. It may have yet another level that is the formal specification of the representation of the data — e.g., using XML document-type definitions (DTDs) or XML schema. All new XML messages should be specified using XML schemas (although DTDs are still more widely used because they came first). XML DTDs and XML schemas describe the data transferred through a particular touchpoint (if the touchpoint happens to use XML documents). A collection of DTDs or schema definitions, however, is not necessarily based on a common set of semantic definitions. Although a mechanism for copying definitions across a set of XML schemas is available, the use of this tool is not enforced. Moreover, there is no guarantee that schemas that represent different subsets of the same overall data set have consistent views of the data. Some leading developers use UML, an OO design language, to model the underlying information model for the data that is exchanged. This generally will complement, not replace, the use of XML schemas. UML is better than hierarchical ontologies for representing the network relationships that may appear when working with two or more overlapping message classes. Even a crude version of a repository is useful if it makes it easier for developers to examine the impact of change or to reuse touchpoints into applications. The alternative — no documentation Chapter 4 Organizational, Political and Executive Structures 62 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach on interfaces, or widely scattered and incomplete documentation — is much worse than having an imperfect repository. Use Loose Coupling Between B2B and Internal Business Object Definitions: Enterprise integration strategies will usually have to deal with external (B2B), as well as internal, integration issues. Although having a common exchange information model (e.g., a uniform XML schema) for internal and B2B interactions is theoretically appealing, it may be difficult or impossible to achieve. Indeed, it is often impossible to enforce a single, canonical view of a business object even within the enterprise, but it is more difficult to align the activities of an enterprise with XML grammars and other standards of its trading partners, private or public exchanges, or consortia and standards bodies. Outside organizations may take years to agree on standard XML grammars for a given purpose; the standards, and ongoing changes to the standards, may not match an enterprise's internal timeliness needs or strategic imperatives. It is, therefore, usually impractical to have a direct, lock-step alignment between an enterprise’s internal business object definitions and those of external organizations. External definitions (e.g., a standard XML schema for a business object, such as a purchase order) are often good starting points for an organization's internal XML grammar definitions. The enterprise usually will need to add or modify these definitions to meet unique organizational requirements. It will then be necessary to transform a business object from an internal representation to one or more external “standard” representations. This implies "schema firewalls" that insulate the enterprise from the impact of external changes to XML schemas that are not in its control. This loose coupling for B2B purposes is technically similar to what may exist within the enterprise, as different business units and their respective, heterogeneous application systems employ similar “firewalls” (transformations) among themselves. This is the essence of application integration: dealing with heterogeneity because homogeneity is often impractical to achieve. Organization To the best of our knowledge, no enterprise has a detailed, enterprise wide application integration repository for holding a comprehensive exchange information model. Today's repositories are project-based or, at best, multi-project but still limited in domain (limited to a particular IS group or set of applications). This just reflects the fact that integration, in general, continues to be done in a fairly piecemeal fashion. This is changing a bit as developers migrate toward the notion of the enterprise nervous system (Schulte et al. 2001). Having an integration competency center with an enterprise wide scope manage the exchange metadata can be extremely beneficial. A centralized group can reduce overall training costs, because: 1) fewer people need to know the details of integration middleware tools and shorter development cycles; and 2) the people involved have more experience with the challenge of dealing with heterogeneous applications. It also promotes the use of enterprise standards for business objects sent between systems (canonical messages). For example, an enterprise may be able to use one XML-based standard for purchase order documents across multiple application systems, rather than having five XML formats for purchase-order documents, each invented by a Chapter 4 Organizational, Political and Executive Structures 63 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 4 Organizational, Political and Executive Structures 66 additional, practical technique is to base the design of each message on a business object (e.g., example, customer, invoice or purchase order). Integration metadata is a superset of protocol-specific metadata held in specialized tools such as a CORBA interface repository or a Web services Universal Description, Discovery and Integration (UDDI) directory. It does not document the data model used within application systems. Each application system is considered to be encapsulated in a “black box,” its internals unknown and irrelevant. Integration is only concerned with the externally visible behavior and the “exchange” information model (i.e., the metadata pertaining to information that is communicated to and from sources and destinations outside of the application system through integration touchpoints). Integration metadata contains information about the communication content, the touchpoint identities of the senders and receivers, and the interaction process mechanics and business implications. However, once it gets to the technical stages, the process becomes easier as the typical technical details will become the main focus. This stage is free from considerations of top management buy-in and other organizational issues. Therefore, it is easily under control and can resort to the typical engineering process. Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 5. IT Management and Planning “WisDOT is coming to the second stage evolution of technology, moving beyond acquiring data to making decisions with it. We have struggled with how to collect data, get it right, put it together and support it. Now we are focusing on making decisions based on that data.” Ruben Anthony, Deputy Secretary Wisconsin DOT This Chapter presents discussion of our findings on IT management structure, strategies, and practices in IT project planning, implementation and maintenance among the state DOTs studied. At each agency, the IT department identifies project components planning, development, and then onto maintenance. Different teams model the business processes, identify the systems to be touched, and the gaps or holes requiring solutions. Every project (business process or technology) starts with a charter or protocols specific for the project. The charter clearly defines outcomes and team members. 5.1. PLANNING, MANAGING AND EXECUTING INTEGRATION INITIATIVES AND PROJECTS We start with the role of the IT department in project management and development. This is about personnel (e.g., hierarchy and roles) for strategic planning, implementation, and management of integrated systems identified by the IT infrastructure plan. 5.1.1 Process for Identifying and Prioritizing System Development Projects The most important critical success factor in identifying and prioritizing system development projects is to consider the relationship with business processes, functions and mandates. Without a clear and measurable impact on the agency’s ability to provide core services cross-functional systems integration project cannot be justified. Furthermore because they have agency-wide impacts, these cross-function systems integration and data sharing efforts must have a top level manager acting as the champion. The agency’s executive management team should draw upon the expertise of the chief information officer (CIO). Another important success factor is a strong working relationship between the executive management team and the CIO. The agencies recommend the CIO be part of the agency’s executive management team. The CIO should not have the role of convincing top management of the need for strategic initiatives but rather a role of advising on priority and potential for success. The agencies have slightly different methods for identifying, reviewing, and prioritizing strategic initiatives. Common characteristics include the following: • Upper management creates a vision and series of objectives for initiatives. • Potential projects are collected through an agency-wide Call for IT Proposals. The call includes the vision and strategic objectives. The submitted descriptions for each project identifying what it is to do, what its goals are, and how many users it will have. • IT projects of any magnitude go through an executive management review. The projects are evaluated according to the strategic objectives. • The agency has a cross departmental Information Technology Operations Group (ITOG) that reviews IT proposals to be sure they are compatible with existing systems and infrastructure. Chapter 5 IT Management and Planning 67 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach This review includes a project study (technical and business) that can cost from $30,000 to $100,000. The agencies differ in how they prioritized strategic initiatives and how they make final decisions on what initiatives to study and undertake. The discrepancies are rooted in the source of funding for the study and development. At some agencies, each project requires a sponsor from among the business units and a project manager to champion it. At other agencies, the project proposals compete for agency wide IT funds. One potential problem is having too many strategic initiatives being studied or underway concurrently. This can overburden the business and IT staff. One way of dealing lack of resources for multiple projects is to have well defined scope and cutoff points. 5.1.2 Experience with ISP/Information Framework Development At some agencies, the IT department uses the Information Strategy Plan (ISP) primarily as input in determining the annual IT budget needs and work plan. The ISP should be more than a budget planning tool; it is the integration planning tool. Influence of the agency’s Information Strategy Plan (ISP) on development decisions deserves attention. Status, acceptance and performance of the ISP/framework need to be considered. State agencies have asset management systems but hooks and feedback loops to other related management systems are missing and are desperately needed. This occurs despite past efforts by agencies in creating an Information Strategy Plan (ISP) for system integration. Parts of the ISP can easily fall by the wayside because keeping them current is labor intensive. But having a current ISP can help ensure new systems fit. 5.2. ROLE OF THE IT DEPARTMENT Traditionally the role of IT departments has been in providing core support for the IT infrastructure (i.e. software, hardware, and technology) for the entire department. The IT department set standards for hardware and software and develops replacement schedules. The provision of IT services may be centralized or decentralized. The IT departments at state transportation agencies are taking on new responsibilities in response to the need for cross-functional information systems development. These new responsibilities are in the role of business analyst for the agency. The IT department has the responsibility for examining and managing the relationships and impacts of proposed strategic initiatives with existing and future business processes. 5.2.1 Organization of IT Services The IT operations and services at a state transportation agency include desktop support and telecommunications for the central office, and in some states, the regional offices too. The services cover the entire life cycle of hardware and enterprise software and application systems, including help desk, 1st, 2nd, 3rd tier support, CAD operations, DBMS and the data warehousing. The IT department may also be responsible for the agency’s voice and data telecommunications support and networking. Some agencies centralize the IT services while others decentralize. In some agencies, technical services for IT support are distributed throughout the organization. Each of the functional areas has its own IT services unit. In addition, there is a department-level IT coordinating unit. Along Chapter 5 IT Management and Planning 68 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach acceptance because they are more likely to be compatible with the agency’s business culture. Contractors cannot be expected to understand the agency’s business. 2. The agencies successfully use prototyping techniques to clearly communicate and overcome communication barriers with the contractors. 3. Partner with software developers that are the best in the industry and certified as the highest quality. 4. Outsourcing of the entire system development leaves agency without in-house expertise to make modifications and/or enhancements. Rather, include in-house technical staff in system development along side contractors with the goal of developing in-house expertise of the same quality level. Without this goal, the agency may become permanently dependent on the consultant’s expertise. 5. If consultants are used for specific knowledge, arrange for the consultants to train in- house staff and hand-off the project as soon as possible. For some tasks, such as data scrubbing and maintenance there will be short and long term cost benefits of having the in-house expertise. Training of in-house staff may be included in the consultant’s contract. 6. Allow the IT staff to oversee internal and external standards choices, data types, naming convention, and integration points may arise. (One agency actually used the term “watch dog” to describe this concept.) 5.2.5 Metadata Management Metadata is information about data sources, including how it was derived, business rules and access authorizations. The metadata is crucial for data sharing because it explains the data to new users and provides a way to evaluate whether existing data is applicable for new applications. Metadata requires a tremendous maintenance effort. None of the states had a formal metadata management strategy or repository. One reason identified for the lack of integration-based metadata was the lack of metadata standards across tools. Developing metadata standards and creating a metadata interface are considered the role of the IT department. In addition to accepted metadata standards across the organization, and then collecting metadata, training is important. Just collecting the information and making it available are not sufficient. The states have informal strategies to manage metadata. ODOT organizes interface metadata through user advocates whose responsibility is to work with the data warehouse and populate it. Another strategy for metadata management is the use of “readme” files to explain the meaning of data. These files are created and maintained by the data owner-user within the agency. Overtime, the data owner-users save considerable time by deferring to the readme file when other users ask for clarification. ODOT created a web tool to collect and disseminate questions and answers about data. 5.3. TECHNOLOGY INVESTMENT AND ADOPTION An agency’s process for making technology choices is likely to be one of compromise. For example, at ODOT a challenge in planning for BTRS was the decision to use Sybase over Oracle. The business unit wanted to use Oracle but the IT Department was using Sybase and had Chapter 5 IT Management and Planning 71 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach the tools to do updates and manage standards. The business unit realized that they couldn’t afford to maintain separate databases so they switched to the Sybase platform. One suggestion for making technology investments is to avoid them. The IT department looks first at business processes and works to connect them in the best way without a great deal of financial or technology efforts. But if technology investments are necessary, then tie them to measures for improving business processes. With this strategy, the agency may avoid implementing technology at the request of one business unit but causes problems for another unit. Another issue is risk of obsolescence during system development. Being ahead of current technology in system design and development can lead to serious gaps that affect system acceptance, use, and expandability. Technology is moving so fast that agencies must be concerned about software versions and technology compatibility that may change before the system is implemented. For example, development of WISLR meant that WisDOT needed to bringing together Oracle, for the database, SDE, GIS and other IT technologies. With all the different types of software connecting with WISLR, a major challenge was dealing with software updates and version changes. WISLR used every new technology at WisDOT. The project team had to deal with new development tools, new servers, new GIS software, new programming languages, and new business objects for reporting. Every software tool changed during the project lifecycle. A technically sophisticated workforce can drive technology investment and adoption. Consequently issues may arise from having advanced IT skills that are decentralized throughout the organization but centralized control of the IT investment. For example, to use GIS you had to be classified as a master GIS user. Now GIS people are spread out into the organization and GIS is slowly emerging to become a common desktop workstation application. Impact of technology fundamentally changes the workforce and business processes. The classification and staffing at state transportation agencies have fundamentally transitioned from a labor-intensive, procedure-oriented organization to a technology smart organization. Overtime, the agencies have increased technology investment through staff positions. Two basic approaches for physical data integration are a client server network to create decentralized (interoperable) data storage/access or a centralized (fused data warehouse). Some agencies experienced deteriorated performance of client server application that connects multiple databases in real time because of the dependency on all servers running. WISLR uses 14 WisDOT servers that all have to be running. If each server has 99% reliability, then at best WISLR would be operating at about 80% reliability. If any server slows down, then WISLR slows down. The reliability and speed impacted the adoption of the WISLR system. As a result, the agency decided to run WISLR using point-in-time copies of each application database. Alternatively, ODOT uses a data warehousing approach as the most cost effective central location for storage. BTRS, ELLIS and several other systems (e.g., traffic, construction management, pavement data) reside in the 100 GB data warehouse. The warehouse was the best strategy for managing data from many different system platforms including back systems, on- line systems, mainframe, and UNIX systems. As a result legacy systems did not have to be excluded or replaced. The data warehouse is updated nightly from various legacy systems. 5.4. INTEGRATING LOCATION-BASED DATA Chapter 5 IT Management and Planning 72 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach There are several issues that may arise with data integration involving spatial data. First, having multiple location referencing systems leads to data integration problems if the are no methods for automatically and consistently translating between the systems. WisDOT has three main referencing systems (link-site, state plane coordinates and log-miles) that cause integration problems. The translation between link-site and photo log-miles is bigger problem but the potential is great for richer datasets if the problem is solved. The agencies recommend creating a strategic plan specifically for spatial data along with and related to other IT plans. At WisDOT, a strategic planning effort (ISP) in the early 1990’s created a master plan and enterprise model that lead to the creation of agency’s link-site model to integration linear location referencing methods (mile points, reference points) and cartographic representations. Much of what WisDOT can do now to integrate location data is a result of the time spent in the 90’s through the ISP to create link-site. Currently, they are looking at ways to link the photo-log miles and GPS coordinates to the link-site model. Other issues arise with the integration of spatial and non-spatial data. Project development staff at the agencies recommends not building applications with the location referencing system embedded in the business data. Otherwise, each update to business data may require an update to the location referencing system. ODOT’s BTRS and GIS are connected in this way. The Division of Planning understands for GIS to be successful they need to work with the IT data warehousing people. The IT staff has to go into the system from time to time to fix the data so that GIS can work with the data and present it. People from both divisions understand the importance of working together. The agencies also recommend not undertaking the development of a corporate spatial referencing system as a subproject or add-on to the development of a business system. The main reason is that parallel development can be overwhelming to the project team. The likely result is simplifications to the spatial system that may severely limit its use beyond the immediate application. A rational is that the corporate data model for location referencing and spatial data management should be independent on any particular application. The business system and data would be owned and maintained by business units while location data, location referencing systems, and spatial data are corporate wide. The GIS portion of WisDOT’s WISLR was envisioned to be a corporate data model designed to be the state’s core line work that everyone would use to do overlays. The WISLR project development team concedes that bundling the design and development of the corporate data model for line work with development of the business application for local roads management created a strategic initiative that was too large. In the end, the WISLR application is a success, but the agency did not achieve the corporate data model envisioned. ODOT describes as similar experience in the development of Ellis and the associated BTRS. Data from map vendors is not a good solution. There are several problems that may arise when agencies use proprietary spatial data sets. Licenses may restrict or prohibit data sharing for more than one application and the proprietary data models impede the ability to update/correct cartography on the fly. These are only a few of the problems that may occur. 5.4.1 Managing Spatial Data At each agency, spatial data and metadata are managed centrally within the agency and the IT department has a role in the management. The role of the IT department is in connecting applications to the GIS environment and providing user tools for data integration and Chapter 5 IT Management and Planning 73 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach • Facilitate development of business rules, • Oversee the development of the project documents and keep them updated, • Establish project benchmarks, monitor progress, and resources, • Facilitate the establishment of integration standards and then enforce the standards, • Facilitate communication, and project continuity. 6.2.2 Cross-functional Project Team In addition to professional project management, each project initiative needs a cross-functional team to drive the day-to-day project operations based on the executive mandate. Depending on the project organization, the cross-functional team may be a steering committee, a strategic planning committee or a project team. This project team has the final approval of detailed work. A cross-functional team will be needed to define cross-function system requirements to satisfy cross-functional business needs. The professional management team will be responsible for keeping the project team focused. Additional information, such as accuracy requirements, may be gathered from user surveys, by sub-committees or the IT department. Because asset management draws from multiple agency divisions, a team of business staff, users, and data owners is assembled for the project. Data owners are business staff who are responsible for data correctness and currency. The team integrates business and technical expertise for the development effort. The team has the knowledge and vision of what needs to be done as well as the business expertise. The team makes decisions on managing databases, systems and changes. One agency suggests two sessions for project development meetings: one focusing on the business and the other on the technology. Business and technology people attend both sessions. After the sessions then all participants come together again to make final technology and business decisions. The cross-functional project team involves people who will share in the project work. Everyone on the team should be “on-board” with the data integration initiative, aware that there is a lot of work, and willing to contribute to accomplishing the project objectives as their job responsibility. Being a team member on a strategic initiative means the employee takes on the role of being a catalyst for process improvements. Communication in the project management and system development process is a key success factor. The cross-functional team makes agency-wide communication possible. Being a team member on a strategic initiative involves several important responsibilities including working to reconcile requirements, certifying development products, answering questions, attending meetings, and making presentations. Employees can become overwhelmed if all these activities are expected in addition to their regular job responsibilities. 6.2.3 End-User Involvement Communication and participation are critical. End user involvement is a key factor for success. It is important to get people who are using or will use the data to have input in making decisions. Data quality is critical in getting buy-in and establishing credibility of the system. User may be consulted to draw out information on business processes. It may be a challenge to get the attention of end user who will be affected by the system to provide input. The steering Chapter 6 Managing Date Integration Efforts 76 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach committee may host formal demonstration sessions at various stages along project development to gather feedback. This approach fit well with the use of prototyping. 6.2.4 Resource Allocation Resource allocation and time management are key success factors. Agencies need to plan for the time commitment required from project participants. To manage project resources (people and money), the allocation models must include time for meetings, answering questions, data acquisition, data cleaning, and ongoing data management. To be successful the project participants will need to devote time to the project not only during development but also afterwards during operations. Resource modeling must consider time commitments of data users and data owners during development and for ongoing upkeep after the system is deployed. Also identifying big ticket items up-front and addressing those head on results in fewer headaches. Staff time commitments should be estimated early in the project planning and business supervisors need to be aware. Depending on the scope of the project, significant time will be spent deciding what to do and how. Business staff needs to become team members on a strategic initiative. Their role should not be an add-on to the normal workload, but a specific job assignment. Their job is to be the program owner (i.e., to be catalysts for process improvements). The overall project cost estimate should identify bigger ticket items (i.e., software environment, network, and infrastructure) upfront. Allocation decisions for these should be done early on to avoid serious issues later. It is important to conduct the preliminary cost estimate but also to have ongoing checks to see if resources are being spent and budgeted. On-going checks focus the team on keeping the schedule and lead to early awareness of growing problems. 6.2.5 Managing the Project Scope and Expectations The project steering committee should clearly define the scope as only what needs to be accomplished to successful accomplish the business mandate associated with the strategic initiative. Each agency described failed attempts to integrate data systems because of problems with system scoping. Either the team defined the scope too deeply or they bit off too much. One agency’s project team set out to accomplish a scope much larger than defined for the business mandate. The scope mushroomed to include establishing corporate definitions and identifying integration points for numerous other applications without process models that identified how the other applications fit with the strategic initiative. The project team worked to define functions to make the application corporate compatible. Twenty-eight empty tables were added to make the application compatible for the future. Eventually after much work was done the team pulled back due to time and money constraints. Every time a change was made, those tables had to be adjusted. Along with the extra data tables came requests to add data functions that took time and staff away from the strategic initiative. Additionally, the team was responsible for answering questions and responding to concerns that were generally outside the scope of the original initiative. To manage scope creep and prioritize outcomes, look at time, money and resources. Avoid spending time and energy to develop data definitions and integration points that will not be immediately used since they may not be applicable when they are needed. It was recommended to look at the big vision and identify small pieces to invest time into that one knows are going to be used. Chapter 6 Managing Date Integration Efforts 77 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Managing project expectations seems to be a lesser problem than managing scope creep. To manage expectations, the agencies recommend two strategies. First, communicate a consistent vision. Second, disseminate and refer to the project charter documents as defined for the business mandate. 6.2.6 Measures the Success From the perspective of the project developer, success occurs if the system requirements are accomplished and the project delivers what is promised. However, this measure is not necessarily of the data integration effort. Success of data integration may be expressed in terms of improved ability to manage highway assets or the ability to adapt to business process changes. The success measure for Meta-Manager is the ability to accomplishment a business goals: district compliance with project consistency goals (80% consistence with recommended projects based on ‘right place’, ‘right time’, and ‘right thing’). For WISLR, success is the ability to realize 15 key improvements that were identified during process modeling. 6.2.7 Using Standards and Formal Documentation System development starts with Charter for the project including the business case, outcomes, and cross-functional team members. As the project progresses, expectations can be managed through the Charter and kept realistic. Standardized project documents are important to ensuring smooth progress of the project. They help information sharing and update and keep everyone on the same page. The steering committee develops a work plan outlining steps and procedures, identifying the applications to be convert/integrate and how they will be integrated. The agencies say the approach is not necessarily a classic system development lifecycle. Each of the agencies uses standards for integration (tables, attribute names, sizes, domains, and links). The standards enable the management of data of different formats, from different sources, with different data definitions and owners. There are IT technical standards as well as logical naming conventions. Likely, the committee can agree on business rules but not as easily on integration standards. Some of the most heated discussions with the cross-functional steering committee may be over attribute names and integration standards. In the end, the team will document the business rules for what each attribute means. People hate doing data modeling. But when they have used the model for a while, they wished they had spent more time on it. Managers must understand that by doing a data model correctly, in the long term, all systems will link together. Other important documents track project milestones and progress. These manage the reviews, checkpoints, and deliverables through sign-offs and status sheets. Members of the steering committee or other responsible business staff will need to certify correctness and compliance with business rules. 6.2.8 Location Referencing Methods Having a common location referencing method is critical in being able to integrate systems for asset management. The systems we reviewed all depended upon location-referenced data such as bridges and pavements. They all had problems with data integrity, domains and consistency. Chapter 6 Managing Date Integration Efforts 78 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach • A big challenge may be in getting people not on the project team, whose day-to-day operations would be impacted, to take the time to give input. There may be incentives to local governments to participate such as creation of user tools or simply providing local data and ability to use that data for forecasting, projections and analysis. • Members of the project steering committee should visit the districts early in the project to explain, gather comments, hear concerns, and get buy-in. • For systems that cross institutional lines (i.e., involve local governments, or districts), do a pilot in one organizational entity as a means for getting buy-in among others. An initial version of WisDOT’s Meta-Manager was developed before showing it to the districts. Input was sought and designs were changed as a result of district feedback. 6.5. MANAGING DATA QUALITY 6.5.1 Data Quality Issues Data integration efforts are often driven directly by data quality issues associated with data consistency and currency. An agency may take a closer look at solving data integration issues after it experiences public embarrassment because different units gave conflicting information to press inquiries. The solution is to have management systems query the same data. As data integration efforts get underway data quality issues arise. These relate to data format, bad data, lack of storage capacity, unanticipated financial/time costs, inadequate cooperation from data owners, or lack of data management expertise. End users of the integrated data sets may not understand the meaning of data entities resulting in misuse of data. 6.5.2 QA/QC, Metadata Practices and Policies Data integration for asset management produces the capability to build desktop applications that can access huge volumes of data with virtually no restrictions. Problems with data access may be replaced by problems with data misuse. Business rules are needed to check queries to prevent bad data from being entered and to ensure correct use of data. Another approach is to create standard reports and forms that represent general user views of the data. For each subject area of the integrated database, ODOT designates a “User Champion” to be responsible for data quality and operational control. The User Champion is someone who knows the data, works with the data daily, and can assume the on-going responsibility to populate the warehouse and keep it updated. The User Champion becomes the data manager/owner for that subject area and has an important role of overseeing data quality, creating/managing metadata for operational quality control, and developing business rules that governed new processes on the data. This approach makes a subject matter person responsible for what is entered into the system, how accurate data is, and for developing business rules to enforce use of the system. Furthermore, the business units that owned the data prior to the integration effort continue to do so after the system is complete. The agencies build in some quality control checks at data entry for the operational databases. These are accomplished using consistency checking tools in database management systems. For example ELLIS checks that a road exists and the log point is in the acceptable range for the road before a user is allowed to enter roadway data. Data owners have the responsibility for identifying the consistency checks. Chapter 6 Managing Date Integration Efforts 81 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 6 Managing Date Integration Efforts 82 The metadata documents all attributes, data types, and embedded business rules. While the agencies create and use metadata fields they do not use metadata management tools. The reason cited is the lack of integration metadata standards across tools (i.e., getting metadata from one tool that uses GQL into another using Power Designer). Each of the integration efforts forced the various business units in each agency to come to consensus on names and data types for shared data items. At one agency, some of the most contentious discussions among data users from multiple business units occurred when selecting names of data entities. 6.5.3 Data Quality Requirements and Evaluating Data Quality Data integration efforts to support asset management are driven more by the desire for convenient access to existing data than by the desire to manage new data sets. For this reason, business managers and project managers approach the integration efforts with the notion that data is sufficiently accurate for its intended use. Although the agencies do not develop data quality standards for their data integration efforts, there are concerns about data quality. Data from one business unit often must be scrubbed to make it acceptable for the application needs of another. In the development of BRTS, ODOT encountered reluctance by some data owners to have their data included because of fear related to potential embarrassment about poor data quality. The agency addressed the issue by providing technical assistance for data scrubbing and the incorporation of consistency checking. Development for WISLR included a major data conversion effort. Detailed procedures for data scrubbing and monitoring data quality had to be identified. Quality checks were established to tell if the converted data is clean. With hard deadlines for project completion and limited funding and resources, data owner and users get forced to prioritize and make data quality concessions. A business imperative is a good motivation for data quality. Now ODOT uses the ELLIS system data to make funding allocations and for personnel performance reviews. The agency found that since data is being used, the measures are accurate and get updated on a timely schedule. Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 7. Conclusions During the past few decades, the impact of technology fundamentally changed the workforce and work processes at state transportation agencies. The agencies were continually increasing their technology investment by updating the workforce and position descriptions. The classification and staffing have transitioned from labor-intensive organizations to technology-smart organizations. Data integration is not asset management but it leads to data access, consistency, and currency that support asset management decision making. Asset Management systems are the product of evolutionary IT projects. Until recently, IT projects were inventory based – answering questions like, “How many roads or bridges do we have and what is their condition?” Agencies struggled with how to collect data, get it right, put it together and support it. Now, asset management systems support decision making. Data that didn’t co-exist is being brought together to help make decisions on managing projects and setting priorities. Emerging is another decision-making layer in thinking about how to use integrated data in the context of a transportation community across different government organizations. Currently, agencies struggle with issues related to the organizational structure such as transforming location references, disconnected business cycles, and inconsistent terminology. From a strategic business point of view, first and foremost, all data integration efforts must be business driven. Before making an investment in systems development, there has to be a business imperative. Otherwise, there is no incentive for users to learn and implement the system resulting in atrophy of the system. Constant involvement and participation of both business and technology people is a hallmark of a successful development effort. Agencies can anticipate failed development projects if there are disconnects between the business and technology implementation. Development of asset management systems requires heavy user involvement and lots of communication with people who use the individual business systems being integrated. Today, IT services at state transportation agencies are either centralized or decentralized. Neither approach is clearly better. Centralized IT operations tend to reduce redundancy and incompatible IT infrastructure and maintenance and thus reduce the need for IT staff. Decentralized IT operations have the benefits of freedom of choice among departmental units in systems selection. Thus, departmental units can make system advance without barriers thus avoiding obsolescence. Synthesis results include common practices and recommendations. The following are the most salient observations. 7.1. RECOMMENDATIONS FOR UPPER MANAGEMENT Perspective of Upper Management Asset management should be view as a strategic initiative driven by business needs; Executives should think about data integration as a business issue, not an IT issue; and Executive staff supports IT and innovation. Identifying Strategic Systems Initiatives Identification process should top-down and business driven; Top management narrows and prioritizes strategic systems initiatives; Chapter 7 Conclusions 83 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Address problems associated with upstream/downstream data and business cycles with a data capture program; and Capture business information during relevant and related business procedures to replace periodic data collection activities Using External Expertise for Project Development Agencies often hire contractor for part or all of the systems development. The consultants should be selected for specific knowledge or when the agency does not have enough in-house staff. The contractors may bring specialized expertise but they may not understand the agency’s business or business culture. When using consultants, enlist agency IT Department to act as “watch dogs” over internal and external standards choices, data types, naming convention, integration points, etc.; Partner with software developers that are the best in the industry and certified as the highest quality. Use prototyping techniques to overcome communication barriers with consultants and across business units; Do not outsource an entire project; If consultants are used for specific knowledge, then have in-house staff work side-by-side with consultants so that in-house staff can maintain the system; Plan for consultants to train in-house staff and hand-off work in 24 months. Consider the need to include training in the consultant’s contract; and Have a plan for keeping the agency’s project team focused when transitioning between contractors. Getting Participation in System Development The following are recommendations for dealing with this challenge. Business managers must reallocate workload for project participants. Project participants must be given work time to reconcile issues, certify results, answer questions, attend meetings, etc.; and Making sure up front that project team buys-in to the project and that they recognize the project work as their job responsibility. Managing Project Expectations and Scope Creep Unrealistic project expectations and scope creep are very real potential problems. These may occur early on if the management Steering Committee issues an unrealistic Project Charter. Expectations and scope creep can be managed by Establishing the project scope at the onset by involving all stakeholders in identifying key improvements to existing data procedures; Prioritizing expected outcomes based on time, money and resources; Developing consensus through team communication on core data and functions to be supported – other data and functions can be noted for future development efforts; and Not developing data definitions and integration points that will not be used immediately. Getting Agency Buy-in and Acceptance Broad agency buy-in and acceptance are important early on and at the time of deployment. A big challenge may be in getting input from employees not on the project team but whose day-to-day operations will be impacted by the project results. Use prototyping as a communication tool to get buy-in early on. Build agency support by demonstrating a pilot project or proof of concept system; Chapter 7 Conclusions 86 Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach Chapter 7 Conclusions 87 Create systems that reflect organizational alignment; Create strong business imperatives the provide incentive for employees to participate in development and use of the system; Have the Steering Committee visit the districts to explain the project and get buy-in; and Develop end user training geared to various user levels: top management, primary and secondary. Create Data Teams and Designate Data Owner-Users Quality and currency of underlying inventory data are critical for getting buy-in and establishing credibility of the system. The business units should be regarded as the data owners. The IT staff should stay in the background to facilitate and support the data management processes. Specific recommendations include: Creating in-house data teams of core, main, and peripheral users to identify and document business functions; and Designating “owner-users” from each business area to prepare metadata, define operational constraints and quality controls, populate and maintain the database, and respond to questions from other users. The role of the “owner-user” does not end after system is complete; on- going functions include: o Creating standard data reports for casual users; and o Creating and posting “readme” files to explain the meaning of data when users ask for clarification. Identify and Use Measures of Success Finally, agencies need to identify a set of success criteria early on in the project development. Some measures of success suggested by the state agencies include: Evaluate the development project performance by measuring change (improvement) in infrastructure system performance; Measure success of system development project by user’s ability to adapt to business process changes; Success if asset management system outputs can be explained to the public and legislature; and Use accomplishment of key requirements to measure success of the project. 7.4. SUMMARY In summary, data integration is a complex project requiring state of the art design of the system and also requiring art of the practice in organizing and implementing it successfully. It is encouraging to see good practices among several state DOTs in the region that have provided many insights and successful experiences. Lessons have also been learned. Along the wide availability of data and information as well as supporting IT technology, we believe data integration will become more of a reality in the future. Great benefits will result from it in the general areas of planning, operation and control . Synthesis of Best Practices for the Development of Integrated Data and Information Management Approach References 1. Asset Management Primer. (1999). FHWA Office of Asset Management, US DOT Transportation. December. (http://wwwcf.fhwa.dot.gov/infrastructure/asstmgmt/amprimer.pdf) 2. Cambridge Systematics Inc. (2002). Transportation Asset Management Guide. Final Report NCHRP Project 20-24(11). National Cooperative Highway Research Program, Publication No. RP-TAMG-1. November. 3. Data Integration Primer. (2001). US DOT Office of Asset Management. Publication No. FHWA IF-01-01. August. (http://199.79.179.19/OLPFiles/FHWA/010393.pdf) 4. Data Integration Glossary. (2001). US DOT Office of Asset Management. Publication No. FHWA IF-01-017. August. (http://199.79.179.19/OLPFiles/FHWA/010394.pdf) 5. Data Integration Forum and Peer Exchange. (2001). FHWA Office of Asset Management and AASHTO. Chicago, IL. Dec. 12-13. (http://wwwcf.fhwa.dot.gov/infrastructure/asstmgmt/dimeet.htm) 6. Evans L., (2003). Data Integration: The Ohio Experience, FHWA 7. James G. (2002). Managing Multiplying Messages. Research Note DF-14-5561. Gartner, Inc. February. 8. Kost, J. (2003). US State Technology Management Assessment. Research Note Number SPA-19-0306. Gartner Research. 9. Nestler J, (2003). Wisconsin Information System for Local Roads. Wisconsin DOT, August. 10. Ohio Department of Transportation, (2003). ODOT Business Plan 2004-05, December. 11. Proceedings, Data Integration for Asset Management Forum and Peer Exchange. (2002). US DOT Office of Asset Management. Publication No. FHWA IF-02-042. August. (http://199.79.179.19/OLPFiles/FHWA/010620.pdf) 12. Schulte, R., W. Rishel, J. Thompson, and J. Sinur. (2002a). Identifying Useful Kinds of Application Integration Metadata, Research Note TU-15-1931. Gartner, Inc. March. 13. Schulte, R., J. Thompson, W. Rishel, and B. Lheureux. (2002b). Best Practices: Managing Application Integration Metadata. Research Note TG-15-1933. Gartner, Inc. March. 14. Schulte, R. J. Thompson, M. Pezzini, W. Rishel, and M. Blechar. (2002c). Tools and Sources for Application Integration Metadata, Research Note T-15-1932. Gartner, Inc. March. 15. Schulte, R., M. Blecher, J. Thompson, W. Rishel, and M. Pezzini. (2002d). Strategies for Managing Application Integration Metadata, Research Note T-15-5501. Gartner, Inc. March. 16. Schulte, R., Y. Natis, J. Thompson (2001). The Enterprise Nervous System Arrives.” Decision Framework, DF-15-0450. Gartner, Inc. December 17. St.Clair B., (2001). WisDOT’s Meta-Manager, 4th National Transportation Asset Management Workshop, September. 18. Surber Rob, (2004). Michigan Geographic Framework Network, (http://www.michigan.gov/cgi/1,1607,7-158-12618-31485--,00.html) , accessed November References 88