xPactor®

Impact + Expectation + Inspektor + XML

The Challenge

Time and again, the same question is asked when dealing with different problems in and around the Service Management processes (Availability, Incident, Change, Capacity, etc.). “If certain events occur, what is the impact on my work or performance?”.

Usually, if an answer is available, it is because certain people in an organisation have developed certain rules or reaction pattern based on their experience or knowledge. That works as long as the complexity of how building blocks interact does not become too large, or know-how is lost due to out-, insourcing, staff turnover or other organisational changes.

If however key know-how is lost, the response to the question becomes uncertain, and with it risk of losing revenue or overseeing containable problems before they spin out of control.

The solution

One the one hand, a model is needed (the “Master Plan”) which describes the relationships and the interplay of the service-related components, and maps these into “blocks”.

One the other hand, the ability to define custom rules and activities per block is needed.

Now, if an event occurs, usually detected by external systems such as network or performance monitors, the following rule-based processing steps are run:

  1. What does this event mean for the element? Does it result in a status  change of the element?
  2. What impact has the event on the neighboring elements (as defined by the master plan)? If an impact is detected, the element in question is sent an event, thereby triggering its own inherent rule-set.
  3. Are actions to be initiated beyond the scope of the master plan? Should notification emails or alarms be sent, or other steps to be taken?

This recursive process is repeated as long as either no adjacent element is present or the rule prohibits a further stimulation.

Overview

individual master plans

  • The individual master plans are created externally, and loaded as tree structures into the xPactor
  • every element has specific, dedicated and unique qualifications – name of the element, associated unique control ID (allows referencing of contextual information)

performant Rule-Engine

  • upon receipt of an event, the calculation of a uniquely assigned rule is triggered within a given element
  • results are stored for further processing in a repository
  • if an element has “parents”, it will be informed of any status changes of the child

Flexible Rule-Definition

  • each element has individually assigned rules
  • rules define how to react to events of “child” elements, what result the rules produced, and which actions were triggered as a result
  • rules can be taken from a rule catalog, or custom rules can be defined during integration

configurable actions

  • the outcome of run rules can trigger external actions
  • the standard implementation allows for Tweets, RSS-Feeds, EMails orr commandline commands to be triggered

historical Repository

  • provides out-of-the-box auditable historical events and results
  • allows reporting and analysis of historical data without additional customised data dumps