BSSaaS: Making the cloud work for you

BSSaaS: Making the cloud work for you In his second blog exploring Business Support Systems as a Service, Richard Doughty analyses the key requirements for ‘cloud BSS’ and looks at the practical implications for CSPs choosing to go down this route.
 
In my previous blog It’s BSS Jim, but not as we know it we looked at the cloud and what Communications Services Providers (CSPs) mean when they are asking for cloud Business Support Systems. This week we’re going to look at those requirements in some more detail and explore how they apply to the way a CSP uses its systems.

 
Evergreen software
 
The nature of traditional BSS projects has meant that customers are nearly always one version behind the latest release; a project starts, takes 12-18 months to complete, and in the meantime the vendor keeps up their R&D and a new product version is released. So the desire to find a way to remain on the cutting edge is understandable. However, there are reasons why ‘evergreen’ works with more simple applications and is less well suited to the mission critical systems of larger telcos.
 
The evergreen model requires a true single version of the platform. And whilst many BSS vendors (Cerillion included) offer a pure product kernel approach it is common to most implementations of this kernel that the customer has their own bespoke interfaces (network, workforce management, inventory/fulfilment, etc.) and also sometimes their own specific customisations.
 
In a true cloud (SaaS) model, new software releases take place at a time of the vendor’s choosing, with staged rollout to sandbox environments providing a window for customers to familiarise and test integrations prior to the live cutover. This is fine for smaller businesses and niche applications, however it’s a whole different story for large telcos that are used to controlling the release of software into their production environments.
 
Mandated upgrade and outage windows don’t always work for large CSPs providing 24/7 service to their customers so this maintenance schedule can’t be applied to everyone, it needs to be on a customer by customer basis.
 
The super-lightweight interface
 
The browser has become the de facto front-end for many enterprise applications and telco BSS solutions are no exception. The main difference between native cloud applications and traditional BSS is in the use of the browser real-estate and here we’re seeing some of that top-down meets bottom-up between cloud and BSS.
 
Most SaaS applications started in a very minimalist Web 2.0 manner, with nice clean lines, lots of white space and a sexy look and feel. Whereas BSS has traditionally been the complete opposite, with lots of information and functionality to squeeze into the viewing area in order to speed up user response times. But as the functionality in many SaaS platforms has broadened and as the BSS vendors have done what they can to make their platforms prettier and take advantage of new UX design techniques, nowadays there’s often not much daylight between the two.
 
The cloud money-model
 
SaaS is synonymous with a straightforward monthly fee and often when we’re asked about our cloud model it is this that is at the forefront of the enquiry. This is in contrast to traditional large telco implementations that are known for being CAPEX heavy, though the concept of vendor finance or deferred payments is not new.
 
What often comes hand in hand with this request is the cloudesque delivery that’s expected within a monthly fee. Not only the implementation, but also the third party costs (hardware and database), the hosting and availability, and also the running of the platform itself. And this last piece is something we’re seeing more and more – running the platform on behalf of the CSP.
 
A common experience of cloud software is that “you just use it” and don’t have to worry about the underlying system housekeeping which is all taken care of for you. So with BSSaaS it becomes increasingly a managed service delivering the end user the functionality of the BSS without the CSP being required to retain systems administrators or DBAs, and also ensuring that critical revenue management processes such as charging, billing and payments ‘run’ as part of the package.
 
So this cloud model can in fact involve not just spreading of the CAPEX component of a project, but an overall, monthly price per ‘sub’ for delivering everything a CSP needs to run their BSS operations.
 
It’s in the Cloud!
 
Typically a SaaS platform is remotely hosted somewhere and until a few weeks ago many people looking for a SaaS platform didn’t give too many thoughts as to where actual, physical servers might reside. However, with the recent Safe Harbour ruling and increasing focus on security breaches, hacking and data protection, this is becoming much more of an issue. 
 
And it is possibly on this point more than any other where the requirements for BSS and that of a pure SaaS market diverge. No matter what other cloud requirements a CSP has requested, the one on which they all agree is ‘Private Cloud’; so on their own servers in their own data centres. When you’re handling that much sensitive customer information and you probably own and run a gaggle of data centres housing your network equipment, it’s not a problem throwing a few more blade centres in to the mix for the comfort and peace of mind in knowing where your data is actually stored.
 
Added to this come the High Availability and Disaster Recovery requirements of mission critical systems that nearly always mandate a replication of kit, it’s no surprise that there remains a strong desire to retain physical equipment within a room to which the CSP still has the key.
 
Conclusion
 
The cloud concept is one of a simple service and predictable cost; no hassle and easy to understand. Large software projects delivering systems that are the bedrock of high-value companies are not simple, but they are still a service and there are several aspects of the cloud model that are desirable, achievable and applicable to BSS deliveries. Some vendors are already able to offer most of these options and the key to a CSP getting what they want is to be specific on the aspects of the cloud model that they believe are most important for them and the way their business works.
 
Find out more about Cerillion Enterprise, Cerillion Skyline and our Managed Services offerings.