After years of seeing OSS products, there’s one set of functionality that tends to be highly desired by customers but rarely offered (well) by vendors.
This tells me that it is very difficult to implement, and having also worked with vendors, I can attest to the challenge faced.
The functionality set I’m talking about relates to network planning, being able to store multiple overlapping or cross-dependant infrastructure designs ahead of their implementation.
It’s relatively easy to store states (eg planned, reserved, etc) against objects (eg equipment, ports, cables, ducts, etc). It’s much tougher to store plans of future infrastructure build-out that uses some existing objects, planned objects, multiple reserved use of objects for comparison planning (eg starting from a given port on an equipment, is route A or route B going to be more efficient?).
Tougher again is to show multiple future snapshots in time to plan cascading and dependant projects. Another challenge is managing the work-flow through the various planning states from design drawings and redline markups through to as builts, as well as the various approval gates.
As you can tell, this is important for any organisation that plans complex infrastructure builds.
The reason it’s so challenging from a product perspective is because of the multiple use states of a shared piece of infrastructure. For example, if port 1 is used for the Route A plan and Route B plan, then they’re both claiming “ownership” of the same object. Since most OSS are built on top of databases, where any data record is protected (locked) from being used simultaneously, OSS developers need to write code that works around this limitation (but powerful data integrity protection mechanism).
Have you seen a product that has provided this planning functionality simply and elegantly?
As (another) vendor of a network planning tool I agree with your statement that the requested functionality is rarely offered and if it is offered than it is hardly provided “Simply and elegantly”.
On the other hand it is a matter of fact that sophisticated functionality requires experienced planning engineers to work with it. Such planners must spend time on the tools and the tasks. And this leads me to another observation: Most of the functions which do not work more or less automatic are very often not used.
Operators hesitate to invest in sophisticated functionality which is a main reason that it is not implemented.
It seems to me that the bigger vendors of OSS tools do not invest in sophisticated functionality since the overall market is too small?
Ways to overcome such a situation for a small and specialized company like ours are
(1) Research projects which are supported somehow
(2) Projects where tool providers and operators work close together to define the requirements and implement them on basis of the real needs.
Point (1) is something what we do since years, but one can get support (by authorities) only if one investigates technologies and functions which really touch the future. And this actually is difficult to sell to operators. Very often it needs a further push by an operator to be ready for the market. Nevertheless we will also engage in this area since we have good experience and relations to German universities.
Point (2) is highly appreciated but even if offered together with free of charge licenses the main problem on operators site is the necessary investment of time. Planning engineers at small and medium sized operators do not get that time to work on such a project.
(Often at small operators planning engineers do not even have the time to run an OSS tool integration project at all.)
Coming back to the subject: our solution offers the requested functionality mainly through the planning in so-called “parallel working environments”, but it is not that flexible and I would not call it “simply and elegantly”.
Wow! Thanks very much for your viewpoint on this challenge Dr Michael.
You have highlighted a number of important factors including the dilemma of delivering complex functionality versus the cost-benefit.
You’re also right that the workflows used by each organisation’s planning departments vary, so creating a tool that works consistently across organisations also contributes to the challenge.
I also agree that it requires significant coordination and skill within planning teams to have multiple resources working on overlapping designs, even if they have an OSS solution to support it.
The MP3 player market also had many usability challenges, so perhaps your organisation will be the one to deliver the OSS planning tool equivalent to the iPod? 🙂
Thanks Dr Michael.