New Enghouse Product Guide details the full data migration tools that can help you pick your own OSS destiny
Without a doubt, operators need the best business support and operations support (BSS and OSS) systems they can get. The reasons hardly need rehearsing, but without BSS you’re not going to be sure all your customer-related functions, from CRM to accurate billing, won’t be at industry standard. By the same token, if you don’t have great OSS capabilities for your network inventory management, fault management, performance monitoring, and configuration management, you just aren’t working your core resource, the network, at the right levels of efficiency.
For sure, there are some great OSS solutions out there, spread over a very healthy global market (OSS and BSS together are predicted to be over $26 billion now, but rapidly rising to $60 billion by 2032) and as suppliers concentrate their investments on accelerating digital transformation, demand for Cloud OSS BSS is increasing.
But not all network management systems are created equal. Many are very niche, or tightly coupled with their maker’s other solutions. The functions, features, and integration capabilities of OSS solutions vary. That means OSS integration and migration efforts can be complex and require a lot of customisations to ensure seamless operation within a specific environment. If not exactly lock-in—though the hassle of moving can be functionally equivalent—the situation means that in practical terms, an OSS switch can seem like just far too much pain and hassle to most network managers.
Some see the best way to a more open OSS world via more industry-wide take up of standards and vendor use of Application Programming Interface (APIs) to promote interoperability. Well, we’ll see. In the meantime, there can often be very pragmatic use case reasons to move from one OSS to another. And based on having recently worked with just such a customer, we think there is room for optimism around how tractable all this can be.
‘A key requirement of any potential new OSS: maintain the flexibility of designing that circuit network it was already enjoying’
Our OSS migration customer was using one of the market’s leading solutions, but was facing a big hurdle: it had had to customise it in order to meet some of its priority business requirements—but over time, those changes had added up so much that when the supplier released a new version with attractive new features, its in-house version was now so different from the vendor’s standard model it was essentially impossible to move from A to B.
Options were considered. One was to accept the need to upgrade to the essentially new version of the OSS from its writers and accept a period of disruption as users had to be trained up on the new system. Another was to accept the need to start afresh—but as it would have to perform a change management exercise anyway, see what else on the open market could meet its needs.
A key requirement of any potential new OSS: maintain the company’s ability to take and implement a solution that could manage both its full transmission and circuit infrastructure and allow it to maintain the flexibility of designing that circuit network it was already enjoying. What that meant in practice: the brand wanted to always see what services were being transported over those circuits, and then be able to reconfigure those circuits and redirect those circuits as needed. Plus, if there was a need to perform a quick redesign based on being able to make sure that those circuits were accessible to deliver the services, it had to be able to do that on the fly.
It so happened that we already had a relationship with the organisation–part of its portfolio of OSS solutions included the Enghouse network performance management system, NetBoss. That meant that its network leadership was familiar with our strengths in the network management area, and so offered our team a chance to make a formal bid for the migration.
We were delighted to be awarded the final full responsibility of taking this company off its existing OSS onto a new basis. This has been a fairly long process, as this is a very complex environment and because the application is mission critical.
That complexity—and so need to minimise disruption and downtime, as the service has to keep running as the migration is actioned—means we’ve ended up having to do a lot of this through COVID. The good news is that solid progress was made—and despite some delays, everything is now fully back on track and full system User Acceptance Testing (UAT) and specialist internal engineer training is done.
Given how familiar users were with the older system, that level of learning curve and adaptation is natural (and was fully planned for on both sides). To help, the Enghouse project team have been doing everything from writing design specification documents to implementing lab systems to both initial and core training on-site for the customer on the product features and capabilities they can now take advantage of—a process further enhanced by setting up a bunch of workflow menus to guide users through all the new controls.
And from go-live, real benefits from taking on the significant challenges of full OSS change are getting racked up day-by-day. The customer now has a fully integrated OSS solution from end to end. And that prime requirement of being able to maintain full management and design/implementation and maintenance of its extensive circuit inventory: yup—not one second lost.
Out of this project, we’ve learned a few things about switching OSS mid-stream. One is that this is never going to be a trivial scope of work. This organisation—like most operators, of course—had complex and busy telecom and network solutions and the data migration of all those assets to a new platform needed extensive preparation and consideration.
To help there, well in advance we marked out the more dated solutions elements in the customer’s network and created a set of templates (‘adapters’) that allowed us to go in and directly pull the information from those network elements directly onto our platform. That made the crucial data migration step so much easier than it would have been otherwise.
Once we got all this vital data into our system, we were able to work with it and be able to pipe into the right elements of our solution, such as our projects module to manage all its projects, Overall, we were able to very quickly get a handle on all its critical workflows and core business processes.
Having this data streamlining meant that the migration process just went so much sooner, as it made it easy for us to pull the right information from the existing OSS into the client’s new Enghouse environment. Next steps: configure it to be able to manage its new OSS exactly as it wants to, going forward.
The verdict is that while OSS migration is a significant project, deploying the right data migration strategy—backed by having the best new OSS systems at the target end—and with the right partner, it’s absolutely not just doable, but even straightforward.
So, there’s no need to remain stuck—or even locked-in—in an ageing OSS ‘jail’; and could Enghouse Aktavara NRM (Network Resource Management) be the best shovel for tunnelling you out?
