Thus wrote a MIT Sloan school professor in a Wall Street Journal opinion bit, about the concept of removing a department he felt to be unaligned with the business it is serving. His basis for making this assertion of non-alignment, is sadly, a strawman argument about metrics being "different".
Put another way, he made a point of arguing that IT metrics are budgetary and control in nature. Not specific business objectives. And hence, unaligned.
IT departments are, by their nature, cost centers. Many CIOs report to the CFO as a result of their nature as cost centers. The CFO wants to make sure the IT service organization is having a positive impact across the organizations, at a controlled and predictable cost.
This is also, not so coincidentally, why drives to go "cloud first" originate in the financial management portion of the company. CapEx vs OpEx? CFOs love OpEx, can't stand CapEx in most cases. On premises equipment involves aspects of capital expenditure, and shows up on the balance sheet as such. OpEx shows up on the income statement. Moving to the cloud in "cloud first" shifts the costs to the income statement.
What it doesn't do, is bound those costs.
So if the CFO allots a budget of X for CapEx, chances are they are going to pay (far) more than X for the OpEx equivalent. And the magic of cloud computing is that it is far more friendly to the metrics that the CFO requires the firm to meet.
The complaint that the IT department (usually under direct/oversight dotted lines to the CFO) is measured according to the CFO's requirements rather than the businesses, is a red herring at best. C-suite has a responsibility to the shareholders to manage the expenses, assets, as well as grow income and profit. CFO level control means that this will happen.
So if the IT department is not meeting/exceeding the business requirements, I'd expect to see changes at the management/organization level of such a department. You can explicitly, or implicitly mission the IT department management to meet objectives supplied by their internal customers.
Hence I disagree with the argument he made about the non-alignment of objectives. They are well aligned.
His other point was somewhat more on target though. IT departments tend to wind up as silos, and tend to be rigid, inflexible. In my experience, this occurs in larger companies, or highly regulated smaller companies. Being flexible means, generally, breaking out of particular mindsets, such as "we only buy X from Y", or "everyone must use Z" regardless of how well, X, Y, or Z fit the business needs.
I've found, when the IT department is rigid, it specifically tries to limit a number of choices, to make their lives easier, rather than meet the needs of their customers. Its not hard to imagine a user who needs a specific type of machine, software stack to do their jobs well, and is told, for reasons, that they cannot have that. Instead, the IT department will supply what they think will work. It is a poor substitute at best, and the user winds up annoyed at the inflexibility.
That is a real scenario, one I've witnessed and experienced during my career(s). It leads to people seeking out their own solutions (not a bad thing, really), supporting themselves, and then IT saying "but you can't do this" despite the fact that its been done. This is, curiously, how cloud computing started. Make it drop dead easy, and cheap enough so that people who may not be IT people, can swipe a credit card, get a machine configured exactly as they need, and start work.
Though, that model doesn't work in regulated industries, it did work in general for others. The rigidity of IT policy drove the desire to consume resources in this manner. And to a degree, this appears to be what the author was basing much of his argument upon.
And this rigidity is a problem. I've argued (for more than a decade) that, for HPC jobs, the OS (and its configuration) is a detail of the job you want to run. Containers have to a degree, freed people from the often combinatorial nightmare of system/package configuration.
Likewise, cloud computing enables users to build what they need, when they need it, for a price. Its that last part that is the kicker, as what you need may be very expensive to implement/run in the cloud.
To make this work, you need significant support for automation (turn on/off systems as required). This exists. Though, who will do this for you, and has the permission to spend/expense for this? This would be an IT department again.
You could always, as he suggests in the article, break the department up and embed them within each business unit. His suggestion includes "guardrails". Which come from ... where ... exactly ? The CFO?
Thus the problem with his concept. Without an organization to help the business manage/run its tech, a tech dependent business will be in a world of hurt the first time something goes awry.
Moreover, if the CFO sets the guardrails, and says "don't spend more than X", and then your team finds out you need "4X" to make what you want work, are you going to ask the CFO to solve your problem by giving you a bigger spend, or are you going to look for a way to reduce your needs? And who will help you with that engineering?
Basically, my argument is that the author didn't make a convincing argument as to why IT departments should be deleted. He did note that they can be rigid and difficult to work with. That part is true. But a department not aligned to company business objectives, won't long survive in the business without new management and reorganization.