How to Enhance Existing Applications with Embedded Analytics

A great deal of attention is being spent on analytics as an extension to commercial business intelligence or data warehouse systems. However, if you are responsible for building or deploying other types of enterprise applications, you may not see any benefit in the analytics movement. Here, Knowledge Center contributor Jim Falgout discusses a use case in order to convey the steps necessary to enhance existing applications with high-value, embedded analytics.

bug_knowledgecenter_70x70_(2).jpg

Enterprises are filled with custom applications such as claims processing or fraud detection that routinely analyze large and growing data sets. So, how do these enterprises benefit from recent advances in data-intensive analytics? The answer is embedded analytics.

Embedded analytics allow you to include in your existing software applications the same analytics capabilities that software giants such as SAS and SPSS deliver in their stand-alone analytics packages. For example, if your in-house system currently processes health insurance claims, you can improve your fraud detection by applying models derived from historical data to flag suspicious claims.

Fortunately, there are best practices for adding analytics to your software. Powerful tools are available that make it relatively easy and efficient, both at design time and runtime. I will illustrate this with a use case in order to convey the high-level steps necessary to enhance an existing application with high-value analytics.

A telecom use case

The use case involves a midsized telecommunications company. The operations team of the company receives log files continuously from switches within the company's networks. The logs from the switches contain call detail records (CDRs) that provide exacting details about each call serviced by a switch. In fact, many CDRs may be produced per call. The operations team also receives logs from many of their operational servers. In all, the large volume, fast velocity and variety of the data can overwhelm an already overworked operations team.

The operations team has done a great job of getting the needed information from the CDRs for required company operations such as billing. However, they suspect they may be losing money to fraud. They already have processes in place to scrub the logs for their required needs but they would like to extend that to add some level of fraud detection.

Here are five steps the operations team follows to move the fraud detection project from conceptual to production: