National ITS Architecture

Background

Since 2011, Austroads has funded the development of the National ITS Architecture Framework (NIAF) supporting a priority action in the Policy Framework for ITS in Australia (2012–2015) to assist road transport agencies in their deployment of consistent and interoperable Intelligent Transport Systems.

NIAF was established as an ITS industry-specific reference architecture with a distinct focus on transport business and technology (Austroads 2014). By definition, industry architectures “guide the integration of common systems components with industry-specific components, and guide the creation of industry solutions for targeted customer problems within a particular industry” (TOGAF 2018).

A series of staged projects have been delivered by Austroads from 2011–2019 to support NIAF’s development:

Stage 1: 2011–2014 - NIAF establishment based on TOGAF as the framework (methodology and metamodel) and the EU FRAME content
Stage 1C: 2014–2016 - NIAF adoption planning to develop a NIAF roadmap and agency-based transition plans
Stage 2: 2015–2017 - NIA pilot architecture development to educate and assist implementation
Stage 3: 2018–2019 (incomplete) – NIA content and governance, to develop priority content and governance framework. This last stage was halted in 2019 after consultation with Austroads members raised questions over the value of NIAF and commitment to it by members.

NIAF Components

TOGAF metamodel and ADM

The National ITS Architecture comprises:

The architecture framework – this is based on the well established TOGAF metamodel and TOGAF Architecture Development Methodology (ADM) shown in the figures above. The architecture metamodel describes the content of the architecture and its relationships, and the methodology assists with defining and implementing business, information systems and technology changes related to an ITS change initiative (e.g. building new motorway management capability or implementing a new incident management application).
The architecture repository, which is a repository of reference conceptual and logical business, information systems and technology diagrams, tables and matrices that assist with identifying and defining requirements for ITS initiatives (e.g. definition of the actors involved in incident management, or a description of the data and application components required for incident management). This content is based on the EU’s ITS architecture, FRAME (which has a very-ITS specific technology focus), and requires modification to suit Austroads members’ situations. Components from FRAME are also mapped to TOGAF’s Content Metamodel – a model that describes the architecture outputs and their relationships.
The governance framework, which defines how the NIAF is controlled and changed. This framework has not been formalised and is currently a discussion paper.

National ITS Architecture Review

Austroads recently reviewed the way forward for the development and jurisdictional use of the National ITS Architecture. The review found that although the projects to-date had delivered the required outputs, there was a large variety of NIAF levels of understanding and agency capability. Pockets of staff within certain agencies possess high levels of either NIAF or TOGAF capability and are able to provide NIAF-compliant content. However, other agencies do not possess this same level of capability and therefore are still learning about NIAF. This makes it a challenge to achieve the intended Stage 3 outcomes which were focused on further developing high-priority content, when not all project participants have the same level of understanding.

It was found that agencies see the benefits of a common architecture repository and sharing/learning from other agencies. Specifically, opportunities include:

assisting with capability change within an agency; and that these capabilities may include business, information systems or technology change and,
collaboration and share architecture amongst agencies and reduce duplication of work and lower costs.

As a result of the previous work, some agencies have or will embed NIAF (and TOGAF). However, other agencies are non-committal at this stage until NIAF’s vision and intent, and Austroads and agency roles are clearly defined and it is determined how best to maximise value from NIAF for agencies.

National ITS Architecture Way Forward

Following the review of NIAF projects and consultation with agencies, it was determined that Austroads should attempt to develop tailored NIAF content supporting its members rather than continue with the previously-halted NIAF Stage 3 project. However, in order to gain improved engagement and provide greater value for its members, it was recognised that Austroads needs to employ a different approach to NIAF content development. The need for customised architecture content was determined to be a higher priority than the creation of a governance framework (which can be done at a later point in time once the architecture content needs governing).

Accordingly, it was determined that any additional NIAF architecture development should aim to identify and develop a “segment” of highly valuable architecture content that will fill a high-priority knowledge gap that exists across multiple Austroads members. This approach would encourage buy-in and use of the architecture content; and over time, this demonstrated use would build further demand for other architecture segments to be created.

For this approach to be implemented, two ingredients are required: the approach to deliver valuable and attractive NIAF content; and the identification of architecture content to be developed.

Minimum Viable Product / Minimum Lovable Product Approach

A Minimum Viable Product / Minimum Lovable Product (MVP/MLP) approach was selected and endorsed by Austroads members. In the context of delivering architecture content, this approach stands for:

Minimum: the architecture content defines a basic set of features and capabilities
Viable: the architecture content provides value to the customers, so that they can and are ready to use it
Lovable: the architecture content brings delight to customers so that they admire it and recommend it to others
Product: the architecture content is ready to use immediately after development.

MVP/MLP is an iterative method that divides architecture content scope into manageable deliverables that are highly wanted by users. In theory, demand for additional architecture content will continue to follow based on positive user feedback, and this cycle will repeat until all architecture needs are met.

The MVP/MLP approach provides customer value by delivering a set of lovable features that early adopters will use. It collects user feedback that enables future architecture development that resonates with users, and further cycles of the MVP/MLP approach can be used to continue to develop the architecture content.

The benefits of this approach are that Austroads can:

maximise learnings and minimise development costs for NIAF content
release architecture content iterations quickly and learn from mistakes
build NIAF customer fans (evangelists) that further promote the architecture.

Focus on Multimodal Incident Management Reference Architecture

Multimodal incident management (MMIM) has been chosen as the scope of the initial NIAF content development. The reasons for choosing MMIM are:

It is needed by agencies and has a high likelihood of use – it will help planning and decision making for most agencies that are either providing or starting to plan MMIM services.
It aligns with Austroads’ priorities – Austroads currently has a project underway: Best Practices in Multimodal Incident Management, and this work can be delivered by augmentation of this existing project.
It is achievable and definable – there are some agencies with some background MMIM knowledge and learnings that can be shared as a starting point for MMIM architecture content.

A typical MMIM value chain is shown below to illustrate the potential scope of this work.

MMIM value chain

The expected outcomes from delivery of an MMIM architecture are that it will:

be a useful agency reference for multimodal incident management practices and information technology
be used as a guide to develop agency organisational capability
be used as a guide to develop agency solution architecture
be an opportunity to share existing knowledge between agencies (and reduce costs)
form a basis for developing common incident management capabilities across agencies
assists with interoperability of data.
signal to suppliers, future directions for incident management capabilities.

This work is being delivered under project NEG6019 Guidance and Architecture for Multimodal Incident Management.