The Architecture Scope sets the context for all of the other components shown below. The definition of geographic, timeframe, and scope of services informs the decisions made by developers regarding what stakeholders, elements, services, etc. to include in the architecture.

Regional ITS Architecture Scope

Updating an Existing Architecture's Scope

Updating an existing regional ITS architecture begins with the consideration of whether the definition of the region has changed since the previous version of the architecture. Generally, the scope of a regional ITS architecture can be defined in three ways:

1)            Define the geographic area covered by the architecture. What cities, counties, states, corridors, or other special areas does it include? 

2)            Define the planning timeframe or "time horizon" that the regional ITS architecture will address. Should the architecture encompass systems and services that are implemented over the next ten years, or twenty years?

3)            Specify the general scope of services that are included. For example, should the architecture cover commercial vehicle services?

These three "dimensions" of the scope are explained in more detail below:

Geographic Area

Ideally, the previous geographic scope of a region was established so that it encompasses all systems that should be integrated together. In practice, it is sometimes difficult to determine where to draw the line so that the regional ITS architecture is inclusive without expanding to the point that the effort becomes unmanageable and consensus is difficult to achieve. While this is frequently called a "geographic" area, it is usually a political map that is being partitioned, defining a region along existing institutional boundaries.

The regulation states that metropolitan areas must consider the metropolitan planning area (MPA) as a minimum size for a region. The MPA is a good place to start since this boundary normally encompasses most integration opportunities and it coincides with the geographic region used for transportation planning. In practice, the MPA is the most commonly defined geographic region for metropolitan regional ITS architecture, but other geographic regions are sometimes defined.

For example, service boundaries or special conformity boundaries may have been a factor when determining the original regional boundary:

-         Service Boundaries:  Regional transportation agencies and other stakeholders each have geographic areas that they serve (e.g., transit services, toll authorities, etc.). In metropolitan areas, these service boundaries may go outside the metropolitan planning area and influence the regional ITS architecture boundary.

-         Special Conformity Boundaries:  In regions where there are special conformity issues like Air Quality, special conformity boundaries may also be considered. For example, ITS projects that are implemented to meet air quality goals within an air quality conformance boundary may require integration with other projects in the region. In this case the air quality conformance boundary may have been a consideration in establishing the previous geographic area covered by the regional ITS architecture.

When updating a regional ITS architecture, the most common reason to revise the geographic scope is because one or more of the factors discussed above in defining the original geographic scope has changed. One of the most common changes for a metropolitan architecture is that the MPA (often through expansion of the MPA) has been adjusted since the previous version. Sometimes additional counties (or portions of counties) are added to the MPA based on regional growth. In other cases, the creation of regional transportation authorities might impact the service boundary previously considered.

One final consideration for the geographic scope of the architectures is what other regional ITS architectures are adjoining or overlapping with the regional ITS architecture. For example, many states have created statewide ITS architectures that must be taken into account by the metropolitan area architecture(s) in those states. A few agencies have also created their own agency architectures that focus on internal agency interfaces, creating additional levels of architecture definition that should be taken into account in establishing architecture scope. It is not often that the existence of the other architectures will affect the geographic scope of the regional ITS architecture being updated, the other architectures may influence the service scope that is defined for the region.

Special care is required when regional ITS architectures do overlap. Caution should be used whenever the same ITS element or interface is included in more than one regional ITS architecture. Unless automated methods like a relational database or RAD-IT are used, it is almost certain that some difference or ambiguity will arise in the two (or more) representations of the same architecture definition. Whenever possible, it is a good idea to define the ITS element or interface in one architecture and reference the one "authoritative" definition in all other regional ITS architectures.

Time Horizon

The regional ITS architecture should look far enough into the future so that it serves its primary purpose of guiding the efficient integration of ITS systems over time. While there is no required minimum, the most appropriate timeframe should be established based on how the regional ITS architecture will be used. Making the timeframe too short reduces the value of the regional ITS architecture as a planning tool. Making the time horizon too long increases the effort involved in updating the architecture since a longer timeframe usually translates into expanded services and projects.

-         10-Year Horizon:  A ten-year horizon is normally the shortest timeframe that should be considered as it is long enough to include most of the system integration opportunities that can be clearly anticipated by the region's stakeholders. This timeframe is sufficient to support Transportation Improvement Program (TIP) generation and guide project implementation.

-         20-Year Horizon:  A 20-year time horizon is long enough to include all integration opportunities that may be included in the long-range Transportation Plan.

Look at the long range plan time horizon and consider that as a potential upper limit for the architecture.

When a regional ITS architecture is updated, the time horizon is normally carried over from the previous version, but if use of the architecture evolves with each update, then the time horizon may need to be reconsidered. In other words, the timeframe should be adjusted as necessary to match the vision of the stakeholders and the planned use of the architecture.

Service Scope

When an architecture is updated, the previous version has a defined service scope. This scope usually stays the same through each update, but as with the timeframe, if use of the architecture evolves or additional overlapping regional ITS architectures have been developed, then the scope of services may evolve as well. In general, the definition of scope of services is impacted based on the scope of other regional ITS architectures. For example, if a statewide ITS architecture is defining commercial vehicle services, the 511-traveler information system, and the electronic toll collection system for the state, then any other regional ITS architectures in the state may decide to reference the statewide architecture for these services.

Avoid defining the same ITS services in multiple overlapping regional ITS architectures. The redundancy will cause difficulty in maintaining regional ITS architectures so that they are always consistent and complicate architecture use in the region.

Developing a New Architecture's Scope

Developing a regional ITS architecture for the first time begins with a definition of the region. The fundamental scope for the regional ITS architecture is established with the definition produced in this step. The general scope of a regional ITS architecture can be defined in three ways:

1)            Geographic Area: Define the geographic area covered by the architecture. What cities, counties, states, corridors, or other special areas does it include? 

2)            Time Horizon: Define the planning timeframe that the regional ITS architecture will address. Should the architecture encompass systems and services that are implemented over the next five, ten, or twenty years?

3)            Service Scope: Specify the general categories of services that are included. For example, should the architecture cover commercial vehicle services?

See the section on updating the scope of an existing architecture for more details about each of those 3 aspects of scope.

For a new architecture development this process will need to involve discussions among all of the core set of stakeholders discussed in the Stakeholders section. This discussion should start early to help decide who else needs to be involved in the process.

Don't invest too much time trying to define the region perfectly the first time. Remember that developing a regional ITS architecture is an iterative process, and the definition of the region can be adjusted as the regional ITS architecture begins to take shape.

The stakeholders should make a first cut at defining the region and then update the geographic area, time horizon, and service scope as new stakeholders are identified, new integration opportunities are considered, and the ultimate uses for the regional ITS architecture are discussed in more detail.

RAD-IT

There is no separate tab in RAD-IT for architecture scope, but the basic scope information is contained on the Start tab as shown below.

Architecture Scope in RAD-IT

Denver Regional ITS Architecture Scope