IT Operating Models

The term ‘IT Operating Model’ is poorly defined and this publication proposes a definition in terms of its components. The definition is derived from the definition of an Operating Model for enterprises.

When considering IT Operating Models, it is important to distinguish between an IT Operating Model as used by a specific enterprise, and a meta-model or template of IT Operating Models in general, on which the enterprise’s specific model could be based.

The specific IT Operating Model is the design or description of how the IT function of a specific enterprise interacts with its stakeholders. It describes the IT function and how it functions.

The generic IT Operating Model describes the kinds of components that are needed to describe an IT function and how it functions.

Unfortunately, “IT Operating Model” is often used to denote both the specific and the generic variations. In this publication, “IT Operating Model” refers to the generic meta-model.

A broadly accepted definition of an IT Operating Model has not yet emerged, so the IT Operating Model in this publication has been based on Andrew Campbell’s Operating Model (for enterprises, not specifically for IT) as described in the Wikipedia entry ‘Operating Model’.

Seeing as this enterprise Operating Model is positioned as part of an enterprise’s Business Model, both are described below in terms of their component parts.

The Operating model describes how an organization delivers value, and it is a subset of the larger concept Business Model. A Business Model describes how an organization creates, delivers and captures value and sustains itself in the process. An Operating Model focuses on the delivery element of the Business Model. Campbell points out that there is still much disagreement about the use of the words business model and operating model.

Business Model (how an organization creates, delivers and captures value and sustains itself in the process):

• Stakeholders with whom the organisation will interact
•  Offers that the organisation makes to each stakeholder segment
• Contributions that each stakeholder segment is expected to make
• Resulting financial models (income statement and balance sheet)
• Operating Model that makes it possible for the organisation to interact effectively with its stakeholders

Operating Model (how an organization delivers value):

• Core work processes that create and deliver value to stakeholders
• Equipment and technology to execute these core processes
• Information and information systems to support these core processes
• Other processes to support the core processes
• Suppliers and supplier agreements to support the processes
• People to do the work
• Organization structure, decision rights, incentives and accountabilities and culture that ‘govern’, motivate and support the people
• Locations, buildings and ambiance

An IT Operating Model can easily be derived from the enterprise Operating Model by changing the focus from generic business processes to IT processes and by assuming that there is no other “equipment and technology” than “information systems”.

IT Operating Model (how an IT function delivers value): 

• Core work IT processes that create and deliver value to stakeholders
• Information and information systems to execute and support these core IT processes (it is assumed that there is no other “equipment and technology” than “information systems”)
• Other processes to support the core IT processes
• Suppliers and supplier agreements to support the processes
• People to do the work
• Organization structure, decision rights, incentives and accountabilities and culture that ‘govern’, motivate and support the people
• Locations, buildings and ambiance

Many discussions about IT Operating Models focus on the processes. This broader definition points out the other components that enable the IT function to deliver value.

It should be noted that these components are interrelated. Changes to components may influence other components in expected but also unexpected ways. The interactions between components should therefore be closely monitored, as much if not more so, than the components themselves.