DBMS - February 1997 - Notification Systems

Notification Systems

By Stewart McKie
DBMS, February 1997

Could the advent of notification systems mean the end of reporting as we know it?

Imagine you are a general commanding a complex battle with many fronts involving many different combat arms. Would you prefer to command using periodic sit-reps (situation reports) from your officers on the ground, or would you like to know the exact position and status of key troop formations and equipment in real time? Ideally, you would want both, but in reality you can only expect to get the sit-reps. Business managers are in exactly the same position. Most of their business management applications can only deliver reports, not realtime notifications of significant business events. The good news, however, is that more sophisticated technology and the recognition of the potential of notification systems are prompting more vendors to add this functionality to their applications.

Reports vs. Notifications

To understand the role of notifications, let's start by defining the role of the traditional report. Just what exactly is the purpose of the types of report that we get from the typical software application? You could classify reports as:

audit trails of activity such as transaction postings, user logins, or table updates
lists of items such as charts of accounts, employees, or inventory items
exception reports such as top-10 customers or lowest-profitability items
business status snapshots such as income statements and balance sheets
"rich" content-briefing books that combine text, charts, and tables

Each of these reports is typically produced sometime after the fact. Although you may produce reports on an ad hoc basis, for report types 3 through 5 it usually makes sense to produce them periodically (at the end of the day, month, or quarter, for example). Reports are by definition a collection of information within a particular information domain. One of the benefits of a report is the contextual richness that it supplies to the reader. Although you can schedule reports to run automatically, you usually produce them on demand, which means that they depend on the "pull" effort of a user. You may deliver reports on paper or electronically, either as attachments to email messages or via an Internet browser inquiry. Reports usually represent the logical end of a business process.

On the other hand, notifications occur as the result of an event. The event may be a system event, such as the addition or failure of a component, or a business event, such as the posting of a particular transaction. As with reports, there are various types of notification. For example:

informational notifications: "Your Login was successful"
prompt notifications: "You should backup your system now"
alert notifications: "Your conference call is due in five minutes"
assistance notifications: "A better way to achieve your objective is to. . ."
exception notifications: "Item # 99 has reached its reorder point"
workflow notifications: "Please approve invoice # 99"

Usually, notifications are generated automatically by the software application immediately after the event that triggers the notification has been recorded. Notifications are typically not context-rich; they only provide information specific to the notification event. The deliverable from a notification is usually an electronic message or action generated under system control that requires no user input and that may signify the beginning of a whole new business process. For further detail, refer to the online version of this article on the DBMS Web site, www.dbmsmag.com. The first table (See Table 1) shows the six components of a notification, and the second table (See Table 2) compares notifications and reports.

Using Notifications

Notifications can be used in a variety of ways to change the way that users interact with systems and the way that systems interact with one another.

Notifications help enable an exception-based business-management paradigm because they use alerts and exception notifications. This should reduce the number of reports that need to be run and help managers cut through "info-glut" and focus on items important to them.
Notifications help ensure that applications are utilized correctly through the use of prompt and assistance notifications. These notifications force users to carry out actions they may otherwise ignore or forget and to investigate alternative, possibly more efficient, ways of using application functionality.
Notifications help deliver greater value from a simple report through the use of mining engines that interrogate report files, apply business rules, and then generate a multiplicity of notifications as a result. The value of a single report becomes much greater because the information it contains can be exploited more effectively and in a shorter period of time than may be possible by a human "reader."
Notification systems can be used to populate universal inboxes or Web pages that can act as information "consoles" to provide a particular view of the business relevant to the needs of the recipient authorized to access the inbox or Web page. This usage lets recipients avoid the need for expensive application licenses.
Notifications can be used as a means for delivering better application integration through the passing of data packages between applications. They have a role in facilitating extended transaction workflows that may cross multi-vendor application packages. This process helps make more effective use of, and leverage more value from, the business's software assets.

A notification system offers more than just business alerts; it offers a fundamentally new way to manage and participate in the business.

Implementing Notifications

A traditional way of implementing notifications in database systems has been through the use of triggers. Problems with this approach include the following:

high-volume transaction systems that use notification triggers extensively could seriously impact overall database performance because of the volume of trigger events being managed
triggers typically contain business rules or fire stored procedures that contain business rules, which means they can be difficult to maintain in a complex application
triggers are asynchronous in operation, which means that an application must wait for one trigger to finish before the next can start

One solution to these problems is to make the trigger itself into a simple event-notifier service located on the database server. The role of the trigger is simply to make some basic information -- for instance, action Y (insert) occurred on object Z (invoice_table) -- available to a separate object or agent that can then "evaluate" the event's business implications. Making triggers into event notifiers ensures that they are stripped of their business rules, simpler to code and maintain, and faster to run.

SQL Financials International Inc. (Atlanta, Ga.) is taking this approach as the company rearchitects its accounting applications into business object components compliant with Microsoft's COM model. The "evaluator" function can be run as an OLE automation server or the database server, or it can be located on one or more application servers on the network in order to provide scalability if required. The evaluator object encapsulates the business intelligence to apply appropriate business rules to the trigger event. The evaluator then hands off an action to another "dispatcher" object that determines how the impact of the trigger is communicated to the application or its users. For example, the dispatcher may return a message to the application client, send an email alert to a user, or dispatch an RPC to initiate another application process.

Another way to implement notifications is as an administrative service managed by the database. This approach is taken by Microsoft Corp.(MS) in SQL Server 6.5 with its new Server Alerts function. The basic premise of this functionality is to let people know when specific database errors have occurred so that they can take remedial action if required. For example, you can set up alerts in SQL Server to be triggered by certain server error numbers or by class of error (severity level). Alerts are communicated to operators -- system users visible to the database -- via email or pager messages. An alert may then instantiate a task to carry out a process, such as an operating system command, a replication distribution command, or a Transact-SQL statement. Finally, you can schedule your new task to run on demand (when called), once, or recurring (according to a predefined time schedule). This type of database notification service could make the SQL Server DBA's job a lot easier. It clearly has great potential for use in generating application alerts.

Application vendors such as Platinum Software Corp. (Irvine, Calif.), and no doubt many others, are already planning to exploit the MS SQL Server Alert capabilities. The 4.0 release of the Platinum SQL accounting suite includes enhancements to its existing Financial Alerts function that will take advantage of MS SQL Server's Alert capabilities. Leveraging the Alert functionality is another example of why MS SQL Server is proving a popular database choice for application vendors in the accounting market. It would be much harder to provide the same level of functionality from other Platinum-supported database engines, such as the Sybase SQL Server. Platinum has predefined a number of financial alerts that its users can decide whether and how to use through interacting with Platinum SQL's Alert Wizard, which guides them through the decision process. The wizard lets users define which alerts to use, the frequency at which they can be run, who is sent the alert messages, and what message they are sent via a MAPI-compliant email system. If the alerts included in the box are not sufficient, you can define new alerts using Platinum's Customization Workbench.

Other business alert systems include Oracle Alerts, which can be used in conjunction with Oracle Applications, and SBT Corp.'s (San Rafael, Calif.) WebAlert product, which is used with SBT's Pro Series 3.0i accounting suite.

Report-Driven Notifications

Single-event, single-response notifications can add real value to any business that can benefit from this "realtime" aspect of notifications; report-driven notifications, however, deliver yet another level of sophistication. Here a report's contextual richness and focus can be combined with the proactive benefits of notifications. In this case, running the report process is the event that initiates a notification -- or, more accurately, the notification workflow. The report is not printed but is stored as a file, relational table, or multidimensional cube that can then be mined by agent software using business rules and an existing knowledgebase to look for notification "justifications" in the report data. Users may never see the report, only the notifications that result from the mining operation.

Using a weekly sales analysis report as an example, the mining software and notification system could:

identify high-volume products so that an email can be sent to the inventory manager to ensure that these products are in stock or an electronic requisition is generated to order more stock if levels are low
identify high-performing stores or salespeople so that a congratulatory email can be sent or a management to-do item created to deal with under-performing stores or people
identify interesting sales trends by comparing the report data with the historical knowledgebase and formatting the information as an HTML page that the notification system can link to the territory manager's Intranet home page
extract the sales data and export it into "snapshot" database tables or multidimensional cubes for further analysis that the notification system could route to the appropriate servers

Running the report first, rather than mining the database directly, may be a more efficient approach because the report already forces one level of business intelligence onto the data extract. The mining engine is then running against data that is already "focused," and so business rules can be applied at a higher level of abstraction. Clearly this powerful combination of conventional reporting with mining and notification agents could become a whole "invisible" subsystem that sits beneath any conventional application. Suddenly a report is no longer the end of a process but the start of a whole new added-value workflow.

Computron Software Inc. (Rutherford, N.J.) provides this type of report-mining notification functionality through a combination of its COOL (computer output on-line) and workflow technology. Reports from Computron's Financials system can be stored as files using the COOL technology, which compiles meaningful indices from the report data. These indices can then be mined by the business-rule-driven workflow engine to trigger a range of useful notifications. In turn, the notifications could initiate new workflow processes or be communicated to users as email messages via a MAPI-compliant email system. Computron's workflow engine makes use of notifications itself as part of its work item state management and workflow queue management. For example, managers can be notified if items in a workflow have been left unattended for over a certain period of time or if work needs to be distributed to a wider range of participants.

CODA Inc. (a subsidiary of the CODA Group, PLC, Manchester, N.H.) recently purchased technology from an Icelandic company that combines a notification system with a workflow engine to deliver real-time business information from its integrated accounting database. Because CODA already operates a realtime accounting paradigm -- all tables are updated as soon as a transaction is posted rather than relying on after-the-fact batch processes -- CODA believes that notifications will add even more value in its environment. For example, a cashflow report typically requires data to be collected from receivables (AR), payables (AP), and general ledger (GL) modules before it can be produced. CODA can use its notification system to alert managers of potential cashflow problems before they occur because its single-ledger architecture lets the notification engine gather up-to-minute data from AR, AP, and GL modules altogether without requiring any batch processes to be run to first update the information. Consequently, CODA is well placed to exploit the transition to the realtime enterprise and expects to release its new notification module in mid-1997.

Data Delivery Services

Another approach to notifications is being taken by Blue Isle Software Inc. (Lowell, Mass.). You can use Blue Isle's InTouch/2000 product to service other business applications by providing them with data extracted from "feeder" data sources either on demand or at scheduled intervals. InTouch can access Microsoft Access databases and any file structure or database supported by the Access data-export function. Once you define the data extract logic, the event can be scheduled and the data package routed to its destination via an email system or FTP file transfer. Currently, InTouch is focusing on automating the delivery of data to OLAP tools such as Pilot Software's Analysis Server, Cognos PowerPlay, or Arbor's Essbase. InTouch can provide a means for automating the dissemination of personal data "cubes" to managers for desktop analysis or keeping multidimensional data warehouse and datamart servers populated with the latest summary data from transaction systems. In addition to the delivery of data packages, InTouch can be used to generate conventional notifications such as alerts and other event-driven messages.

Another Differentiator

As users of business applications become aware of the added value that notifications can deliver, notifications will become another important differentiator among competing applications. More sophisticated database technology (along with more demanding application users) is one reason why notification systems are more practical to implement now than they were in the past. In addition, the widespread implementation of email and connectivity to the Internet facilitates notification routing and participation in notification-initiated workflows. Finally, as business applications are redefined as collections of business objects, we can expect notification methods to become a standard part of every object's basic functionality, providing one means of communicating business intelligence to collaborating business objects.

Stewart McKie is principal of PinPoint Inc., a financial software consulting firm based in Redmond, Washington. He also edits the CFO/Info newsletter. You can email Stewart at 74660. 3123@compuserve.com.

Listing 1: Defining Notifications

Component	Description
Event	The event that triggers the notification to take place. Simple events may be the insert, update, or delete of table rows. More complex events may be the running of one or more stored procedures to produce a specific result that can trigger the notification.
Schedule	When or how often the event should take place that triggers the notification. This may be on demand, according to a time-based schedule, or automatically based on a database event such as an insert, update, or delete.
Condition	The rules that determine what type of notification takes place. Simple conditions may be to trap values that are greater than or less than a threshold. Complex conditions may include IF. . .THEN. . .ELSE constructs or even the use artificial intelligence techniques such as neural networks or fuzzy logic to apply complex business rules.
Action	The action taken as a result of the notification being generated. A simple action is to generate a message to send to a user or group of users. A more complex action may be to trigger another process to take place, to insert, update, or delete rows in a table, or to initiate a completely new workflow process.
Package	The package of data that may be required to be routed by the notification. This data could be an image, spreadsheet file, data table, or word-processing document for example that is dispatched with the notification message (if any).
Message	The message used to communicate the notification to a user. A notification may be just the message itself, the message plus a package, or an action that is also communicated via a message.
Routing	Who receives the notification based on the result of rules associated with the notification event. Routings may be internal or external to the business and may reach single users or groups of users. Notification systems usually depend on the integration of email, telephony, or the Internet with applications for effective routing.
Delivery	How the notification package or message should be delivered by the notification -- for example as a database table, an email address, a pager, a fax number, or an HTML page.

Listing 2: Reports vs. Notifications

Characteristic	Report	Notification
Initiated By	user	system
Mode	reactive	proactive
Timeliness	periodic	immediate
Exception Handling	low	high
Delivery	paper (traditionally)	electronic
Workflow	end of process	start of process

Please send questions or comments to dbms@mfi.com
Updated Wednesday, January 22, 1997.