Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
58 Introduction This chapter provides a catalog of components, characteris- tics, and draft specifications for a national freight data architec- ture that takes into consideration the results and lessons learned from the literature review, surveys and follow-up interviews, and peer exchange described in Chapters 2 and 3. Special Considerations A prerequisite for the development of specifications for a national freight data architecture is to define what a national freight data architecture should be. There are several dimen- sions to this issue, including focus, content, scope, and access to private-sector data sources. Freight Data Focus Different stakeholders may have different interpretations of what should be the focus of the national freight data archi- tecture. As such, focus affects content and, therefore, data architecture specifications. For example, a data architecture that focuses on commodity flows has certain data require- ments such as O-D data; commodity characteristics, weight, and value; modes of shipment; routing and time of day; and vehicle type and configuration. By comparison, a data archi- tecture that focuses on the physical interaction between com- mercial vehicles and the transportation network has different data needs, such as vehicle type and configuration, network characteristics and performance, oversize and overweight data, safety data, and inspection data. Likewise, a data architecture that focuses on commodity flows and requires the collection of real-time supply chain data from the private sector has special data confidentiality requirements. There is some over- lap between different focus options, and the challenge is to identify which one(s) to pursue. Freight Data Content Different stakeholders may have different interpretations of what should be the content of (i.e., what should be included in) a national freight data architecture. As with focus, content affects data architecture specifications. Obviously, the con- tent of a data architecture depends on what is meant by data architecture. Different definitions exist, but, in general, a data architecture is the manner and process used to organize and in- tegrate data components. It is worth noting that a data archi- tecture is not a database (databases may be built based on data architectures); a data model, a data standard, a specification, or a framework (these items could be components of a data architecture); a system architecture (a system architecture could use data architecture components); a simulation or optimiza- tion model; or an institutional program. In order to concep- tualize data components, data architectures normally use one or more of the following tools: ⢠Business process model (i.e., a representation of processes); ⢠Conceptual model (i.e., a representation of concepts and relationships); ⢠Logical model (i.e., a representation of data characteris- tics and relationships that is independent of any physical implementation); ⢠Physical model (i.e., a representation of data characteris- tics and relationships that depends on the specific physical platform chosen for its implementation); and ⢠Data dictionary and/or metadata (i.e., listing of definitions, characteristics, and other properties of entities, attributes, and other data elements). In practice, which tools to use in a data architecture de- pends on the purpose and needs of the specific application. For example, a data architecture can be generic or specific. An example of a data architecture that is tightly integrated C H A P T E R 4 Outline and Requirements for a National Freight Data Architecture
into a specific application is the EFM data architecture (130). The EFM database schema includes several tables that sup- port shipment tracking across the supply chain. By compar- ison, a generic data architecture that focuses on data flows rather than how data entities are organized and stored in a database is the National ITS Architecture (87). This architec- ture describes functions, subsystems where the functions re- side, and data flows that connect functions and subsystems in connection with the implementation of transportation oper- ation systems. It may be interesting to note that despite the name, National ITS Architecture implementations are usu- ally carried out at the local level. Freight Data Scope Freight data scope (including both coverage and resolution) also has an impact on data architecture specifications. As doc- umented in Chapter 3, different levels of decisionmaking tend to have different data requirements. For example, as the level of analysis migrates from a national level to a local level, the quantity and level of detail associated with the data needed for decisionmaking tends to increase. It follows that a data archi- tecture that has to support several levels of decisionmaking has to accommodate a wider range of data requirements than does a data architecture that only needs to support one level of de- cisionmaking. By extension, a national data architecture that is to serve the needs of both public and private decisionmakers not just at the national level, but also at the state and local lev- els, has to be even more encompassing. Plenty of documents provide information about the limi- tations of current data collection programs, adding weight to the idea that the coverage and resolution of current freight data sources are not sufficient. The data resolution issue is particularly critical because no statements are currently available that outline (1) the required data disaggregation and accuracy levels to address current and anticipated data collection needs from a technical and statistical perspective and (2) the corresponding impacts of those requirements on data collection costs and privacy requirements. Developing those statements is critical in order to identify data collection requirements (131). Dimensions to freight data disaggregation include areas such as commodity type disaggregation, geographic disaggre- gation, temporal disaggregation, financial data disaggregation, operating data disaggregation, and privacy requirements. For example, CFS does not collect shipment data for certain industries and commodities and does not collect shipment data for shipments passing through the United States. In addi- tion, cross-border shipment paths only include U.S. mileage. Further, CFS follows a 5-year cycle, which is inadequate for freight analyses in connection with phenomena such as reces- sions or droughts. The 2-year lag between data collection and release is also a weakness. Likewise, the 2002 CFS used the largest 50 metropolitan areas plus remainders of state areas. Several ideas have been suggested to increase the number of CFS regions, including using three-digit zip codes (of which there are 929 throughout the country) and BEA areas (of which there are 172 through- out the country) (37). A recent study of techniques to gener- ate national FAZs for transportation models recommended a system of 400 zones (40). A current NCFRP project (NCFRP Project 20, âGuidebook for Developing Sub-National Com- modity Flow Dataâ) is expected to shed light on recommended practices in this area (132). Specifically, the research will pro- duce a guidebook describing standard procedures for compil- ing local, state, regional, and corridor commodity flow data- bases, as well as new and effective procedures for conducting sub-national commodity flow surveys and studies. The need for data quality awareness is increasing, as evi- denced by the 2001 OMB mandate that required Executive Branch agencies in charge of gathering, processing, or ana- lyzing data for statistical purposes to issue quality guidelines to maximize the integrity, quality, and usability of the infor- mation those agencies disseminate (133). Relevant U.S.DOT documents include the HPMS field manual (67), the BTS com- pendium of source and accuracy statements (76), the Guide to Good Statistical Practice in the Transportation Field (131), and the BTS Statistical Standards Manual (134). The privacy provisions in the E-Government Act of 2002 included a requirement for federal agencies to conduct pri- vacy impact assessments (PIAs) to document what informa- tion is to be collected, its purpose and intended use, informa- tion sharing practices and security measures, opportunities for consent, and whether a system of records is created fol- lowing Privacy Act provisions (135). The PIAs for the systems managed by the various operating administrations within the U.S.DOT, including relevant freight-related systems discussed in this report, are listed online (136). Access to Private-Sector Data Sources Aggregated freight data from commercial data providers have been available for years. For example, TRANSEARCH Insight merges several data sources including data from federal agencies and data from carriers. PIERS relies on data sources such as copies of shipping documents, monthly sum- maries from CBP, and information gathered through partner- ships with companies abroad that specialize in manifest data collection in other countries. In practice, it is not always possi- ble to obtain detailed documentation about the characteristics 59
and methodology used for the production of commercial databases. These databases can be more expensive compared to public-sector data (at least from the standpoint of regular freight data users who do not need to internalize the cost to collect, process, and publish public-sector data). The shipper industry collects large amounts of data. Many shippers and logistics service providers transmit data elec- tronically using EDI technologies. These stakeholders use EDI regularly for load tendering, tracking, and freight pay- ment purposes. However, accessing data from shippers and logistics service providers for transportation planning ap- plications (beyond aggregated data from commercial data providers and national survey campaigns such as CFS) is not necessarily straightforward. For example, although a data record might characterize a commodity as well as origin and destination locations, the route data component may be miss- ing unless the carrier movement data are included. In addi- tion, many of the shipper stakeholders interviewed indicated they could not share data without the express consent of sen- ior management and a review by their legal departments (par- ticularly on a load-by-load basis, given its proprietary and confidential nature). Motor carriers also expressed reservations about sharing proprietary and confidential data. Their reservations were re- lated to the need to develop mechanisms to protect proprietary and confidential information and to maintain the anonymity of carriers and customers. In general, carriers would need to know in advance the specific uses of the data and, in return, would expect information in the form of industry bench- marking metrics. It is worth noting that developing metrics of interest to the private sector is part of NCFRP Project 3, âPerformance Measures for Freight Transportationâ (129). In practice, the type and amount of data provided by, or available through, carriers varies considerably, depending on factors such as carrier size, geographic locations, activity focus, and type of cargo transported. Carriers handle large amounts of disaggregated data during the course of their business operations. Increasingly, carriers use EDI standards and applications. However, most of this information is con- fidential and limited to the direct exchange of data between trading partners. Some federal agencies are implementing EDI-based technologies to capture data from carriers, mainly through customs and homeland security processes. The amount of shipment information detail in EDI trans- action sets varies according to the type of transaction set used. In general, although the transaction sets support the use of commodity codes such as NMFC or STCC, these codes are different from other codes such as SCTG or NAPCS. Although crosswalk tables enable the conversion of commodity codes across coding systems, the current inventory of crosswalk tables is neither comprehensive nor coordinated. Questions also remain regarding the current level of market penetration of standardized commodity codes among shippers and carri- ers because, in reality, industry operational environments, customer expectations, and freight billing practices affect the collection of shipment-level data by carriers. For example, TL carriers, who tend to bill customers on a per-mile basis or by using a flat rate, rarely collect detailed commodity data, col- lecting instead generalized, non-standardized, and/or pro- prietary descriptions. Shipper bills of lading also vary widely in commodity-level descriptions (or contain no description at all). In addition, TL carriers are less likely to collect data on tonnage hauled or tare-level data, also attributable to industry- accepted billing practices. By comparison, LTL carriers typically bill customers using a rate structure based on shipment weight, origin, destina- tion, and freight classification. As a result, they tend to col- lect more commodity-level data. The traditional classifica- tion of LTL freight is based on NMFC codes. However, there is anecdotal evidence that LTL carriers frequently collect less descriptive or uniform commodity-level detailed data, favor- ing a freight-all-kinds rating structure that assigns a general freight classification to all shipments from a shipper regard- less of freight commodity or type. As opposed to TL carriers, LTL carriers are more likely to track total tonnage. The implementation of ITS technologies is facilitating the acquisition of operational-level data from carriers. Most of these initiatives focus on the interaction between carriers and the transportation network environment, but not on the collection of detailed commodity data. This is the case of the CVISN program, which involves the deployment of systems to streamline the credential process, automate inspection screen- ing activities, and exchange data in connection with safety checks, credential checks, and fee processing. Some initiatives are addressing data exchange between stakeholders along the supply chain process, as in the case of the EFM initiative sponsored by FHWA, but it is not yet clear whether, and to what degree, some of the data result- ing from this process could be used for freight transporta- tion planning purposes. EFM has undergone several field tests, including field operational tests at OâHare and JFK International Airports, and the Columbus Electronic Freight Management deployment test. An upcoming deployment test is scheduled to launch at the Kansas City SmartPort project. Other initiatives also are resulting in the collection of vast amounts of operational-level data at little to no cost to carri- ers, as in the case of the FHWA-sponsored initiative that has resulted in the collection of several billion anonymized posi- tional data records per year from more than 600,000 trucks that operate in North America. This large database is facil- itating the determination of performance measures such as travel times and speeds on freight-significant highways, as well as route choice by truck drivers. 60
National Freight Data Architecture Definition Based on the analysis in the previous section, a generic def- inition for a national freight data architecture is as follows: The national freight data architecture is the manner in which data elements are organized and integrated for freight transportation-related applications or business processes. The data architecture includes the necessary set of tools that describe related functions or roles, components where those roles reside or apply, and data flows that connect roles and components at different domain and aggregation levels. In practice, several alternative implementation options may be possible depending on factors such as the following: ⢠What is the freight community really interested in pursuing? ⢠What is the level of funding that different stakeholders (both public and private) are willing to invest to support that effort? ⢠Where is the source of the funding and what are the require- ments and steps to secure it? ⢠What benefits would different stakeholders derive? ⢠What is the implementation horizon? There are no simple answers to these questions. Although this report lays out a few alternative implementation options and discusses issues such as value, challenges, and strategies to assist with the discussion, ultimately it is up to the freight community to decide what option to implement (and how). Some alternative implementation options follow: ⢠Single-application approach. In this case, the national freight data architecture would become the manner in which data elements are organized and integrated for a specific freight application or business process at the na- tional level (e.g., commodity flows). ⢠Intermediate approaches (depending on the number of applications). In this case, the national freight data archi- tecture would become the manner in which data elements are organized and integrated for a specific set of applica- tions at the national, state, regional, and local levels. A large number of intermediate approaches is possible, depending on the business processes and geographic levels included. For example, an intermediate implementation approach could include commodity flows at the national, state, and regional levels. Another, more encompassing, intermediate implementation approach could include commodity flows, safety, and pavement impacts at the national, state, regional, and local levels. ⢠Holistic, all-encompassing approach. In this case, the na- tional freight data architecture would become the manner in which data elements are organized and integrated for all freight transportation-related applications or business pro- cesses at the national, state, regional, and local levels. For any of these implementation options, the data archi- tecture would include the necessary set of tools that describe related functions or roles, components where those roles reside or apply, and data flows that connect roles and components. National Freight Data Architecture Value Increasing the focus, content, and scope of the national freight data architecture has the potential to increase the total benefit derived from its implementation (Figure 9a). However, the rate of growth of the total benefit would probably decrease with the level of implementation (and even become negative at some point). At the same time, the complexity and costs asso- ciated with the implementation of the national freight data ar- chitecture would be likely to increase with the level of imple- mentation (Figure 9b). The value of the national freight data architecture is a function of both total benefit and cost and complexity associated with its implementation. As Figure 9c shows, it is quite likely that the maximum net value would take place at some intermediate level of implementation. These observations suggest a scalable implementation path in which the national freight data architecture starts with one application at one or two levels of decisionmaking and then adds applications and levels of decisionmaking as needed or according to a predetermined implementation plan until, eventually, reaching the maximum net value. Unfortunately, data about benefits, costs, or complexity for each level of im- plementation that might enable a quantifiable determination of value are currently not available. Conducting appropriate benefit-cost analyses to obtain this type of information is a necessary activity that needs to occur both at the beginning and at different phases of implementation of the national freight data architecture. From the documentation and information gathered in pre- vious chapters, the research team identified the following list of benefits that, together, provide a statement of value for the national freight data architecture: ⢠Better understanding of the different business processes that affect freight transportation at different levels of cov- erage and resolution; ⢠Better understanding of the supply chain, which should help transportation planners to identify strategies for im- proving freight transportation infrastructure; ⢠Better understanding of the role that different public- sector and private-sector stakeholders play in freight transportation; 61
⢠Better understanding of the need for standards to assist in data exchange; ⢠Systematic, coordinated development of reference datasets (e.g., comprehensive commodity code crosswalk tables); ⢠Systematic inventory of freight transportation data sources; ⢠Systematic inventory of user and data needs that are pre- requisites for the development of freight data management systems; ⢠Use as a reference for the identification of locations where there may be freight data redundancy and inefficiencies; ⢠Use as a reference for requesting funding allocations in the public and private sectors; and ⢠Use as a reference for the development of outreach, profes- sional development, and training materials. National Freight Data Architecture Components As previously mentioned, a data architecture is not limited to data models because the models are just the tools that en- able a systematic understanding of other components such as data, business processes, and roles. A list of components that make up a data architecture is therefore necessary. In the con- text of a scalable national freight data architecture that might need to serve the needs of a variety of decisionmaking levels, this data architecture would need to include a number of com- ponent categories, such as the following: ⢠Physical transportation components, ⢠Cargo or freight, ⢠Freight functions or roles, ⢠Business processes, ⢠Data sources, ⢠Freight-related data, ⢠Freight data models, ⢠Freight data standards, and ⢠User interface and supporting documentation. This list is preliminary and will need to be refined during the process of developing and implementing the data architecture. Figure 10 shows a high-level modular conceptualization and lists different categories of components. Each category and each component in Figure 10 can be thought of as an ob- ject or dimension that can be defined and characterized using appropriate information parameters such as description, do- main, aggregation levels, attributes, and performance mea- sures. Although the diagram emphasizes the high degree of interaction among components, the main use of the diagram would be as a tool to develop explicit lists of components to include in the national freight data architecture. As such, the diagram recognizes the scalable nature of the national freight data architecture and enables the production of a variety of diagram versions (as well as tabular representations) depend- ing on what implementation level to pursue. 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 functions and business processes. Similarly, not all data standards would need to be considered, and the requirements for user interfaces to support that data architecture would be relatively minor. Fig- ure 11 and Table 8 illustrate this concept. 62 Holistic, all- encompassing approach Intermediate approaches Single- application approach $, Co mp lex ity Holistic, all- encompassing approach Intermediate approaches Single- application approach To ta l b en ef it Holistic, all- encompassing approach Intermediate approaches Single- application approach N et v al ue (a) (b) ( c) Figure 9. Relationship between national freight data architecture implementation level, total benefit, cost and complexity, and net value.
Tuesda y, June 02 , 20 09 Page 1 Data Mode l Physical Transportation Components Cargo or Freigh t Freight Function s o r R ole s Fixed infrastructur e m anager or operator Regulator or policymaker Researcher Shipper or receiver Third-party logistics or broker Business Processes Congestion management International trade Logistics management On-board security monitoring Planning and forecasting Roadside safety inspection Routing and dispatching Safety analysi s Transportation infrastructur e analysis, design, and construction Transportation operations Workforce development and training Dat a S ources Administrativ e r ecords by laws an d r egulation s -sector data -sector data Freight Dat a M odels Freight Data Standards Commodity and product classification standards CP C HMIS HS NAPC S NMFC NST 2007 PL U SCTG STCC Industrial classification standards ISIC NAIC S SI C SITC at a e xchange standards ANSI ASC X1 2 s tandards UN/EDIFACT standards OASI S U BL standards FIP S P UB 161-2 National ITS standards FGDC-sponsored standards (including metadata ) Other standards ITD S S DS MET S Vehicle classification standards User Interface an d S upporting Documentation -based information clearinghous e Freight-Related Dat a Freight-Related Data and condition , s peed, and delay data routing dat a Note s : 1) Categories an d c omponent s a re provided for illustration purposes , a re not exhaustive, and ma y b e s ubjec t t o c hange . 2) Not all categories an d c omponents apply to all freight-related busines s p rocesses. Figure 10. National freight data architecture framework and components.
Tuesda y, June 02 , 20 09 Page 1 Data Mode l Physical Transportation Components Cargo or Freigh t Freight Function s o r R ole s Fixed infrastructur e m anager or operator Regulator or policymaker Researcher Shipper or receiver Third-party logistics or broker Business Processes Congestion management International trade Logistics management On-board security monitoring Planning and forecasting Roadside safety inspection Routing and dispatching Safety analysi s Transportation infrastructur e analysis, design, and construction Transportation operations Workforce development and training Dat a S ources Administrativ e r ecords by laws an d r egulation s -sector data -sector data Freight Dat a M odels Freight Data Standards Commodity and product classification standards CP C HMIS HS NAPC S NMFC NST 2007 PL U SCTG STCC Industrial classification standards ISIC NAIC S SI C SITC at a e xchange standards ANSI ASC X1 2 s tandards UN/EDIFACT standards OASI S U BL standards FIP S P UB 161-2 National ITS standards FGDC-sponsored standards (including metadata ) Other standards ITD S S DS MET S Vehicle classification standards User Interface an d S upporting Documentation -based information clearinghous e Freight-Related Dat a Freight-Related Data and condition , s peed, and delay data routing dat a Note s : 1) Categories an d c omponent s a re provided for illustration purposes , a re not exhaustive, and ma y b e s ubjec t t o c hange . 2) Not all categories an d c omponents apply to all freight-related busines s p rocesses. 3) Component s m arked wit h f ocus on commodit y f lows at the national level . Figure 11. National freight data architecture components (focus on commodity flows at the national level).
The diagram in Figure 10 is only one example of potentially many different types of diagrams that can be used to depict interactions among freight transportation components. An example of a different type of diagram is Figure 12, which shows a high-level conceptual model that depicts relationships between different individual data architecture components for specific business processes. In Figure 12, each oval represents a component within a component category. For example, a physical transportation component could be a vehicle, a con- tainer, a transportation network, or a traffic control system. Arrows between ovals represent relationships between com- ponents. Each component is associated with user interface and supporting documentation components (as indicated by the Documentation label). The arrows between ovals in Figure 12 represent many-to-many relationships between components. Examples of relationships include the following: ⢠A physical transportation component can be associated with many cargo or freight components and/or freight function or role components. 65 Table 8. Category components that pertain to commodity flows at the national level. N a t i o n a l F r e i g h t D a t a A r c h i t e c t u r e C a t e g o r y / C o m p o n e n t Commodity- Flow-Related N a t i o n a l F r e i g h t D a t a A r c h i t e c t u r e C a t e g o r y / C o m p o n e n t Commodity- Flow-Related C a r g o o r F r e i g h t Travel time, speed, and dela y data Bill of ladi ng ⢠Vehicle inve ntories Commodity ⢠F r e i g h t D a t a M o d e l Invoice Busi ness pr ocess model ⢠Item or product ⢠Conc ep tual model ⢠Purchase orde r ⢠Data dictionary ⢠Shipment ⢠Logical model ⢠Waybill ⢠Metadata ⢠P h y s i c a l T r a n s p o r t a t i o n Physical model ⢠Contai ner ⢠F r e i g h t D a t a S t a n d a r d Traffic control system ⢠Commodity /p roduct classification: Transportation network ⢠CPC ⢠Vehicle HMIS ⢠F r e i g h t F u n c t i o n o r R o l e HS ⢠Analys t NAPC S ⢠Carrier ⢠NMFC ⢠Fixed in frastructure manage r NST 2007 ⢠Planne r ⢠PLU ⢠Policymaker ⢠SCTG ⢠Producer or manufacturer STCC ⢠Regula to r ⢠Industrial classification standards: Researcher ISIC Shipper or receiver ⢠NAICS ⢠Third-party logistics or broker ⢠SI C ⢠F r e i g h t - R e l a t e d D a t a SITC ⢠Busi ness directories ⢠Data exchange standards: Carrier used ANSI ASC X12 standard ⢠Commodity i nvent ories FIPS PUB 161-2 ⢠Products shi pped/received ⢠OASIS UBL standards Distribution warehouse truck tr affi c ⢠UN/EDIFACT standards Economic data National ITS standards Emissions data a nd esti mates FGDC-spons ored stan dards Employment by freight activit y Other standards: Freight volumes ⢠ITDS SDS Fuel statistics METS Import and export statistics Vehicle classification standard s Licensed carrier data D a t a S o u r c e Manifests and way bills ⢠Administrative records Mine out put data Census ⢠Oversize/overweight routing data ⢠Data standards ⢠Pipeline volum es ⢠Mandatory reporting required by laws ⢠Railroad tonna ge data ⢠Surveys ⢠Safety data Other private-sector data ⢠Shipment origins a nd de stinati ons ⢠Other public-sector data ⢠Shipment weigh t ⢠U s e r i n t e r f a c e / s u p p o r t i n g d o c u m e n t a t i o n Traffic bottlenecks Outreach and traini ng material s ⢠Traffic volumes ⢠Web in formation clearinghous e ⢠Transportation infrastructure inve nt ory Note: Compone nts no t marked as commodity -flow-related are not critical or may be c ons id ered optional.
⢠A cargo or freight component can be associated with many physical transportation components and/or freight func- tions or role components. ⢠A physical transportation component, a cargo or freight component, and a freight function or role component can produce freight-related data. Likewise, freight-related data can be associated with many physical transportation com- ponents, cargo or freight components, and/or freight func- tion or role components. National Freight Data Architecture Specifications This section describes some of the most relevant specifica- tions to implement and develop the various national freight data architecture components described in the previous sec- tion. Readers should note that the list of specifications is pre- liminary and might need refinement during the process of building the data architecture. The specifications described in this section are as follows: ⢠Compare candidate data architecture implementation concepts; ⢠Develop implementation plan for national freight data architecture components; ⢠Develop lists of components to include in the national freight data architecture; ⢠Develop and implement protocols for continuous stake- holder participation; ⢠Conduct data gap analysis; ⢠Conduct data disaggregation need analysis; ⢠Assume a distributed approach (as opposed to a centralized approach) to freight data repository implementations; ⢠Use a systems engineering approach for developing the na- tional freight data architecture; ⢠Use standard information technology tools and procedures; 66 Business Process C Documentation Business Process B Documentation Business Process A Documentation Cargo Documentation Freight Role Documentation Transportation Component Documentation Freight Data Documentation Freight Data Model Documentation Data Standard Documentation Data Source Documentation Business Process D Documentation Figure 12. National freight data architecture component conceptual model.
⢠Develop and/or use standardized terminology and defini- tions for each data architecture component developed; ⢠Implement strong privacy protection strategies; and ⢠Establish integration points with other data architectures and standards. Compare Candidate Data Architecture Implementation Concepts As previously mentioned, there are several potential imple- mentation levels for a national freight data architecture, in- cluding the following: ⢠Single-application approach. In this case, the national freight data architecture would become the manner in which data elements are organized and integrated for a spe- cific freight application or business process at the national level (e.g., commodity flows). ⢠Intermediate approaches (depending on the number of applications). In this case, the national freight data archi- tecture would become the manner in which data elements are organized and integrated for a specific set of applications at the national, state, regional, and local levels. ⢠Holistic, all-encompassing approach. In this case, the na- tional freight data architecture would become the manner in which data elements are organized and integrated for all freight transportation-related applications or business pro- cesses at the national, state, regional, and local levels. It is not necessary to evaluate all of the candidate implemen- tation levels. However, as the development of the National ITS Architecture demonstrated, comparing various data architec- ture concepts enabled the ITS community to develop a better understanding of the issues, which, in turn, facilitated the decision of which data architecture to pursue. In the case of the national freight data architecture, it is reasonable to expect a scalable implementation path that starts with one applica- tion at one or two levels of decisionmaking and then adds ap- plications and levels of decisionmaking as needed or accord- ing to a predetermined implementation plan until, eventually, reaching the maximum net value. As previously mentioned, data about benefits, costs, or complexity for each level of im- plementation that might enable a quantifiable determination of value are currently not available. Conducting appropriate benefit-cost analyses to obtain this type of information is a necessary activity that needs to occur both at the beginning and at different phases of implementation of the national freight data architecture. A peer exchange recommendation was to use NCFRP as a mechanism for funding the development of alternative data architecture concepts and prototype. Participants indicated the request for proposals should outline clear objectives, while leaving the definition of approaches to the research team(s) selected. An idea discussed was to develop the data architecture around scenarios or themes, such as business areas or pro- cesses, levels of government, and/or economic activity. Partic- ipants identified four potential scenarios or themes, including MPOs, the private sector, cross-border trade (e.g., Washington State and British Columbia, or Texas and Mexico), and multi- state freight (e.g., I-95 corridor, Great Lakes region). Activities and requirements in connection with each of these scenarios or themes would include structuring a competition for research teams (each of which would include a university partner, a private-sector partner, and a government-level partner) to develop and test competing data architecture concepts, mak- ing sure to include multimodal components in the scenarios and tests, and to conduct a follow-up evaluation. The final step would be to merge the best concepts and practices into one composite program. Develop Implementation Plan for National Freight Data Architecture Components Part of the analysis will include developing a plan for component implementation depending on the selected data architecture implementation level(s). The plan, which should include both short-term as well as long-term activities, will enable stakeholders to measure implementation progress and identify corrective actions if needed. The plan should include, at a minimum, the following activities: ⢠Develop lists of components to include in the national freight data architecture; ⢠Develop and implement protocols for continuous stake- holder participation; ⢠Conduct data gap analysis; ⢠Conduct data disaggregation need analysis; ⢠Develop, test, and validate data models; and ⢠Develop an implementation schedule, including both short- term as well as long-term activities. This chapter describes some of these activities in detail. Develop Lists of Components to Include in the National Freight Data Architecture Following Figure 10, the national freight data architecture should include one or more of the following categories of components (depending on the results of the data architecture comparison analysis above): ⢠Physical transportation components. The physical trans- portation components refer to all the components used to transport cargo or freight. For each component, it will be necessary to identify the relevant data models to include in the data architecture, using as a reference existing systems 67
and databases. Examples of components (which could in- clude subtypes to provide adequate disaggregation level support) include the following: â Vehicle, â Container, â Transportation network, and â Traffic control system. A mode of transportation describes a functional combi- nation of vehicles, containers, transportation network, and traffic control. Common modes of freight transportation in the United States are air, rail, truck, pipeline, and water. The developer should note that some applications (e.g., CFS and FAF) use special mode of transportation designations for intermodal movements that do not necessarily conform to the definition above. The national freight data architecture will need to handle these special cases at the data model level. ⢠Cargo or freight. Cargo or freight refers to the various com- ponents that describe the goods being transported. For each component, it will be necessary to identify the relevant data elements to include in the data architecture, using data ele- ments already included in existing standards (e.g., EDI standards) as a reference. A small sample of components in this category, which could be expanded as needed, includes the following: â Bill of lading, â Commodity, â Invoice, â Item or product, â Purchase order, â Shipment, and â Waybill. ⢠Freight functions or roles. Freight functions or roles refer to the type of responsibility a stakeholder has in relation to freight transportation. Depending on the data architecture implementation level selected, this part of the analysis will include developing a map of functions and the typical kinds of freight data that each function requires. A situation in which this type of mapping is necessary is when trying to identify different levels of data access to different stake- holders. Examples of roles (which could include subtypes to provide adequate support for roles at different disaggre- gation levels) include the following: â Analyst, â Carrier, â Fixed infrastructure manager or operator, â Planner, â Policymaker, â Producer or manufacturer, â Regulator, â Researcher, â Shipper or receiver, and â Third-party logistics or broker. ⢠Business processes. Business processes refer to the various types of activities that different stakeholders have in rela- tion to freight transportation. Depending on the data ar- chitecture implementation level selected, this part of the analysis will include developing formal representations of freight-related business processes using industry-standard business process modeling tools. Examples of high-level business processes (which could include subtypes to pro- vide adequate support for business processes at different disaggregation levels) include the following: â Commodity flows; â Congestion management; â Customs processing; â Development and economic incentives; â Economic analysis and impact; â Energy and climate change; â Environmental impacts; â Hazardous material handling; â Incident response; â Industry and state needs; â International trade; â Logistics management; â Marketing and grant funding; â On-board security monitoring; â Planning and forecasting; â Policy development; â Roadside safety inspection; â Routing and dispatching; â Safety analysis; â Transportation infrastructure analysis, design, and construction; â Transportation operations; and â Workforce development and training. One of the first activities while developing the national freight data architecture will be to assemble a prioritized list of business processes for implementation. ⢠Data sources. Data sources refer to systems, databases, data collection programs, reports, and other similar prod- ucts and activities that can be sources of freight data. Ex- amples of data sources (which could include subtypes to provide adequate support for data sources at different dis- aggregation levels) include the following: â Administrative records, â Census, â Data standards, â Mandatory reporting required by laws and regulations, â Surveys, â Other private-sector data, and â Other public-sector data. It will be necessary to develop a properly cross-referenced index of data sources, using as a foundation already existing systems such as BTSâs TranStats (137). One of the activities 68
to complete will be to formulate recommendations for po- tential upgrades to TranStats to include other freight-related data sources, including state agencies and private-sector data sources. Based on experiences with other systems and ar- chitectures (e.g., the National ITS Architecture) one of the requirements in this area also will be to include archived freight data capabilities in the data architecture. ⢠Freight-related data. Freight-related data refer to the var- ious types of data that can be associated with each of the components previously mentioned (i.e., physical trans- portation components, cargo or freight, business functions or roles, business processes, and data sources). Freight- related data can be associated with just one component or in connection with the interaction between two or more components. For example, in the supply chain, a product or order must have relevant information about different re- quirements, situations, and conditions that might influence the movement from origin to destination. This information is needed for a variety of reasons, including payment, ship- ment, safety and recall purposes, and documentation to affected stakeholders. Some of the most commonly used types of freight data, as well as types of freight data that users do not have but would see benefit in having, include the following (while developing the national freight data architecture, it will be necessary to assemble a comprehensive inventory of freight data types and prioritize those types for implementation): â Descriptions of products shipped or received; â Shipment origins and destinations; â Shipment weight; â Freight volumes; â Manifests and waybills; â Carrier used; â Railroad tonnage data; â Commodity inventories; â Licensed carrier data; â Vehicle inventories; â Business directories; â Employment by freight activity; â Import and export statistics; â Mine output data; â Economic data; â Transportation infrastructure inventory and condition; â Pipeline volumes; â Traffic volumes; â Distribution warehouse truck traffic data; â Travel time, speed, and delay data; â Traffic bottlenecks; â Oversize and overweight permitting and routing data; â Safety data; â Fuel statistics; and â Emissions data and estimates. ⢠Freight data models. Freight data models refer to the set of data models needed to represent freight data characteristics and processes. Depending on the level of freight data archi- tecture implementation selected, this part of the analysis will include selecting, developing, testing, and validating the corresponding data models needed. Typical data models might include the following: â Business process model, â Conceptual data model, â Logical data model, â Physical data model, and â Data dictionary. An alternative (or complement) to a data dictionary is a metadata document (138). Examples of metadata stan- dards at the federal level are CSDGM (106), described ear- lier, and the Metadata Encoding and Transmission Stan- dard (METS) (139). METS, which is maintained by the Library of Congress, is a standard for encoding descrip- tive, administrative, and structural metadata about library objects. ⢠Freight data standards. Freight data standards refer to documents that include specific requirements about struc- ture, syntax, and content of freight data. The developer of the national freight data architecture will not be responsi- ble for developing freight data standards. However, at a minimum, the data architecture developer should formu- late recommendations for communication protocols with organizations responsible for developing relevant data standards and include âplace holdersâ for data standard cross-references in the data architecture. Examples of data standards that pertain to freight information include the following: â Commodity and product classification standards CPC HMIS HS NAPCS NMFC NST 2007 PLU SCTG STCC â Industrial classification standards ISIC NAICS SIC SITC â Data exchange standards ANSI ASC X12 standards UN/EDIFACT standards OASIS UBL standards FIPS PUB 161-2 69
â National ITS standards â FGDC-sponsored standards (including metadata) â Other standards ITDS SDS METS Vehicle classification standards. ⢠User interface and supporting documentation. User in- terface and supporting documentation refer to the system components and materials needed to present and dissem- inate information about the data architecture effectively. As the previous chapter shows, which confirms the find- ings of several reports, freight data are scattered across many systems, jurisdictions, and business processes. Having an information clearinghouse that describes these freight data sources and how they relate to the national freight data architecture will be critical to assist in the process of under- standing and developing the data architecture. Depending on the data architecture implementation level selected, it will be necessary to develop interfaces and materials such as the following: â Web-based information clearinghouse. The purpose of the web-based information clearinghouse is to describe and explain the various components of the national freight data architecture interactively. Examples of sys- tems that can be used as a reference to build this Web- site include the National ITS Architecture Website (87) and TranStats (137). Companion documentation to the Web-based system could include data models (see above), system design documents, and other standard reference materials. â Outreach and training materials. Examples of outreach and training materials include brochures, summaries, presentation files, instructor notes, and handouts to as- sist in the process of disseminating information about the national freight data architecture for use in venues, such as conferences, workshops, and courses. Develop and Implement Protocols for Continuous Stakeholder Participation Lack of proper stakeholder participation is one of major rea- sons for systems to fail. The developer of the national freight data architecture should develop channels of communication and mechanisms to ensure and document the participation of stakeholders at every step during the development of the data architecture. Specific requirements, in addition to those in connection with the implementation of the information clear- inghouse and training materials, include the following: ⢠Articulate messages clearly, ⢠Provide clear, uniform guidance, ⢠Develop communication and marketing strategies, ⢠Identify and address buy-in and consensus issues, ⢠Identify and develop working relationships with data ar- chitecture champions, ⢠Develop a âshowcaseâ to bring attention to the issue of freight data, and ⢠Develop a roadmap for collaboration between the public sec- tor and the private sector for more effective data collection. Conduct Data Gap Analysis This report documented the results of a literature review, surveys, and follow-up interviews with a number of freight stakeholders, primarily planners, shippers, and motor carri- ers, to identify user and data needs. Targeted data gap analy- ses may be necessary to more precisely characterize user and data needs. This report identified (or further expanded on) a few areas where there are freight data gaps. Some gaps are related to limitations of current survey-based data col- lection programs. Other gaps are related to limitations in supply chain data processes or to the high degree of special- ization of certain processes (e.g., shippers may have com- modity data at a high level of disaggregation, but carriers do not need that level of commodity disaggregation to con- duct business transactions). Part of the process to identify data needs will be to develop a thorough understanding of the relationship between freight performance measures (many of which are still in the research and development phase) and the data needed to support those measures. Conduct Data Disaggregation Need Analysis Plenty of documents provide information about the lim- itations of current freight data collection programs, adding weight to the idea that current data sources are not suffi- ciently accurate or detailed. The data resolution issue is par- ticularly critical because no statements are currently avail- able that outline (1) the required data disaggregation and accuracy levels to address current and anticipated data col- lection needs from a technical and statistical perspective and (2) the corresponding impacts of those requirements on data collection costs and privacy requirements. Developing those statements is critical in order to identify data collec- tion requirements. Dimensions to freight data disaggregation could include areas such as commodity type disaggregation, geographic disaggregation, temporal disaggregation, financial data dis- aggregation, operating data disaggregation, and privacy re- quirements. Conducting the data disaggregation analysis is a significant effort. (Note that NCFRP Project 20 will address the issue of commodity flow geographic disaggregation). 70
Assume a Distributed Approach (as Opposed to a Centralized Approach) to Freight Data Repository Implementations As previously mentioned, freight data are scattered across many systems, jurisdictions, and business processes. This prac- tice is not likely to change any time soon. The availability of computerized processes that automate the collection and transmission of freight data will continue to increaseâand the freight community should strive for continuous improve- ment and optimization of those processes. However, in the short to mid term, the chances for freight data exchange pro- grams to succeed will depend greatly on the identification of integration points among disparate data systems; documenta- tion of the location, characteristics, and limitations of those in- tegration points; and the development of tools and processes (e.g., data conversion tools and survey tools) to facilitate data exchange. Use a Systems Engineering Approach for Developing the National Freight Data Architecture Systems engineering is an interdisciplinary approach to project development that focuses on the identification of user needs and required functionality early in the development process, documenting those requirements, and executing sys- tem verification and validation plans at different points dur- ing the development (140). Systems engineering is frequently used for the development of complex engineering and soft- ware projects, including many ITS implementations around the country. Considering the complexity that characterizes freight data processes, it would be advisable to use a systems engineering approach for the development of the national freight data architecture (and any system implementation that could result from that effort). Key systems engineering principles that could apply to developing the national freight data architecture include the following (140): ⢠Keep an eye on the finish line, ⢠Stakeholder involvement is key, ⢠Define the problem before implementing the solution, ⢠Delay technology choices, ⢠Divide and conquer, and ⢠Connect the dotsâmaintain traceability. Another tool in systems engineering that is frequently used, the âVâ diagram (Figure 13), could also be used for develop- ing the national freight data architecture (140). The V diagram shows the steps for developing systems, including the integra- tion of validation activities throughout the process. Use Standard Information Technology Tools and Procedures In addition to the requirement to use a systems engineering approach is the requirement to use industry standard informa- tion technology tools and procedures (including data model- ing, database, and software development tools) to develop the various components of the national freight data architecture. The choice of tools will need to take into consideration exist- ing federal-level enterprise architecture requirements (141). 71 Figure 13. Systems engineering âVâ diagram (140).
Develop and/or Use Standardized Terminology and Definitions for Each Data Architecture Component Developed This requirement affects both information technology terms (such as architecture, data architecture, system, data- base, and framework) and freight transportation business process terms. This report includes a number of definitions the developer of the national freight data architecture should take into consideration. The developer also should note the various sources of freight-related terms and definitions that will need to be reconciled, particularly in the case of defini- tion sources at the federal level. Examples of sources include the following: ⢠BTSâs dictionary (142), ⢠CFS definitions (33), ⢠Economic Census definitions (143), ⢠Glossary from the Energy Information Administration (EIA) (144), ⢠FAF2 data dictionary (63), and ⢠IANAâs glossary (145). Implement Strong Privacy Protection Strategies The national freight data architecture will need to comply with (and/or provide support to) the privacy provisions of the E-Government Act of 2002 (135, 136). Requirements in this act include conducting privacy impact assessments to document what information is to be collected, its purpose and intended use, information sharing practices and security measures, opportunities for consent, and whether a system of records is created following Privacy Act provisions. Beyond these legal requirements, the analysis will need to take into consideration confidentiality and anonymity requirements in connection with the participation of private-sector stake- holders (e.g., producers, shippers, and carriers) in data col- lection programs that result from the implementation of the national freight data architecture. Establish Integration Points with Other Data Architectures and Standards Although the main focus of the national freight data ar- chitecture will be freight planning (at least initially), it will need to provide support to, or ensure compatibility with, other data architectures. The national freight data architec- ture will also need to provide support to, or ensure compat- ibility with, applicable data standards. As previously men- tioned, although the developer of the national freight data architecture will not be responsible for developing freight data standards, the data architecture developer should for- mulate recommendations for communication protocols with organizations responsible for developing relevant data standards and include âplace holdersâ for data standard cross-references in the data architecture. Challenges and Strategies This section outlines some of the most relevant issues and challenges that might block the implementation of the national freight data architecture, as well as some candidate strategies for developing, adopting, and maintaining the data architecture. Challenges and Potential Impediments to Successful Implementation Technical Challenges Technical challenges refer to issues (e.g., technological lim- itations, hardware and software incompatibilities, and stan- dards incompatibilities) that might impede the successful implementation of the data architecture. Examples include the following: ⢠The national freight data architecture will be successful only if it meets the expectations of the freight community. This report laid out several implementation approaches for a national freight data architecture. Are the approaches appropriate? Will it be necessary to identify additional alternatives? What is the implementation horizon for each alternative? ⢠Data storage requirements may be enormous, even under a distributed, multi-agency data repository model. Will the key agencies responsible for managing the data have the necessary technical infrastructure and resources needed (e.g., servers, database system(s), and other applications) to undertake that task successfully? ⢠There may be tabulation errors and redundancies if more than one stakeholder needs to enter the same data. Ideally, data should be entered only once. However, is this scenario realistic with todayâs technologies, processes, and resources? ⢠Many motor carriers still rely on fax transmissions to move freight. Who will enter relevant data into a database to facil- itate the collection of shipment data at the national level? Is it necessary for all motor carriers to be computerized? Is it necessary to collect data about all shipments? ⢠Upgrading computer systems at carriers and other freight stakeholders to support key elements of the national freight data architecture might take many years to implement, particularly if the objective is to obtain commodity flow data at finer levels of resolution. Financial considerations 72
aside, how feasible is it to deploy EFM and other similar initiatives throughout the entire supply chain? Even if computer systems are upgraded, one of the challenges would be how to address issues such as the common use of the generic freight-all-kinds freight classification to all shipments from a shipper regardless of freight commod- ity or type. ⢠Measurement units for commodities are different depend- ing on the stakeholder. Further, commodity code classifi- cations are different depending on the stakeholder. Is it possible to develop a comprehensive classification sys- tem that enables all crosswalks so that it could work for all stakeholders? ⢠Some data are not available in a timely fashion. For exam- ple, one agency reported that waiting for year-end reports did not allow the agency to find reporting irregularities early, forcing the agency to collect data on a quarterly basis. Feed- back from the private sector indicates that the private sec- tor does not make business decisions based on data they perceive to be old (e.g., CFS data). Under what circum- stances is it possible to collect data more frequently than the current practice? ⢠Data quality control practices vary widely. How will differ- ent datasets be compared and integrated in a reliable way, even if datasets are not physically merged? ⢠There are substantial differences in terminology, data item definitions, and data implementations among freight data stakeholders. How feasible is it to identify integration points among disparate data systems; document the location, char- acteristics, and limitations of those integration points; and develop tools and processes (e.g., data conversion tools and survey tools) to facilitate data exchange? ⢠Not all data components may be necessary or should be considered high priority. Of course, whether a data com- ponent is important, urgent, or relevant is relative and depends on many factors. For example, a planner who is engaged in freight forecasting at the national level might not be interested in regional correlations between carrier operating data and transportation infrastructure charac- teristics and conditions. However, these data components are important to a regional planner who is developing rec- ommendations for transportation improvement plans at the regional or state levels. ⢠Integrating data from shippers and carriers to character- ize commodity movements properly may be challenging. Although both shippers and carriers are increasingly using EDI technologies, the type of data they collect is not neces- sarily the same. For example, a shipper might record com- modities and O-D locations, but not routes. Similarly, a carrier might record routes and some generalized descrip- tion of the commodities being transported, but not in a way that facilitates integration with shipper-produced data. ⢠Different stakeholders have different data confidentiality and data security concerns. Incorporating strong data secu- rity measures will be critical. However, there are technical challenges that would need to be addressed to make sure proper access is provided to users while complying with strong security standards. Policy Challenges The national freight data architecture might fail if re- quired policies, both in the public and private sectors, fail or are not feasible. Examples of policy challenges include the following: ⢠Homeland security concerns may limit the dissemination of certain freight data. All import and export cargo is doc- umented, yet the resulting data are not shared effectively among transportation planning agencies. Can interagency agreements be implemented to ensure that authorized per- sonnel have access to relevant data in a timely manner, not just for hazardous materials as in the case of the HIP? ⢠Today, a number of private-sector associations, such as AAR and ATA, collect data from, or on behalf of, their members. What would be the impact of a national-level data collection effort on those initiatives? ⢠Anecdotal information suggests that collecting freight and company data is more difficult in the United States than in other industrialized countries due to differences in soci- etal perceptions about the needs for, and benefits of, gov- ernment regulation. However, freight and company data are widely exchanged daily (and voluntarily) by millions of trading partners in the private sector. Is it possible to recon- cile these seemingly contradictory positions in a way that enables the collection of valuable data for freight transporta- tion planning purposes? Is it possible to guarantee confiden- tiality and anonymity for data providers? Economic and Financial Challenges The national freight data architecture might fail if the perceived costs associated with its implementation exceed the benefits that stakeholders would receive. Examples of economic and financial challenges include the following: ⢠The cost of data collection, storage, and quality assurance will be enormous. Who will bear the cost of the imple- mentation and how will the implementation be funded? Will users need to pay to access the data? If so, under what circumstances? ⢠Benefits from the implementation of the national freight data architecture might not materialize if the relation- ship between finer levels of data disaggregation and those 73
benefits has not been clearly established. What are the re- quired levels of data disaggregation for different business processes? ⢠Access to data produced by private-sector data aggregators could be limited if the cost to acquire the data is prohibitive. Large organizations might be able to afford the data, but smaller organizations would not. What are the implications? ⢠Different stakeholders have different data confidential- ity and data security concerns. Incorporating strong data security capabilities may be expensive, although necessary. Who will bear the cost for the implementation of those capabilities? Stakeholder Buy-In and Consensus The national freight data architecture might fail if there is no stakeholder buy-in or consensus about the potential ben- efits that could result from implementing the data architec- ture. Examples of related issues include the following: ⢠Stakeholders might be reluctant to participate if there is no clarity as to why they should participate or what kind of short-term and long-term benefits stakeholders could derive from participating. It will be critical to involve stake- holders early and often. ⢠Confidentiality clauses are often included in the contracts between supply chain trading partners. Participation in a national data collection program might compromise com- petitive advantages. Is it possible to implement strong pri- vacy and confidentiality elements in the data architecture to satisfy the requirements of all the parties involved? ⢠Opposition could surface if there is a perception that data collected as part of a national freight data collection pro- gram could be used to validate projects of national signifi- cance at the expense of small or rural communities. ⢠Small carriers (e.g., independent owner-operators) might not have the ability to provide data about loads they move. ⢠If the number of stakeholder participants is too low, the re- sulting data might not be representative. It is important to ensure a minimum sample size to guarantee data reliability. ⢠Not all data standards may be adequate to support key elements of the national freight data architecture. What will be the challenges to obtain stakeholder support to upgrade those standards or to develop new standards that might be necessary? Strategies for Successful Implementation Strategies to ensure the successful implementation of the national freight data architecture include the following: ⢠Develop and compare candidate data architecture concepts. As previously mentioned, there are several possible imple- mentation approaches for a national freight data architec- ture, some more ambitious and comprehensive than others. Completing the exercise of comparing data architecture concepts will enable stakeholders to develop a better under- standing of the issues, which, in turn, will facilitate the development of a data architecture that meets stakeholder expectations. ⢠Identify business process and implementation level prior- ities and develop high-quality data architecture concepts and applications that address the needs of the highest priority items first. A successful initial implementation will increase the chances of success for future expansions of the data architecture. ⢠Identify data architecture leaders and champions. It is important to include representatives of the public sector (including federal, state, regional, and local levels) and the private sector (including producers, shippers, carriers, and third-party logistics and brokers). ⢠Engage the national freight data architecture champions early, identify major progress milestones, and maintain good communication channels with the various stakeholders dur- ing all phases of the development and implementation of the national freight transportation data architecture. ⢠Identify funding mechanisms for the implementation of the data architecture. ⢠Develop criteria for measuring the effectiveness in the implementation of the national freight data architecture. ⢠Tie the implementation of the national freight data archi- tecture to the development of metrics or performance mea- sures that could benefit the entire freight transportation community. Participation is likely to increase if the value proposition to stakeholders makes it clear how the data col- lected can help those stakeholders realize improvements in productivity (e.g., if the data collection program enables the identification of potential chokepoints in the supply chain). ⢠Accelerate the implementation of programs such as EFM and the freight performance measurement program. These programs are laying out the foundation for the collection of freight data at levels of disaggregation not possible before. ⢠Identify data needs at the finest disaggregation level and implement data collection and data storage plans at that level. This strategy will help stakeholders eliminate redun- dancy in data collection. ⢠Develop brochures, presentations, and other materials that explain the national freight data architecture, its scope, high-level components, and what it expects to accomplish. It will also be critical to deliver effective messages on how the national freight data architecture will assist stakehold- ers in the identification of strategies to address various freight-related issues ranging from data collection to analy- sis and reporting. Just as importantly, it will be critical to deliver messages that provide clear, concise answers to the 74
various challenges highlighted in the previous section. As previously mentioned, there is confusion in the freight transportation community about what the national freight data architecture initiative is. Presenting a clear message to the community will increase the chances of success. ⢠Articulate benefits of participation by the private sector and identify opportunities for publicâprivate partnerships to make data accessible for transportation planning pur- poses in a cost-effective manner. Obtaining data from the private sector frequently has been challenging, which high- lights the need to identify creative strategies to address this issue (e.g., by highlighting that existing freight data issues also affect the private sector, by contacting the right person at a sufficiently high administrative level for discussions about data access and sharing). A requirement for these partnerships is to ensure no competitive disruptions as a result of participation. ⢠Take into consideration lessons learned from the imple- mentation and maintenance of existing freight-related sys- tems and architectures. Chapter 2 included a detailed re- view of a sample of those systems, which included topics such as purpose, content, institutional arrangements; chal- lenges and issues faced; strategies and methods for dealing with data integration issues; and adaptability. 75