The Future of SaaS for CSPs

The evolution to SaaS will require CSP’s to change the way they do business. Nokia’s Mark Bunn says it’s a tectonic shift for telecom. It's about demonstrating value that's going to keep your customers coming back. That's the lifeblood of any SaaS business.

Below is a transcript of this podcast. Some parts have been edited for clarity.  

Michael Hainsworth: The telecom industry isn't migrating to 5G. It's evolving to 5G, and that requires a wholesale change in the way communications service providers do business with their enterprise customers, and how those customers interact with their own. The move to Cloud-Native isn't just for the radio access network. It's for the customer as well, and Mark Bunn says the days of customized, siloed software solutions for them are over. Software as a service, isn't new for most industries, but it is for telecom. It requires new thinking, new business models, and a willingness to act like a startup by moving fast and breaking things. The Dallas-based senior VP of SaaS business operations at Nokia tells me, SaaS is a tectonic shift for telecom.

Mark Bunn: SaaS clearly is a mainstream concept in most industries, but yet in our industry, in the communications industry, it's yet to be widely deployed. Instead, the telecom industry today is largely dominated by, on-premise, customized software deployments. That's likely influenced by our heritage and the highly hardware-intensive nature of our industry. However, in recent years, the hardware itself has become smarter. As the software has become more prevalent in those hardware devices. Then gradually we've segregated. Sometimes we like to use these fancy words like disaggregated the software from the hardware. While it's true, that we still require hardware deployments for certain types of communication services today, our software is reaching a state in which it can be hosted literally anywhere. This steady evolution, it sets a stage for what I consider a major paradigm shift for communications software to be provided and consumed in a SaaS, software as a service delivery model, which is quite different from the way software is delivered today in our industry.

MH: The steps communication service providers have to take to offering software as a service. They need to be incremental though. We can't just jump right into this blindfolded. What are some examples of software as a service, a telecom provider, like a Nokia, or a CSP, like a national wireless operator, should be offering enterprise customers?

MB: Yeah, that's a good question. I think maybe start with the recognition that software as a service isn't new. Like I said before, it's mainstream in other industries. There should be no reason for us to stub our toe, so to speak, on the challenges that others have already overcome. It's important that the providers, when they think about software as a service, and they think about how they're going to consume, so how they would receive it or what they would use from a vendor like us, Nokia, or how they would offer a service to their customers, that they do so, very deliberately. As you rightly said, Michael, incrementalism I think is really important here, terminology that you're going to hear me use from time to time, as crawl, walk, run. I feel like that's, that's where we are in our industry.

We should be transitioning deliberately. We should look at some of the former experiences that we had, learn from them, like NFV, network function virtualization, where we tried to apply a one-size-fits-all approach. It didn't really work, but it worked for some particular use cases. In this case, I think we need to do the same. For me, I think you start by defining a multi-year journey. Think of this as the long game, not a short game and start with applications that have a natural affinity for a SaaS deployment, such as analytics.

Our customers are asking for analytics applications today from Nokia. Our customers customers, enterprises, would be asking for analytics packages from them. Analytics is just a natural place I think to start with a SaaS deployment. Some of the others to consider would be in the areas of security and threat management, which will be increasingly popular as we continue to go through this whole evolution of software and what that implies.

Some of the more tricky bits. The systems of record. What we have historically referred to in our industry as our BSS, our business support systems, and our operational support systems, OSS. Those will become SaaS over time, but there's so many on-premise'd, highly customized deployments that are in use today. I think as those become SaaS offerings, they really should be focused on probably new business lines. You know, maybe an IoT business line to start. Eventually, I think consolidation of those systems of record into SaaS offerings would make sense, but I think there will still be some challenges, just because of how we have historically got to this point. In summary, incrementalism probably does apply. I think there could be some radical shifts in certain areas where SaaS just simply makes sense. Analytics is one that's top of mind for me.

MH: Well, as you say, incrementalism is important, but you've also said, we shouldn't have to stub our toe trying to deploy a SaaS environment, and I suppose because the industry has experience in managed services, there is some comparable and relevant internal knowledge that can be applied.

MB: Yeah, absolutely. We do have a strong capability, the vendors do, and even the industry does, have a strong capability in managed services. I see managed services as one vehicle to get us to SaaS, in fact I see managed services even benefiting from SaaS. There are some similarities, as well as some differences. When I was making the reference about stubbing the toe, I think it's important just to look outside of our industry. Sometimes I think it's human nature to be too inwardly focused.

A lot of companies have gone through this transition. They've written books on it. About what's good, and what's bad, and what's ugly, and let's not ignore their experiences. They're easy to really internalize for ourselves. All I'm saying is, let's look over the fence and let's take a look at what some of these leading companies have done, when it came to their transition to SaaS, whether they be ones that adopted SaaS and started to move from more of an on-premise model to SaaS model, or companies that offered SaaS, or companies at one time offered an on-premise model, that was their predominant business model, and then they made a change to software as a service. Those experiences are widely available. We should take a look and understand them, and understand what constitutes good mature software as a service offering.

MH: Through our conversation today, we're not just talking about players like Nokia providing software as a service to CSPs, but also CSPs providing that SaaS to their clients. What kind of margins should a CSP expect when it's offering SaaS to its enterprise clients?

MB: One of the characteristics of a mature SaaS offering is that you're able to provide, I'm going to use the word framework very broadly, but basically provide both a technical and commercial framework, with essentially a unified way of delivering the service, and then so in a highly automated way, such that we're moving further away from our standard operating procedure, SOPs and MOPs heritage, that really has infused this, this industry for some time.

MH: Definition, Techopedia describes a MOP as a method of procedure, a step-by-step sequence for performing an operation. It tells the maintenance and operations technicians, how to execute the actions in order to perform an operation. A SOP is a standard operating procedure, the step-by-step set of instructions to help employees carry out routine operations efficiently, consistently, and within industry regulations while reducing miscommunication.

MB: We're replacing a software. Essentially, software is driving software, and it's that automation software that is enabling us to be able to deliver capabilities faster, to upgrade on demand daily, hourly, if necessary, to test new markets. To provide new products to market much more quickly than we could ever do before. As a result of that velocity, and then the ability to start to pull some of costs, that were really an impedance to us, to being able to scale out of the business. What we see naturally is, there's a margin creation, and then it only grows as more customers start to, onboard to that service. We're starting to serve those customers with the same framework that we had before. We're not having to add more people.

We're not having to necessarily even add more software, once we reach a mature state, in order to serve a much higher number of customers, or a larger number of customers. That's when the margins start to appear. Right now, to set the risk of sounding like I'm a capitalist, sure, we want to make money. Our customers want to make money, and so do vendors, but from Nokia's perspective, we're a partner to our customers. This is an ecosystem. Always has been, it is becoming increasingly so, and so really any economies of scale that we achieve, as a result of reaching these margins, they would naturally get passed onto the ecosystem. Then you create a really healthy environment for everybody in that ecosystem to grow.

MH: I suppose that brings us back to the tectonic shift comment, that we were discussing a little bit earlier. The idea that there is experience in managed services, putting out a product, making it available, but it's that economies of scale that really brings you those margins. It's difficult to say what the margin figure is. If a CSP isn't taking that SaaS offering, and making it available to multiple clients, whereas in the olden days, it was customized software for a specific client, and then when someone new came in the door, you had to start all over.

MB: That's exactly right, and that's one of the problems that we see today in our industry is, you can probably go to every operator, they'll admit this because I've had these discussions with them. They'll go to every operator and they'll point to multiple instances or siloed instances of the same system. These are back office systems. They don't really create any competitive advantage. They're necessary for our customers to run their business. Then if they're large enough, they may have various operating companies, and each has their own, and to make matters worse, they may have customized it extensively to match whatever their business process was at the time. That gets so heavy, and so hard to maintain, so expensive, eventually they can't do much more with it. They cannot move forward in that model.

They have to find a different model. That's what drives a lot of buying decisions that I see today. It's just the need to move to something that is fresh. What we have to be careful of is not to necessarily accept the more of the same. One of the key movements that is happening in our industry is highly important and very relevant to SaaS is Cloud Native. Cloud Native, while I don't consider it necessarily the end game, I do see it as a clear means to an end, but all software that we should be deploying today, should be Cloud Native, or at least have a roadmap to reach some level of Cloud native maturity. From that, what we can do is, we can start to realize some of the operational excellence improvements that come with the auto orchestration capabilities, and self-healing capabilities, that naturally make a SaaS easier to provide.

MH: You're talking about the architecture of SaaS driving profitability, ultimately, because there is a difference between the single-tenant, and the multi-tenant business model, that SaaS provides.

MB: Yeah. To pick up maybe on two points that you're raising here. One question I'm asked a lot of times is, what's the difference between on-premise and SaaS? Isn't SaaS just really kind of on-premise, hosted for a number of customers? An answer can be, yes, no, maybe? Depending on, on how you approach it. Fundamentally, the difference between on-premise and SaaS is defined by the implementation of the business model itself. A lot of times, Michael, when we talk in terms of tenancy, we think about a technical architecture. That's not what I'm thinking about at all at this moment. I'm thinking about a business model that caters either, quite well to a single-tenant, or a business model that caters quite well to multiple tenants aggregated.

In a single-tenant business model, which is represented by an on-premise deployment, it's established for one and only one customer. It's further defined and exemplified when the deployment is uniquely tailored, because then it becomes even more excessively focused on one and only one customer, and hard to be used by other customers. Multi-tenant business model, however, such as one that's delivered by SaaS, result in all of the tenants receiving a similar experience, with some acceptable exceptions of configuration variations, such as the scale of service, so each customer may have a different scale. They may use the service more than another, but far as their experience is concerned, it's very similar.

When you get into that kind of model, a multi-tenant business model, that's where the architecture starts to play a critical role in two ways. One, I've already referred to Cloud Native. Cloud Native is necessary for us to be able to experience the benefits of things like auto scale, the ability to scale it in both ends of the spectrum, whether this is a large deployment, or a very small deployment. The second area where the technology and architecture comes into play is around the deployment, and management, and administration automation, because in the mature SaaS delivery model, that's not done by humans. The software's written by humans, but the hard work is done by software. It's software managing software, and when we get to that stage of the SaaS game, then we experience those economies of scale that we're looking for. Both us, and as well as, our customers.

MH: As we talk about margins leading to increased profitability, what about the other side of that coin? The churn rate. The CSP is constantly focused on lowering the churn rate. Is there an argument to be made, that software as a service, helps do that?

MB: Certainly, there's an argument to be made that, if you have a high churn rate, and you're running a SaaS business, then there's trouble ahead. There are books written on this. How important the concept of customer success is to a SaaS company? Not customer support, but customer success. Engaging with the customers in a proactive way to make sure that they're getting value out of the service.

The technology is helpful, for sure, in retaining customers, especially if you can get to a high level of maturity where the software is always reliable, and you're able to keep a roadmap that is consistent with the roadmaps of the customers. Then you retain them. But, I think what's vitally important, something that every industry needs to learn, but certainly now applicable as we think about these shifts that we're going to go through is, we got to pay attention to our customers.

The ones that are consuming these services, whether they be an enterprise or a consumer, a residential customer, doesn't matter, we have to pay attention to them equally, because, with SaaS, one of its basic foundational tenets is that you are providing a service in a consistent way. That's demonstrating value. That's going to keep your customers coming back. That's the lifeblood of any SaaS business.

MH: You've been quoted as saying, that "to become a powerful SaaS provider, it begins with a startup mentality". Whether it's Nokia's 92,000 people in a 27 billion dollar company across 100 countries, or a national CSP, how do you move fast and break things, without breaking the wrong things?

MB: Yeah. I know, I understand that all too well. First of all, going back to your question about tectonic shift. Whenever there's a tectonic shift, usually the ones that can capitalize the most are the ones that are agile, and then they tend to be the startups. So many times, companies that are in a position of leadership can be disrupted, for a variety of reasons, by these kinds of shifts. I think because of where Nokia is, where we are with relationship to the industry, and the relationships we enjoy with our customers, we're in a great place to be able to help our customers along this learning curve, and this technology curve that we're all going to go through together. I think that one question that might be on folks' minds is, what's in it for me?

Can you nail it down for me? Why do I even care about going through this whole transition? I think, the easy answer would be, well it's going to happen, whether we're ready or not. The more elaborate and compelling answer for customers is that, look, it's going to help us all with our business plans. SaaS is an enabler to rapid time to launch new services. It's going to allow new companies, or even flanker brands of existing companies to testing markets, to move into markets and out of markets really quickly, because you don't have a lot of expense upfront in deploying hardware and software. You can just get on board, test the market, and move on. Move into the market, or move on, if it doesn't work out for you. Maybe the most compelling reasons why SaaS is important to our customers is that we've struggled with our on-premise deployments to stay on the most current versions of the software, including the security patches.

In this day and age, that's something that nobody can allow that happening, to get out of with your security programs. Perhaps one of the most significant benefits of SaaS models is that it enables our customers to stay current on the software, and adding to that, SaaS transfers security management risk to the SaaS vendor. These are all important considerations for our customers. I think though, in my position, the way I'm thinking about bringing this capability, of this new strength to Nokia, I have to think of it as a startup, or with a startup mentality, because it is somewhat new and fresh for all of us, even though SaaS is a capability that's been resident in other industries. I think we just need to adopt it with an open mind, and we have to move very quickly in implementing the business model, along with the technology that underpins that business model.

MH: You advised Nokia to manage SaaS customers as herds, not pets. I think we're going to need to explain that.

MB: Yeah. Maybe it's not intuitive. Let me see if I can explain it, and then maybe give it even another analogy that might help. The use of the terms, pets and herds, are references that attempt to provide a relatable analogy. As I've said a couple of times now, Michael, it's been historically common practice in our industry for customers to implement specialized, and often highly customized software, and even hardware solutions. I liken this activity to the relationship that we create with our pets, which need a lot of intensive care and feeding. In contrast, SaaS begins with the assumption that all customers or tenants, as they're often called, can be more efficiently managed when done in an aggregated, a standard, a familiar way. The benefit to the customers, as I've been trying to explain throughout the discussion, is that there are cost efficiencies that can be reflected in the price of the service and can be amplified, when combined with the reduction and customization costs.

If it doesn't make sense to you, when I use terms like pets and herds, then perhaps a different analogy might be helpful, and that is one of a multi-tenant apartment complex versus a single-tenant home. You think about apartments. The apartments can have configurable differences. There's generally little variation in things like the layout of the apartment, the appliances that you get with the apartment, and the decor that's all chosen for you. There's an apartment management company that looks after the grounds, the facilities. It looks after the security, even on a regular schedule. As a tenant, my responsibility is to consume the resources, to live in the apartment, and make sure I'm paying my monthly subscription, so they don't don't throw me out.

In contrast, when you're living in a single-tenant, single family home, you usually have the right to customize without constraints. You're responsible for your own maintenance, both inside and outside the home. Any improvements that you're doing to the home, renovations, taxes on the home, and even security are your responsibility. Consequently, while you have all those benefits living in a single family home, your expense is generally higher as well. Those are two analogies. Hopefully one of the two resonates with the audience.

MH: With that in mind, give us your sense as to what it will take, for SaaS to become the predominant business model that CSPs prefer.

MB: That's a very good question. I think it will go back to some of the advantages that I'd raised earlier. The first thing I'd ask is, for those listening, keep an open mind. As I mentioned before, hardware is becoming software. Then we took a step further. A few years back and we disaggregated the software from the hardware, and all the smarts are really in the software to the extent, that disaggregation continues to happen, then software has to be managed in one way or another. We have historically wanted to retain control over that software, the same way we retain the control over the hardware, but I just don't see why, especially not in all cases, but even in many cases, why that has to continue to be our norm. Seems like we're setting up for a new norm, with the same new norm that the other industries have adopted a long time ago.

That is software provided by vendors, that can specialize in it, and do it very well, and provide a highly secure environment on demand. They can do it better really than the individual customers can do. What it does is it, yes, it takes away some of the control from the consumer, but also relieves the consumer of the responsibility for things that, I don't see, have a lot of differentiating value. Managing software packages, especially standard back office software packages, doesn't make a lot of sense in the long game. What makes more sense is to take that same investment, invest in new lines of business, or in new ideas that can be enabled by SaaS offerings.

<<Go to previous episode