OSS Roadmap Tools

“A good plan today is better than a perfect plan tomorrow”
Proverb

As content, applications and technologies change, so does the need for a roadmap to plan for that change.

When defining a roadmap, it helps to know where you are starting from. You’ll have to document the current situation.

Obviously we then seek to understand a future-state (rather than an end-state, which will continue to evolve beyond the view-point of this exercise). A gap analysis will identify the interfaces, products and projects that will be required to transition from current state to end state.

The simplified process is as follows:

1. Current State Analysis
2. Future State Requirement Analysis
3. Gap Analysis (between step 1 and 2)
4. Recommendations
5. Implementation Steps

This article will help to provide some suggestions to map from current to future states.

Roadmap Frameworks

Future state requirement analysis takes into account many aspects discussed earlier, including mapping of business strategy, benefits, functionality, process, organisation, etc. These help to define the Business Architecture, which is also the first of four architectural domains in the TOGAF model. TM Forum’s TAM (applications / functionality) and eTOM (process flow) models can also assist to map the future state of the business domain.

The three subsequent domains of the TOGAF model are Applications Architecture, Data Architecture and Technical Architecture. All three are captured in the application / interface mapping technique shown below.

More rigorous mappings are prescribed in TOGAF and frameworks such as Zachman’s.

A Function / Project / Agile Roadmapping Framework

The following framework is provided courtesy of Raman Bhalla in his article here. Please read the article in the link because his framework does a fantastic job at describing key roadmap features such as:

• Starting with personas (the WHO) and their required actions / functions (their WHY)
• Current-state / future-state / gap (as mentioned above), including tagging of functions
• Emphasis on strong support by “champions”
• The importance of using frameworks to articulate the message on a single page (a powerful visual tool to communicate and coordinate change)
• Breaking the project down into essential functions and then into the projects as well as their sequencing
• Emphasis on organisational change, not just technology change

The framework is summarised by Raman in the following Plan on a Page:

A few other things to consider adding to your version of Raman’s framework:

1. Can it accommodate your WHO as well (closely related to WHY), where the who includes stakeholders such as sponsors, champions, implementers, users, etc
2. Can it relate the blocks of the framework to your WHO, WHY, WHAT, HOW (eg “Change Drivers” block = WHY)
3. The WHO is really important because it helps you define stakeholders, and stakeholder management is a key part of your Organisational Change Management plan (see our article on OSS change management)
4. The functional breakdown (HOW) helps you to define a work breakdown (see our article on planning a project using WBS), which helps turn the roadmap into an implementation plan; list of activities, roles and responsibilities; and even a Gantt / schedule of activities
5. Many roadmaps focus on an “end state,” but they often lack thought of the “stepping stone” states required to get to the “desired state” (not “end state” because they’re always evolving). In some cases an Architect’s ideal end state is impossible to achieve by delivery teams due to system and process entanglement. Roadmaps have to be better at plotting a realistic path through, even if the “end state” isn’t quite as perfect

Application / Interface Mapping Technique

The attached template provides a visual representation of the constituent components of your current (black lines) network management suite, as well as presenting the roadmap to a future (red lines) architecture for your OctopOSS.

It clearly identifies the applications/devices and their functionality as well as their coverage regions and support models. It also shows associated northbound, southbound and physical interfaces.

This page is just the starting point though, as those other above-named frameworks provide an enormous amount of helpful detail that I won’t seek to replicate here.

For your security, the file is uploaded as a PDF but I’d be happy to provide a copy in Visio format upon request. If you find this template helpful, I’d love to hear about your story, your project and any other enhancements that you’ve made to the template.