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). Version R17.5.1 in this case. It is as close as we get to a standard mapping of OSS/BSS functionality modules. I find it to be a really useful guide, so 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.
For the OSS/BSS 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 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, I thought I’d provide the cut-down TAM mapping below for those who want a less complex OSS/BSS suite (with arrows differentiating between high-level fulfilment flows that tend to progress downwards through the stack and assurance flows that tend to progress upwards through the stack).
It’s 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 what high-level functionality goes into these building blocks? That’s possibly even more subjective, but here are some hints:
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
6 Responses
Hi Ryan, what’s your take on TMF’s ODA initiative and the (announced) revamp of the TAM. Is this geared towards the top 50 worldwide CSPs and will leave the tier 2 / tier 3 CSPs unimpressed?
Now that’s a loaded question! Good luck answering that Ryan. 🙂
Haha!!
Very interesting. In the partitioning between the multiple levels, which level (in your opinion) is/should be responsible for decomposition. For example we have a product view in the Product Catalog, and a service view in the Service Catalog. But which component translates between the products and the underlying services that fulfil the product. Similarly which component decomposes Services to Resources.
Fantastic question Jonathan because the diagrams don’t make the orchestration between layers clear.
Let’s look at it in layers like:
3. Product
Business orchestration
7. Service
Network orchestration
9. Resources
I’d tend to move the orchestration blocks up (ie business orchestration becomes part of Product and network orchestration becomes part of Service) in case the resources layer needs to be split into operational domains. But, they could equally be handled by separate orchestration / workflow blocks that aren’t shown in my diagram (eg if implemented using COTS orchestration products).
What are your thoughts?
Hi Roland,
TM Forum has asked me to get involved with the development of the ODA, one sub-program in particular. In answer to your question, I haven’t formed an opinion yet, but will undoubtedly get the chance to once I get a little deeper into the subject matter. 🙂