Regional ITS Architecture
Maintenance
White
Paper
January 31, 2004
Regional ITS Architecture
Maintenance
White
Paper
January 31, 2004
TECHNICAL REPORT DOCUMENTATION PAGE
|
1. Report No. FHWA-HOP-04-004 |
2. Government Accession No. |
3. Recipient's Catalog No. | |||
|
4. Title and Subtitle Regional ITS Architecture Maintenance White Paper |
5. Report Date January 31, 2004 | ||||
|
|
|
6. Performing Organization Code
| |||
|
7. Author(s) National ITS Architecture Team |
8. Performing Organization Report No.
| ||||
|
9. Performing Organization Name and Address Iteris-1515 S. Manchester Ave/Anaheim, CA 92802 Lockheed Martin- 9500 Godwin Dr./Manassas, Va 20110 Consensus Sys. Technologies -POB 501,17 Miller Ave/Shenorock, NY 10587 R.C. Ice and Associates-27155 Big Horn Mountain Way/Yorba Linda, CA 92887 |
10. Work Unit No. | ||||
|
|
|
11. Contract or Grant No. DTFH61-01-C-00023 | |||
|
12. Sponsoring Agency Name and Address |
13. Type of Report and Period Covered White paper | ||||
|
Department of Transportation Intelligent Transportation Systems Joint Program Office 400 7th Street, S.W., Room 3416 Washington, Dc 20590 |
|
14. Sponsoring Agency Code
| |||
|
15. Supplementary Notes
| |||||
|
16. Abstract This white paper is a guide for transportation professionals who are involved in the development, use and maintenance of regional ITS architectures. It provides guidance on what should be contained in an architecture maintenance plan and on the process of maintaining the architecture. | |||||
|
17. Keywords ITS, Architecture, Maintenance, Configuration Management. |
18. Distribution Statement No restrictions. This document is available to the public from the sponsoring agency. | ||||
|
19. Security Classification (of this report) Unclassified |
20. Security Classification (of this page) Unclassified |
21. No. of Pages 42 |
22. Price
| ||
REGIONAL ITS ARCHITECTURE MAINTENANCE WHITE PAPER
This white paper is a guide for transportation professionals who are involved in the development, use and maintenance of regional ITS architectures. It supplements the Regional ITS Architecture Guidance Document dated October 2001 by providing a more detailed guide for the development of a regional ITS architecture maintenance plan and the activities involved in maintaining a regional ITS architecture.
A Regional ITS Architecture is: “A regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects.”[1] In January 2001, FHWA published a Final Rule (ITS Architecture and Standards) and FTA published a companion Final Policy that requires each region with ITS projects using funds from the Highway Trust Fund to create a regional ITS architecture adopted by its stakeholders by April 8, 2005, or within four years of the date that its first ITS project advances to final design. The Final Rule/ Final Policy requires that, at a minimum, a regional ITS architecture shall include:
· Description of the region;
· Identification of the participating agencies and stakeholders;
· An operational concept that identifies roles and responsibilities of stakeholders;
· Any agreements required for operations;
· System functional requirements (high level);
· Interface requirements and information exchanges with planned and existing systems and subsystems;
· Identification of ITS standards supporting regional and national interoperability; and
· Sequence of projects required for implementation
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 Final Rule/ Final Policy, which says: “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.”
The development and use of a regional ITS architecture are fully described in the Regional ITS Architecture Guidance Document dated October 2001 and will not be further discussed in this white paper. The guidance document can be obtained on CD from FHWA division representatives or downloaded from the FHWA’s ITS Electronic Document Library at http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/13598.pdf. The guidance document discusses maintenance of the regional ITS architecture, and white paper builds upon that discussion, providing a maintenance process and laying out the activities needed to effectively maintain a regional ITS architecture.
Regional ITS Architecture Maintenance
As ITS projects are implemented, the regional ITS architecture will need to be updated to reflect new ITS priorities and strategies 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.
What’s covered in this white paper?
Section 2 of the white paper discusses why maintenance of a regional ITS architecture is needed. Section 3 begins the discussion of the maintenance process by addressing decisions that must be made regarding who is responsible for maintenance, what is maintained, and the timing of maintenance actions. Section 4 presents the maintenance process and section 5 presents conclusions. Appendix A contains examples of change requests, change database logs and topics for the architecture maintenance plan. Finally, Appendix B contains several actual maintenance plans. References from these example maintenance plans serve as examples throughout the paper. Note that the process of architecture maintenance covered in this white paper 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.
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, 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.
· New stakeholders. New stakeholders become active in ITS and the regional ITS architecture should be updated to reflect their place in the regional view of ITS 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 touch 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 the National ITS Architecture has been expanded and updated to include new user services or to better define how existing elements satisfy the user services. A regional ITS architecture based on an earlier version of the National ITS Architecture should take into consideration these changes as the regional ITS architecture is updated. The National ITS Architecture may have expanded to include a user service 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 the National ITS Architecture 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.
· 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 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.
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.
Each of the maintenance decisions discussed in this section are primarily in support of keeping the regional ITS architecture relevant to the ITS planning and deployment of ITS projects as resources become available. As conditions in a region naturally evolve, an effective regional ITS architecture maintenance process will also evolve the regional ITS architecture so that it “keeps up” with the evolving conditions, and maintains the characteristic consensus that ensures stakeholders will find it relevant and a benefit to use.
The decisions that will be discussed are:
Who will maintain the Regional ITS Architecture? This is perhaps one of the most crucial maintenance decisions for a regional ITS architecture. 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.
An important concept is that the responsibility for architecture maintenance should not be delegated to an individual person, but should instead be assigned to an agency or institutional group in the region.
Often an individual may be, or may have been, a champion in the development of a regional ITS architecture, and that’s fine. But maintenance is recurring, and necessarily is a long-term effort. 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 agencies. This is the case with the Inland Empire maintenance plan (see appendix B) that provides for the maintenance responsibility to be assumed jointly by four key agencies in the region.
Issues in determining maintainer
Two key considerations in selecting a maintainer are described below.
1. Does the maintainer have the necessary skills/resources to maintain the regional ITS architecture?
Maintaining a regional ITS architecture utilizes 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 Turbo Architecture 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.
2. Does the maintainer 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. This is the case in the Northeastern Illinois maintenance plan-- the responsible agency for maintenance is the MPO in the region (CATS). This is also true for the Oahu Regional ITS Architecture, where Oahu Metropolitan Planning Organization will assume the maintenance responsibility. Both of these plans can be found in Appendix B. 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 rural in nature) alternate maintainers might be identified. Some other possibilities for maintainer organizations are:
When one agency or institution takes responsibility for architecture maintenance, they may use agreements to create a management/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 management/oversight function 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.
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. As an example, the Inland Empire maintenance plan (in Appendix B) calls out the creation of a new group-- the Architecture Maintenance Team-- with representation from key stakeholders. The Oahu Regional ITS Architecture Report calls out an existing group— the ad hoc ITS Technical Task Force—to support the maintenance activity. See Appendix B for both of these examples.
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 will the architecture be updated? Another way to describe this is 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.
Note, the above discussion relates to ‘how often’ the architecture is updated. A complementary discussion regarding whether the update involves incremental changes or is an update of the full baseline will be provided in section 4.2.
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”. This section will consider the different “parts” of the regional ITS architecture and whether they should be a part of the baseline.
One of the benefits of a regional ITS architecture is to enable the efficient exchange of information between ITS elements in a region and with elements outside the region. Efficiency refers to the economical deployment of ITS elements and their interfaces. The result of these ITS deployments should be contributions to the safe and efficient operation of the surface transportation network. Each of the components in the regional ITS architecture below have a role in this economy, and appropriate effort should be levied to maintain them.
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 may reside in a database containing aspects of the regional ITS architecture, and should certainly be a part of the baseline.
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. The stakeholders should be described in architecture documentation (and may also reside in a database representing aspects of the regional ITS architecture). Their listing and description should be part of the baseline.
Operational Concept
It is crucial that the operational concepts (which might be represented as roles and responsibilities or as customized market packages) 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. Many of the remaining maintenance efforts will depend on the outcome of the changes made here. The operational concept will reside in the architecture documentation (and possibly in a diagramming tool if a customized market package approach is used) and should be part of the baseline.
List of ITS Elements
The inventory of ITS elements is a key aspect of the regional ITS architecture. Changes in stakeholders as well as operational concepts may impact the inventory of ITS elements. Furthermore, recent implementation of ITS elements may change their individual status (e.g. from planned to existing). The list of elements is often contained in architecture documentation, and is key information in any architecture database. It is a key aspect of the baseline.
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 Operational Concept and/or interfaces between elements. The list of agreements will usually be found in the architecture documentation. This listing should be a part of the baseline.
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. These details are usually held in an architecture database. They are a key aspect of the architecture baseline, and one that will likely see the greatest amount of change during the maintenance process.
System 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. Because of the level of detail, these are usually held in spreadsheets or databases, but may be included in the architecture document. They are a part of the baseline.
Applicable ITS Standards
The selection of standards depends on the information exchange requirements. But 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). For example, if XML based Center-To-Center standards reach a high level of maturity, reliability and cost-effectiveness, then a regional standards technology decision may be made to transition from investments in other standards technologies (e.g. CORBA to XML). The description of the standards environment for the region, as well as the details of which standards apply to the architecture should be part of the baseline.
Project Sequencing
While 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 sequences are local policy decisions. Project sequences should be reviewed to make sure that they are in line with current policy decisions. Furthermore, policy makers should be informed of the sequences, and their input should be sought to make the project sequences in line with their expectations. This is crucial to avoiding the regional ITS architecture becoming irrelevant. The project sequencing should be included in the architecture documentation and may also be held in a spreadsheet or database. These should be part of the architecture baseline.
This section describes the regional ITS architecture maintenance process. The process described below is based upon the more general discipline of Configuration Management. This section will first present a short summary of configuration management, and then describe the process of maintaining a regional ITS architecture, drawing connections between the general discipline and the specific application of it for maintaining a regional ITS architecture. The maintenance process described in this section is a suggested or example process for the maintenance of regional ITS architecture. The process presented can be applied to the maintenance of any regional ITS architecture, but should be tailored to fit the size and scope of the particular architecture. The process should also be tailored so that it fits within the region’s transportation planning processes (e.g., the Regional Transportation Plan update process).
Configuration management 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”[2] and can be applied to the development of any system. In the context of 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 – making decisions 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, with the decisions formalized in a configuration management plan. In the context of maintaining a regional ITS architecture this corresponds to the architecture maintenance plan.
· Configuration identification – identifying the configuration items and the unique identifiers that you use to keep track of all items that need 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 – the control of which changes are made to the configuration baseline and when and how they are made.
· Configuration status accounting – keeping track of the state of all configuration items, all pending proposed changes, and all approved changes to configuration items
· Configuration audits –verifying 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. Figure 1 summarizes these process steps. There are some additional resources that provide deeper discussion, broader application of these principles and some specific tools and techniques for implementation of configuration management. These may provide additional information in adapting the information in the white paper to specific regional needs.
· TMC Pooled-Fund Study Configuration Management for Transportation Management Systems – Final Report September 2003.
· A Guide to Configuration Management for Intelligent Transportation Systems - April 2002.
 |
Figure 1. Configuration Management Process
The process of maintaining a regional ITS architecture involves managing change, and can be described using the activities summarized in the previous discussion of configuration management.
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 have been described in Section 3. Both 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. Appendix A provides a sample set of topics for such an architecture maintenance plan. The plan should be created during the initial development of the regional ITS architecture, but if it was not (as has been the case in many architectures developed prior to the release of the Final Rule/ Final Policy) then the process should be defined and documented as soon as possible. The maintenance plan should 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 the discipline of configuration management this group of stakeholders is termed the configuration control board (CCB). In addition to defining who will be involved in maintenance a description of each agencies roles and responsibilities may be included. The Oahu Regional ITS Architecture Report in Appendix B provides just such details on roles and responsibilities.
When
The maintenance plan should also identify the timetable for regional ITS architecture updates. As discussed in section 3.2, there are several options for this timeline. 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. Section 3.3 discussed the parts of the regional ITS architecture that should be maintained. In fact, these parts are contained in databases (e.g. a Turbo Architecture database), spreadsheets, drawing files (e.g. PowerPoint or Visio) 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 – 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 Turbo Architecture software and the version of the National ITS Architecture 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 market 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.
Figure 2 shows some examples of the items that might be selected for the architecture baseline.
Figure 2: Examples of Configuration Items to Consider.
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 National ITS Architecture (and possibly Turbo Architecture) used for the development.
Deciding How to Change the Baseline
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 incremental change based upon individual change requests. The second 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 process of changing the baseline can be broken into the steps shown in Figure 3. 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.
Figure 3: Process for Changing the Baseline
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”. This approach is called out in the Inland Empire maintenance plan in the appendix. 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 CCB 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 given in Appendix B. This has the added benefit of spreading the resources needed to generate or evaluate changes among the group.
The plan might also address when a change request should be made. For example, the Oahu maintenance plan in Appendix B lays out detailed directions for inclusion of ITS projects in the TIP, identifying when changes to the regional ITS architecture need to be made in order for a project to be funded through the TIP. Also the plan might identify the types of changes that will be made to the architecture. The Oahu plan identifies administrative amendments that do not require Policy Committee approval and non-administrative amendments that do require Policy Committee approval.
It is recommended that a simple change request form be created that contains at least the following information:
· Name of change
· Description of change
· Rationale for change
· Originator name or agency
· Originator contact information
· Date of origination
A sample change request form, as well as an example of a change is provided in Appendix A.
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
A sample change log entry is shown in Appendix A.
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.
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 CCB (or their staff) do the evaluation. If the proposal for architecture modification has an impact on other stakeholders, someone from the CCB 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.
Approve Change
When using the incremental change approach, the changes should be presented to the CCB 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. Should approval require unanimous consensus of all members of the change review board? Approval of all stakeholders affected by the change? Or just a majority of the CCB members? Which procedure is 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.
Update Baseline
This activity involves putting the changes into the architecture baseline documents 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 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.
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, as well as a short summary of the changes.
Configuration Management Resources
What resources are needed to perform configuration management? In the context of maintenance of a regional ITS architecture, the same personnel skills that are used to work with the National ITS Architecture and possibly the Turbo architecture tool will be used in managing the configuration items that are included in the configuration management plan. In addition to human resources, there will be the need to have 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.
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 Turbo Architecture, 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. First, 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. Second, you want to be able to track the status of each item as it changes. Third, 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 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/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 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 to 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.
In the incremental change approach, it is also possible to allow the database version of the information to change more frequently than the documentation. This might be appropriate if the form of the information used most often by stakeholders is the database (e.g. in the mapping of regional ITS architecture to projects). This could be handled by notes in the configuration item list.
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 of configuration status accounting 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 to reduce research efforts in future change control activities whether implementing a new change or rolling back a change that had a negative or unexpected impact. To report status, a format similar to that shown in Figure 4 might be used.
Figure 4. Sample Configuration Identification Document.
For a small regional ITS architecture, the only configuration items might be a document and a Turbo database. This would mean that configuration status accounting amounts to reporting on the version of the two configuration items (e.g. ruralRegArchV1-6-3-03.tbo and ruralRegionarchV1-7-3-03.doc are the latest versions of the “rural region ITS architecture”). Reporting this status could be done by phone call, letter, email or fax to interested stakeholders just to let them know that these files are still the latest. When using the incremental change approach, the other thing typically reported during status accounting 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.
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 database and 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.
How much effort must be expended to maintain a regional ITS architecture? That is dependent on several factors:
§ How much is the architecture being used? The more it is used to support planning and project development activities, the greater the level of changes it will probably see.
§ 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 CCB 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 CCB. Evaluating each change will take only a small time investment (e.g. under an hour). The CCB 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 CCB 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 to maintenance, 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 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.
This white paper, written as a guide for transportation professionals who are involved in the development, use and maintenance of regional ITS architectures, has drawn the following conclusions about maintenance of regional ITS architectures:
§ Change to a regional ITS architecture is inevitable. The many reasons for this were elaborated in section 2.
§ In recognition of the need to update the architecture, the Architecture and Standards Final Rule/ Final Policy has, as one of its requirements, that all regions developing a regional ITS architecture “shall develop and implement procedures and responsibilities for maintaining it”.
§ An architecture maintenance plan should be developed that lays out these responsibilities and procedures, which will be tailored to each region’s special needs.
§ The discipline of configuration management as discussed in this paper provides a foundation for the maintenance process.
Appendix A: Sample Change Management Forms and Maintenance Plan Outline
The following are examples of change request form and change log entries indicating the type of information one might expect to find in these forms
Sample Change Request Form
Sample Change Log Entry
|
Change # |
Change Description |
Change Originator |
Change Disposition |
Disposition Date |
Baseline Affected |
Change Type |
Disposition Comment |
|
Some unique identifier such as 2004.01 to indicate the first change cataloged in 2004) |
This could be a copy of the suggested change above, or might be an expanded description. This field might also point to a white paper that details the change. |
Copy of name from above |
Field with set of choices such as Accept, Reject, Defer. Filled in once the CCB has decided on the change |
Date of Disposition |
List of baseline documents/ outputs that will be affected by change. This could be a set of columns- one for each part of baseline with check boxes. |
Categorize change- might use minor/ major, or something similar. |
A field for comments regarding the change or its disposition. |
Architecture Maintenance Plan Outline
The following provides an example outline for an architecture maintenance plan that follows the guidance given in this white paper. The exact form and content of each region’s plan should be tailored to meet the needs and resources of the region.
1- Introduction
2- Roles and Responsibilities (for maintaining the architecture)
3-