The SeeWhy System runs in a J2EE environment, processing and analysing the operational events streaming through your existing business software. It is highly scalable and has been designed to have a minimal performance impact on your existing systems.

The diagram below shows the major components of the SeeWhy System and how captured business events flow between them:

The SeeWhy Event Capture component works in conjunction with your existing integration software, receiving events in XML format via JMS compliant message queues. Alternatively events can be received via database tables using the SeeWhy Database Event Interface.

The events are then passed to the SeeWhy Adaptive Interpretation Engine, where they are added to the relevant time window in memory and analyzed using the calculations and rules contained in the SeeWhy Configuration Store.

The results of this analysis are stored in the SeeWhy Interpretation Store, where they form the basis of future analysis, and are also passed to the Presentation Server making them available for graphic display in the SeeWhy Navigator.

Where the analysis results in an alert state change, a message is also passed to the Notification Server which triggers the sending of appropriate emails formatted using the templates in the Configuration Store.

Each component in the SeeWhy system is described in more detail below.

Event Capture

The Event Capture component listens to its Event Interfaces which connect to either message queues or database tables where events are being published by your existing business systems or integration software.

For message queue event interfaces these events should be in XML format conforming to pre-defined XML schemas, and formatted within a text message without any additional text. The SeeWhy Database Event Interface allows rows in a database table to represent events, and in this case the database table is polled for new information.

Once received, events are converted into an internal representation, assigned a unique identifier, and checked to ensure they are in sequence before being passed to the Interpretation Engine and saved in the Interpretation Store.

In the Community Edition this component must be co-located with the Interpretation Engine.

Configuration Store

The logical collection of configuration files and database tables that define a SeeWhy System are referred to as the Configuration Store. The information this contains includes:

• XML Schemas defining the structure of incoming business events
• Definitions of the calculations and rules that will be applied to these business events. This is the core of the Interpretation Strategy and includes:
  • When calculations should be triggered
  • How to determine what is normal
  • If individual as well as aggregate level calculations should be performed, e.g. an average value for sales irrespective of customer, and an average value for each individual customer
  • How the results of calculations should be evaluated to determine if an alert condition exists
• Details of how to show graphical displays in the SeeWhy Navigator
• Templates for the notifications to be sent when alert conditions occur
• Details of who will receive these alert notifications  

The physical database used for the tables in the Configuration Store is shared by the Interpretation Store. This database may be remotely located from the other SeeWhy components.

Interpretation Store

The logical collection of database tables that hold the results generated by a SeeWhy system are referred to as the Interpretation Store. This information, which forms the basis of further analysis and provides context for alert notifications, includes:

• The raw business event data
• The results of calculations performed
• The normal values associated with each of these calculations
• Details of alert conditions that have occurred

Adaptive Interpretation Engine

The Adaptive Interpretation Engine (Interpretation Engine), in conjunction with the Interpretation and Configuration Stores, is at the centre of the SeeWhy System, and performs the event analysis and evaluation.

The Interpretation Engine receives events from the Event Capture component, and this triggers an appropriate series of calculations and rule evaluations. For the event type received, the engine will look to see which calculations should be triggered, and these will be performed. They in turn will cause the engine to look at which further calculations and rule evaluations should then take place, and so on.

A simple example

To give a very simple example, take the case where a ‘Sale’ type event has been received by the Interpretation Engine. The engine looks to see which calculations should be performed. This may include, for example, a ‘Mark Down’ calculation which determines the percentage of list price for each sale. In this particular ‘Sale’ event the engine determines that the price was 20% of the list price. The ‘Mark Down’ calculation then triggers a ‘Mark Down’ rule, this checks if the mark down is below 30% of list price - which in this case results in an alert condition.

Powerful statistical, analytical and evaluation functions 

There is a wide range of statistical, analytical and rule evaluation functions available to the Interpretation Engine, which can be used to create a rich variety of calculations and rules. These functions, in the simplest cases, are applied purely to the data within the event itself and the rules then evaluate this result against a fixed threshold – as in our example above.

Sliding time windows and expected values 

However, two key features of the SeeWhy Interpretation model are the ability to apply functions over a sliding time window, and the use of calculated ‘expected’ values to determine whether a value differs from the norm. For example, we may choose to track the average selling price for our products over the last 30 days and check that every sale is within 20% of this.

Configuring such a scenario with the SeeWhy System is very straight forward. As well as being triggered by the receipt of a business event, a sequence of calculations and rule evaluations may also be triggered based on a time schedule. These calculations may be purely schedule driven, e.g. every minute, or used in conjunction with business events, e.g. every ‘Sale’ event and every 15 minutes. This latter example is particularly useful where you need to detect situations where events have not happened.

Aggregate and individual level 

Calculations within the Interpretation Engine are hierarchical, that is they can be made at both the aggregate and individual levels, e.g. an average value for sales irrespective of customer, and an average value for each individual customer.

Where new individuals within a hierarchy are encountered, for example new customers, any calculations and rules that have been defined at this level will automatically start tracking the new individuals.

Replay historical data 

Once a set of event data has been captured it is possible to instruct the Interpretation Engine to replay its interpretation from a particular point in time onwards. All existing calculation and evaluation data is first removed and then the events are replayed using the latest calculation and rule definitions. In replay mode it is possible to suppress the sending of alert notifications, for example if you are resetting the data in a production system and the sending of historical alerts would be meaningless.

In the Community Edition this component must be hosted on a single cpu server.

Presentation Server

The Presentation Server receives and caches calculation and rule evaluation information, making it available to the SeeWhy Navigator. It also compresses the data for graphical display, such that older data is held at a progressively lower resolution, whereas for the most recent data all values are retained.

In the Community Edition this component must be co-located with the Interpretation Engine.

Navigator

The Navigator is a Java Applet based real time dashboard which gives a constantly updated view of calculation trends and alert states.  [See full size image]

It is accessed via an Internet Explorer Web Browser and includes:

• Real time plots of actual v expected values over time at the aggregate and individual level
• Bar charts showing a comparison of the most recent values for individuals within a hierarchy, e.g. a sales value for each customer or product line
• Alert state summaries across hierarchies
• The ability to zoom out, and view the full set of historical data, or zoom in to see the most current data at a higher resolution 

You can clearly see from the diagram above how accurately the SeeWhy 'Expected' line (in blue) tracks the 'Actual' data (in red).  

There are no restrictions on the use of the Navigator in the Community Edition.

Notification Server

This component sends any alerts that occur to whoever needs to know. A publish/subscribe model allows different alerts to go to different recipients, and for different recipients to see the same alerts in different formats.

The template that is used to construct the email notifications can include a mixture of information, including:

• Formatted text, expressed using HTML
• Data from the SeeWhy alert, referenced using SRL (SeeWhy Reference Language)
• Other data extracted from the Interpretation Store, referenced using SQL

In the Community Edition this component must be co-located with the Interpretation Engine.