“Products are evaluated, services are experienced”
Ken Rutsky
So, what’s it going to be?
Will you have your OctopOSS in your own cage (ie on your site) – the SaaP (Software as a Product) model. Or will you rent your OctopOSS from someone else – the SaaS (Software as a Service) model?
What are the implications of each?
Software as a Service (SaaS)
SaaS is a software delivery model that sees the applications and data housed in a central location, but can be accessed from a remote location, usually via an Internet browser. Hence the solution is sometimes known as placing the applications “on the cloud”. Administration from the central location means that IT support costs are centralised (and minimised hopefully). For example, if an upgrade or patch is required to the software, it is introduced on the central server/s and there should be no need to upgrade all of the remote computers of the CSP.
In the past, CSP core systems were simply too diverse and complex to consider placing them on the cloud. This is still true in many cases, but there are certain niches that this strategy suits well.
For example, if the CSP’s business model is built around outsourced network operations and focuses primarily on retail sale of services, the SaaS model could suit the CSP very well. In this situation, the SaaS could be an “OSS-in-a-box” (on the cloud), providing all services to the CSP’s operators via web browsers. This turn-key solution offers rapid commencement and low start-up costs, which is ideal for the smaller, nimbler CSP. Another alternative is to offer specific sub-sets of the BSS / OSS on the cloud.
Another example suits even the largest CSPs. In situations where customers expect fast delivery of new services, it could be too cumbersome for the CSP to integrate the service via their giant OctopOSS. So they may choose to spin off their innovative solution quickly via a SaaS model.
It should be noted that generally the SaaS model is perceived to be provided by a third-party to one or more CSPs. However, there’s no reason why the CSP could not build and manage a SaaS solution for their internal business units.
It should also be noted that the CSPs themselves may build a business model around delivery of XaaS (ie Software as a Service, Platform as a Service, Infrastructure as a Service, and so on) to their customers.
Software as a Product (SaaP)
This is the traditional method for developing the OctopOSS. Various software products are managed internally within the CSP and offered to their staff via internal networks. In some cases, this will be via browser technologies and in other cases it will be via software installed on individual computers.
SaaP is the most viable model for Tier 1 CSPs in particular because of data security, having a customised solution to meet specific needs, service differentiation and the fundamental complexity of their existing OctopOSS.
Data security is one of the biggest issues with SaaS, particularly when it comes to the private/confidential/privileged nature of data retained by the CSPs. If the data is kept in house via a SaaP (or even an internal SaaS), then it’s protection is completely within the CSP’s control. If using a third-party SaaS provider, data migration to an alternate supplier could be a challenging prospect.
Summary
So what is the best for your CSP? It all depends on your business model. Many CSPs are finding that a hybrid approach suits them best, combining SaaS and SaaP solutions together to best suit the needs of their organisation, combining data security and complexity (SaaP) with bringing a new service faster and more cheaply to market (SaaS).
BTW. As I’m sure you’re aware, there is also XaaS (ie anything as a service), whereby other variants include:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS).
- Storage as a service (SaaS)
- Network as a service (NaaS) and even
- Monitoring as a service (MaaS).
Elements of each of these might also apply to your OSS, but that’s a different discussion entirely.