Category Archives: Simplification

Minimise the tentacles on the OctopOSS. Keep it simple

Is service personalisation the answer?

Posted on by
2

“The actions taken by the telecom industry have mostly been around cost cutting, both in terms of opex and capex, and that has not resulted in breaking the curve. Too few activities has been centered around revenue growth, such as focused activities in personalization, customer experience, segmentation, targeted offerings that become part of or drive ecosystems. These activities are essential if you want to break the curve; thus, it is time to gear up for growth… I am very surprised that very few, if any, service providers today collect and analyze data, create dynamic targeted offerings based on real-time insights, and do that per segment or individual.”
Lars Sandstrom, here.

I have two completely opposite and conflicting perspectives on the pervading wisdom of personalised services (including segmentation of one and targeted offerings) in the telecoms industry.

Telcos tend to be large organisations. If I invest in a large organisation it’s because the business model is simple, repeatable and has a moat (as Warren Buffett likes to say). Personalisation is contra to two of those three mantras – personalisation makes our OSS/BSS far more complicated and hence less repeatable (unless we build in lots of automations, which BTW, are inherently more complex).

I’m more interested in reliable and enduring profitability than just revenue growth (not that I’m discounting the search for revenue growth of course). The complexity of personalisation leads to significant increases in systems costs. As such, you’d want to be really sure that personalisation is going to give an even larger up-tick in revenues (ie ROI). Seems like a big gamble to me.

For my traditional telco services, I don’t want personalised, dynamic offers that I have to evaluate and make decisions on regularly. I want set and forget (mostly). It’s a bit like my electricity – I don’t want to constantly choose between green electricity, blue electricity, red electricity – I just want my appliances to work when I turn on the switch and not have bill shock at the end of the month / quarter. In telco, it’s not just green / blue / red. We seem to want to create the millions of shades of the rainbow, which is a nightmare for OSS/BSS implementers.

I can see the argument however for personalisation in what I’ll call the over-the-top services (let’s include content and apps as well). Telcos tend to be much better suited to building the platforms that support the whole long tail than selecting individual winners (except perhaps supply of popular content like sport broadcasts, etc).

So, if I’m looking for a cool, challenging project or to sell some products or services (you’ll notice that the quote above is on a supplier’s blog BTW), then I’ll definitely recommend personalisation. But if I want my telco customers to be reliably profitable…

Am I taking a short-term view on this? Is personalisation going to be expected by all end-users in future, leaving providers with no choice but to go down this path??

More places for the bad guys to hide?

Posted on by
Reply

Just wondering – do you think there would be any correlation between the number of fall-outs through an OSS/BSS stack and the level of security on a network?

In theory, they are quite separate. NetOps and SecOps are usually completely separate units, use different thinking models, don’t rely on common tools (apart from the network itself), etc.

The reason I ask the question is because fall-out rates amplify with complexity. And within the chaos of complexity, are there more places for the bad guys to hide?

Thoughts?

Networks lead. OSS are an afterthought. Time for a change?

Posted on by
Reply

In a recent post, we described how changing conditions in networks (eg topologies, technologies, etc) cause us to reconsider our OSS.

Networks always lead and OSS (or any form of network management including EMS/NMS) is always an afterthought. Often a distant afterthought.

But what if we spun this around? What if OSS initiated change in our networks / services? After all, OSS is the platform that operationalises the network. So instead of attempting to cope with a huge variety of network options (which introduces a massive number of variants and in turn, massive complexity, which we’re always struggling with in our OSS), what if we were to define the ways that networks are operationalised?

Let’s assume we want to lead. What has to happen first?

Network vendors tend to lead currently because they’re offering innovation in their networks, but more importantly on the associated services supported over the network. They’re prepared to take the innovation risk knowing that operators are looking to invest in solutions they can offer to their customers (as products / services) for a profit. The modus operandi is for operators to look to network vendors, not OSS vendors / integrators, to help to generate new revenues. It would take a significant perception shift for operators to break this nexus and seek out OSS vendors before network vendors. For a start, OSS vendors have to create a revenue generation story rather than the current tendency towards a cost-out business case.

ONAP provides an interesting new line of thinking though. As you know, it’s an open-source project that represents multiple large network operators banding together to build an innovative new approach to OSS (even if it is being driven by network change – the network virtualisation paradigm shift in particular). With a white-label, software-defined network as a target, we have a small opening. But to turn this into an opportunity, our OSS need to provide innovation in the services being pushed onto the SDN. That innovation has to be in the form of services/products that are readily monetisable by the operators.

Who’s up for this challenge?

As an aside:
If we did take the lead, would our OSS look vastly different to what’s available today? Would they unequivocally need to use the abstract model to cope with the multitude of scenarios?

Designing OSS to cope with greater transience (part 2)

Posted on by
Reply

This is the second episode discussing the significant change to OSS thinking caused by modern network models. Yesterday’s post discussed how there has been a paradigm shift from static networks (think PDH) to dynamic / transient networks (think SDN/NFV) and that OSS are faced with a similar paradigm shift in how they manage modern network models.

We can either come up with adaptive / algorithmic mechanisms to deal with that transience, or mimic the “nailed-up” concepts of the past.

Let’s take Carrier Ethernet as a basis for explanation, with its E-LAN service model [We could similarly analyse E-Line and E-Tree service models, but maybe another day].

An E-Line is a point-to-point service between an A-end UNI (User-Network Interface) and a Z-end UNI, connected by an EVC (Ethernet Virtual Connection). The EVC is a conceptual pipe that is carried across a service provider’s network – a pipe that can actually span multiple network assets / links.

In our OSS, we can apply either:

  1. Abstract Model – Just mimic the EVC as a point-to-point connection between the two UNIs
  2. Specific Model – Attempt to tie network assets / links associated with the conceptual pipe to the EVC construct

The abstract OSS can be set up just once and delegate the responsibility of real-time switching / transience within the EVC to network controllers / EMS. This is the simpler model, but doesn’t add as much value to assurance use-cases in particular.

The specific OSS must either have the algorithms / policies to dynamically manage the EVC or to dynamically associate assets to the EVC. This is obviously much more sophisticated, but provides operators with a more real-time view of network utilisation and health.

Which OSS tool model do you prefer – Abstract or Specific?

Posted on by
Reply

There’s something I’ve noticed about OSS products – they are either designed to be abstract / flexible or they are designed to cater for specific technologies / topologies.

When designed from the abstract perspective, the tools are built around generic core data models. For example, whether a virtual / logical device, a physical device, a customer premises device, a core network device, an access network device, a trasmission device, a security device, etc, they would all be lumped into a single object called a device (but with flexibility to cater for the many differences).

When designed from the specific perspective, the tools are built with exact network and/or service models in mind. That could be 5G, DWDM, physical plant, etc and when any new technology / topology comes along, a new plug-in has to be built to augment the tools.

The big advantage of the abstract approach is obvious (if they truly do have a flexible core design) – you don’t have to do any product upgrades to support a new technology / topology. You just configure the existing system to mimic the new technology / topology.

The first OSS product I worked with had a brilliant core design and was able to cope with any technology / topology that we were faced with. It often just required some lateral thinking to make the new stuff fit into the abstract data objects.

What I also noticed was that operators always wanted to customise the solution so that it became more specific. They were effectively trying to steer the product from an open / abstract / flexible tool-set to the other end of the scale. They generally paid significant amounts to achieve specificity – to mould the product to exactly what their needs were at that precise moment in time.

However, even as an OSS newbie, I found that to be really short-term thinking. A network (and the services it carries) is constantly evolving. Equipment goes end-of-life / end-of-support every few years. Useful life models are usually approx 5-7 years and capital refresh projects tend to be ongoing. Then, of course, vendors are constantly coming up with new products, features, topologies, practices, etc.

Given this constant change, I’d much rather have a set of tools that are abstract and flexible rather than specific but less malleable. More importantly, I’ll always try to ensure that any customisations should still retain the integrity of the abstract and flexible core rather than steering the product towards specificity.

How about you? What are your thoughts?

An embarrassing experience on an overseas OSS project

Posted on by
Reply

The video below has been doing the rounds on LinkedIn lately. What is your key takeaway from the video?

Most would say the perfection, but for me, the perfection was a result of the hand-offs, which were almost immediate and precise, putting team-mates into better position. The final shot didn’t need the brilliance of a Messi or Ronaldo to put the ball into the net.

Whilst based overseas on an OSS project I played in an expat Australian Rules Football team. Aussie Rules, by the way, is completely different from the game of soccer played in the video above (check out this link to spot the differences and to see why I think it’s the greatest game in the world). Whilst training one afternoon, we were on an adjacent pitch to one of that country’s regional soccer teams.

Watching from the sidelines, we could see that each of the regional team’s players had a dazzling array of foot skills. When we challenged them to a game of soccer we were wondering if this was going to be embarrassing. None of us had anywhere near their talent, stamina, knowledge of the game of soccer, etc.

As it turns out, it WAS a bit embarrassing. We won 5-1, having led 5-0 up until the final few minutes. We didn’t deserve to beat such a talented team, so you’re probably wondering how (and how it relates to OSS).

Well, whenever one of their players got the ball, they’d show off their sublime skills by running rings around our players, but ultimately going around in circles and becoming corralled. They’d rarely dish off a pass when a teammate was in space like the team in the video above.

By contrast, our team was too clumsy to control the ball and had to pass it off quickly to teammates in space. It helped us bring our teammates into the game and keep moving forward. Clumsy passing and equally clumsy goals.

The analogy for OSS is that our solutions can be so complex that we get caught up in the details and go around in circles (sometimes through trying to demonstrate our intellectual skills) rather than just finding ways to reduce complexity and keep momentum heading towards the goals. In some cases, the best way-forward solution might not even use the OSS to solve certain problems.

Oh, and by the way, the regional team did score that final goal… by finally realising that they should use more passing to bring their team-mates into the game. It probably looked a little like the goal in the video above.

Re-writing the Sales vs Networks cultural divide

Posted on by
Reply

“Brand, marketing, pricing and sales were seen as sexy. Networks and IT were the geeks no one seemed to speak to or care about. … This isolation and excommunication of our technical team had created an environment of disillusion. If you wanted something done the answer was mostly ‘No – we have no budget and no time for that’. Our marketing team knew more about loyalty points … than about our own key product, the telecommunications network.”
Olaf Swantee, from his book, “4G Mobile Revolution”

Great note here (picked up by James Crawshaw at Heavy Reading). It talks about the great divide that always seems to exist between Sales / Marketing and Network / Ops business units.

I’m really excited about the potential for next generation OSS / orchestration / NaaS (Network as a Service) architectures to narrow this divide though.

In this case:

  1. The Network is offered as a microservice (let’s abstractly call them Resource Facing Services [RFS]);
  2. Sales / Marketing construct customer offerings (let’s call them Customer Facing Services [CFS]) from those RFS; and
  3. There’s a catalog / orchestration layer that marries the CFS with the cohesive set of RFS

The third layer becomes a meet-in-the-middle solution where Sales / Marketing comes together with Network / Ops – and where they can discuss what customers want and what the network can provide.

The RFS are suitably abstracted that Sales / Marketing doesn’t need to understand the network and complexity that sits behind the veil. Perhaps it’s time for Networks / Ops to shine, where the RFS can be almost as sexy as CFS (am I falling too far into the networks / geeky side of the divide?  🙂  )

The CFS are infinitely composable from RFS (within the constraints of the RFS that are available), allowing Sales / Marketing teams to build whatever they want and the Network / Ops teams don’t have to be constantly reacting to new customer offerings.

I wonder if this revolution will give Olaf cause to re-write this section of his book in a few years, or whether we’ll still have the same cultural divide despite the exciting new tools.

Does the death of ATM bear comparison with telco-grade open-source OSS?

Posted on by
Reply

Hands up if you’re old enough to remember ATM here? And I don’t mean the type of ATM that sits on the side of a building dispensing cash – no I mean Asynchronous Transfer Mode.

For those who aren’t familiar with ATM, a little background. ATM was THE telco-grade packet-switching technology of choice for most carriers globally around the turn of the century. Who knows, there might still be some ATM switches/routers out there in the wild today.

ATM was a powerful beast, with enormous configurability and custom-designed with immense scale in mind. It was created by telco-grade standards bodies with the intent of carrying voice, video, data, whatever, over big data pipes.

With such pedigree, you may be wondering then, how it was beaten out by a technology that was designed to cheaply connect small groups of computers clustered within 100 metres of each other (and a theoretical maximum bandwidth of 10Mbps).

Why does the technology that scaled up to become carrier Ethernet exist in modern telco networks, whereas ATM is largely obsoleted? Others may beg to differ, and there are probably a multitude of factors, but I feel it boils down to operational simplicity. Customers wanted operational simplicity and operators didn’t want to have a degree in ATM just to be able to drive it. By being designed to be all things to all people (carriers), did that make ATM compromised from the start?

Now I’ll state up front that I love the initiative and collaboration being shown by many of the telcos in committing to open-source programs like ONAP. It’s a really exciting time for the industry. It’s a sign that the telcos are wresting control back from the vendors in terms of driving where the collective innovation goes.

Buuuuuuut…..

Just like with ATM, are the big open source programs just too big and too complicated? Do you need a 100% focus on ONAP to be able to make it work, or even to follow all the moving parts? Are these initiatives trying to be all things to all carriers instead of changing needs to more simplified use cases?

“Sometimes the ‘right’ way to do it just doesn’t exist yet, but often it does exist but is very expensive. So, the question is whether the ‘cheap, bad’ solution gets better faster than the ‘expensive, good’ solution gets cheap. In the broader tech industry (as described in the ‘disruption’ concept), generally the cheap product gets good. The way that the PC grew and killed specialized professional hardware vendors like Sun and SGi is a good example. However, in mobile it has tended to be the other way around – the expensive good product gets cheaper faster than the cheap bad product can get good.”
Ben Evans here.

Is there an Ethernet equivalent in the OSS world, something that’s “cheap, bad” but getting better (and getting customer buy-in) rapidly?

Blown away by one innovation. Now to extend on it

Posted on by
Reply

Our most recent two posts, from yesterday and Friday, have talked about one stunningly simple idea that helps to overcome one of OSS‘ biggest challenges – data quality. Those posts have stimulated quite a bit of dialogue and it seems there is some consensus about the cleverness of the idea.

I don’t know if the idea will change the OSS landscape (hopefully), or just continue to be a strong selling point for CROSS Network Intelligence, but it has prompted me to think a little longer about innovating around OSS‘ biggest challenges.

Our standard approach of just adding more coats of process around our problems, or building up layers of incremental improvements isn’t going to solve them any time soon (as indicated in our OSS Call for Innovation). So how?

Firstly, we have to be able to articulate the problems! If we know what they are, perhaps we can then take inspiration from the CROSS innovation to spur us into new ways of thinking?

Our biggest problem is complexity. That has infiltrated almost every aspect of our OSS. There are so many posts about identifying and resolving complexity here on PAOSS that we might skip over that one in this post.

I decided to go back to a very old post that used the Toyota 5-whys approach to identify the real cause of the problems we face in OSS [I probably should update that analysis because I have a whole bunch of additional ideas now, as I’m sure you do too… suggested improvements welcomed BTW].

What do you notice about the root-causes in that 5-whys analysis? Most of the biggest causes aren’t related to system design at all (although there are plenty of problems to fix in that space too!). CROSS has tackled the data quality root-cause, but almost all of the others are human-centric factors – change controls, availability of skilled resources, requirement / objective mis-matches, stakeholder management, etc. Yet, we always seem to see OSS as a technical problem.

How do you fix those people challenges? Ken Segal puts it this way, “When process is king, ideas will never be. It takes only common sense to recognize that the more layers you add to a process, the more watered down the final work will become.” Easier said than done, but a worthy objective!

Blown away by one innovation – a follow-up concept

Posted on by
Reply

Last Friday’s blog discussed how I’ve just been blown away by the most elegant OSS innovation I’ve seen in decades.

You can read more detail via the link, but the three major factors in this simple, elegant solution to data quality problems (probably OSS‘ biggest kryptonite) are:

  1. Being able to make connections that break standard object hierarchy rules; but
  2. Having the ability to mark that standard rules haven’t been followed; and
  3. Being able to uses the markers to prioritise the fixing of data at a more convenient time

It’s effectively point 2 that has me most excited. So novel, yet so obvious in hindsight. When doing data migrations in the past, I’ve used confidence flags to indicate what I can rely on and what needs further audit / remediation / cleansing. But the recent demo I saw of the CROSS product is the first time I’ve seen it built into the user interface of an OSS.

This one factor, if it spreads, has the ability to change OSS data quality in the same way that Likes (or equivalent) have changed social media by acting as markers of confidence / quality.

Think about this for a moment – what if everyone who interacts with an OSS GUI had the ability to rank their confidence in any element of data they’re touching, with a mechanism as simple as clicking a like/dislike button (or similar)?

Bad example here but let’s say field techs are given a design pack, and upon arriving at site, find that the design doesn’t match in-situ conditions (eg the fibre pairs they’re expecting to splice a customer lead-in cable to are already carrying live traffic, which they diagnose is due to data problems in an upstream distribution joint). Rather than jeopardising the customer activation window by having to spend hours/days fixing all the trickle-down effects of the distribution joint data, they just mark confidence levels in the vicinity and get the customer connected.

The aggregate of that confidence information is then used to show data quality heat maps and help remediation teams prioritise the areas that they need to work on next. It helps to identify data and process improvements using big circle and/or little circle remediation techniques.

Possibly the most important implication of the in-built ranking system is that everyone in the end-to-end flow, from order takers to designers through to coal-face operators, can better predict whether they need to cater for potential data problems.

Your thoughts?? In what scenarios do you think it could work best, or alternatively, not work?

I’ve just been blown away by the most elegant OSS innovation I’ve seen in decades

Posted on by
1

Looking back, I now consider myself extremely lucky to have worked with an amazing product on the first OSS project I worked on (all the way back in 2000). And I say amazing because the underlying data models and core product architecture are still better than any other I’ve worked with in the two decades since. The core is the most elegant, simple and powerful I’ve seen to date. Most importantly, the models were designed to cope with any technology, product or service variant that could be modelled as a hierarchy, whether physical or virtual / logical. I never found a technology that couldn’t be modelled into the core product and it required no special overlays to implement a new network model. Sadly, the company no longer exists and the product is languishing on the books of the company that bought out the assets but isn’t leveraging them.

Having been so spoilt on the first assignment, I’ve been slightly underwhelmed by the level of elegant innovation I’ve observed in OSS since. That’s possibly part of the reason for the OSS Call for Innovation published late last year. There have been many exciting innovations introduced since, but many modern tools are still more complex and complicated than they should be, for implementers and operators alike.

But during a product demo last week, I was blown away by an innovation that was so simple in concept, yet so powerful that it is probably the single most impressive innovation I’ve seen since that first OSS. Like any new elegant solution, it left me wondering why it hasn’t been thought of previously. You’re probably wondering what it is. Well first let me start by explaining the problem that it seeks to overcome.

Many inventory-based OSS rely on highly structured and hierarchical data. This is a double-edged sword. Significant inter-relationship of data increases the insight generation opportunities, but the downside is that it can be immensely challenging to get the data right (and to maintain a high-quality data state). Limited data inter-relationships make the project easier to implement, but tend to allow less rich data analyses. In particular, connectivity data (eg circuits, cables, bearers, VPNs, etc) can be a massive challenge because it requires the linking of separate silos of data, often with no linking key. In fact, the data quality problem was probably one of the most significant root-causes of the demise of my first OSS client.

Now getting back to the present. The product feature that blew me away was the first I’ve seen that allows significant inter-relationship of data (yet in a simple data model), but still copes with poor data quality. Let’s say your OSS has a hierarchical data model that comprises Location, Rack, Equipment, Card, Port (or similar) and you have to make a connection from one device’s port to another’s. In most cases, you have to build up the whole pyramid of data perfectly for each device before you can create a customer connection between them. Let’s also say that for one device you have a full pyramid of perfect data, but for the other end, you only know the location.

The simple feature is to connect a port to a location now, or any other point to point on the hierarchy (and clean up the far-end data later on if you wish). It also allows the intermediate hops on the route to be connected at any point in the hierarchy. That’s too simple right, yet most inventory tools don’t allow connections to be made between different levels of their hierarchies. For implementers, data migration / creation / cleansing gets a whole lot simpler with this approach. But what’s even more impressive is that the solution then assigns a data quality ranking to the data that’s just been created. The quality ranking is subsequently considered by tools such as circuit design / routing, impact analysis, etc. However, you’ll have noted that the data quality issue still hasn’t been fixed. That’s correct, so this product then provides the tools that show where quality rankings are lower, thus allowing remediation activities to be prioritised.

If you have an inventory data quality challenge and / or are wondering the name of this product, it’s CROSS, from the team at CROSS Network Intelligence (www.cross-ni.com).

Trickle-down impact planning

Posted on by
Reply

We introduced the concept of The Trickle-down Effect last year, an effect that sees the most minor changes trickling down through an OSS stack, with much bigger consequences than expected.

“The trickle-down effect can be insidious, turning a nice open COTS solution into a beast that needs constant attention to cope with the most minor of operational changes. The more customisations made, the more gnarly the beast tends to be.”

Here’s an example I saw recently. An internal business unit wanted to introduce a new card type into the chassis set they managed. Speaking with the physical inventory team, it seemed the change was quite small and a budget was developed for the works… but the budget (dollars / time / risk) was about to blow out in a big way.

The new card wasn’t being picked up in their fault-management or performance management engines. It wasn’t picked up in key reports, nor was it being identified in the configuration management database or logical inventory. Every one of these systems needed interface changes. Not massive change obviously, but collectively the budget blew out by 10x and expedite changes pushed out the work previously planned by each of the interface development and testing teams.

These trickle-down impacts were known…. by some people…. but weren’t communicated to the business unit responsible for managing the new card type. There’s a possibility that they may not have even added the new card type if they realised the full OSS cost consequences.

Are these trickle-down impacts known and readily communicated within your OSS change processes?

The answer is soooo obvious…. or is it?

Posted on by
Reply

There’s a crowded room of OSS experts, a room filled with serious intellectual horsepower. You might be a virtu-OSS-o, but you surely know that there’s still so much to be learnt from those around you. You have the chance to unlock the experiences and insights of your esteemed colleagues. But how? The answer might seem to be obvious. You do so by asking questions. Lots of questions.

But that obvious answer might have just one little unexpected twist.

Do you ask:

  1. Ego questions – questions that demonstrate how clever you are (and thus prove to the other experts that you too are an expert); OR
  2. Embarrassing questions – questions that could potentially embarrass you (and demonstrate major deficiencies in your knowledge, perhaps suggesting that you’re not as much of as expert as everyone else)

I’ve been in those rooms and heard the questions, as you have too no doubt. What do you think the ratio of ego to embarrassing would typically be? 10 to 1? 20 to 1?

The problem with the ego questions is that they can be so specific to the context of a few that they end up steering the conversations to the depths of technology hell (of course they can also end up inspiring / enlightening too, so I’m generalising here).

But have you observed that the very best in our industry happen to ask a lot of embarrassing  questions?

A quote by Ramit Sethi splices in brilliantly here, “The very best ask lots of questions. 3 questions I almost never hear: (1) “Just a second. If you don’t mind me asking, how did you get to that?” (2) “I’m not sure I understand the conclusion — can you walk me through that?” (3) “How did you see that answer?” Ask these questions and stop worrying about being embarrassed. How else are you going to learn?”

Just for laughs, next time you’re at one of these events (and I notice that TM Forum Live is coming up in May), try to guess what the ego to embarrassing ratio might be there and which set of questions are spawning the more interesting / insightful / helpful conversations.

One sentence to make most OSS experts cringe

Posted on by
2

Let me warn you. The following sentence is going to make many OSS experts cringe, maybe even feel slightly disgusted, but take the time to read the remainder of the post and ponder how it fits within your specific OSS context/s.

“Our OSS need to help people spend money!”

Notice the word is “help” and not “coerce?” This is not a post about turning our OSS into sales tools, well, not directly anyway.

May I ask you a question – Do you ever spend time thinking about how your OSS is helping your customer’s customer (which I’ll refer to as the end-customer) to spend their money? And I mean making it easier for them to buy the stuff they want to buy in return for some form of value / utility, not trick or coerce them into buying stuff they don’t want.

Let me step you through the layers of thinking here.

The first layer for most OSS experts is their direct customer, which is usually the service provider or enterprise that buys and operates the OSS. We might think they are buying an OSS, but we’re wrong. An organisation buys an OSS, not because it wants an Operational Support System, but because it wants Operational Support.

The second layer is a distinct mindset change for most OSS experts. Following on from the first layer, OSS has the potential to be far more than just operational support. Operational support conjures up the image of being a cost-centre, or something that is a necessary evil of doing business (ie in support of other revenue-raising activities). To remain relevant and justify OSS project budgets, we have to flip the cost-centre mentality and demonstrate a clear connection with revenue chains. The more obvious the connection, the better. Are you wondering how?

That’s where the third layer comes in. We have to think hard about the end-customer and empathise with their experiences. These experiences might be a consumer to a service provider’s (your direct customer) product offerings. It might even be a buying cycle that the service provider’s products facilitate. Either way, we need to simplify their ability to buy.

So let’s work back up through those layers again:
Layer 3 – If end-customers find it easier to buy stuff, then your customer wins more revenue (and brand value)
Layer 2 – If your customer sees that its OSS / BSS has unquestionably influenced revenue increase, then more is invested on OSS projects
Layer 1 – If your customer recognises that your OSS / BSS has undeniably influenced the increased OSS project budget, you too get entrusted with a greater budget to attempt to repeat the increased end-customer buy cycle… but only if you continue to come up with ideas that make it easier for people (end-customers) to spend their money.

At what layer does your thinking stop?

The pruning saw technique for OSS fall-out management

Posted on by
Reply

Many different user journeys flow through our OSS every day. These include external / customer journeys, internal / operator journeys and possibly even machines-to-machine or system journeys. Unfortunately, not all of these journeys are correctly completed through to resolution.

The incomplete or unsatisfactory journeys could include inter-system fall-outs, customer complaints, service quality issues, and many more.

If we categorise and graph these unsuccessful journeys, we will often find a graph like the one below. This example shows that a small number of journey categories account for a large proportion of the problematic journeys. However, it also shows a long tail of other categories that are individually insignificant, but collectively significant.

Long tail of OSS demands

The place where everybody starts (including me) is to focus on the big wins on lhe left side of the graph. lt makes sense that this is where your efforts will have the biggest impacts. Unfortunately, since that’s where everybody focusses effort, chances are the significant gains have already been achieved and optimisation is already quite high (but numbers are still high due constraints within the existing solution stack).

The long tail intrigues me. It’s harder to build a business case for because there are many causes and little return for solving them. Alternatively, if we can slowly and systematically remove many of these rarer events, we’re removing the noise and narrowing our focus on the signal, thus simplifying our overall solution.

Since they’re statistically rarer, we can often afford to be more ruthless in the ways that we prevent them from occurring. But how do we identify and prevent them?

Each of the bars on the chart above represent leaves on a decision tree (faulty leaves in this case). If we work our way back up the branches, we can ruthlessly prune. Examples could be:

  • The removal of obscure service options that lead to faults
  • Reduction (or expansion or refinement) of process designs to better cope with boundary cases that generate problems
  • Removal of grandfathered products that have few customers, generate losses and consume disproportionate support effort
  • Removal or refinement of interfaces, especially east-west systems that contribute little to an end-to-end process but lead to many fall-outs
  • Identification of improved exception handling, either within systems or at hand-off points

I’m sure you can think of many more, especially when you start tracing back up decision trees with a pruning saw in hand!!

 

How smart contracts might reduce risk and enhance trust on OSS projects

Posted on by
Reply

Last Friday, we spoke about all wanting to develop trusted OSS supplier / customer relationships but rarely finding them and a contrarian factor for why trust is so hard to achieve in OSS – complexity.

Trust is the glue that allows OSS projects to happen. Not only that, it becomes a catch-22 with complexity. If OSS partners don’t trust each other, requirements, contracts, etc get more complex as a self-protection barrier. But with every increase in complexity, there becomes an increasing challenge to deliver and hence, risk of further reduction in trust.

On a smaller scale, you’ve seen it on all projects – if the project starts to falter, increased monitoring attention is placed on the project, which puts increased administrative load on the project team and reduces the time they have to deliver the intended outcomes. Sometimes the increased admin / report gains the attention of sponsors and access to additional resources, but usually it just detracts from the available delivery capability.

Vish Nandlall also associates trust and complexity in organisational models in his LinkedIn post below:

This is one of the reasons I’m excited about what smart contracts can do for the organisations and OSS projects of the future. Just as “Likes” and “Supplier Rankings” have facilitated online trust models, smart contracts success rankings have the ability to do the same for OSS suppliers, large and small. For example, rather than needing to engage “Big Vendor A” to build your entire, monolithic OSS stack, if an operator develops simpler, more modular work breakdowns (eg microservices), then they can engage “Freelancer B” and “Small Vendor C” to make valuable contributions on smaller risk increments. Being lower in complexity and risk means B and C have a greater chance of engendering trust, but their historical contract success ranking forces them to develop trust as a key metric.

We all want to develop trusted OSS partnerships, so why does so much scepticism exist?

Posted on by
Reply

Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer.

I’m an independent consultant, so I have been lucky enough to represent many organisations on both sides of that equation. And in that position, I’ve been able to get a first-hand view of the perception of trust between OSS vendors / integrators (suppliers) and operators (customers). Let’s just say that in general, we’re working in an industry with more scepticism than trust.

So if trust is so important and such a desired status, where is it breaking down?

Whilst I’d like to assume that most people in our industry go into OSS projects with the very best of intentions, there are definitely some suppliers that try to trick and entrap their customers whilst acting in an untrustworthy way. For the rest of this post, I’m going to assume the best – assume that we all have great intentions. We then look at why the trust relationships might be breaking down and some of the ways we can do better.

Jon Gordon provides a great list of 11 ways to build trust. Check out his link for a more detailed view, but the 11 factors are as follows:

  1. Say what you are going to do and then do what you say!
  2. Communicate, communicate, communicate
  3. Trust is built one day, one interaction at a time, and yet it can be lost in a moment because of one poor decision
  4. Value long term relationships more than short term success
  5. Sell without selling out. Focus more on your core principles and customer loyalty than short term commissions and profits.
  6. Trust generates commitment; commitment fosters teamwork; and teamwork delivers results.
  7. Be honest!
  8. Become a coach. Coach your customers. Coach your team at work
  9. Show people you care about them
  10. Always do the right thing. We trust those who live, walk and work with integrity.
  11. When you don’t do the right thing, admit it. Be transparent, authentic and willing to share your mistakes and faults

They all sound quite obvious don’t they? Do you also notice that many of the 11 (eg communication, transparency, admitting failure, doing what you say, etc) can be really easy to say but harder to do flawlessly under the pressure of complex OSS delivery projects (and ongoing operations)?

I know I certainly can’t claim a perfect track record on all of  these items. Numbers 1 and 2 can be particularly difficult when under extreme delivery pressure, especially when things just aren’t going to plan technically and you’re focussing attention on regaining control of the situation. In those situations, communication and transparency are what the customer needs to maintain confidence, but the customer relationship takes time that also needs to be allocated to overcoming the technical challenges. It becomes a balancing act.

So, how do we position ourselves to make it easier to keep to these 11 best intentions? Simple. By making a concerted effort to reduce complexity… actually not so simple as it sounds, but rewarding if you can achieve it. The less complex your delivery projects (or operational models), the more repeatable and reliable a supplier’s OSS delivery becomes. The more reliable, the less friction and a reduced chance of fracturing relationships. Subsequently, the more chance of building and retaining trust.

Hat-tip to Robert Curran of Aria Networks for spawning a discussion about trust.

Fast / Slow OSS processes

Posted on by
Reply

Yesterday’s post discussed using smart contracts and Network as a Service (NaaS) to give a network the properties that will allow it to self-heal.

It mentioned a couple of key challenges, one being that there will always be physical activities such as cable cuts fixes, faulty equipment replacement, physical equipment expansion / contraction / lifecycle-management.

In a TM Forum presentation last week, Sylvain Denis of Orange proposed the theory of fast and slow OSS processes. Fast – soft factories (software and logical resources) within the operations stack are inherently automatable (notwithstanding the complexities and cost-benefit dilemma of actually building automations). Slow – physical factories are slow processes as they usually rely on human tasks and/or have location constraints.

Orchestration relies on programmatic interfaces to both. Not all physical factories have programmatic interfaces in all OSS / BSS stacks yet. It will remain a key requirement for the forseeable future to be able to handle dual-speed processes / factories.

The challenges in transforming network assurance to network healing

Posted on by
Reply

A couple of interesting concepts have the ability to fundamentally change the way networks and services are maintained. If they can be harnessed, we could replace the term “network assurance” with “network healing.”

The first concept is SON, which has been formulated specifically with mobile radio networks in mind, but has the potential to extend into all network types.

“A Self-Organizing Network (SON) is an automation technology designed to make the planning, configuration, management, optimization and healing of mobile radio access networks simpler and faster.”
Wikipedia

One of the challenges of creating self-organising, self-optimising, self-healing networks is that every network has physical points of failure – cable cuts, equipment failure, etc. These can’t be fixed with software alone. That’s where the second concept comes in.

The second concept is smart-contract technology (possibly facilitated by Blockchain), which provides the potential for a more automated way of engaging a mini procurement / delivery / test / payment process to fix physical problems (or logical for that matter). Whilst the work might be done in the physical world, it could be done by third-parties, initiated by the OSS via microservice. Network Fix as a Service (NFaaS), with implementation, test, acceptance and payment all done in software as far as the OSS sees it.

To an extent this already happens via the issuance of ToW (Tickets of Work) to third party fault-fix teams, but it’s normally a significantly manual process currently.

However, the bigger challenge of transforming network assurance to network healing is to find a way to self-heal services that span multiple network domains. This could be physical network functions (PNF), virtual network functions (VNF) and the myriad topologies, technologies and protocols that interconnect them.

I can’t help but think that to simplify (self-healing) we first have to simplify (network variant minimisation).

If we can drastically reduce the number of variants, we have a better chance of building self-heal automations… and don’t just tell me that AI engines will solve all these problems! Maybe one day, but perhaps we can start with baby steps first.

Compiling “The Zen of OSS” perhaps?

Posted on by
Reply

A recent presentation just reminded me of “The Zen of Python.” It’s a collection of 20 (19?) software principles, particularly as they relate to the Python programming language.

Since OSS is software-defined, (almost) all of the principles (not sure about the “Dutch” one) relate to OSS in a programming sense, but perhaps in a broader sense as well. I’d like to share two pairings:

Errors should never pass silently.
Unless explicitly silenced.

Unfortunately too many do pass silently, particularly across “best-of-breed” OSS stacks.

And

Now is better than never.
Although never is often better than right now.

An especially good hint if you’re working within an Agile model!

So that got me thinking (yes, scary, I know!). What would a Zen of OSS look like? I’d be delighted to accept your suggestions. Does one already exist (and no, I’m not referring to the vendor, Zenoss)?

In the meantime, I’ll have to prepare a list I think. However, you can be almost assured that the first principle on the Zen of OSS will be:

Just because you can, doesn’t mean you should.