What is information technology (IT)?

"Information technology" gets used for two different things: a department inside a company, and an industry that supplies systems to companies. Both uses are correct. Mixing them up causes a specific and expensive kind of failure, so it is worth being clear about which one is in play.

The two things the label points at

IT as an internal function is the team that runs and changes the systems the business already depends on. They hold the pager, administer the platforms, and are accountable for the estate staying up. Their success is measured in availability, ticket times and change success rate.

IT as a supplier industry is what an engineering partner like Infromatin Technologies does: designing, building and operating software for organisations that do not have the capability in-house. Their success is measured in whether the delivered system survives contact with the business three years later.

The failure comes from treating one as the other. Buying an external supplier on the assumption that they will behave like an internal team — accountable for everything, indefinitely, at the speed of a conversation — is a common procurement error. So is asking an internal team to deliver a product they have no product discipline for, with no mandate to own the outcome.

What actually sits inside the label

Strip out the acronyms and information technology is five overlapping concerns, each with its own failure mode:

• Infrastructure — where systems run and who patches them. Failure is usually capacity planning and certificate expiry rather than anything dramatic.
• Applications — the software that carries a process, and the configuration that makes it fit. This is where most customisation lives.
• Data — the records everything else is built on. Failure is definitional: two teams meaning different things by "active customer".
• Security and access — who can do what, and the audit trail proving it. In regulated environments this is a legal obligation, not a preference.
• Run and change — the work after go-live. This is usually the largest share of the lifetime cost and the least planned.

The common mistake is funding the first two thoroughly and treating the last three as overhead to be trimmed later.

What is not IT, however much IT delivers it

The process itself is not IT. Neither is the decision the system is meant to inform, the quality of the data underneath it, or the operating model that decides who acts on the output.

A system faithfully implements whatever process it was given, including the parts nobody wanted. Automating a broken workflow does not fix the workflow; it makes the broken version faster and harder to reverse. Most "the system is the problem" reports are, on inspection, process problems wearing a system.

A test for whether something is really an IT system

Ask one question: who outside the business depends on this being right, and what happens when it is wrong?

If the answer is "nobody, we noticed a figure looked odd", it is a reporting tool. It deserves modest investment and nobody should be paged for it. If the answer involves money moving, a customer being served, a regulatory obligation, or a production line stopping, it is an operational system — and it earns operational discipline: tested changes, documented recovery, named ownership and a monitored failure path.

Where IT projects actually fail

Rarely on the technology. The predictable places are:

• the process was never written down, so the system encodes an undocumented version of it
• ownership ends at go-live, and nobody is accountable for the year-three problem
• data is treated as an extract from a system rather than an asset with a steward
• the build was costed properly and the maintenance was not

None of these are technology problems, and none of them are fixed by choosing a different vendor.

Three questions worth asking about any IT spend

1. What decision does this change? A system that changes no decision has no value proposition, however good the demo.
2. Who owns it in year three? Not "who supports it" — who is accountable for whether it still does its job.
3. What does it cost to keep running? Including the internal people, the licences and the change that will inevitably be needed.

If those three answers are missing, the budget is buying activity rather than capability, and the invoice will keep arriving either way.

The short version

Information technology is not a product you acquire. It is a capability an organisation maintains — infrastructure, applications, data, access and ongoing change, held together by people who are accountable for it.

The useful question is never "do we need IT?" but "what does this system change, and who is responsible for it when it stops working?" That question survives every technology cycle, and it is the one most worth writing into a brief before anything is bought.