The missing entity in ITSM models, the Interruption

Long ago we used to follow the one true Codd, and data normalisation mattered. Now middleware, messaging, MapReduce and Twitter seem to have blown that idea away. Charles Betz may not agree but it seems to me data modelling is in retreat. Certainly it amazes me that a framework like ITIL can gain such ascendancy without even a token effort at a data model. (Personally i think that is just pandering to the vendors with existing products who would all end up with a non-complaint model). As a result I think some obvious entities are missed out, and one of those is the Interruption.

There is a missing entity in most models I have seen but it must exist within SLA tracking/reporting tools; the interruption. This entity tracks each interruption to a service from start to finish.

I'll draw a pretty Visio later, but I think the model looks like this:
Event >-o Incident >-o Interruption >-- Problem

>-o means many-to-0-or-1
>-- means many-to-1

An Incident is related to a user. Many Incidents may relate to the one Interruption to service. We handle this with a Master Incident. This is a denormalised kludge. The Master Incident is actually not an incident, it is a different entity - the Interruption to service. the Interruption is the interval from loss of service level until its restoration. it may affect one or many users. It may spawn one or many incidents.

The Service Level tools actually report Interruptions. They aggregate data to create Interruption instances. Yet while ITIL talks about Events, incidents and Problems as Things To Be Managed, it doesn't treat an interruption this way - it is just a word, a happening. If you think about it, what ITIL calls Incident Management isn't incident management at all, it is Interruption Management. Resolving all the incidents is just part of the cleanup of the Interruption, to make sure each affected user is OK.

ITSM desperately needs a standardised Conceptual Data Model, even if the vendors all have differing Physical Data Models. I know there are several initiatives out there. What is taking us towards this?


Data Model would be highly useful

Interruption is an interesting idea - I tend to agree with your opinion on what Incident Management does. The need for conceptual data model of ITIL would be highly welcome and it would certainly make discussions more relevant, products' assessment lot easier...

The missing link

Yes skep, I agree that the objects in ITIL are not complete when modelling data. You get far too many "many-to-many" relationships and that is usually a hint that you are modelling on a too high level. But I disagree with the name of interruption. A reduction in quality (e.g. performance, security, resilinace against failures [as in continuity]) is also a base for incidents / problems just as your interruptions. And when you start thinking about it (remember the discussion on problems being causes?) - I would call the missing link Effect.

Event >-- Effect (correlating Events & Effects may be hard upon creation, so in reality it may start out as >-0)
Effect --< Incident (Create an incident since someone feels the effect), so as Charles stated Incident 0-< Party
Effect >-- Cause and also Cause >-0 Cause (aka Problem)

So the relationships between incident, problem & event become: Event >-< Incident >-- Problem (Multiple problems only due to the hierachial [or non-looping network] relationships between Problems).

Marc -

ITIL entity relationships

We are having lots of prblems working out the relationships between Problems --> incidents ----> changes. Are problems releated TO changes and are incidents related TO problems? And what about people who are assigned to a problem or change request? is the person linked TO the problem or is the Problem linked to the person?

Very confusing!

Please let us know if anyone has some kind of database model or relationship diagram or even some direction.


please see top of thread

There are a number of entity models as I note above. But the incident/problem relationship is a bit tricky and I don't think is well understood at a conceptual modeling level.

I agree with mbuzina "Incident, Problem & Change (as well as Service Request) derive from the same supertype (could call it Ticket, Request or whatever) that has an N:M relationship to itself." But I take it a step further. I call it the IT Process supertype and it has the following subtypes:

• Demand Request
• Project
• Release
• Change
• Service Request
• Service Restoration
• Service Improvement

Incidents are equivalent to Service Restorations, and Problems are equivalent to Service Improvements. (there are other types of service improvements, driven e.g. by capacity, availability, agility, etc).

Charles T. Betz

Misleading concepts

Agree, incident and problem are misleading inside-out concepts.

I'm doing a presentation in Pink 11 on Problem Management. I spent far too much time writing it but my conclusion is that there is no such thing. Problem management is a mixture of different activities. Solving and fixing problems is quite important, it is just the terminology that is wrong. Part of problem management is problem solving, part of it is service improvement and an important part is risk management. It becomes much clearer when you get that.

Looking at "incident" from the customer perspective, there are three basic contact needs:
* to order a service or to order a change in an existing service
* give feedback
* to require support with a problem

Notice that here a problem is customer's problem, and the definition of problem is: an unsatisfactory state of things which is hard to solve. What is a problem for the customer may not be a problem for IT.

ITSM Portal has published my column on this subject yesterday There is also a very skeptical comment from Rob.


ER Diagram

Well, you can not find one, because it is not defined. If ITIL would have been so concise to include ER models and business logic rules, a lot this fun discussion would not be needed ;-)

Basically I would propose the following (others may disagree):

Incident N:1 Problems "is caused by" - so there is one problem causing the incident. Since the relationship would mean "we assume this incident is caused by this problem" the relationship can change over time, but usually you have one single problem as the so-called "root cause".

Problem N:M Problems "is caused by" - so a problem can be caused by multiple other problems. The application should check that this directed network of problems does not contain circles (e.g. if A is caused by B and B by C and C by A all 3 problems are the same). The network of problems is a more advanced topic, so not many systems include such a thing.

Incident N:M Change "is solved by" - so a change my solve more than one incident and more than one change may be needed to solve an incident.

Problem N:M Change "is solved by" - so again a change may solve more than one problem and more than one change may be needed to solve a problem.

Overall I tend to build a system in which Incident, Problem & Change (as well as Service Request) derive from the same supertype (could call it Ticket, Request or whatever) that has an N:M relationship to itself. Than the logic is enforced by the business logic or editing logic of the application.

When you ask about people, what kind of relationship do you mean? Works On? Reported by? Manages? Customer of? And as in any ER model a relationship is a relationship and has 2 sides. So I would have Incident N:1 Person "assigned to", which is the same as Person 1:N Incident "assigned to" (you may use different relationship names, but the meaning is the same). Both mean at a time only one person (depends on nullability, one or none) works on a given Incident and a person can work on more than one incident.

It will not be fixed before version 4, if ever

Agree completely but it would need a complete rewrite of IM and PM with new terms and concepts and that is not likely to happen with 3.1.


some places to start

Covering both the broader & more specific issues...

Actually I think that data modeling is on the rise again. With increasingly commoditized IT, there is more interest in solving problems higher on the food chain, and you don't get far there without conceptual data modeling. The NoSQL movement was created to solve specific problems and is much lower in the tech stack than conceptual modeling; the two conversations are talking past each other. (BTW see Michael Stonebraker's NoSQL critique in CACM.)

The metadata modelers have done the most with making some formal sense of "Business of IT" conceptual entities, as the metadata problem segues seamlessly into those broader concerns. The core data dictionary problem gets linked to applications and processes, which in turn bring in projects and operations and so forth.


- David Marco / Brian Jennings, Universal Meta Data Models
- David Hay, Data Model Patterns: A Meta Data Map
- Len Silverston, Data Model Resource Book, Telecommunications chapter

and of course my own book, which devotes about 100 pages to a conceptual data model for the business of IT, matrixed to both the major IT process areas and the major classes of IT systems available from IT management vendors. (sorry for the shameless plug but it does seem apropos.)

The OMG has dabbled in the space; reading UML as a "Business of IT" semantics is an interesting (if incomplete) exercise. See also the Business Modeling Specifications.

DMTF CIM is not a strong modeling effort, in my opinion. While they have many entities covering many concepts, they do very little to establish the cardinalities and business rules that make conceptual modeling valuable.

TMF eTOM might also be consulted but I think is too telecomm-centric. IBM and Gartner both have IP in this space as well (I think that IBM's model is free for download).

I'm not sure that we'll ever see a conceptual "standard" tho. The OMG has wrestled mightily with the problem of "upper ontologies" and that's exactly what you're tangling with when you attempt to standardize concepts like "Service," "Process," and "Capability." What efforts are you aware of (and CMDBf doesn't count for reasons we both understand)?


In terms of the concept of Interruption -- another semantic representation might be to say that the Incident *is* the master record, and Service Calls of a given type are the children. (Not sure if this is "ITIL-compliant.") I know in much common usage it is typical to say "The Incident lasted X hours." In that usage, they clearly *are* talking about what you term "Interruption." It might be difficult to re-train people to say "The Interruption lasted X hours and caused 56 Incidents" where Incidents are counted in terms of people making calls to the Service Desk.

Also, you are making Incident functionally dependent on an impacted party. No impacted party, no incident, correct? And if that is the case, then is it not also possible you might have Events tied directly to an Interruption with no intermediating Incident? In that case the model would be

Event >-o- Interruption -+-< Incident -o-+< Party ...

(Incident requires a Party, Party does not require an Incident)

I'd have to crack open a modeling tool to get much further.

Charles T. Betz


Yes there is a direct relationship between event and interruption: it is conceivable that a service could be interrupted but no user complain.

Likewise there is also a direct relationship between event and problem: an event can indicate a problem that hasn't yet caused an interruption or an incident. This is the situation that ITIL lumps in as part of the incident definition ("a potential interruption"), hopelessly muddying it and reducing its usefulness. if I ruled the world, an incident would be a user reporting an unexpected variance in service level. period.

if you want to call interruption an incident and call incident a service call, that's fine by me :) We agree on the structure.

As to current efforts, CIM and Oh My God were the two I was thinking of. And there are hints of COBIT 5 having a crack at it too.

Syndicate content