This article is based on analysis originally published by CIO.com (September 2017). The core concepts remain highly relevant as cloud adoption, SaaS proliferation, and DevOps practices continue to reshape enterprise IT.
What Does “Collapsing the Stack” Actually Mean?
Enterprise IT has traditionally been organized as a multi-layer technology stack: physical servers, operating systems, middleware, databases, enterprise applications, and security layers. Sitting on top of that technical architecture is an equally layered functional organization — infrastructure teams, database administrators, middleware specialists, application developers, security engineers, and so on.
“Collapsing the stack” refers to two interrelated forces that are compressing those layers: automation and integration. As these forces take hold, both the technology architecture and the human organization that supports it are forced to consolidate and restructure.
The Two Engines of Stack Collapse
Automation
Cloud computing is the clearest example of automation at scale. When a company migrates its data center workloads to a public cloud, it replaces manual provisioning, patching, and capacity planning with automated, self-service infrastructure. This automation enables elasticity and shareability — properties that were expensive or impossible to achieve in traditional on-premises environments.
Software-defined infrastructure — where networking, storage, and compute are controlled through code rather than physical configuration — amplifies this further by pushing automation down into every layer of the stack.
Integration
Integration collapses the layers themselves. Platform as a Service (PaaS) is a straightforward illustration: it bundles middleware, runtime environments, and database services directly into the infrastructure layer, removing the need for separate teams to manage each component independently.
Software as a Service (SaaS) takes this further. A SaaS product such as Salesforce integrates the application layer, security controls, the PaaS tier, and underlying infrastructure into a single managed entity. The enterprise no longer owns or operates any of those individual layers — it simply consumes the outcome.
Collapsing the Technical Stack Forces a Functional Rotation
When the technology stack compresses, the functional organization that mirrors it comes under immediate pressure. Consider what happens when a company moves its CRM to Salesforce:
- Server administrators who previously provisioned and maintained CRM infrastructure no longer have that work to do.
- Database administrators who tuned on-premises CRM databases see that responsibility absorbed by the SaaS vendor.
- Middleware teams that managed integration layers find those integrations handled through vendor-provided APIs and connectors.
The people previously distributed across those functional silos can — and increasingly must — reform into a cross-functional sales operations team with end-to-end accountability for the Salesforce platform and its business outcomes. Their success is now measured by sales productivity and revenue metrics, not by server uptime or patch compliance rates.
This pattern repeats across IT. A shift from self-managed middleware to a PaaS model creates the organizational conditions for a DevOps team. A DevOps pod is not primarily organized around technology components — it is organized around application functionality, deployment velocity, and user outcomes. The team owns the full delivery pipeline, from code commit to production, rather than handing work across functional boundaries.
Key Characteristics of the Post-Collapse Organization
Whether the trigger is SaaS adoption, PaaS migration, or cloud-native development, the resulting organizational model shares several properties:
- Business-aligned metrics: Teams are evaluated on business outcomes — sales conversion, application release frequency, customer satisfaction — rather than infrastructure service levels or cost-per-transaction.
- Cross-functional composition: A single team owns development, operations, security, and data concerns for a specific business capability rather than a technology layer.
- Higher velocity: Removing handoffs between functional silos compresses delivery cycles. Decisions that previously required coordination across multiple teams are made within a single team.
- Lower total cost: Automation reduces the headcount required to maintain infrastructure, and integration eliminates redundant coordination overhead.
The Two Possible Ultimate Outcomes
Pushed to its logical conclusion, the collapse of the technical and functional IT stacks leads to one of two destinations:
1. Enterprise IT Reinvents Itself Around Business Services
In this scenario, enterprise IT does not disappear — it transforms. Functional technology teams are progressively replaced by service-oriented teams, each accountable for a specific business capability. The IT organization becomes a portfolio of internal service lines, each run like a product team, with engineering, operations, and business ownership unified under shared goals.
2. The Business Absorbs IT Functions Directly
In this scenario, business units take direct ownership of the technology platforms they rely on — procuring and operating SaaS tools, building low-code workflows, and contracting specialist vendors — leaving central IT with a much narrower governance and security mandate. Enterprise IT as a large functional organization effectively ceases to exist.
Both outcomes are responses to the same fundamental problem: traditional enterprise IT is perceived as too slow, too expensive, and too disconnected from business results. Stack collapse — driven by automation and integration — is the mechanism forcing that resolution, whether IT leaders plan for it or not.
What IT Leaders Should Do Now
Understanding this dynamic is the first step. The practical response involves several deliberate moves:
- Audit which layers of your stack are candidates for SaaS or PaaS replacement and plan the organizational consequences alongside the technical migration.
- Redesign teams around business capabilities, not technology components. Identify which functional roles will be displaced and which new cross-functional roles need to be created.
- Shift performance measurement. Begin tracking and reporting on business outcomes alongside traditional IT service metrics to build the case for restructuring and to prepare teams for new accountability models.
- Treat DevOps adoption as an organizational change, not just a tooling change. The tools (CI/CD pipelines, container orchestration, infrastructure as code) enable the collapse, but the lasting value comes from restructuring the team around end-to-end ownership.
- Engage business stakeholders early. If IT does not lead its own reinvention, business units will route around it — accelerating the second outcome rather than the first.
The collapse of the enterprise IT stack is not a risk to be avoided — it is a structural shift already underway. Organizations that understand the mechanism and manage it proactively will emerge with leaner, faster, and more business-aligned IT capabilities. Those that do not will find the transformation happening to them rather than by them.