The Multi-Dimensional Rush to Managed Services

We are definitely hearing more about managed services these days.  I’ve talked about some technology developments linked to managed services (notably SD-WAN) but I’ve been going through user surveys and comments to decode the driving forces.  Since those forces will shape the market far more than technology will, I want to spend some time on them, and also on some of the things I think those forces will promote.

In managed services as in other technology sectors, one size (or one driver) doesn’t fit all.  There are two broad classes of technology buyers—“enterprises” and small-to-medium-sized businesses (SMBs).  Both these groups have a strong and growing interest in managed services, but different things are behind them, or at least different mixes of some common factors.

The issue that influences managed services most complexity.  Networks are getting more complicated, and I mean a lot more complicated, and the pace of complexity is accelerating.  That means that the skills needed to build or expand networks and sustain network operations are expanding.  Most companies have some difficulty acquiring and retaining qualified network professionals, and with more and more dependence on networks and more and more complexity to deal with, the skill problem just gets worse.

For SMBs, this is the big problem, particularly for mid-sized companies who are unusually rich in professional or other high-unit-value-of-labor people.  The services these companies offer (healthcare, financial planning, engineering, etc.) don’t allow for a lot of interruptions and delays, and the workers themselves can’t be diverted to fix problems with networks.  In surveys, I’ve found that the median number of network professionals in these companies is two.  That doesn’t leave much room for illness, for late-night operations, or for retirement or resignations.  It also means there’s probably no career path for the professionals within the company, so you can see the problems these firms face.

Almost two-thirds of SMBs have told me that they would prefer a managed service deal for WAN services to one where the user was responsible for the network, and almost as many said they would really like to have managed services “right from the desktop”, meaning on-premises too.  The problem is less willingness to pay (say the SMBs) as it is a lack of familiarity with offerings, or even knowledge of their availability.

Providers say that the problem with the SMB space is the difficulty in selling them, combined with the low return if you succeed.  One managed service provider salesperson told me “It takes me twice as long to sell to a mid-sized business as it does to a big enterprise, and the commission I end up getting is ten times as large with the enterprise, or even more.”  Even network operators, who already have a relationship with SMBs, say that it’s difficult and usually unrewarding to sell managed services to them.

I think the real problem here is the classic problem of marketing versus sales, and what I’ve always called “trajectory management”.  When you have a product or service that can’t really be sold efficiently by cold-calling, you need leads, which means you need a chain of events that ends with a prospect identifying themselves as such.  Often that starts with articles on the topic, read by users because they are network-dependent and know it.  That leads to website visits, then to sales calls.  That happy sequence hasn’t worked well with managed services, though.

Part of the reason is the other side of the picture, the enterprise.  Enterprises are worth more to sellers, to advertisers, to practically everyone.  Their professional service situation is very different from that of the SMB; they have a larger staff, fewer retention problems, and most of all the people who might be making a managed-service decision may see their own jobs at risk in the deal.  You need to couch managed service positioning carefully to avoid entangling yourself in job-fear pushbacks.

Actually, enterprises see their reason for adopting managed services as being more one of containment of professional staff needs than a desire to reduce staff.  Right now, the biggest problem enterprises face (according to them) is that of scope of operation compared to scope of services and support.  Big businesses have people everywhere, and so they need network services everywhere.  In today’s world, that means they need IP connectivity everywhere because all meaningful current applications depend specifically on IP connectivity.  It’s one thing to drop a data line in a remote area (or country) to connect a financial terminal, and another to sustain a workgroup that has to be connected to your corporate VPN.

The problem enterprises say they have is in remote locations where VPNs can’t be directly extended.  These locations likely have different service providers supporting access, and fewer employees who can be pressed into service to do local diagnostics and take remedial steps that are necessarily local and hands-on.  It’s this problem set that has become more serious as companies shift from providing simple device or local-server data connections to trying to add these locations to the corporate network.

What buyers say they need from managed services is more uniform.  They want a single point of contact, proactive monitoring and problem notification, a formal and detailed service-level agreement (SLA), an escalation plan if a problem isn’t resolved, a strategy for applying remedies locally, and a partitioned management system approach that doesn’t require the contact the MSP for things like adding a system or changing a security policy.  They don’t want to lose management visibility completely, a mandatory local “geek-squad” partner that does all the local work even where someone on site is considered qualified, and per-incident pricing that makes it impossible to budget for the costs.

Then, of course, there’s pricing.  There used to be a rule of thumb that said that total cost of ownership for a network was twice service costs, but that was in a day when people built their own network from circuits and devices.  An “average” midsize business today, one with 5 sites to connect, can make the connection with services costing about $6,000 per year, and would require two network types at a burdened labor cost of about $160,000 per year.  Obviously managed services could save this kind of buyer a hefty chunk.  Enterprises are different; the average TCO for enterprises in my survey ran 1.58 times service costs.  Both these figures omit capex.  Obviously, there’s a huge range of possible value propositions, possible prices, and possible drivers.

What the MSP has to do in order to meet buyer requirements and realize the managed service opportunity at a profit can be reduced to a phrase: management economy of scale.  Managed services displace in-house technical costs, so to be profitable they have to be able to deliver at least acceptable or equivalent support, at a price that buyers say should be about 30% lower than doing it in-house.  Getting to that breaks down into four specific points of action.

First, the MSP must have an excellent network operations center, and that means not only having a powerful and resilient management system but also a staff who has the experience to run things properly and deal with problems.  In any managed service, while the NOC isn’t the only thing needed, it’s the heart of the process and the place where the other stuff has to come together.

The second thing the MSP must have is an organized point of management visibility and control at the service boundary.  The “organized” part means that since a managed service is a form of virtual service, whatever collection of network stuff is needed to create the functional boundary point between WAN and LAN on a site must be abstracted into something singular and easy for all parties to interpret.  The border works, or it doesn’t.  You can’t have people digging through subtle components to figure that out; the user can’t and the NOC shouldn’t be taking the time.

The third point is that the location of the visibility boundary and the “policy boundary” determine the scope of the service level agreement.  This boundary point then serves as the default point of visibility and control for the MSP.  To extend it deeper means not only extending the responsibility of the MSP, but also the ability to see and control behavior at the new location of the boundary.

Point number four is orchestration and automation of the service lifecycle within the visibility/control boundary defined by the SLA.  You can’t have efficient management and management economy of scale without a toolkit to reduce human intervention.  Ideally, this toolkit should be one that can also be deployed by the user, perhaps offered as an add-on by the MSP, to facilitate problem detection, isolation, and remediation end-to-end.

Users say, by an almost 90% margin, that they don’t see this from MSPs today.  Interestingly, that statistic is nearly the same for enterprises and SMBs.  I think that enterprises are seeing the real issues with the MSP management platforms because they have the technical skill to assess those issues.  For the SMBs, I think the problem is more “subjective frustration”.  Nobody is talking with them about these points, and when they hear them they believe that the silence is because the MSP doesn’t offer the stuff or isn’t doing it right.  In either case, I don’t think the problems would be difficult to solve in most cases.

The product implications of this are harder to pin down.  If the virtual visibility/control boundary is made up of a number of “real” products or connections, some kind of management aggregation of the interfaces will be required.  If something tangible sits at the boundary, like an SD-WAN node or some network agent process, then that element may be able to provide a complete picture of the network.  Since most branch locations will be a single IP subnetwork, the visibility into that subnet is significantly improved if the boundary element provides DNS and DHCP services.

A final managed service driver that creates its own technology issues is security.  While managed service prospects don’t rate security as their primary driver (that’s support issues and costs), it places a close second and it’s becoming a driver for the primary issue.  Lack of technical support skills is one of the three biggest reasons for security problems for SMBs, and one of four for enterprises.  The contribution networks can make to security are primarily in the area of connection validation, a topic we include in “logical networking”, and Cisco recently purchased Duo Security for its ability to provide a broad strategy for access authentication.  However, security raises the problem of management system partitioning, because many companies don’t want to cede security policy control to a third party.  A strong managed service offering with good connection security could be a “killer app” for the whole space.

Another possible challenge for security as the basis for managed services is that security issues tend to be proportional to the number of user-to-resource relationships a company sustains in normal operation, which is only very loosely linked to the number of sites.  Managed services today, of course, are valuable proportional to the number of sites, so there’s a bit of “orthagonality” going on.  Security is a broader issue, and some MSPs might want to lead with it and then slip in managed services where appropriate, rather than try to redefine managed services in a more security-centric way.

Because of that, security may also redefine managed-service platform strategies.  As I’ve pointed out in a number of places (including our SD-WAN tutorial), security is a natural feature of “logical networking” and thus of advanced SD-WAN implementations.  However, you can also argue that SD-WAN is a natural feature of connection-validation security solutions, and we already see some companies (Fortinet, for example) making the move from the security space to a broader SD-WAN space.  That positioning, with security taking the lead, might be more palatable if security becomes the primary driver for managed services.

The final point here is that managed services don’t necessarily have to be simply a managed version of a traditional service.  MSPs in the SD-WAN space (the most active space at the moment) already include cloud hosting of elements, transport trunks that are combined with Internet connectivity, and other native-network features.  This is likely to expand both because of the desire for MSPs to differentiate their offerings, and because of technologies that abstract a variety of network underlayments into a common service model.

There is a lot of interest in standardizing various aspects of managed service, management itself not being the least of the targets.  These efforts, in the next three years or so, are almost certain to lag behind the new developments in the space, so we can expect managed services to get more diffuse and (some would say) disorderly in the near term.  That may be a good thing, because a lot of varied offerings are the best way for the market to vote on what’s really important.