Alerts vs Notifications – moving to a business focus
I have been doing some research recently on how the world of alerts has changed, and I am now a convert in the alerts vs notifications debate to the notifications team.
The change of terminology is not just cosmetic – to me it really represents the difference between a technical perspective and a business one, and the business one embodies so much more value.
My own memories of alerts stem from systems management tools, where if a monitor detected a problem an alert was sent to the operational bridge or perhaps some other node for action. This is a simpe answer to a technical problem – “I need to let someone know that something has happened, so they can work out what to do (if anything)”. But from a business perspective this is pretty damn inadequate. This ‘fire and forget’ approach of raising an alarm and then walking away is no good if there is a business reason to CARE about what might be done.
Notification is a different word – most dictionaries talk about alerts as ‘warnings’. In contrast, the Oxford dictionary describes notify as meaning to ‘inform or give notice to (a person)’. In other words, notifications are more about an exchange of information as opposed to turning on a warning light.
So what does this mean in real terms? Is this just a grammatical argument? The answer is – not at all. Notification software suppliers are focused not on just getting a warning out, but communicating with the ‘right’ individual to get some action to happen and tracking activity to resolution. Good notification software has to not only get the message to the target in the appropriate way, such as email, SMS text, fax or voicemail, but also has to be able to ‘close the loop’ in the whole process of reacting to the detected event. For example, what if the target person is not available? Can calendars be consulted? Is there a way to implement an escalation process? Can the recipient of the notification communicate status back? Is there a way for the notification to be officially closed when resolved?
If real business value is to be obtained from notifications, it is imperative that the whole notification process can fit into the overall operational workflow. For anyone interested in more about this subject, and the necessary functionality to make closed loop notifications work, Lustratus has just published a report, “Closed Loop Notification Software”, available from the Lustratus store.
Steve
Recent Comments
November 1, 2010 (8:36) CICS and PHP - DON'T PANIC It's great to see transactional support of any kind for a cloud language... be it PHP or not (whi...
July 16, 2010 (12:41) Does Micro Focus Server for SOA miss the point? I think Micro Focus has done a tremodeous introduction of Web Service from a COBOL. May not be a ...
June 15, 2010 (6:14) CICS and PHP - DON'T PANIC Hi Steve, Well, we don't actually *demand* that you host the PHP in regions separate to those ru...
April 3, 2010 (12:27) AMQP - Great idea, but it will never work As someone who has worked on DDS from an implementation perspective as well as an OMG standards p...
December 12, 2009 (9:15) Did Teilhard's JuxtaComm patent wipe out IBM, Microsoft and SAP? Subsequent to my post, the Calgary Herald ran an article (http://www.calgaryherald.com/business/P...
December 10, 2009 (9:01) AMQP - Great idea, but it will never work Now, this is a late reply! @Thorlin. I looked at DDS before embarking on AMQP (I also looked a...
December 7, 2009 (2:40) Come in Texas East District Court, your time is up The important thing to remember about patents is that they're all about the claims. While the bu...
October 27, 2009 (9:08) BAM vs BI Good article. Thanks, Emil
October 23, 2009 (11:04) So Oracle got Sun - but why? Oracle has stepped up the rhetoric when it comes to its plans for Sun. In a message to Sun custom...
September 16, 2009 (1:15) IBM gets Cognos to fill the gaps IBM has two BAM solutions now Cognos Now! and Websphere Business Monitor. Why two BAM solutions f...