Low-code and no-code platforms arrived with a promise that has been partially delivered and significantly oversold: that business users without programming backgrounds could build the software applications they needed without depending on IT development teams. The partially-delivered part is real. Workflow automation tools like Power Automate, Zapier, and Make have genuinely enabled business users to build integrations and automations that previously required developer time. The oversold part is the claim that this capability extends to applications of arbitrary complexity.

Enterprise IT has adopted AI-assisted tools at an uneven pace across the four functional areas. The adoption unevenness reflects a genuine difference in the maturity of AI applications across contexts — some IT functions have clear, measurable AI use cases with documented productivity gains, while others have AI vendor claims that have not translated to operational reality at the scale most enterprises require.

The honest assessment of where AI is saving time in enterprise IT is narrow but real: specific use cases within IT support, security operations, and software development assistance have demonstrated consistent productivity gains. The broader claims — AI transformation of IT operations across all functions — remain future-oriented rather than present-tense.

The IT budget allocation problem is structural, not mathematical. Organizations that spend the right total amount on IT frequently allocate it incorrectly across the four functional areas — run the business, grow the business, transform the business, and maintain the infrastructure that enables all three — producing technology environments that are simultaneously overspent in some areas and critically underfunded in others.

The allocation pattern that is most common and most damaging is heavy spending on new software and technology initiatives with insufficient investment in the support, security, and infrastructure maintenance that determines whether those investments function reliably. An organization that spends aggressively on digital transformation while deferring network infrastructure refresh, understaffing the helpdesk, and running security with inadequate tooling has not made a strategic trade-off. It has made an accounting error that looks like a strategic choice.

Every enterprise IT organization is running software it should have replaced years ago. The system is old enough that the vendor who originally built it may no longer exist. The employees who know how it works are approaching retirement or have already left. The documentation, if it ever existed, is incomplete or missing. The integration with everything else in the technology stack was built on assumptions that have since changed. The system runs critical business processes that the organization cannot operate without.

The average organization with 500 to 1,000 employees is running between 100 and 200 SaaS applications. A fraction of those are managed by IT. The rest were procured by individual departments, teams, and employees using corporate credit cards, expense reports, and in some cases personal cards that get reimbursed. The finance team knows about the ones with purchase orders. The IT team knows about the ones that went through the security review queue. Nobody knows about all of them.

Enterprise software procurement moves at a pace that the software it is trying to purchase has long since left behind. The average procurement cycle for a mid-market enterprise software purchase — from initial vendor identification to signed contract — runs between four and nine months. The software category the procurement team is evaluating will have shipped multiple major releases during that period. The requirements documentation that anchored the evaluation will have drifted from what the business actually needs. The vendor selected may have been acquired.