OSS and BSS has traditionally been where IT meets telco network – two often divergent sets of technologies and two different engineering cultures working together. So historically that’s not been the easiest interface to oversee. The OSS/BSS world, which sits on the IT side of the join, has traditionally been seen, indeed has seen itself, as slow-moving, expensive to tinker with, often quite proprietary, and ultimately exhibiting whatever the opposite of agile is. So the question is: where does OSS/BSS fit in to the telco transformation picture? Will it be a boat anchor or, as its proponents suggest, a critical component engaging with the NFV protocol stack to provide the service catalogue necessary to turn NFV capabilities into those much anticipated, fast-to-market new services?

 

Operations or Operational Support Systems (OSS), and, especially, Business Support Systems (BSS) are the computerised descendents of card indexes and paper files against which telcos used to bill their customers and keep records – they might be described as generating ‘Little Data’.

Not any more of course – computers were introduced to push things along in the 1970s, computerisation was ramped up in the 1980s and 1990s and, partly because of the necessarily ‘non-stop’ nature of the network, the applications tended to be siloed – one system for each operations or business function. There ended up being lots of them.

 

Operations or Operational Support Systems

The main OSS applications involve network inventory, service provisioning & activation, network configuration and fault management; along with network management, service assurance and customer care.

 

Business Support Systems

Business Support Systems (BSS) deal with the revenue generation side of things: taking orders and issuing bills. BSS therefore more or less supports four processes: product management, order management, revenue management and customer management. So managing products, their prices, their discounts and their bundling; issuing bills and collecting payments and billing systems, and doing all this in real time, is what BSS is all about.

The important thing to note (one of them) is that OSS/BSS is hugely data-profligate. All those call minutes and data volumes to measure out in real time; all that data to store, database hardware and expensive software licenses to pay for (Oracle is often mentioned in this context), then there’s roaming data, data recording the downtime for specific customers (and how much penalty will have to be paid) and much more.

All in all it’s easy to paint a picture of huge complexity and therefore of expensive BSS and OSS overhead for the world’s telcos and there’s probably more data and more complexity on the way with next generation services, in particular 5G.

It’s also important to understand that a good proportion of this data is still be effectively siloed – existing under different systems, different vendors and different databases – and that’s still a major problem in today’s highly competitive telecoms market where every call detail record has to be rated and deducted from a plan – in real time.

 

Which leads us straight to the perennial OSS/BSS agility problem

All those silos are a pig to update and change and that’s a major reason (some would say the main reason) why it traditionally takes months (sometimes 18 of them) for a telco to introduce a new service or even an updated version of an existing service. That new service has to be carefully designed and tested before it is unleashed on the public because total reliability and 99.999 percent uptime is required from the network and, by extension, the systems which keep it operating and keep it in business. Being bulletproof is the most prized quality in telecoms, but all that armour plating makes the vehicle very difficult to manoeuvre.

This is not a new or even recently recognised problem. Long before the advantages of SDN/NFV were being extolled in terms of the agility it could bestow on CSPs, the TM Forum, the global framework-setting body for OSS/BSS, has been obsessed with telco agility (or rather the lack of it). Much of the Forum’s work had therefore been concerned with developing guidelines and frameworks which over time, and if adopted, could make the various support systems more interoperable and easier to integrate, both internally and between telcos.

How would the Forum adapt itself to SDN/NFV and the telco cloud which, in many ways, presented a real challenge to the accepted way of doing things?

After what seems like a pause for internal argument, the Forum this year signaled it was fully on-board with ‘the journey’, launching its Open Digital Architecture (ODA), building the case for OSS/BSS transformation and launching a manifesto commiting it to providing front and centre support. More recently it’s released a report, ‘5G monetization: Operational imperatives,’ which ties telco success with 5G to CSPs ability to transform their operational and business support systems.

It claims the operational silos still bedeviling the OSS/BSS should be consigned to history and services must be managed horizontally (cutting right across the old silo boundaries) on an end-to-end basis, covering everything from network provisioning, through to product creation, billing and service delivery.

The old distinctions between OSS and BSS also had to be cast aside in favour of a micro-service-based cloudified arrangement building-in the AI powered automation it claims will be essential to monetizing service differentiation for 5G.

Clearly now, one way or another the modernization, transformation, virtualisation of OSS/BSS will be key to enable the network automation, increased openness and software-driven enhanced agility that service providers now require. Despite some disgruntled “voices off” NFV itself and its progressive cloudification is the settled and accelerating direction for all of telecoms and networking – there is no going back.

So OSS/BSS is a growing market, but some bits will grow faster than others. Market research outfit, Global Market Insights says the global OSS/BSS market is expected to hit $50 billion by 2024 with other sources sizing it at around $30 billion in 2016. But the interesting numbers might be those which indicate which segments within BSS will grow the fastest. Fig. 1 shows the dramatic changes expected in Europe at least. While the bread and butter core of legacy BSS, billing and revenue management, is expected to grow modestly over the forecast period to 2024, both customer and product management and, especially, service fulfilment will roar ahead as telcos double down on driving greater network automation and reduced operational expenditure.

Outsourcing on the rise

Faced with a steep rise in complexity in the BSS domain, telcos have a range of mitigators in the toolbox. ‘Just cope’ is always one: trusting the inhouse talent to make the right decisions and perhaps even lead the internal transformation effort with a virtualized OSS/BSS. Another is to try to avoid the expensive technical engagement necessary for a full open source transformation by adopting a turnkey or ‘pre-integrated’ product set approach. Such an option was recently launched by one of the leading OSS/BSS players NetCracker. (see – TelecomTV TRACKER: Netcracker goes for the pre-integrated approach) and Comarch has another explicit BSS ‘compact solution in a box’.

 

Whatever a telco’s OSS/BSS technology choices they can always be outsourced, an option that appears to be a major trend at the moment.

Outsourcing is a longstanding option in telecoms and tends to come in waves, especially when some sort of challenging disruption is taking place. For the outsource provider it usually means a more profitable business model can be deployed with lots of nice recurring revenue, especially where open source solutions are gaining traction and margins on software solutions are being squeezed.

For the outsourcee the attractions are just as compelling. With OSS/BSS outsourced, core personnel can be pointed at service innovation and customer retention, while the OSS/BSS service provider can take full responsibility for OSS/BSS performance, with “feet held to fire” incentives to meet KPIs. Outsourcing also makes best use of telecom industry resources by enabling the outsourcer to service multiple telcos with one team.

Downsides include the potential lack of flexibility for the outsourcing telco.

However, the fact that all things telco are migrating to the cloud (OSS/BSS included) while telco functions are being virtualized, must make outsourcing a more agile proposition in itself.

 

Virtualization doesn’t mean ‘virtually’ doing what you did before

The NFV White paper implied that existing telecoms vendors could just virtualize their legacy code if they wanted to play. But the realisation soon dawned for some that the OSS/BSS would have to be re-thought completely. Simply transferring monolithic applications code onto virtual machines was not always going to provide the performance or reliability required by service providers or indeed the agility required for spinning up those new services.

The old code would have to be split up and rebuilt as cloud native applications and to be effective it needed to be done in as open a way as possible, probably using open source code.

As it has turned out, NFV and cloud native microservices are just the start. Those technologies will really start to pay dividends when the next big step is undertaken – the full-blooded move by telcos into the public cloud – after all that’s where most of the data that wants shifting is going to be and it will also offer the ultimate in low cost and scalability.

A good explanation of this ultimate progression – from stage 1 virtualization, to stage 2 microservices and cloud native, to stage 3 public cloud – was extracted by Martyn Warwick in a recent panel session at 5G World in July.

 

Next gen technologies will demand more of the BSS

5G would appear to mean a huge uptick in the requirement to monitor, bill and assure. Running multiple network slices means vast amounts of data about data needs to be generated to validate performance guarantees, bill for data throughput at different levels of quality, and so on. Whatever happens, it looks like being more, rather than less, complex to oversee.

That’s just the network monitoring, incoming records, side of the equation. In the new world of ever-diminishing OpEx and ever-expanding network automation, OSS/BSS should be instrumental in enabling provisioning, configuring, network recovery and fault-rectifying as well as fault finding.

 

Conclusion

Virtualizing the OSS/BSS functions and driving them forward via open source, DevOps and, as we have seen, cloudification, is inevitable and probably vital. If the existing OSS/BSS players can’t manage to make the leap, then the virtualization specialists already entering the telecoms domain from the IT industry will take up that role.

We’ve all seen the old scissors crossover graph where telco network costs per bit are shown to zoom upwards while telco revenues are heading down. A couple of years ago no telco gear presentation was complete without a brief re-explanation of the phenomenon. Less is heard of it now though, partly I suspect because of the vast cost-saving potential of software defined networks, automation and, public cloud computing. This has given telcos the opportunity, if they take it, to drastically reduce operational costs (cut the headcount) and scale network capacity and functions up when required. So there is a way forward out of the old telco scissors trap, but it requires imagination and a willingness to invest in OSS/BSS and next generation technology to take it.

Comarch is turning out to be one of the leading NFV/SDN, cloud-oriented OSS/BSS players. That’s quite a complicated mouthful but it does at least indicate the scope and complexity Comarch and its customers face as they navigate the transformation journey together.

The task for Comarch, and the OSS/BSS industry generally, is to transform their offerings to mesh with the transformation path being taken by the CSPs with their adoption of what we might roughly bracket as SDN, NFV, microservices and cloud. Not just at the technical level, but at the customer relationship layer whose transformation may be the most crucial aspect of all.

OSS/BSS applications no longer just ‘support’ the people running the network (as the term implies) but these applications now define the network and its services. Comarch’s approach is therefore to build its SDN/NFV solution on top of its OSS suite so as to support a hybrid network dealing in both VNFs (virtual network functions) and PNFs (physical network functions), with the OSS essentially being the integration engine which enables the network’s gradual technical transformation.

Comarch has been working with the TM Forum for the last few years and has signed up to the TM Forum Manifesto. One of the company’s lead customers is the Innovative global Enterprise network platform ngena (Next Generation Enterprise Network Alliance) which has adopted Comarch’s software to provide a BSS/OSS solution including network inventory, product & service catalog, assurance, CRM and self-service portals.

 

Ian Scales sat down with Dominik Pacewicz, Head of BSS Product Management at Comarch, to talk about what Comarch is doing right in a rapidly changing field.

 

I asked him to differentiate Comarch: what makes it different?

 

All our software is organically developed in-house and we do both the selling and the integration work.”

This is the best way, he says, and the key advantage for both Comarch and its customers is the closed loop involving close cooperation for the benefit of both parties.

Once you include hosting services, which is increasingly becoming cloud-based, the partnership becomes even closer, he says. It means that things like a customer’s day-to-day maintenance and configuration can be done jointly with the Comarch team. Another advantage with this approach is that CSPs can get more hands-on experience. More on this later.

 

One of our differentiators is our toolkit approach,” claims Dominik. “This means the customers can do a lot with their own hands. At the same time we have to simplify lots of things to avoid costly code changes. So we let our customers model different entities in the system and, based on the models, the whole system knows how to behave.”

 

The models operate in a ‘top down’ manner and the same models are applied to both OSS and BSS.

This enables us to shorten our time to market,” says Dominik. “The models are understood by all the processes that exist in the system, so when launching a new product or service, the order manager (part of the BSS) knows immediately how to capture all of the data. It’s then decomposed slightly and applied to the OSS layer so that we know how to fulfill it.”

 

The big pay-off is that you do it once and then you can re-use the resulting process solution in a variety of ways on other, related projects. It all leads to a better time to market while at the same time supporting ‘innovation culture’ since customers get to experiment and play about and to construct new service ideas.

 

Roles and relationships on the move

What came through strongly in our conversation was that the most profound change, with the onrush of open source, virtualization and DevOps, is to do with relationships between BSS/OSS vendor and telco customer.

Working closely with customers is important in the new open source environment,” says Dominik.

And it’s not only because the traditional vendor/customer relationships are shifting, but because relationships within telcos are changing too.

 

One of the reasons the OTTs were able to disrupt the market with their new business models is that the business and the technical folks were sitting next to each other and were cooperating very closely,” he says.

The telcos have clearly seen this and are aiming to emulate the OTTs by getting involved in open source groups and, of course, developing their NFV virtualization effort. The new focus is leading to much more internal cooperation with the old barriers between the business, network and IT sides of the house coming down.

So Comarch has been migrating in the same direction as the telcos. It’s been removing expensive middleware and replacing costly database licenses with cheaper (but not less reliable or lower performing) alternative solutions.

 

Migration is a challenge

About four or five years ago Comarch adopted the Microservices approach for its own software. Microservices, Dominik explained, have been adopted extensively by the big OTTs – eBay, Amazon etc – to increase software agility. The idea is to take the functionality contained in a traditional software ‘monolith’, in this case an OSS/BSS application, and break it into smaller pieces of software to compose a suite of very small services – all modular and independently deployable. The resulting system is easier to build, easier to change without bugs rippling through the entire ‘monolith’ and, crucially, it’s a software approach that supports DevOps and collaboration.

 

The benefits of the microservices approach include microservice re-use and cost reductions both for us and the customer,” says Dominik. “It enables us to join the same journeys as our customers – all of us are transforming, we just have different challenges and our journeys started in different places.”

 

Moving to Microservices and DevOps sounds like an obvious step, but it’s not the easiest process to execute.

It involved the entire R&D team that we had at the time,” says Dominik. “You have to slice your solution as thinly as possible and it’s a real challenge. You have to change all the internal processes, decompose them into smaller pieces of software and then reconstruct them as services. That meant changes to everything: from our day-to-day routines to the way we tested and deployed the software: it all had to be in line with the DevOps and microservices approach.”

 

How important is DevOps?

It’s become a must because telcos want to have a hands-on experience on the software they’re using. Again, what really makes it work is its ability to bring together the IT and business sides of an organization. You can put experts from different domains together in a DevOps team and they can collaborate in a much more effective way. It’s a much smarter and more agile way of working than any other approach we’ve seen in the past.”

But you need a culture around it that supports fast delivery, continuous integration and new ideas, fail fast and so on.

Comarch has many joint DevOps teams working with customers and it’s working well, says Dominik.

We don’t expect our customers to change our code but we have our powerful toolkit so we can create sandboxed applications to validate their ideas and then, as long as the final idea meets the customer’s approval, we can move quickly to a production environment. We couldn’t do that without the powerful toolkit we have.”

 

What we’re also seeing is that our customers are wanting to get their hands on the software before they even know what their target business models are. They say to us, ‘Just come, just do the training and leave us the software and we’ll find out what we can do with it.’ We think that’s a unique approach for us.”

 

Intimate customer relationships

We see an increasing demand for knowledge transfer as part of the migration towards open source and DevOps,” he says, “which means we meet to support each other much more often than we might have done in the past.”

 

The roles at the customers have also blended. For instance the business guys are now often interested in doing things with the software – it’s so easy to use that even business people can do lots of different configuration steps themselves.”

 

With all those close customer relationships, the next step could be to host CSPs’ OSS/BSS applications. Where is Comarch on this business model?

 

In fact, this is exactly where we’re heading,” says Dominik. “The way customers can use our solutions is very flexible: they can be installed on the premises or on private or hybrid clouds using public cloud facilities.”

 

Comarch is building an enterprise cloud solution to serve all its customers (not just OSS/BSS) in its own data centres as a cost-effective alternative to the biggest public cloud providers. This Comarch private cloud has proved to be a highly successful OSS/BSS offering. Dominik says most of Comarch’s customers are already hosted there using the company’s software.

As of today, more than 300 million subscribers in Europe are served by Comarch’s BSS/OSS running on our Cloud,” he claims.

 

In fact the board has decided that we’ll move all the portfolio and all the customers to the cloud environment in the next few years. Eventually,” he says, “it’s going to be the only way to get Comarch software.”