"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"


This page is about building roadmaps for communities with interoperable architectures.

Such a roadmap weaves multiple architectures, competing needs and more or less known technologies into something which can support a shared vision.

It is likely that the scope of such endeavours will include more than one software architecture.

This is an early draft, published to give a starting point for collaboration.

The ideas here are infomed by experiences with the first SEEGrid RoadmapDocument and subsequent projects.

Differences from Traditional Development

The context of a roadmap includes both more unknowns and the intent to leave them unknown, for some time, than a traditional architecture.

It has to accomodate the uncertainties in knowledge, changes in capability and community and above all provide a governance framework for how to respond to such change.

This includes decisions being made as to when areas of ignorance need to be resolved, technology developed or goals abandoned.

The roadmap tries to make explicit how to cope with disappointment and inconsistency.

What is Provided by such a Roadmap?

  • Oversight of a traditional requirements gathering process leading to one or more technical architectures

Relationship with the RM-ODP

The RM-ODP (Reference Model for Open Distributed Processing) provides a model for an architecture and how to implement it.

It is purposefully minimalistic and describes a framework within which many standards can co-exist and interoperate.

It is therefore helpful in providing a shape for much of what the roadmap will contain or produce. It does not provide as much help in a process as to how to get there.


Mindmap of Issues in the Scope of a Roadmap

Click this image to see an expanded, more detailed map GenericRoadmapCompact.png

The topics on the above Mindmap are all things you are likely to have to deal with!

Metaphors: Filling in the Picture

Like an interlaced image on a web page, over time the roadmap provides more and more detail. However, right from the start it provides a coherent (albeit fuzzy) picture of the final system.

Metaphors: Physical Roadmap

Imagine a roadmap covering a wide territory. There are many routes which will be traversed to totally cover the territory (customer as Travelling Salesman analogy).

The Towns or Places metaphor of the physical roadmap suggests somewhere concrete at which to stop.

In our terms:
  • a coherent set of requirements has been met to an agreed level, with technologies or other assets delivered
  • we know how we got there - a clear path of development exists which was intended to reach this place.
  • we know where we are going - the roadmap tells us what is next in this particular path, or that it may be a cul-de-sac (we may legitimately reach dead ends in order to achieve some regulatory compliance, show off a technology or satisfy a stakeholder need, without anything else in the roadmap being dependent on products at this point).

Another way of thinking about this physical metaphor is to imagine the entire roadmap is like the information we serve with a Web Feature Service. You can do a spatial presentation or use a spatial bounding box to restrict what is seen but you can also query by non-spacial attributes.

Concept Map for Building Relevant Architectures


This process may well be applied at multiple levels of scale, for the entire roadmap as well as again for particular architectures.

I am not very happy with this name, maybe the diagram needs to be called something other than Building Relevant Architectures, something to do with the process?


Some or all of the following might be more easily provided by a dynamic system that allows some querying. Do not assume a static document is being specified.

  • Traceability of requirements
    • back to some original recorded concern or need of a stakeholder,
    • forward to resolution with delivered assets
    • with clearly specified points for whole or partial delivery ('Places' metaphor above)
    • factored into smaller requirements, or up into their parent
    • terminated with a delivery or reason for no longer being required
  • Coverage Testing
    • all concerns or requirements are either
      • satisfied
      • documented as to why they are unsatisfied
      • have a place on the roadmap indicating when they are expected to be satisfied. This might be a very fuzzy definition, the further out you go. * requirements include
      • governance specifications:
        • rights and responsibilities for all stakeholders or general classes of stakeholders
        • description of governing body or legislature
      • descriptions of performance sensitivity for all computational and data supply services
      • usability specifications, possibly as how personas will be satisfied.
  • Dependencies are documented
    • chains of dependencies can be built showing the technical and social issues involved in satisfying requirements
    • scheduling dependencies can be calculated
    • fan-out from technological or requirement change can be calculated to see the impact of change, to support decision-making
  • RM-ODP Viewpoints
    • relevant assets can be seen in the context of at least one of the RM-ODP viewpoints

Roadmap as a Collection of Assets

(I am tempted to use the word Artefacts instead of Assets but maybe Assets best-represents things which may have existed before the roadmap development activity started)

Instead of a relatively static document, consider a roadmap as a collection of relatively small assets which can be retrieved and presented in various ways.

There would be narrative sections weaving some of these assets together, including tables that might reference and summarise many more of them.

To be able to do such varied grouping, assets need identifying as being linked. This might be explicit or implicit (eg: identifying a particular stakeholder as being linked to anything with Security implications).

Another way of putting this is to say, a roadmap is chock-full of relationships.

Ways to Index or Group Assets

Depending on your role, personality or immediate question to ask, you might want to see things by
  • RM-ODP Viewpoint, eg Technical
  • Domain
  • Persona
  • Requirement
  • Schema
  • more specialised concern, eg: Security
  • Funding body or agreement
  • Stakeholder
  • Date of Revision

Typical Sequences

I'm using the term Sequence here rather than Timeline because these are not necessarily temporal.
  • Temporal - planned timeline
  • Temporal - actual delivered timeline
  • Conceptual Roadmap - the "spatial" analogy, representing some order based on how things appear between two points
  • Dependency:
    • technical, as in A can't function without B
    • social or project-planning
  • Narrative - when we use use cases or stories to describe a situation being covered by the roadmap, all the things mentioned in that narrative can be summarised in the order of the narrative.

Other Thoughts

  • A way to resolve being stuck is to identify points of variation and allow for them in the architecture, not necessarily the implementation, then move on. This is a general principle of architectures and software design, not just relevant to roadmaps but possibly very useful in the context of being able to deliver something partial and fuzzy.

Minimalist Roadmaps

Sparked by reviewing a roadmap from another source, here are some thoughts on what is the absolute minimum a roadmap could provide:
  • main reason for existence/problem to solve
  • boundary
  • governance framework - at least who's going to be involved in what happens next
  • some outline of what happens next, such as:
    • starting list of use cases
    • pointer to first feature wanted (first footstep on the road?)
    • next roadmap refinement stage

This brings me to a very real question - do you regard a roadmap as a relatively static artefact, delivered once, or is it a living document going through incremental development and delivered possibly in formal versions?



Relevant Standards

Articles of Interest



Software Architectures and Documentation

User Stories and User-centred Development



  • Domain
  • Personas
  • Use Case
Topic attachments
I Attachment Action Size Date Who Comment
BuildingRelevantArchitectures.pngpng BuildingRelevantArchitectures.png manage 51.0 K 23 Nov 2006 - 12:55 AndyDent Building Relevant Architectures Concept Diagram
BuildingRelevantArchitectures.vuevue BuildingRelevantArchitectures.vue manage 11.0 K 23 Nov 2006 - 12:55 AndyDent Building Relevant Architectures Concept Diagram original VUE file
GenericRoadmap.mmmm GenericRoadmap.mm manage 14.6 K 23 Nov 2006 - 12:54 AndyDent Generic roadmap MindMap
GenericRoadmap.pngpng GenericRoadmap.png manage 86.2 K 23 Nov 2006 - 12:57 AndyDent Generic roadmap
GenericRoadmapCompact.pngpng GenericRoadmapCompact.png manage 36.9 K 23 Nov 2006 - 13:08 AndyDent Generic roadmap trimmed picture
Topic revision: r5 - 15 Oct 2010, UnknownUser

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).