My last column introduced the concept of a real-time decision-making system that enables business users to react rapidly (ideally in real time) to changing business conditions and, where required, automate the decision-making process. Three underlying business intelligence (BI) technologies support near real-time and automated decision-making: a data integration server, an on-demand analysis server and a rules engine.
A data integration server captures and transforms operational data and loads it into a near real-time data store (i.e., a data warehouse whose data currency is close to that of operational systems). This technology could be used, for example, to build an operational data store (ODS) that integrates customer data from all the customer touchpoints throughout an organization. Data latency in the ODS may vary from a few seconds to many hours, depending on business requirements. The ODS could be used in a front-office application such as a call center to provide current customer status information for making day-to-day operational decisions. An example would be to identify high-value customers who are to be given priority service or a better discount.
An on-demand analysis server reacts to requests from users and applications for business analytics for tactical and strategic planning and decision-making. The analytics produced by the server can also be used as input to a rules engine. An analysis server may be implemented using vendor-provided packaged analytical applications, by in-house applications built using OLAP and data mining tools or by a component-based BI development tool. Commonly requested analytics will be prebuilt by the application, but less commonly requested analytics might be calculated dynamically. The main objective of an analysis server is to convert raw analytics stored in a data warehouse to actionable analytics that put the warehouse information into a business context that can be acted upon. For example, the raw analytic, widget sales today = $20,000 could become the actionable analytic, today's widget sales were 30 percent lower than forecast.
A rules-engine is used for operational decision making. The engine employs actionable analytics and business rules to generate and deliver personalized alerts and associated business intelligence to business users or to generate and deliver action messages for processing by operational applications. The alerts and messages may contain notifications, warnings, recommendations or suggested actions for handling a particular business situation. If widget sales fall by 30 percent, for example, the appropriate business users could be informed or the rules engine could generate an operational message to lower the price of widgets by 10 percent.
A rules engine is normally invoked based on actionable analytics produced by an analysis engine; but it may also be called dynamically in real time by a user or application for help in making business decisions, whether to grant a client a loan or credit card, or to assess the risk of a specific business transaction, for example.
The business rules used to drive the rules engine may be entered and maintained by business users and analysts or generated by a tool such as a data mining product. Rules engines are embedded in a number of software products including Web application servers and business intelligence tools (where they are sometimes called intelligent agents). There are also several vendors who develop and market sophisticated standalone rules engines. Examples include Computer Associates (CleverPath Aion BRE), HNC (Blaze Advisor) and Pegasystems (PegaRULES).
To fully exploit the power of a decision-making system, the analytics, recommendations and actions must be related and integrated with the overall business process. One way to achieve this integration is through business process automation (BPA). The best way to explain the use of BPA in a business intelligence environment is by using an example.
Figure 1: Automated Decision-Making Workflow Example
The top part of Figure 1 shows a simplified operational workflow for processing a customer order. This workflow can be used to determine the points in the operational process where business activity needs to be monitored by a BI system. Application and data events can then be captured at these points and used to populate an ODS and/or a data warehouse. Event capture can be achieved directly in the application itself, in an integration broker or at application and data interfaces (database API, application API, EJB interface, user interface, etc.).
If an analytics workflow in a rules engine in the BI system identifies a business situation that requires action, the business user could be alerted and passed an action workflow to help diagnose the problem and determine what action to take. If automation is required, the action workflow could be embedded in the rules engine, which would generate the appropriate action messages to be sent to the operational environment. Gartner Research uses the term "business activity monitoring," or BAM, to describe this integrated and dynamic real-time environment.
We are likely to see increasing use of workflow and associated business rules to help integrate BI into the overall business process. This is one reason why workflow and rules engines are being added to integration brokers and application middleware. For some examples, look at Compaq's ZLE solution, the Mercator Integration Broker and Vitria BusinessWare. We are also seeing these technologies being integrated with BI tools. For an example, take a look at how products from SeeRun Corporation are integrated with data warehousing and BI tools from Microsoft and ProClarity.
From a business intelligence and data warehousing perspective, it is important to realize that the term real time is the latest industry term to become abused in vendor marketing literature and campaigns. The move toward real-time BI processing must be related to business needs and to what can be achieved by current BI technology. In general, "real-time" should be considered to be a marketing term, and realistically you should not equate real-time BI with the sub-second response times we have become accustomed to in operational transaction processing.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access