End of an era
In 2018, Ericsson (ERIC) announced the end-of-life for its physical network inventory system, a widely known GIS for managing telecommunications networks, Network Engineer. This, coupled with ESRI’s official retirement of 10.6.x Desktop, has left Network Engineer customers hanging on for solutions to take them into the future of network management. Many companies who currently have Network Engineer are looking to replace it with a contemporary ESRI solution - ArcGIS Pro and thin client browser-based ArcGIS Server solutions seem to be the crowd favorites.
Service providers face enough challenges in a world of rapidly burgeoning data usage and heightened consumer expectations, 5G and IoT; they don't want to face any of their inventory management systems being deprecated. Do you face that unfortunate reality?
Challenges shared around the world
“But we’ve been accumulating data in the system for over 15 years!” A common objection presumably heard around water coolers throughout the world after the news was announced. I personally spent over 10 years of my career supporting Network Engineer customers around the globe, and thoroughly enjoyed my interactions with teams on nearly every continent. I also had the opportunity to visit places that as a kid I had only dreamt of seeing; like Petra, ancient Rome, and the Parthenon just to name a few!
Of course, change is never easy, and the larger the organization and the magnitude of the customizations that have been created for the business, as the use cases have evolved with years of development, make it increasingly so. If you hadn’t already considered the implications of data migration from the Network Engineer data model, or heard your IT department bemoaning the task, you’ll soon face that reality. Modeling points and lines on the map is relatively easy, as are many of the ownership relationships between Structures and Equipment for example.
As people often say, ‘the devil is in the details’: How will I retain my connectivity/tracing records? How will my target data model handle: transmedia units (fiber strands, copper pairs), inside-plant models like structure units, span units, and equipment detail views? What about port-to-port connectivity?! “Please tell me I can retain my schematic diagrams that I’ve invested hundreds of man hours perfecting!!”
Many people familiar with the data model think that the utility network is still “a ways off” being able to support the intrinsic complexity of the telecommunications data model and being able to perform essential functions like end-to-end signal tracing, circuit layouts and perform automated brownfield designs leveraging existing civil infrastructure. I am, by the way, one of those people.
The silver lining
The good news is of course that many software vendors vying to win this business, and that commercial product offerings in the market are already up to the task of handling your complex data. Several of which are ESRI based systems, which alone is great news because much of the risk associated with data migration is mitigated by default. What’s more, is that these vendors understand business drivers behind the workflows that Network Engineer supported, and they know well that the system has to be able to scale to handle thousands or even tens of thousands of edits every single workday, and even entirely eliminating some of the weekly maintenance routines (Parallel Reconcile and Compress), downtime due to versioning, that is arguably the most significant pain point for many large scale Network Engineer deployments.
The even better news is that some of these commercially available systems have a proven enterprise-ready data model and are based on a next generation thin-client platform. As you already know, this inherently offers an overall lower cost-of-ownership. Many customers have found over the years that upgrades in the Network Engineer system were often troublesome, not only in terms of the core functionality, but especially so in the extensive customizations that clients relied upon, that used a library of proprietary APIs. Many of the calls into these next generation systems are built on ArcGIS server, offer concise syntax using ESRI’s Rest APIs. This allows you to integrate virtually any upstream or downstream system with ease, and with the full backing of ESRI support.
So, if you’re one of the nearly 100 companies that share in this challenge, you have few choices. A) Create a home grown telco system using ESRI’s out-of-the-box tools for reconstructing the data model complete with thousands of lines of code to support your existing workflows. B) Choose a commercially available product and face the challenges associated with data migration or worse yet conversion to another data format.
Finally, the best news yet, you’ll never have to spend another day toiling in Model Builder with various geometric shapes to build a placeable or unplaceable component model! Some traditions, though relatable, are better laid to rest!
Looking to move from Ericsson Network Engineer? Download our e-book ‘Modernizing your fiber network management strategy – The essential guide to moving from ENE’.
