Why does everyone know an operator’s business better than the operator?

The headline today blatantly steals from a post by William Webb. You can read his entire, brilliant post here. All quotes below are from the article.

William’s concept aligns quite closely with yesterday’s article regarding external insights that don’t quite marry up with the real situation faced by operators.

At the Great Telco Debate this week there was no shortage of advice for operators. Some counselled them to move up the value chain or branch out into related areas. Others to build “it” so that they would come… But there were no operators actually talking about doing these things.”
Funny because it’s true.

In most industries the working assumption is that a company knows its customers better than outsiders… But this assumption of knowing your customers seems not to hold in the mobile telecoms industry. It appears that the industry assumes that the mobile operators do not know their customers, but that they – the suppliers generally – understand them better.
Interesting. So this is a case of the suppliers purportedly knowing their customer (the operators) but also their customer’s customer (the end-users of comms services). This concept is almost definitely true of network suppliers. I don’t feel that this is common for OSS suppliers though. In fact it’s an area that could definitely be improved upon – an awareness of our customers’ customers.

At the Great Telco Debate, Nokia spoke about how the telcos needed to be bold, to build networks [eg 5G] for which there was no current business plan on the basis that revenue streams would materialise. Telling your customer to do something which cannot be justified economically seems a risky way to ensure a good long-term relationship.

I actually laughed out loud at the truth behind this one. So many related stories to tell. Another day perhaps!

The operators have been advised for decades that they are in a business that is increasingly becoming a utility and that they need to “move up the value chain” or find some other growth opportunity. This advice seems to be predicated on the view that nobody wants to be a utility, that it is essential for organisations to grow, and that moving around the value chain is easy to do. All merit further investigation. Utility businesses are stable, low-risk and normally profitable. Many companies do not grow but thrive nevertheless. But most problematic, mobile operators have been trying to “move up the value chain” for many years, with conspicuous lack of success.”

The CSP vs DSP business model. There is absolutely a position for both speeds in the telco marketplace. Which is better? Depends on your investment objectives and risk/reward profile.

Most operators, sensibly, appear to be ignoring all this unsolicited advice and getting on with running their networks reliably while delivering ever-more data capacity for ever-lower tariffs. Of course, they listen to ideas emanating from around the industry, but they know their business, their financial constraints, and their competitive and regulatory environment.”

As indicated in yesterday’s post, every client situation is different. We might look at the technical similarities between projects, but differences go beyond that. A supplier or consultant can’t easily replace local knowledge across financial and regulatory environments especially.

OSS answers that are simple but wrong vs complex but right

We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills…”
John F Kennedy
.

Let’s face it. The business of running a telco is complex. The business of implementing an OSS is complex. The excitement about working in our industry probably stems from the challenges we face, but the impact we can make if/when we overcome them.

The cartoon below tells a story about telco and OSS consulting (I’m ignoring the “Science vs everything else” box for the purpose of this post, focusing only on the simple vs complex sign-post).

Simple vs Complex

I was recently handed a brochure from a consulting firm that outlined a step-by-step transformation approach for comms service providers of different categories. It described quarter-by-quarter steps to transform across OSS, BSS, networks, etc. Simple!

The problem with their prescriptive model was that they’d developed a stereotype for each of the defined carrier categories. By stepping through the model and comparing against some of my real clients, it was clear that their transformation approaches weren’t close to aligning to any of those clients’ real situations.

Every single assignment and customer has its own unique characteristics, their own nuances across many layers. Nuances that in some cases are never even visible to an outsider / consultant. Trying to prepare generic, but prescriptive transformation models like this would seem to be a futile exercise.

I’m all for trying to bring repeatable methodologies into consulting assignments, but they can only act as general guidelines that need to be moulded to local situations. I’m all for bringing simplification approaches to consultancies too, as reflected by the number of posts that are categorised as “Simplification” here on PAOSS. We sometimes make things too complex, so we can simplify, but this definitely doesn’t imply that OSS or telco transformations are simple. There is no one-size-fits-all approach.

Back to the image above, there’s probably another missing arrow – Complex but wrong! And perhaps another answer with no specific path – Simple, but helpful in guiding us towards the summit / goal.

I can understand why telcos get annoyed with us consultants telling them how they should run their business, especially consultants who show no empathy for the challenges faced.

But more on that tomorrow!

The Theory of Evolution, OSS evolution

Evolution says that biological change is a property of populations — that every individual is a trial run of an experimental combination of traits, and that at the end of the trial, you are done and discarded, and the only thing that matters is what aggregate collection of traits end up in the next generation. The individual is not the focus, the population is. And that’s hard for many people to accept, because their entire perception is centered on self and the individual.”
FreeThoughtBlog.

Have we almost reached the point where the same can be said for OSS workflows? In the past (and the present?) we had pre-defined process flows. There may be an occasional if/else decision gate, but we could capture most variants on a process diagram. These pre-defined processes were / are akin to a production line.

Process diagrams are becoming harder to lock down as our decision trees get more complicated. Technologies proliferate, legacy product lines don’t get obsoleted, the number of customer contact channels increases. Not only that, but we’re now marketing to a segment of one, treating every one of our customers as unique, whilst trying not to break our OSS / BSS.

Do we have the technology yet that allows each transaction / workflow instance to just be treated as an experimental combination of attributes / tasks? More importantly, do we have the ability to identify any successful mutations that allow the population (ie the combination of all transactions) to get progressively better, faster, stronger.

It seems that to get to CX nirvana, being able to treat every customer completely uniquely, we need to first master an understanding of the population at scale. Conversely, to achieve the benefits of scale, we need to understand and learn from every customer interaction uniquely.

That’s evolution. The benchmark sets the pattern for future workflows until a variant / mutation identifies a better benchmark to establish the new pattern for future workflows, which continues.

The production line workflow model of the past won’t get us there. We need an evolution workflow model that is designed to accommodate infinite optionality and continually learn from it.

Does such a workflow tool exist yet? Actually, it’s more than a workflow tool. It’s a continually improving loop workflow.

Thump thump clap

I recently watched the film Bohemian Rhapsody about Freddy Mercury and the band Queen.

The title of this blog refers to the sounds made by the band at the start of their song, “We Will Rock You.”

There was a scene in the movie showing the origins of Thump Thump Clap, with the band adding it into the song purely to engage their fans more in their concert performances. It was to be the first of many engagement triggers that Queen used during their concerts. The premeditated thinking behind that simple act blew me away.

Audience engagement. It’s as important to a band as it is to an OSS transformation.

Thump Thump Clap. Simple. Brilliant. You could say it’s become more than just engaging. It’s become transcendent.

It got me thinking about what could the equivalent in OSS transformations be? How do we get the audience (stakeholders) participating to make the outcomes bigger and better than if only the project team were involved? Too momentous an experience for anyone to quibble about a technical off-note here or there.

There needs to be a performance involved. That implies a sandpit environment. There needs to be excitement around what the audience is seeing / hearing. There needs to be crowd involvement (or does there?).

There needs to be less dead-pan presentation than most of the OSS show-cases I’ve seen (and delivered if I’m being completely honest) 🙂

What are your Thump Thump Clap suggestions?

That’s not where to disrupt your OSS

The diagram below comes from an actual client’s functionality usage profile.
Long tail of OSS

The x-axis shows the functionality / use-cases. The y-axis shows the number of uses (it could equally represent usefulness or value).

Each big-impact demand (ie individual bars on the left-side of the graph) warrants separate investigation. The bars on the right side (ie the long tail in the red box) don’t. They might be worth investigating if we could treat some/all as a cohort though.

The left side of the graph represent the functionality / use-cases that have been around for decades. Every OSS has them. They’re so common and non-differentiated that they’re not remotely sexy. Customers / stakeholders aren’t going to be wowed by them. They’re just going to expect them. Our product developers have already delivered that functionality, have moved on and are now looking for new things to work on.

And where does the new stuff reside? Generally as new bars on the right side of the graph. That’s the law of diminishing returns territory right there! You’re unlikely to move the needle from out there.

Does this graph convince you to send your most skilled craftsmen back to do more tinkering / disrupting at the left side of the graph… as opposed to adding new features at the right side? Does it inspire you to dream up exciting cohort management techniques for the red box? Perhaps it even persuades you to cull some of the long-tail features that are chewing up lifecycle effort (eg code management, regression testing, complexity tax)?

If it does convince you, don’t forget to think about how you’re going to market it. How are you going to make the left side sexy / differentiated again? Are you going to have to prove just how much easier, cheaper, faster, more efficient, more profitable, etc it is? That brings us back to the OSS proof-of-worth discussion we had yesterday. It also brings us back to Sutton’s Law – go to where the money is.

The OSS proof-of-worth dilemma

Earlier this week we posted an article describing Sutton’s Law of OSS, which effectively tells us to go where the money is. The article suggested that in OSS we instead tend towards the exact opposite – the inverse-Sutton – we go to where the money isn’t. Instead of robbing banks like Willie Sutton, we break into a cemetery and aimlessly look for the cash register.

A good friend responded with the following, “Re: The money trail in OSS … I have yet to meet a senior exec. / decision maker in any telco who believes that any OSS component / solution / process … could provide benefit or return on any investment made. In telco, OSS = cost. I’ve tried very hard and worked with many other clever people also trying hard to find a way to pitch OSS which overcomes this preconception. BSS is often a little easier … in many cases it’s clear that “real money” flows through BSS and needs to be well cared for.”

He has a strong argument. The cost-out mentality is definitely ingrained in our industry.

We are saddled with the burden of proof. We need to prove, often to multiple layers of stakeholders, the true value of the (often intangible) benefits that our OSS deliver.

The same friend also posited, “The consequence is the necessity to establish beneficial working relationships with all key stakeholders – those who specify needs, those who design and implement solutions and those, especially, who hold or control the purse strings. [To an outsider] It’s never immediately obvious who these people are, nor what are their key drivers. Sometimes it’s ambition to climb the ladder, sometimes political need to “wedge” peers to build empires, sometimes it’s necessity to please external stakeholders – sometimes these stakeholders are vendors or government / international agencies. It’s complex and requires true consultancy – technical, business, political … at all levels – to determine needs and steer interactions.

Again, so true. It takes more than just technical arguments.

I’m big on feedback loops, but also surprised at how little they’re used in telco – at all levels.

  • We spend inordinate amounts of time building and justifying business cases, but relatively little measuring the actual benefits produced after we’ve finished our projects (or gaining the learnings to improve the next round of business cases)
  • We collect data in our databases, obliviously let it age, realise at some point in the future that we have a data quality issue and perform remedial actions (eg audits, fixes, etc) instead of designing closed-loop improvement cycles that ensure DQ isn’t constantly deteriorating
  • We’re great at spending huge effort in gathering / arguing / prioritising requirements, but don’t always run requirements traceability all the way into testing and operational rollout.
  • etc

Which leads us back to the burden of proof. Our OSS have all the data in the world, but how often do we use it to justify and persuade – to prove?

Our OSS products have so many modules and technical functionality (so much of it effectively duplicated from vendor to vendor). But I’ve yet to see any vendor product that allows their customer, the OSS operators, to automatically gather proof-of-worth stats (ie executive-ready reports). Nor have I seen any integrator build proof-of-worth consultancy into their offer, whereby they work closely with their customer to define and collect the metrics that matter. BTW. If this sounds hard, I’d be happy to discuss how I approach this task.

So let me leave you with three important questions today:

  1. Have you also experienced the overwhelming burden of the “OSS = cost” mentality
  2. If so, do you have any suggestions / experiences on how you’ve overcome it
  3. Does the proof-of-worth product functionality sound like it could be useful (noting that it doesn’t even have to be a product feature, but a custom report / portal using data that’s constantly coursing through our OSS databases)

OSS’ Rosetta Stone

When working on OSS projects, I find that linking or reference keys are so valuable at so many levels. Not just data management within the OSS database, but project management, design activities, task assignment / delivery, etc.

People might call things all sorts of different names, which leads to confusion.

Let me cite an example. When a large organisation has lots of projects underway and many people are maintaining project lists, but each with a slightly (or massively!!) different variant of the project name, there can be confusion, and possibly duplication. But introduce a project number and it becomes a lot easier to compare project lists (if everyone cites the project number in their documentation).

Trying to pattern match text / language can be really difficult. But if data sets have linking keys, we can easily use Excel’s vlookup function (or the human brain, or any other equivalent tool of choice) to make comparison a whole lot easier.

Linking keys could be activity codes in a WBS, a device name in a log file, a file number, a process number, part numbers in a designer’s pick-lists, device configuration code, etc.

Correlation and reconcile tasks are really important in OSS. An OSS does a lot of data set joins at application / database level. We can take a lead from code-level use of linking keys.

Just like the Rosetta stone proved to be the key to unlocking Egyptian hieroglyphs, introducing linking keys can be useful for translating different “languages” at many levels in OSS projects.

Sutton’s Law of OSS

Willie Sutton was an accomplished bank robber, particularly during the 1920s and 1930. Named after Willie, Sutton’s Law effectively states, “I go to where the money is,” which was supposedly Sutton’s response to a reporter’s question asking why he robbed banks instead of easier targets.

Interestingly for the OSS industry, we seem to follow the inverse of Sutton’s Law. We go to where the money isn’t. In other words, we mostly attempt to build business cases around the “cost-out” model, helping our customers achieve cost savings. These savings are in the form of automations that lead to reductions in head-count, cost of doing business, etc. Think about the common buzz-words – AI, machine learning, virtualisation, etc. Are they Sutton, or inverse-Sutton?

Truth be told, we do still go to where the money is because our customers (the network operators) are willing to spend money to save even more money. But you can see where I’m coming from can’t you?

Let me pose a question for you? Who is more likely to be comfortable spending money, someone who is confident in making money from the investment or someone who is going to save money from an investment?

I’d back Sutton’s Law and respond with the former. But we don’t tend to follow Sutton’s Law very often. It can often be challenging because so many of the benefits of our OSS and BSS are intangible. We’re seen as cost centres because we don’t do a good enough job of showing how important we are at operationalising everything that happens in a service provider’s network (and business).

At TM Forum’s DTA event a couple of weeks ago, I was pleased to see that some of the big telco API initiatives (eg Telkomsel, Telstra’s Network as a Service [NaaS] and China Mobile’s Data Security and Privacy Management Framework) are starting to make a real impact. The API model represents our strongest industry-wide push towards revenue-based business cases in years (that I can remember anyway).

Monty Hong of Telkomsel (Indonesia) made a presentation that provides a useful guide for future telco value-stream / revenue-models, effectively showing Sutton’s Law at play:
http://passionateaboutoss.com/how-oss-bss-facilitated-telkomsels-structural-revenue-changes.

The API model is an interesting one though. As well as revenue-in, it also potentially represents a cost out model (ie reduced cost of sales), a platform play (ie leveraging the network effect by allowing partners to build their own revenues on top), but on the downside also potentially triggers revenue cannibalisation.

Personally, I’m considering Sutton’s Law more in terms of our customers’ customers (ie end users of communication services, like the gamers in the Monty Hong link) rather than customers (ie the comms service providers that want to reduce costs).

I’d love to hear about your perception of Sutton’s Law in OSS. Where do you think the money is?

Cannibalisation intrigues me

We’ve all heard the Kodak story. They invented digital cameras but stuck them in a drawer because it was going to cannibalise their dominant position in the photographic film revenue stream… eventually leading to bankruptcy.

Swisscom invented an equivalent of WhatsApp years before WhatsApp came onto the market. It allowed users (only Swisscom users, not external / global customers BTW) to communicate via a single app – calls, chat, pictures, videos, etc. Swisscom parked it because it was going to cannibalise their voice and SMS revenue streams. That product, iO, is now discontinued. Meanwhile, WhatsApp achieved an exit of nearly $22B by selling to Facebook.

Some network operators are baulking at offering SD-WAN as it may cannibalise their MPLS service offerings. It will be interesting to see how this story plays out.

What also intrigues me is where cannibalisation is going to come for the OSS industry. What is the format of network operationalisation that’s simpler, more desirable to customers, probably cheaper, but completely destroys current revenue models? Do any of the vendors already have such capability but have parked it in a drawer because of revenue destruction?

History seems to have proven that it’s better to cannibalise your own revenues than allow your competitors to do so.

The Jeff Bezos prediction for OSS

If we start to focus on ourselves, instead of focusing on our customers, that will be the beginning of the end … We have to try and delay that day for as long as possible.”
Jeff Bezos
.

Jeff Bezos recently predicted that Amazon is likely to fail and/or go bankrupt at some point in time, as history has eventually proven for most high-flying companies. The quote above was part of that discussion.

I’ve worked with quite a few organisations that have been in the midst of some sort of organisational re-structure – upsizing, downsizing, right-scaling, transforming – whatever the words that might be in effect. Whilst it would be safe to say that all of those companies were espousing being focused on their customers, the organisational re-structures always seem to cause inward-facing behaviour. It’s human nature that change causes feelings of fear, job security, opportunities to expand empires, etc.

And in these types of inward-facing environments in particular, I’ve seen some really interesting decisions made around OSS projects. When making these decisions, customer experience has clearly been a long way down the list of priorities!! And in the current environment of significant structural change in the telco industry, these stimulants of internal-facing behaviour appear to be growing.

Whilst many people want to see OSS projects as technical delivery solutions and focus on the technology, the people and culture aspects of the project can often be even more challenging. They can also be completely underestimated.

What have your experiences been? Do you agree that customer-facing vision, change management and stakeholder management can be just as vital as technical brilliance on an OSS implementation team?

The culture required to support Telkomsel’s OSS/BSS transformation

Yesterday’s post described the ways in which Telkomsel has strategically changed their value-chain to attract revenues with greater premiums than the traditional model of a telco. They’ve used a new digital core and an API framework to help facilitate their business model transformation. As promised yesterday, we’ll take a slightly closer look at the culture of Telkomsel’s transformation today.

Monty Hong of Telkomsel presented the following slides during a presentation at TM Forum’s DTA (Digital Transformation Asia) last week.

The diagram below shows a graph showing the need for patience and ongoing commitment to major structural transformations like the one Telkomsel underwent.

Telkomsel's commitment to transformation

The curve above tends to represent the momentum and morale I’ve felt on most large OSS projects. Unfortunately, I’ve also been involved in projects where project sponsors haven’t stayed the journey beyond the dip (Q4/5 in the graph above) and haven’t experienced the benefits of the proposed project. This graph articulates the message well that change management and stakeholder / sponsor champions are an important, but often overlooked component of an OSS transformation.

The diagram below helps to articulate the benefits of an open API model being made accessible to external market-places. We’re entering an exciting time for OSS, with previously hidden, back-end telco functionality now being increasingly presented to the market (if even only as APIs into the black-box).

Telkomsel's internal/external API influences

Amongst many other benefits, it helps to bring the customer closer to implementers of these back-end systems.

How OSS/BSS facilitated Telkomsel’s structural revenue changes

The following two slides were presented by Monty Hong of Indonesia’s Telkomsel at Digital Transformation Asia 2018 last week. They provide a fascinating insight into the changing landscape of comms revenues that providers are grappling with globally and the associated systems decisions that Telkomsel has made.

The first shows the drastic declines in revenues from Telkomsel’s traditional telco products (orange line), contrasted with the rapid rise in revenues from content such as video and gaming.
Telkomsel Revenue Curve

The second shows where Telkomsel is repositioning itself into additional segments of the content value-chain (red chevrons at top of page show where Telkomsel is playing).
Telkomsel gaming ecosystem

Telkomsel has chosen to transform its digital core to specifically cater for this new revenue model with one API ecosystem. One of the focuses of this transformation is to support a multi-speed architectural model. Traditional back-end systems (eg OSS/BSS and system of records) are expected to rarely change, whilst customer-facing systems are expected to be highly agile to cater to changing customer needs.

More about the culture of this change tomorrow.

DTA is all wrapped up for another year

We’ve just finished the third and final day at TM Forum’s Digital Transformation Asia (https://dta.tmforum.org and #tmfdigitalasia ). Wow, talk about a lot happening!!

After spending the previous two days focusing on the lecture series, it would’ve been remiss of me to not catch up with the vendors and Catalyst presentations that had been on display for all three days. So that was my main focus for day 3. Unfortunately, I probably missed seeing some really interesting presentations, although I did catch the tail-end of the panel discussion, “Zero-touch – Identifying the First Steps Toward Fully Automated NFV/SDN,” which was ably hosted by George Glass (along with NFV/SDN experts Tomohiro Otani and Ir. Rizaludin Kaspin ). From the small amount I did see, it left me wishing that I could’ve experienced the entire discussion.

But on with the Catalysts, which are one of the most exciting assets in TM Forum’s arsenal IMHO. They connect carriers (as project champions) with implementers to deliver rapid prototypes on some of the carriers’ most pressing needs. They deliver some seriously impressive results in a short time, often with implementers only being able to devote part of their working hours (or after-hours) to the Catalyst.

As reported here, the winning Catalysts are:

1. Outstanding Catalyst for Business Impact
Telco Cloud Orchestration Plus, Using Open APIs on IoT
Champion: China Mobile
Participants: BOCO Inter-Telecom, Huawei, Hewlett Packard Enterprise, Nokia

2. Outstanding Catalyst for Innovation
5G Pâtisserie
Champions: Globe Telecom, KDDI Research, Singtel
Patricipants: Neural Technologies, Infosys, Ericsson

3. Outstanding New Catalyst
Artificial Intelligence for IT Operations (AIOps)
Champions: China Telecom, China Unicom, China Mobile
Participants: BOCO Inter-Telecom, Huawei, Si-Tech

These were all undoubtedly worthy winners, reward for the significant effort that has already gone into them. Three other Catalysts that I particularly liked are:

  • Transcend Boundaries – which demonstrates the use of Augmented Reality for the field workforce in particular, as championed by Globe. Collectively we haven’t even scratched the surface of what’s possible in this space, so it was exciting to see the concept presented by this Catalyst
  • NaaS in Action – which is building upon Telstra’s exciting Network as a Service (NaaS) initiative; and
  • Telco Big Data Security and Privacy Management Framework – the China Mobile led Catalyst that is impressive for the number of customers that are already signed up and generating revenues for CT.

BTW. The full list of live Catalysts can be found here.

For those who missed this year’s event, I can only suggest that you mark it in your diaries for next year. The TM Forum team is already starting to plan out next year’s event, one that will surely be even bigger and better than the one I’ve been privileged to have attended this week.

Is OSS the future of OSS?

Don’t worry. The title of this post isn’t a typo, but I’ll get to that shortly.

I’ve just had an interesting day 2 at TM Forum’s Digital Transformation Asia (https://dta.tmforum.org and #tmfdigitalasia ). The quality of presentations was again quite high with further thought-provoking ideas!!

My favorite session for the day was a panel discussion entitled, “Is open-source the future of OSS/BSS?” Hence the title of today’s blog. Is OSS (open source software) the future of OSS?

Trevor Cheung of OpenROADS Community spoke about their framework for delivering transformation. One point he emphasised was that we’re so wrapped up in Customer Experience (CX), we often forget about Employee Experience. Put simply, if we don’t win the hearts and minds of the implementers, there’s never going to be a transformed experience for the customers to have.

Jurgen Hase of unlimit gave a number of really interesting perspectives, but the best is paraphrased as follows, “The S in IoT stands for security… Wait, what? There is no S in IoT??”

Next was Angelia Ooi of TIME. Angelia provided 8 really useful tips on digital transformation via a presentation pack that is easily the most succinct and polished of all those I’ve seen at DTA so far.

Joddy Hernady of Telkom Indonesia provided some of the economics of becoming a digital telco, which provided an interesting perspective on the benefits of achieving digital transformation.

But finally, and it was the last presentation of the day that was most thought-provoking. Is open source the future of OSS/BSS?
Unfortunately I missed almost all of Catherine Michel’s opening gambit, but I believe the CTO of Sigma Systems made the key point that open source projects such as Mongo DB should really only be considered once they’d reached a level of maturity, ongoing development and support that approaches the large ISVs (Independent Software Vendors) such as Sigma Systems. She also highlighted the multi-layered challenges around licensing / rights.
Gnanapriya Chidambaranathan of Infosys contended that there is a wealth of open source projects that can be leveraged, curated and supported by integrators such as Infosys. She posed that open source adoption is a key to innovation.
Venura Mendis of Apigate provided the perspective of an open source software provider. He highlighted the challenge he faces in dealing with traditional carrier procurement teams, particularly in their ambition of reaching comparative TCO (Total Cost of Ownership) models.
Guy Lupo of Telstra provided a number of different and interesting perspectives, as he regularly does, this time on a carrier deciding between ISV, open source products and going down the path (rabbit hole?) of open sourcing their own developments. Guy’s perspectives were really pertinent as he’s currently utilising all of these options in his NaaS (Network as a Service) program at Telstra.

Finally, a few thoughts from me on the topic of OSS as the future of OSS.

1. One of the biggest challenges facing the future of OSS is fragmentation. The PAOSS vendor list has over 200 records (and I’ll be doing a major update again shortly that will add hundreds of additional vendors). This means the available skills pool is diluted with a lot of functionality duplication. It also means it becomes really challenging for customers to choose the right product for their needs (although we could claim that this is a good thing for PAOSS as we often assist customers with this challenge). The proliferation of open source projects that deliver OSS/BSS functionality further fragments and dilutes

2. We’re seeing a trend away from the behemoth software stacks of the past for a variety of reasons, but could be summed up as the laws of physics preventing us from making a large-scale OSS pivots. The more modular OSS appear to be more nimble. This plays into the hands of niche open source offerings. It appears contra to the massive-scale open source efforts of ONAP, which interestingly, the above mentioned panelists also held doubts over ONAP’s ability to succeed. I should note that they, like me, were also enthusiastic about facets of ONAP such as the collaboration, initiative taken, etc.

3. I still believe there is the potential to build an open-source OSS core that then allows collaboration and plug-ins to be developed, thus better leveraging the long tail of innovation from the available skills pool. Today’s panelists did throw something of a spanner in these works though by pointing out the layered licensing challenge with open source. It’s quite common for open source projects to leverage open source projects, which in turn leverage open source projects. Guy in particular highlighted just how big a problem it has been for Telstra’s procurement team to trace out all the open source threads.

OSS that capture value, not just create it

I’ve just had a really interesting first day at TM Forum’s Digital Transformation Asia (https://dta.tmforum.org and #tmfdigitalasia ). The quality of presentations was quite high. Some great thought-provoking ideas!!

Nik Willetts kicked off his keynote with the following quote, which I’m paraphrasing, “Telcos need to start capturing value, not just creating it as they have for the last decade.”

For me, this is THE key takeaway for this event, above any of the other interesting technical discussions from day 1 (and undoubtedly on the agenda for the next 2 days too).

The telecommunications industry has made a massive contribution to the digital lifestyle that we now enjoy. It has been instrumental in adding enormous value to our lives and our economy. But all the while, telecommunications providers globally have been experiencing diminishing profitability and share-of-wallet (as described in this earlier post). Clearly the industry has created enormous value, but hasn’t captured as much as it would’ve liked.

The question to ask is how will our thinking and our OSS/BSS stacks help to contribute to capturing more value for our customers. As described in the share of wallet post above, the premium end of the value chain has always been in the content (think in terms of phone conversations in days gone by, or the myriad of comms techniques today such as email, live chat, blogs, etc, etc). That’s what the customer pays for – the experience – not the networks or systems that facilitate it.

Nik’s comments made me think of Andrew Carnegie. Monopolies such as the telecommunications organisations of the past and Andrew Carnegie’s steel business owned vast swathes of the value chain (Carnegie Steel Company owned the mines which extracted the raw materials needed to make steel, controlled the transportation used to deliver the materials and the product, and ran the mills used for steel production). Buyers didn’t care for the mines or mills or transportation. Customers were paying for the end product as it is what helped them achieve their goals, whether that was the railway tracks needed by the railroads or the beams needed by construction companies.

The Internet has allowed enormous proliferation of the premium-end of the telecommunications value chain. It’s too late to stuff that genie back into the bottle. But to Nik’s further comment, we can help customers achieve their goals by becoming their “do-it-yourself” digital partners.

Our customers now look to platforms like Facebook, Instagram, Google, WordPress, Amazon, etc to build their marketing, order capture, product / content delivery, commercial transactions, etc. I really enjoyed Monty Hong‘s presentation that showed how Telkomsel’s OSS/BSS is helping to embed Telkomsel into customers’ digital lifestyles / value-chains. It’s a perfect example of the biggest OSS loser proof discussed in yesterday’s post.

The biggest OSS loser

You are so much more likely to put effort into something when you know whether it will pay off and what the gains will be. Not knowing how things will turn out undermines your motivation and makes you delay taking action.”
Dr Theo Tsaousides
in his book, Brainblocks.

Have you seen the reality TV show, “The Biggest Loser?” I rarely watch TV, but have noticed that it’s been a runaway hit in the ratings here in Australia (and overseas apparently). Why has it been so successful and what does it have to do with OSS?

Well, according to Dr Tsaousides, the success of the show comes down to the obvious body-shape / fitness transformations each of the contestants makes over each season of the show. But more specifically, “You need to watch only one season from beginning to end and you will start craving to be a contestant on the show, regardless of your current weight… Seeing the people’s amazing transformation over a few months is a much more convincing way to start working out and eating well than being told by your doctor that you need to lose weight and about the cardiovascular advantages of exercise. Forecasting a positive outcome, especially when dealing with something new and unfamiliar, leads to action.”

Can you see how this might be a useful technique when planning an OSS transformation?

Change management is always a challenging task on any large OSS transformation. It’s always best to have the entire OSS user population involved in the change, but that’s not always feasible for large groups of users.

It’s one of the reasons I’m always a big advocate for getting a baseline, sandpit version of off-the-shelf OSS stood up and available for the user population to start interacting with. This is particularly helpful if the sandpit is perceptibly better than the current one.

To paraphrase, “Forecasting a positive outcome (via the OSS sandpit), especially when dealing with something new and unfamiliar (the future state after OSS transformation), leads to action (more excitement, engagement and less pushback from the user population during the course of the transformation).”

Do you think the biggest loser technique could work on your next OSS transformation?

Is your data getting too heavy for your OSS to lift?

Data mass is beginning to exhibit gravitational properties – it’s getting heavy – and eventually it will be too big to move.”
Guy Lupo
in this article on TM Forum’s Inform that also includes contributions from George Glass and Dawn Bushaus.

Really interesting concept, and article, linked above.

The touchpoint explosion is helping to make our data sets ever bigger… and heavier.

In my earlier days in OSS, I was tasked with leading the migration of large sets of data into relational databases for use by OSS tools. I was lucky enough to spend years working on a full-scope OSS (ie it’s central database housed data for inventory management, alarm management, performance management, service order management, provisioning, etc, etc).

Having all those data sets in one database made it incredibly powerful as an insight generation tool. With a few SQL joins, you could correlate almost any data sets imaginable. But it was also a double-edged sword. Firstly, ensuring that all of the sets would have linking keys (and with high data quality / reliability) was a data migrator’s nightmare. Secondly, all those joins being done by the OSS made it computationally heavy. It wasn’t uncommon for a device list query to take the OSS 10 minutes to provide a response in the PROD environment.

There’s one concept that makes GIS tools more inherently capable of lifting heavier data sets than OSS – they generally load data in layers (that can be turned on and off in the visual pane) and unlike OSS, don’t attempt to stitch the different sets together. The correlation between data sets is achieved through geographical proximity scans, either algorithmically, or just by the human eye of the operator.

If we now consider real-time data (eg alarms/events, performance counters, etc), we can take a leaf out of Einstein’s book and correlate by space and time (ie by geographical and/or time-series proximity between otherwise unrelated data sets). Just wondering – How many OSS tools have you seen that use these proximity techniques? Very few in my experience.

BTW. I’m the first to acknowledge that a stitched data set (ie via linking keys such as device ID between data sets) is definitely going to be richer than uncorrelated data sets. Nonetheless, this might be a useful technique if your data is getting too heavy for your OSS to lift (eg simple queries are causing minutes of downtime / delay for operators).

Are telco services and SLAs no longer relevant?

I wonder if we’re reaching the point where “telecommunication services” is no longer a relevant term? By association, SLAs are also a bust. But what are they replaced by?

A telecommunication service used to effectively be the allocation of a carrier’s resources for use by a specific customer. Now? Well, less so

  1. Service consumption channel alternatives are increasing, from TV and radio; to PC, to mobile, to tablet, to YouTube, to Insta, to Facebook, to a million others.
    Consumption sources are even more prolific.
  2. Customer contact channel alternatives are also increasing, from contact centres; to IVR, to online, to mobile apps, to Twitter, etc.
  3. A service bundle often utilises third-party components, some of which are “off-net”
  4. Virtualisation is increasingly abstracting services from specific resources. They’re now loosely coupled with resource pools and rely on high availability / elasticity to ensure customer service continuity. Not only that, but those resource pools might extend beyond the carrier’s direct control and out to cloud provider infrastructure

The growing variant-tree is taking the concept beyond the reach of “customer services” and evolves to become “customer experiences.”

The elements that made up a customer service in the past tended to fall within the locus of control of a telco and its OSS. The modern customer experience extends far beyond the control of any one company or its OSS. An SLA – Service Level Agreement – only pertains to the sub-set of an experience that can be measured by the OSS. We can aspire to offer an ELA – Experience Level Agreement – because we don’t have the mechanisms by which to measure or manage the entire experience yet.

The metrics that matter most for telcos today tend to revolve around customer experience (eg NPS). But aside from customer surveys, ratings and derived / contrived metrics, we don’t have electronic customer experience measurements.

Customer services are dead; Long live the customer experiences king… if only we can invent a way to measure the whole scope of what makes up customer experiences.

Are you heading to Digital Transformation Asia (the new name for TM Forum Live Asia!)?

DTA – TM Forum’s Digital Transformation Asia event (https://dta.tmforum.org/) is almost upon us already. Held in Kuala Lumpur from 13-15 November, there are some really interesting looking talks on the agenda (https://dta.tmforum.org/agenda). I’m looking forward to being overwhelmed by the collective genius that is sure to be in attendance.

Will you be making an appearance?

Does Malcolm Gladwell’s 10,000 hours apply to OSS?

You’ve probably all heard of Malcolm Gladwell’s 10,000 hour rule from his book, Outliers? In it he suggests that roughly 10,000 hours of deliberate practice makes an individual world-class in their field. But is 10,000 hours enough in the field of OSS?

I look back to the year 2000, when I first started on OSS projects. Over the following 5 years or so, I averaged an 85 hour week (whilst being paid for a 40 hour week, but I just loved what I was doing!!). If we multiply 85 by 48 by 5, we end up with 20,400 hours. That’s double the Gladwell rule. And I was lucky to have been handed assignments across the whole gamut of OSS activities, not just monotonously repeating the same tasks over and over. But those first 5 years / 20,000+ hours were barely the tip of the iceberg in terms of OSS expertise.

Whilst 10,000 hours might work for repetitive activities such as golf, tennis, chess, music, etc it’s probably less impactful for such multi-faceted fields as OSS.

So, what does it take to make an OSS expert? Narrow focus on just one of the facets? Broad view across many facets? Experience just using, building, designing, optimising OSS, or all of those things? Study, practice or a combination of both?

If you’re an OSS expert, or you know any who stand head and shoulders above all others, how would you describe the path that got you / them there?
Or if I were to ask another way, how would you get an OSS newbie up to speed if you were asked to mentor them from your lofty position of expertise?