Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!

You are here


Before starting work on creating the ITS architecture it is very important to estimate the resources that will be needed. The best way to do this is to split the work of creating the ITS architecture into three phases:

  • Phase 1 – creating the service descriptions
  • Phase 2 – creating the ITS architecture
  • Phase 3 – carrying out the follow-on activities

The numbers of people needed for each phase will depend on the number of stakeholders and the expected scope of the services that the ITS implementation is to provide.

Phase 1 – creating the service descriptions

Experience has shown that it is impractical to have only one person at the meetings with stakeholders to enable the Stakeholder Aspirations to be captured (See How to Create One?). This is because it is virtually impossible to direct the course of a meeting and take meaningful notes of what is said at the same time. Stakeholders can be encouraged to submit written descriptions of the ITS services they need or aspire to (“Stakeholder Aspirations”), but holding stakeholder meetings, either individually or in groups is a better way to gather this type of information. An accurate record of what is said at these meetings will be an invaluable aid to developing the detailed Service Descriptions. Discussions with stakeholders before the architecture is developed are likely to produce “Stakeholder Aspirations” rather than strict, specific Service Descriptions which need to be refined by the Architecture Team before starting work on creating the ITS architecture.

At least two people will be needed for each stakeholder meeting – one to lead the discussion and the other to take notes. If a large number of stakeholder meetings are needed, it may be necessary to deploy teams of two people each, so that meetings between non-related groups of stakeholders can be held in parallel. For most ITS implementations, the time taken to produce the service descriptions to the level of detail required, will be about 6 months, since it is usually necessary to talk to stakeholder representatives whose diaries are often very full.

Phase 2 – creating the ITS Architecture

Previous experience suggests that having more than one person working on the actual creation of the ITS architecture does not save time or effort and may produce inconsistencies within it. The best solution is to have one person creating the architecture and at least one person to review it.

If the ITS architecture is be created from either the US National ITS Architecture or the European FRAME Architecture, then the time required should be relatively short - about one month should be sufficient and includes the creation of the physical viewpoint. If the "Start from Nothing" approach is taken, then the time taken will be considerably longer – probably about 9 months for a small scale ITS project and up to 2 years for a more extensive architecture.

Phase 3 – carrying out the follow-on activities

Creating the different viewpoints for an ITS architecture (physical, communications, organisational) and analysing other aspects of the ITS implementation (deployment, cost-benefit, risk analysis) (See What is an ITS Architecture) can be undertaken by several people – if necessary working in parallel. The possibilities for parallel working can best be seen from the diagram below.

Relationships between different ITS architecture viewpoints and other aspects of ITS implementation

Many of the links are bi-directional because work on one view or viewpoint can affect the contents of a previously created view or viewpoint. So for example, physical and communications constraints identified by work on their viewpoints can require changes to the way that the functionality is partitioned in the functional viewpoint.

It is tempting to think that some ITS architectures will not need all of these viewpoints or an analysis of the other aspects, for example when the ITS architecture for a research and development project. In practice this is not true. What will vary is the level of detail that is needed, so that for example, an ITS architecture for a single service may require less detail in its organisational viewpoint, plus a much simpler treatment of deployment, cost/benefit and risk.

To create all of these viewpoints and other outputs three people will be needed and they should be able to complete the work in three months. Obviously if less detail is required then the amount of effort reduces, which can be expressed either as a reduction in people or in the time taken.

Overall estimate of resources required to create an ITS architecture

The following table summarises the three phases of ITS architecture creation.



Number of people

Duration (months)







Creating the service descriptions


up to 4

up to 6


Creating the ITS architecture


up to 3



Carrying out the follow-on activities


up to 3

up to 3

The conclusion from the table is that between 2 and 4 people will be needed for a period of up to 10 months. It is advisable for each team member to work on the three phases of architecture development rather than focusing just on one.

Resources needed to maintain an ITS architecture

Once the ITS architecture has been created, it needs to be maintained and kept relevant if it is to continue to serve a useful purpose. The resources required to do this should be small, with two people needed for a period of about 6 months every 12-18 months – but this will depend on the size of the project. The need to update the ITS architecture will depend on the speed of the evolution of ITS and the stakeholders’ need for implementing new ITS applications.

Advice to practitioners

When allocating resources, it is helpful to keep in mind the long term situation and the need to keep the ITS architecture consistent with the continual evolution of ITS. For large ITS architectures, such as those with several different types of service (for example, traffic management, public transport and tolling) it will be cost effective to employ the same person to create and maintain the architecture. The dividends will be reduced staff resource time because of retained knowledge, which in turn can be translated into reduced costs. Stakeholders will be dealing with someone who knows about the ITS architecture, which will inspire them with confidence.


It is possible that there will be no suitable local expertise to create the architecture but dependency on the use of consultants will be expensive. A better plan may be to train at least two locally-based people to create the ITS architecture and carry out the maintenance work – drawing on a mentor for help and advice. The locally based people do not have to be software or hardware engineers - in fact it is probably better if they are not. Computer literacy, willingness to learn and enthusiasm are the prime requirements, with some knowledge of ITS being a great help. Local staff will be better placed to appreciate what the stakeholders want from ITS.

Reference sources

No reference sources found.