United States Department of Transportation - Federal Highway Administration FHWA HomeFeedback

Regional ITS Architecture Guidance Document

TOC      Previous Page      Next Page

2 Developing a Regional ITS Architecture

This section provides an overview of a representative regional ITS architecture development process. In subsequent sections, each step in the process is described in more detail, defining the major activities, identifying the important inputs and outputs, and providing tips, resources, and cautionary advice that reflect lessons that have been learned in development of many regional ITS architectures over the past several years.

Development of a regional ITS architecture actually occurs in the context of broader regional planning, programming, and project development processes. The relationship between the regional ITS architecture development process described in this section and the regional planning and programming processes is described in detail in sections 1.1 and 7.2. The relationship between the regional ITS architecture and the project implementation process is described in section 7.3.

CautionMany different processes can be used to develop a regional ITS architecture. The objective of this section is NOT to define a single process that should be universally adopted. If you have a process that works, and it generates all the products that are required by the final rule/policy, then feel free to continue to use your process. If you don't have an existing process, then the process described in this section can be a good starting point for tailoring a regional ITS architecture development process that best meets your needs.

Figure 1 shows six general steps in the "lifecycle" of a regional ITS architecture. In the first four steps, the regional ITS architecture products are developed and then these products are used and maintained in steps 5 and 6. The development process begins with basic scope definition and team building and moves through increasingly detailed steps, culminating in specific products that will guide the "implementation" of the regional ITS architecture. An overview of each step in the process follows:

The six general steps in the lifecycle' of a regional ITS architecture: Step #1: Get Started, Step #2: Gather Data, Step #3: Define Interfaces, Step #4: Implementation, Step #5: Use the Regional Architecture, Step #6: Maintain the Regional Architecture


Figure 1: Regional ITS Architecture Development, Use, and Maintenance


Get Started: The regional ITS architecture effort begins with a focus on the institutions and people involved. Based on the scope of the region, the relevant stakeholders are identified, one or more champions are identified, the team that will be involved in architecture development is organized, and the overall development effort is planned. This step defines "who" will be involved with (and served by) the architecture and how the regional ITS architecture development will be structured.

TipAlthough a regional ITS architecture development effort is much smaller than a major construction project in terms of financial expenditure, an architecture development effort is institutionally complex because it is so inclusive. Architecture development planning, particularly for outreach and consensus building, is an important factor in a successful regional ITS architecture development. Allow sufficient time for this outreach and consensus building when planning the overall effort.

Gather Data: Once the stakeholders are involved and a plan is in place for assembling their input into a consensus regional ITS architecture, the focus shifts to the ITS systems in the region. At this step, the existing and planned ITS systems in the region are inventoried, the roles and responsibilities of each stakeholder in developing, operating, and maintaining these ITS systems are defined, the ITS services that should be provided in the region are identified, and the contribution (in terms of functionality) that each system will make to provide these ITS services is documented.

Define Interfaces: Once the ITS systems in the region are identified and functionally defined, the existing and planned interfaces between these systems are defined. First, the connections (or "Interconnects") between systems are identified, and then the information that will be exchanged on each of the interfaces is defined.

Implementation: Once the system interfaces are defined, additional products can be defined that will guide implementation of the projects that will flow from the regional ITS architecture. These include a sequence of projects, a list of needed agency agreements, and a list of standards that can be considered for project implementation.

Use the Regional ITS Architecture: The real success of the regional ITS architecture effort hinges on effective use of the architecture once it is developed. The regional ITS architecture is an important tool for use in transportation planning and project implementation. It can identify opportunities for making ITS investments in a more cost-effective fashion. This step is where the benefits are realized.

Maintain the Regional ITS Architecture: As ITS projects are implemented, the region's needs evolve, and new services are added to the National ITS Architecture that weren't originally considered, the regional ITS architecture will need to be updated. A maintenance plan is used to guide controlled updates to the regional ITS architecture baseline so that it continues to accurately reflect the region's existing ITS capabilities and future plans.

While this may look like a sequential process where each step is completed before beginning the next, the actual development process is normally iterative and tasks will frequently be performed in parallel. For example, in step #1, the scope of the region may be adjusted as new stakeholders are identified and they begin to suggest changes to the regional boundary. Similarly, new stakeholders are frequently identified as the inventory for the region is defined, causing iteration between step #2 and step #1. It is also common for changes to the inventory to be made as interfaces are defined, causing iteration between steps #3 and #2. This "two steps forward and one step back" progression is a normal part of the process.

Security Considerations

SecurityThe regional ITS architecture development effort provides an important opportunity to address security early in the planning process. Experience shows that security can be a stumbling block in systems integration if it isn't considered early in the process. The regional ITS architecture should address security so that the integration opportunities that are identified do not adversely impact the mission-readiness of the regional transportation system. The regional ITS architecture provides a natural starting point for a top-level security policy and strategy for a secure regional transportation system.

ResourcesVersion 5.0 of the National ITS Architecture added focus on security and included a Security Document that provides background information, a list of resources, and specific guidance for addressing security in a regional ITS architecture. This document is available at: http://www.iteris.com/itsarch/documents/zipped/security.zip.

TOC      Previous Page      Next Page FHWA