Information technology strategy
Definition
Information technology strategy
Information technology strategy is the plan for what a firm’s technology estate should become: which systems to keep, retire, buy or build, and what it costs. It governs systems and spend, not content; information governance covers who may decide about content.
A strategy is a set of commitments, not a wish list. It names what you will stop running, what you will buy, and the short list of things you will build yourself.
A plan that names no retirement is a shopping list — not a strategy. Every pound committed to something new has to come from somewhere, and usually that somewhere is a system you agreed to switch off.
Most of the money is already spoken for — keeping existing systems alive eats the budget before a single new idea is funded. That is the arithmetic any honest strategy has to open with.
A chief technology officer usually owns the document, with finance holding the other pen.
Key takeaways
- The strategy covers the whole estate: systems, spend, skills and the order of work.
- Most technology budgets go on running what already exists rather than on new builds.
- Ageing systems are a cost line and a security exposure at the same time.
- A documented modernisation plan is what separates intent from a slide deck.
How it works
You sort the estate into four verbs. Keep what still fits, retire what no longer earns its place, buy what the market does better than you could, and build only where the work is genuinely your advantage. Then you sequence it against money.
| Decision | Question it answers | Evidence you need |
|---|---|---|
| Keep | Does it still fit the business? | Cost to run, user demand |
| Retire | What breaks if it goes? | Dependency map |
| Buy | Is this a commodity now? | Market options, total cost |
| Build | Is this our advantage? | Capability case |
| Sequence | What goes first, and why? | Risk and funding window |
Public sector law puts a name on the owner. In the United States, federal law makes the chief information officer responsible for developing, maintaining and facilitating a sound, secure and integrated technology architecture.
That statute also gives the role teeth. The officer monitors programme performance and advises the agency head on whether to continue, modify or terminate a project, which is the part most private sector strategies forget to assign.
The spend is where strategy stops being abstract. In a June 2019 review, the Government Accountability Office reported that the United States government planned to spend over $90 billion that fiscal year on information technology.
Most of that money was earmarked for operating and maintaining systems that already existed. Private firms rarely publish the equivalent split, but anyone who has read an internal technology budget recognises the shape of it.
The same review examined ten critical legacy systems aged between 8 and 51 years. Three of the agencies holding them had no documented plans to modernise at all, which is the gap a strategy exists to close.
Information architecture is a different question entirely. The strategy decides which systems exist and what they cost; the architecture decides how content inside them is labelled and found.
Skills belong in the plan as much as systems do. A migration that assumes you can hire twenty engineers in a tight market is a schedule built on a guess, and the sourcing decision is part of the strategy rather than a consequence of it.
Sequencing is where good strategies are won. Doing the cheap, visible work first buys the credibility that funds the expensive, invisible work later, and the reverse order has killed many sound plans.
A business capability model keeps that conversation out of brand names. You argue about capabilities first, then about which system serves them.
Examples
Four shapes recur across sectors and company sizes. The scale and the regulator differ, but each one turns on the same decision: which systems the firm will stop running, and who pays for what replaces them.
Post merger consolidation. Two decades of acquisitions leave four payroll systems — and nobody owning the choice between them. The strategy’s job is to pick one, fund the migration, and set the date the others go dark.
Core platform replacement. Replacing a general ledger or an enterprise resource planning (ERP) suite is a multi-year commitment. It usually reshapes the business operating model before it delivers a single report.
Capacity through partners. Mid-sized firms rarely hold every skill they need. An experienced IT project manager hired through an offshore partner is often how a strategy gets delivered rather than admired.
Regulated modernisation. Insurers and banks often run ageing core systems they cannot simply switch off. The strategy there is a sequence of carefully fenced replacements, each one proved before the next begins.
None of those depend on a product choice. They depend on somebody writing down what the estate should look like in three years and then funding the route there.
Related terms
- Business transformation program: delivers the change a technology strategy calls for, across people and process too.
- Knowledge management specialist: looks after the content inside systems, which the strategy itself does not cover.
- Chief technology officer: usually owns the strategy document and defends its funding.
- Business capability model: maps what the firm must be able to do, before any system is named.
- Enterprise resource planning (ERP): one large system a strategy decides about, never the strategy itself.
FAQ
What is in an information technology strategy?
A view of the current estate, the target state, the keep, retire, buy and build decisions, a funded sequence, and the measures that say whether it worked.
How long should an information technology strategy run?
Three years is common, with an annual refresh. Anything longer tends to describe technology that no longer exists by the time the plan reaches its midpoint.
Who writes it?
The technology leadership with finance and the business owners. A strategy written by the technical team alone usually fails at the funding stage rather than the design stage.
How is strategy different from a roadmap?
The strategy sets direction — the roadmap sets dates. One says what the estate should become and why, while the other says which quarter each move actually happens in.
Should legacy systems always be replaced?
No. Some run cheaply and safely for years, and the test is cost to operate, security exposure and whether anyone still has the skills to support them.
Find delivery partners by capability in the Outsource Accelerator directory before you commit to a modernisation date.
Independent
