What if most OSS/BSS are overkill? Planning a simpler version

What are the key features / functions of an OSS and BSS?

You may recall a recent article that provided a discussion around the demarcation between OSS and BSS, which included the following graph:

Note that this mapping is just my demarc interpretation, but isn’t the definitive guide. It’s definitely open to differing opinions (ie religious wars).

Many of you will be familiar with the framework that the mapping is overlaid onto – TM Forum’s TAM (The Application Map). A dated version (R17.5.1 in this case). This is as close as we get to a standard mapping of OSS/BSS functionality modules, although it’s now being replaced by the ODA component model.

Regardless, I still find the TAM to be widely used and familiar to many who don’t spend a lot of time staying abreast of changes within TM Forum. I also find the TAM to be a really useful guide to where OSS ends and BSS begins (or vice versa). Today’s article is going to call on the TAM again.

As you would’ve noticed in the diagram above, there are many, many modules that make up the complete OSS/BSS estate. And you should note that the diagram above only includes Level 2 mapping. The TAM recommendation gets a lot more granular than this. This level of granularity can be really important for large, complex telcos.

However, I find that for the OSS/BSS and experts that support smaller telcos, network providers or utilities, this might be overkill.

Similarly, there are OSS/BSS vendors that want to cover all or large parts of the entire estate for these types of smaller, less complex customers. But as you’d expect, they don’t want to provide the same depth of functionality coverage that the big telcos might need.

As such, we’ve developed the cut-down, simplified TAM mapping below for those who want a less complex OSS/BSS suite.

The Simplified TAM

This Simplified TAM lifts the OSS/BSS building blocks up a couple of levels:

• First with the 15 blue functionality building blocks (more details below)
• Then with the even higher-level, generalised workflows (arrows)
  • Green Arrow – high-level fulfilment flows that tend to progress downwards through the stack
  • Light Blue Arrow – assurance flows that tend to progress upwards through the stack
  • Yellow Arrow – shows the high-level network design and planning flows that tend to revolve around the network, network resources and project implementations
  • Purple Arrow – highlights the high-level billing and revenue related flows

Both of these layers are a really subjective mapping because each telco, provider or vendor will have their own perspective on mandatory features or modules. Hopefully it provides a useful starting point for planning a low complexity OSS/BSS.

Then you may ask what high-level functionality relates to each of the blue building blocks? That’s possibly even more subjective, but here are some hints:

If you’re already familiar with the PAOSS Blue Book OSS/BSS Vendor Directory, you might have noticed that these blue blocks are used for each vendor’s product capability mappings (where green circles / icons indicate the vendor provides this capability and the grey circles indicate that they don’t provide this functionality) as per the sample shown below.

.

Open API Mappings to the Simplified TAM

Many people are curious about how the TM Forum Open APIs align with functional blocks within the TAM. As far as I’m aware, there isn’t a mapping table.

The following is an indicative mapping between the functional blocks in The Simplified TAM and TM Forum’s Open APIs (which you can find here). Note that this TM Forum link is updated regularly, whereas the following mappings are likely to be updated far more sporadically. Always refer to the TM Forum link when you require up-to-date, accurate mappings.

Unmatched APIs

These are not “bad fits” per se. They are cross-cutting fits that do not have a clean single primary home in the 15-block model.