TM Forum announces 2019 award winners

On Monday evening in Nice, TM Forum announced the list of 12 Excellence Awards for 2019. They also anointed Distinguished Fellow and Distinguished Engineer status on two of the industry’s leading contributors.

Huge congratulations to each of the following award winners:

  1. Business Transformation – Royal KPN, Vlocity and Salesforce
  2. IT Transformation – China Mobile & Huawei
  3. Operational Transformation & Agility – Netcracker
  4. Network Transformation – Telstra
  5. Digital Service Innovator of the Year – Orange
  6. Open Digital Ecosystem Platform of the Year – TELUS
  7. Disruptive Innovation – Etiya & Fizz, Zeotap
  8. Outstanding Customer Centricity – Whale Cloud & China Telecom
  9. Open API – DGiT, Netcracker
  10. CIO of the Year – Cody Sanford, T-Mobile USA
  11. CTO of the Year – Giovanni Chiarelli, MTN South Africa
  12. Future Digital Leader – Ye Ouyang, AsiaInfo
  13. Distinguished Fellow – Dr. Lester Thomas, Vodafone
  14. Distinguished Engineer – Takayuki Nakamura, NTT Group

I’m most excited about number 4 on the list, partly because I was involved in the early concept / PoC stages of Telstra’s NaaS (Network as a Service) project and because of what NaaS represents to our industry [more on that in tomorrow’s post]. I’m also excited to see a little Australian company, DGiT, appearing amongst a list that’s mostly made up of industry heavyweights.

Where does BSS end and OSS begin?

Over the years, I’ve been asked the question many times, “what’s the difference between OSS (Operational Support Systems) and BSS (Business Support Systems)?” I’ve also been asked, albeit slightly less regularly, how OSS and BSS map to TM Forum standards like the TAM and eTOM.

To my knowledge, TM Forum has never attempted to map OSS vs BSS. It sets off too many religious wars.

Just for fun, I thought I’d have a crack at trying to map OSS and BSS onto the TAM. Click on the image for a larger PDF version.

OSS and BSS overlaid onto the TAM

I’ve taken the perspective that customer or business-facing functionality is generally considered to be BSS. Alternatively, network / operations-facing functionality is generally considered to be OSS.
And these two tend to overlap at the service layer.

Or, you could just simply call them business operations systems (BOS) that cover the entire TAM estate.

What do you think? Does it trigger a religious war for you? Comments welcomed below.

FWIW. I come from an era when my “OSS” tools had a lot of functionality that could arguably be classified as BSS-centric (eg product management, customer relationship management, service order entry, etc). They also happened to deliver functionality that others might classify as NMS or EMS (Network Management System or Element Management System) in nature. In my mind, they’ve always just been software that supports operationalisation of a network, whether customer or network/resource-facing. It’s one of the reasons this site is called Passionate About OSS, not Passionate About OSS/BSS/NMS/EMS.

Top 10 most common OSS project risks

OSS projects are full of risks we all know it. OSS projects have “earned” a bad name because of all those risks. On the other side of that same coin, OSS projects disappoint, in part I suspect because stakeholders expect such big things from their resource investments.

Ask anyone familiar with OSS projects and you’ll be sure to hear a long list of failings.

For those less familiar with what an OSS project has in store for you, I’d like to share a list of the most common risks I’ve seen on OSS projects.

Most people working in the OSS industry are technology-centric, so they’ll tend to cite risks that relate to the tech. That’s where I used to focus attention too. Now technology risk definitely exists, but as you’ll see below, I tend to start by looking at other risk factors first these days.

Most common OSS project risks / issues:

  1. Complexity (to be honest, this is probably more the root-cause / issue that manifests as many of the following risks). However, complexity across many aspects of OSS projects is one of the biggest problem sources
  2. Change ManagementOSS tend to introduce significant change to an organisation – operationally, organisationally, processes, training, etc. This is probably the most regularly underestimated component of any large OSS build
  3. Stakeholder Support / Politics – Challenges appear on every single OSS project. They invariably need strong support from stakeholders and sponsors to clear a path through the biggest challenges. If the project’s leaders aren’t fully committed and in unison, the delivery teams will be heavily constrained
  4. Ill-defined Scope – Over-scoping, scope omission and scope creep all represent risks to an OSS project. But scope is never perfectly defined or static, so scope management mechanisms need to be developed up-front rather than in-flight. Tying back to point 1 above, complexity minimisation should be a key element of scope planning. To hark back to my motto for OSS, “just because we can, doesn’t mean we should)
  5. Financial and commercial – As with scope, it’s virtually impossible to plan an OSS project to perfection. There are always unknowns.These unknowns can directly impact the original estimates. Projects with blow-outs and no contingency for time or money increase pressure on point 3 (stakeholders/sponsors) to maintain their support
  6. Client resource skills / availability – An OSS has to be built to the needs of a client. If the client is unable to provide resources to steer the implementation, then it’s unlikely for the client to get a solution that is perfectly adapted to the client’s needs. One challenge for the client is that their most valuable guides, those with the client’s tribal knowledge, are also generally in high demand by “business as usual” teams. It becomes a challenge to allocate enough of their time to guide  the OSS delivery team. Another challenge is augmenting the team with the required skill-set when a project introduces new skill requirements
  7. CommunicationOSS projects aren’t built in a vacuum. They have many project contributors and even more end-users. There are many business units that touch an OSS/BSS, each with their own jargon and interpretations.  For example, how many alternate uses of the term “service” can you think of? I think an important early-stage activity is to agree on and document naming conventions
  8. Culture – Of the client team and/or project team. Culture contributes to (or detracts from) motivation, morale, resource turnover, etc, which can have an impact on the team’s ability to deliver
  9. Design / Integration – Finally, a technology risk. This item is particularly relevant with complex projects, it can be difficult for all of the planned components to operate and integrate as planned. A commonly unrecognised risk relates to the viability of implementing a design. It’s common for an end-state design to be specified but with no way of navigating through a series of steps / phases and reach the end-state
  10. Technology – Similar to the previous point, there are many technology risks relating to items such as quality, scalability, resiliency, security, supportability, obsolescence, interoperability, etc

There’s one thing you will have probably noticed about this list. Most of the risks are common to other projects, not just OSS projects. However, the risks do tend to amplify on OSS projects because of their inherent complexity.

TM Forum’s Digital Transformation World (DTW) starts tomorrow

For those who don’t already know, one of the peak OSS industry events starts tomorrow in Nice, France. It’s known as Digital Transformation World (DTW) and is run by TM Forum.

OSS and BSS (and so much more) experts will be there, collaborating via multiple different methods – talks, presentations, demonstrations, industry proofs-of-concept, campfire events, etc.

Leave us a comment below if you’re attending and tell us what you’re most excited about.

Inverting the pyramid of OSS and network innovation

Back in the earliest days of OSS (and networks for that matter), it was the telcos that generated almost all of the innovation. That effectively limited innovation to being developed by the privileged few, those who worked for the government-owned, monopoly telcos.

But over time, the financial leaders at those telcos felt the costs of their amazing research and development labs outweighed the benefits and shut them down (or starved them at best). OSS (and network) vendors stepped into the void to assume responsibility for most of the innovation. But there was a dilemma for the vendors (and for telcos and consumers too) – they needed to innovate fast enough to win work against their competitors, but slow enough to accrue revenues from the investment in their earlier innovations. And innovation was still being constrained to the privileged few, those who worked for vendors and integrators.

Now, the telcos are increasingly pushing to innovate wider and faster than the current vendor collective can accommodate. It means we have to reach further out to the long-tail of innovators. To open the floor beyond the privileged few. Excitingly, this opportunity appears to be looming.

“How?” you may ask.

Network as a Service (NaaS) and API platform offerings.

If every telco offers consumption of their infrastructure via API, it provides the opportunity for any developer to bundle their own unique offering of products, services, applications, hosting, etc and take it to market. If you’re heading to TM Forum’s Digital Transformation World (DTW) in Nice next week, there are a number of Catalyst projects on display in this space, including:

Zero-touch partnering could make platform ‘utopia’ real for telcos

Packaging Open APIs for NaaS

The challenge for the telcos is in how to support the growth of this model. To foster the vendor market, it was easy enough for the telcos to identify the big suppliers and funnel projects (and funding) through them. But now they have to figure out a funnel that’s segmented at a much smaller scale – to facilitate take-up by the millions of developers globally who might consume their products (network APIs in this case) rather than the hundreds/thousands of large suppliers.

This brings us back to smart contracts and micro-procurement as well as the technologies such as blockchain that support these models. This ties in with another TM Forum initiative to revolutionise the procurement event:

Time to kill the RFP? Reinventing IT procurement for the 2020s: Volume 1

But an additional benefit for the telcos, if and when the NaaS platform model takes hold, is that the developers also become a unpaid salesforce for the telcos. The developers will be responsible for marketing and selling their own bundles, which will drive consumption and revenues on the telcos’ assets.

Exciting new business models and supply chains are bound to evolve out of this long tail of innovation.

Could you believe it? An OSS with less features that helps more?

All OSS products are excellent these days. And all OSS vendors know what the most important functionality is. They already have those features built into their products. That is, they’ve already added the all-important features at the left side of the graph.
Long-tail features

But it also means product teams are tending to only add the relatively unimportant new features to the right edge of the graph (ie inside the red box). Relatively unimportant and therefore delivering minimal differential advantage.

The challenge for users is that there is a huge amount of relatively worthless functionality that they have to navigate around. This tends to make the user interfaces non-intuitive.

In a previous post, we mentioned that it’s the services wrapper where OSS suppliers have the potential to differentiate.

But another approach, a product-led differentiator, dawned on me when discussing the many sources of OSS friction in yesterday’s post. What if we asked our product teams to take a focus on designing solutions that remove friction instead of the typical approach of adding features (and complexity)?

Almost every OSS I’m aware of has many areas of friction. It’s what gives the OSS industry a bad name. But what if one vendor reduced friction to levels far less than any other competitor? Would it be a differentiator? I’m quite certain customers would be lining up to buy a frictionless OSS even if it didn’t have every perceivable feature.

But can it work? What do you think?

Is your OSS squeaking like an un-oiled bearing?

Network operators spend huge amounts on building and maintaining their OSS/BSS every year. There are many reasons they invest so heavily, but in most cases it can be distilled back to one thing – improving operational efficiency.

And our OSS/BSS definitely do improve operational efficiency, but there are still so many sources of friction. They’re squeaking like un-oiled bearings. Here are just a few of the common sources:

  1. First-time Installation
  2. Identifying best-fit tools
  3. Procurement of new tools
  4. Update / release processes
  5. Continuous data quality / consistency improvement
  6. Navigating to all features through the user interface
  7. Non-intuitive functionality / processes
  8. So many variants / complexity that end-users take years to attain expert-level capability
  9. Integration / interconnect
  10. Getting new starters up to speed
  11. Getting proficient operators to expertise
  12. Unlocking actionable insights from huge data piles
  13. Resolving the root-cause of complex faults
  14. Onboarding new customers
  15. Productionising new functionality
  16. Exception and fallout handling
  17. Access to supplier expertise to resolve challenges

The list goes on far deeper than that list too. The challenge for many OSS product teams, for any number of reasons, is that their focus is on adding new features rather than reducing friction in what already exists.

The challenge for product teams is diagnosing where the friction  and risks are for their customers / stakeholders. How do you get that feedback?

  • Every vendor has a product support team, so that’s a useful place to start, both in terms of what’s generating the most support calls and in terms of first-hand feedback from customers
  • Do you hold user forums on a regular basis, where you get many of your customers together to discuss their challenges, your future roadmap, new improvements / features
  • Does your process “flow” data show where the sticking points are for operators
  • Do you conduct gemba walks with your customers
  • Do you have a program of ensuring all developers spend at least a few days a year interacting directly with customers on their site/s
  • Do you observe areas of difficulty when delivering training
  • Do you go out of your way to ask your customers / stakeholders questions that are framed around their pain-points, not just framed within the context of your existing OSS
  • Do you conduct customer surveys? More importantly, do you conduct surveys through an independent third-party?

On the last dot-point, I’ve been surprised at some of the profound insights end-users have shared with me when I’ve been conducting these reviews as the independent interviewer. I’ve tended to find answers are more open / honest when being delivered to an independent third-party than if the supplier asks directly. If you’d like assistance running a third-party review, leave us a note on the contact page. We’d be delighted to assist.

Fast and slow OSS, where uCPE and network virtualisation fits in

Yesterday’s post talked about one of the many dichotomies in OSSfast and slow data / processes.

One of the longer lead-time items in relation to OSS data and processes is in network build and customer connections. From the time when capacity planning or a customer order creates the signal to build, it can be many weeks or months before the physical infrastructure work is complete and appearing in the OSS.

There are two financial downsides to this. Firstly, it tends to be CAPEX-heavy with equipment, construction, truck-rolls, government approvals, etc burning through money. Meanwhile, it’s also a period where there is no money coming in because the services aren’t turned on yet. The time-to-cash cycle of new build (or augmentation) is the bane of all telcos.

This is one of the exciting aspects of network virtualisation for telcos. In a time where connectivity is nearly ubiquitous in most countries, often with high-speed broadband access, physical build becomes less essential (except over-builds). Technologies such as uCPE (Universal Customer Premises Equipment), NFV (Network Function Virtualisation), SD WAN (Software-Defined Wide Area Networks), SDN (Software Defined Networks) and others mean that we can remotely upgrade and reconfigure the network without field work.

Network virtualisation gives the potential to speed up many of the slowest, and costliest processes that run through our OSS… but only if our OSS can support efficient orchestration of virtualised networks. And that means having an OSS with the flexibility to easily change out slow processes to replace them with fast ones without massive overhauls.

Give me a fast OSS and I might ask you to slooooow doooown

The traditional telco (and OSS) ran at different speeds. Some tasks had to happen immediately (eg customers calling one another) while others took time (eg getting a connection to a customer’s home, which included designs, approvals, builds, etc), often weeks.

Our OSS have processes that must happen sequentially and expediently. They also have processes that must wait for dependencies, conditional events and time delays. Some roles need “fast,” others can cope with “slow.” Who wins out in this dilemma?

Even the data we rely on can transact at different speeds. For capacity planning, we’re generally interested in longer-term data. We don’t have to process at real-time. Therefore we can choose to batch process at longer cycle times and with summarised data sets. For network assurance, we’re generally interested in getting data as quick as is viable.

Today’s post is about that word, viable, and pragmatism we sometimes have to apply to our OSS.

For example, if our operations teams want to reduce network performance poll cycles from every 15 mins down to once a minute, we increase the amount of data to process by 15x. That means our data storage costs go up by 15x (assuming a flat-rate cost structure applies). The other hidden cost is that our compute and network costs also go up because we have to transfer and process 15x as much data.

The trade-off we have to make in responses to this rapid escalation of cost (when going from 15 to 1 min) is in the benefits we might derive. Can we avoid SLA (Service Level Agreement) breach costs? Can we avoid costly outages? Can we avoid damage to equipment? Can we reduce the risk of losing our carrier license?

The other question is whether our operators actually have the ability to respond to 15x as much data. Do we have enough people to respond at an increased cycle time? Do we have OSS tools that are capable of filtering what’s important and disregarding “background” activity? Do we have OSS tools that are capable of learning from every single metric (eg AI), at volumes the human brain could never cope with?

Does it make sense that we have a single platform for handling fast and slow processes? For example, do we use the same platform to process 1 minute-cycle performance data for long-term planning (batch-processed once daily) and quick-fire assurance (processed as fast as possible)?

If we stick to one platform, can our OSS apply data reduction techniques (eg selective discard of records) to get the benefits of speed, but with the cost reduction of slow?

Hansen acquires Sigma Systems

Acquisition of Sigma Systems.

Hansen Technologies Limited announced the signing of definitive agreements for the acquisition of Sigma Systems (“Sigma”). The acquisition is expected to close on 31 May 2019.

Key Points:

Founded in 1996, Sigma is a leading global provider of catalog-driven software products for telecommunications, media, and high-tech companies. Its software is designed to streamline complex product and service offerings and provide a faster path to creating, selling and delivering new digital products and services, combined and packaged with traditional core services.
It is being acquired for an enterprise value (EV) of CAD157.0m (AUD166.2m1) – which equates to an EV/EBITDA acquisition multiple of 8.3 times calendar year 2018 (CY182) normalised EBITDA3
Funding for the acquisition will be 100% provided by a new bank debt facility of AUD225m underwritten by RBC Capital Markets.
Sigma has been majority owned by private equity investor Birch Hill Equity Partners Management since 2015.
CY18 revenue was CAD73.1m (AUD75.5m4) and CY18 normalised EBITDA3 was CAD18.8m (AUD19.4m4).
CY18 revenue split was Americas 56%, EMEA 29% and APAC 15%.
Sigma has more than 70 customers with deployments in some 40 countries. Tier 1 customers include Liberty Global, Telstra, Vodafone, Inmarsat, Telkomsel, Altice, and Cox Communications.
Sigma has more than 480 staff with major offices located in Toronto, Canada (Head Office), London and Wales (UK) and Pune, India.
The strong strategic rationale for the acquisition includes:
The business is a high-quality asset – being a global leader in providing enterprise catalog-driven software products to the communications, media and high-tech sectors
It significantly expands Hansen’s scale and scope in the telecommunications sector – revenue from the telecommunications sector would have been 38% of total revenue in CY18 on a pro-forma basis if Sigma was owned during that period, compared to actual of 17%
Cross-sell opportunities exist into Hansen’s large utilities customer base by integrating the Catalog product into our energy product offerings, as well as PayTV.
The acquisition is expected to be earnings per share (EPS) accretive in FY202, excluding amortisation of acquired intangibles5.

Sigma Overview
Products
The Sigma product portfolio comprises catalog-driven software solutions that streamlines complex product and service offerings for communications, media, and high-tech companies.

The product portfolio includes:

Catalog – which provides a single source of “knowledge” for all of the service provider’s products and services, enabling the introduction and management of new and existing products and services with a single point of control, thus reducing the time-to-market for new offerings.
Configure Price Quote (CPQ) – Catalog-driven, this product applies real-time, enterprise-wide pricing structures to quote and capture orders, from standardised consumer offerings to complex tailored enterprise services.
Order Management – provides end-to-end management of an order, from when it is placed to when it is fulfilled and operational.
Portfolio Inventory – provides a single source of “knowledge” on all the products customers have ordered, the services that were activated for those products, and the resources that were provisioned for those services.
Provisioning – a network service and device activation product that manages, tracks and activates a complete range of network communication services and devices from a set of preconfigured activation solutions.
Insights – an analytics tool that provides service providers with real-time visibility of operational and sales performance at a granular level, allowing them to adjust sales strategies as necessary.
Sigma’s products enable business growth from new digital services combined and packaged with traditional core services. The product suite is highly complementary in nature and drives cross-sell expansion after initial deployment of one product. Product deployment can be either cloud or on-premise.

Sigma’s go-to-market strategy comprises a global direct sales force, combined with partnering with several systems integrators and CRM providers such as PwC, Infosys, Tech Mahindra, Microsoft and Salesforce to expand reach.

Customer Base
Sigma has a diversified revenue base with over 70 customers globally with deployments in approximately 40 countries. The average customer age is more than 8 years and includes many Tier 1 operators across the globe.

Customers include: Vodafone, Liberty Global, Telstra (Australia), Altice, Cox Communications (USA), Ziggo (Netherlands), Telkomsel (Indonesia), J:Com (Japan), Inmarsat (UK), Telmex (Mexico), Tiscali (Italy), Telus (Canada), Sky (UK), EWE TEL (Germany) and ViaSat (USA).

Financial Profile
Revenue in calendar year 2018 (CY18) was CAD73.1m (AUD75.5m4) and CY18 normalised EBITDA3 was CAD18.8m (AUD19.4m4), equating to a normalised EBITDA margin of 25.7%

Sigma has high levels of recurring revenue – derived from maintenance & support fees, periodic licence fees and managed professional services, while non-recurring revenue is derived from professional services and one-off licence fees.

CY18 revenue split was Americas 56%, EMEA 29% and APAC 15%.

Strategic Rationale
There is strong strategic rationale for the acquisition:

The business is a high-quality asset – being a global leader in providing enterprise catalog-driven software products to the communications, media and high-tech sectors
Sigma’s proprietary products sit within or adjacent to our core business of billing and customer management, and are well designed to capture growth opportunities from the rollout of new telecommunications services such as 5G
It significantly expands Hansen’s scale and scope in the telecommunications sector – revenue from the telecommunications sector would have been 38% of total revenue in CY18 on a pro-forma basis if Sigma was owned during that period, compared to actual of 17%
Cross-sell opportunities exist into Hansen’s large utilities customer base by integrating the Catalog product into our energy product offerings, as well as PayTV
Sigma further expands the depth and breadth of our global presence
It is expected to be earnings per share accretive in FY20, excluding amortisation of acquired intangibles5.

About the OSS that transmits on radio station WIIFM

Nobody is interested in you, your brand or your OSS.

Well, that’s a big negative and confrontational statement isn’t it? You’re probably thinking I got out of the wrong side of the bed this morning and took a big handful of emo pills.

The reality is, all of our customers and colleagues are walking around tuned into radio station WIIFM (What’s in it for me?), so it’s our job to transmit on that wavelength if we expect to be heard.

The example I’d like to talk about today is the OSS NASCAR page. You know the page don’t you? It’s the one in the vendor’s deck that contains logos of all their past customers. It looks a little like the image below, but without the Goodyear tyre hopefully.
Sponsors emblazened on the side of a NASCAR

The NASCAR page is a great social proof persuasion technique, one that shows all the other clever customers who have signed with this vendor… and therefore you should too. But like Spiderman, my cynic senses start tingling when I see a page like this. Of the full page of past clients, it’s likely that very few of those logos represent a scope that resembles my OSS needs. Many are probably using different OSS product mixes, processes, data sources, etc.

The thing I find interesting is that in all the years of seeing vendor presentations like this, I can only ever recall a couple of presentations that ever took the NASCAR page to the next level. That is, to select 2 or 3 of those logos and dive into detail to show how they were similar to my project and demonstrate how they had solved my problems on those projects previously.

That one little step tells me the vendor is not just using a standard presentation deck, but has truly moulded it for presentation on station WIIFM.

And I should point out here that the WIIFM technique is not just relevant to vendors. Not by any stretch. It surely has relevance to your situation too. For example, if you’re building an OSS for internal customers, are you ensuring that it’s built and communicated at their wavelength?

What’s your experience? Leave me a comment below to share your experience of the OSS industry:

  • WIIFM – if you feel the OSS market transmits on your wavelength and addresses your problems
  • IAAT (It’s all about themselves) – if you feel the OSS market only transmits on the wavelength that’s important to them

Elon Musk’s SpaceX gets FCC approval to beam broadband from space

FCC AUTHORIZES SPACEX TO PROVIDE BROADBAND SERVICES VIA SATELLITE CONSTELLATION.

The Federal Communications Commission (FCC) approved an application by Space Exploration Holdings, doing business as SpaceX, to provide broadband services using satellite technology in the United States and around the world. With this action, the Commission takes another step to increase high-speed broadband availability and competition in the United States.

This is the first approval of a U.S.-licensed satellite constellation to provide broadband services using a new generation of low-Earth orbit satellite technologies. SpaceX proposed a satellite system comprised of 4,425 satellites and was granted authority to use frequencies in the Ka (20/30 GHz) and Ku (11/14 GHz) bands to provide global Internet connectivity.

The Memorandum Opinion, Order and Authorization today outlines the conditions under which SpaceX is authorized to provide service using its proposed NGSO FSS satellite constellation. Specifically, the Order specifies the conditions to ensure compliance with Commission rules, and to protect other operations in the requested frequency bands.

Over the past year, the FCC has approved requests by OneWeb, Space Norway, and Telesat to access the United States market to provide broadband services using satellite technology that holds promise to expand Internet access, particularly in remote and rural areas across the country. These approvals are the first of their kind for a new generation of large, non-geostationary satellite orbit, fixed-satellite service systems, and the Commission continues to process other, similar requests.

Would you hire a furniture maker as an OSS CEO?

Well, would you hire a furniture maker as CEO of an OSS vendor?

At face value, it would seem to be an odd selection right? There doesn’t seem to be much commonality between furniture and OSS does there? It seems as likely as hiring a furniture maker to be CEO of a car maker?

Oh wait. That did happen.

Ford Motor Company made just such a decision last year when appointing Jim Hackett, a furniture industry veteran, as its CEO. Whether the appointment proves successful or not, it’s interesting that Ford made the decision. But why? To focus on user experience and design as it’s next big differentiator. Clever line of thinking Bill Ford!!

I’ve prepared a slightly light-hearted table for comparison purposes between cars and OSS. Both are worth comparing as they’re both complex feats of human engineering:

Idx Comparison Criteria Car OSS
1 Primary objective Transport passengers between destinations Operationalise and monetise a comms network
2 Claimed “Business” justification Personal freedom Reducing the cost of operations
3 Operation of common functionality without conscious thought (developed through years of operator practice) Steering

Changing gears

Indicating

Hmmm??? Depends on which sales person or operator you speak with
4 Error detection and current-state monitoring Warning lights and instrument cluster/s Alarm lists, performance graphs
5 Key differentiator for customers (1970’s) Engine size Database / CPU size
6 Key differentiator for customers (2000’s) Gadgets / functions / cup-holders Functionality
7 Key differentiator for customers (2020+) User Experience

Self-driving

Connected car (car as an “experience platform”)

User Experience??

Zero-touch assurance?

Connected OSS (ie OSS as an experience platform)???

I’d like to focus on three key areas next:

  1. Item 3
  2. Item 4 and
  3. The transition between items 6 and 7

Item 3 – operating on auto-pilot

If we reference against item 1, the primary objective, experienced operators of cars can navigate from point A to point B with little conscious thought. Key activities such as steering, changing gears and Indicating can be done almost as a background task by our brains whilst doing other mental processing (talking, thinking, listening to podcasts, etc).

Experienced operators of OSS can do primary objectives quickly, but probably not on auto-pilot. There are too many “levers” to pull, too many decisions to make, too many options to choose from, for operators to background-process key OSS activities. The question is, could we re-architect to achieve key objectives more as background processing tasks?

Item 4 – error detection and monitoring

In a car, error detection is also a background task, where operators are rarely notified, only for critical alerts (eg engine light, fuel tank empty, etc). In an OSS, error detection is not a background task. We need full-time staff monitoring all the alarms and alerts popping up on our consoles! Sometimes they scroll off the page too fast for us to even contemplate.

In a car, monitoring is kept to the bare essentials (speedo, tacho, fuel guage, etc). In an OSS, we tend to be great at information overload – we have a billion graphs and are never sure which ones, or which thresholds, actually allow us to operate our “vehicle” effectively. So we show them all.

Transitioning from current to future-state differentiators

In cars, we’ve finally reached peak-cup-holders. Manufacturers know they can no longer differentiate from competitors just by having more cup-holders (at least, I think this claim is true). They’ve also realised that even entry-level cars have an astounding list of features that are only supplementary to the primary objective (see item 1). They now know it’s not the amount of functionality, but how seamlessly and intuitively the users interact with the vehicle on end-to-end tasks. The car is now seen as an extension of the user’s phone rather than vice versa, unlike the recent past.

In OSS, I’ve yet to see a single cup holder (apart from the old gag about CD trays). Vendors mark that down – cup holders could be a good differentiator. But seriously, I’m not sure if we realise the OSS arms race of features is no longer the differentiator. Intuitive end-to-end user experience can be a huge differentiator amongst the sea of complex designs, user interfaces and processes available currently. But nobody seems to be talking about this. Go to any OSS event and we only hear from engineers talking about features. Where are the UX experts talking about innovative new ways for users to interact with machines to achieve primary objectives (see item 1)?

But a functionality arms race isn’t a completely dead differentiator. In cars, there is a horizon of next-level features that can be true differentiators like self-driving or hover-cars. Likewise in OSS, incremental functionality increases aren’t differentiators. However, any vendor that can not just discuss, but can produce next-level capabilities like zero touch assurance (ZTA) and automated O2A (Order to Activate) will definitely hold a competitive advantage.

Hat tip to Jerry Useem, whose article on Atlantic provided the idea seed for this OSS post.

Do you wish more people fell in love with your OSS?

I’d hazard a guess that everyone reading this would admit to being a techie at some level. And being a techie, I’d also imagine that you have blatant tech-love for certain products – gadgets, apps, sites, whatever.

But, let me ask you, are there any OSS products on your love-interest list?

If yes, leave me a comment of “yes” and name of the product below.
If no, leave me a comment of “no” below.

I’m really interested and intrigued to see your answer.

There’s probably only one OSS that I’ve ever had a tech-crush on (but it’s no longer available on the market). It definitely wasn’t love at first sight. If I’m honest, it was probably the opposite. It was a love that took a long time to build. It had some cool modules, but generally it was a bit clunky. The real attraction was that the power and elegance of its data model allowed me to do almost anything with it. To build almost anything with it. To answer almost any business / network / operation question that I could dream up.

I wonder whether the same is true of your other tech-loves? Do they provide the platform for us to create/achieve things that we never dreamed we’d be able to?

If that’s true, I wonder then whether that’s one key to solving the header question?

I wonder whether the other key (the second authentication factor) is in the speed that a user can achieve the necessary level of expertise? Few users ever have the luxury that I had, spending every day for years, to establish the required expertise to make that OSS excel.

As Seth Godin says, “Make things better by making better things.”

PS. If you were kind enough to leave a Yes or No comment below, I’d also love to hear why in an additional comment.

The no accounts receivable OSS model

Unfortunately for OSS vendors / integrators, their business models have a dependency (and major risk) on accounts receivable.

Investopedia states, “Accounts receivable are amounts of money owed by customers to another entity for goods or services delivered or used on credit but not yet paid for by clients.”

One of the earliest OSS projects I worked on was worth in excess of $30m for the vendor. It was a multi-year implementation. Two years in, they’d only received the initial mobilisation payment. With implementation costs blowing out, it was proving to be a major challenge for the company to continue operating.

The team had delivered a majority of the functionality written into the contract, as well as many other features negotiated in-flight. It was successfully being used in production, helping to deliver revenues to the customer. Unfortunately for the vendor, there was some key functionality that was still a way off being delivered. That meant contractual objectives hadn’t all lined up for payments to occur.

The balance of financial power was definitely in the hands of the customer.

Whether it’s in a large, complex implementation or ongoing license fees, accounts receivable can be the bane of OSS vendors.

That’s why I try to establish a no accounts receivable model for OSS vendors. That means up-front payment, but as shown below, means up-front value also needs to be delivered. It’s one of the attractive aspects of cloud-delivery business models.

The project I mentioned above had a product suite that worked out of the box, but only delivered value after features, data, integrations and automations were custom built… over a period of years.

So a couple of questions for the OSS vendors out there:

  1. How to deliver value, not just functionality, early in a project and then ongoing through the product lifecycle?
  2. How to give the customer enough confidence that they’ll receive up-front (and recurring) value that they’re prepared to pay up-front (and recurring)?

Leave me a comment below if accounts receivable is a bane of your organisation’s existence or whether you’ve found a way to have less reliance on AR.

Ooops. The 3GPP network management omission

A recent discussion with a learned and respected OSS colleague reminded me that there had been a major omission from the PAOSS History / Standards page. With the buzz developing around 5G, not to mention some of the advanced features like network slicing and radio infrastructure virtualisation, the oversight was a big one. We’d forgotten to include radio network management standards.

We’ve filled that gap now by adding a section relating to the network and service management standards prepared by 3GPP.

But what’s now concerning me is, “what else is missing?”

Would you mind doing me a favour? Would you like to quickly skim through the link above and let me know if there’s anything else that needs to be added? I know you’re really busy and your time is valuable, so any input you might find time for would be greatly appreciated.

What are OSS “platform wrapper” roadblocks?

OSS can be cumbersome at times. Making change can be difficult. We tend to build layers of protections around them and the networks we manage. I get that. Change can be risky (although the protections are often implemented because the OSS and/or network platforms might not be as robust as they could be).

Contrast this with the OSS we want to create. We want to create a platform for rapid innovation, the platform that helps us and our clients generate opportunities and advantages.

For us to build a platform that allows our customers (and their customers) to revolutionise their markets, we might have to consider whether the protective layers around our OSS that are stymying change. Things like firewall burns, change review boards, documentation, approvals, politics, individuals with a reticence to change, etc.

For example, Netflix takes a contrarian, whitelist approach to access by its engineers rather than a blacklist. It assumes that its engineers are professional enough to only use the tools that they need to get their tasks done. They enable their engineers to use commonly off-limits functionality such as adding their own DNS records (ie to support the stand-up of new infrastructure). But they also take a use-it-or-lose-it approach, monitoring the tools that the engineer uses and rescinding access to tools they haven’t used within 90 days. But if they do need access again, it’s as simple as a message on Slack to reinstate it.

This is just one small example of streamlining the platform wrapper. There are probably a million others.

When working on OSS projects as the integrator / installer, I’ve seen many of these “platform wrapper” roadblocks. I’m sure you have too. If you see them as the installer, chances are the ops team you hand over to will also experience these roadblocks.

Question though. Do you flag these platform wrapper roadblocks for improvement, or do you treat them as non-platform and therefore just live with them?

Only do the OSS that only you can do

A friend of mine has a great saying, “only do what only you can do.”

Do you think that this holds true for the companies undergoing digital transformation? Banks are now IT companies. Insurers are IT companies. Car manufacturers are now IT companies. Telcos are, well, some are IT companies.

We’ve spoken before about the skill transformations that need to happen within telcos if they’re to become IT companies. Some are actively helping their workforce to become more developer-centric. Some of the big telcos that I’ve been assisting in the last few years are embarking on bold Agile-led IT transformations. They’re cutting more of their own code and managing their own IT developments.

That’s exciting news for all of us in OSS. Even if it loses the name OSS in future, telcos will still need software that efficiently operationalises their networks. We have the overlapping skills in software, networks, business and operations.

But I wonder about the longevity of the in-house approach unless we come focus clearly on the first quote above. If all development is brought in-house, we end up with a lot of duplication across the industry. I’m not really sure that it makes sense doing all the heavy-lifting of all custom OSS tools when the heavy-lifting has already been done elsewhere.

It’s the old ebb and flow between in-house and outsourced OSS.

In my very humble opinion, it’s not just a choice between in-house and outsourced that matters. The more important decisions are around choosing to only develop the tools in-house that only you can do (ie the strategic differentiators).