Click for next page ( 80

The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 79
79 In practice, the value of the national freight data architec- focuses on relationships between different individual data ture is also a function of the costs associated with its imple- architecture components for specific business processes. mentation. Quantifiable data about expected benefits and costs are currently not available (benefit-cost analyses need to National Freight Data Architecture occur both at the beginning and at different phases of imple- Recommendations and mentation of the national freight data architecture). How- Specifications ever, it is clear from the documentation and information gathered during the research that the "do-nothing" alterna- In addition to the list of categories and components, the tive (i.e., not implementing the national freight data architec- research team put together a list of recommendations for the ture) is costly, ineffective, and, unsustainable. Therefore, the development and implementation of the national freight data research team's recommendation is to pursue the national architecture. For convenience, the recommendations are writ- freight data architecture following a scalable implementation ten in the form of specifications to guide and monitor the path in which the national freight data architecture starts with implementation of the data architecture. one application at one or two levels of decisionmaking and Chapter 4 provides a detailed discussion of each specifica- then adds applications and levels of decisionmaking as needed tion item. For compactness, only the title of each specification or according to a predetermined implementation plan until, is listed here: eventually, reaching the maximum net value. Adopt a definition for the national freight data architecture that is generic, scalable, and is understood and accepted by National Freight Data the freight transportation community (see proposed defi- Architecture Components nition above); Compare candidate data architecture implementation The research team identified the following categories of com- ponents to include in the national freight data architecture: concepts; Develop implementation plan for national freight data Physical transportation components, architecture components; Develop lists of components to include in the national Cargo or freight, freight data architecture; Freight functions or roles, Develop and implement protocols for continuous stake- Business processes, holder participation; Data sources, Conduct data gap analysis; Freight-related data, Conduct data disaggregation need analysis; Freight data models, Assume a distributed approach (as opposed to a central- Freight data standards, and ized approach) to freight data repository implementations; User interface and supporting documentation. Use a systems engineering approach for developing the national freight data architecture; Figure 10 (shown previously) presents a high-level modular Use standard information technology tools and procedures; conceptualization and list of different categories of compo- Develop and/or use standardized terminology and defini- nents. The diagram recognizes the scalable nature of the tions for each data architecture component developed; national freight data architecture and enables the production Implement strong privacy protection strategies; and of a variety of diagram versions (as well as tabular represen- Establish integration points with other data architectures tations) depending on what implementation level to pursue. and standards. For example, for a single-application data architecture that only focuses on commodity flows at the national level, it may not be necessary to depict (at least not in detail) other freight Challenges and Strategies functions and business processes. Similarly, not all data stan- The research team identified relevant issues and challenges dards would need to be considered, and the requirements that might block the implementation of the national freight for user interfaces to support that data architecture would be data architecture, as well as candidate strategies for develop- relatively minor. ing, adopting, and maintaining the data architecture. The The diagram in Figure 10 is only one example of potentially challenges were in the following categories: technical chal- many different types of diagrams that can be used to depict lenges, policy challenges, economic and financial challenges, interactions among freight transportation components. An and stakeholder buy-in and consensus. Chapter 4 provides a example of a different type of diagram previously shown is detailed description of each challenge. Only a summarized list Figure 12, which presents a high-level conceptual model that of challenges is provided here.

OCR for page 79
80 Technical challenges. Technical challenges refer to issues Confidentiality clauses in supply chain contracts, which (e.g., technological limitations, hardware and software might impede data sharing for transportation planning incompatibilities, and standards incompatibilities) that purposes; might impede the successful implementation of the data Perception that data collected as part of a national architecture. Examples include the following: freight data collection program could validate projects Feasibility of different implementation approaches; of national significance at the expense of small or rural Data storage requirements; communities; Feasibility of updated data entry protocols to eliminate Ability of small carriers to provide data about loads they data redundancies and support standardized data entry move; procedures; Risk of low stakeholder participation, which could Conversion of commodity code classifications; decrease data reliability; and Data life cycle and usefulness to support the decision- Adequacy of data standards. making process by public and private stakeholders; Variability in data quality control practices, which affect Strategies to ensure a successful implementation of the data accuracy, completeness, and timeliness; national freight data architecture include the following: Differences in terminology, data item definitions, and data implementations among freight data stakeholders; Implementation levels Prioritization of data architecture components; Develop and compare candidate data architecture Integration between shipper and carrier data to charac- concepts, terize commodity movements properly; and Identify business process and implementation level Data confidentiality and security concerns. priorities, Policy challenges. The national freight data architecture Develop high-quality data architecture concepts and might fail if required policies, both in the public and private applications that address the needs of the highest prior- sectors, fail or are not feasible. Examples of policy challenges ity items first, and include the following: Identify data needs at the finest disaggregation level and Homeland security concerns, which might limit the dis- implement data collection and data storage plans at that semination of certain freight-related data; level. Impact on current private-sector data collection initia- Relationships with leaders, champions, and stakeholders tives; and Identify data architecture leaders and champions; Competitive and proprietary (privacy) concerns with Engage the national freight data architecture champions the concept of public-sector agencies having access to early; private-sector data. Maintain good communication channels with the vari- Economic and financial challenges. The national freight ous stakeholders during all phases of the development data architecture might fail if the perceived costs associated and implementation of the national freight transporta- with its implementation exceed the benefits that stakehold- tion data architecture; ers would receive. Examples of economic and financial Identify funding mechanisms for the implementation of challenges include the following: the data architecture; Cost of data collection, storage, and quality assurance; Develop brochures, presentations, and other materi- Benefits and costs related to data disaggregation require- als that explain the national freight data architecture, ments for different business processes; its scope, high-level components, and what it expects to Data life cycle and usefulness to support the decision- accomplish; making process by public and private stakeholders; Deliver effective messages on how the national freight Cost to acquire private-sector data; and data architecture will assist stakeholders in the identifi- Cost to implement robust data confidentiality and data cation of strategies to address a variety of freight-related security measures. issues ranging from data collection to analysis and Stakeholder buy-in and consensus. The national freight reporting; data architecture might fail if there is no stakeholder buy- Deliver messages that provide clear, concise answers to in or consensus about the potential benefits that could the various challenges highlighted in the previous section; result from implementing the data architecture. Examples Articulate benefits of participation by the private sector; of related issues include the following: and Reluctance of stakeholders to participate if there is no Identify opportunities for partnerships with the private clarity regarding justification and anticipated benefits; sector (e.g., through publicprivate partnerships) to make

OCR for page 79
81 data accessible for transportation planning purposes in a Develop systems that are consistent with input data cost-effective manner. limitations; Performance measures and effectiveness Develop applications with backward compatibility; Develop criteria for measuring the effectiveness in the Evaluate data disaggregation level requirements to implementation of the national freight data architecture, ensure statistical significance; Identify major progress milestones, Provide adequate resources for data collection, fully Tie the implementation of the national freight data archi- understand the implications of small sample sizes, and tecture to the development of metrics or performance continue to involve the U.S. Census Bureau for the use measures that could benefit the entire freight transporta- of survey instruments; tion community, and Emphasize data access, quality, reliability, confidentiality, Accelerate the implementation of programs such as EFM and integrity; and the freight performance measurement program. Participate in the standards development process; Lessons learned from the implementation and mainte- Create crosswalks to ensure compatibility of survey data nance of existing freight-related systems and architectures internally over time and externally across other datasets; (see Chapter 2 for detailed information about these systems Involve stakeholders early and often through a variety and architectures) of mechanisms and technologies; and Develop systems that are relevant to stakeholders, Develop and implement professional capacity and train- include adequate stakeholder participation, and provide ing programs early. incentives to encourage participation--particularly in the case of state and local entities; One of the strategies for implementation mentioned above is Clearly define expected outcomes and development and to develop and compare candidate data architecture concepts. coordination plan; Peer exchange participants highlighted that implementing a Articulate programs well; provide clear, uniform guid- comprehensive data architecture at once with no testing of ance; and provide good documentation; options prior to making a decision about the correct approach Develop applications that rely on widely used data would be too risky. Participants also favored the concept of standards; developing and comparing several alternative approaches. Develop and compare candidate architecture concepts; A recommendation from peer exchange participants was to Consider federal legislation to support and develop the use NCFRP as an avenue for funding the development of alter- program; native data architecture concepts. Participants indicated the Develop tools to measure benefits and costs early; request for proposals should outline clear objectives, while Integrate archived data needs into frameworks and leaving the definition of approaches to the research team(s) architectures early and develop data programs that use selected. An idea discussed was to develop the data architecture industry standards; around scenarios or themes, such as business areas or processes, Implement interagency data exchange programs with levels of government, or economic activity. Activities in connec- centralized data coordination; tion with each scenario or theme would include structuring a Use available data sources and develop long-term plans competition for research teams (each of which would include a while keeping systems flexible to respond to changes university partner, a private-sector partner, and a government- and new data sources; level partner) to develop and test competing data architecture Schedule major and regular revisions effectively while concepts, making sure to include multimodal components in avoiding scope creep; the scenarios and tests, and conduct a follow-up evaluation.