Best-of-breed or Single-vendor Implementation?

Striving for perfection is the greatest stopper there is. It’s your excuse to yourself for not doing anything. Instead, strive for excellence, doing your best.”
Sir Laurence Olivier

So, what is it going to be?
Is your OctopOSS going to be built using the “best of breed” approach (ie the best available product) for each aspect of your OSS (eg Fault Management, Performance Management, Inventory, etc)? Or is it going to be the “OSS-in-a-box” solution that has many pre-integrated functional components supplied by a single vendor?

Best of Breed
These are the tools that are stand-out market leaders for a specific segment of the OSS market. Using this solution allows a CSP to choose the best available tool for each component of their overall OSS (and for individual use-cases and/or persona groups). The major benefit of this approach is that the vendor that isolates on a single segment is likely to have a great depth of capability in this area because they don’t have to spread resources thinly across a broad set of segments.

However, this means that the overall solution consists of a jigsaw puzzle of different vendors and tools, all requiring custom integration (assuming pre-existing connectors aren’t available between certain tools). It also means the CSP will have to deal with multiple vendor relationships and develop processes that can identify clear lines of demarcation of responsibility. Integration of separate products introduces interdependencies that didn’t previously exist. So now release and change management become more complex after the solutions are introduced into the production (ie live) environment. Also architectural governance becomes more complex with the more separate products and integrations you introduce.

It should be noted that the “best of breed” could mean the best available for the given CSP given the constraints and requirements they have. Their best of breed may actually be an open-source tool if their budget is limited and/or they want/need to do in-house customisations.

The single vendor approach makes vendor relationship management (VRM) simpler from an ongoing relationship perspective. However, this “vendor lock-in” can be much more difficult if the CSP becomes unhappy with the performance of the vendor or its products and wants to change to a different vendor. It also identifies a single point of contact and responsibility, simplifying demarcation (ie the break-down of responsibilities between vendor and CSP).

When writing this entry, there were no vendors who could claim coverage of every segment of an OSS (eg all boxes on the TM Forum TAM map). However, there are a few that can provide enough coverage to deliver an OSS-in-a-box solution, even to some tier-one carriers. The single vendor approach suits the CSPs that wish to have a standardised, simplified OctopOSS and not worry about cross-platform integrations.

This single-vendor strategy is usually better suited to tier 2 or 3 carriers, utilities (eg electricity companies with communication assets) or other service providers. Many tier 1 carriers already have an array of tools / use-cases and tend to only supplement with a new best-of-breed product.

Integrators often have the ability to combine the best of both worlds. Assuming the integrator has the freedom to choose from any products on the market, they can create a single integrated solution from the available best of breed solutions. The CSP also has a single point of contact, simplifying VRM. Assuming no contractual barriers, the CSP also has the ability to change products and service vendors where required. This is the ideal world, but many integrators are bound by relationships to use partner products rather than the true best of breed. But on the upside, the integrator partnership model also often means that inter-product integration has already been developed, reducing time, cost and risk to the CSP.

Factors to consider

Other factors that you should consider with either of these approaches are:

  • What is the scalability of the solution?
  • What is the product development roadmap (a single-vendor approach will mean that development effort has to be rationed across all products in the vendor’s suite)? Does this rationing mean your TTM (time to market) of new functions / services is impacted?
  • How much integration will you need between the “best-of-breed” solutions? As the name suggests, each of these products are outstanding within it’s own OSS domain.  But will cross-domain integration enhance and enrich your experience (eg integrating alarms with inventory to provide alarm enrichment)?
  • What is the vendor’s propensity for custom development (assuming that you need particular functionality that isn’t in their current core functionality)?
  • Do you need additional architectural building blocks to support best of breed (eg enterprise service bus [ESB], common data stores, etc)?
  • What are the costs (up-front, integration tax, on-going, annual licensing)? Take total cost of ownership (TCO) into account when comparing models
  • Have you looked beyond the realm of network operations? How does the proposed solution cater for the needs of other parts of your organisation (eg marketing, sales, regulatory, products, finance, legal)? How does your OSS help them or perhaps from a different perspective, how easily will it integrate with their support systems and processes?
  • How does the proposed solution cater for ongoing operations such as adding new products / services, changing workflows, adding new device types, etc?

So what is the best model? Like many OctopOSS dilemmas, there is no “one approach fits all” solution and it depends on the CSP’s specific needs. Each of the three different models suit different situations. Ultimately it comes down to which is best suited to your particular needs.

Let’s use an example. Let’s say that a single vendor’s solution covers 95% of your needs and is much cheaper because the integration tax is significantly lower, but unfortunately its functionality doesn’t cover one of your most fundamental use case requirements. If that vendor isn’t willing to develop the essential functionality, then can you select them?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.