Architecture Maintenance

Architecture maintenance is the set of procedures put in place by a region to describe the various options and considerations associated with on-going maintenance of the architecture products. This includes detailing the responsibilities for the maintenance as well as the procedures that need to be considered as an architecture is used and maintained over time. Much as ITS systems require planning for operations and maintenance, a plan should be put in place during the original development of the regional ITS architecture and updated as necessary each time the architecture itself is updated.

The development of an architecture maintenance plan and the implementation of a program to maintain the architecture is also a requirement of the ITS Architecture and Standards regulations as identified in 23CFR940.9(f) and FTA National ITS Architecture Policy Section 5.f, which say: "The agencies and other stakeholders participating in the development of the regional ITS architecture shall develop and implement procedures and responsibilities for maintaining it, as needs evolve within the region."

 

Overview

A regional ITS architecture is a plan for the deployment of ITS in a region. Once created, it needs to be updated via a maintenance process that can keep the plan current. The regional ITS architecture will need to be updated to reflect new ITS priorities, strategies and projects that emerge through the transportation planning process, to account for expansion in ITS scope, and to allow for the evolution and incorporation of new ideas. A maintenance process should be detailed for the region, and used to update the regional ITS architecture. This maintenance process should be documented as part of the initial development of the regional ITS architecture in a regional ITS architecture maintenance plan. The goal of the maintenance plan is 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.

 

The purpose of maintaining a regional ITS architecture is to keep it current and relevant, so that stakeholders will use it as a technical and institutional reference when developing specific ITS project plans. A key characteristic of a successful regional ITS architecture is consensus; that is, the notion that each stakeholder has and continues to buy-in to the architecture as the model for how ITS elements have been deployed in a region, and more importantly how future ITS elements should be deployed in the region. A key consideration is Why a Regional ITS Architecture Needs to Be Maintained.

 

The maintenance of the architecture is driven by a set of maintenance decisions that define:

-         Who:  Roles and responsibilities for the maintenance effort

-         When: Update timetable

-         What:  Architecture baseline

-         How: the Approach to Architecture Maintenance, including the change management process and documented maintenance plan

 

The maintenance approach is meant to apply to a wide range of regional and statewide ITS architecture developments. Each architecture development effort will need to tailor the process to meet the needs and resources of their particular region.

 

 

Why Maintain a Regional ITS Architecture

The regional ITS architecture is not static. It must change as plans change, ITS projects are implemented, and the ITS needs and services evolve in the region. The regional ITS architecture must be maintained so that it continues to reflect the current and planned ITS systems, interconnections, services and other aspects of architecture. The following list includes many of the events that may cause change to a regional ITS architecture:

 

-         Changes in regional needs. Regional ITS architectures are created to support transportation planning in addressing regional needs. Over time these needs can change and the corresponding aspects of the regional ITS architecture that address these needs may need to be updated. These changes in needs should be expressed in updates to planning documents such as the Regional Transportation Plan, the TIP, and the ITS Strategic Plan.

 

-         New stakeholders. As new stakeholders become active in ITS the regional ITS architecture should be updated to reflect their place in the regional view of ITS services, elements, interfaces, and information flows. Why might new stakeholders emerge? The stakeholders might represent new organizations that were not in place during the original development of the regional ITS architecture. Or maybe the geographic scope of the architecture is being expanded, bringing in new stakeholders. Or maybe additional transportation modes or transportation services are being considered that interface with the systems of additional stakeholders.

 

-         Changes in scope of services considered. The range of services considered by the regional ITS architecture expands. This might happen because ARC-IT has been expanded and updated to include new service packages or to better define how existing elements satisfy the user needs. A regional ITS architecture based on an earlier version of ARC-IT should take into consideration these changes as the regional ITS architecture is updated. ARC-IT may have expanded to include a service package that has been discussed in a region, but not included in the regional ITS architecture, or was included in only a very cursory manner. Changes in ARC-IT are not of themselves a reason to update a regional ITS architecture, but a region may want to consider any new services in the context of their regional needs.

 

ARC-IT and its accompanying tool, RAD-IT are not updated on a set schedule but on the basis of the program's configuration control process that reviews and analyzes stakeholder inputs and works with US DOT to schedule when the updates should be incorporated. Updates to ARC-IT and RAD-IT will be publicized on the national ITS reference architecture web site: www.arc-it.net.

 

-         Changes in stakeholder or element names. An agency's name or the name used to describe their element(s) undergoes change. Transportation agencies occasionally merge, split, or just rename themselves. In addition, element names may evolve as projects are defined. The regional ITS architecture should be updated to use the currently correct names for both stakeholders and elements.

 

-         Changes in other architectures. A regional ITS architecture covers not only elements and interfaces within a region, but also interfaces to elements in adjoining regions. Changes in the regional ITS architecture in one region may necessitate changes in the architecture in an adjoining region to maintain consistency between the two. Architectures may also overlap (e.g. a statewide ITS architecture and a regional ITS architecture for a region within the state) and a change in one might necessitate a change in the other.

 

There are several changes relating to project definition that will cause the need for updates to the regional ITS architecture.

 

-         Changes due to project definition or implementation. When actually defined or implemented, a project may add, subtract or modify services, elements, interfaces, or information flows from the regional ITS architecture. Because the regional ITS architecture is meant to describe the current (as well as future) regional implementation of ITS, it must be updated to correctly reflect how the developed projects integrate into the region.

 

-         Changes due to project addition/deletion. Occasionally a project will be added or deleted through the planning process or through project delivery and some aspects of the regional ITS architecture that are associated with the project may be expanded, changed or removed.

 

-         Changes in project priority. Due to funding constraints, or other considerations, the planned project sequencing may change. Delaying a project may have a ripple effect on other projects that depend on it. Raising the priority for a project's implementation may impact other projects that are related to it.

           

The above reasons for possible changes in the regional ITS architecture baseline may happen frequently or infrequently, depending upon the region and the specifics of the original regional ITS architecture development effort. This should be taken into account as one set of factors in determining how often to update the regional ITS architecture.

 

Who Is Involved in Architecture Maintenance Effort

Who will maintain the Regional ITS Architecture and what are their Roles and Responsibilities?  Also, who will support the effort, and who will manage or have oversight for the maintenance effort? To maintain a consensus regional ITS architecture, to some extent all stakeholders will need to participate, but typically one or two agencies will take the lead responsibility to maintain the regional ITS architecture.

 

While responsibilities often reside with an individual within the primary organization, maintenance is a recurring activity and is necessarily a long-term effort. So, it is important that the agency responsible for architecture maintenance accepts that responsibility. The responsibility may be delegated to an individual at any given time, but the overall responsibility should be a stated role of an institution or agency in the region. In this way the responsibility transcends the variabilities that can impact an individual person's activities and career. Sometimes this responsibility will be shared by multiple agencies that are part of regional ITS coordinating councils or other groups.

 

If and when the individual responsible for architecture maintenance leaves the organization make sure maintaining the regional architecture is a part of the job description for their replacement.

 

Maintenance Roles and Responsibilities

Two key considerations in defining roles and responsibilities for architecture maintenance are described below.

 

1.     Does the agency responsible for architecture maintenance have the mission and authority to maintain the full stakeholder and functional scope of the regional ITS architecture?

 

The agency that maintains a regional ITS architecture ideally is one that has broad functional responsibilities across the full scope of the regional ITS architecture. In this case, "scope" represents the geographic area of the region, the transportation functions in the region, and the timeframe for deployment of new ITS elements and interfaces in the region.

 

A natural maintainer for many regions is the Metropolitan Planning Organization (MPO). Very often the scope of the MPO will match (or nearly match) the scope of the regional ITS architecture. In cases where the MPO does not possess the resources to manage the effort, or in cases where there is no MPO (e.g. if the "region" is a state) alternate maintainers might be identified. Some other possibilities for maintainer organizations are:

 

-         State Department of Transportation (DOT). A State DOT might take responsibility for maintaining the regional ITS architecture. This particular approach makes the most sense for statewide architectures where the ITS functions are largely the responsibility of the state DOT. But it could also apply to regions that have limited resources available in the MPO.

-         Transportation Authorities. These entities manage transportation infrastructure using a business model that may be relatively independent of those agencies more aligned with the MPO business model. If a Transportation Authority is a stakeholder in a regional ITS architecture, then an agreement between the Authority and the MPO may be necessary to carry on the appropriate maintenance of their common regional ITS architecture.

-         Regional ITS Committees:  Regions often have some institutional framework that make decisions about integration, ITS issues, operations, or procurement. Many areas in the United States address this issue by creating an ITS Committee, Working Group, ITS Program Committee, or Operations Task Force. This institutional group could be responsible for the architecture maintenance, but more likely will have responsibilities in supporting maintenance.

 

When one agency or institution takes responsibility for architecture maintenance, they may use agreements to create a management or oversight function (e.g. a "regional ITS architecture maintenance committee" or "regional ITS architecture maintenance board") to oversee regional ITS architecture maintenance work, which would have representation from the key stakeholders to the agreement. This group might be given management authority over the maintenance process. In this way, the stakeholders are investing in and controlling their own regional ITS architecture, and they will have direct responsibility for the quality of the product.

 

2.     Does the maintainer have the necessary skills and resources to maintain the regional ITS architecture?

 

Depending on the approach used for architecture maintenance (see the Tab on Maintenance Approach) maintaining a regional ITS architecture can require a range of skills. In order to properly evaluate changes to the architecture the maintainer must have staff that is knowledgeable of the existing regional ITS architecture. This implies a detailed technical understanding of the various parts of the architecture and how changes would affect each part. Also required is an understanding of transportation systems in the region (although this understanding can reside jointly in the group of agencies/ stakeholders who participate in the maintenance process). Finally, the maintainer agency needs to have staff with an understanding of the tools used to create (and to update) the architecture. This might include for example, knowledge of the RAD-IT tool, if that is used to hold some of the architecture information. The agency responsible for maintaining the architecture needs to have the skills within its own organization or consider acquiring the skills. In either case, the agency needs the necessary funding to support the maintenance effort.

 

Having the resources to maintain a regional ITS architecture may mean that the stakeholders using the regional ITS architecture have to share in the costs to acquire these resources, even though one specific agency may commit to maintain staff or contract the skill set necessary.

 

 

3.     What group will assist the maintainer in evaluating and approving changes?

 

Another decision that must be made is who will support the maintainer in evaluating and approving changes to the architecture. This should be a group of representatives of key stakeholders, ideally members from the areas of traffic, transit, public safety, and maintenance. This group might be a carryover from a committee or body that consisted of key stakeholders in the development of the architecture, or it could be a newly constituted group, or it might be a form of the Regional ITS Committee described above. These groups have many names, but one common trait – they often include both technical and managerial representatives of the key transportation agencies in the region.

 

The group responsible for evaluating and approving changes to the architecture may be a group that has some coordinating authority for integration of systems in the region. However there is no need for the group to have legal or contracting authority. They will be serving as a vehicle for consensus.

 

 

When – the Architecture Update Timetable

Another way to describe when the architecture will be updated is to consider what "timetable" will be used for making updates or changes to the architecture. There is no set timetable that will apply to every region. The timetable chosen will depend on several factors including how the regional ITS architecture is used and the funding/ staffing available for the task.

 

How often will the regional ITS architecture be modified or updated? There are two basic approaches to update interval:  periodic maintenance and exception maintenance. Each has their advantages and disadvantages. They are not mutually exclusive, and an approach could be developed that is a combination of the two basic models.

 

-         Periodic Maintenance. This approach ties the maintenance of the regional ITS architecture to one of the recurring activities of the transportation planning process. For example, if an MPO is the lead maintenance agency for a region, it's natural that the regional ITS architecture would be updated at the same frequency as the regional transportation plan is updated (every three to five years) or the Transportation Improvement Program is updated (at least every two years). The update of the architecture could occur prior to or following the transportation planning document update. If the architecture update precedes the update to the planning document the revised architecture could serve as an input to the planning update. The drawback to this approach is changes in support of ITS projects may not be updated into the regional ITS architecture on a timely basis. Publication and versioning costs are minimized for the periodic maintenance approach since there is a new version only once in the maintenance cycle.

 

-         Exception Maintenance. This approach considers and makes changes to the regional ITS architecture in a process that is initiated as needed. This is very convenient for Federal Highway Administration (FHWA) Code of Federal Regulation (CFR) 940 consistency issues, but may be more costly than a periodic process (where requests for changes are queued until they are all addressed at once). Publication and versioning costs are dependent on the frequency of changes made to the regional ITS architecture.

 

-         Combined Periodic and Exception Maintenance. This approach is the most responsive to stakeholder needs, and perhaps the most likely to succeed with regard to usage of the regional ITS architecture, however, it implies the greatest cost. Specific stakeholder requests are dispatched immediately, and a more thorough process of analysis is periodically applied to discover and incorporate new ITS requirements.

 

 

What – Defining the Architecture Baseline

What aspects of the regional ITS architecture will be maintained?  Those constituent parts of a regional ITS architecture that will be maintained are referred to as the "baseline".

 

Architecture Components Baseline

All the components that have been developed for a regional ITS architecture should be maintained as part of the architecture baseline. These include:

 

Description of Region

This description includes the geographic scope, functional scope and architecture timeframe, and helps frame each of the following parts of a regional ITS architecture. Geographic scope defines the ITS elements that are "in" the region, although additional ITS elements outside the region may be necessary to describe if they communicate ITS information to elements inside the region. Functional scope defines which services are included in a regional ITS architecture. Architecture timeframe is the distance (in years) into the future that the regional ITS architecture will consider. The description of the region is usually contained in an architecture document, but should also reside in the RAD-IT file on the Start tab.

 

List of Stakeholders

Stakeholders are key to the definition of the architecture. Within a region they may consolidate or separate, and such changes should be reflected in the architecture. Furthermore, stakeholders that have not been engaged in the past might be approached through outreach to be sure that the regional ITS architecture represents their ITS requirements as well.

 

Connection of architecture to planning goals, strategies, and objectives

This component provides the connection between a regional ITS architecture and attributes used by regional planners for their transportation planning efforts. The connection between regional goals, strategies, or objectives and architecture service packages or projects provides the link between the needs of the community to the deployment of ITS.

 

Roles and Responsibilities

It is crucial that the roles and responsibilities in a regional ITS architecture accurately represent the consensus vision of how the stakeholders want their ITS to operate for the benefit of surface transportation users. These should be reviewed, and if necessary, changed to represent both what has been deployed (which may have been shown as "planned" in the earlier version of the regional ITS architecture) and so that they represent the current consensus view of the stakeholders.

 

List of ITS Elements

The inventory of ITS elements is a key aspect of the regional ITS architecture. Changes in stakeholders as well as Roles and Responsibilities may impact the inventory of ITS elements. Furthermore, recent implementation of ITS elements may change their individual status (e.g. from planned to existing).

 

ITS Services

ITS Services, defined in the architecture by a set of service packages and often a set of user needs, provide the key details on what ITS capabilities are currently deployed or planned for possible deployment in the region. The service packages define how the elements are connected to provide the ITS services.

 

List of Agreements

One of the greatest values of a regional ITS architecture is to identify where information will cross an agency boundary, which may indicate a need for an agency agreement. An update to the list of agreements can follow the update to the Roles and Responsibilities and/or interfaces between elements.

 

Interfaces between Elements (interconnects and information flows)

Interfaces between elements define the "details" of the architecture. They are the detailed description of how the various ITS systems are or will be integrated throughout the timeframe of the architecture. They are a key aspect of the architecture baseline, and one that will likely see the greatest amount of change during the maintenance process.

 

Functional Requirements

High-level functions are allocated to ITS elements as part of the regional ITS architecture. These can serve as a starting point for the functional definition of projects that map to portions of the regional ITS architecture.

 

Applicable ITS Standards

The selection of standards depends on the information exchange requirements. As projects are implemented and standards are chosen for a project they need to be reflected back in the regional ITS architecture so that other projects can benefit from the selections made. In addition, the maintenance process should consider how ITS standards may have evolved and matured since the last update, and consider how any change in the "standards environment" may impact previous regional standards choices (especially where competing standards exist).

 

Project Sequencing

While the definition of projects and project sequencing is partly determined by functional dependencies, e.g. "surveillance" must be a precursor to "traffic management"; the reality is that for the most part project definition and their sequences are local policy decisions. Project definition and their sequences should be reviewed to make sure that they are in line with current policy decisions. The update of projects and their sequences is a key aspect of any maintenance effort so that the architecture can continue to be used by project development activities.

 

 

Baseline Artifacts

While the components listed above constitute the architecture baseline, a key consideration is what documents, files or databases hold the information from these components. The most common artifacts are:

-         RAD-IT file. This file contains the details of components described above

-         Documentation. The most common documentation is an Architecture document that describes the different components and may contain the architecture maintenance plan. Some architectures put all the details of their architecture in a document (or documents), usually in lieu of having a web site. Sometime a maintenance or use plan are separate documents and sometimes chapters in a single architecture document. Documentation can also include spreadsheet information such as architecture changes planned for the next update.

-         Diagram files. Some architectures create customized service package diagrams that are contained in separate applications such as Visio or PowerPoint

-         Web files. Many architectures create a web-based version of the architecture. The set of files comprising the web site are another key artifact

 

In addition to the components of the architecture being maintained above, it is also important to document the resources that were used along the way to develop the architecture – the Region's Transportation Plan, TIP, ITS Strategic Plans, TSMO plans, various studies, as well as other regional ITS architecture. Document these other resources with their titles, dates or versions, and where they can be found so that future maintainers can understand some of the background that supported the development of this regional ITS architecture and remember that changes to those documents may affect the architecture.

 

Maintenance Approach (How)

This section describes possible regional ITS architecture maintenance approaches, answering the question, "How is a regional ITS architecture maintained?" These approaches fall into roughly two options:

1.     Architecture updates occur only at periodic intervals as specified in the maintenance plan. In general, little maintenance effort occurs between these periodic updates, although potential architecture changes may be collected by whatever agency or group is taking responsibility for the architecture. Some basic elements of configuration management are used to maintain the current version of the architecture. The vast majority of architectures developed fall into this category.

2.     Architecture updates occur as needed to address new stakeholders, elements, services, or projects defined by the region. This approach is used by some regions to help address federal requirements for major projects that were not covered in the current architecture. This approach implies a somewhat more robust use of configuration management is needed to keep the architecture up to date and to make sure all the relevant stakeholders are informed of any changes made.

 

These two general approaches can apply to the maintenance of any regional ITS architecture, but should be tailored to fit the size and scope of each particular architecture. The approach should also be tailored so that it fits within the region's transportation planning processes, e.g., the Regional Transportation Plan update process.

 

Effort Required for Maintenance

How much effort must be expended to maintain a regional ITS architecture?  That is dependent on several factors:

 

-         How much activity is there that would involve use of the architecture?  The more it is used to support planning and project development activities, the greater the level of changes it will probably see. Is the region going through a major update to their long-range plan?  Is there a high-level of investment in technology in the region?  Is the project activity concentrated in one department or agency or is it spread across several agencies in the region?

-         What is the approach being used for architecture maintenance?  Is it incremental changes or full baseline update?

-         What is the maintenance update cycle?  Are changes being incorporated on a regular basis or is revision of the architecture happening once every planning cycle?

-         What is the size and complexity of the architecture?  The larger the architecture the greater the effort in maintaining it.

 

To identify the effort required consider several maintenance scenarios:

 

1.     The maintaining organization collects change requests and reviews them with the maintenance committee on a periodic (e.g. quarterly) basis.

 

How many changes are collected in each period is very dependent on use of the architecture (how much is it being looked at while stakeholders are using it) as well as the complexity of the architecture (how many elements or connections could be changed). Creating a change request should be a small-time investment for any submitter (e.g. under an hour of time). There is a small-time investment of the maintaining organization to log the changes. Periodically, changes would be evaluated and presented to the maintenance committee. Evaluating each change will take only a small-time investment. A maintenance committee meeting of a couple hours will dispose of the changes. The amount of effort required to update the baseline will be a function of the scope of the change (e.g. adding a new stakeholder, inventory items and connections will take longer than changing the status of a few information flows). Again, the amount of effort for the activities described above is dependent on the number of changes being considered.

 

2.     The maintaining organization collects change requests and holds them until an update occurs X years after the initial architecture is completed.

 

This scenario is very similar to the previous one (in terms of time required for each change). The primary difference would be the number of changes to be incorporated. Again, the amount of effort will be highly dependent on such things as the level of ITS investment in the region. One way to limit the amount of effort required in the evaluation and approval part of the process is to have maintainer staff produce a summary of changes and recommended outcomes (approve, defer, or reject). This will allow the maintenance committee to focus on only those changes requiring significant stakeholder consensus when it meets.

 

3.     At the update cycle stakeholders are brought back together for one or more workshops to review and update the architecture.

 

This is the full baseline update approach. In this approach, additional time will be spent getting some subset of the stakeholders together in one or more workshops to review the architecture. A series of changes will naturally flow from these meetings that can be incorporated en masse into the architecture. The level of effort required for these meetings will be dependent on how many meetings are planned and how much effort will be required to present the architecture to the stakeholders.

 

So how much will it cost?  We all have to answer to the realities of budgeting and planning which forces us all to the bottom line. The cost of maintaining a regional ITS architecture depends on how you are going to use it. As you can see from the discussion above, the cost of paying someone to update the database, web site, and documents may be trivial compared to the cost of all of the stakeholders' time reviewing and approving changes. Think about the scenarios above and decide what maintenance approach your region will likely follow. Based on that decision you can then decide whether to allocate some financial resources to your future budgets to cover the cost of maintenance – personnel, equipment, contractors, etc. If the regional ITS architecture is going to be maintained by the MPO, then they should consider making architecture maintenance a work item in their Unified Planning Work Program (UPWP).

 

For more information consult FHWA's "Regional ITS Architecture Maintenance Resources: Technical Advisory" (available in HTML or PDF from https://ops.fhwa.dot.gov/its_arch_imp/resources.htm). It describes resources needed to effectively maintain a regional ITS architecture including; estimated resources needed (work-load and budget), variables that influence resource allocation, and situations where substantially more resources may be needed.

 

Configuration Management

Configuration Management (CM) is defined as: "A management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design and operational information throughout its life." CM can be applied to the development of any system. In the context of a regional ITS architecture it is a process for establishing and maintaining consistency of the architecture's information content throughout its life. In general, the configuration management process consists of five major activities:

 

-         Configuration management planning – Before you start, there are some decisions that need to be made about what needs to be controlled within a product configuration, when you establish a controlled configuration, how you change a controlled configuration, and what amount of effort you're going to expend in managing configurations. In the context of maintaining a regional ITS architecture this corresponds to the architecture maintenance plan.

-         Configuration identification – Identify what needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained. Identifying the configuration items and what identifiers will be used is part of the architecture maintenance plan.

-         Configuration control – Describe the process by which changes are made to the configuration baseline and when and how they are made.

-         Configuration status accounting – Establish how you will keep track of the state of all configuration items, all pending proposed changes, and all approved changes to those configuration items.

-         Configuration audits – Periodically verify the consistency of configuration documentation against the product. In the context of a regional ITS architecture this includes verifying that different representations of the architecture (e.g. document and database) match.

 

These activities are performed throughout the life of the development and operation of systems. Each of the activities described above can be described within the context of managing change as it relates to a regional ITS architecture.

 

Architecture Maintenance Process

This section takes the concepts of Configuration Management described previously (See CM section) and applies them to the approach needed to maintain a regional ITS architecture.

 

Planning

Before the maintenance activity begins the parameters of the activity must be identified and the details of the process must be determined. These parameters, defining who will maintain the architecture, when the architecture will be updated, and what will be the baseline maintained. These decisions and the maintenance process itself should be defined in an architecture maintenance plan, which is the primary output of the configuration management planning activity. The maintenance plan may be a separate document or part of the larger regional ITS architecture document. The plan should be created during the initial development of the regional ITS architecture. If it was not then the process should be defined and documented as soon as possible. The maintenance plan should also be a part of the architecture baseline described below.

 

Who

The maintenance plan should identify who will be responsible for the maintenance effort and what group of stakeholders will review and approve changes to the architecture baseline. In addition to defining who will be involved in maintenance a description of each agencies roles and responsibilities may be included.

 

What resources are needed to maintain an architecture?

In the context of maintenance of a regional ITS architecture, the same personnel skills that are used to work with the RAD-IT tool and ARC-IT will be used in managing the configuration items that are included in the configuration management plan.

In addition to human resources, there will need to be file servers, web sites, or other central locations to store electronic copies of configuration items. These must be "read-only" and protected so that changes are not made to released versions of the databases and documents. Any required changes require a new version number/date and hence a new copy of the configuration item separate from the previous version.

 

When

The maintenance plan should also identify the timetable for regional ITS architecture updates. As discussed before, there are several options. The other timing decision that should be identified in the maintenance plan is when to set the baseline and begin the maintenance process. In the case of regional ITS architectures, the first release of the architecture after its initial development would normally constitute the initial baseline. This is the point at which the architecture is ready for distribution and use, and the point at which potential changes to the architecture may begin to develop.

 

What

The maintenance plan should clearly identify what will be maintained- i.e. the architecture baseline. In fact, these parts are contained in databases (e.g. a RAD-IT database), spreadsheets, drawing files (e.g. PowerPoint or Visio), Hypertext Markup Language (HTML) files for a web site, and documents. Defining the architecture baseline is defining exactly what documents, databases, etc. will be maintained.

 

In addition to these architecture outputs, source documents that were used to produce the regional ITS architecture outputs may also be important to identify. Some of these documents will be the subject of later revision and maintaining a consistency between the architecture and the other efforts is important. For example, if the regional ITS architecture inventory was derived from a number of individual stakeholder inventory documents, then the date and version numbers of those source documents should be considered for inclusion in your list of controlled items. Other examples of these source documents might include early deployment study reports, strategic deployment plans, and inventory tracking reports. It is important that the dates of reports and any version numbers associated with the reports are recorded as part of the configuration that is controlled. This way, subsequent releases of these documents would trigger an analysis to determine how the changes are best propagated through the rest of the controlled items in order to maintain a consistent configuration. It's also necessary to record where these are stored, e.g., at which agency, on which data server, web site or other storage location.

The versions of software tools that were used to produce the architecture might also be included in the set of configuration items. These might include the RAD-IT tool and the version of ARC-IT used. For these tools, the important thing to record as part of the configuration is the version number and date of release. Subsequent updates to the tools and databases would trigger a change analysis.

 

A final consideration that goes into the definition of the architecture baseline is how you plan to use the architecture. Will service package diagrams be an important source of interfaces for project definition?  Or will interconnect diagrams be used?  Or will project developers go directly to the database representation for their detailed definition? Considering some of these alternatives will help you decide which representations of the architecture are most important to your region.

 

The list below shows some examples of the items that might be selected for the architecture baseline.

 

-         RAD-IT Databases

-         Regional ITS Architecture Documentation

-         Maintenance Plan (if a separate document)

-         List of documents used in developing architecture or with which the architecture should be consistent:

o    Planning Documents

o    Inventory Tracking Documents

o    RAD-IT tool Version

o    ARC-IT Version

 

The definition of baseline will depend greatly on the scope and complexity of the regional ITS architecture effort. For small efforts the baseline might consist of only a database, an architecture summary document (which would include the maintenance plan) and the version of RAD-IT tool and ARC-IT used for the development.

 

How

Once the Who, When, and What are established, deciding how to change the baseline needs to be considered. Change is inevitable. The goal of configuration management is not to keep changes from occurring, but to permit changes in a controlled fashion, ensuring that all configuration items are consistent with their descriptions at all times. Due to the nature of a regional ITS architecture (i.e. a set of documentation and databases rather than an actual system of software and hardware), there are two basic approaches that could be taken to updating the baseline. The first is a full baseline update based upon a periodic revisiting of the entire architecture. In the latter case all the architecture outputs are revisited and modified based upon stakeholder inputs, using much the same process as was used in the original development of the architecture. The second is incremental change based upon individual change requests. The approach below is meant primarily to deal with the second case- where incremental changes are performed.

 

The approach used for changing the baseline can be broken into the steps shown in the figure below. The following sections will consider each process step as it might be applied to both approaches to architecture maintenance. The formality or amount of effort that goes into these process steps will depend upon the scope and complexity of the regional ITS architecture.

Approach for Change Identification

 

 

1.     Identify Change

The primary aspects of change identification are:

-         Who can suggest a change?

-         How is the change request documented?

 

Each architecture effort will need to make a decision about who can initiate a change request. In some areas the selected answer will be "anyone". Allowing anyone to initiate a change is conducive to the development of a "consensus" architecture because it empowers all stakeholders to provide inputs. However the approach does have a drawback – if literally anyone can input requests the region runs the risk of being overrun by requests that will tax scarce resources to review and decide upon proposed changes. An alternative approach that may be attractive to some larger regions is to limit who can make change requests to members of the maintenance committee/board or members of other key ITS committees. This effectively means that any change suggested has the approval of a key stakeholder. This approach is planned in the Northeastern Illinois maintenance plan. This has the added benefit of spreading the resources needed to generate or evaluate changes among the group.

 

It is recommended that a simple change request form be created that contains at least the following information (note something like this is relevant for any maintenance approach):

-         Name of change

-         Description of change

-         Rationale for change

-         Originator name or agency

-         Originator contact information

-         Date of origination

 

As part of the configuration management process this information should be maintained in a change log (or change database) that would add the following additional fields of information:

-         Change number (some unique identifier)

-         Change disposition (accepted, rejected, deferred)

-         Change type (minor or significant)

-         Part of baseline affected (could be check boxes for document, database, web site, and not known)

-         Disposition comment

-         Disposition date

 

There are many ways the above change forms can be implemented. The form could be on a regional architecture website for download by anyone submitting a change. A less formal alternative would be for a change request to be submitted as an email containing the key information above. The formality in the process creates an audit trail of all changes considered as well as a record of those approved, those rejected, and those deferred. This audit trail can come in handy in future assessments of proposed enhancements or changes to the systems.

 

The above description of initiating changes applies to individual change suggestions that might arise from review of the architecture by a stakeholder or from the impact of individual projects. In the case of a full baseline update of the regional ITS architecture, this could be handled by a summary change request indicating the nature of the update and referencing the stakeholder interactions that will generate a set of changes.

 

2.     Evaluate Change

When using the incremental change approach to maintenance, each change request needs to be evaluated to determine what impact it has upon the architecture baseline. This evaluation could be required of the person proposing the change, or it could be performed by someone else (possibly the person, or group of people responsible for maintaining the architecture). Since a proper evaluation of a change requires detailed knowledge of the aspects of the regional ITS architecture baseline that are affected: it is usually a better idea to have someone on the maintenance committee (or their staff) do the evaluation. If the proposal for architecture modification has an impact on other stakeholders, someone from the maintenance committee should contact the stakeholders to confirm their agreement with the modification. If the issue warrants it, a stakeholders meeting or teleconference to discuss the modification may be held. In the case of a full baseline update, the change evaluation happens through stakeholder consensus as part of the overall update.

 

3.     Approve Change

When using the incremental change approach, the changes should be presented to the maintenance committee along with recommendations to approve, defer, or reject them. This could be handled informally through email, or through periodic face-to-face meetings.

 

The maintenance plan should identify how change approval will occur and any procedures that will be used to make the decisions. For instance:

-         Should approval require unanimous consensus of all members of the committee? 

-         Approval of all stakeholders affected by the change? 

-         Or just a majority of the committee members? 

The procedure used depends greatly on the nature of consensus building in the region. Approval of affected stakeholders is a good approach and one that may fit a wide range of conditions. For example, if a change to an interconnection between the traffic management center and the transit center is suggested, then approval by the appropriate traffic and transit agency represents consensus on the change and should be all that is needed for approval. Unanimous consent is not recommended as it is the hardest to maintain (and may slow down the process considerably due to trying to get all parties to respond, or come to meetings). In the case of full baseline update, the approval comes from the stakeholder inputs obtained when each architecture input is revised.

 

4.     Update Baseline

This activity involves putting the changes into the architecture baseline documents, web files, and databases. This requires much the same skills and techniques used in creating the initial baseline. When using the incremental change approach, all the changes would be entered by one or more assigned personnel, and then checked per the process described in the maintenance plan. When using the full baseline update, new versions of documents, web files, and databases would be circulated to stakeholders for a wider review. In addition, the change log would be updated to describe the actual change made and the version identification of all architecture baseline material would be updated as described in the maintenance plan. In some cases, the changes might be held until there is sufficient volume to make the changes efficiently.

 

5.     Notify Stakeholders

The final part of the maintenance process is to notify stakeholder of the changes or updates to the architecture. This applies equally to incremental change and full baseline update approaches. In order to perform this notification, the maintaining organization should create and keep up to date a contact list for all stakeholders represented in the architecture. As part of the maintenance process, this contact list should be reviewed and updated periodically to identify changes in personnel or changes in contact information (e.g. phone numbers or email addresses).

 

The task of actually notifying the stakeholders of changes may be handled in a variety of ways ranging from hard copy to e-mail to websites. Each approach has its strengths and weaknesses, and what is best for the region will be based on the current methods of communicating. A suggested approach that may meet a wide range of needs is to identify a website where information about the architecture is available and have a place on that website to provide notification of changes. This could be coupled with email notification to the stakeholder list that a change has occurred and to access the information on the website. As part of the note, as well as on the website, it would be good to provide the new version and date of baseline items along with a short summary of the changes.

 

 

Configuration Identification

Each configuration item must have a unique identifier associated with it. The identifier for the item should be marked on it in some fashion, so that the item can be identified without error and tracked. In the context of regional ITS architecture maintenance, this can be accomplished by suffixing a version number and date in the file name for a database file or electronic document, or it can be physically marked on a printed document. The identifier can also be included in a header or footer for documents and diagrams. In this way, everyone who reads the materials or looks at the database (using RAD-IT, for example) will know which version they are reviewing.

 

It also makes sense to have a controlled document that lists all of the configuration items and the versions that constitute that baseline in time. Maintenance history can also be included. Any interdependencies between the items are worth recording. There are several reasons for this:

1.     You want to be able to know what items you have under configuration control and be able to locate them. Marking them with a unique identifier makes it possible to do that.

2.     You want to be able to track the status of each item as it changes.

3.     If a change is made to one of your configuration items, you want to be able to determine the impact of that change on the other items.

 

Configuration Control

Configuration control refers to the process of identifying, evaluating and approving changes (as laid out in the Architecture Maintenance Plan) and then updating the baseline and all associated documentation. Any additions after the initial release of that baseline will be noted with a changed version number and date to the relevant identifiers. This must also include an update and new version of the overall configuration item list that documents the current versions of all configuration items.

 

In the case of a regional ITS architecture the baseline consists of databases, documents, and possibly other supporting outputs such as spreadsheets or drawing files. The process of configuration control and of updating these can become challenging since there is likely to be more than a single representation of the same information. For example, if a RAD-IT database contains the architecture inventory and an architecture document contains a table that lists this inventory, these two representations of the same information need to be kept in sync. Eliminating this kind of duplication is not really an option because a database representation of the architecture is needed to manage the large number of elements and connections, but some form of documentation is also required to make the information more understandable and usable for the stakeholders. The solution is to be aware of the duplication and to put in place a plan to manage it. Because of the potential for changes affecting multiple parts of the baseline, the changes in each part of the baseline should be coordinated with updates in other parts of the baseline. This is particularly true when using the incremental change approach to architecture maintenance.

 

Configuration Status Accounting

Configuration status accounting is the process of ensuring that all of the relevant information about an item – documentation and change history – is up to date and as detailed as necessary. This includes the status of all pending changes. A primary goal of configuration status accounting is to disseminate configuration item information necessary to support existing and future change control efforts. A typical configuration status accounting system involves establishing and maintaining documentation for the entire life cycle of an item. Status accounting is ideally carried out in conjunction with change control.

 

The primary benefit of configuration status accounting is that it provides a methodology for updating all relevant documentation to ensure that the most current configuration is reflected in the configuration identification database. It accounts for the current status of all proposed and approved changes. The goal is to provide decision makers with the most up-to-date information possible. Having the most recent information about a change item or including how the changes were implemented helps reduce research efforts in the future whether implementing a new change or rolling back a change that had a negative or unexpected impact.

 

For a regional ITS architecture, the primary configuration items might be a document and a RAD-IT database. Report the status on these items periodically to interested stakeholders just to let them know that these files are still the latest. This can be done during regular stakeholder meetings, e.g. an ITS Committee meeting.

 

When using the incremental change approach, the other thing typically reported would be the list of pending changes to the regional ITS architecture, and for a small region there may not be very many changes typically encountered and these may be very infrequent. So, in addition to identifying the latest version of the architecture, the region might report that there have been 2 changes received from stakeholder A and B that these haven't been implemented yet but are expected to be worked on in the next 6 months. When using a full baseline update approach pending changes are collected but probably not reported until summarized in the change log that occurs when the full baseline is updated.

 

 

Configuration Audits

In the general discipline of configuration management, configuration verification and audit is the process of analyzing configuration items and their respective documentation to ensure that the documentation reflects the current situation. In the case of a regional ITS architecture the configuration items are the documentation. Hence this step in the process becomes a rather simple one that can look at two aspects of the architecture:

 

-         Verifying the correctness of the configuration status accounting report

-         Verifying that different representations of the architecture information, e.g. the RAD-IT file and the document, are in sync

 

This type of audit is most applicable when using the incremental change approach, which may result in many small updates to configuration items, but is also a good idea to perform at the end of the effort in the full baseline update. Issues and changes are then provided as feedback to the maintainers of the architecture.