The latest Magic Quadrant for Operations Support Systems is as follows:
Source: Gartner (February 2018)
The latest Magic Quadrant for Operations Support Systems is as follows:
Source: Gartner (February 2018)
How many times have you heard a colleague say they wish they could clone themselves (or one of their trusted colleagues)? Alternatively, to say they’d like to do a copy *.* of a colleague’s brain?
I’m feeling that way more now than at any time in the past, not of any one person in particular, but on whole fields of expertise. Data science, network virtualisation, cloud development models, digital marketing, the art of selling, getting hands-on with the many open-source OSS tools and integrating them together (as recently flagged by Christi). The list goes on. Gaining expertise in each field is a life’s work. Just gaining proficiency is a full-time job.
To be an expert in future OSS requires managing all these facets, not to mention all the challenges of the past / present. The question I find myself asking is how to find a balance of proficiencies up until the invention of a time-extension machine.
The best answer I’ve come up with so far is to be a super-connector. That requires four things:
I’d love to hear your thoughts on how you best manage the conundrum of multi-faceted expertise.
We introduced the concept of The Trickle-down Effect last year, an effect that sees the most minor changes trickling down through an OSS stack, with much bigger consequences than expected.
“The trickle-down effect can be insidious, turning a nice open COTS solution into a beast that needs constant attention to cope with the most minor of operational changes. The more customisations made, the more gnarly the beast tends to be.”
Here’s an example I saw recently. An internal business unit wanted to introduce a new card type into the chassis set they managed. Speaking with the physical inventory team, it seemed the change was quite small and a budget was developed for the works… but the budget (dollars / time / risk) was about to blow out in a big way.
The new card wasn’t being picked up in their fault-management or performance management engines. It wasn’t picked up in key reports, nor was it being identified in the configuration management database or logical inventory. Every one of these systems needed interface changes. Not massive change obviously, but collectively the budget blew out by 10x and expedite changes pushed out the work previously planned by each of the interface development and testing teams.
These trickle-down impacts were known…. by some people…. but weren’t communicated to the business unit responsible for managing the new card type. There’s a possibility that they may not have even added the new card type if they realised the full OSS cost consequences.
Are these trickle-down impacts known and readily communicated within your OSS change processes?
There’s a crowded room of OSS experts, a room filled with serious intellectual horsepower. You might be a virtu-OSS-o, but you surely know that there’s still so much to be learnt from those around you. You have the chance to unlock the experiences and insights of your esteemed colleagues. But how? The answer might seem to be obvious. You do so by asking questions. Lots of questions.
But that obvious answer might have just one little unexpected twist.
Do you ask:
I’ve been in those rooms and heard the questions, as you have too no doubt. What do you think the ratio of ego to embarrassing would typically be? 10 to 1? 20 to 1?
The problem with the ego questions is that they can be so specific to the context of a few that they end up steering the conversations to the depths of technology hell (of course they can also end up inspiring / enlightening too, so I’m generalising here).
But have you observed that the very best in our industry happen to ask a lot of embarrassing questions?
A quote by Ramit Sethi splices in brilliantly here, “The very best ask lots of questions. 3 questions I almost never hear: (1) “Just a second. If you don’t mind me asking, how did you get to that?” (2) “I’m not sure I understand the conclusion — can you walk me through that?” (3) “How did you see that answer?” Ask these questions and stop worrying about being embarrassed. How else are you going to learn?”
Just for laughs, next time you’re at one of these events (and I notice that TM Forum Live is coming up in May), try to guess what the ego to embarrassing ratio might be there and which set of questions are spawning the more interesting / insightful / helpful conversations.
Let me warn you. The following sentence is going to make many OSS experts cringe, maybe even feel slightly disgusted, but take the time to read the remainder of the post and ponder how it fits within your specific OSS context/s.
“Our OSS need to help people spend money!”
Notice the word is “help” and not “coerce?” This is not a post about turning our OSS into sales tools, well, not directly anyway.
May I ask you a question – Do you ever spend time thinking about how your OSS is helping your customer’s customer (which I’ll refer to as the end-customer) to spend their money? And I mean making it easier for them to buy the stuff they want to buy in return for some form of value / utility, not trick or coerce them into buying stuff they don’t want.
Let me step you through the layers of thinking here.
The first layer for most OSS experts is their direct customer, which is usually the service provider or enterprise that buys and operates the OSS. We might think they are buying an OSS, but we’re wrong. An organisation buys an OSS, not because it wants an Operational Support System, but because it wants Operational Support.
The second layer is a distinct mindset change for most OSS experts. Following on from the first layer, OSS has the potential to be far more than just operational support. Operational support conjures up the image of being a cost-centre, or something that is a necessary evil of doing business (ie in support of other revenue-raising activities). To remain relevant and justify OSS project budgets, we have to flip the cost-centre mentality and demonstrate a clear connection with revenue chains. The more obvious the connection, the better. Are you wondering how?
That’s where the third layer comes in. We have to think hard about the end-customer and empathise with their experiences. These experiences might be a consumer to a service provider’s (your direct customer) product offerings. It might even be a buying cycle that the service provider’s products facilitate. Either way, we need to simplify their ability to buy.
So let’s work back up through those layers again:
Layer 3 – If end-customers find it easier to buy stuff, then your customer wins more revenue (and brand value)
Layer 2 – If your customer sees that its OSS / BSS has unquestionably influenced revenue increase, then more is invested on OSS projects
Layer 1 – If your customer recognises that your OSS / BSS has undeniably influenced the increased OSS project budget, you too get entrusted with a greater budget to attempt to repeat the increased end-customer buy cycle… but only if you continue to come up with ideas that make it easier for people (end-customers) to spend their money.
At what layer does your thinking stop?
A Passionate About OSS article last month spoke of how the investment strategy of a $106 billion VC fund has changed my thinking on our OSS‘ most valuable asset. Masayoshi Son is quoted in that article as follows:
“Those who rule data will rule the entire world. That’s what people of the future will say.”
But one question keeps coming back to me… if you’re ruling poor quality data, will you rule nothing whatsoever?
Along the same lines, the old adage, “practice makes perfect,” is not very helpful if you’re not practicing in a constructive way. A better (albeit somewhat impossible) variant on the adage would be “PERFECT practice makes perfect.”
Let me share an example. There is a product that is completely ground-breaking in its ability to automate and optimise designs of large-scale network roll-outs – designs that include outside plant and access network technologies. In bake-offs with some of the best available network designers, this product and its algorithm consistently beats the humans by far more than 25% (when measured by capital costs, implementation time and various other metrics).
Its one challenge in taking over the world and automating every future network design is having a base set of data that is so perfect that no re-design work is required. For example, if the base data says a duct route is available and has capacity for inserting a cable, then the product assumes it can use the duct in its optimal design. But when the field techs arrive at site, they find the duct is too badly damaged to use or already filled to capacity with other cables that can’t be overhauled. A new optimal design has to be calculated to consider the lack of availability of that duct.
The tool still gives great results, even after all the manual intervention, but perfect source data would give breathtaking results.
So I’d look to make one small tweak to Masayoshi Son’s quote. “Those who rule PERFECT* data will rule the entire world. That’s what people of the future will say.”
* whereby perfect means as high in quality as realistically possible.
So, perhaps those expensive data audits and cumbersome data quality processes will have a far greater ROI (Return on Investment) in future than any of us could ever estimate.
Many different user journeys flow through our OSS every day. These include external / customer journeys, internal / operator journeys and possibly even machines-to-machine or system journeys. Unfortunately, not all of these journeys are correctly completed through to resolution.
The incomplete or unsatisfactory journeys could include inter-system fall-outs, customer complaints, service quality issues, and many more.
If we categorise and graph these unsuccessful journeys, we will often find a graph like the one below. This example shows that a small number of journey categories account for a large proportion of the problematic journeys. However, it also shows a long tail of other categories that are individually insignificant, but collectively significant.
The place where everybody starts (including me) is to focus on the big wins on lhe left side of the graph. lt makes sense that this is where your efforts will have the biggest impacts. Unfortunately, since that’s where everybody focusses effort, chances are the significant gains have already been achieved and optimisation is already quite high (but numbers are still high due constraints within the existing solution stack).
The long tail intrigues me. It’s harder to build a business case for because there are many causes and little return for solving them. Alternatively, if we can slowly and systematically remove many of these rarer events, we’re removing the noise and narrowing our focus on the signal, thus simplifying our overall solution.
Since they’re statistically rarer, we can often afford to be more ruthless in the ways that we prevent them from occurring. But how do we identify and prevent them?
Each of the bars on the chart above represent leaves on a decision tree (faulty leaves in this case). If we work our way back up the branches, we can ruthlessly prune. Examples could be:
I’m sure you can think of many more, especially when you start tracing back up decision trees with a pruning saw in hand!!
Last Friday, we spoke about all wanting to develop trusted OSS supplier / customer relationships but rarely finding them and a contrarian factor for why trust is so hard to achieve in OSS – complexity.
Trust is the glue that allows OSS projects to happen. Not only that, it becomes a catch-22 with complexity. If OSS partners don’t trust each other, requirements, contracts, etc get more complex as a self-protection barrier. But with every increase in complexity, there becomes an increasing challenge to deliver and hence, risk of further reduction in trust.
On a smaller scale, you’ve seen it on all projects – if the project starts to falter, increased monitoring attention is placed on the project, which puts increased administrative load on the project team and reduces the time they have to deliver the intended outcomes. Sometimes the increased admin / report gains the attention of sponsors and access to additional resources, but usually it just detracts from the available delivery capability.
Vish Nandlall also associates trust and complexity in organisational models in his LinkedIn post below:
This is one of the reasons I’m excited about what smart contracts can do for the organisations and OSS projects of the future. Just as “Likes” and “Supplier Rankings” have facilitated online trust models, smart contracts success rankings have the ability to do the same for OSS suppliers, large and small. For example, rather than needing to engage “Big Vendor A” to build your entire, monolithic OSS stack, if an operator develops simpler, more modular work breakdowns (eg microservices), then they can engage “Freelancer B” and “Small Vendor C” to make valuable contributions on smaller risk increments. Being lower in complexity and risk means B and C have a greater chance of engendering trust, but their historical contract success ranking forces them to develop trust as a key metric.
“The survey found that 82 percent of service providers conduct less than half of customer transactions digitally, despite the fact that nearly 80 percent of respondents said they are moving forward with business-wide digital transformation programs of varying size and scale. This underscores a large perception gap in understanding, completing and benefiting from digitalization programs.
The study revealed that more than one-third of service providers have completed some aspect of digital transformation, but challenges persist; nearly three-quarters of service providers identify legacy systems and processes, challenges relating to staff and skillsets and business risk as the greatest obstacles to transforming digital services delivery.
Driving a successful digital transformation requires companies to transform myriad business and operational domains, including customer journeys, digital product catalogs, partner management platforms and networks via software-defined networking (SDN) and network functions virtualization (NFV).”
Survey from Netcracker and ICT Intuition.
Interesting study from Netcracker and ICT Intuition. To re-iterate with some key numbers and take-aways:
To overcome these challenges, I’ve noticed that some operators have been building up separate (often low-cost) brands with digital-native front ends, back ends, processes and skills bases. These brands tend to target the ever-expanding digitally native generations and be seen as the stepping stone to obsoleting legacy solutions (and perhaps even legacy business models?).
I wonder whether this is a market niche for smaller OSS players to target and grow into whilst the big OSS brands chase the bigger-brother operator brands?
Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer.
I’m an independent consultant, so I have been lucky enough to represent many organisations on both sides of that equation. And in that position, I’ve been able to get a first-hand view of the perception of trust between OSS vendors / integrators (suppliers) and operators (customers). Let’s just say that in general, we’re working in an industry with more scepticism than trust.
So if trust is so important and such a desired status, where is it breaking down?
Whilst I’d like to assume that most people in our industry go into OSS projects with the very best of intentions, there are definitely some suppliers that try to trick and entrap their customers whilst acting in an untrustworthy way. For the rest of this post, I’m going to assume the best – assume that we all have great intentions. We then look at why the trust relationships might be breaking down and some of the ways we can do better.
Jon Gordon provides a great list of 11 ways to build trust. Check out his link for a more detailed view, but the 11 factors are as follows:
They all sound quite obvious don’t they? Do you also notice that many of the 11 (eg communication, transparency, admitting failure, doing what you say, etc) can be really easy to say but harder to do flawlessly under the pressure of complex OSS delivery projects (and ongoing operations)?
I know I certainly can’t claim a perfect track record on all of these items. Numbers 1 and 2 can be particularly difficult when under extreme delivery pressure, especially when things just aren’t going to plan technically and you’re focussing attention on regaining control of the situation. In those situations, communication and transparency are what the customer needs to maintain confidence, but the customer relationship takes time that also needs to be allocated to overcoming the technical challenges. It becomes a balancing act.
So, how do we position ourselves to make it easier to keep to these 11 best intentions? Simple. By making a concerted effort to reduce complexity… actually not so simple as it sounds, but rewarding if you can achieve it. The less complex your delivery projects (or operational models), the more repeatable and reliable a supplier’s OSS delivery becomes. The more reliable, the less friction and a reduced chance of fracturing relationships. Subsequently, the more chance of building and retaining trust.
Hat-tip to Robert Curran of Aria Networks for spawning a discussion about trust.
Further to yesterday’s post on fast / slow processes and factory platforms, a concept presented by Sylvain Denis of Orange in Melbourne last week, here’s a diagram from Sylvain’s presentation pack :
The yellow blocks represent the fast (automated) processes. The orange blocks represent the slow processes.
The next slide showed the human interaction points (blue boxes) into this API / factory stack.
NEC Corporation and Netcracker Technology announced that Vodafone Group has selected NEC/Netcracker’s Hybrid Operations Management (HOM) solution to support its transition into a telecommunications cloud provider. The virtualization initiative will incorporate the use of cloud-native, SDN and NFV technologies to evolve operational and business systems and processes. NEC/Netcracker’s Hybrid Operations Management will support this initiative by orchestrating and managing end-to-end resources and services within Vodafone domains.
Vodafone Group is one of the world’s largest telecommunications companies and provides a range of services including voice, messaging, data and fixed communications.
NEC/Netcracker’s solution will help Vodafone streamline and automate operational processes across its operating companies in order to increase service efficiency and flexibility. This will reduce the time it takes to launch new services and enable dynamic, closed-loop operations with automated lifecycle capabilities in order to meet unpredictable and constantly changing network demand.
Vodafone and NEC/Netcracker will jointly demonstrate the power of orchestration to deliver zero-touch cloud services at Mobile World Congress 2018. The compelling demonstration underscores the role of orchestration to automate networks and services driving agility and cost efficiencies in the mobile market and will be showcased in Vodafone’s booth in Hall 3 Stand 3D30 and NEC/Netcracker’s booth in Hall 2 Stand 2H31.
“As we accelerate the transformation of our network and services to fully leverage cloud and virtualization, Orchestration and Automation plays a critical role in how we build and operate both the infrastructure and our business,” said Fran Heeran, Head of Network Virtualization, SDN and NFV at Vodafone Group. “We selected NEC/Netcracker due to its deep understanding of both physical and virtual domains and its unique capabilities for hybrid operations across physical and cloud environments.”
“As customer demands change, service providers are under increasing pressure to leverage networks that will enable the delivery of new services and support evolving customer lifestyles,” said Andrew Feinberg, President and CEO at Netcracker. “We are excited to work with Vodafone on its massive cloud transformation program, which will lay the foundation for innovation to deliver the next generation of digital services.”
AI (Artificial Intelligence) and networking pioneer Aria Networks has joined the ETSI group formed to lead the industry in mapping the future of AI and Networking.
The ETSI Experiential Networked Intelligence (ENI) Industry Specification Group (ISG) was set up in February 2017, to define a new architecture for network management leveraging Artificial Intelligence and Machine Learning to improve automation.
ETSI ENI already has the backing of telecom operators including Telecom Italia and Vodafone, as well as vendors such as Huawei, ZTE, Samsung and Xilinx. Aria is the first independent software vendor to join the group. (The full list of members is at https://portal.etsi.org/TBSiteMap/ENI/ListOfENIMembers.aspx)
Aria’s Head of Research, Dr Archie Wade, commented: “Network automation has risen to the top of the agenda for network operators in the last few years. But many operators are still taking quite a narrow view of what that means, and the role for AI. Through our participation in the ETSI ENI group, we hope to provide an industry blueprint for business-driven network automation, delivering real transformation.”
ETSI ENI Chair, Ray Forbes, added: “We welcome Aria’s involvement in our group. The practical application of AI techniques to networking challenges is a rare but vital skill set for this initiative.”
Aria Networks is a pioneer in the field of AI and Networking. Its software platform uses AI and Machine Learning to create optimal designs for complex networks, in response to any set of criteria (such as lowest latency, lowest power consumption) or conditions (such as scheduled or unplanned outages).
According to Aria, the use of Artificial intelligence technology is essential for automating new software-controlled, dynamic networks including 5G. By using AI to automate network design and optimisation processes, operators can achieve “closed loop” operations at a business level, delivering greater agility and scalability.
Aria has previously featured in high-profile industry collaborations such as Vodafone’s 2016 Mobile World Congress “VPN+” demonstration, and several TeleManagement Forum “Catalyst” collaborations on 5G slicing and closed loop automation.
Aria’s technology has been used by Tier 1 network operators including BT and Level3 as well as web-scale giants such as Facebook. Privately-held, the company is based in the UK.
It mentioned a couple of key challenges, one being that there will always be physical activities such as cable cuts fixes, faulty equipment replacement, physical equipment expansion / contraction / lifecycle-management.
In a TM Forum presentation last week, Sylvain Denis of Orange proposed the theory of fast and slow OSS processes. Fast – soft factories (software and logical resources) within the operations stack are inherently automatable (notwithstanding the complexities and cost-benefit dilemma of actually building automations). Slow – physical factories are slow processes as they usually rely on human tasks and/or have location constraints.
Orchestration relies on programmatic interfaces to both. Not all physical factories have programmatic interfaces in all OSS / BSS stacks yet. It will remain a key requirement for the forseeable future to be able to handle dual-speed processes / factories.
A couple of interesting concepts have the ability to fundamentally change the way networks and services are maintained. If they can be harnessed, we could replace the term “network assurance” with “network healing.”
The first concept is SON, which has been formulated specifically with mobile radio networks in mind, but has the potential to extend into all network types.
“A Self-Organizing Network (SON) is an automation technology designed to make the planning, configuration, management, optimization and healing of mobile radio access networks simpler and faster.”
One of the challenges of creating self-organising, self-optimising, self-healing networks is that every network has physical points of failure – cable cuts, equipment failure, etc. These can’t be fixed with software alone. That’s where the second concept comes in.
The second concept is smart-contract technology (possibly facilitated by Blockchain), which provides the potential for a more automated way of engaging a mini procurement / delivery / test / payment process to fix physical problems (or logical for that matter). Whilst the work might be done in the physical world, it could be done by third-parties, initiated by the OSS via microservice. Network Fix as a Service (NFaaS), with implementation, test, acceptance and payment all done in software as far as the OSS sees it.
To an extent this already happens via the issuance of ToW (Tickets of Work) to third party fault-fix teams, but it’s normally a significantly manual process currently.
However, the bigger challenge of transforming network assurance to network healing is to find a way to self-heal services that span multiple network domains. This could be physical network functions (PNF), virtual network functions (VNF) and the myriad topologies, technologies and protocols that interconnect them.
I can’t help but think that to simplify (self-healing) we first have to simplify (network variant minimisation).
If we can drastically reduce the number of variants, we have a better chance of building self-heal automations… and don’t just tell me that AI engines will solve all these problems! Maybe one day, but perhaps we can start with baby steps first.
I recently attended an event where a brainstorming question was posed about how a particular next-gen OSS concept might fail. Interesting exercise!
There were a lot of super-clever technical people in the room. The brainstorming of ideas was a fascinating one. We dived deeply into the experiences of many of the technical people in the room and all the potential technical reasons for failure.
But I was left with an overwhelming feeling that:
That’s where I’ve noticed a greater proportion of OSS project failures anyway. Does this align with your experiences?
NEC Corporation and Netcracker Technology announced that NEC/Netcracker’s Network-as-a-Service (NaaS) Business and Operational Support solution has gone into production at TELUS, a Canadian telecommunications company.
TELUS NaaS enables businesses to virtually build, manage and cloud-optimize their networks quickly, easily and cost-effectively through a flexible self-serve platform. New secure networking services, such as SD-WAN, can be configured up to 80 percent faster than traditional networks, enabling TELUS to better serve the needs of its customers while reducing networking costs.
The TELUS NaaS solution uses NEC/Netcracker’s Order Management and Service Orchestration. The NaaS platform also utilizes NEC/Netcracker’s Business Enablement Applications, including NaaS Self-Service for real-time configuration and monitoring, and Netcracker’s Customer and Product Information Management offerings.
“Service providers are looking for new ways to evolve their networks and embrace more open ecosystems. Thanks to the emergence of cloud architecture, software-defined networking and network virtualization technologies, NaaS represents a significant stride forward in achieving these opportunities,” said Uzi Murad, General Manager North America at Netcracker.
“By leveraging the power of TELUS’ advanced fiber network, we are able to deliver access to faster and more reliable business services, including innovative NaaS solutions, to more business customers than ever before,” said Ibrahim Gedeon, CTO at TELUS. “Collaborating with NEC/Netcracker has contributed to our ability to deliver SD-WAN and other next-generation services to meet our customers’ increasingly complex demands.”