Regional Architecture Update/Development Approaches
Update (or development) of a Regional ITS Architecture occurs in the context of broader regional planning, programming, and project development processes. The relationship between the regional ITS architecture update approach is described below and the regional planning and programming processes is described in detail in Regional ITS Architecture Use in Planning/Programming. The relationship between the regional ITS architecture and the project implementation process is described in "Use in Project Development" (use section). Overtime, no matter how the architecture is used it will need to be maintained. See "Architecture Maintenance" for tips and steps on what to include in the maintenance of a regional ITS architecture.
Many different approaches can be used to update (or develop) a regional
ITS architecture. The approach described here is a suggested approach that has
been used by regions throughout the country, but it is NOT the only approach
that will result in an updated architecture that can be effectively used by the
region.
Updating an Architecture
Each region should employ an approach that works best for the unique set of institutional and technical conditions that define transportation planning and project deployment. Any approach that generates all the products that are required by the federal regulation can be followed to update an existing regional ITS architecture (or to develop an architecture if one does not currently exist). If your region doesn't have an existing approach, then the approach described in this section can be a good starting point for tailoring a regional ITS architecture update approach that best meets your needs.
The basic update approach can be described by the following general activities:
These steps represent general activities that will likely be iterated or performed in varying sequences depending on the stakeholder interaction during the update. Each step is described in more detail below. While these steps relate to the update of an architecture, with some slight variation they apply to developing an architecture for the first time (see the Developing a New Architecture discussion below).
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.
Getting started with an update of the regional architecture – whether it's been 3 or 4 years or a decade or more – assumes that there's a good reason or need to update the architecture. The need to update an architecture is driven by change:
1. Changes in the elements and services that are in the architecture, maybe as simple as changing the things that were 'planned' a few years ago to 'existing'
2. Changes in the region itself – new stakeholders, new needs/services anticipated, growing populations centers, etc.
3. Changes in ITS as reflected in the national ITS reference architecture, www.arc-it.net.
Getting started also defines "who" will be involved with (and served by) the architecture and how the regional ITS architecture development will be structured.
Although a regional ITS architecture development effort is much smaller
than a major construction project in terms of financial expenditure, it 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.
As you get started with the update or development of a regional ITS architecture there are 4 activities to consider:
Identify the Need
After so many years of having intelligent transportations systems this may seem like a non-issue – Of course, we need an architecture! Or you may be saying, "We already have an architecture!" The decision to create and/or update an architecture may still be worth exploring to make sure the right stakeholders are involved in the decision and better prepared to take on the rest of the update.
Through this decision process, the development and maintenance of a regional ITS architecture is established as a shared objective by the transportation planning and operating agencies in the region.
A regional ITS architecture is required by the FHWA Regulation (23CFR940) & FTA
Policy for regions that have deployed, or will be
deploying, ITS projects. An examination of the deployed ITS systems, the plans
for future ITS deployments, and system integration opportunities in the region
will establish if the regulation applies and a regional ITS architecture is
required. Every state and virtually every metropolitan region has some form of
ITS. While the regulation establishes a clear "requirement" for a regional ITS
architecture for many regions, the real "need" for a regional ITS architecture
is based more on its utility in ITS project planning and implementation.
The most important reason to develop a regional ITS architecture is that it can help the region to efficiently plan for and implement more effective ITS systems. Thus, the ultimate objective is not to develop a regional ITS architecture that complies with a federal regulation, but to develop a regional ITS architecture that can really be used by the region to guide ITS implementation. A regional ITS architecture that includes all the products specified by the regulation but is never used by the region is not of real benefit to the region or US DOT. To meet the requirements of the regulation, the regional ITS architecture must be used to measure conformance of ITS projects on an on-going basis and be maintained as regional ITS requirements evolve.
The decision to proceed then should actually be based on a clear understanding and commitment by planning agencies, operating agencies, and key decision makers in the region that a regional ITS architecture is needed and will be put to good use. This implies that a decision to proceed should be accompanied by significant outreach and education on the benefits of ITS and system integration and the important role that a regional ITS architecture can play in developing these integrated systems.
There are many good resources available that can
support the outreach and education effort that may be required to realize the
benefits of a regional ITS architecture. USDOT has a website that lists
hundreds documents, web sites, training courses, software tools, and points of
contact covering all aspects of ITS, including ARC-IT and regional ITS
architectures. Check out the Resources page for the US DOT's ITS Joint
Program Office website.
Define the Region
The process of developing a regional ITS architecture begins with a definition of the region and captured as the 'scope' of the architecture.
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. Timeframe: 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. Scope of Services: Specify the general categories of services that are included. For example, should the architecture cover commercial vehicle services?
See "Architecture Scope" in the Definition of a Regional Architecture for more information.
Identify Stakeholders to Participate in the Process
The success of the regional ITS architecture depends on participation by a diverse set of stakeholders. In the early stages of updating or creating a regional ITS architecture, the stakeholders in the regional surface transportation system are identified and the process of encouraging their participation in the regional ITS architecture development process is initiated.
Identification
of participating agencies and stakeholders is one of the required components of
a regional ITS architecture as identified in 23CFR 940.9(d)2 and FTA National
ITS Architecture Policy Section 5.d.2.
See "Updating Stakeholders" in the Definition of a Regional Architecture for more information on how this information is capture in the architecture.
Regions will vary dramatically in the degree to which the surface transportation system stakeholders are aware of ITS. In regions that have already implemented substantial ITS systems, the stakeholders have already been working together on many of the issues that will be addressed during regional ITS architecture development. As a result, these regions usually have existing ITS committees that will be a natural forum to kick-off the regional ITS architecture development.
Other regions will require more significant education and outreach efforts about ITS in general and the merits of a regional ITS architecture in particular to assemble and motivate enough stakeholders. When preparing education and outreach material to introduce stakeholders to the regional ITS architecture, it is a good idea to use local project examples that may already be familiar. If local examples are not available, a variety of excellent material is available from USDOT and other sources.
Educating the right people is important – frequently the education and outreach efforts will target the management levels in an organization where decisions can be made to commit valuable personnel resources to support the architecture development effort. Without management support, it will be difficult or impossible for those with a working knowledge of ITS in the region to participate effectively in the regional ITS architecture effort.
It is
often best to start with a core stakeholder group and then add participants to
the core group over time. The core stakeholders group would itself be a diverse
group with representation from each major agency and from both planners and
system operators. This core group provides continuity to the development effort
and an important set of contacts for the champion(s) and architecture
developer(s). Including too many stakeholders at the start can hinder regional
ITS architecture development progress and discourage people with limited vested
interest in the process. Although the architecture effort should be very
inclusive, a region may have better initial success if they are able to build
consensus among the stakeholders that plan/own/operate ITS systems first before
adding others into the decision making process.
The figure below shows a conceptual view of how stakeholders are added over time to the core stakeholder group. The core group is used to kick-off the effort. The number of active participating stakeholders increases as the architecture development effort begins to generate more detailed and varied products that require broad review and support. The number of active stakeholders may then begin to taper off as reviews are completed, comments are incorporated, and "completed" regional ITS architecture products are published. This same strategy of engagement can be used, but probably on a smaller scale, for periodic maintenance activities that follow.
Stakeholder Identification and Involvement over Time
While the number of active stakeholders begins to taper as the workload is reduced, the graph on the right shows that the total number of stakeholders will continue to increase over time, as different specialties and agencies participate in different parts of the architecture and different steps in the process. The perspective of the graph on the right is that once you are a stakeholder, you are always a stakeholder, although you may not actively participate beyond a specific milestone in the process. Over time, all relevant stakeholders in the region are engaged, just not all at once at the beginning of the architecture development effort.
If it is decided to initially limit the number of participants to a core group as depicted in Figure 57, set a timeframe to add others so that the architecture reflects the broader interests of the region. Table 4 in provides a list of potential stakeholders to consider.
Table 4. Candidate Stakeholders/Participants
|
Area |
Potential Stakeholders |
|
Transportation Agencies |
- State Departments of Transportation (DOT) - Local Agencies (City & County) o Department of Transportation o Department of Public Works - Federal Highway Administration (FHWA) - State Motor Carrier Agencies - Toll/Turnpike Authorities - Bridge/Tunnel Authorities - Port Authorities - Department of Airport or Airport Authority |
|
Transit Agencies/Other Transit Providers |
- Local Transit (City/County/Regional) - Federal Transit Administration - Paratransit Providers (e.g., Private Providers, Health/Human Services Agencies) - Rail Services (e.g., AMTRAK) - Intercity Transportation Services (e.g., Greyhound) |
|
Planning Organizations |
- Metropolitan Planning Organizations (MPOs) - Council of Governments (COGs) - Regional Transportation Planning Agency (RTPA) |
|
Public Safety Agencies |
- Law Enforcement o State Police and/or Highway Patrol o County Sheriff Department o City/Local Police Departments - Fire Departments o County/City/Local - Emergency Medical Services - Hazardous Materials (HazMat) Teams - 911 Services |
|
Other Agency Departments |
- Information Technology (IT) - Planning - Telecommunications - Legal/Contracts |
|
Activity Centers |
- Event Centers, e.g., stadiums, concert halls, convention centers, fairgrounds, ski resorts, casinos, etc.) - National Park & US Forest Services - Major Employers - Airport Operators |
|
Fleet Operators |
- Commercial Vehicle Operators (CVO o Long-Haul Trucking Firms o Local Delivery Services - Courier Fleets (e.g., US Postal Services, Parcel services, etc.) - Taxi Companies |
|
Travelers |
- Commuters, residents, bicyclists/pedestrians - Tourists/Visitors - Transit Riders, others |
|
Private Sector |
- Traffic Reporting Services - Local TV & Radio Stations - Travel Demand Management Industry - Telecommunications Industry - Automotive Industry - Private Towing/Recovery Business - Mining, Timber or Local Industry Interest |
|
Other Agencies |
- Tourism Boards/Visitors Associations - School Districts - Local Business Leagues/Associations - Local Chambers of Commerce - National Weather Services (NWS) - Air & Water Quality Coalitions - Bureau of Land Management (BLM) - Academia Interests, local Universities - National and Statewide ITS Associations (e.g. ITS America, AASHTO chapter members, etc.) - Military |
As additional stakeholders are added to the process, it may be a good idea to retain a core group that meets regularly and have a broader group that is included at selected milestones in the regional ITS architecture development. It is critical that all stakeholders participate enough in the process that they understand the architecture and feel some ownership of the process and the regional ITS architecture that is developed. It is important to continually encourage and validate participation of stakeholders in the development process.
It is
also important to focus stakeholder participation appropriately. For example,
both planners and system operators will participate in the process, but with
substantially different focus. System operators may be more interested in the
operational concepts, functional requirements, and interface definitions, while
the planners may have more substantial input while identifying transportation
needs and services and project sequencing. Other individuals with specialized
knowledge will be needed to assist in development of the list of agreements and
list of required ITS standards. As the "stakeholder roster" is developed,
consider the various areas of expertise that are required and use your stakeholder
resources selectively. Different stakeholders should be engaged in different
parts of the process, consistent with their expertise and interests.
Encouraging broad participation from many agencies, companies, and special interests in the region will occasionally bring people into the process who aren't really stakeholders in the regional transportation system. If the representative doesn't have, or plan to have, a system that should be integrated within the architecture timeframe or an interest in the surface transportation system as a whole (e.g., planners, the tourist industry, other special interests), then the representative is probably NOT really a stakeholder, will have little to contribute, and may ultimately grow frustrated with the process. It is best to understand the role of each potential new stakeholder in the surface transportation system at the outset and determine how they may contribute before significant time is invested. The objective is to be inclusive without wasting the time of those who do not have a vested interest.
Recognize
and respect that everyone's time is limited. Draw participants into the process
without bogging them down. Some useful techniques to encourage people with
demanding schedules to participate are to make sure everyone gets plenty of
time to review documents, and schedule short meetings with teleconferencing
options. This will help retain participants that may otherwise give up on the
architecture effort due to other commitments.
Identifying the Champion(s)
The champion(s) drive the process that must occur in order to develop a regional ITS architecture and build consensus at each step of the development. Without strong leadership, consistent meetings and a plan for completion of tasks, many of the participants will quickly become busy with other daily responsibilities. Regional ITS Architecture efforts that succeed all have a strong champion or champions to lead the effort and make it happen.
How do you identify champions? Many regions have already developed a team of ITS stakeholders that meet on a regular basis. Chances are that the champion(s) have already been identified by the fact that they are leading the regional efforts through an ITS Task Force, Technical Advisory Committee or the fact that they are already leading a major ITS project in the region. Adding regional ITS architecture consensus building to whatever "hat" these people are already wearing will be a natural transition. The process of identifying a champion or champion(s), and developing a task force to put the regional ITS architecture together should be woven into the existing regional planning process for ITS if one is already underway.
Champions are usually not voted-in; they are selected "on the job" in the course of working together. In many regions, a single champion will be identified. If there are several people who rise to the occasion, several champions can be identified that take turns leading the meetings or agree upon some shared responsibilities that will keep everyone engaged. A champion's skills include:
- Understanding of the subject (regional ITS architecture including familiarity with the National ITS Architecture)
- Knowledge of local ITS systems and projects
- Vision for interconnectivity, partnership, and regional integration
- Consensus builder (facilitator)
- Executive level access to resources to gain support for various regional efforts
The skill level that is needed in each area will vary depending on the technical and institutional maturity of the region. A more technically mature region may have many people with existing knowledge of the National ITS Architecture, but require increased skills in consensus building to pull various interests together. In institutionally mature areas that are growing in ITS technology, it may be a strong vision that guides the process. All of the identified skills are important for a strong successful champion along with the knowledge of when to use them.
No one individual is likely to possess all the knowledge and skills required to develop a regional ITS architecture. To be successful, the champion(s) must draw on the knowledge and skills of a diverse set of stakeholders. The champion is primarily a facilitator and manager and is not normally the one that actually defines the architecture – the stakeholders are.
A Champion must be a Stakeholder. It would be very difficult, if not impossible, for someone who did not have a vested interest in the outcome to be the champion for a regional ITS architecture development effort. A stakeholder who is already recognized in the region will best be able to take ownership and invest the time necessary to manage the regional ITS architecture development. FHWA, FTA, consultants, vendors and others are great participants, consultants may even do a lot of the detailed analysis and legwork in a regional ITS architecture effort, but for regional long-term benefit, they should not be champions.
Identifying
more than one Champion from varying backgrounds and disciplines (e.g., public
safety, transit, state DOT, city and/or county traffic engineering) can be a
benefit. A small group of people with diverse backgrounds and contacts can
strengthen the regional ITS architecture product by improving stakeholder
participation, encouraging agency buy-in, and facilitating access to the
information and resources necessary to support architecture development. Where
several champions are identified, they may form a steering committee (which
could also include representation from others such as FHWA/FTA) that manages by
consensus or advises and supports a leader who actually manages the development
and maintenance effort.
Identify Stakeholders introduced the idea of a core stakeholder group that would be involved throughout the architecture development effort. This group might be the small group of "champions" described in the previous paragraph, or it could be a larger group. No one model will encompass all regional ITS architecture development efforts. Each region must decide how they wish to organize their efforts. The key is that there is a group of stakeholders who plays a key role throughout the architecture development effort.
Champions will probably come and go over the evolution of developing
and maintaining the regional ITS architecture, and certainly will change over
the life of regional ITS system implementation and expansion. The task of the
Champion, like other leadership responsibilities, takes significant time.
Dividing the work among a few champions will limit the turnover and ease the
transition when one person leaves. It is important that good meeting minutes
and records of action items are kept so that new champions will have some
guidance regarding when, where, and why decisions were made.
Gather Data
Gathering data is a key activity that may occur several times during the update. The first period of data gathering, which will occur during every architecture update, occurs at the beginning of the update effort and will gather data regarding changes to the core components of the architecture. When the decision is taken to update an existing regional ITS architecture, it may be just a couple years since the last update or it may be a decade or more, so the scope of the changes will vary greatly depending on the timing of the update.
What data needs to be gathered during the initial phase of the update?
Updates to any of the following components described fully in Regional ITS Architecture Definition:
- Regional Goals, Objectives, and Strategies
- Stakeholders, including their Roles and Responsibilities
- Projects
The other components of a Regional ITS Architecture (e.g. functional requirements and standards) are details that are usually updated later in the process rather than at the time of this initial data collection. Many times changes to requirements, interfaces, standards, etc., will be derived from the changes made to the components listed above.
Approaches for Initial Data Gathering
When updating a regional ITS architecture, there are a variety of approaches for the initial gathering of the data listed above.
If the key stakeholders in the region are not familiar with the existing regional ITS architecture, which is often the case when the previous update occurred a number of years ago, then a good first step in the data gathering process is to have a kickoff meeting to bring the key stakeholders together and discuss the regional ITS architecture in general, the current architecture, and the steps that will be taken to update it. This type of meeting can get all the key stakeholders "on the same page" and motivate the work to come.
The data gathering can then commence using any of a variety of methods:
- Interviews (in person or by phone)
- Document reviews (including planning documents, e.g. metropolitan transportation plans, strategic plans, or TSMO plans)
- Stakeholder Surveys
Subsequent Data Gathering
Data gathering can occur at other times during an architecture update. Some of the times when this step may be repeated are:
- After initial architecture update
- After initial architecture review
The data gathered will likely be the same components described above. This data gathering may occur to close gaps in the initial data gathering effort, or to gather additional information from stakeholders after the initial architecture review.
Output of Gather Data Step
This step has two types of outputs
1. Summaries of data gathering inputs
2. List of architecture component changes to be used for the update.
The data collection summaries can be a complete set of all inputs obtained from stakeholders, or a summarization of key results. In the case of interviews or document reviews, a summary of results is the most likely outcome. In the case of stakeholder surveys, a complete set of the data collected is often the result. In some update efforts these summaries may be an actual deliverable, but equally often the data collected remains internal to the development process and serves as the input to the next step.
Update the Architecture
Once key regional data has been collected, the next key step is to create an update to the baseline of the architecture, specifically the RAD-IT file and any other files or documents developed previously.
Establishing the Architecture Baseline
A regional ITS architecture is defined by a baseline, which describes the documents, files, and website (if applicable) that make up the definition of the architecture. The most common parts of an architecture baseline are:
- A Regional Architecture Development for Intelligent Transportation (RAD-IT) file
- An architecture document that summarizes key components of the architecture and likely contains the maintenance plan for the architecture
- Website with a hyperlinked representation of the architecture
Additionally, the baseline could also contain:
- File of Service Package diagrams
- Change spreadsheet or database (to collect architecture changes requested since the previous update)
Updating the Baseline
The actual update of the baseline involves inputting the data collected into RAD-IT or the other baseline files. RAD-IT is organized around a set of Tabs that will need to be updated shown in the figure below:
RAD-IT Main Screen Showing Tabs for Input
The specific components of the regional ITS architecture that will need to be updated are shown below (along with the relevant Tab in RAD-IT if the Tab name differs from the component name). Each of these components is linked to a larger discussion that provides additional information on the component, how the component is represented in RAD-IT, update approaches, and examples of the component from other regional ITS architectures.
- Architecture Scope (on the Start Tab)
- Regional Goals, Objectives, and Strategies (on the Planning Tab)
- Elements (on the Inventory Tab)
- Services
- Stakeholder Roles and Responsibilities (on the R&R Tab)
- Requirements (on the Functions Tab)
- Communications and System Standards (on the Communications Tab)
- Projects (on the Start Tab)
The first step in the update of the RAD-IT (or Turbo Architecture) file
is to convert the starting file (from the last update of the
architecture) into the current version of RAD-IT. This conversion will be an
option the first time you open the starting file in the current version of
RAD-IT. Depending on how long it has been since the last update, the conversion
may cause a large number of possible changes to the architecture since the
underlying reference architecture (ARC-IT) has changed dramatically over the
years.
The changes impact all ARC-IT components and it is a very good idea to
review the Conversion table outputs to understand what has changed in the
architecture – both the regional architecture being converted and changes to
ARC-IT since your regional architecture was last updated.
The updates to RAD-IT can be entered into the file in whatever order the analyst decides, although it's often best to start with changes to stakeholders and elements as these are used in many parts of the update. The updates to RAD-IT and the other baseline files will likely occur several times during the overall architecture update. The goal of the initial set of updates, which usually are confined to the RAD-IT file and a file of Service Package diagrams, is to have a set of key updates that can be shared with stakeholders for review (see the Outputs step below).
An additional output that is usually created prior to stakeholder review is a web-based version of the architecture. RAD-IT has the capability of generating a simple hyperlinked website that represents all the components of the architecture that have been input to the RAD-IT file. In many cases this web-based representation of the architecture is used directly, or placed into an additional set of web pages that may expand upon the basic information generated by RAD-IT. While RAD-IT holds the details of a regional ITS architecture, it is not a particularly good tool for sharing information with stakeholders, with a website providing a more interactive and easily understood representation of the architecture.
Once an initial review of the architecture is held, the files will need to be updated again based on comments received, or additional data collected. The updates continue until the updating agency and the rest of the stakeholders reach consensus on the revised version of the architecture. At this point a final set of files is created and the project is completed.
Generating Outputs
Two key outputs from an architecture update are:
- Updated baseline files, e.g., RAD-IT, with the revisions based on data gathered or comments received from stakeholders.
- Material that can be used to provide stakeholder review. These could include some of the baseline files such as the architecture website and the updated service package diagrams. Additional outputs can be created out of RAD-IT to support stakeholder interaction such as tables to summarize stakeholders, elements, or other components.
You can use RAD-IT to regenerate a set of website files for a regional architecture. RAD-IT also has utilities to generate Word documents for a regional architecture that organize the contents of the architecture into a document format.
Reviewing the Architecture
In order to develop a consensus update to a regional ITS architecture, all of the updates made need to be reviewed with the relevant stakeholders. The inputs from the stakeholders will validate the changes to be made.
There are many ways that stakeholder review can be obtained including:
- Stakeholder meetings: Meeting with a variety of stakeholders is probably the best way to gather inputs. One of the key benefits of updating an architecture is the stakeholder interactions that occur in stakeholder meetings. It is rare in regional settings for operational stakeholders from a variety of disciplines to gather together to discuss their transportation plans. One of things that commonly happens at the meetings is that one agency will hear what capabilities another agency currently deploys, or what their plans for the future are and will say "I didn't realize you were doing that". While these meetings have traditionally been face-to-face, on-line meetings can be equally effective and may draw larger number of stakeholders.
- Website Review: As mentioned above, creating a website version of the architecture is an excellent way for stakeholders to review their part of the architecture. Whether as part of a meeting or off-line these reviews are essential to creating a useful architecture update.
- One-on-One Meetings: While stakeholder meetings are a good way to gather input, the likelihood is that the agency won't get all key stakeholders to a meeting(s), so one-on-one meetings with key stakeholders can help fill in the missing reviews.
In today's distracted world everyone has a lot of demands on their
time. If there is no way to gather people together for a large format meeting
or if a key stakeholder is not available then a webinar may help. A webinar
allows a presenter to control the flow and demonstrate key parts of the
architecture that need to be reviewed. Participants can ask questions and their
inputs can be recorded for review later.
Another key aspect of Stakeholder Review is a discussion of how the architecture will be used and maintained. Additional discussion of Architecture Use for Planning and Project Implementation is discussed on separate pages, as is a discussion of Architecture Maintenance.
An Architecture Review naturally happens once an initial Architecture Update has been performed, and differing aspects of Review will happen until the architecture update is finalized.
Approach for New Architecture Development Effort
The approach to be followed for a new architecture development effort or where the existing regional ITS architecture is more than a decade old is similar to that described above for an update. However, more time and effort may be spent on the tasks under Getting Started to set the stage for the development.
The high-level steps to create a regional ITS architecture are:
Get Started
If a region has never developed an architecture, or the original architecture is so out of date that it cannot really form the basis for an update, then the data gathering step will need to start with a couple of additional steps: Establish the need for the architecture, establish the scope, identify the stakeholders to include, and establish who will be the champion for the effort.
Identify Need
Before beginning development, a region should consider why they are developing the architecture. A regional ITS architecture is required by the federal regulation for regions that have deployed, or will be deploying, ITS projects. An examination of the deployed ITS systems, the plans for future ITS deployments, and system integration opportunities in the region will establish if the rule/policy applies and a regional ITS architecture is required. While the regulation establishes a clear "requirement" for a regional ITS architecture for many regions, the real "need" for a regional ITS architecture is based more on its utility in ITS project planning and implementation.
The most important reason to develop a regional ITS architecture is that it can help the region to efficiently plan for and implement more effective ITS systems. Thus, the ultimate objective is not to develop a regional ITS architecture that complies with a federal rule or policy, but to develop a regional ITS architecture that can really be used by the region to guide ITS implementation. A regional ITS architecture that includes all the products specified by the rule/policy but is never used by the region is not of real benefit to the region or US DOT. To meet the requirements of the rule/policy, the regional ITS architecture must be used to measure conformance of ITS projects on an on-going basis and be maintained as regional ITS requirements evolve. So, definition of a "concept of use" is important to a new development effort. This can be an actual document, or just the results of discussions among key stakeholders. The decision to proceed then should actually be based on a clear understanding and commitment by planning agencies, operating agencies, and key decision makers in the region that a regional ITS architecture is needed and will be put to good use.
Define the Region
The process of developing a regional ITS architecture begins with a definition of the region and captured as the 'scope' of the architecture.
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. Timeframe: 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 "Architecture Scope" for more information.
Identify Stakeholders
The success of the regional ITS architecture depends on participation by a diverse set of stakeholders. In this step, the stakeholders in the regional surface transportation system are identified and the process of encouraging their participation in the regional ITS architecture development process is initiated.
Regions will vary dramatically in the degree to which the surface transportation system stakeholders are aware of ITS. In regions that have already implemented substantial ITS systems, the stakeholders have already been working together on many of the issues that will be addressed during regional ITS architecture development. As a result, these regions usually have existing ITS committees that will be a natural forum to kick-off the regional ITS architecture development.
Other regions will require more significant education and outreach efforts about ITS in general and the merits of a regional ITS architecture in particular to assemble and motivate enough stakeholders. When preparing education and outreach material to introduce stakeholders to the regional ITS architecture, it is a good idea to use local project examples that may already be familiar. Educating the right people is important – frequently the education and outreach efforts will target the management levels in an organization where decisions can be made to commit valuable personnel resources to support the architecture development effort. Without management support, it will be difficult or impossible for those with a working knowledge of ITS in the region to participate effectively in the regional ITS architecture effort.
See "Updating Stakeholders" for more information on how this information is captured in the architecture.
See "Identifying Stakeholders to Participate in the Process" for more about the way you include and educate stakeholders in the update or development of an architecture.
This is similar to the conversations and processes to involve the right operations stakeholders as part of FHWA's initiatives to advance Transportation System Management and Operations (TSMO). From FHWA's website here are some questions that start the conversation for TSMO and apply as well to regional ITS architectures:
- Who owns what routes in the transportation system? (Freeways, arterials, local roads)
- Are we coordinating with the right stakeholders? (State/Local DOT's, Cities, Counties, MPOs, Transit Authorities, First Responders, etc.)
- How are we tracking and monitoring the performance of our transportation system?
- How can we best utilize the data and metrics we have?
- What technology needs should we address to advance TSMO? Is our technology interoperable with other related systems and jurisdictions?
- Do senior leadership and other departments understand TSMO?
Find out more at https://ops.fhwa.dot.gov/tsmo/index.htm.
Identify the Champion(s)
See Identifying the Champion(s) in the section on Updating an Architecture. Whether this is a brand new architecture or an update to an existing architecture the process will need a champion to shepherd the stakeholders through the process. Having a good champion or two from the principle stakeholder agencies involved in the planning, deployment, operations, and maintenance of ITS is a key to the success of the development of an architecture.
Gather Data
Once the need for an architecture has been established, and the champion(s) identified, then the data collection will proceed in a similar fashion as for an update. See Gather Data in the section on Updating and Architecture.
Develop the Architecture
If a region has never developed an architecture, or the original architecture is so out of date that it cannot really form the basis for an update, then this step is about developing an architecture for the first time, rather than performing an update. Many of the steps mentioned in the "Update the Architecture" section still apply, but in the case of the RAD-IT file the region will have to start with a blank slate and develop the initial version of the components.
A recommendation is to start with the region's goals/objectives/strategies,
the lists of stakeholders, elements, services and projects to build an initial
version of the architecture. Convene reviews of the draft components of the
architecture as you go to help achieve early buy-in and continued motivation to
support the process. Once an initial version of the key components has been
developed then it can proceed much like the update steps listed above.
Review the Architecture
This step is essentially the same as described above. It is really important to engage stakeholders in meaningful ways to get them to provide their input. Using large format workshops, webinars, draft websites, and one-on-one interviews all play a part. See "Reviewing the Architecture" for more information.