Analytics is seeping into all aspects of business processes. It is not just part of a dashboard or a report any more. Now we are starting to see the integration of analytics, traditional and advanced, directly into our operational processes. This is evident in everyday concepts such as:
- Traditional taxi cabs versus Uber, powered by geo-spatial analytics
- Broadcast television versus Netflix click-by-click-driven video streaming
- Grocery store experience versus using Amazon Prime Pantry’s optimized supply chain
Listen to Pentaho’s Ben Hopkins brief author John Myers on the topic of embedded analytics in The Briefing Room entitled, “Beyond Discovery: Visualization at the Point of Impact.”
Enterprise Management Associates (EMA) considers this type of workload in our Hybrid Data Ecosystem (HDE) as “operational analytics.” This includes concepts such as bringing predictive analytics associated with risk and fraud management into operational processes when onboarding new customers or shipping goods and services. Finding transactional or identify fraud before a customer is brought into a customer base or a product is shipped helps to lower the costs of an operation and improve customer experiences. The HDE’s operational analytics concept also looks at how to use big data semantic analytics in the context of customer care and support operations. Understanding the social media opinions of a customer and referencing the previous customer-care experience notes can help change a difficult customer care situation in to a “customer save.”
This tight integration between operational processes and analytics provides both proactivity and disruption. However, it comes at a cost. Traditional business intelligence (BI) platforms are usually not connected to existing operational platforms due to the differences in data models, processing workloads and data consumer communities. Existing operational platforms oftentimes have difficulty integrating specific types of analytics into processes because of issues with data collection, speed of processing and cultural adoption. These hurdles have kept the “true” integration of analytics and operational processes from becoming a reality.
Let’s take a look at some of these hurdles. First, the differences in workload processing speeds or the speed-of-response expectations associated with these two areas. Acceptable speed-of-response rates differ between operational and analytical use cases. Often operational processes require some real-time processing. Think of going to the grocery store or ordering a product or service, you expect this particular process to take place in real time. When you use an online or mobile application, your tolerance for slow response actually goes down. With the ability to change providers/applications quickly, it is important to match the expected speed of response with the performance of the application. This means that if you integrate analytics directly into operational processes, the speed of analytical response needs to match the real-time nature of most operational processes.
The next issue is the time to implementation. When we think about the integration between analytical and operational platforms, we often think about how we incorporate either analytics into an operational platform or an operational platform workload into an analytical platform. This comes from the fact that operational systems and analytical systems often have different data models for the construction of data. To the untrained eye, the difference between normalized (3NF) and denormalized data models is minor. But in the construction of applications, this a huge gulf that is rarely crossed. Also, there are vastly different data consumer communities. Operational processes often go from A to B to C with a standardized process. Analytics often move from A to C to E to Q based on the results and require additional investigation to make the most from the platform. Bringing operational and analytical platforms together using an either/or approach takes a long time. We think of this in terms of 12-to-18 month type of integration efforts if we can even get them to meet those particular timeframes.
One way to overcome this issue is with “swivel chair” integration. This concept is one where we have one application in one environment and we have one application another. The user will then “swivel” in his/her chair from one to the next in order to integrate analytics into a particular operational workflow. In these cases, you have individuals who need to know both the location of the analytics and the analytical platform and how the operational process works. This may result in mistakes between integrating the right analytics into the operational platform or understanding the appropriate workflow associated with the operational platform. It is a very manual and error prone (but many times not filled) arrangement.
Another (much more reasonable) solution is called embedded BI. Embedded BI solves many of the problems just listed. Instead of fully integrating one application into another, such as taking our analytical platforms and making the new operational workflows or taking our operational platforms and making them do analytical processing, we integrate these at the point of the visual contact with the user. This involves taking analytical graphs, charts and reports that have been generated in the BI platform and integrating them into the operational platform. This type of embedded analytics allows you to separate the workflow process associated with your operational platform and the processing workload associated with your analytical platform. Users do not have to have the concept of swivel chair integration. You can integrate these components together into a single application, a single point of contact or a single view.
Currently this type of embedded BI is taking place across many different avenues. With the advent of HTML5 interfaces for operational platforms we see a web page brought into an operational platform’s user interface. Or with more detailed application programming interfaces (APIs), application developers can embed individual charts and metrics into an operational system. In both of these cases the ability to do the integration allows organizations to increase implementation times, avoid swivel chair analytics and enable the use of higher processing engines associated with BI platforms to enable this integration of analytics into our operational platforms.