The BTM Blog

Customer Experience is definitely one of the hot topics for 2008. Against a background of intense competition and with operators generally having access to similar technical and service capabilities, it is recognised that focusing on the overall Customer Experience is critical. This places challenging demands on operators’ planning, operations and support functions – not least of which is an effective mechanism for measuring and optimizing Customer Experience. Unfortunately Customer Experience is one of those terms that can mean everything or nothing depending on who and when you ask.

Here at WestGlobal we like to think we’re pretty good at helping operators and other enterprises to measure and maximise their Customer Experience. So let’s walk the talk and define exactly what we mean when we use the term. We use the visual metaphor of the Experience Cube below to explain to customers how our solution, Vantify Experience Centre, can measure Customer Experience. It works something like this….

Starting with the first 2 dimensions (X and Y for the mathematically inclined), any interaction between a Customer and an operator can be defined in terms of the service (WAP, E-commerce, Voice, Support…) or Business Activity (provision, port, blacklist….), and the channel (e.g. IVR, Point of Sale, Call Centre) over which the service is delivered. We think that any ‘real-deal’ Customer Experience measurement solution must be able to measure any combination of service and channel. The particular orientation is generally dependent on who you talk to – Line of Business owners are typically interested in measuring their service over all channels whereas operations teams are often oriented around a particular channel e.g. Call Centre, IVR.

This two dimensional view can be considered as providing an aggregate view of Customer Experience in that key metrics or KPIs such as response time and error rate can be measured for the complete service or activity, but are not resolved down to a single customer, specifically the third or ‘Z’ axis in the Experience Cube. While we have found this aggregated view is often adequate to allow performance issues or failures to be rapidly identified and resolved, there is a reasonable argument that any solution claiming to measure Customer Experience must be able to resolve issues down to the individual customer. Vantify Experience Centre supports all three dimensions, including integration into support systems such as CRM enabling customer histories to be automatically updated with any performance issues. This allows the CRM agent to be primed for any customer calls relating to the issue, shortening the investigative part of the call, reducing support cost and improving the Customer Experience

Time is the fourth dimension in the Experience Cube. Our view is that Customer Experience measurement is a continuous activity with measurements and results presented in real-time. This provides the best opportunity to identify issues, either aggregate or per individual customer, as early as possible and eliminate or at least minimize impact on Customer Experience. Certain activities such as baselining and historical analysis can be adequately supported using historical usage data

To wrap up we’d say that Customer Experience can be defined as which service or business activity via which channel for which customer and when. If you can measure all those then you’ll have a pretty good idea of your overall Customer Experience.

The EPTS Use Case working group met on Monday in Rome before the DEBS 08 conference got underway.  It was hot stuff – temperatures touched 40C or 104F, laptops overheated, but great progress was made.  The new use case template should be available on the EPTS website in about four weeks.  After that, work should begin on trying to produce a reference architecture.  It was great to see Alex from Betfair, an end user of CEP software, with great views and great ideas.   Alex had some great ideas and great views on the benefits of CEP, and it benefits everyone to have real customers describe the value the derive, and the areas they wish to see progress.

The EPTS seems to be achieving some real momentum – no small part in thanks to the tireless Opher who pushes and organises everything behind the scene.  My thanks to Opher and to the DEBS 08 organisers for a great conference, but it reminds me that everybody has a part to play.  Those with an interest in CEP also have a responsibility to be heard and to play a part.

“Ambition should be made of sterner stuff”

Recently WestGlobal went through a rebranding exercise. We wanted to update our image to reflect our product strengths and also to find a new name for our flagship product.

Our product is built on a Complex Event Processing (CEP) engine and we present output to users via real-time dashboards (BAM), so wordplay and variations on a theme around these acronyms were bandied about with abandon.

Finally we settled on Vantify.

One of my suggestions, which I was quite pleased with in a smarty-pants way, was “roofbox”. Now you might think you know what a roofbox is, and may even have used one on your car in the past, but this word also has another meaning which is far more interesting and relevant to the topic in hand.

Here in Ireland there is a Megalithic Passage Tomb at Newgrange, Co. Meath. It is world famous and was built about 3200 BC. It is estimated that the construction of the Passage Tomb at Newgrange would have taken a work force of 300 at least 20 years.

It predates the pyramids by 500 years.

Of particular interest to us is one facet of this magnificent structure. That is, its ability to illuminate a passageway once a year on the winter solstice. To achieve this feat, an ancient device was, and still is, used to capture the rays of the sun. This device is called a roofbox.

This is defined in Wikipedia as follows:

“A roofbox is a specially contrived opening above a doorway, usually built for some astronomical significant event.”

Also interesting is the fact that the term was first coined by an Irishman:

“The term was coined by Professor Michael O’ Kelly’s during his excavation of the Newgrange passage cairn, at Brú Na Bóinne, Ireland.”

So , we at WestGlobal are not the first Irish-based community to try our hand at event processing. We are merely the latest in a very long line of innovative people who used the technology of the time in clever and lasting ways.

If we can achieve even a smidgen of the success and longevity of our illustrious forbearers at Newgrange, we think you will agree that we will have done a good job.

There’s some ongoing discussions in blogland as a result of a recent blog posting here by my good friend Tim Bass.  In his post, he applauds the use of analytics to the point of damning the current crop of CEP vendors for being made up of companies that don’t “support or advocate advanced analytics”.

Opher responded here by saying that most of today’s CEP problems do not require advanced analytics, and used the metaphor of blind men feeling an elephant.

For me, I confess that I fail to understand the debate.  I’m curious as to the term “analytics”.  Just what is “Advanced Analytics” as applied to CEP?  Is it advanced situation detection – in other words, will I use advanced analytical techniques to detect a situation?  Or is it advanced visualisation – will I be able to produce a real-time updating graph or chart based on a series of complex mathematical calculations?

Here at WestGlobal, we tend to focus on detecting whatever situations need to be detected, in the lowest latency required.  We can use a variety of techniques, depending on the situation.  We might find that one situation may be detected with a series of very simple rules, but that another requires enrichment from a data source, while joining with a variety of other data streams, and a dependency on the occurance of a series of other situations within the past 2 minutes.  But is this advanced analytics? 

For me, analytics is not a requirement – at most it’s an implementation detail for a specific problem.  As Tim points out, there are probably many examples of event processing that require very sophisticated processing techniques (I’m avoiding the term analytics).  As Opher points out, most applications today don’t require it.  And I’d like to point out, if the requirement existed and someone could make lots of $$ doing it, then chances are there’s somebody doing it already (and they’re keeping it a secret for as long as they can).

I’d love for Tim (or anyone else) to post an example or two of specific problems that exist that require advanced analytics.  Otherwise, it may be that I, and many other people, conclude that the trumpeting of the requirement of advanced analytics is just another type of snake oil.

Next week, I’m attending the DEBS 2008 conference in Rome. The conference is a great occasion for people from the academic and industrial worlds to mix and share ideas. Unfortunately, I’ll be cutting my attendance short due to customer commitments, but I am looking forward to seeing how event processing is maturing as a technology on many fronts. The DEBS conference pushes large scale considerations to the fore, and focuses less on the minutiae of implementation such as event processing languages or correlation techniques. Instead, discussions will tend to focus on the distributed aspect of event processing, with issues such as security, availability and reliability, volumes, filtering, event ordering, and synchronization all being presented. And I’m especially looking forward to the software demonstrations.

A surprisingly interesting question; are we talking about a) the processing of complex events or b) the complex processing of events? Both possibilities lead to interesting follow on questions such as what is a complex event? or what constitutes complex processing of events? This has been a source of much discussion within the event processing community and rather than present the argument in this post, I’d like to present the outcome of the discussion.

Recently, David Luckham and Roy Schulte produced an event processing glossary which defines complex event processing as the processing of complex events, and defines a complex event as an event that contains other events (known as it’s members).

Of course, the members of one complex event can be other complex events, leading to a hierarchical tree (or even graph!) structure of nested events. The processing of complex events can consist of tasks such as aggregating a set of events into a new event; deriving events from other events; filtering events based on their arbitrarily deeply nested members and so on – a rich paradigm indeed!

Obviously this hierarchy of events must start somewhere; with simple events that do not have other members. According to the event processing glossary, these simple events can be used to represent anything that happens or is perceived as happening. Starting with source events a powerful complex event processing network can be built which uses tasks such as aggregation to build intelligent models of business processes in an organisation.

One of the first tasks of the newly formed Event Processing Technical Society when they meet, will be to produce an event processing glossary which will hopefully become an industry standard. We look forward to seeing what they come up with!

In our work with IT intensive enterprises, we observe different approaches to the implementation of IT and service monitoring. These range from a fragmented model dependent on multiple and effectively isolated ‘point’ solutions through to highly unified BPM (Business Process Management) models providing excellent monitoring performance but typically demanding significant investment, technology and process re-architecting and imposing restrictions on supported technologies or vendors.

In our view, the most successful approaches in terms of maximising IT ROI, technology performance and improving Customer Experience are based on a combination of pragmatism and planned coherence. Pragmatism comes from an approach that supports highly heterogeneous IT and network environments comprising multi-vendor technology deployed often over as many as 10 or more years. Coherence recognizes the need to combine different monitoring ‘models’ to achieve a rich, timely, efficient and complete view of how IT and network systems are interacting to deliver excellent Customer Experience.

At WestGlobal, we have found a 4-Quadrant grid is useful in explaining the ‘coherence’ element. On the vertical axis, ‘Monitoring Focus’ moves from Technology in the ‘South’ to Business Activity/Customer Experience in the ‘North’. The horizontal axis measures timeliness or immediacy, with non-real-time (nrt) to the West and real-time (rt) to the East. All monitoring approaches can be positioned on this grid and we can outline the key characteristics of each quadrant as follows. . .

NW (nrt/ Business Activity Focus): Business Intelligence / Data Warehouse exceptionally rich in the ability to create marketing and businesses views of customer and business activity; but ‘after the event’.

SW (nrt / Technology Focus): Historical technology performance measurement. Typically based on log and CDR file analysis and frequently used for capacity measurement and planning of underlying IT and network elements.

SE (rt / Technology Focus): Here the focus is typically on monitoring and alerting the health of individual or groups of IT / network elements or application servers (e.g. WEB servers). But this provides limited insight into actual Customer Experience which may depend on the interaction of many elements and servers.

NE (rt / Business Activity Focus): Here the focus is on measuring the health and performance of actual business activities. It is interesting that while it is this layer that the customer interacts with and can therefore reasonably be argued as the most important in measuring Customer Experience, monitoring often remains focused on the underlying technology i.e. the ‘South Side’. The emergence of Complex Event Processing as a means to enhance the performance of solutions in the NE quadrant provides excellent opportunities for enterprises to detect patterns and events that signal potential Customer Experience degradation even before the customer is impacted.

The most effective monitoring approaches reflect the need to ‘cover the bases’ in the above grid. This implies a need for organizations to have some degree of coordinated planning across the complete monitoring architecture. With such an approach, additional benefits arise from ‘Grid Synergies’. For example, while it can often be difficult for Business Intelligence solutions to access certain network or low level data directly, the data can often be proxied via elements in the real-time side of the grid. Similarly, integration between the NE and SE quadrants combines real-time Business Activity Monitoring with the ability to ‘drill-down’ into the underlying technology only when necessary, for example to investigate a degradation or failure in a Business Activity. This is approach we have adopted with Vantify Experience Centre, in other words an ‘East side’ solution.

In many organizations, despite knowing what everyone is doing, finding out what’s actually going on can be next or nigh impossible. Operators are delivered notifications about everything that happens, good and bad, and they end up in a fog of detail.

Complex Event Processing (CEP) allows us to tackle this “wood for the trees” problem in two ways. First, it allows the unimportant details to be discarded, leaving only those that are relevant. Second, it allows those details to be tied together into a business oriented view.

It is often the case that under normal operation, things don’t always go to plan. A user’s session may take longer than normal to start or a credit card validation times-out. These once-off errors are not that interesting, particularly, as by the time they register with the support staff, the cause of the error has passed and everything is back to normal. What’s far more interesting is knowing when five users in a 10 minute window are experiencing problems or the credit card validation fails 3 times in a row. CEP’s Event pattern matching solves this problem very nicely. It allows detection of patterns like “X is followed by Y or Z in a 10 minute window”. When the pattern is detected an alert notification can appear on an operators dashboard or be sent by text message to the support staff. Only the events that indicate something of interest is happening get presented to the operators.

Another problem is that the monitoring that does take place does not give any real insight into how the business is performing. Low-level service monitoring can tell us that the web application is up and running or that the credit-card payment gateway is functioning ok but does not tell us how these services are supporting (or not) the business side and, ultimately, the customer. CEP solves this problem by allowing the low-level happenings (a user a logged in, a credit card payment was processed) to be aggregated into a more high-level event (user bought something over the web). This is known as “Event Abstraction” where a set of basic events are represented by a more high-level one. Thus, the actual business value emerges from the deluge of detail but the detail is retained should it be needed.

So CEP allows the bigger picture to emerge from overwhelming amount of detail. That’s the well informed ones! The not-so-well informed ones may be oblivious to what’s happening until they get phone calls from irate customers.

Conrad O’Dea

Chief Architect