What’s the biggest tech challenge, according to enterprises? Multiplicity. We have too many tech things, too many tech administration tasks, too many product types, too many layers of functionality. Who’s at fault? Enterprises admit that they are largely responsible. Is anything being done about it? Sort of.
Management, in particular, feels that it’s buried in problems, issues, and “priorities”. We’re largely through the 2024 budget process, and of 385 enterprises who offered me comments on it this year, 311 said it was the most challenging cycle ever, from a tech perspective. A big causal factor is that multiplicity problem.
Of our 311 worst-cycle believers, 285 said problems and issues have grown because there’s more stuff involved. It’s like a household that’s gone crazy with gadgets and found themselves enslaved by the challenges of making the most of what they have. But most household gadget crises are caused by simple impulse buying, perhaps by having too much to spend and too little discipline, and enterprises say their problems are really rooted in having too little to spend and too much discipline.
“When I started work here [fifteen years ago] we had a technology strategy. Now we have a technology collage,” according to one tech executive. Of the 285 enterprises who said they had the multiplicity problem, 209 said that IT and network planning was “reactive rather than proactive”, and that the reason was related to budget constraints. In 2024, the companies told me, 83% of all their tech budget was allocated to sustaining the current applications and practices. On the average, 11% was allocated to “fighting fires”, meaning addressing new problems identified by business management, and only 6% was allocated to IT improvements driven by IT planners.
How does this relate to multiplicity? Enterprises say that the only “new” spending is focused on high-priority executive-level demands that require quick action, but are still under spending pressure. This encourages the “band-aid” approach, adding something tightly focused and highly incremental to what’s already in place. Because these new elements are loosely related to what’s already in place (if they’re related at all), they almost always add in new integration and management challenges, and the short timelines demanded mean that in many cases, issues aren’t found until the new stuff is in production.
In security, the 285 enterprises reported growth in the number of separate tools from two twenty years ago to five in 2024. In application hosting, they said they had an average of three platforms in use two decades ago, and had 6 today. They also used just over twice the average number of programming languages, four times the number of cloud APIs, double the number of network service providers, and went from two IT operations tools to five.
All this growth says that something has changed to increase the level of disorder what? Some of the problem is surely the band-aid problem, caused by the fact that almost twice the amount of budget money is allocated to fighting fires (to mix a metaphor) as is allocated to planned IT optimization. But why did we apparently do better in the past, to secure the lower reported numbers? Is the current level of budget contrast the whole story? I don’t have a way to get explicit enterprise comments on that; most people I chatted with weren’t in jobs that made them aware of this issue back 20 years in time.
My own experience in IT, and some indirect data from surveys that go back well over 20 years, suggest that the biggest problem is one I’ve mentioned before in blogs, the decline in the number of “major” IT projects. When companies did a major new productivity project, it usually justified a major change in infrastructure, planned and implemented over a multi-year period. In effect, this refreshed tech and reset the overall IT model in play. We lost this influence in the 1990s, when the last major cycle ended, and without it we’ve been building up a form of what’s often called “technical debt”, a legacy of old ideas cobbled together with those band-aids to address new problems.
The cloud, I think, is another factor. IT that lives entirely in the data center is something that has to be planned out. The problem-response nature of today’s new IT development encourages the use of an extemporaneous resource like the cloud. That then reduces the need for tech planning, and multiplies the number of platforms and tools, even of programming languages. It may be the latter impact that’s easiest to understand, but it may be the former that has the greatest effect over time. How long does it take for real IT planning skills to go stale when they’re not exercised? How can IT multiplicity be addressed without those skills?
If these points represent the real source of the problems, do enterprises say they’re being addressed? No. Of the 285 enterprises who cited the multiplicity problem, 218 agreed with at least one of the points, but only 74 said their companies were even aware of the issues, and only 48 said they were taking steps to address them. The nature of the initiatives of that 48 may show why real action here is still rare.
Of the 48 companies, 36 characterized their activity as the creation of a holistic IT plan or architecture, the creation of something on which they’d converge all IT planning. All of this group said this was a multi-year initiative. The remaining 12 indicated they were “consolidating” their vendor decisions, with the goal of modernizing and unifying things. This group also said this was a multi-year plan.
Consolidation of vendors seems to be a reaction to the multiplicity problem even for enterprises who don’t claim to be addressing any of these issues directly. Remember, there were 211 enterprises who didn’t even believe their companies were aware of the issues driving multiplicity, but 121 of this group said they were working to reduce the number of vendors and 88 said they were looking to identify a single IT giant as their strategic partner.
It’s not clear how effective a vendor consolidation move will be in addressing multiplicity, given that it’s not clear that’s even a recognized goal or a target in the consolidation. I think that vendor consolidation is only an indirect solution at best, and many vendors have embraced so many technologies that they’re not narrowing enterprise options much, if at all. The best approach would seem to be IT strategic planning, but we may have to wait for that to emerge, and perhaps wait a long time.
