“It does not do to leave a live dragon out of your calculations, if you live near him.”
J.R.R. Tolkien, The Hobbit
In our case, the dragon is our OctopOSS. Where do we start when planning a new OSS project? Every OctopOSS is different.
Like any other major infrastructure project, developing a program/project to build or transform an integrated OSS relies heavily on developing a clearly defined strategy. Many factors within the CSPs environment make the strategy completely unique/ Therefore it is nigh on impossible to document a “best practice” OSS strategy that can be applied across multiple CSPs.
Impacting factors include:
- Business model and associated competitive advantages. [You can find a great business model generation template here
- Network technologies, reliability / availability and footprint
- Service offerings
- Sales model (eg re-seller, wholesale, retail)
- Target customer type (eg residential, wholesale, corporate, etc)
- Funding strategy and / or access to funds
- Staffing levels and automations
- In-house / Outsource / Partnership resource models
- Legacy OSS and network environment
And each of these factors needs to take into account the current situation and projected future situation. There could be unforseen scenarios such as mergers or partnerships, disruptive technologies and innumerable other situations that could impact the OSS roadmap. So whilst encouraging a 5-10 year strategy, there will also need to be flexibility in the planning.
The strategy should aim to minimise change from rework – via enhancements rather than replacement. But this requires adaptability, anticipation and vision.
With regards to implementation, the following high-level considerations are required:
- Commercial Off The Shelf (COTS) software or Custom Development
- Best-of-breed or Single-vendor
- Vendor, Integrator or in-house implementation
- Phased or big-bang implementation
- Single-site or Highly Available
- Software as a Product (SaaP) or as a Service (SaaS)
Please see the links above to blog entries that cover each of these questions in more detail and the pros/cons of each approach.
Work Breakdown Structures (WBS)
I start almost every assignment with a WBS (Work Breakdown Structure) chart, whether the project involves planning from requirements capture, ongoing operations or any part in between.
Attached are sample WBS for various situations here on Passionate About OSS.
The visual nature of the WBS allows a reader to quickly visualise all the constituent parts of the OctopOSS and how they all hang together. It also allows various members of the team to brainstorm their ideas and ensure all major components are covered. The use of colour-coding of the WBS elements assists with the delegation of tasks to the various members of the implementation team.
Whilst I ascribe to the merits of the Agile approach to capturing requirements (user stories) and using it to work through the finer details of an evolving OSS implementation (scrum), I have concerns that concentration on the minutae could divert attention from the guiding vision of a project…. unless there is a visionary leading the development.
Hats off to those who are already taming their OctopOSS using an Agile approach. Speed, flexibility and using prototyping to give users early involvement in the evolution of the look and feel are attributes that every OctopOSS implementation should ascribe to.
OctopOSS projects are all-encompassing and easily side-tracked. One of the reasons they can be diverted is due to large numbers of people providing their opinions on the wants and needs of the final solution. To overcome this problem, I’m an advocate of thrashing hard and thrashing early, allowing all major and minor stakeholders to contribute their desired outcomes, but then leaving a very small team to architect a solution that they believe is the best fit of all desired outcomes. This trusted team must be left alone after thrashing has occured and allowed to represent the needs of the entire organisation. Many OctopOSS projects fail due to in-flight changes that get out of control. The trusted team must also be tasked with refraining from all but the most necessary of in-flight changes if possible.
The KISS principle
Keep It Simple Stupid! Don’t get distracted by the “nice to haves” and “wish-list.” OSS products have many features or can be heavily customised to do many tasks that add minimal value to an organisation. Wherever possible:
- Use out of the box functionality rather than heavy customisation
- Focus on simplifying the actions that are most important to your organisation (eg adding customer services, responding quickly to alarms, etc)
- Seek quick-wins, delivering project phases that are quicker and easier to develop momentum for project sponsors. Examples include rolling out alarm or performance management before flow-through provisioning because it is generally much easier to present alarm lists quite quickly from standard applications with minimal customisation
Current / Future Roadmap
When building a roadmap, I look to analyse the current application / interface situation using my OSS Interface Assessment Tool, then build a current-state application diagram using my OSS Roadmap Tool. When aligned with future objectives, I find that the visual representation of the OSS topology helps to identify gaps that we can target with products and / or integration effort.