We’d love to think that advances in the tech sector come about because of successes, but what might be the most consequential advance these days is a result of failures. Integration services are hot already and getting hotter, and according to enterprises the reasons lie mostly in faults in the way we create and explain technology, but we can’t fix that problem quickly. What do enterprises do when they need technologies they don’t understand? Integration services.
Enterprise data over the last three decades tracks some very interesting shifts, but none more than the level of technology dependence of enterprises versus their technology literacy. Thirty years ago, the number of avowed enterprise network decision-makers and the number of specialists who were fully conversant in the technologies they considered was roughly the same. Today, the number of decision-makers is four times the number of tech-savvy people.
An equally interesting statistic comes from the literacy of technical staff, decision-makers and support people alike. Twenty years ago (as far back as I have the data), three-quarters of enterprise technical personnel said they were “fully qualified” in the technologies they currently supported and were evaluating. Today, only 18% say that. Twenty years ago, just under two-thirds of enterprise technical personnel said they “fully understood” the current state of network technology. Today, only 11% say that. The explanation for both shifts, according to the workers themselves, is that sheer number of advances and changes in our industry.
That may not be fully accurate, though. My data strongly suggests that the primary reason for a slip in tech-savvy is the shift to ad-sponsored tech media. This shift has given vendors enormous influence, because of course only sellers buy ads. The increase in vendor influence, coupled with the Sarbanes-Oxley legislation that sought to eliminate hype-driven tech stock prices, shifted the focus of media to one of short-term sales of point products rather than to broad technology evolution. But I’ve blogged on this in the past and I don’t propose to reprise the topic here. Instead, I want to look at the result.
An enterprise who buys a network architecture and the associated products buys a total solution. An enterprise who buys a network product is depending on integrating that product into a solution, into a network architecture. The same, of course, is true of computing. When buyer tech literacy was high, we could expect that buyers understood the architecture, the products, and the integration. When it dropped, integration became an independent requirement, the only alternative to which was staying the course with the technologies and vendors already deployed.
Even vendors sometimes need to promote technology shifts, and so big vendors initially filled the role of integrator, and they benefited because they were able to pull through their own product suites through their integrator role, the classic “Camel’s nose” situation. Eventually, though, vendors realized that they could actually sell integration services and still pull through their products, and virtually all major network vendors now do that, but even that level of integration isn’t keeping up with buyer needs.
Networks are a lot more complex these days, despite the fact that we’ve shifted away from private routers and trunks to VPNs. Not only that, the justification for network budgets is increasingly intertwined with compute (cloud, servers, and software) elements in new projects. Finally, the growth of interest in open-source software and white-box devices has introduced product elements that are to a degree “vendor-less”, and so there is no vendor integration support available, for free or for a fee. There have been specialized integrators in tech for decades, but there is strong indication that dependence on these companies is growing, and may be about to explode.
Twenty years ago, only 6% of enterprises in my survey indicated that they had considered using a network or systems integrator. Early this year, that number had grown to 41%, and when you asked whether they believed they would seriously consider using an integrator within the next five years, 88% said “Yes”. The number one reason was cloud computing, and of course widespread cloud adoption introduces significant potential for changes to networks. For networks specifically, the top reasons for expecting to need integration were open-model elements, multi-vendor networks, new technologies, and expanded business scope, in that order.
Vendor-based integration is challenged to support these issues, particularly if the enterprise is trying to move in a direction (like open-model networks) that vendors don’t support, or if the driver of change is something a network vendor probably doesn’t have skills in, like the cloud. The value proposition for third-party integration services for both networking and computing is clear; you can obtain skills you need and don’t have, from an objective source. The risks are that the integrator doesn’t have the skills, isn’t objective, and is going to add significantly to your cost.
Data on all this is a bit sketchy, but what I have says that the rate of project failures for projects depending on third-party integrators is almost 20% higher than for projects advanced using staff skills. Cost overruns on integration projects occurred at 1.8 times the rate of projects based on staff skills. This in contrast to vendor integration, which resulted in no statistical difference in either project failures or cost overruns versus staff-skill-based projects. Some of this may be due to the increased complexity of the projects most likely to involve third-party integration, but I’m skeptical that’s the big reason.
I’ve audited integrator projects for enterprises and a few network operators, and what I found was that at least half of all deliverables in the planning phase were boiler-plate. The insights that were delivered were little different from what could have been generated by the company’s own staff, which indicated that there was less of a skill difference between integrator and enterprise than the former group presented and the latter one believed.
All this seems to add up to a conclusion that integrators (system or network) aren’t generally delivering what’s expected of them. That has certainly been true in the past, but there is at least some indication that it’s less true today. The rate of project failures and cost overruns from 2000 to 2018 actually went up slightly year over year, but from 2018 to 2022 they stabilized and then began (in mid-2021) to drop just a little. My data suggests that the reason is that enterprises have gotten better at managing projects involving integrators, and better at writing contracts for integration services. That may now be inducing integrators to raise their own skill levels.
The big question is whether that positive news can be sustained as enterprise integration needs grow. Salaries for technical staff among system and network integrators is typically almost 20% higher than among enterprises, and so enterprises may lose skilled people over time. However, vendors have been the largest source of competition with enterprises for skilled people, and many vendors have been slowing their acquisition of integrator talent. There hasn’t been much migration of skills from integrators to somewhere else, but in 2022 I have some limited data that suggests integrators are now starting to lose skilled staff, mostly to vendors but sometimes even to enterprises.
The best news, though, may be the fact that the adoption of open-model technology (as opposed to vendor-proprietary) is the largest current driver of integration services. We already have open-source software distribution through major firms (Red Hat, VMware, HPE, and more), and these firms are increasingly creating mission-specific ecosystems from combinations of open-source tools. They are also increasing their own efforts in the integration space, and if open-model technology remains a top driver of integration needs, they may ultimately be the most significant players in the space.
Less so in networks, of course, and I think that the big challenge in networking is that there is no real “open-source software” giant providing white-box software. However, I think it’s inevitable that VMware, because of the Broadcom acquisition, will end up doing that, and that would mean that Red Hat, HPE, and other vendors who offer open-source would likely be pressured to follow suit.
Managed services are the final element in network integration, but could become one of the most important. Physical networks tend to be partitioned by provider, since most wireline providers serve a specific (often national) geography. Since enterprises are increasingly global in their business scope, they need to create their WAN by compositing various provider networks. In many cases, this means crossing over to use broadband Internet access rather than MPLS VPNs, and that means SD-WAN. Since supporting the smaller remote SD-WAN sites is difficult, enterprises turn to managed SD-WAN services.
Managed service providers (MSPs) who offer SD-WAN VPNs would be happy to displace some MPLS sites, too, and also to expand their support into office LANs in the locations they offer SD-WAN service. If this trend continues, and enough sites are converted to SD-WAN, it could mean that most company sites are connected by MSP services, and no additional integration is required.
No single approach to integration is going to relieve enterprise issues relating to acquiring and retaining skilled people. White-box adoption, including SDN adoption, is likely to depend on how much open-source software vendors are prepared to support white boxes. Multi-vendor network integration depends on either the primary vendor or a third-party integrator, and Internet and SD-WAN integration are probably best obtained in the form of managed services. It’s tempting to wonder whether we’ll need an integrator to integrate the integrators, but enterprises’ choices in building networks with staff skill limitations will only expand, so I guess we’re destined to find out.