The PAOSS Call for Innovation has been released

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

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

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

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

The mafia… Pressure? What pressure?

OSS delivery teams can be quite tense environments to work within can’t they? Deadlines, urgency, being in the customer’s line of sight and did I mention deadlines? [As an aside, I’m not sure which type of deadline is more stressful, the ongoing drain of fortnightly releases under Agile, or the chaos of a big-bang release that is preceded by lengthier periods of relative calm.]

When it comes to dealing with stress, I see two ends of a continuum:

  • The teflon end – get it off me, get it off me – the people who, when under stress, push stress onto everyone else and make the whole team more stressed
  • The sponge end – the people who are able to absorb the pressure around them and exude a calm that reduces stress contagion

I can completely understand those who fall at the teflon end, but I can’t admire them or aspire to work with them. I’m sure most would feel the same way. They let urgency overwhelm logic.

This reminds me of a project where the mafia were tightly entwined into a customer’s project team and they were constantly wrangling scope, approvals and payments to ensure “the organisation” profited. They were particularly “active” around delivery time.

A biggest of big-bang deliveries required me to stand in front of a large customer contingent for three days straight to demonstrate functionality and get grilled about processes, tools and data sets. At the end of the third day, we’d scheduled the demonstration of some brand new functionality.

It was a module that had been sold to the customer before even being conceptually architected let alone built. [You know the story – every requirement on an RFP must be responded to with a “Complies” even if it doesn’t]. My client (the vendor) was almost ready to back away from this many-million dollar contract due to the complexity and time estimated to build the entirely new module from scratch. I stepped in and proposed a solution that stitched together four existing tools, some glue and only a few weeks of effort… but we’d never even had it working in the lab before entering into the demo.

At first pass, the demo failed. Being at the end of the three-day demo (and the hectic weeks leading up to it), my brain was fried. The customer agreed to take a short break while we investigated what went wrong. We were struggling to find a resolution, so I was proposing to delay demonstration of the new tool until the following day.

Luckily for me, the most junior member of our team sat in the background plugging away, trialling different fixes. He tapped me on the shoulder and told me that he thought he’d resolved the problem.

We regathered the customer’s team and presented the new module. We waited for the customer’s lead to push an unknown configuration into the network and waited for him to check whether our new tool had responded correctly. It did and the customer was ecstatic.

We’d been saved by a very clever young man with an ability to absorb pressure like a sponge. I couldn’t thank him enough.

Omnichannel will remain disjointed until…

Omnichannel is intended to be a strategy that provides customers with a seamless, consistent experience across all of their contact channels – channels that include online/digital, IVR, contact centre, mobile app, retail store, B2B portal, etc.

The challenge of delivering consistency across these platforms is that there is little cross-over between the organisations that deliver these tools. Each is a fragmented market in its own right and the only time interaction happens (in my experience at least) is on an as-needed basis for a given project.

Two keys to delivering seamless customer experience are the ability to identify unique customers and the ability to track their journeys through different channels. The problem is that some of these channels aren’t designed to uniquely identify and if they can, aren’t consistent with other products in their linking-key strategies.

A related problem is that user journeys won’t follow a single step-by-step sequence through the channels. So rather than process flows, user journeys need to be tracked as state transitions through their various life-cycles.

OSS/BSS are ideally situated to manage linking keys across channels (if the channels can provide the data) as well as handling state-transition user journeys.

Omnichannel represents a significant opportunity, in part because there are two layers of buyers for such technology. The first is the service provider that wants to provide their customer with a truly omnichannel experience. The second is to provide omnichannel infrastructure to the service providers’ customers, customers that are in business and want to offer consistent omnichannel experiences for their end-customers.

Who is going to be the first to connect the various channel products / integrators together?

The trickle-down effect

There’s an interesting thing with off-the-shelf OSS solutions that are subsequently highly customised by the buyer. I call it the trickle-down effect.

By nature, commercial-off-the-shelf (COTS) solutions tend to be designed to cope with as many variants as their designers can imagine. They’re designed to be inclusive in nature.

But customised COTS solutions tend to narrow down that field of view, adding specific actions, filters, etc to make workflows more efficient, reports more relevant, etc. Exclusive in nature.

The unintended result of being exclusive is the trickle-down effect. If you exclude / filter things out, chances are you’ll have to continually update those customisations. For example, if you’re filtering on a certain device type, but that device type is superseded, then you’ll have to change all of the filters, as well as anything downstream of that filter.

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 mat, the more gnarly the beast tends to be.

AIOps (Algorithmic IT Operations)

AIOps stands for Algorithmic IT Operations and is a new category as defined by Gartner research that is an evolution of what the industry previously referred to as ITOA (IT Operations and Analytics). We have reached a point where data science and algorithms are being successfully applied to automate traditionally manual tasks and processes in IT Operations. Now, algorithmics are being incorporated into tools that allow organizations to streamline operations even further by liberating humans from time-consuming and error prone processes, such as defining and managing an endless sprawl of rules and filters in legacy IT Management systems.

Algorithmic IT operations platforms offer increasingly wide and valuable sets of advanced analytical techniques. Although initially targeted at IT operations management use cases and data, they can also be applied by infrastructure and operations leaders to broader data sets to yield unique insights.

A goal of AIOps solutions is to make life better for us, but the line gets a bit blurry when humans interact with AIOps. The more advanced AIOps solutions will have neural-network technology built in that will learn from its operators, adapt and attempt to eliminate repetitive and tedious tasks.
Sai Krishna here.

Yesterday’s post talked about how to reduce a 150-person OSS implementation team down to just 1. The concept of AIOps, if taken to its proposed conclusion, could lead to large reductions in OSS support teams too. In theory, you put the system/s in place, seed them and then let them learn for themselves rather than having a team implement lots of logic rules.

In Gartner’s report, they detail the monitoring capabilities of the top AIOps tools, dividing comprehensive monitoring into 11 categories that include historical data management, streaming data management, log data ingestion, wire data ingestion, document text ingestion, automated pattern discovery and prediction, anomaly detection, root cause determination, on-premise delivery, and software as a service.”
This article from Loom Systems provides some really interesting perspectives on AIOps and the corresponding Gartner report.

For full disclosure, I have no financial interests in Loom Systems or Gartner, nor have I used the Loom Systems tools to be able to promote or deride their market offerings.

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.