When is an OOTB OSS Not Really Out of the Box?

When it comes to OSS, the term Out of the Box (or OOTB) can be correct, incorrect and highly confusing all at the same time.

Buying an OOTB OSS is a bit like buying a suit off the rack. It exists. It has structure. It has the pockets, buttons, sleeves and lining you expected.

But unless it is specifically tailored to the person wearing it, the fit is never quite right.

In OSS, that tailoring (by the vendor, supplier or integrator) is needed to the unique “body-shape” of the carrier’s services, network topology, inventory data, workflows, naming conventions, operational / engineering rules and much more.

In this article, we’ll explore why vendors can be right when they say a solution is capable OOTB, why carriers can also be right when they say the same solution does not work OOTB, and how this confusion usually arises.

.

Lesson 1: OOTB software capability is not the same as operational readiness

An OSS vendor may legitimately say that a capability is available out of the box. The application may already include functionality, user interfaces, workflows, dashboards, APIs, reporting structures, user roles and automation logic. It’s all there, ready to go.

It’s an accurate and meaningful claim. There is already product capability that has been designed, built, tested and reused across other environments and clients.

However, this is where the misunderstanding often begins. “Available in the product” is not the same as “ready for immediate use by my business.”

Readiness for carrier-specific demonstrations and Production readiness is something else entirely.

The applications also require operational data, application configuration, integrations and alignment with the carrier’s real processes, among other things!

In other words, the suit exists. But it has not yet been fitted to the person who is going to wear it every day.

Another analogy relates to Microsoft Word or Excel. When you fire up those applications, they’re functionally ready OOTB. But until you start entering data, it won’t have the documents you need for your business already pre-generated.

.

Lesson 2: The application may be OOTB, but the data almost never is

The biggest source of confusion is the difference between:

• OOTB software and
• OOTB data

The value of OSS applications arguably depends less on their in-built business logic than on the data they ingest and act upon.

Network Inventory solutions need devices, resources, locations, services, circuits, logical connections and physical topology.
Fulfilment needs products, order types, task flows, dependencies and exception paths.
Assurance needs alarms, service relationships, topology, impact rules and escalation paths.

A generic, pre-loaded dataset can show that the software works. It can prove that a workflow can run, a dashboard can display, or a topology view can render.

The problem is that it doesn’t mean the dataset reflects a particular carrier’s network, service catalogue, naming conventions or operational experiences.

This is why both parties can feel they are telling the truth:

• The vendor says, “The capability is OOTB.”
• The carrier says, “It does not work OOTB for us…..”

The missing part of the phrase is usually “….with our data, our processes and our network context”.

Sometimes this could be subterfuge by the vendor. It reminds me of one particularly well-known vendor that is renowned for being OOTB – in the sense that the box arrives on site and two dozen engineers jump out of the box and start writing code to make their solution meet the carrier’s requirements.

More often than not though, it’s just that the vendor assumes the carrier already knows that an OSS only works once the carrier’s data is loaded and some configuration is done.

.

Lesson 3: Every carrier has a different body shape

No two carriers are exactly alike. Even when they sell similar services, they often have different technologies, architectures, topologies, legacy systems, naming standards, organisational structures and process flows.

A mobile operator, wholesale fibre provider, enterprise services carrier and converged operator may all need inventory, fulfilment and assurance. But the way those functions behave can be very different. One carrier may have highly standardised products. Another may have years of bespoke enterprise designs. Another might have highly complex product designs and bundling models.

This is the OSS/BSS equivalent of different shoulder widths, sleeve lengths and waist measurements. The product may be well made, from premium materials, but the fit still depends on the wearer.

Tailoring is not a defect. It doesn’t imply that custom code development (customisation) is required. Nor does it immediately indicate a failed OOTB promise. Often, it just means that human intervention is required (ie configuration, modelling, data preparation, rule definition and process alignment) to make it useful. These activities are what turn general product capability into carrier-specific operational value.

.

Lesson 4: A vendor demo or POC is often OOTB plus preparation

Vendor demonstrations and proofs of concept (POCs) can add another layer of confusion.

A vendor’s initial demo may look seamless, but that’s because they’ve invested huge prior effort in curating a set of supporting data that allows them to demonstrate many of the product’s features. The product may be standard. The functions may be genuinely OOTB. But the dataset, scenarios and workflows are usually shaped to make the capability visible and deliver the wow-factor experience in the hope of winning an OSS contract.

That is not automatically misleading. A good demo needs data to show off. The problem arises when buyers assume the smoothness of the demonstration proves immediate production fit.

Demo or POC data may simplify network complexity, remove messy exceptions, use idealised workflows, limit the number of service types, or avoid awkward integration dependencies. The result can be a valid proof of capability, but will almost never represent a complete proof of carrier readiness.

This is why clients should ask more precise questions. What is core product capability? What has been configured? What data has been prepared (or still needs to be prepared… by us)? What assumptions are built into the scenario? What would need to change for our services, topology, processes and operational rules?

It’s for all of these reasons that I wrote my first book, “Mastering your OSS.” It was designed to bridge the gap between what the Buyer and Seller expected / assumed upon starting an OSS transformation.

.

Lesson 5: The real value of OOTB is acceleration, not elimination of effort

The best way to think about OOTB OSS is not as an automagical promise of zero effort. It’s more of a promise of acceleration.

A strong OOTB product gives the carrier proven patterns, reusable workflows, existing models, tested components, pre-integrations and a faster starting point. It should reduce design effort, lower delivery risk and avoid unnecessary reinvention.

But it will not remove all effort completely.

The tailoring still matters. In fact, the better the tailoring, the more valuable the OOTB capability becomes.

There’s an old saying, “You get back what you put in,” and in the case of all the OSS projects I’ve worked on over the years, this quote has been abundantly clear and accurate.

The real question is therefore not simply, “Is this OOTB?” A better question is, “What comes ready-made, what needs fitting, how much tailoring effort is required and how predictable is it?”

This series of questions should creates a much smaller gap between expectations and assumptions – and thus a healthier conversation between vendor and carrier. It recognises that OOTB software can be real, while also acknowledging that carrier-ready outcomes depend on data, context and fit.

Just like a good suit, the value is not only in how it looks on the hanger. The value is in how well it fits when the buyer has to wear it (ie operate it).