• Alarm Deferring – Experience shows that operators start reviewing certain alarms only when they persist in sounding for a specific amount of time. For example, when certain radio links are down, operators usually wait two minutes before further investigating the alarm. Deferring allows the hiding of such alarms for a set amount of time, so operators know that once they do sound, attention is required. Manual deferring is also available, for times where an alarm needs to be "snoozed".
• Alarm Toggling – For those times where problems toggle or "flap" rapidly or briefly, flooding operators with alarms that are automatically resolved in a few seconds – sometime going unseen. Toggling "freezes" those faults, making sure the operators are aware of them and preventing them re-occurring.
• Alarm Repeating – When certain events only matter when they reoccur above a certain frequency, Alarm Repeating allows you to set just this threshold and determine when alarms should be presented, based on the number of times they sounded in the past minute, hour or even day.
• Parent-Children Relationships – Introducing hierarchy into the event list reduces clutter and better presents problems and their root-cause. Be it a topological, business, containment or other relation type - Parent-Children allows operators to create, modify, rearrange and break families of events. Operators can show all family members, only parents, and orphans (children whose parent no longer exists). Designed as a system-wide mechanism, families can be created automatically using impact policies or automations, and co-exist with ITNM and NCIL, root-cause relations.
• Message Dispatcher – A single hub mechanism for all messaging needs (e-mails, SMS's and even fax messages) makes sure critical events won't go unnoticed. This is done using the customer's existing message dispatching software.
• Group Repeating – sometimes a certain number of events, residing simultaneously in the object server, is the only real indication of a critical fault (such as in the case of multiple redundant servers). Group Repeat makes it possible to mark those events in groups and raise faults only when they occur together.
• ScheduleSet – Some events can be safely disregarded depending on a schedule such as a late-night maintenance window, a public holiday, weekends, etc. ScheduleSet mechanism allows associating such schedules with events and either discard them or defer them to the end of the schedule window.
• Heartbeat – for those devices and data sources where "no news" can mean "bad news," the Heartbeat mechanism is able to point out awkward silences, based on individual data-source reporting interval expectations. For example, if a device does not generate an event within the given time, one is generated to raise an alert, letting the user know that the device may not be functioning correctly.
Head-On Breeze is a tailored version of IBM® Netcool®, addressing the common needs of operators. Breeze allows operators to reduce the number of alarms presented and time to resolving them - using the various included automatic, semi-automatic and manual tools. Breeze is presently used by a number of customers, including the Israeli Air Force, HOT Telecom (a triple player operator) and Cellcom – Israel's largest cellular operator.
The Netcool solution by IBM addresses the needs and concerns of network operators. It provides the means to answer questions such as:
Is my network doing OK?
Where is a fault taking place?
Who is affected?
When did it last happen?
Who is responsible for getting it fixed?
By augmenting event data, and providing it in the right context, operators can substantially reduce the MTTR (mean-time-to-repair) and make a big difference.
Breeze by Head-On makes this difference even bigger by providing an additional set of features. Some of these include:
In designing Breeze, we deliberately placed a strong emphasis on re-usability and inter-operability. We made sure to combing functionality of different features within the solution (e.g. a deferred repeating event or a toggling heartbeat message) with other parts of the Tivoli/Netcool suite (e.g. Netcool/Impact, TADDM, TBSM, ITNM, etc.)
Breeze combines tools and services adaptable to specific Tivoli/Netcool deployments.