The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?
No?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

The OSS Think Big juxtaposition

I recently saw the advertisement below:

I’ve clipped only the last 10 seconds because that was the part that struck me. The ad is for BHP*, one of the world’s largest miners. The mining industry thinks in long-term projects because it takes many years to deliver results – for exploration, planning, approvals, for the infrastructure to be built and operationalised, etc.

Mining is “only” the process of pulling natural resources out of the ground, but despite all our complexities, mining projects tend to be far more complex than for OSS. The decade-long duration of projects means that technologies that were originally included in plans frequently become obsolete mid-flight and have to be re-planned. That means major contracts also need to be obsoleted and re-planned mid-flight. Work-force management has a completely different scale than for OSS.

Mining thinks in time-frames of decades. OSS transformations are planned in time-frames of years. OSS delivery, especially Agile deliveries, often only think in quarters (or much, much less).

In OSS, do we really Think Big?

But there’s a twist on this question. In the rare cases when we do think big, are we constraining ourselves by then following into the “deliver big” mindset too? In OSS, I’ve always felt that we deliver most efficiently when very small numbers of very clever people group together.

So there’s the juxtaposition with the clip above – Think Big… Think Small.

When you’re thinking of OSS roadmaps, what’s your thinking time-frame?

* For disclosure, I’m not an investor in BHP to my knowledge, but perhaps my super fund is.

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

Use cases for architectural smoke-tests

I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.”

Yesterday’s blog discussed the use of use cases to test a new OSS architecture. TM Forum’s eTOM is the go-to model for process mapping for OSS / BSS. Their process maps define multi-level standards (in terms of granularity of process mapping) to promote a level of process repeatability across the industry. Their clickable model allows you to drill down through the layers of interest to you (note that this is available for members only though).

In terms of quick smoke-testing an OSS stack though, I tend to use a simpler list of use cases for an 80/20 coverage:

  • Service qualification (SQ)
  • Adding new customers
  • New customer orders (order handling)
  • Changes to orders (adds / moves / changes / deletes / suspends / resumes)
  • Logging an incident
  • Running a report
  • Creating a new product (for sale to customers)
  • Tracking network health (which may include tracking of faults, performance, traffic engineering, QoS analysis, etc)
  • Performing network intelligence (viewing inventory, capacity, tracing paths, sites, etc)
  • Performing service intelligence (viewing service health, utilised resources, SLA threshold analysis, etc)
  • Extracting configurations (eg network, device, product, customer or service configs)
  • Tracking customer interactions (and all internal / external events that may impact customer experience such as site visits, bills, etc)
  • Running reports (of all sorts)
  • Data imports
  • Data exports
  • Performing an enquiry (by a customer, for the purpose of sales, service health, parameters, etc)
  • Bill creation

There are many more that may be required depending on what your OSS stack needs to deliver, but hopefully this is a starting point to help your own smoke tests.

Use-case driven OSS architecture

When it comes to designing a multi-vendor (sometimes also referred to as best-of-breed) OSS architecture stack, there is never a truer saying than, “the devil is in the detail.”

Oftentimes, it’s just not feasible to design every interface / integration / data-flow traversing a theoretical OSS stack (eg pre-contract award, whilst building a business case, etc). That level of detail is developed during detailed design or perhaps tech-spikes in the Agile world.

In this interim state, I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.

Can you define why OSS projects are so challenging?

Answer. Change creates incompetence.

Whether on the vendor/integrator side, the customer side or along the strategic advisor line, OSS projects bring about constant change; massive change.

I’ve often wondered why I can feel so incompetent in the world of OSS, even though I know more about it than (probably) any other topic.

The answer has just dawned on me, as per above – change creates incompetence. There is so much change happening on so many levels within OSS that every one of us is a freshly-minted incompetent, no matter how much prior competence we may’ve built up.

And this defines the double-edged sword of OSS. The pain of feeling incompetent drives the thirst for learning / evolution.

The top-down, bottom-up design process

When planning out a full-stack business / network / services management solution, I tend to follow the top-down, bottom-up design process.

Let’s take the TMN pyramid as a starting point:
TMN Pyramid
Image courtesy of www.researchgate.net

Bottom-up: When designing the assurance stream (eg alarms, performance, etc), I start at the bottom (Network Elements), understanding what devices exist in the network and what events / notifications / monitors they will issue. From there, I seek to understand what tool/s will manage them (Element Management / Network Management), then keep climbing the stack to understand how to present key information that impacts services and the business.

Top-down: When designing the fulfilment stream (eg designs, provisioning, moves/adds/changes, configuration, etc), I generally start at the top* (Business Management), what services are being offered (Service Management) and figure out how those workflows propagate down into the network and associated tools (such as ticketing, workforce management, service order provisioning, etc).

This helps to build a conceptual architecture (ie a layered architecture with a set of building blocks, where the functional building blocks start out blank). From the conceptual architecture, we can then identify the tools / people / processes that will deliver on the functions within each blank box.

This approach ensures we have the big picture in mind before getting bogged down into the minutiae of integrations, data flows, configurations of tools, etc.

To get momentum quickly, I tend to start with the bottom-up side as data flows (eg SNMP traps) are more standardised and the tools tend to need less configuration to get some (but not all) raw alarms / traps into management tools, perhaps just sand-pit versions. For the next step, the top-down part, I tend to create just one simple service scenario, and perhaps even design the front-end to use The Mechanical Turk model described yesterday, and follow the flow manually down through the stack and into element management or network layers. Then grow both streams from there!

* Note that I’m assuming services are already flowing through the network under management and/or the team has already figured out the services they’re offering. In a completely green-fields situation, the capabilities of the network might determine the product set that can be offered to customers (bottom-up), but generally it will be top-down.

Short-sighted / long-sighted OSS

When I hear that the average tenure in tech is just two years, I wonder how anyone gets anything done. When I hear such job hopping justified by the fact that changing companies is the only way to get a raise, I just shake my head at the short-sightedness of such companies.”
David Heinemeier Hansson
here on Signal v Noise.

Have you noticed how your most valuable colleagues also tend to have had lengthy tenures in their workplace*? No matter how experienced you are at OSS, it takes a six month (plus) apprenticeship before you start adding real value in a new OSS role. The apprenticeship is usually twelve months or longer for those who are new to the industry. Unfortunately, it takes that long to develop the tribal knowledge of the tools, the processes, the people, the variants and the way things get done (including knowing how to circumvent rules).

To be honest, like DHH above, I shake my head when employers treat their OSS talent as expendable and don’t actively seek to quell high turnover in their ranks. An average tenure of two years equates to massive inefficiency. That’s my perspective on internal resources, the resources that run an OSS. The problem with internal roles though is that they can be so all-encompassing that resources become myopic, focused only on the internal challenges / possibilities.

The question then becomes how you can open up a wider field of view. The perfect example in our current environment is in the increasing use of CI/CD / DevOps / Agile methods to manage OSS delivery. I hear of a new tool almost every day (think Ansible, Kubernetes, Jenkins, Docker, Cucumber, etc, etc). It bewilders me how people keep up to know which are the best options, yet this is only one dimension of the change that is occurring in the OSS landscape. In these situations, high turnover actually helps with the cross-fertilisation of ideas / tools / practices. Similarly, external consultants can also assist with insights garnered from multiple environments.

There is a place for both on OSS projects, but I strongly subscribe to DHH’s views above. It’s the age-old question – how to attract and retain great talent, but do we give this question enough consideration??

* BTW. I’m certainly not implying that by corollary all long-tenured resources are the most valuable.

Ramping down network variants, ramping up digital variants

Voice and data are no longer the services that organisations, large and small, see as making a difference. The services that do make a difference are more dynamic and diverse – digital distribution, promotion and marketing, payments and billing, business intelligence, business continuity (including security) and more – the factors that make their organisations thrive.

Our OSS and BSS are currently complex due to all the network variants that they handle. But if customers don’t value the network (as a differentiator) then why are we putting so much effort / attention there? If customers want ubiquitous, secure data streams with digital services on top, then why aren’t we reducing network variants and correspondingly reducing complexity in our network-based OSS / BSS?

That will give us the head-room to enhance our tools and ramp up the digital services that organisations do value.

Customers like options. But if all the options are available on the digital services / bundles, customers won’t really care if they’re delivered over a network stream that has almost no variants. This also allows a transition to more of a consumption-based model rather than all the variants of speeds and feeds and protocols.

The big challenge here is convincing the networks teams to ramp down and allow digital teams to ramp up. That concept won’t go down too well at most service providers though will it?

The three big lies of the telecoms industry

What are the three big lies of the telecoms industry?
The first lie is that data monetisation is coming. Well we are still waiting.
The second is that we have billions of customers. Well are they really our customers or are they people who just tolerate us and are really customers of someone else?
The third lie is that we are utility so we have stable returns, and because we have spectrum allocations that is our safety net. EBITDA multiples for the telco industry were at around 6, while utilities were at multiples of 12 to 16, so it could not be said that telcos – which often had up to five competitors in markets – were utilities
.”
Alexey Reznikovich

Three valid points. OSS / BSS could be highly influential in whether these are actually lies or not.

Data:
If we think of data as carriage, that’s clearly not monetising for most telcos currently. Well, it does bring in revenues but at a diminishing rate per bit. If we think of data in terms of content (eg voice, video, text, etc), then there are some monetisation wins (eg Game of Thrones) but more content is coming on line so there is more supply, making the profitability tail longer. If we talk about data as insight (or supporting the generation of insights if selling analytics or API offerings) then this will never go out of fashion (although with more “insights” being generated, the bar will be raised on what is truly insightful)

Customers:
Alexey’s note here that our customers just tolerate us and are really customers of someone else possibly has some merit. It’s the reason why the OTT play has been so successful. I still have the sense that there is an implicit trust in our service providers, due to the long subscription/billing history, media / shareholder attention on them and regulation that governments place on them (even if not an implicit trust in their customer service). Not all OTT players have the same track record of regulatory governance. Some OTT providers are invisible, hidden somewhere out on the cloud. I feel that this could represent a strong opportunity in a world where crypto-currencies carry vastly more value than they do today.

Utilities:
This comes down to the business model of any given Telco and / or the regulatory frameworks they operate within. They could opt to go down the path of ubiquitous data (like ubiquitous voice of the distant past), or like most, they can go down the path of being a digital service provider. To be honest, there are probably quite a few incumbent providers that are probably more closely aligned to utility than DSP in the collective way of thinking within their workforce. That often transfers to their mindset in building OSS.

Channelling “Intel Inside” to improve the brand recognition of your OSS

During Intel’s marketing of “Intel Inside” they taught consumers to look for the Intel Inside logo as an assurance of quality. Consumers eventually came to see “Intel Inside” as a standard and began asking the question: “Why doesn’t your product use Intel processors?” This standard became so important that today it is one of the world’s largest co-operative marketing programs,where hundreds of computer companies license the use of the Intel Inside® logos.
The ingredient must be highly differentiated in order to add value to the overall brand. This means the ingredient should have a separate name and logo and overall purpose, because the added value comes from the extra identity. First and foremost, brands should not create confusion in the market. The main brand should be well established in the market before employing an ingredient branding strategy because the consumer needs first understand the core brand and then find additional value in the ingredient
.”
From an article about Ingredient Branding on Disenthrall.co.

When you think about the chips inside the multitude of electronic devices you own and use, how many brands could you identify? How many chipsets are differentiated enough to sway your decision on the device itself?

According to FastCompany, “If one thing distinguishes Intel’s innovative thinking, it is their 1990s strategy of branding a semiconductor chip as a valuable feature that consumers would look for when they purchased a computer. The campaign’s two decades of ubiquity make us forget this now, but at the time it was an incredibly novel approach to marketing. People bought computers because of the software, the specs, or a friend’s recommendation. Who cared about who made some tiny chip inside the box that you couldn’t even see?
But with the proliferation of PCs, and with consumers at a loss in trying to figure out what made one better than the other, Intel saw an opportunity, and so it took a major risk. Intel’s leadership was convinced this was the way to grow market share…

The “Intel Inside” initiative has arguably been the most successful ingredient marketing exercises in history. They’ve made the invisible visible.

To many users/customers, the achievements of our OSS are invisible, with other components getting the credit for outcomes that are heavily underpinned by our OSS. The challenge for us, just like Intel, is to differentiate and improve the value of our brand. We get the flak for when things go wrong (often through no fault of our own), but we rarely get the credit for the things that work – for the services activated, for the problems resolved, for the equipment ordered, for the new services enabled, for the insights gleaned, etc.

The question for us all is how to make those accomplishments, that differentiation, the brand value visible. [Note that I’m referring to the brands of internal OSS suites here, not just external vendor products]

If we think about making the invisible visible to key execs / sponsors / stakeholders, we need to think about how they tend to interact with OSS. I would surmise that in most cases they interact via reports. Assuming you’re confident that you’ve nailed the content of your reports, that they’re succinct and valuable to those stakeholders, is there any reason why we couldn’t put our equivalent of the “Intel Inside” badge on the reports?

But first, are you confident that the badge is a badge of honour? Will your brand instil in customers a sense of quality, assuredness and innovation?

Next step, man-machine partnerships

Getting literate in the language of the future posed the thought that data is the language of the future and therefore it is incumbent on all OSS practitioners to ensure their literacy.

It also posed that data literacy provides a stepping stone to a future where machine learning is more prevalent. This got me thinking. We currently think about man-machine interfaces where we design ways for humans and machines to get info into the system. But the next step, the future way of thinking will be man-machine partnerships, where we design ways to leverage machines to get more out of the system.

Data literacy will be essential to making this transition from MM interface to MM partnership. Machines (eg IoT and OSS) will get data into the system. Through partnerships with humans, machines will also be instrumental in the actions / insights coming out of the system.

Inverting the iceberg to get more funding for your OSS

In the last couple of days, we’ve discussed frameworks that could allow CSPs to design disruptive business models around factors that our OSS / BSS can control. Not exactly riveting stuff for the tech-heads amongst the reader-base, but relevant for the amount of investment that gets directed into the tech projects that we all work on.

Let me get a little more specific today. We only get to work on cool OSS projects if funding is allocated to them. As we all know, OSS are the linchpin around which a service provider is built, but most executive sponsors don’t grasp the full extent of this dependence. There are a few reasons for this:

  1. OSS are perceived as not generating any revenue directly
  2. OSS projects continually disappoint (on time, cost and/or functionality)
  3. The full picture of OSS functionality is hidden (like an iceberg) and is boring to most. The Service provider’s customers certainly have zero interest in the back-end systems / functionality in use
  4. Our business cases tend to be built around cost reduction, not business growth. Let’s be honest, OSS cost reductions go in the same excitement bucket as a reduction in paper clips, pens and printer paper
  5. The technologies used by OSS seem to be obsoleted even faster than the network technologies they manage
  6. They tend to deliver more negative messaging (eg network outages, fall-outs resulting in poor customer experiences, etc), whilst others get the credits for any positive messaging that OSS have facilitated
  7. Due to the costs of implementation and change, OSS are seen by many as giant sinkholes of cost centres
  8. The list goes on!!

Aaarghhh! Why do we bother working in OSS?

For all of us in the OSS industry, we understand the justifications behind these derogatory remarks above.

It all comes down to the messaging going to executive sponsors. Like Steve Jobs, I have just three things (to help build a compelling story for your executive sponsors):

  • Break “the sink-hole perspective” by generating revenues – via APIs, via platforms, via metrics that show OSS contribution to revenues or anything else that shows real value, not just cost-out, to executive sponsors as well as the customers they’re trying to service
  • Invert the iceberg – show just how much capability is hidden under the surface by mapping how dependant the organisation’s positive outcomes are on its OSS (OSS as the puppet-master). All the sexy stuff (eg 5G, IoT, network virtualisation, etc) can only be monetised if our OSS pull all the strings to make them happen
  • Simplify – the massive (and increasing) complexity in our business is boring to non-OSS people and an impediment to us in our ability to deliver exciting outcomes for everyone else. Just take Google – they have an incredibly complex tech-stack to run… but what does the customer interact with on their search page?

How to disrupt through your OSS – a base principles framework

We’ve all heard the stories about the communications services industry being ripe for disruption. In fact many over-the-top (OTT) players, like Skype and WhatsApp have already proven this fact for basic communications services, let alone the value-add applications that leverage CSP connectivity.

As much as the innovative technologies they’ve built, the OTT players have thrived via some really interesting business models to service gaps in the market. The oft-quoted examples here are platforms like Airbnb providing clients with access to accommodation without having the capital costs of building housing.

In thinking about the disruption of the CSP industry and how OSS can provide an innovative vehicle to meeting customer demands, the framework below builds upon the basic principles of supply and demand:

Supply and Demand opportunities in a service provider

The objective of the diagram is to identify areas where innovative OSS models could be applied, taking a different line of thinking than just fulfillment / assurance / inventory:

  • Supply – how can OSS influence supply factors such as:
    • Identifying latent supply (eg un-used capacity) and how incremental revenues could be generated from it, such as building dynamic offers
    • Unbundling supply by stripping multiple elements apart to supply smaller desirable components rather than all of the components of a cross-subsidised bundle. Or vice versa, taking smaller components and bundling them together to supply something new
    • Changing the costs structures of supply, which could include virtualisation, automation and many of the other big buzz-words swirling around our industry
  • Demand – how can OSS / BSS build upon demand factors such as:
  • Marketplace / Platforms – how can OSS / BSS better facilitate trade between a CSP‘s subscribers, who are both producer / suppliers and consumers. CSPs traditionally provide data connectivity, but the OTT players tend to provide higher perceived value of trade-connectivity including:
    • Bringing buyers and sellers together on a common platform
    • Providing end-to-end trade support from product development, sales / marketing, trading transactions, escrow / billing / clearing-house; and then
    • Analytics on gathered data to improve the whole cycle
  • Supply chain – how can OSS / BSS help customers to efficiently bring the many pieces of a supply chain together. This is sometimes overlooked but can be one of the hardest parts of a business model to replicate (and therefore build a sustainable competitive advantage from). For OSS / BSS, it includes factors such as:
    • As technologies get more complex, but more modular, partnerships and their corresponding interfaces become more important, playing into microservices strategies
    • Identifying delivery inefficiencies, which include customer impediment factors such as ordering, delivery, activations. Many CSPs have significant challenges in this area, so efficiency opportunities abound

These are just a few of the ideas coming out of the framework above. Can the questions it poses help you to frame your next OSS innovation roadmap (ie taking it beyond just the typical tech roadmap)?

The OSS / Singapore analogy

Singapore has made some really innovative decisions over the years. Recent ones include tokenisation of the Singapore Dollar on cyber-currencies, investing heavily in international startups based in Singapore and the streamlining of identity management (which will undoubtedly help to get around one of the biggest blockers to self-on-boarding new customers onto comms networks, particularly mobile).

Singapore perhaps lacks the natural commercial advantages (eg mining, manufacturing, agriculture, etc) that some other countries have. Despite that, it has made itself into a significant global player by being an economic and trading hub. It’s a focus on the abovementioned types of innovative thinking that has helped simplify the ability for people to do business in / through Singapore and has been instrumental in it developing a presence that outsizes its natural assets.

OSS falls into a similar category with regards to natural commercial advantages. Most people see OSS as cost centres, which implies having no ability to generate revenues directly (I don’t agree with this perspective, but that’s another story or two).

OSS can take a leaf out of Singapore’s book to out-size its presence – by acting as a highly efficient facilitator of business (and social) activities – but also by diligently identifying innovative ways to improve efficiency even further.

One way is for OSS to take more of a lead in the omni-channel experience as elegantly stated here:
The customer travels across all their channels — online, mobile, IVR, live and more – as they interact with you. You need to travel with them. If your channels aren’t fully integrated, they become just one more source of customer frustration. When you aren’t fully aware of how your customers have engaged with you across all your channels, costs of sales and service rise, and customer satisfaction shrinks.”

Another is through acting as a conduit to trade by doing more to bring its subscribers, all of which are buyers and sellers at some level, together with platform / marketplace / API / service thinking.

Another is through using data to provide marketing / sales / product-dev insights. Taking this further, to provide insightful information as mobile moments.

I’m sure you can think of more angles that take OSS beyond an inward-only facing operations toolset (ie cost centre). Do you have any great Singapore-thinking ideas for OSS to embrace?

OSS S-curves

I should say… that in the real world exponential curves don’t continue for ever. We get S-curves which closely mimic exponential curves in the beginning, but then tail off after a while often as new technologies hit physical limits which prevent further progress. What seems to happen in practice is that some new technology emerges on its own S-curve which allows overall progress to stay on an something approximating an exponential curve.
Socio tech

The chart above shows interlocking S-curves for change in society over the last 6,000 years. That’s as macro as it gets, but if you break down each of those S-curves they will in turn be comprised of their own interlocking S-curves. The industrial age, for example, was kicked off by the spinning jenny and other simple machines to automate elements of the textile industry, but was then kicked on by canals, steam power, trains, the internal combustion engine, and electricity. Each of these had it’s own S-curve, starting slowly, accelerating fast and then slowing down again. And to the people at the time the change would have seemed as rapid as change seems to us now. It’s only from our perspective looking back that change seems to have been slower in the past. Once again, that’s only because we make the mistake of thinking in absolute rather than relative terms.”
Nic Brisbourne
here.

I love that Nic has taken the time to visualise and articulate what many of us can perceive.

Bringing the exponential / S-curve concept into OSS, we’re at a stage in the development of OSS that seems faster than at any other time during my career. Technology change in adjacent industries are flowing into OSS, dragging it (perhaps kicking and screaming) into a very different future. Technologies such as continual integration, cloud-scaling, big-data / graph databases, network virtualisation, robotic process automation (RPA) and many others are making OSS look so different to what they did only five years ago. In fact, we probably need these technologies to keep apace with the other technologies. For example, the touchpoint explosion caused by network virtualisation and IoT mean we need improved database technologies to cope. In turn this introduces a complexity and change that is almost impossible for people to keep track of, driving the need for RPA… etc.

But then, there are also things that aren’t changing.

Many of our OSS have been built through millions of developer days of effort. That forces a monumental decision for the owners of that OSS – to keep up with advances, you need to rapidly overhaul / re-write / supersede / obsolete all that effort and replace it with something that keeps track of the exponential curve. The monolithic OSS of the past simply won’t be able to keep pace, so highly modular solutions, drawing on external tools like cloud, development automation and the like are going to be the only way to track the curve.

All of these technologies rely on programmable interfaces (APIs) to interlock. There is one major component of a telco’s network that doesn’t have an API yet – the physical (passive) network. We don’t have real-time data feeds or programmable control mechanisms to update it and manage these typically unreliable data sources. They are the foundation that everything else is built upon though so for me, this is the biggest digitalisation challenge / road-block that we face. Collectively, we don’t seem to be tackling it with as much rigour as it probably deserves.

Customers buy the basic and learn to love the features

Most customers buy the basic and learn to love the features, but the whole customer experience is based on trying to sell the features.”
Roger Gibson
.

This statement appears oh-so-true in the OSS sales pitches that I’ve observed.

In many cases the customer really only needs the basic, but when every vendor is selling the features, customers also tend to get caught up in the features. “The basic” effectively represents Pareto’s 20% of functionality that is required by 80% (or more) of customers. However, since every vendor has the basic they don’t feel differentiated enough to sell that 20%. They sell the remaining 80%, “the features,” that give the perspective of uniqueness compared with all the other vendors.

When I help customers through the vendor selection process, I take a different perspective though. I work with the customer to understand what is “the basic” of their business model and what the OSS will channel most impact through. It’s not the hundreds of sexy features, the ones which will get used on rare occasions, but “the basic” that get used hundreds (or thousands, or millions) of times every day. I then work with the customers to figure out a way of benchmarking which vendor solution delivers the greatest efficiency on their basic.

A couple of side benefits come from this strategy too:

  • The basic is usually the easiest part of an OSS to roll-out and get delivery momentum going (and momentum is such an important feature of delivering large, complex OSS projects)
  • Once delivery momentum is established and the customer’s operators are using the basic, there are still hundreds of features to play with and enhance over time. Hundreds of more little wins that enhance the customer experience, building the love

OSS survivorship bias

Take a look at the image below. If you were told that the image showed where planes had taken hits in WWII before returning to base and were asked to recommend locations on the plane where armour should be strengthened, where would you choose? Would you choose to strengthen behind the cockpit and on the wingtips?

Survivorship bias

“During World War II, the statistician Abraham Wald took survivorship bias into his calculations when considering how to minimize bomber losses to enemy fire. Researchers from the Center for Naval Analyses had conducted a study of the damage done to aircraft that had returned from missions, and had recommended that armor be added to the areas that showed the most damage. Wald noted that the study only considered the aircraft that had survived their missions—the bombers that had been shot down were not present for the damage assessment. The holes in the returning aircraft, then, represented areas where a bomber could take damage and still return home safely. Wald proposed that the Navy instead reinforce the areas where the returning aircraft were unscathed, since those were the areas that, if hit, would cause the plane to be lost.” Wikipedia.

Survivorship bias is prevalent in OSS too. We have complex processes (assurance, fulfilment and inventory) with many possible variants. Too many variants to test them all. Too many variants to catch them all. And if we don’t catch them, we can’t measure or process them – Survivorship bias.

Another example is in telco IVRs. Their designers are often asked to make traversing the decision tree so complicated that callers drop off the call before reaching an agent (that costs the telcos money to man the call centres). The sentiments of those dropping callers aren’t measured. Oftentimes, these callers are probably analogous to the downed planes of WWII (ie they’re the ones you actually want data on).

In the current age of omnichannel communications there are more cracks for customers to fall into than ever before because there is generally no single tool measuring journeys through all channels and watching all hand-offs between systems.

Do you think survivorship bias might be prevalent in your OSS?

OSS data as a business asset

To become a business asset, the role of data within an organization must move from being departmentally siloed to being centrally managed. Breaking down the siloes is not necessarily a technical challenge, but an organizational one. It requires a data strategy, the correct level of ownership and corporate governance. Data-as-a-business-asset means a single definition of the customer, ownership at an executive level and a well-managed change control process to ensure ongoing data quality and trust in the data across the organization.”
Steve Earl
here.

As Eric Hoving said at TM Forum Live!, “For 20 years we tried to make sense out of data and failed, but Google did it. Stuff is not an asset if you don’t get something out of it. If you aren’t going to do something with it then stop doing it.”

This is a strong statement by Eric Hoving but an important one when building our OSS strategies. Do we see ourselves collecting data for operational purposes or are we really going to try to make sense of it and turn it into a significant business asset? [wikipedia refers to an asset as “Anything tangible or intangible that can be owned or controlled to produce value and that is held by a company to produce positive economic value is an asset.”]

Should the data collection requirements of our OSS and BSS be defined by ops only or should they be defined by the Chief Data Office (ie centrally organised with a whole-of-business asset strategy in mind)?

As Steve Earl says, this “is not necessarily a technical challenge, but an organizational one.” Do we want to lead this change or follow?