How to avoid the network-as-a-service shell game

I can’t tell you how many times one of my clients or contacts has complained about the difficulties associated with getting network-budget approval. If I’d never met a CFO in person, the description these people gave me would have led me to expect something like a troll or a zombie, bent on eating projects and maybe people, too. Do we wear garlic when we visit the CFO, or maybe do a chant before the meeting, or might there be a more practical approach?

CFOs aren’t just trying to mess up a good technology project (at least most of the time), they’re trying to validate two basic financial rules that govern technology procurements.  Rule One is that any project must advance a company’s financial position and not hurt it. That seems logical, but it’s often difficult to assess just what the return on investment (ROI) of any project is.  Rule Two is that you don’t want to buy equipment that you’ll have to replace before it’s been fully depreciated. The useful life of something should be at least as long as the financial life as set by tax laws.

One obvious way to address Rule Two is to avoid buying something that has to be depreciated, which means that if you can expense something as a service rather than installing capital equipment, you dodge Rule Two bullets. Expensing also makes it easier to calculate ROI, because there are no complex financial calculations involving things like cost of money when you’re not making capital purchases. One of the things enterprises like about the cloud is that you don’t buy data centers, you buy the service of data centers.

This substitute-expense-for-capex is an old concept in networking. Today, rather than building a private network with leased connections and routers, most companies use virtual private networks. VPNs are now being augmented or replaced by managed SD-WAN services, which are also a virtual network technology. You’ll probably not be surprised to learn that we have a name for what comes next in networking. The cloud gave us “as-a-service”, and so we’re now starting to hear about network-as-a-service or NaaS.  It’s also not surprising that NaaS already means different things to different people.

The one common element in all NaaS definitions is that substitution of expense for capital purchases. Service providers see NaaS as being VPN/SD-WAN with a lot of personalization and agility built on. The cloud lets you scale up and down and replace something that breaks, and service providers are seeing NaaS evolve in those directions, even to the point where individual applications or users might have their own virtual networks that add or subtract endpoints and capacity as needed. You then pay for your usage.

Vendors are in a more difficult position here because it’s their equipment that the service provider vision of NaaS is turning into a service. Big network operators have economies of scale that enterprises can’t match, so less equipment would be sold to create NaaS service than to support private networking. Not only that, it’s hard for equipment vendors to differentiate their offerings when they’re hidden inside a NaaS cloud. 

Cisco, the equipment vendor best known for their marketing skills, has a solution.  They start with that notion that NaaS means you expense something rather than capitalize it, and that’s how Cisco’s website opens their NaaS discussion. Cisco takes it further, though, with a now-emerging concept they call Cisco Plus. This tag line will cover not only NaaS but also cloud computing, edge computing, virtual desktop, and so forth.  Everything-as-a-service—from Cisco, of course.

It’s hard to say exactly how all this works at this point, but it appears that what Cisco plans to do is to combine both computing and networking inside a common Cisco cloud model, accessed via a secure access service edge (SASE). You’d likely pay a fixed access charge to your network provider to get connected, and then pay for whatever features, connectivity, and capacity you use.

Before you get too excited at the prospect of facing down the CFO by shouting, “Cisco-Plus-NaaS,” to force a retreat to one of those dark caverns, consider that NaaS doesn’t address our two rules of project justification fully, it just falls through a different set of cracks.

Our Rule One says that your project has to meet financial targets, meaning a target ROI. NaaS makes it easier to figure out whether a project meets CFO targets, but remember that anything sold as a service has to include a profit margin for the seller. The cloud has not replaced every data center, not because of CIO intransigence but because the cloud isn’t always cheaper. NaaS wouldn’t always be cheaper either, so a NaaS-based project is going to have to prove it’s a better strategy than capital purchasing would be. Your trip to the CFO’s office just got more complicated.

Another issue with NaaS is cost control. With traditional  networking, you pay a fixed amount for fixed capacity. Your cost is predictable. Any kind of consumption-based pricing risks generating some truly eye-popping bills if the usage is greater than expected, and most such systems really don’t make it easy to ensure that excess usage doesn’t happen. Serverless cloud computing customers are already whining over multi-hundred-percent cost overruns.  It seems like you can either face your CFO during project approval  or face your CFO when you blow your budget. The latter isn’t likely a great career move for you.

It just might be that the biggest problem we have in networking isn’t the CFO, it’s the bandwagon. We seem to expect that any new technology is the best because it’s the newest, and that it will sweep the old technologies away. We jump on every bandwagon. The cloud didn’t sweep data centers away. VPNs didn’t eliminate the sale of routers to enterprises, and serverless hasn’t replaced all other forms of cloud computing. Network as a service isn’t always a good idea.

Where is it a good idea? NaaS is good where usage is highly variable, because fixed-price solutions would in that situation mean paying for the peak usage all the time. It’s also a good idea where the support of purchased network technology is difficult for a user to provide. Operations costs are often overlooked in NaaS project justifications, and yet CFOs tell me that operations costs are often what tips the scales from rejection to approval. So, yes, you have to estimate them, too.

The point here is that there’s no easy solution to justifying network projects, and new offerings like NaaS are likely to make justification harder, not easier, because you’ll have to know a lot more about the applications, traffic, and users of a network than you did before. You’ll need statistics and charts, and you’ll need to be able to cost out any and all NaaS options against traditional VPNs and SD-WAN.

Oh, my, what do I do? Make your sellers help you. Demand they make a specific business case for what they want to sell you, not just hand you some packaged business case the vendor or service provider probably paid someone to write. Take some of your past experiences with your own CFO and translate them into your own vendor-conference game face, then let the vendors/providers worry about garlic, chanting, and NaaS, while you contemplate a move to a corner office.