IoT equals lower ARPU?

Surprisingly though, wireless providers themselves are one of the largest hurdles for advancing IoT, with many resisting adding connectivity to new devices due to fears of lower APRU metrics. CSPs must band together and embrace future innovation before competition edges them out. Perhaps creating an IoT MVNO is the transition necessary for addressing lower ARPU, while still fostering the innovation necessary to drive these new revenues.”
Humera Malik
in this article.


Are CSPs really resisting IoT due to fears of lowering ARPU (Average Revenue Per User) figures? If so (and I have no reason to disbelieve Humera’s claims BTW), then aren’t the CSPs taking too narrow a perspective on what IoT represents? Are they really only looking at providing wireless data (and hence the low ARPU due to IoT generally being a low data volume telemetry-style service)?

Now I’m only a humble OSS consultant / engineer / architect / promoter, but why would the telcos not be seeking to build* the whole IoT ecosystem play, as discussed here, not just the data plumbing?

Would ARPUs from the whole IoT ecosystem (network, apps, content, sensor management, etc) be less than ARPUs of a traditional mobile user? Given that the ecosystem model is designed around the value fabric and revenues are shared amongst the players that are adding value, does ARPU remain the relevant metric for IoT for CSPs?

I’d love to get your opinions on this. Are telcos going to just provide the wireless data streams or should they (are they) aiming higher?

* When I say build, this could be in the value-fabric / partnership model of service offering.

OSS flaws

People are too eager to say “This legendary person had flaws!” instead of, “Wow, this flawed human being managed to do something legendary.”
Mishell Baker.

Interesting perspective from Mishell above, one which I concur with.

As usual, I have a take on this in relation to OSS. I think we often spend so much time on making the little things perfect that we lose sight of the big things that will make our OSS legendary. But this is something of a contrarian view.

Your customers and your stakeholders expect your product offerings to be perfect, for no fall-outs to occur, for all events to be processed, for no exceptions to arise, etc. I agree that this is a great objective, although I’d also note that this level of perfection requires an exceptional amount of your thought, design, development, process, data cleansing and testing.

But I wonder whether all that extra effort could be redirected to identifying and creating products that can make a significant difference to the organisation, acknowledging that there will be slight imperfections that are captured and processed manually.

This perspective is particularly important for customers / stakeholders that don’t have large budgets to allocate to their OSS. They need to get the best organisational bang for their buck, rather than a smaller but highly refined product.

But the tough part of this is convincing stakeholders that they won’t be getting perfection (although noting that there is no such thing in OSS anyway). How many of customers / stakeholders have you ever been able to persuade to accept flaws in return for something legendary?

Chief Simplification Officer

What simple action could you take today to produce a new momentum toward success in your life?
Tony Robbins

Complexity is the single biggest challenge that stands in the way of us delivering OSS masterpieces. As described in, “The triple constraint of complexity,” the reduction of any complexity should have a multiplier effect towards the success of the project. This principle doesn’t just apply to OSS, but also to the CSPs that utilise them.

So for today’s blog, I came up with this catchy concept of the Chief Simplification Officer. How very unique… Only problem is that when I searched for the term online I found there were around 400,000 existing references so the concept isn’t remotely unique unfortunately. Anyway….

Whilst we all have the responsibility of being CSO on our projects, I wonder whether every significant OSS project or OSS operational team should have a CSO or a Project Simplification Officer whose entire purpose is to identify ways of making the OSS simpler.

Do you think that such a role is justified? If so, what do you think are the essential traits that this person would need?

The Telco/Utility Model

Something strange is happening in a rubbish bin in Milton Keynes. On his way to the bus stop, Alex drops a drinks carton into it. The bin’s sensor system detects that an item has passed the top ridge of the container. It sends out a signal that alerts local rubbish trucks. Before Alex’s bus arrives, Becky’s truck comes to empty the bin. Milton Keynes Council’s MK:Smart partnership is trialing new kinds of sensor systems at a city scale. This experiment uses new communication channels, bypassing mobile phone masts and WiFi hubs. These channels can use electromagnetic spectrum with much longer wavelengths. If the communication system needs to pass on small amounts of information at a time, it doesn’t matter if the waves are more spaced out.”
Jessica Bland
, here on Nesta.

Yesterday’s blog covered an interesting opportunity for telcos to generate new streams of income, specifically in the form of delivering smart city capabilities. The concept takes sensor networks or IoT (Internet of Things) to a city-wide scale.

Telcos already have the network reach, the subscriber base, the service volumes, customers within all market sectors and have been servicing sensor networks like traffic lights for years.

BT has already cottoned onto the opportunity, working with Nuel, a provider of low power, connected sensor networks in a trial at Milton Keynes called the MK:Smart project.

The trouble with IoT and smart city concepts is in the ability to build a compelling business case around them. The tech may sound exciting, but do rubbish bin sensors produce business benefits. There’s no doubt that clever innovators will develop concepts that are beneficial, popular and profitable, but I wouldn’t expect the telcos to corner that market, just as they are unable to provide all of the most successful apps that leverage their wireless networks.

The opportunities for telcos like BT are to provide the platform that supports the whole tail of users, the successful and not so successful. Opportunities in markets such as health-care, transport systems, emergency services, education, etc. This is where tools that I’ll loosely call OSS come in. These “OSS” tools are probably a combination of telemetry, analytics, user portals, content delivery, etc all rolled into one. Just as Nuel has provided it’s Weightless-standardised technology to provide the sensor network platform for BT and MK:Smart, the opportunity exists for “OSS” providers to build the frameworks that telcos will provide to their customers to build smart-city / smart-grid / IoT applications on.

Where OSS meets Smart Grids

It’s less about boxes and bases stations; it’s now a lot about software analytics, capability of reconfiguration and all that. It’s a very big shift from what we have seen in the last years.”
Professor Mischa Dohler

In the video in the link above, Prof Dohler suggests there are two major disruptions happening in relation to the telecommunications industry – one is an internal one of making the very painful transition from hardware to software (and all the related configurability) and a second one that works for the Telco industry in its ability to offer totally different applications than we’ve seen before.

He highlights the overlap of the telemetry of Telco networks with those of smart cities (ie smart grids) and how that provides an opportunity to deliver applications that blend the best of those technologies.

In an environment like this, OSS are no longer just an internal operational tool, but become the platform for making connections, applications and content to service a CSP‘s customers in new ways. To live up to this lofty goal, OSS has to become a highly open framework to facilitate the needs of a CSP‘s customers rather than it’s current guise as servicing the CSP‘s internal needs.

Supporting Ops

The mind is seldom quickened to very vigorous operations but by pain, or the dread of pain. We do not disturb ourselves with the detection of fallacies which do us no harm..”
Samuel Johnson

Operational Support Systems are exactly that – OPERATIONAL support systems.

Many people in our industry lose sight of that fact sometimes.

For example, how many of us actually know what our CSP‘s field work-force actually do? The processes they follow, the equipment they use, their return-to-base policies, their most common job allocations, their scheduling rules, the terminologies or naming conventions they use, the particular rules / constraints / regulations that they must abide by, the rules-of-thumb they apply, etc?

Other operational teams, such as network operations, are commonly consulted on an OSS‘s requirements, but the field workforce rarely is. If you’re in any way responsible for creating the Tickets of Work or Work Packages that the field workers use, then don’t you think you’re obliged to find out rather than assume what they might need (the fallacies which do us no harm)? And when I say “in any way responsible,” that also means all the upstream decisions, such as naming conventions, interface specifications, data capture, process designs, etc.

Often the field-work activities are outsourced to third-party companies, so it’s an easy excuse to claim that you don’t have access to the field workers. That’s probably true… but any inefficiencies created (directly or indirectly) by your OSS tools or processes will impact the CSP you’re representing through repeated truck rolls, inaccurately recorded data, etc.

You might counter by claiming that the third-party could be compensated by orders activated rather than truck rolls so there is no financial impact to the CSP. You could be right about the contracts, but there is a reason why many CSPs around the world are using the NPS (Net Promoter Score) metric. Many believe that customer satisfaction (or dissatisfaction if the field workers can’t deliver service quickly) is a fundamental measure of whether their organisation is thriving (or not).

Telco as a Utility (TaaU)

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three – and paradise is when you have none.”
Doug Larson

Will there come a time when telco services are simply like every other utility – a unit of service (ie Mb) that a residential user (and commercial?) can purchase from any retail provider that services their area and consume as needed?

Let’s look at electricity. It’s wired to your house and distributed to each of the power points within your house. There are millions of different devices that you could plug into your power points that don’t require complex configuration, protocol matching, specific electricity supplier product variants, etc. Nor does the electricity industry try to supply all of the devices. They simply couldn’t innovate fast enough to service the long tail of customer needs, although they may influence the certification of every new type of device for use on their networks in some countries. The electricity distributors don’t sell a huge range of electricity “products” and their pricing plans are usually just a relatively limited combination of connection/network charge plus consumption charges.

Let’s look at telco by comparison. We try to deliver a million different product variants, with another million different pricing bundles / plans. Since product / marketing is at the start of the life-cycle, these variants then flow through every other part of the business and complexity amplifies. By the time it reaches network design, business processes, OSS/BSS, etc we have to handle an incalculable array of possibilities.

Just as the electricity industry doesn’t try to be all things to all people in terms of electrical products, the telco world can’t possibly deliver to every need of every customer. That’s part of the reason why the telco industry has been disrupted by OTT products/services that utilise bulk-bandwidth to deliver innovations that service the long tail of customer needs. They can innovate at the speed of software. [As an aside, one of the reasons the iPhone was successful is that Apple did away with the keypad and opened up the interface to be fully programmable in software and hence adaptable to any future innovation the world could come up with rather than being stuck in user input via a qwerty keypad and menu control buttons. That could equally apply to TaaU].

Simpler products, processes, technologies and systems would have to lead to more efficient delivery of service (and more easily deliverable OSS projects) wouldn’t it?

This un-differentiated telco utility model would tend towards commoditisation and perhaps we’re already well down this path anyway. This model would also seem to suit the Telco REIT investor, giving reliable cashflow but perhaps with constrained profit margin opportunities. As discussed in the same link, spinning off the REIT part of the telco business would also allow for investment in the new media business units that focus on applications and content, where margins have been stronger in recent times for market leaders.

To be honest, this topic is filled with an open-ended discussion of pros, cons and possibilities. I’ve barely scratched the surface here (I haven’t even discussed regulatory implications for example). I’d love to hear your thoughts on the subject.

And assuming TaaU is on the horizon, is a similar fate awaiting data centre operators with commoditised compute/storage/network units of consumption?? DCaaU??

Augmented Outside Plant – Part 2

In an earlier blog entry, I wrote about using Augmented Reality (AR) to equip field staff with views of physical assets (eg underground, data centre, etc) (and OSS data of course). Well, I’ve just found out that such a product exists from a company called Augview (perhaps there are others I’m unaware of too?). The following video provides a demonstration of Augview:

Open source software supportability

When it comes to software, I much prefer free software, because I have very seldom seen a program that has worked well enough for my needs, and having sources available can be a life-saver.”
Linus Torvalds

I recently had an interesting conversation with a very bright young man who is just starting out on his career. During the wide-ranging discussion he asked why more organisations don’t use open source software.

In my opinion, it comes down to support. Most organisations (and individuals) want to be able to delegate responsibility for their software, particularly when it comes to business continuity risks. This is where the old adage of, “you don’t get fired for signing with IBM,” often comes into consideration. Obviously there are also many organisations that have faith in their own resources’ ability to support their open source tools, but these are in the relative minority.

Whilst Paul’s question was not directly related to OSSOSS (Operational Support System – Open Source Software), the perspective is equally reflective for OSSOSS.

The diagram below shows a generalistic view of what types of organisations choose proprietary versus open source OSS.

I find the middle tier interesting from the perspective of the red question mark. Generally speaking, organisations with medium pockets tend to find it difficult to fund full-spectrum proprietary OSS and baulk at the prices. Conversely, supportability is often a point of consternation for these customers when considering the integration of multiple open source OSS tools to form a full-spectrum OSS.

I believe that there is a great opportunity to service this growing middle-tier market. There are many open-source OSS tools available that could partner / bundle / integrate together to offer full-spectrum functionality and partner to provide a compelling support service.

DCIM Opportunities No. 2

GIS is a form of digital mapping technology. Kind of like Google Earth, but better.”
Arnold Schwarzenegger

Two days ago, we discussed the similarities and differences between DCIM (Data Centre Infrastructure Management) and OSS. In it, we indicated that Data Centres (DCs) tend to have less outside plant or inter-site connectivity (ie most power and network links tend to reside within the Data Centres), but cable management and network links are more likely to be managed within 3D spatial systems (x, y and height), not just the x and y coordinates of GIS (Geographical Information Systems).

This occurs in multi-level DCs and/or multiple levels of cable trays, where height of cable trays and/or riser shafts above ground-level become important for spatial visualisation of cable assets. Many traditional spatial systems are configured for managing highly distributed cable assets (ie direct buried cables spread out across countries!), so they don’t really need the third dimension of height.

For OSS vendors, adding the third dimension to your spatial systems will have the benefit of increasing the attractiveness of your product to industrial and utility organisations. They also have cable assets at various heights throughout their plants and easements.

3D modelling can also be important for modelling heat build-ups in certain areas within data centres, but this would require algorithms that are quite different in nature to those in existing Telco spatial systems!

Sell to – Sell through

One of my partners reminds us that, to be a success, a company must not only sell successfully to its immediate customers (“sell-to”), but also enable the customer to sell successfully to his/her end customers (“sell-through”), not just once, but repeatedly. Too often we (as venture investors) see businesses that have revenue traction selling to immediate customers. But, that success proves illusory when the end-customer does not buy, or if s/he buys, there is no stream of repeat business. As a result, the business spends more and more on sales and marketing, but ultimately fails to scale.”
Todd Hixon
here on Forbes.

If you’re with an OSS vendor or integrator (or consultant), are you selling to immediate customers (“sell to”) or do you also have an approach that sells to their customers (“sell-through”)?

It’s patently clear that you know who your customers are (eg CSPs – Communication Service Providers, Utilities, etc) and are selling your products and/or services to them. But do you know who their customers are? Do their customers have a need for OSS products or services?

Let’s take the example where you’re selling to CSPs. They undoubtedly have lots of corporate / enterprise customers that need to monitor and manage the networks on which they rely (increasingly so in the information age). How do you partner with your direct customer (the CSP) to deliver valuable OSS-related products / services to the corporate / enterprise market repeatedly?

Now let’s say your customer is a utility. They have a completely different set of customers because they tend not to deliver communications services to their customers (unless they’re a multi-utility). Their customers might be wholesale providers (ie if they’re electricity generators / distributors) or might be retail customers if they deliver their utility into homes. These customers may derive more value from the analytics coming from the OSS rather than the OSS tools themselves.

To summarise – who are your customer’s customers and how can your products or services potentially help them? Would they be suited to a sell-through model? Does that customer base allow repeatability to thrive?

Utility business models

The traditional business model of utility companies is under threat, with a new approach needed to ensure future success.”
‘s “Business Pulse: Exploring the dual perspectives of the top 10 risks and opportunities in 2013 and beyond.”

Whilst the OSS technologies remain more or less the same, the business imperatives for an OSS are quite different between CSPs and utilities.

The above-mentioned report provides the following four key themes that OSS providers should have in mind when building a solution for their utility customers:

  • Tightening regulation weighing heavily on utilities looking to court consumers
    The consumer is at the heart of the complex relationship between utilities, regulators and policy-makers. With electricity prices expected to increase, it is those utilities that make the most of smart technology to shape how they interact with consumers that are likely to capitalize on the opportunities available to shift public perception of the industry
  • Economic volatility: the new normal
    Utilities have large capital investment needs and long term planning horizons and so uncertainties associated with energy and climate policy, regulatory developments and commodity markets all add exposure and cost to any investment plan. However, growth via the increasing energy demand in rapid growth markets presents opportunities for both local and overseas P&U companies
  • Business model evolution: striving for innovation
    As the utilities sector transforms, so too must its traditional business model of supplying, metering and billing; towards one that is capable of adapting to constantly changing stakeholder requirements. While the nature of this transformation varies among markets, there is a clear shift from a focus purely on selling energy to consumers, to selling energy efficiency or home services
  • Operational challenges: large scale and high risk
    Securing investment and delivering large capital projects will be a key challenge for all utilities as the infrastructure investment needs of these companies are unprecedented. Completing these projects safely, on time and on budget will see companies compete in a fierce battle for in-demand resources and skills. At the same time, P&U businesses must also ensure their approach to managing aging infrastructure – and related asset failure risk – is adequate.

    Political intervention through energy policy changes is also a significant risk, given its potential impact on operations, even in markets previously considered stable and transparent. Since political intervention in utility operations is expected to continue as energy policy evolves it is increasingly important that utilities make the commitment not only to educate consumers about the impact of policy changes but also to build trust.
    When looking towards the operational opportunities, integrating distributed energy resources and improving the on- and off-shore wind supply chain offer real opportunities for utilities to mitigate the risks of these operational challenges.

As the report goes on to say, “Thriving in a volatile environment is not easy, but companies that do so share several characteristics. They are more outward looking and focused on the market, they respond smartly – and quickly – to change, they understand what drives cost and value, and they engage closely with stakeholders. While utilities face the prospect of value erosion in some areas, a robust forward view recognizes that these risks, as well as opportunities, are essential to future success.”

At it’s most fundamental, OSS vendors must consider that the communications network their tools would manage is only a means to an end rather than core business. For CSPs the network is their means of deriving an income. For utilities, the comms network is only used to support their means of deriving an income (eg the comms network supports the operation of the electricity network that delivers revenues). The customer’s OSS business case will similarly spawn from different business imperatives.

The book is now available! Mastering your OSS

My OSS book, entitled “Mastering your OSS” is finally available to the market.

Click on the image below to take a closer look.

For the next two weeks only, I’m offering an extra US$10 off the purchase price to readers of this blog. Just send me an email or a note via the Contact Page and I’ll send you the discount code.

Mastering your OSS, the book.

The link again is


Exciting news

I still encourage anyone who feels at all compelled to write to do so. I just try to warn people who hope to get published that publication is not all it is cracked up to be. But writing is. Writing has so much to give, so much to teach, so many surprises. That thing you had to force yourself to do—the actual act of writing—turns out to be the best part.”
Anne Lamott

Today’s an exciting day (for me at least). The content and cover art of my book, “Mastering your OSS,” have been accepted for publishing and proofs are being shipped. Can’t wait to flip my way through the bound copy that represents many months of late nights / early mornings! 🙂

Mastering Your OSS Cover Image

AT&T creates $500M TV service

AT&T creates $500M joint venture for a Netflix-style TV service

AT&T, America’s second largest broadband provider and wireless company, is getting into the streaming business with a $500 million joint venture created to acquire, invest in and launch a Netflix-style video streaming service. As the television distribution model that’s been in place for decades collapses online, this deal marks the first time a big U.S. ISP has decided to go over the top with a TV service.

AT&T has joined forces with media and entertainment company the Chernin Group, and together the two companies have committed $500 million in funding to the venture. However, the Chernin Group will bring assets to the venture, including the contribution of its majority stake in Crunchyroll, a subscription video on demand service.

This is a massive move by AT&T towards content and is in line with this structural shift blog from a few days ago.

I think we’ll begin to see more of these moves as a means of diluting the share of wallet from OTT players. I think this is especially true for bandwidth hungry services like streaming video where traditional CSPs have control over traffic prioritisation over their own networks (unlike the OTT players).

Is content delivery software part of what you consider to be an OSS? Can your solution pull analytics from streaming video to extract valuable information? If not, I’m sure you’ll be able to analyse interactions with content (eg number of times played, watched in entirety, genres selected, etc).

What are your revenue models from content (eg subscription, advertising, analytics, service bundling, etc) and how does that impact your BSS and billing services?

My new OSS book is nearly ready for publishing

Whenever you read a good book, somewhere in the world a door opens to allow in more light.”
Vera Nazarian

After lots of writing and refining, my book, which is dedicated to OSS implementations, is almost finished. It’s based around 22 commonly asked questions, particularly by readers who are relatively new to OSS. It also allows readers with a particular question in mind to go straight to the relevant question / section. It’s my own version of a choose-your-own-adventure book.

The common questions are:

  1. What is an OSS exactly?
  2. What is the History of OSS and Related Standards?
  3. What are Your Common OSS Terminologies?
  4. Why are OSS Naming Conventions so Important?
  5. Where do You Start When Planning an OSS/BSS Project?
  6. Why is OSS Change Management Important?
  7. Should You Perform an OSS Impact Analysis?
  8. How do You Capture OSS Requirements?
  9. How do You Define Your Organisation’s OSS Roadmap?
  10. How do You Prepare a Compelling OSS Business Case?
  11. How do You Select an OSS Vendor / Integrator?
  12. What Insights can Help Your OSS Negotiation Strategies?
  13. Who should be in Your OSS Implementation Team?
  14. What are Your Biggest Risks and how do You Manage Them?
  15. How do You Plan to Conduct OSS Testing?
  16. How do You Define and Refine Business Processes?
  17. What do You Need to Know about Data Collection and Reporting?
  18. How Should You Kick Off an OSS Project?
  19. How do You Coordinate a Vendor-Led Implementation?
  20. What Post Project Operations Issues Should You Consider?
  21. What Training Should You Take?
  22. What is the Future for OSS?

So, what are the other big questions that I’m overlooking?

Augmented outside plant

When you think of any aspect of life or work, augmented reality is completely going to change how we do it.”
Ori Inbar

Here in Australia, we have a program called Dial Before You Dig, which provides information, usually in the form of plans, about underground assets for a given address. It is used by technicians and individuals wanting to know the locations of underground utility assets (ie electricity lines, water mains, gas lines, telecommunications cables) before commencing on a project that requires excavations at a site.

It’s not too hard to envisage a day when the dial before you dig information from existing utility plans becomes spatially mapped into GIS (Geographical Information Systems) formats and becomes available within augmented reality (AR) visualisation tools like Google Glass. It would enable you to put on your AR glasses and see an overlay of all the underground assets as you walk around the site before starting excavations.

As discussed in an earlier post, AR is likely to impact a number of different functional groups within CSPs. AR could be really helpful for CSP technicians to quickly find cable pits, when they are often covered with dirt and the associated work package only provides approximate coordinates of the pit that they’re due to work at.

Enabling this type of AR is likely to be a joint initiative between:

  • GIS manufacturers
  • AR visualisation tools
  • Custom tools that allows spatial data / content creation, storage and playback / visualisation

The two most exciting aspects of this concept for OSS are:

  1. Many CSPs already use GIS to model their outside plant data
  2. Modern GIS are spatial engines that allow organisations to easily overlay visual information of almost any sort

The ramification of these two points is that many CSPs already have the tools and when combined with any other OSS objects that are geo-coded (ie have GPS coordinates assigned to them) they just need AR visualisation tools and a bit of development work to create powerful AR experiences for their field technicians.

Examples might include:

  1. Logical, not just physical views of the network (eg logical configurations of head-end equipment that ties back to the network termination devices in a customer premises)
  2. Cable joint layouts showing current state and proposed state after jointing works have been completed
  3. Using OSS cable trace toolsets (eg Remote Fibre Test Systems – RFTS) to indicate estimated cable cut locations (although you don’t really need AR to show where a cable has been cut when you spot a massive yellow digger and a sheepish looking operator in the proximity of the fault)
  4. Visualisation of the names of cables and perhaps even the impacted customers or other service data on each cable strand when opening a cable joint
  5. Allow techs to relay field work conditions to the design team so that they can make on-the-spot modifications to designs and/or OSS data that reflects the real site conditions. An example could be a tree that prevents an aerially strung cable being installed in the location the designers had originally specified
  6. Allows techs to see the actual designs that are recorded in OSS tools, as opposed to the slightly earlier design that was printed out with the work package (ie before some other designer made unrelated changes in the area where the tech is working).
  7. Visualisation of communications assets in three dimensions when working on riser cable and network devices on multiple levels of a data centre, high-rise building or segregation of assets in a multi-tenant building

In fact, I shouldn’t even limit the perspective to outside plant. Areas that have a high density of physical infrastructure, such as the many racks and cable looms that exist inside exchanges / data centres, are also prime locations for AR.

For example:

  1. Tracing a cable route through the complex cabling looms in a DC
  2. Showing an overlay of key information (eg alarm status) above each rack
  3. Showing design / topology configurations for a piece of equipment
  4. Showing routing or far-end connectivity coming from a physical port (ie where the cable ultimately terminates, which could be in the same DC or in another state / country)

I’m sure you can come up with a lot more!

Where to from here for OSS growth?

Entrepreneurs and their small enterprises are responsible for almost all the economic growth in the United States.”
Ronald Reagan

Speaking with many of the large OSS vendors, it seems that the tier-one Telco and Utility market is still their prime sales and marketing focus, not to mention their product development focus.

Interestingly, I wonder whether this is the ideal market to be targeting, for the following reasons:

  1. Tier ones already have significant suites of OSS so vendors will tend to fight for only sub-sets of the customer’s total OSS when the opportunity arises
  2. Having large suites of OSS tools means that integration is more of a challenge
  3. The same is true for data and processes
  4. Most other vendors are also targeting this market, so they are almost all either looking to beat you to signing a new contract or scheming to usurp you from your existing contract
  5. Tier-one revenue streams are diminishing, as is their ability to fund mega-OSS-projects (refer to “Eroding profitability“)
  6. Tier-one carriers are in a war with OTT providers, so the carriers are looking to their OSS to make them nimble enough to compete. This leads to significant expectations that are difficult to live up to on large OSS projects due to the integration, data, process and people constraints listed above
  7. Tier-one operators tend to have a wealth of experience working on OSS, so they are more sophisticated in their dealings. This is a double-edged sword. They can definitely be more helpful when assisting OSS integrations (eg data migration, data mapping, data collection, process mapping, etc) but that knowledge can also become pedantic and slow a project down (eg requirement capture, specifying / approving contracts, document approvals, etc)

Naturally each carrier and vendor has different strategic advantages and capabilities within their segments of the market so I’m acknowledging a very generalist view above.

There is another segment of the OSS market that is barely serviced by traditional OSS providers because the price points are too high. I spoke about it in an earlier post entitled “Scarce Resources.”

As more small to medium to large enterprises become e-businesses, a correspondingly greater number have a heavy dependence on their IT and networks for revenue. This implies that they also have a much greater incentive to monitor and manage their IT and networks. Combine this with technology trends in virtualisation of IT and networks leading to greater proliferation and potential for change and you have a much bigger market opening up for OSS toolsets.

The problem for most traditional OSS providers is they don’t have the pricing models or business models to support the smaller end of town. In many cases, these customers choose open-source or enterprise tools that don’t necessarily provide the level of support and/or functionality that they are seeking.

It’s definitely the long-tail model of OSS sales, but I can envisage a greater amount of innovation and growth from this segment of the OSS market.

I also envisage the following as key requirements for this type of customer:

  • A single vendor / product for the whole of the organisation’s estate (ie alarms, performance, configuration, inventory, etc) rather than having to integrate a suite of products
  • Ruthlessly simpler, cut-down functionality rather than all the bells and whistles. Afterall, these types of networks are probably run from customer spreadsheets currently, so any consolidated OSS toolset is an improvement
  • Programmatic interfaces to provide the flexibility for customers to adapt their OSS to their custom needs if they can justify their own set of cost benefits
  • Easy access to training programs
  • Easy access to documentation
  • User communities / forums to self-support
  • Price-points that start very low and scale significantly
  • Easy access to support services
  • Possibly based on cloud infrastructure so that the organisations don’t have to own and support their own infrastructure
  • Market segment diversification means support for a larger number of industries and languages (refer also to “The OSS world moves Eastwards“)
  • The networks under management are more likely to be IT in nature (ie Ethernet, virtualisation, VoIP, etc) as opposed to traditional Telco technologies (ie SDH, TDM, etc)
  • Unlike the carriers that have assets spread across large geographies, these customers are likely to have a smaller number of locations, but may need three-dimensional spatial representation of their assets (ie multiple levels within a building or row-racks within a data centre space)

Oh. Perhaps a couple of interesting caveats too though. I’m not saying that all tier-one OSS investments will dry up. I’m just not expecting as significant growth as from blue-ocean strategies. The following are just two examples of where major OSS spend will be necessary:

  1. We are reaching a Massive Inflection Point that I believe will soon turn many existing OSS into legacy / obsolete technologies. If so, the carriers will need to invest heavily to install next-generation OSS. Even if not, some of these big network changes will bring about the need to invest in OSS upgrades
  2. Services and customer-service will become differentiators amongst telcos, but being more nimble in these areas will also help to combat the OTT threat, so big OSS investments are likely to occur here from carriers.

The multi-utility model

Many connection providers use outdated manual procedures for design, sizing, costing and build rather than embrace new technology.
Few companies have so far adopted a GIS-driven (Geographic Information System) approach to design and build that allows more accurate designs more quickly and can inform other processes such as sizing, costing and overall customer service
Davis Langdon

In yesterday’s blog we discussed the Everything of Internet (EoI) and how this model could support other utilities to become telcos as well (ie multi-utilities).

We’ve also spoken about how the OTT (Over the Top) players are skimming revenues off the old CSP business model and even how one research organisation is predicting up to $172B in revenue loss for CSPs in coming years.

One of the many reasons why CSPs find it difficult to compete with OTT players is in the CAPEX outlay required to build and operate a fully-fledged communications network as opposed to the OTT organisations, whose traffic tends to depend heavily on the data networks of the CSPs.

With the EoI, the multi-utility model discussed could actually reduce the difference between the network costs of a CSP and an OTT. The utilities already have network assets in place to service their main utility (eg electricity lines, power poles, lights, etc), so if routine maintenance replaced those assets (eg lights) with new assets that were lights and wireless access points rolled into one, the multi-utility becomes a more cost-effective proposition.*

* Noting that this is a simplistic view that doesn’t include the complexities of backhaul, the assumed negligible cost differential between the old asset and the new asset with built-in wireless, the assumption that routine maintenance refresh rates are short so the old will quickly be replaced by the new and many other reasons.

Similarly, the utilities already have operational systems to run their internal networks (communications and/or other utilities)and BSS to manage their billing, so from a general view the tools and processes will just need to be configured rather than replaced hopefull.

IoE or EoI

We have a good shot at becoming the number one IT company in the world. That’s clearly our goal.”
John Chambers
, CEO of Cisco.

Cisco is certainly getting word out about how an IoE (Internet of Everything) is going to change the IT / networking world with its massive growth in networked sensors.

But I wonder whether our future of B/OSS could also be framed not by IoE but EoI (Everything of Internet)? By this, I mean if all of the sensors were actually able to become wireless hot-spots in their own right, as opposed to sensors having network links.

What if every one of a city’s lights had a built-in wireless network access point? Or water meters did? Or electricity switchboards?

If one of these utilities had the protocols / ability to cope with hand-offs between access points (when customers are mobile), develop a backhaul mechanism and determine usage on a customer-by-customer basis, we’d have a nearly ubiquitous access network to compete against the traditional telcos (assuming regulatory leeway).

A utility of this type would need their B/OSS to be flexible enough to handle dual-state management (or more), whereby it would need to manage and bill the wireless network as well as managing and billing the sensor or device network, each with their own unique needs.

Now throw into the mix the inherent ability for such a network to be spatially aware and you have the platform for even more innovation. Add to it the massive subscriber bases that these utilities already have, the brand credibility (when it comes to billing) and hence the relatively lower barrier to entry for adding further costs onto an existing bill than starting with a new CSP.

Perhaps there is a case of “sticking with the knitting” with those utilities sticking with what is their core business and not diversifying into becoming CSPs. Most utilities I’ve come across already have a network services department to service their own infrastructure, but the question becomes whether they can service external comms customers.

Irrespective of all these business model “what-if?” scenarios, would this be a big paradigm shift for your B/OSS?