Silvano Rebai - Fotolia
Every industry vertical has a core or mission-critical set of applications that normally drive its technology evolution. The CIO of a bank would never plan for technology change without considering demand deposit accounting -- which, in banking, is savings, checking and teller support. In telecommunications, the core application set is operations support systems/business support systems, or OSS/BSS. But in this critical time of telecom change, it's not clear whether telecom's core applications are driving the change or being driven by it.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The original mission of operations systems was to manage people, rather than networks or services. But, as networks evolved and relied more on autonomous behavior, OSS/BSS became focused on billing and other noninfrastructure issues. In many cases, the CIOs of network operators head activities that are not directly related to either service or infrastructure evolution. And with SDN and network functions virtualization (NFV), for example, CIOs as recently as last year were saying they were largely unengaged in those technologies.
What's changing this is the need to prove that network technology like SDN and NFV have tangible business benefits. Operators quickly agreed the Capex reduction was a goal unlikely to drive enough change and moved to a broader benefits justification that included operations efficiency and service agility. Now, there's the question of whether operations efficiency and agility can be brought to existing networks through changes in operations systems, or whether new infrastructure offers a better hope of significant gains. And that is what will determine whether OSS/BSS will drive, or be driven.
Putting network operations efficiency first
The case for an operations-first approach is compelling. For every dollar in earned revenue, operators currently spend an average of about 20 cents on Capex. Operating costs attributable to service and network support and related activities make up about 27 cents. Few operators believe there is any credible way to reduce Capex by even 25%, so Capex reduction could contribute only a 5-cent-per-revenue-dollar savings in a best-case scenario.
In contrast, operators believe they could reduce operations expense by as much as 75% through software automation and orchestration. That would produce savings comparable to an operator's entire capital budget. Those savings could be achieved with little investment in new technology, so risk and return on investment would be favorable.
If operators' savings in operations costs -- driven by operations software changes -- were applied to fund new infrastructure, like SDN and NFV, the cost burden of early deployment could be reduced, and software automation would magnify the operations savings that infrastructure could generate. This could almost make next-generation network transformation self-funding.
On the service agility side, operators point out that creating self-service portals for customers' services, combined with service automation software in operations systems, could significantly reduce order-to-billing time for services and reduce operations costs at the same time. Just adding agile customer premises equipment to host virtual functions, or virtual CPE, would allow new service features to be added on premises, further enhancing revenue and shortening the provisioning cycle.
The problem with the network OSS everybody-wins scenario
The challenge to this apparent everybody-wins outcome is operations systems and their vendors haven't embraced this approach. Even network operators tend to frame their orchestration, operations efficiency and service agility missions in terms of devices, and have pursued these device-driven goals through SDN and NFV tests and trials. This has fostered an infrastructure-driven vision, where new technology creates virtual devices that interface with operations software just as the physical devices did. While that simplifies integration at one level, it insulates operations software from network technology trends.
The virtual-device model breaks the operations efficiency and service agility benefits in half, with the operations part of the picture left to evolve without specific drivers of change. The break means lacking a common driver would not only make it difficult to secure the full range of operations efficiency and agility benefits, but the lack of new OSS for technology hidden inside virtual devices would make it difficult to realize agility and efficiency benefits there.
Another complication is the fact that transformation has long been seen as meaning infrastructure transformation, driven by changes in standards and technologies under network operator CTO organizations. Initiatives like SDN and NFV have created enormous visibility for CTO organizations, and tests and trials aimed at transformation have targeted SDN and NFV. As a result, operations changes have been excluded from the scope of trials, and that has cemented the limited virtual-device model into place.
OSS, emerging technology separation affects next-gen architectures
The organizational separation of operations systems and emerging technologies has even colored emerging operator architectures for next-gen networks, notably those from Verizon and AT&T. Both have codified the operations and infrastructure separation by supporting multiple layers of orchestration. It is feasible to combine these layers into one, but the fact that operators look at operations and infrastructure orchestration separately will likely perpetuate divisions on the issue vendors. Few vendor sales reps call on both the operations and infrastructure sides of the business.
Economics should be the deciding factor in whether operations drive or are driven by transformation, but operators and vendors have struggled with network transformation for a decade without success. With SDN and NFV, the trend seems to take a narrow service-specific leap, rather than a broad migration. If SDN and NFV initiatives drive the change, a narrow infrastructure-driven shift is emphasized, and that risks the classic service-silo problem. But, most importantly, since SDN and NFV don't define operations automation and orchestration, the service-driven transformations seem to force operations into follow-me missions.
It could take five years longer to achieve service agility and operations efficiency if technology evolution at the infrastructure level is separated from the evolution of operations systems into an event-driven, service-automation model. Arguably, we might never fully realize the goals because SDN and NFV present more potential complexity, and that could raise costs, rather than lower them. Right now, we're on an "operations is driven" path, and we need to shift policy to make operations the driver.
Automated network OSS needed for SDN and NFV
Survey links next-gen OSS to faster service deployment
OSS not glamorous, but necessary for network changes