Course Preview

IT Operating Models

An IT operating model defines how an organization turns technology strategy into working products and services. It connects decision authority, teams, funding, governance, suppliers, workflows, and measures so work can move from demand to operation with clear ownership.

itIT service management and support | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic — IT Operating Models

An IT operating model is the arrangement that turns technology strategy into decisions, work, and running services. It is not the organization chart wearing a more expensive title. The chart shows reporting lines. The operating model also shows who can decide, where money goes, how teams interact, which controls apply, and what happens after release day has departed with the project cake.

The central idea is a loop. Demand enters as a need, problem, risk, or opportunity. Someone shapes it, someone commits resources, teams deliver and operate, and evidence returns to the next decision. If any link is missing, the loop develops a queue. Organizations are remarkably skilled at naming queues after committees, which does not make them move faster.

Three concepts keep the map honest. A decision right names who can make a particular choice and within what guardrails. A value stream traces work from demand to an outcome, including the waiting and handoffs that polite diagrams omit. A persistent owner remains accountable through discovery, delivery, operation, improvement, and retirement instead of handing the service to a surprised operations team at the end.

Structural labels come next. A centralized model pools authority and expertise. A decentralized model places more of both near products or business units. A federated model combines shared enterprise guardrails and capabilities with delegated local decisions. Federation is useful, but it is not magic dust sprinkled over a matrix. It needs explicit global and local authority, usable platform interfaces, and an exception route that does not summon a new council for every awkward case.

Funding is where many cheerful diagrams meet the floor. A product described as persistent but funded as a sequence of temporary projects will behave like a project. Ownership fragments at each handover, reliability competes with the next visible feature, and the service continues operating because software has an inconvenient attachment to reality.

Different work also needs different paths. Discovery needs feedback. A standard request needs repeatable fulfillment. An incident needs restoration authority. A routine change can use automated evidence and delegation. A high-risk change may need independent review. One universal approval path either slows the ordinary work or treats the dangerous work with alarming optimism.

The Practice tab provides the mapping techniques. Use it to trace one value stream, inventory decisions, compare structural placement, and specify team interfaces. The Exercise gives those techniques a fictional identity service with queues, duplicate platforms, and confused ownership. The Field Notes describe the bits that resist tidy diagrams, especially exceptions and informal escalation. The Cheatsheet is the compact reference when the terms start breeding.

The lasting mental model is not a target chart. It is a feedback system: strategy directs demand, authority commits resources, teams deliver and operate, and evidence changes the next decision. Improve one constrained interface, observe the result, and adapt. A model that can learn is operating. A model that can only be presented is a slide deck.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources