Looking outside for innovation strategy

Brainstorms inside the company are useful but not as efficient as stepping outside and checking out the world around you. A lot of companies talk about innovation strategy. I always laugh when I hear that. In this rapidly changing world you cannot talk about innovation strategy anymore. That implies some sort of planning or forecasting the future. Innovation, especially in communication and technology business, you find outside your own company.”
Erik Hoving
here.

There’s a particular telco company that organises OSS RFIs on an almost annual basis. They bring in vendors big and small to demonstrate their best stuff and take careful note of the innovations.

Unfortunately for the vendors / integrators, they’re almost never contracted to do any work for this carrier. However, their best innovations do seem to end up in the carrier’s in-house developed OSS within a year or two. [I should not here that I’ve never dealt with Hoving’s employer so this story is not about KPN].

It seems to me that most of the paradigm shifts in OSS are coming from other digital industries in recent years. I’m blessed to have a large network of highly knowledgeable friends and colleagues who are passionate about tech. PAOSS is another vehicle for looking outside to find relevant innovations but I often feel like there’s so much more I’m missing out on.

I’d love to hear where you “look outside” to find innovation that is relevant / insightful to your OSS trajectory.

Customers buy the basic and learn to love the features

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

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

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

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

A couple of side benefits come from this strategy too:

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

Just three things

I was due to speak at TM Forum Live today but wasn’t able to make it across to France this year. However, the talk will still continue on, so if you’re in Nice please drop in to listen to Amrit Singh and Crispin Blackall talk about how Infosys and Telstra are using microservices to deliver on Telstra’s next-generation of operational support tools. Details as follows:

Date: Wednesday 17th May
Time: 12:20 PM for 25 minutes
Track: Agile Operations & IT Live!
Room: Athena Auditorium, Level 2
CASE STUDY: Putting Microservices into Practice

I may’ve missed out on Nice, but I had the honour of hosting some lectures at LaTrobe University here in Melbourne yesterday instead. During the lectures, I presented some of the ideas in the video below because it really resonates with me. I often come back to this video because of the simple, articulate messages that Steve Jobs delivers.

This is a really interesting snapshot of Steve Jobs’ mode of thinking roughly 8-10 weeks after re-joining Apple as Interim CEO in 1997, at the start of one of the more famous turn-arounds in corporate history. In typical Jobs fashion, he focuses on threes… just three things… a simple list of three objectives.

Great Products – smaller, more concise, more relevant product line

Great Distribution – simplifying the supply chain and reducing backlog of inventory

Great Marketing – clear messaging and investment in the brand and core values rather than the product features

He may be speaking of Apple’s strategic shift, but these three things are also highly pertinent to the OSS industry (and I’ve found them relevant to other business strategies too).

Great Products – smaller, more concise, more relevant product line rather than the unwieldy, confusing list of products that make up many OSS offerings (that goes for internally developed OSS suites, not just vendor offerings)

Great Distribution – I also associate this with simpler and clearer “delivery” of projects / services as well digital software distribution methods (think cloud delivery). I also see this as a reference to the supply chain for our customers, helping them to deliver great offerings out to the market.

Great Marketing – clear messaging and investment in the brand and core values rather than the product features. OSS marketing tends to focus on the features (ie the arms-race of functionality) rather than articulating the advantages we deliver. This possibly occurs because we often can’t articulate to ourselves what the customer is really wanting to solve (to be honest, the customer often isn’t always great at articulating this either, as they often talk about features too).

Steve’s three things helped Apple’s turnaround become one of the most successful in history, so perhaps they can work for you. If not, what are your three things?

Theseus’ OSS transformation

Last week we compared OSS to Theseus’ ship, how it was constantly being rebuilt mid-voyage, then posing the question whether it was still actually the same ship.

OSS transformation is increasingly becoming a Theseus’ ship model. In the past, we may’ve had the chance to do big-bang cutovers, where we simply migrated users from one solution to another. This doesn’t seem to be the case anymore, probably because of the complexity of systems in our OSS ecosystems. We’re now being asked to replace components while the ship keeps moving, which isn’t suited to the behemoth, monolithic OSS of the past.

This new model requires a much more modular approach to solution design, creating components that can be shared and consumed by other components, with relationships in data rather than system interconnectedness. In other words, careful planning to avoid the chess-board analogy.

In some ways, we probably have the OTT (over the top) play to thank for this new modular approach. We’ve now become more catalog-driven, agile, web-scaled and microservices in our way of thinking, giving us the smaller building blocks to change out pieces mid-voyage. The behemoth OSS never (rarely?) allowed this level of adaptability.

This complexity of transformation is probably part of the reason why behemoth software stacks across all industries are going to become increasingly rare in coming years.

In our case the Theseus paradox is an easy one to answer. If we change out each component of our OSS mid-voyage, it’s still our OSS, but it looks vastly different to the one that we started the voyage with.

Rebuilding the OSS boat during the voyage

When you evaluate the market, you’re looking to understand where people are today. You empathize. Then you move into storytelling. You tell the story of how you can make their lives better. That’s the “after” state.
All marketing ever does is articulate that shift. You have to have the best product, and you’ve got to be the best at explaining what you do… at articulating your value, so people say, ‘Holy crap, I get it and I want it.’

Ryan Deiss
.

How does “the market” currently feel about our OSS?

See the comments in this post for a perspective from Roger, “It takes too long to get changes made. It costs $xxx,xxx for “you guys” to get out of bed to make a change.” Roger makes these comments from the perspective of an OSS customer and I think they probably reflect the thoughts of many OSS customers globally.

The question for us as OSS developers / integrators is how to make lives better for all the Rogers out there. The key is in the word change. Let’s look at this from the context of Theseus’s paradox, which is a thought experiment that raises the question of whether an object that has had all of its components replaced remains fundamentally the same object.

Vendor products have definitely become more modular since I first started working on OSS. However, they probably haven’t become atomic enough to be readily replaced and enhanced whilst in-flight like the Ship of Theseus. Taking on the perspective of a vendor, I probably wouldn’t want my products to be easily replaceable either (I’d want the moat that Warren Buffett talks about)… [although I’d like to think that I’d want to create irreplaceable products because of what they deliver to customers, including total lifecycle benefits, not because of technical / contractual lock-in].

Customers are taking Theseus matters into their own hands through agile / CI-CD methodologies and the use of micro-services. They have merit, but they’re not ideal because it means the customer needs more custom development resourcing on their payroll than they’d prefer. I’m sure this pendulum will shift back again towards more off-the-shelf solutions in coming years.

That’s why I believe the next great OSS will come from open source roots, where modules will evolve based on customer needs and anyone can (continually) make evolutionary, even revolutionary, improvements whilst on their OSS voyage (ie the full life-cycle).

Communications Support Systems (CSS)

Have you ever worked in a big telco (or any large organisation for that matter)? Have you ever noticed the disconnection in knowledge / information? On a recent project, I was brought in as an external consultant to find potential improvements to one business unit’s specific key performance indicator (KPI).

As a consultant, my role is a connector – a connector of people, ideas, projects, products, technologies, approaches, etc. On the abovementioned project, I posed questions within the business unit, but also reached out to adjacent units. There were no less than 6 business units that were investigating a particular leading-edge technology that could’ve improved the KPI. Unfortunately, they all only had budget for investigations, with one also having the budget to conduct a very small Proof-of-Concept (PoC). Collectively, they would’ve had the budget to do a fairly significant implementation for all to leverage but separately, none were within 1-2 years of implementation .

I later found out that there was an additional, completely unrelated business unit that had already taken this technology into production with a small trial. It was for a completely different use case but had stood up a product that could’ve been leveraged by the rest.

That got me thinking – the challenge for us in technology is finding a way to remove this waste through “perfect” communication, without bogging us down with information gathering and grooming. Can a conjunct of existing technologies be used, as follows?
Perfect Communication
We already have:

  • Knowledge management systems (KMS) to gather and groom knowledge
  • Chat-bots to collect verbal information and respond with recommendations (more on OSS chat bots tomorrow BTW)
  • Artificial Intelligence (or even just basic analytics tools) to scan data (from KMS, chat-bots, OSS, etc) and provide decision support prompts

We have all the technologies required to significantly augment our current poor communication methods. The question I have for you is do Communications Support Systems (CSS) become an adjunct to OSS or just another IT system that happens to consume OSS data as well as any other sources?

Note: I’ve bracketed “Ambient Listening” in the chat-bot because the six different groups above were all working on research into the cutting-edge technology and talking about it, but there was little in the way of official documentation stored – mostly just emails, communicator conversations, verbal discussions, etc. I do acknowledge the invasion of privacy concerns with this thought experiment though!!  🙂

Bending over backwards

Over the years, I’ve dealt with (and worked with) many vendors, as I’m sure you have too.

Some will bend over backwards to help their customers (or potential customers) out, finding workarounds to their own internal rules to help make something good happen.

Others will persuade their customers into signing a contract before bending their customers over backwards, finding internal rules to their own workarounds to make sure nothing good happens.

Which group do you think customers prefer dealing with? The answer’s obviously the first.
But having been the impartial advisor in vendor selection processes, the group the customer prefers dealing with doesn’t always equate with who they sign a contract with. That answer seems less obvious – to me at least (acknowledging though that there are many factors that go into an OSS purchasing decision).

Nobody cares about your products and services

Many people steeped in the tradition of product promotion naturally feel drawn to prattle on and on about their products and services. But I have news for you. Nobody cares (except you). Yes, you read that right. Get over it. What people do care about is themselves and solving problems. How do you do that?
David Meerman Scott
here.

David Meerman Scott’s quote reflects the same feelings as the first date analogy. He’s right – Nobody cares about your products and services. They only care about what your products and services do for them.

His statement doesn’t just refer to those “sleazy” sales people that us technologists try to take the moral high-ground over (usually without justification, but that’s another story). It applies to us. Are you willing to admit that you’ve been so excited about a technology that you’ve lost complete track of why it’s actually needed? Be brutally honest. I will be. I find that I constantly have to keep the tech-nerd inside me in check.

I’m not sure whether I’m passionate about OSS because of the myriad of cool tech involved or the breadth of benefits they can provide. Probably both… plus a whole bunch of other reasons too.

But I’m hoping there are at least a few people out there who care about my products and services… if for no other reason than because people have found them useful. I’d be delighted to hear from you with ideas on how I can better assist the OSS industry. In fact, I’m currently starting to build towards publishing my next book on OSS / telco and would love to hear your thoughts on what needs to be in it. What are the hot topics that you just can’t find any info on?

The Noah’s Ark of OSS success

Don’t be involved in 50 or 100 things. That’s a Noah’s Ark way of investing – you end up with a zoo that way. Put meaningful amounts of money in a few things you know well.”
Warren Buffett
.

There are a lot of OSS products on the market. From that list, you can probably name a handful that have been very profitable. The reason why, I believe, can be distilled down to two primary factors:

  1. Successful OSS have a specific focus
  2. Successful OSS help a large number of people

Specific Focus – One of the best* OSS that I’ve worked with had a brilliant core and covered a large portion of the TM Forum TAM map (ie delivered a lot of the components that make up a “complete” OSS). I still have a soft spot for this vendor but unfortunately they went out of business, in part because they didn’t narrow their focus tightly enough. Their product development was spread out across the whole zoo. By contrast, unlike this company, some of the OSS companies with largest market share (and profits) don’t directly develop resource performance or fault management tools. Those segments of the market are already well serviced, so those big vendors focus their efforts elsewhere.

Extend helpfulness – I believe that the fastest way to achieve success is to first assist a large number of people in succeeding. The larger the number, the better. If you think about the most profitable companies in the world, you’ll notice that they tend to help a large number of people. The same is true in OSS – the most successful vendors either support a large number of customers, or if supporting a relatively smaller customer list, then each customer tends to be large a organisation with many operators.

The way I like to think of it is:

  • For point 1 – know what’s on the left side of your whale curve and therefore what to focus attention on
  • For point 2 – without breaching point 1, think laterally about how your focussed product / suite could assist a larger customer group. For example, this might be thinking about how it can assist your customer’s sales / marketing / executive / etc business units, not just operations

This isn’t just an organisational-level perspective. From a personal level, these are also the same two personal growth questions I ask myself regularly. What are your thoughts? How could I (or you) improve on these two factors (or others)?

* When I referred to the vendor as being one of the “best,” I was clearly judging on metrics other than profitability.

OSS design…silence instead of shouting

Sometimes designing is very tempting; sometimes not designing is the answer. Often silence is required instead of shouting.”
Karres en Brands
.

It’s said that when presenting a lecture, the softly spoken have more chance of reaching an audience than the classical loud extrovert. The theory goes that if a voice is barely audible, the listener has to tune right in to hear what is being said.

When it comes to OSS, shouting is the predominant design style. Think about it – how many OSS have you seen where there are hundreds of data points jammed into each page / screen? All of them? I’ll be honest, I can only recall seeing one OSS where the design style could be said to be minimalist. And to be equally honest, I think their approach is the way of the future for OSS. They’re only a relatively new player on the market and they share a number of guiding, but contrarian, OSS principles with me so I am watching their progress with anticipation.

Have you ever heard the old adage when selling a house, “remove the clutter!” Do you think the same applies to selling / building an OSS? I do… but it’s also a courageous decision in the current environment where vendors are competing in an arms-race of features (most of which will never be used by any given OSS operator). Just like your house, if you know what’s (not) being used, you know what to remove. But if you don’t know what features are being used by customers (ie you don’t have a way of measuring this), how do you know what is clutter and what is actually valued by customers?

BTW. You can tell that I’m equally guilty of this. De-cluttering the PAOSS website has been on my to-do list for some time but the sheer volume of client work has kept it on the back-burner (for now).

Treating telco like electricity

Whenever I look at telco provisioning projects, I can’t help but think at the complexity involved. Processes are lengthy, with multiple manual steps, mappings, data gathering, sequencing activities, approvals, settings and options. It’s no wonder that OSS evolutions and transformations are a nightmare for operators from the perspectives of effort, risk, cost, etc.

If we look at residential customer services, the 80% in Pareto’s 80:20 rule just want a connection to the Internet at the fastest speeds possible and possibly some additional over-the-top services like email. The base service sounds like electricity supply – a standardised service with almost no service choices and a consumption-based pricing model (perhaps with a fixed annual service and/or connection fee).

I can understand the thought processes. 1) From the product-owner perspective, a standardised service tends to commoditise. 2) From a network-operator perspective, the configurability of current networks make service complexity a necessity.

What if we were to counter those arguments in an effort to get to the electricity model? 1) Profit is the difference between income and cost. A commoditised service generates lower income, but cost and risk (particularly within OSS) reduce massively if the proposed model could be implemented. 2) If the network can’t be simplified because of the vendor offerings currently on the market then virtualised networks represent an opportunity to change this. To change entire protocols even. Even still, most network complexity is introduced because of the long-tail of “what-if” scenarios – “what if” a customer asks for feature X? But if feature X is introduced, does the revenue generated outweigh the total lifecycle cost of introducing it? Instead, can network features be pared back?

I’d love to hear your thoughts about why there is an opportunity for the SouthWest Airlines version of a telco, or why I’m in dreamland and it can never happen.

OSS vendor websites – are they helping their customers?

Amongst other consultancy activities, I help clients find the best OSS solution for their needs. This means I’m constantly analysing vendor offerings to cross-reference against client needs.

Based on this perspective, there’s a question I would like to pose to vendors – Why are potential customers coming to your site? [Note: for the purpose of this blog we’ll disregard existing customer visits]

Can we assume that it’s because customers either:
A) Have an existing OSS and are looking to replace it
B) Don’t have the functionality yet (or maybe they’re just winging it with spreadsheets or similar)
And they’ll want to do a review (ie an informal shortlisting) before contacting any vendors directly.

For both A and B above:
1) They’ll need to prepare a business case to justify that the new investment will deliver a positive return
2) They’ll need to justify that the new capability will improve their current situation
3) They’ll want to have the sense that they can trust the professionalism of the vendor

They’ll also need to do a comparison:
4A) If A) above, they’ll need to be able to compare your solution (financial, technical, risk, etc) with theirs.
4B) If B) above, they’ll need to be able to compare your solution (financial, technical, risk, etc) against others on the market

Vendor websites usually help with 2) and 3), but obviously some are much easier than others to find the information customers are after. As a customer, the dilemma is that most vendors have highly flexible pricing scales / models so they’re hesitant to publish this info online and vendors find it difficult to gather the quantifiable benefits they provide. THhis means they struggle to help customers to resolve 1). And regarding 4), customers will usually have to kick off their own analysis (or engage PAOSS) because vendors rarely make it easy to generate competitor comparisons.

An important note in relation to 1), the customer potentially has little concept of what their new OSS will cost, and hence prefer to do some groundwork before negotiating with their financial boffins what their budget will be… and only then will they speak with vendors. There’s also the old concept that if an investment looks like delivering big then budgets can (almost) always be increased commensurately. For example, would you spend your $1M OSS budget on Option 1 if you could only identify $500k benefits, or would you spend $2M (ie a 100% increase on budget) on Option 2 if you could identify $5M in recurring benefits? Your organisation would invariably opt to increase the budget wouldn’t they?

The other challenge in relation to 1) is that the benefits of OSS are often quite intangible. That’s part of the reason why I wrote the OSS Business Case builder e-book.

If you’re a vendor and think any of that relatively generic info is worth diving further into, please contact me and we can create a more directly actionable plan for your site.

I’d hate to alarm you…

… but I will because I’m alarmed. 🙂

The advent of network virtualisation, cloud-scaling and API / microservice-centric OSS means that the security attack surface changes significantly compared with old-style solutions. We now have to consider a more diverse application stack, often where parts of the stack are outside our control because they’re As A Service (XaaS) offerings from other suppliers. Even a DevOps implementation approach can introduce vulnerabilities.

With these new approaches, service providers are tending to take on more of the development / integration effort internally. This means that service providers can no longer rely so heavily on their vendors / integrators to ensure that their OSS solutions are hardened. Security definitely takes a much bigger step up in the list of requirements / priorities / challenges on a modern OSS implementation.

This article from Aricent provides a few insights on the security implications of a modern API architecture.

* Please note that I am not endorsing Aricent products here as I have never used them, but they do provide some thought-provoking ideas for those tasked with securing their OSS.

The modern OSS cycle – to build rather than buy

Have you noticed a changing trend where some of the largest service providers in the world are reverting to building their own OSS / orchestration (ie writing software) rather than buying off-the-shelf? The trends pushing this cycle are software defined networks and agile development models.

In the earliest days of OSS, the service providers made their own tools. They developed for their own internal needs and eventually banded together to write up standards like ITU-T’s M.3400. Over time, the market changed, with more off-the-shelf products being available with baked-in functionality and service providers decided not to develop tools that were already available and just needed configuration.

OSS Development Cycle

But now, it’s all about custom-built microservices, APIs, browser-based user interfaces, DevOps, machine-to-machine interfaces to accommodate automations and the piece de resistance, orchestration. Instead of collaborating with standards, we’re collaborating with open-source. The modern OSS/orchestration is all about rapidly (and continually) rolling out smaller, custom updates.
I acknowledge that open-source could be considered “off-the-shelf” in terms of being a pre-existing code base and there are some existing products that slot into certain blocks within architecture stacks (eg application servers, orchestrators, etc).

Sounds good… However, I two slight reservations with the current approach that may lead to the eventual cycle back to off-the-shelf:

  • The relative scarcity of resources who are skilled and experienced enough to build these new wild-west models (noting tongue-in-cheek that over time the wild-west will be tamed and more of the functional building blocks will become productised and available off-the-shelf). The previous blog was designed to be prerequisite reading to this point. The question becomes whether next-generation languages will allow everyone to code and if not, will service providers want so many pigeon-holed resources (ie developers) on their payroll? Would organisations prefer teams who can make the configuration changes of the previous cycle rather than code changes?
  • The long-term challenge of code maintenance – large developments work well when the project is underway and there is a large pool of resources who know what’s happening and roughly how the code works. But as the projects diminish and the products go into maintenance mode, resources move on. Will the infinite cycle of DevOps actually last forever and the code will be continually renewed or will it be like other cycles and future redundancies strip an organisation of anyone who knew how today’s products worked. At least with off-the-shelf products, vendors are obliged to retain the skills to know and evolve their products until obsolesence

Is it inevitable that the current cycle of in-house development will revert to off-the-shelf solutions once DevOps loses steam and software eventually stops eating the world? How far off is that?

BTW, I’m not trying to suggest that the current off-the-shelf product model is the right way, harking back to the past, because that model also has its own limitations (eg too bloated with baked-in functionality, too inflexible unless the vendor is developing to the beat of your drum, etc). Perhaps the next generation will have fewer warts (or just a different type)?

Marc Andreessen’s platform play for OSS

Marc Andreessen describes platforms as “a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.”

Platform thinking is an important approach for service providers if they want to recapture market share from the OTT play. As the likes of Facebook have shown, a relatively limited-value software platform becomes enormously more valuable if you can convince others to contribute via content and innovation (as evidenced in FB’s market cap to assets ratio compared with traditional service providers).

As an OSS industry, we have barely scratched the surface on platform thinking. Sure, they are large platforms used by many users, we sometimes offer the ability to deliver customer portals and more recently we’re starting to offer up APIs and microservices.

As we’ve spoken about before, many of the OSS on the market today are the accumulation of many years (decades?) of baked-in functionality (ie product thinking). Unfortunately this baked-in approach assumes that the circumstances that functionality was designed to cater for are identical (or nearly identical) for all customers and won’t change over time. The dynamic and customised nature of OSS clearly tells us that this assumption is not right.

Product thinking doesn’t facilitate the combinatory innovation opportunities represented by nascent technologies such as cloud delivery, network virtualization, network security, Big Data, Machine Learning and Predictive Analytics, resource models, orchestration and automation, wireless sensor networks, IoT/ M2M, Self-organizing Networks (SON) and software development models like DevOps. See more in my research report, The Changing Landscape of OSS.

Platforms are powerful, not just because of the cloud, but also the crowd. With OSS, we’re increasingly utilising cloud delivery and scaling models, but we probably haven’t found a way of leveraging the crowd to gain the extreme network effects that the likes of FB have tapped into. That’s largely because our OSS are constrained by “on-premises” product thinking for our customers. We allow customers to connect internally (some may argue that point! 😉 ), but aside from some community forums or annual customer events, we don’t tend to provide the tools for our global users to connect and share value.

In not having this aggregated view, we also limit our potential on inherent platform advantages such as analytics, machine-learning / AI, combinatorial innovation, decentralised development and collaborative value sharing.

Do you agree that it all starts with re-setting the “on-prem” thinking or are we just not ready for this yet (politically, technically, etc)?

[Noting that there are exceptions that already exist of course, both vendor and customer-side. Also noting that distributed datasets don’t preclude centralised / shared analytics, ML/AI, etc, but segregation of data (meta data even) from those centralised tools does!]

 

A hat-tip to the authors of a Platform Thinking Point of View from Infosys, whose document has helped frame some of the ideas covered in this blog.

NFV as the catalyst for a new OSS world order

operators that seek to implement NFV without preparing their OSS to support it are unlikely to be successful in capturing the new revenue-generating and cost-saving opportunities. OSS should not be an afterthought; it will continue to be central to the operational efficiency and agility of the service provider.”
James Crawshaw
in “Next-Gen OSS for Hybrid Virtualized Networks.”

The quote above comes via an article by Ray Le Maistre entitled, “NFV Should Be Catalyst for OSS Rethink.” Ray’s blog also states, “OSS transformation projects have a poor track record, notes Crawshaw, while enabling integrated management and implementing an evolved OSS will require a new set of skills, process engineering and “a change in mindset that is open to concepts such as DevOps and fail-fast,” notes the analyst.”

Ray comments at the bottom of his article, “There are certain things that will be relevant to all operators and none that will be relevant to all… in theory, a very smart OSS/NFV savvy systems integrator should be cleaning up RIGHT NOW in this market.”

These are some great insights from James and Ray. Unfortunately, they also mark what is a current dilemma for providers who are committing to a virtualised world. Whereas the legacy OSS had a lot of pre-baked functionality already coded, and needed more configuration than code development, the new world of OSS does need more coder-centric integration work.

The question I am pondering is whether this is:

  1. A permanent shift (ie a majority of work will be done by coders to make API-based customisations); or
  2. Whether it is just a temporary state pending the wild-west of NFV/OSS/DevOps to mature to a point where the main building blocks / capabilities are developed and we revert to a heavy bias towards configuration, not development

If it becomes the former, as an industry we need to be focussing our attention on developing more of the skillsets that overlap in the yellow overlap in the Venn diagram below. There are too few people with the paired expertise in networks (particularly virtualised networks) and IT / coding (particularly in our current DevOps / API environment). In fact, in a world of increasingly software-defined networking, does it become increasingly difficult to be a networking expert without the IT / coding skills?

Even rarer is the mythical beast that sits in the red union of this Venn diagram – the one who actually gets what this all means for the organisations implementing this new world order and is navigating them through it. To paraphrase Ray, “a systems integrator that has great expertise in the red zone should be cleaning up RIGHT NOW in this market.”

But are they really mythical beasts? Do you know any??

Why don’t more OSS use the entry-level offer strategy?

The OSS market has two ends of a continuum – one end consisting of what I refer to as “the self-service customer” (ie highly repeatable) and the other being “the requirement of one customer,” (ie highly customised). Naturally there are contracts that fall on the continuum between these two extremes too.

The self-service end of the market has proven to be a successful niche for some vendors, the ones who have made their products highly user-friendly. They’ve also made them highly repeatable, albeit still customisable. They tend to provide free trials and / or very low-cost starting points. I’d like to explore this with you in more detail today.

One of the challenges for the highly customised OSS offerings is the lengthy sales cycle and corresponding cost of sales that go hand-in-glove. The entry-level offer strategy is designed to circumvent long sales cycles by giving the customer a “rapid outcomes with almost no risk” use of the solution. This is the complete inverse of customised OSS solutions isn’t it? They tend to take a long time to deliver outcomes and there is huge risk in selecting a vendor, which leads to the long sales cycle in the first place.
The entry-level package is basically (no pun intended) the simplest, bare-bones version of the offering (eg a containerised version). Being bare-bones, it requires a minimum viable product, lean thinking approach – to make everything from download to install to configure to operation highly simple, streamlined and repeatable. It requires an 80/20 mindset on many levels, such as which interface types (eg SNMP) and which networks (eg IP) will be used by almost every customer so that almost anyone can easily get some of their data into the system (eg alarms, discovery, etc) to be able to play with.

This entry-level thinking is anathema to most OSS vendors (except the self-service players of course), because there is a perception that they make their money and differentiate their products through their ability to cope with almost any unique customer’s requirements. The entry-level approach is also deemed risky because customers may perceive that this minimalist product is incapable of performing some of their important, unique use cases. This is where really clever design is required – to show the customer that there is an upgrade path to service their need and/or for the product to have functionality that takes the customer’s feedback and allows the vendor’s team to quickly show how that requirement could be met with current or custom functionality.

This approach doesn’t help where the customer issues highly customised request for proposals (RFP) and / or demonstrations, but generally these RFP processes follow lengthy prior dialogue with vendors / integrators.

For many in the industry, this is a very contrarian view, so I’d love to hear your take on the scenarios where it might or might not work.

Where does trial and error belong in OSS?

I hold a somewhat philosophical view of where OSS (and IT in general) fits within its overall timeline. It’s all pretty nascent in the grand scheme of things.

Whilst communitications technology is the common thread, I’ve worked in many industries including construction, mining, engineering, government, utilities, emergency services, healthcare, farming and more. Most of these industries have been around for far longer than OSS. As the outsider looking in on those industries, it seems that the basic techniques they use have existed for decades and have been refined to the point of relative maturity and consistency*. Think the technique for preparing a suture on a wound, of building a timber frame for a house, of milking a cow, etc. There’s not much error because the trialling has already been refined out of the process.

But OSS is much younger. The technologies they’re built upon are still in a state of massive upheaval. We aren’t even close to reaching an asymptote of refinement yet. Within this maelstrom of change, there is still a lot of trialling underway. And when there’s trial, there’s bound to be errors. They happen whether you like it or not. In the case of OSS, a LOT of errors. Clearly, errors are not in short supply.

Trial, on the other hand can be far more scarce. The fear of making mistakes on these large, complex projects often holds us back from performing the trials that could help us contribute to the Global OSS Body of Knowledge (GOSSBOK). We mistakenly believe that to avoid error, we have to avoid trial. We actually need more trial. **

Having said that, these projects consume too many resources to be an out-of-control learning experiment. The key call-out here is that our OSS already provide the tools to conduct many controlled micro-experiments. Our databases of large, relational information are perfect for conducting rapid prototyping or rapid insight checking.

* Note that I’m not trying to denigrate the innovation occurring in these industries, as I’m sure they are all highly innovative.
** I’ve shamelessly borrowed from the words and concepts in a Seth Godin blog

eTOM or TAM as a product mapping tool?

Have you noticed that TM Forum’s eTOM seems to be used in common vernacular when people talk about mapping and/or comparing products. eTOM and TAM are both quite closely linked (you’ll notice the similarities in colour-banding between the two). However, eTOM is more of a standardized mapping of workflows, whereas TAM is more of a mapping of standardized product functionalities.

Since workflows follow a journey, often through multiple products (potentially even multiple vendors’s products), I personally don’t subscribe to eTOM being the best way of mapping product functionality / capability by vendor. To me, TAM is much more applicable for this purpose*. If you’re a service provider mapping your user journeys, then eTOM does seem the right fit. Do you agree? How do you best use these TM Forum toolkits?

* However, I do note that if the customers are talking eTOM (or any other terminology for that matter) then it’s best to move to their language / wavelength. In my experience, many customers don’t know much about either eTOM or TAM (using it as “inclusive” jargon), so you should be able to switch to their wavelength with just a few questions about what they really want to know in relation to a request for eTOM mapping.

Interestingly, the top level TAM mapping is not necessarily a great communication tool in its own right, but I find that with the right supporting dialogue it can tell a very powerful product comparison story.

If the OSS sales process is broken, does this narrative help to fix it?

Yesterday’s blogged posited that the OSS sales process – of joining a customer and a vendor to form a sales contract – tends to have serious flaws.

Whilst deals still get done (you can see enough of them by clicking on the “News” category here on PAOSS), I’ve yet to see a deal where both parties were ecstatic about the whole process, notwithstanding the excitement of actually closing out an important deal. In my experience, each party has never been able to get to alignment on Simon Sinek’s WHY (see yesterday’s blog for details).

This post from Andy Raskin entitled, “The Greatest Sales Deck I’ve Ever Seen,” provides some food for thought in relation to getting alignment between OSS buyer and seller as well as providing a five step plan for getting there.

It takes the approach of building a narrative that can be delivered consistently by all sales agents in an organisation, but more importantly, starts with two steps that help the sales agents to immerse themselves in the customers’s WHY.

Here are the five steps of the approach, but I recommend you read the whole article for greater context:

  1. Name a Big, Relevant Change in the World (of the customer)
  2. Show there will be Winners and Losers
  3. Tease the Promised Land
  4. Introduce features as “Magic Gifts”
  5. Present evidence you can make the story come true

Sounds like a simplified version of The Hero’s Journey doesn’t it? Perhaps it forms the basis of The OSS Hero’s Journey?

Zuora (on which Andy Raskin’s premise is based) isn’t as multi-dimensional as OSS, so instead of one pack, OSS might need some slight refinements for each customer’s big relevant change.

Now let me pose another thought for you in relation to why a story / narrative is more effective than a set of dot-points in a presentation or selling based on a vast list of features / capabilities. The concept is courtesy of the Freakonomics team:
It’s purported that The Bible has sold more copies and is by far the most widely read book in existence. Within it, there is a list that is one of its most famous concepts – the list of the 10 Commandments.

Can you recount each of the 10 Commandments? [not many people can apparently] But even if you’re not a Christian, can you tell the stories of Noah, Moses, Sampson, Adam & Eve, etc?
It seems our brains are wired to remember stories, not lists.