OSS Roadmap Tool

A good plan today is better than a perfect plan tomorrow

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

A roadmap is required because, as a friend of mine stated, “In the end it is subscribers who pay the bills. And subscribers, though often sold on the gadgets and networks technologies powering their favourite services, in the end it is the delivery of the service that matters. Whether they stream or download content over one technology or another isn’t important to them, their main concern is having a connection capable of delivering the service wherever and whenever they want it. If such services are not available, operators not only miss out on revenue opportunities, but their subscribers become frustrated by the lack of connectivity and go elsewhere.

Whilst the CSP‘s subscribers might be paying for network and services, they’re generally only interested in the content that they consume and whether the consumption experience was a positive one. This is forever evolving.

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

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. TMF’s eTOM model 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.

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.

To make the transition from current state to the planned future state, Ron Whitaker has suggested the use of SMART planning of goals/actions, where SMART stands for:
Specific – Keep goals clear, concise and simple
Measurable – Define action plans to measure
Achievable – Keep goals incremental
Realistic – Match goals to needs and ambitions
Timetable – Add milestones and completion dates

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.