OSS implementations are never truly unique: Until you look closer

There are two prevailing schools of thought when it comes to OSS transformation:

• Some believe that choosing an off-the-shelf OSS platform means the deployment will follow a predictable path. After all, the software is proven, the vendor provides reference architectures, they’ve implemented their solution numerous times before and the manuals promise standard processes
• Others are convinced that every OSS transformation is entirely bespoke and demands a fully customised plan and solution

But here’s the reality – even if the tech stack is identical to another OSS implementation (it never is, but let’s assume it is) – the implementations will still be different.

While a majority of the implementation will look reassuringly familiar to prior projects (let’s say ~75% commonality), it’s the remaining 25%, which is shaped by your organisation’s structure, ops models and unique ways of working, that will ultimately define success or failure. Knowing when to embrace consistency and when to design tailored approaches is the hidden skill that separates smooth OSS transformations from costly overruns.

.

How Much of Your OSS Implementation Is Actually Standard?

One of the most common misconceptions in OSS programmes is the belief that every client’s environment is so unique that no shared patterns exist. At face value they are, which is the reason why most people assume they are.

In reality, most modern OSS platforms have evolved to solve the same core problems: inventory management, service orchestration, fault monitoring, performance analysis and more. In addition, most of these products have evolved to perform the same key functions (more-or-less). These functions are supported by a rich ecosystem of standard processes that have been shaped by decades of telecommunications practices.

If you work at the details level (and every project must), every implementation looks different. If you abstract a level or two, it’s remarkable how many similarities exist.

In most transformations, you’ll find that many of the workflows, data models and operational practices align neatly at a rolled-up level. For example, the process for provisioning a new service typically follows a predictable sequence of validation, activation, and confirmation. You can find 50+ of these rolled up process map examples available for download here. At a detailed level, no two network operators’s processes are identical.

We find that most transformation plans can be abstracted to the following phases:

.

Similarly, the data flows passing across integration points between OSS and BSS platforms also often follow established patterns, making large parts of the architecture repeatable. However, at the detailed level, fields, formats, exceptions, etc are vastly different between systems and required detailed mapping.

This repeatability is an asset if you know where / how to look. Once you’ve done enough OSS implementations and specifically look for patterns, it’s possible to identify commonality that allows teams to bring calmness to the chaos, clarity to the fog. To leverage reference implementations, adopt vendor best practices and accelerate delivery due to greater decision clarity.

But it’s a fine balance:

• Discounting the possibility of consistency (reinventing the wheel) or
• Believing uniformity extends to everything / everyone (read the story under the “when mastery becomes a cage” section here)

…is where projects start to slip.

.

Where Do Off-the-Shelf Solutions Stop Fitting?

Even the most mature OSS software platforms can only carry you so far. At some point, you will collide with the realities of your organisation’s unique environment. This is where the predictable / standardised gives way to the bespoke. These are the exceptions, nuances and constraints that no reference architecture can account for.

Off-the-shelf solutions tend to stop fitting in three predictable areas:

• Organisational Structures: Different reporting lines, matrixed teams and decision-making hierarchies can complicate workflow design and approval processes. Every org chart, empires / siloes and cultures are different, even if the tech stack is identical
• Ops Models: Each operator has specific ways of handling responsibilities and situations (eg incidents, provisioning services, handing over to contractors, managing customer / supplier relationships, etc). These models may diverge significantly from vendor assumptions.
• Legacy Systems and Data / Integrations: Historical integrations, proprietary interfaces and non-standard data formats often force customisation in how information flows between systems. Even something as small as different naming conventions on the same device types and network topologies can have down-stream impacts (eg process design, automations, integrations, etc)

These realities demand careful planning and thoughtful adaptation. Assuming you can force your (or your client’s) environment to fit an off-the-shelf mould is one of the fastest ways to erode trust and burn budget.

Before moving on to the next section, I’d like to share a story from my deep, distant past, which will hopefully provide some clues on how even the “identical” becomes “bespoke” when we drill into the details.

On Project 1, we integrated a particular make/model of voice switch to a vendor’s OSS for service provisioning. It required quite a bit of analysis, design and development of a bespoke connector, but we successfully integrated the systems for flow-through provisioning of customer services.

On Project 2, for a different carrier only months later, we needed to integrate the same make/model of voice switch to the same vendor OSS. Even the types of services to be provisioned were similar (DSL and ISDN services if I recall correctly).

Simple right? Just use the same connector??

Sadly not.

This particular voice switch had a provisioning guide with around 10,000 pages of different CLI commands. We’d implemented only a handful of CLI commands to activate services on Project 1 (carrier 1).

For Project 2, the voice network was set up differently, so a similar, but different set of CLI commands were used to provision services.

We could re-use some aspects of the connector (ie protocol adaptors, message encapsulation, etc) but we also needed to redesign the message structure, data model / structure (ie the variables coming from the OSS database) and exception handling for Project 2.

.

What Questions Will Expose Your Unique Requirements?

Success in OSS transformation often hinges on reflecting on past projects, looking for patterns and asking the “nuance” questions earlier.

Before committing to timelines and budgets, it pays to probe where the divergence between standard practice and your reality will occur. This is why I use top-down approaches such as the following when planning each project:

• WBS (Work Breakdown Structures)
• Mind-maps and
• Outline / strawman documents

When attempting to identify the nuances, consider starting with questions like the following:

1. What worked well on the past project and what hindered us?
2. What was common in our work breakdown in similar past projects?
3. At which level do the business processes in our organisation start to look similar to past projects and/or deviate from industry-standard workflows?
4. What cultural factors or legacy practices could conflict with the default solution design or work breakdown for this project?
5. Who holds informal decision-making power that could impact adoption or configuration choices?
6. How different is this Org Chart and/or Ops Model and/or Project Champion Structure to past projects?
7. Which integrations with adjacent systems are non-negotiable or unusually complex?
8. What compliance or regulatory constraints require deviation from the reference architecture?
9. Whilst the starting-out point might look similar, are there future divergence of vision?

By using these questions as a lens, you can quickly identify the areas that need special treatment – and prevent last-minute surprises.

.

How Can You Balance Repeatability with Adaptation?

Once you know where the 25% of uniqueness lies, the next challenge is blending it into the predictable 75% in a structured, manageable way. This is where many transformations either succeed gracefully or become sprawling programmes that overrun both timelines and budgets.

Here are three principles to help you balance standardisation with adaptation:

• Simplification / Pragmatism. Protect the Core: Resist the temptation to customise standard workflows unless there is a clear business justification. Preserving the integrity of proven processes avoids unnecessary complexity. Use pragmatic workarounds where possible. Remove “baked in” business logic wherever possible, allowing flexibility in data / analytics instead
• Create Flexible Adaptation / Edge Layers: Design integration and orchestration layers to absorb the unique requirements without contaminating the core product configuration
• Document Exceptions Rigorously: Every bespoke decision should be captured, justified and reviewed. Clear traceability helps control scope creep and informs future maintenance and upgrades

This balance doesn’t happen by accident. It requires a governance model that empowers teams to innovate only where it truly matters. It’s also one of the reasons I like dealing with the pragmatism of T2 operators rather than the “build or customise anything and everything” approach that some T1 operators take.

.

Learnings?

After delivering or advising on around 80 OSS deployments (and counting), some lessons repeat themselves almost without exception. These insights can help you avoid the most common pitfalls:

• Reflect on past projects to develop repeatable methodologies: At the completion of a project, most implementers don’t have time (or aren’t incentivised) to abstract their learnings into methodologies that can be re-used or refined for future projects. At PAOSS, we’re constantly defining and refining our approaches, leaving us with a library of methodologies for different types of projects (many of them shared here in the blog). The confused mind says no. Clear and concise methodologies help to remove stakeholder confusion
• Assumption is the enemy of clarity: Never assume that because two organisations use the same platform, they can share the same configuration or implementation approach without adjustments
• Customisation is cumulative: Every exception increases future maintenance overhead. Treat each one as a strategic decision, not a convenience
• Change management is often an afterthought: Change management isn’t a 2 week training course just prior to go-live. Even the best technical implementation will fail if operational teams don’t understand, buy-in or accept the changes
• Data migration complexity is always underestimated: Legacy data is rarely clean or complete enough to support a “lift and shift.” Even if data sources are identical, the data formatting (eg naming conventions) often lead to implementation differences
• Clear ownership accelerates delivery: Unclear roles and governance slow down every decision about configuration and adaptation. We use RACI colour-coding on our transformation WBS charts to help show ownership, demarcation and hand-offs in responsibility

.

Bringing It All Together

It’s tempting to choose one narrative or the other: that OSS transformations are either entirely standard or entirely unique. The truth, as always in OSS, is somewhere in the grey areas in between. Off-the-shelf platforms exist because most operators share the same fundamental challenges. But the nuances of your environment, from governance structures to cultural attitudes and legacy data, will always shape how your implementation unfolds.

If you want your transformation to succeed, build your roadmap around a few guiding principles:

• Use top-down and roll-up thinking to identify higher-order patterns
• Seek out and embrace what is proven and repeatable
• Invest time upfront to uncover the remainder that needs bespoke attention
• Use structured questions to drive clarity and alignment
• Govern customisation and use pragmatism rigorously to avoid complexity spiralling out of control
• Never underestimate the power of change management in bridging the gap between standard processes and the real-world behaviours of your teams

In the end, success comes not from choosing sides but from understanding how to blend the predictable with the unique…. all with an eye on the challenges that lay ahead.

But we’re happy to admit that there’s still so much to learn from this OSS transformation caper! What core principles and approaches do you rely on to bring calmness to the chaos? What complexity reduction and repeatability insights do you have worth sharing? Please leave us a comment below.