“IT is far too expensive” – and why the bill lands on the wrong desk

I recently came across an interesting post about the common complaint that “IT is too expensive”. I agree with most of the diagnosis. The harder part is turning that diagnosis into something that actually works in practice. Here are my five cents. As an IT architect I’m supposed to bridge business and technology. For a long time, though, I was clearly more at home on the technology side. The longer I work in this field, the more I notice how easy it is to lose the forest for the trees.

opensight.ch - roman hüsler

TL;DR

In the end it always comes down to one very basic equation:
Cost = Benefit

Yes, this is basic - And that’s exactly the point.
Most of the expensive problems I see in IT don’t come from missing complexity — they come from forgotten fundamentals.

IT is too expensive

The sentence drops in the budget round, somewhere between agenda items four and five. It is rarely meant unkindly. IT is simply the one number a management team can compare without much discussion: one cost centre, one amount, and last year it was smaller.

And then someone has to sit there and defend that amount, without ever having caused it.

Because the uncomfortable truth is this: IT administers these costs. It almost never triggered them.

Every tool had a requester

Go through your application list. Not the tidy one from the PowerPoint. The real one.

The CRM came from sales. The survey platform from marketing. The applicant tracking tool from HR. Plus a time-tracking system, a contract management tool, a second ticketing system because the first one “didn’t fit”. And somewhere an Access database from 2014 that produces a report every Monday which nobody reads any more — and which nobody wants to switch off either.

Not a single one of these systems was IT’s idea.

Each had a requester, a good reason and a budget. And each changed owner the moment the contract was signed. From go-live, it belongs to IT.

The iceberg: the licence price is the smallest number

What’s in the quote is the visible part.

Below the waterline sits everything else: security review and data protection assessment. SSO integration. An authorisation concept that someone has to write and then maintain. Interfaces to two other systems that grow along with it from now on. Patches, upgrades, testing after every release. Backup — and a restore that someone actually tries out once in a while. Two people who know the system, and the question of what happens when one of them resigns. Second-level support. And a risk that only becomes visible once it materialises.

None of it is in the quote. All of it lands in the IT budget later.

So ten tools at CHF 12,000 of licence cost each are not a CHF 120,000 cost problem. They are ten life cycles.

That is why the IT bill grows faster than the tool list. And that is why “too expensive” feels right to both sides: the business sees 12,000. IT sees everything else.

In the end it always comes down to the same equation: cost against benefit. Everything else — ownership models, steering committees, architecture boards — is worth exactly as much as it keeps that equation visible and decidable.

Why “let IT govern it” doesn’t work

The reflex is always the same: more central control. An approval body. An architecture board. IT has to sign off. Sounds like order.

In practice, three things happen.

First: IT cannot judge the benefit. It can say what something costs, whether it is secure and whether it can be operated. Whether the new tool saves sales three hours a week or merely looks different from the old one, it does not know. It cannot know.

Second: whoever cannot judge the benefit can only say no. A no from the architecture board is not a decision about value. It is a decision about effort and risk. That turns IT into a brake — and into one that can never explain why the braking was worth it.

Third: people respond to a brake by driving around it. A credit card, a SaaS subscription, a password shared inside the team. Three months later IT is in the room anyway, only this time with a data protection incident instead of a quote. Central control does not create order. It creates shadow IT.

Side note:
I’ve rarely seen fast-moving companies that were genuinely held together by COBIT or TOGAF. In practice, these frameworks often produce documentation and governance overhead rather than clear ownership and faster decisions. High-performing organisations usually rely on simpler, more direct mechanisms.

And then there is the point where the whole construct tips over: whoever owns something must be allowed to switch it off.

And that is precisely what IT is practically never allowed to do. It switches off what nobody orders any more — but never a system a business unit deliberately wants and still needs. There are exceptions: a security incident, a compliance requirement, a vendor ending support. Then technology forces the shutdown. But that is not a decision about value, it is an emergency. In normal operation, IT stays the owner without any real say. That is the most expensive role there is in a company.

The model: business service → value case → two owners

What is missing is not another committee. It is a connection.

The business service is what the company actually delivers. Not “SAP”, not “the file server”, not “the collaboration platform”. But: produce a quote. Onboard a customer. Run payroll. Take an incident call. Something a customer or an employee experiences — and that one person is accountable for. Not a team. Not a department. One person with a name.

The distinction matters more than it sounds, because it gets blurred constantly. “Microsoft 365” is not a business service; “employee workplace” is — everything a new hire needs to be able to work on day one, and to keep working through every change until they leave. Largely the same components, one decisive difference: the first is something IT delivers, the second is something the company delivers. Only for the second can someone outside IT stand up and answer for it — and that is exactly the point here.

The value case hangs off that service. One page, three numbers. What it costs — all of it, not just licences. What it returns: revenue, time saved, or a risk it prevents. And when someone last looked at it. “Living” means precisely that: reviewed once a year, with a date. A business case written once for the approval and filed away afterwards is decoration.

The rule that holds it all together is unspectacular, and still the entire lever:

Every application is mapped to at least one business service. No mapping, no value case. No value case, no owner. And without an owner the system is a candidate for shutdown — not as a threat, but as the normal case.

On top of that sits the dual accountability, and it separates cleanly:

• The business owns the value. Is it still worth it? Do we keep it? Do we switch it off?
• IT owns the delivery. Is it running? Is it secure? Does it cost what it should cost?

Both sign off on the same service. Neither can overrule the other alone. And for the first time the question “why is IT so expensive” has an addressee who can answer it.

And what about the NetApp?

The objection comes reliably, and it is fair: seven business services run on the storage cluster. Everything hangs off the network. Who owns that?

No single one. Shared systems are a layer of their own: a technical service with an owner inside IT, a capacity plan and a price — so much per terabyte per month. The business services consume that price. They do not own the hardware.

From there you have exactly two clean options, and the choice is made per platform. Either the platform becomes a service in its own right — storage, identity, the network, the container platform — with its own value case, its own price and its own owner, and it is defended on that basis. Or its costs are allocated, consistently and without exception, into the value cases of the services that consume it, so that it never shows up as a block of its own. Both work. What does not work is half of each: a cluster that is partly allocated and partly free is neither, and the model rots from there.

What you must not do is the third option — the one that arrives by itself when nobody decides: expensive infrastructure with no value case at all. No price anyone has to defend, no name against it, no question it ever has to answer. That is how sacred cows are born. And a sacred cow is not expensive because it is big. It is expensive because nobody is allowed to ask.

Then comes the allocation. And there, less depends on accuracy than on one single property: the key has to be something the business can influence. Terabytes allocated, number of tenants, a service level with a price tag — usable. Share of revenue or headcount — useless, because nobody can change anything about them. A key you cannot influence is not a lever. It is a levy. And levies get argued over, not decided.

An allocation distributes costs. It does not lower them. If a business service shuts down and hands back four terabytes, the cluster costs exactly the same the next day. Those four terabytes spread across the others, whose bill goes up — for a decision they never made. There is no faster way to make an allocation model lose its credibility.

That is why a usable value case carries two separate lines: directly attributable — licence, project, dedicated effort; that really does disappear on shutdown. And allocated — that only disappears one level down: at the next expansion or at renewal. Decisions are made on the first line. Savings happen on the second, later and in aggregate.

Which quietly turns the shape of the platform into a value case question. A cost that can only step down at the next hardware refresh is one no owner can act on: the decision is theirs, the timing belongs to the procurement cycle. A cost that follows demand is one they can actually decide about. So wherever the demand behind a service genuinely moves — seasonal peaks, a pilot that may or may not become a rollout, a business that could double or halve — buy capacity in small increments instead of once in a large one. Not because elastic is fashionable, but because a value case that can only ever be defended and never shrunk is half a value case.

In practice that rarely means everything in the cloud. It means a base you own for the load you can predict, and somewhere elastic for the load you cannot — which is what most people mean by hybrid, once the word is stripped down. The mechanics of building it that way are their own topic: scaling up, then out, then hybrid without a rewrite.

And not everything has to be allocated. Network base load, IAM, the service desk: what nobody can influence is better left standing as a visible base load than distributed down to the last centime. Visible base load is not the same as unowned, though: it still sits on a platform service with a name, a price and an owner — it is simply not divided up.

What changes if you really see it through

The budget conversation changes its unit. No longer “IT costs 4.2 million”, but “order processing costs 340,000 — and this is what it carries”. About the first number you can only argue. About the second you can decide.

And the question becomes decomposable. “IT is too expensive” has no answer. “Order processing costs 340,000” has one: you open up the service and see what the number is made of — two applications, one interface, a share of storage, a slice of second-level support. From there the question is no longer whether IT is too expensive, but whether the same benefit could be had for less. That is the first moment in which cost and benefit hang off the same object — and therefore the only one in which saving is something other than cutting.

Requests get a new first question. Not “which tool”, but: which business service does this belong to — and what changes in its value case? Anyone who cannot answer that in two sentences does not have a tool problem. They have a clarity problem, and no software solves that.

Switching things off becomes possible in the first place. Today nobody decommissions a system, because nobody is responsible for missing it. With a named owner there is, for the first time, someone allowed to say: we do not need this any more.

Shadow IT becomes visible instead of punished. If there is a legitimate path — name the service, write the value case, IT delivers — then the credit card is no longer the faster route, only the riskier one.

And IT stops being the department of no. It delivers stability, security and a price. Value is discussed by someone else — namely the person who can actually assess it.

In fairness: none of this is free. The mapping has to be maintained, otherwise it is fiction after eighteen months, and a wrong map is worse than no map at all. That is exactly why the value case has to be brutally short. One page. Three numbers. Anything longer never gets updated — and what never gets updated never belonged to anyone. And yes: in larger organisations there is often a group behind that one name. That is fine, as long as the group sends someone to the front. Accountability spread across several people without one of them signing is not accountability — it is exactly the state this article describes.

The question you can answer today

Take your application list. Again: not the tidy one.

Go through it line by line, thirty seconds per entry, two questions. Which business service does this system support? And what is the name of the person in the business who is allowed to decide whether it still runs next year?

Not a team. Not “IT handles that”. A name.

How many lines are left standing?

And the real question: what are you going to do with the rest?