How can I add value to you?

Today’s blog is all about you (actually they all have you in mind collectively, but this one encourages you to voice your specific obstacles to progress).

In the world of OSS (or perhaps even beyond), what value can I add that goes beyond the generalities of a blog and will help you get what you want? Is there any specific challenge that is preventing you from getting to where you want (or need) to go?

My role as an ICT and OSS consultant can be broken down into two key attributes :

  1. Being a connector (of people, ideas, technologies, products, methodologies, companies, customers, etc) and coach
  2. Producing an outcome that is not possible to do in-house given the constraints that exist in time, resources, skill-sets, priorities, etc

Who do you need to connect with who would be able to help you resolve a problem or jump to the next level? What technology do you want to know more about such as whether it fits your business objectives for the future?

What else is vexing you?

Leave me a message below and I’ll hopefully be able to produce an outcome or connection that can assist you in some meaningful way.

Corning glass in OSS

l love this YouTube video by Corning. l love the future-thinking in relation to how we will interact with the spaces around us. l love the way they’ve turned a blank canvas like our sliding mirror door into an interactive panel.

Did you notice the touch panel at around 2:40 into the video? Do you have any ideas for how something like this could be used in our industry? Two that immediately sprung to my mind are:

  • Resolving cross-domain or complex incidents and
  • Designing cross-domain network or service diagrams

Can you see this becoming a standard input / output technique in OSS? Which of the two options (wall or table panel) do you think would be more useful?

Have you already heard of any OSS organisations or service providers developing tools to make use of these types of panels (which are already available on a smaller scale BTW)?

The Changing Landscape of OSS

The Changing Landscape of Operational Support Systems (OSS):

Technologies, Solutions, and Organizational Impacts


I’m proud to announce that my latest publication has been released today. Click on the image (or here) to find out more about the document published in conjunction with Mind Commerce.

Operational Support Systems (OSS) are the essential set of tools required for a Communications Service Provider (CSP) to design, deploy, monitor and maintain the content, networks and services that their customers pay to use. There are significant changes underway in the CSP industry that are causing fundamental re-evaluations of business models, technology stacks and service offerings. These disruptions to the status quo are similarly influencing, and being influenced by, OSS.

This research assesses a range of relatively nascent technologies that have the potential to change the dynamic of OSS, whether via the networks they manage, or as building blocks on which to build better OSS tools. The report evaluates various technologies including cloud delivery, network virtualization, network security, Big Data, Machine Learning and Predictive Analytics, resource models, orchestration and automation, wireless sensor networks, IoT/ M2M, Self-organizing Networks (SON), software development models, and standards such as ITSM / ITIL.

This report is must-reading for anyone involved in planning or optimizing OSS as well as anyone with a vested interest in realizing positive financial returns from their OSS investment.

Companies in this Report:

  • ABB
  • Accenture PLC
  • Acme Packet
  • Aeris
  • Akamai
  • Alcatel Lucent S.A.
  • Amazon
  • Amdocs Inc.
  • Apache
  • Apple
  • AT&T
  • Big Machines
  • Black Ridge
  • BlueKai
  • BMC
  • Bosch
  • Brocade
  • BT Group
  • CA Technologies
  • Canonical
  • CENX
  • Certes
  • Ciena
  • Cisco
  • Clarity (part of Synchronoss)
  • Cloudera
  • CloudFoundry
  • Collective Intellect
  • Comptel
  • ConceptWave
  • Covisint Corporation
  • DataStax
  • Digi-Data (part of Synchronoss)
  • Docker
  • Embrane
  • EMC
  • Ericsson (Telefonaktiebolaget L. M. Ericsson)
  • European Telecommunications Standards Institute (ETSI)
  • Fabrix
  • Facebook
  • Fastwire
  • F-Secure (part of Synchronoss)
  • GE
  • GenBand
  • Google
  • Guavus
  • Hewlett Packard Company
  • Hortonworks
  • Huawei
  • IBM Corporation
  • InfoVista
  • Intel
  • Intucell
  • Juniper Networks
  • Lightbridge Communications Corporation
  • Linux Foundation
  • LiveLOOK
  • Metacloud
  • MetraTech
  • Metro Ethernet Forum (MEF)
  • Microsoft
  • Mirror 42
  • Miyowa (part of Synchronoss)
  • Moogsoft
  • Neebula Systems
  • NetCracker Technology Corp. (part of NEC)
  • Nokia Networks
  • NTT Communications Corporation
  • Nuel (part of Huawei)
  • Open Networking Foundation (ONF)
  • OpNet
  • Optimi
  • Oracle Corporation
  • Pivotal
  • Riverbed
  • Samsung
  • SAS
  • Satyam
  • Sentilla
  • ServiceNow
  • SevOne
  • Siebel (part of Oracle)
  • Silver Peak
  • Spirent
  • Splunk
  • Strumsoft (part of Synchronoss)
  • Subex
  • Sunrise Technologies
  • Synchronoss Technologies
  • Tail-f
  • Tata Consultancy Services Limited
  • Tech Mahindra Limited
  • Telcocell
  • Telcordia (part of Ericsson)
  • TeleOSS
  • ThingWorx (part of PTC)
  • TimelessMIND
  • TM Forum
  • TOA Technologies
  • Truviso
  • UBIqube
  • Verizon
  • Voxmobili (part of Synchronoss)
  • WindRiver (part of Intel)
  • Wisor (part of Synchronoss)
  • Younited (part of Synchronoss)
  • Zenoss

The language of maps

In the consumer space, I’m very excited that the world is waking up to maps. There’s this natural affinity to maps. Why is that? My theory is that maps are a kind of language. We have text language, we have music as a language, we have mathematical languages, we have software languages. Maps are a language. And their power is that they communicate intuitively to people. You can look at a map, and, Ah! You can see context as well as content. … Whether it’s a law enforcement situation, or a social situation, or whatever. And you also see the content of the actual phenomena that’s occurring.”
Jack Dangermond
(founder of ESRI) here.

Jack Dangermond’s passion for maps comes through loud and clear in this quote above doesn’t it?

I believe that OSS also speaks in the language of maps across a range of different conversations that include:

  • Network and capacity planning
  • Service, usage and asset visualisation
  • Network health and contingency planning
  • Field-workforce management, construction and service delivery
  • Sales and marketing
  • Customer care

Do you use maps extensively to tell your OSS story? If so, I’d love to hear the use cases that provide the greatest insights at your organisation

The death of fibre

It turns out that all Netflix streaming peak on Saturday night can fit inside a single fiber optic, which is the size of one human hair.”
Reed Hastings

Whilst futurists talk about advances in wireless technology being the death of fibre, higher volumes of wireless traffic equals a larger number of fibre backhaul points… for the foreseeable future at least. As we go to microcells, nanocells, picocells, femtocells covering smaller areas to satiate the demand for wireless bandwidth, all that traffic still needs to get back to the service providers distribution/core networks. As cell sizes get smaller, more optical fibre cables are likely to be rolled out.

Similarly, as mobile technology improves (ie GSM to 3G to 4G, etc), the cells are capable of carry larger network bandwidths, necessitating higher bandwidth backhaul pipes, which again implies more fibre.

Reductions in truck rolls are also flagged as being a benefit of Network virtualisation, which is probably safe to claim, but the touchpoint explosion is likely to mean bigger-bandwidth pipes (yes, you guessed it, more fibre).

Whilst the access / edge parts of the fixed network might be being overrun by wireless, clearly fibre networks are still being rolled out.

How does this relate to OSS? Well, it’s just one more reason why wireless and network virtualisation are less likely to disrupt geospatial / physical infrastructure OSS tools than all other segments of the OSS market.

Batched or chained?

A single twig breaks, but the bundle of twigs is strong.”

I have an interesting dilemma to pose for you today.

Let’s say you have a migration to undertake that involves your field work-force. The migration requires the re-direction of customer services from one destination to a new destination via re-patching at various points in the physical network spread across a wide geographical area.

Your OSS processes the migration (from an inventory perspective) as automated designs on a customer-by-customer or order-by-order basis because it’s the only way that it can trace out each new path. This means that a given patching/jumpering point may actually have many customer services traversing it without necessarily needing to be completely re-jumpered.

The question becomes whether you:

  1. Issue work orders to your field workforce on a service-by-service basis to ensure that end-to-end (chained) connectivity is ensured by giving a singular accountability for reactivation of the new service; or
  2. Issue batches of work orders for re-patching an entire patching point in one hit, thus reducing the amount of travel time and improving efficiency of effort, but having multiple workers involved in different parts of the end-to-end service

The same question could equally be posed for automated system tasks. Do you issue provisioning commands in a batch or do you design your process around completing and guaranteeing successful completion of each order in sequence?

Do your workforce management tools have the flexibility of automatically choosing between the batched or chained approach to assigning work orders? If so, which option have you found to be the most efficient and why?

Immunity from the disruption of virtualisation

Undermine their pompous authority, reject their moral standards, make anarchy and disorder your trademarks. Cause as much chaos and disruption as possible but don’t let them take you ALIVE.”
Sid Vicious

In many previous posts (including “A new category of OSS“), I’ve pondered how network virtualisation will disrupt the status-quo within OSS.

If, in the likely event that network virtualisation frameworks such as SDN / NFV gain a significant foot-hold in the global networking market, which segments of the OSS market are most likely to be disrupted and which are likely to remain relatively unscathed?

The physical layer will still be needed within a virtualised world (unless wireless technologies proliferate on big bandwidth pipes and backhaul). Sure, virtualisation should reduce the amount of truck rolls and additional cabling, but we will still need outside plant (cables, pits, ducts, sub-ducts, etc) to carry our virtualised networking traffic around.* Notwithstanding the potential for the outside plant (OSP) demarcation point to change and topology changes, I imagine that OSP / GIS types of OSS tools are minimally impacted by network virtualisation. The same is probably true of FWF (Field Workforce) tools although activities conducted by the field workers are likely to be impacted.

On face-value, real-time tools such as alarm/event management and performance management shouldn’t really be significantly impacted by virtual networks. They’ll still receive events and metrics from physical and virtual networks just like they do today, so they will retain the ability to do that and provide event/metric handling processes. Where virtualisation impacts these types of tools is in volumes. Network virtualisation and IoT are likely to deliver a touch-point explosion that is also likely to deliver rapid growth in the number of events/metrics being received by these real-time tools. They will no longer be able to be processed by humans at scale, so machine learning algorithms and predictive analytics are likely to disrupt existing real-time products.

Almost every other conceivable part of the application map (TM Forum’s TAM) is likely to be disrupted:

  • Market / Sales management – markets will undergo significant shifts
  • Product / Catalog management – product suites will undergo significant shifts
  • Customer, service and resource management  – will become far more real-time and automated in nature to cope with transient resource usage patterns
  • Supplier / partner management – the speed of change will necessitate far more partnership-based XaaS service models rather than monolithic service offerings
  • Enterprise management –  management of fraud, revenue assurance, regulatory, security, etc are all likely to be dramatically effected by virtual network proliferation
  • Application and infrastructure management – drastic changes are already presenting via the number of niche tools that are springing up to deliver the ideal of automated service/network management

* Whilst futurists talk about wireless technology advances being the death of fibre, higher volumes of wireless traffic equals a larger number of fibre backhaul points… for the foreseeable future at least.

Hazards in your environment

Our technological powers increase, but the side effects and potential hazards also escalate.”
Alvin Toffler

One of the many user groups touched by an OSS (directly or indirectly) is the field work-force. The field work-force have to deal with hazards that most of us desk-jockeys don’t come into contact with. Confined spaces, hazardous materials (eg gas, asbestos, etc), working at heights and other similar hazards aren’t always top of mind for people working on OSS platforms.

Whilst I haven’t seen this implemented by any of my past customers, I’m sure some organisations do use their OSS to record hazard notes to be able to identify them in the work packages that are issued to field workers. This would allow field workers to visit sites with the appropriate equipment to handle hazardous environments. In addition, the OSS could perform skills-based routing of tasks to field workers who have the appropriate certifications to work in each type of hazardous environment.

Whilst there would be many ways for an OSS to deliver such functionality, it seems logical that the GIS (Geographical Information Systems) that underpin many OSS (especially inventory platforms) could easily be adapted to record and present hazard notes.

Have you heard of any organisation that uses this type of functionality already? Would it actually enhance operations or do organisations have other simpler methods of hazard risk mitigation?

3D cellular modelling

* Traffic from wireless and mobile devices will exceed traffic from wired devices by 2016.
* Global IP traffic has increased fivefold over the past 5 years, and will increase threefold over the next 5years.
* Busy-hour (or the busiest 60?minute period in a day) Internet traffic increased 32 percent in 2013, compared with 25 percent growth in average traffic.

Statistics from Cisco’s Visual Networking Index (VNI) 2013-2018.

By any of the measures listed above, it’s clear that wireless and mobile devices will consume an ever greater amount of data globally in coming years. This puts pressure on network designers to come up with clever ways to cope, particularly with data density in highly populated areas like central business districts (CBD) and data distribution across broad rural fringe areas.

Some very clever OSS have found ways to model the three-dimensional complexity of radio wave propagation within a varying landscapes, terrains, building and vegetation patterns.
This series of articles from the InfoVista blog reveal some helpful hints to planning your wireless and mobile networks with 3D mapping and coverage tools:

  1. Why 3D Maps are Vital for Small Cell Backhaul Network Planning in Urban Areas
  2. Automate, Collaborate, Empower – Maximizing the RAN’s Value Through Coverage Maps
  3. Using Coverage Maps to Improve Customer Care
  4. Empowering RF Engineers by Automating Coverage Map Generation

OSS conflation

Conflation occurs when the identities of two or more individuals, concepts, or places, sharing some characteristics of one another, seem to be a single identity — the differences appear to become lost. In logic, it is the practice of treating two distinct concepts as if they were one, which produces errors or misunderstandings as a fusion of distinct subjects tends to obscure analysis of relationships which are emphasized by contrasts.”

Conflation is an interesting concept for OSS data migration / creation / cleansing teams.

According to Alan Witmer, there are five steps to the conflation process.

  • Prepare the databases for conflation processing. Analyze the incoming data’s quality and usability, and convert as necessary to a common format.
  • Build similar (congruous) representations of a select group of features from each data set.
  • Matching – identify common elements (also called correlation).
  • Improve the database by performing some action on those identified matches. This includes generating reports, merging selected attribute and spatial information from one database into the other, or perhaps creating a third database with selected elements and attributes of the original two.
  • Perform final QC suites to verify both the quality and completeness of the data transfer.

Alan has also prepared some helpful suggestions for performing these five steps in the link above.

This link from ConfleX also provides a neat description of conflation on spatial data sets.

Helix factors, cable sag factors and more

In fiber optics, the cable is a light pipe or waveguide, into which you inject light. If a finger presses on the pipe, it disrupts that light within the waveguide.”
Jefferson Han

And if a finger pressing on the fibre can disrupt the light signal, imagine what a backhoe can do to an optical fibre cable! As a humourous aside, you may like to read Fred Lawler’s “The 10 Most Bizarre and Annoying Causes of Fiber Cuts.”

Anyway, back to the blog. If you’re sitting in a Network Operations Centre (NOC) and you suddenly lose an intercapital link or two, you’re going to want to get to the root-cause of the problem pretty quickly. Assuming the optics are still functioning correctly and nobody is performing adds/moves/changes to patching in associated equipment rooms, there’s a fairly big chance that there has been a cable cut. But on an intercapital link, the cable could be hundreds of kilometres long, so how do you determine where to send the repair crews?

This is where spatial tools allow your OSS to provide an answer. OTDRs (Optical Time Domain Reflectometers) are able to send a light-pulse down an optical fibre to determine how far along the fibre that the cut has occurred. Let’s say that the break is at 34.6km from the patch panel that the OTDR is plugged into. This is helpful information, but two other factors will help you to identify the location more accurately.

If your OSS has a GIS that shows the exact cable route, then it is likely that it can also run a trace to estimate the GPS coordinates where the cable is broken.

You may think that if you trace the cable out to 34.6km then you’ll have the correct location. Unfortunately, you could be out by hundreds of metres because the cable / sheath length (as indicated on the GIS) and the fibre strand inside that cable (as measured by the OTDR) aren’t identical. Since the fibre strands coil around inside the cable, the fibre lengths are actually slightly longer than the cable lengths.

This difference in length is partly attributable to the helix factor. The helix factor is unique to each manufacturer / model of cable but is usually around 1-2% (see the manufacturer’s cable specs for actual values). Your OSS should have the ability to assign this factor as an attribute of each cable in your network and then consider it when tracing a route.

So assuming a helix factor of 2%, and a break at 34.6km of fibre length, then the cable sheath length will be 33.9km from the patch panel that the OTDR is measuring from. Your OSS / GIS will then show you the exact address where your repair crew can go to find the offending backhoe.

NOTE 1: Your OSS / GIS should also attempt to factor in real cable lengths, including things such as cable loops in pits (slack loops) and cable sag factors (for aerial cables) to determine the sheath length, not just geographic distances.

NOTE 2: Interestingly, larger core-count cables can actually have different helix factors depending on whether the buffer tubes are wound as the inner or outer rows inside the sheath, but I haven’t seen an OSS capable of differentiating for this yet. I guess your repair team will be able to spot the backhoe from a couple of hundred meters away from where the OSS / GIS has sent them anyway. 🙂

NOTE 3: There are a few other tricks for finding cable faults when above ground disturbance (ie backhoe) isn’t apparent, but that’s another story for another day and isn’t really in the realm of OSS anyway.

NOTE 4: Because of the various factors above that separate optical distance from sheath geo-position, it can make more sense to take the OTDR distance from the nearest even (eg splice or patch) and estimate geo from there, especially over very long spans.

NOTE 5: The Index of Refraction (IoR) impacts distance calculations too but it’s assumed the OTDR considers this before handing off the optical length to our OSS.

Data visualisation 5 – GIS

Spatial analysis is how we understand our world—mapping where things are, how they relate, what it all means, and what actions to take. From computational analysis of geographic patterns to finding optimum routes, site selection, and advanced predictive modeling, spatial analysis is at the very heart of geographic information system (GIS) technology..”

Geographic Information Systems (GIS) are a invaluable platform for OSS developers to visualise data on. Many GIS can even portray the three dimensions that we interact with every day, namely height, width and depth.

When it comes to presentation of visual data, GIS are able to display data patterns with a spatial context, including:

  • Geographic maps (eg routes and locations of outside plant networks)
  • Cartographic maps (eg showing overlays of where potential demographic distributions are)
  • Dot distribution maps (eg exact locations of where customers are)
  • Contour / Topographical maps (eg showing land, building and potentially even vegetation terrain contours that may impact line of sight or radio / cellular signal propagation)
  • Proportional symbol maps (eg showing the number of alarms, customers, bandwidth utilisation, bandwidth availability, etc at a given location)
  • Other thematic maps (eg heat maps showing high prevalence, such as regions of higher market penetration, plus the closely related cool maps that could show regions where penetration is statistically much lower than surrounding areas)

Whilst it’s possible to generate all of these maps via other means, the great features of GIS are their ability to cross-reference any number of other attributes to visualised objects as well as showing real-time updates (if needed).

Attributes could include object-by-object drill-down from a cable map into specific details such as:

  • Cable identifier
  • Cable types
  • Impacted customers (ie customers traversing that specific cable)
  • Service types supported
  • Utilised or available capacity on the link
  • Ownership model (eg owned, leased, etc)
  • Cost / expense / depreciation models
  • Maintainer’s contact details
  • Route tracing to show circuits beyond this cable link
  • Predictive analysis (eg when capacity is likely to be fully utilised on this link)

As we’ve discussed recently, there are even augmented reality (AR) tools that allow these various data visualisation techniques to be overlaid onto what we see before us.

Angela Zoss has prepared this interesting review of visualisation types on the Duke University website that might provide further thoughts on how to visualise OSS data. This link on Wikipedia shows some other interesting examples of thematic maps. This link from Esri provides some helpful guidance on understanding spatial relationships and patterns.

Augmented Outside Plant – Part 2

In an earlier blog entry, I wrote about using Augmented Reality (AR) to equip field staff with views of underground assets (and OSS data of course). Well, I’ve just found out that such a product exists from a company called Augview (perhaps there are others I’m unaware of too?). The following video provides a demonstration of Augview:

Mobile service assurance

To offer true, proactive service assurance, mobile operators must monitor three levels of performance. The first is the overall network and service availability – is my network up? Is this service available for subscribers to access? Second is the actual performance of the network – what is the throughput of my network? Is the service experiencing any jitter or latency? Finally, it is all about how the subscriber is experiencing the services and what, if any, issues are individual subscribers experiencing.”
Vikas Trehan
on this blog on

In an earlier post, we discussed how synthetic transactions could be used to simulate the real user experience across a multi-layered service offering (eg database, applications, servers, networks, etc).

However, as more and more communications services are consumed via mobile devices (eg smartphones, tablets), there is now a whole other dimension to consider – the spatial dimension.

With fixed networks, it’s fairly safe to assume that the network is quite predictable across a geographic region (discounting localised contention, outages, etc) so synthetic transactions could be injected at a small number of strategic locations on the network to represent overall user experience.

But when users get mobile, the network gets far less predictable (ie signal strength, throughput, service continuity). Highly localised factors come into play including weather conditions, topography, nearby buildings, congestion, electrical interference, distance from source, etc. In effect, every user will experience different service quality and synthetic transactions won’t provide a representative user experience.

Real-time performance data is needed from connections onto the mobile network. Perhaps the self-optimising network functionality of Self Organising Networks (SON) (and the associated data gathered) will cross over with the user experience performance monitoring of OSS to fill this void?

Have you integrated your OSS with the nascent technology that is SON from the perspective of mobile service assurance?

Points of OSS Interconnect (POSSI)

The basic technical protocols that have enabled the Internet to work in such a globally interconnected way are developed and shared openly by a community of engineers.”
Rebecca MacKinnon

When evaluating OSS tools, I often look closely at the boundary cases… in a literal sense.

OSS rarely operate in isolation. They gain power through interconnectivity, through cross-sharing and cross-referencing of information to provide insight. We know that integration via APIs (Application Programming Interfaces) can be challenging, expensive, time consuming, etc and can be an area that requires great attention when architecting interconnected solutions.

But what we often don’t pay as close attention to is how the tools and data models handle Points of Interconnect that exist between networks, customers, other carriers, management systems, etc.

Some examples include:

  • In an inventory system, a link between Multiplexer A and Multiplexer B has a single circuit name (let’s call it A-B-0001). The inventory system knows it as a single point to point link from a physical port on MuxA to another physical port on MuxB. However, from the perspective of an outside plant management system, a transmit/receive fibre pair is required to deliver A-B-0001. Each fibre is a “circuit” according to the outside plant management system from a patch panel at site A to a patch panel at site B (plus patch-cords at each end from patch panel to Mux). Each fibre circuit may actually traverse multiple components (eg patch panels, splice joints, attenuators, amplifiers). This circuit-pair to single circuit mapping can be confusing to some integrated OSS (eg mapping inventory to GIS)
  • In a transmission network that consists of network A and network B, where each is managed by a different vendor EMS, an end-to-end circuit may exist between a customer-facing port on network A through to a customer-facing port on network B. There are interconnect points between network A and B, which are effectively patch leads between adjacent devices. But each EMS only knows about the half-circuit within its network and most likely doesn’t know about the patch-leads or the half-circuit on the other network. The OSS needs to know about which half-circuits map to each other and which patch-leads complete the half-circuit pairings
  • An OSS has a routing algorithm built-in that helps network planners to design new circuits through their network. When designing an end-to-end circuit between customer Location A and Location Z it gets to an intermediate node and has the choice between 3 links to route the next hop of the fixed circuit. One link is leased from another carrier, one is a satellite link and the other is a highly congested on-net fibre link. Does the OSS‘s auto-route selection tool have the smarts to allocate different weightings to different link types? Is the weighting based on costs (eg perhaps the leased link is most costly), latency (the satellite link adds time delays), congestion (eg perhaps you prefer to load up your competitor’s network link instead of your own if you are incurring fixed costs anyway)?
  • Many carriers utilise leased links that effectively go off-net (ie can’t be managed) so down-time on the leased link has to be monitored via adjacent points on the network that are managed. The leased link details also should be recorded in some way in inventory systems even though they can’t be discovered via API. This may require manual entries similar to patch leads in examples listed above. Various attributes, such as provider details, contact details, service IDs, etc would also need to be stored against the leased link
  • There are many more you’ll be able to think of, especially from the perspective of billing reconciliation at each point of interconnect between carriers

Can you think of some other great POSSI examples worth sharing with the readers?

Cloudification threatens OSS and BSS

For companies like VM Ware and Microsoft no-one predicted that one of their biggest threats would come from an online book retailer, yet Amazon Web Services has upended the entire software industry.
The challenges for VM Ware today or Apple nearly two decades ago are being repeated in many other industries as competitors appear from unexpected directions, which is why it’s important not to ignore and sometimes co-operate with your competitors
Paul Wallbank

In yesterday’s blog, we spoke of Frenemies. Today we’ll expand upon Frenemy Model 3 and look at how it could (will?) threaten the status quo for OSS and BSS.

As many of you will have already noticed, ITSM vendors like HP, IBM, CA are all playing an active role in cloud orchestration, as are vendors with IT in their DNA like Cisco, Juniper, VM Ware and many others. The question becomes whether all of this coordinated development usurps the efforts of traditional OSS vendors and their CSP customer-base to adapt to network virtualisation concepts like SDN and NFV.

Similarly, the dynamism of cloud orchestration means that real-time inventory synchronisation and volumetric billing of IT systems/devices is arguably more attuned to ITSM offerings than OSS or BSS. That cloud orchestration is being facilitated by product and service catalogs is a further risk to diminished scope for traditional BSS providers.

There is no doubt that these threats exist. Just a few thoughts though:

  • At this point in time, cloudification is focussing on the more IP-centric network models and doesn’t replace with the massive “legacy” investments that CSPs have made in transmission technologies (PDH, SDH, DWDM) and other domains, although I do acknowledge that NFV is aiming to virtualise those network functions as well
  • Many of those investments still have years left on their useful life so they’re unlikely to be just stripped out and replaced by virtualised networks
  • CSPs are still likely to want aggregated views of FCAPS domains, so even if the cloud tools provide faults, configuration, accounting, performance, security at the equivalent of EMS-level, aggregation of other EMS up to OSS/BSS level will still exist
  • Best-of-breed solutions in FCAPS domains such as faults and performance are quite mature so it becomes a question of whether cloud-management providers would look to replace or partner with those solutions
  • The cloud orchestration service catalogs that I’ve seen have relatively simple workflow / process management at this stage, but they will undoubtedly mature with time
  • Outside plant management (including GIS and spatial management of assets such as cables, pits and pipes) tends to be more important to traditional CSPs and their OSS than cloud-providers
  • Similarly field workforce management is more important to installers of physical networks than virtual environments

OSS and BSS providers still have time to evolve and innovate whilst SDN and NFV are undergoing rapid development. ITSM providers will definitely be seeking ways to take more functionality share from them as they contribute heavily to SDN and NFV.

I wonder whether the bigger threat is from the unexpected competitor like an online book retailer or similar? My definition of what the next big thing needs to include is defined in this post. Can a traditional OSS/BSS provider deliver all of these evolutionary features or do they have too much invested in their existing code base?

Thanks to Nico Wauters of NetworkMining for spawning the idea for this post in a recent email.

DCIM Opportunities No. 2

GIS is a form of digital mapping technology. Kind of like Google Earth, but better.”
Arnold Schwarzenegger

Two days ago, we discussed the similarities and differences between DCIM (Data Centre Infrastructure Management) and OSS. In it, we indicated that Data Centres (DCs) tend to have less outside plant or inter-site connectivity (ie most power and network links tend to reside within the Data Centres), but cable management and network links are more likely to be managed within 3D spatial systems (x, y and height), not just the x and y coordinates of GIS (Geographical Information Systems).

This occurs in multi-level DCs and/or multiple levels of cable trays, where height of cable trays and/or riser shafts above ground-level become important for spatial visualisation of cable assets. Many traditional spatial systems are configured for managing highly distributed cable assets (ie direct buried cables spread out across countries!), so they don’t really need the third dimension of height.

For OSS vendors, adding the third dimension to your spatial systems will have the benefit of increasing the attractiveness of your product to industrial and utility organisations. They also have cable assets at various heights throughout their plants and easements.

3D modelling can also be important for modelling heat build-ups in certain areas within data centres, but this would require algorithms that are quite different in nature to those in existing Telco spatial systems!

DCIM – Data Centre Infrastructure Management

It is very important to get both IT and facilities groups together before even jotting down the requirement for a DCIM solution. One needs to look at holistic solutions and not treat IT and facilities management as two different silos.” Vivek Vikram Singh. Data Centre Infrastructure Management (DCIM) shares much of its DNA with OSS, but also has a number of unique differences. Similarities:

  • IT and network device management, including life-cycle management (ITIL / ITSM)
  • Electronic data collection and storage
  • Analytics and operational decision support
  • Planning and design tools
  • Predictive modelling
  • Process and change management
  • Capacity planning, resource allocation and provisioning

Differences (ie what Data Centres have that CSP networks don’t):

  • Facilities / Building Management Systems (FMS/BMS)
  • Energy management
  • Environment and heat management
  • Data Centres tend to have less outside plant or inter-site connectivity* (ie most power and network links tend to reside within the Data Centres), but cable management and network links are more likely to be managed within 3D spatial systems (x, y and height), not just the x and y coordinates of GIS (Geographical Information Systems)
  • Data Centres tend to have a higher proportion of virtualised assets than traditional CSPs

TechNavio predicts The Global Data Center market is expected to post a CAGR [compound annual growth rate] of 10.71 percent during the period 2012-2016 whilst 451 Research predicts a 44% CAGR in DCIM revenues from 2011-2016 (see graph below). These are really interesting numbers, so in tomorrow’s blog we’ll look at some of the differences listed above to see how traditional OSS could enhance their offerings to meet the needs of the DCIM market. * There are of course multi-site DC organisations that have links between their sites, but they tend to outsource their long-haul network links to traditional carriers.

Internet of Things is exploding

The internet already connects everyone and it’s about to connect everything. The ubiquity of always-on connectivity, the declining price and increasing versatility of sensors, and the benefits of remote information and control is prompting a new generation of devices ranging from doorknobs to thermostats to refridgerators to lightbulbs.
From the largest technology and manufacturing companies to a cavalcade of startups, the Internet of Things is exploding

The report above also indicates that Apple, Microsoft and Cisco had all held the number one position in the Net Influencer Score (NIS) in the 90 days of Appinion’s study indicating that no clear leader has emerged in the IoT (Internet of Things) market.

That the major tech brands are all heavily involved (throw in Google’s involvement as demonstrated by their recent acquisition of Nest Labs) suggests there is a huge nascent market to tap into.

Appinions indicates that there are three distinct sectors:

  • Connectivity devices
  • Home automation
  • Software platforms

Whilst all three are of interest from an end-to-end service delivery perspective, it is in the software platforms that is of most cross-over interest with OSS and CSPs. Just as CSPs have improved their speed to market with providing unified communication products to customers through partnerships with third-party service providers, it seems there is a clear opportunity for similar partnerships on IoT.

Not only do CSPs get to provide value-added services to customers, but they gain additional revenues without necessarily having to develop deep IoT domain knowledge (the partners hold most of that). The other potentially big up-side for CSPs is gaining access to IoT data to augment OSS data for analytics purposes (I caveat that within the constraints of customer privacy of course).

Automated design

“…with big data techniques we can start to find out where the clusters of [revenue generating businesses] and where the clusters of bad coverage are so you can be far more selective of where you rollout to.”
Kevin Noonan

In yesterday’s blog, we discussed the likelihood of more OSS vendor suites containing large-scale network design automation tools due to the potential for quick payback periods on invested capital as well as faster time to market (TTM).

We cited the example of Australia’s NBN using a fibre optic network design automation tool. However, it’s not just fibre networks that are suited to these design decision support tool.

Other scenarios could include, but are certainly not limited to:

  • Upgrade of HFC networks from DOCSIS 1/2 to 3 will require network reconfiguration to optimise bandwidth available to customers, infrastructure utilisation and identification of where additional infrastructure is required
  • Optimal network expansion areas, whether for fixed or wireless networks, to support the most customers or to best provide blackspot coverage
  • Optimal roll-out sequencing for faster revenue turn-on
  • Identifying areas with the most customers within break-even distance from existing network infrastructure
  • Design optimisation to support time of day and time of year-based traffic engineering of networks
  • Dual overlays of utility networks with their comms assets to provide least-cost or fastest roll-out of new network builds
  • I’m sure you can imagine many others!