That technical reality has been changing for decades, and the forces driving it are not singular. Cloud platforms, software-defined infrastructure, AI-assisted development, and shifting vendor models have each contributed in different ways. Taken together, they are gradually dissolving the technical rationale for the organizational separation that created IT departments in the first place.

One of the more consequential models emerging from that shift is as-a-Service. Not the only one, but one worth understanding carefully, because it combines a financial model change, an operational model change, and a technical model change simultaneously. That combination is why enterprises are moving toward it. It is also why the transition tends to be more complicated than the business case suggests.

The Three Promises

As-a-Service models make three promises to enterprise technology leaders. They promise agility, the ability to scale capability without the friction of capital investment cycles. They promise cost efficiency, a shift from large infrastructure expenditures to predictable consumption-based economics. And they promise operational relief, the idea that by moving execution to a provider, the enterprise recovers the organizational bandwidth that running the operation was consuming.

The first two promises get most of the attention. They are familiar, measurable, and relatively straightforward to model in a business case.

The third promise is the one that deserves more scrutiny than it typically receives.

What Operational Relief Actually Requires

When an enterprise moves infrastructure operations to an as-a-Service provider, it is redistributing operational execution to an organization outside its own boundary. The provider handles the daily work of monitoring, troubleshooting, updating, and governing the infrastructure. The enterprise benefits from the outcome without sustaining the organizational effort required to produce it.

That is the model. The organizational reality is more nuanced.

Large enterprises do not build operational complexity arbitrarily. The approval layers, escalation paths, monitoring routines, exception-handling procedures, and governance structures that accumulate around infrastructure operations exist because the enterprise needed them. They are structural responses to uncertainty, interdependency, and the organizational reality of managing critical systems at scale.

Those structures do not dissolve when a contract is signed. Sometimes they transform, reshaped around the new provider relationship rather than eliminated. Sometimes they persist largely intact, because redesigning them requires organizational attention that the transition itself consumed. And sometimes the enterprise finds itself managing coordination on both sides: provider oversight and relationship governance on one side, and residual internal structure that was never redesigned on the other.

The financial model changes. The organizational complexity does not always follow.

Why Network Operations Is a Useful Lens

Enterprise networking is not where most technology leaders expect a structural insight to surface. It rarely leads the as-a-Service conversation, and it is not the most visible domain in the broader cloud and platform shift.

But it is one of the most operationally dense domains in the enterprise technology stack. Networks carry decades of accumulated internal structure, monitoring disciplines, configuration governance, change approval processes, lifecycle planning cycles, and vendor management practices. The operational complexity is real, well-established, and deeply embedded in how enterprise IT organizations are staffed and run.

Network-as-a-Service is also concrete enough to examine carefully. It has a defined scope, a meaningful adoption continuum, and a growing base of large enterprises that have moved significant operational responsibility to providers. The variation in how far enterprises have gone, and what that has meant organizationally, is observable and comparable in ways that more diffuse platform shifts are not.

That makes it a useful window into a question that applies well beyond networking.

The Question Enterprise Leaders Are Already Living With

When a provider takes over operational execution, what actually changes inside the enterprise?

Not in the contract. Not in the cost model. Inside the organization, in the coordination structures, the staffing models, the governance practices, and the operational rhythms built around doing this work internally.

Does the overhead reduce structurally? Does it shift form without reducing? Does the answer depend on how comprehensively the enterprise has committed to the transition?

These are not abstract questions. Technology leaders navigating as-a-Service transitions encounter versions of them constantly, usually without a clear framework for thinking through the answers. The vendor narrative tends toward simplification. The business case models tend to assume the benefits without examining the organizational conditions required to realize them.

The enterprises that are getting the most from as-a-Service adoption are not just buying a different financial model. They are doing something organizational as well. Understanding what that is, and whether it is something enterprises can design for rather than discover after the fact, is one of the more important practical questions in enterprise technology leadership right now.

If the organizational questions behind enterprise technology strategy are questions you are working through, this publication is written for you. Subscribe to get each post as it publishes.

Not intentionally. I was doing what ambitious business leaders do: identifying opportunities, solving problems, moving fast. When the IT organization couldn’t keep up with what my department needed, I found ways around it. Better tools, faster vendors, creative workarounds. We called it innovation. The IT organization called it Shadow IT.

I didn’t fully understand what I was doing to them until I became one of them.

Three decades ago I made an unlikely move: from the business side of a Fortune 500 company directly into the CIO seat. What I inherited was a world built around two Hitachi mainframes, COBOL-based enterprise systems, and the specialized expertise required to keep them running. The people in that organization weren’t obstacles to progress. They were managing extraordinary complexity with extraordinary discipline, under constraints that most business leaders never had to think about. Security. Reliability. Integration. Governance. The unglamorous architecture of enterprise continuity.

That experience changed how I think about information technology permanently.

The organizational model that created IT departments wasn’t arbitrary. It was a structural response to technical reality. Mainframe computing and COBOL-based systems required centralized infrastructure, specialized expertise, and significant capital investment. The technology itself demanded organizational separation from the business. You couldn’t run payroll on Tuesday and let marketing experiment with the same system on Wednesday. The boundaries existed because the technology required them.

Over the following decades, those boundaries became cultural as much as technical. IT organizations developed their own governance structures, their own planning cycles, their own professional identity. The separation that began as a technical necessity evolved into an organizational assumption so deeply embedded that most enterprises stopped questioning it.

Information technology belongs to the IT organization. Obviously. By definition.

Except something is changing.

Cloud applications now land directly in business units, provisioned by a product manager with a corporate credit card. Software-as-a-service platforms are selected, configured, and operated by the functions they serve: finance, marketing, operations, HR, often with minimal IT involvement until something breaks. AI-assisted development is putting meaningful technical capability into the hands of people who have never written a line of production code. Network-as-a-service models are moving operational execution outside the enterprise boundary entirely, to providers who manage infrastructure on behalf of organizations that no longer need to, or want to, sustain that expertise internally.

None of this happened because someone decided the IT organization should matter less. It happened because the technology changed the equation. The specialized expertise that once made centralization necessary is increasingly embedded in platforms, abstracted behind interfaces, and delivered as a service. The barriers that made organizational separation logical are dissolving. Not by design, but by gravity.

Which brings me to the question I keep returning to.

If the forces reshaping information technology are pulling capability closer to the business, and the evidence suggests they are, what does that mean for how enterprises organize around technology? Is the movement of technology toward the business an inevitable structural shift, or a transition that still requires careful enterprise governance to deliver its potential?

And perhaps more provocatively: if information technology no longer requires the organizational separation that created IT departments in the first place, what is the IT organization actually for?

I’m not asking that question as a criticism. I’ve led one. I understand the value, the discipline, and the complexity that serious technology organizations bring to enterprises that would otherwise underestimate both. I’m asking it because I’ve watched enterprises spend decades and billions on technology without realizing the advantages that investment should have produced, and I’ve come to believe that the organizational assumptions we’ve carried forward from the mainframe era are part of the explanation.

The enterprises getting the most from information technology are doing something differently. It’s not the tools they’re buying. It’s not the vendors they’re partnering with. It’s something more structural: something about where technology decisions get made, who makes them, and how the organization is designed to translate technology capability into business performance.

That’s what this publication is about.

Not technology. Not IT. The relationship between enterprises and the information technology they depend on, and whether the way we’ve organized that relationship is still serving us.

The questions ahead of us don’t have clean answers, and I’m skeptical of anyone who thinks they do. What I hope to offer is a way of looking at the landscape that makes the path a little more visible, informed by four decades in the field, active research, and whatever this community brings to the conversation.

If you’re leading enterprise technology strategy, advising organizations through technology transformation, or building toward a role where those decisions will fall to you, this is written for you.