IBM Business Monitor V8 makes it easier than ever to offer insight into the health of your business, providing your business users with a variety of visualizations of the real-time state of individual business process instances, key performance indicators (KPIs), and sophisticated business intelligence reporting. Monitor model authoring has been significantly simplified, situation detection and alerting are easier to define, and dashboards are now richer and faster to deploy. Due to reduced complexity, new and improved wizards and generators, and a general lowering of the bar in skills needed to develop and deploy the monitoring and dashboards for your enterprise, projects can now be delivered in less time and at lower cost.
You can now more easily develop and test the monitoring for complex environments, while providing dashboards that are simple for your business users to use and understand. By answering a few basic questions in a wizard, you can have new visualizations generated for you, which automatically change color and icons based on the real-time state of the underlying thing being monitored. You can harness the power of Cognos multi-dimensional analysis and reporting by simply filling in a few fields, and quickly get powerful reports and charts with drill-down navigation.
Your dashboards are what your business users ultimately want to see and work with, and now you can have them automatically generated, so that they have real-time visibility without any time-consuming work of defining a mashup and manually configuring all of its widgets. This can be especially helpful during iterative development and playback, so that you can quickly test out if your monitor model is properly processing events and presenting the results in a way that meets the needs of your business users. Of course, you can further customize these generated dashboards as desired, for example by defining new KPIs, alerts, or Cognos reports, and displaying them within the dashboards.
A generated dashboard will contain multiple pages, depending on the monitor model. First, it will have a page per root-level monitoring context (MC), as shown in Figure 1, showing all of the metrics of that MC, plus drill-down links for any child MCs. Also, if that MC has an associated diagram, that too will be displayed, and its annotations will change as you click on different rows in the Instances table above it.
Figure 1. Instances page of generated dashboard
Next, it will have a page per KPI context (KC), as shown in Figure 2, showing all of the KPIs of that KC, in a half-gauge visualization by default. It will also have an Alerts widget below the KPI widget, showing any alerts for this monitor model, such as when any of the above KPIs go out of some desired range.
Figure 2. KPIs page of generated dashboard
Next, it will have a page per cube, as shown in Figure 3, showing all of the reports defined against that cube, arranged in two columns, and using the chart type specified in the monitor model.
Figure 3. Reports page of generated dashboard
Finally, if any KPI contexts reference a diagram, those too will be displayed with appropriate KPI-level annotations. One of the new features of V8 is that you can mark an MC, one of its metrics, or a KPI as hidden, and they will not be visible in the dashboards. For example, if the model needs to keep track of the value of some big hexadecimal string for correlation purposes, but seeing the value of such a metric would be meaningless and possibly confusing to the business user, you could mark that metric as hidden, ensuring that your dashboard users would only be offered metrics that are actually useful in their work.
Milestones are a new concept in the programming model for your monitor models. You can now group a collection of monitoring contexts (MCs) together, and represent that entire group as a single step in a virtual process diagram that will be generated for you. Such a collection of MCs is called a milestone. Using this approach, you can simplify how you present information to your dashboard users.
For example, if you're monitoring something that in reality has twenty different steps (represented as MCs in your monitor model), but your business users only really care about four important points along that flow through the twenty MCs, you can present to them a picture that just shows those four important steps so that they're not unnecessarily exposed to the true complexity of the enterprise environment being monitored.
In Figure 4, you can see that the Automated Approval and Manual Approval MCs have been grouped together into a single Loan Approval milestone, shielding the dashboard user from having to understand how it was decided whether the loan would be approved, and instead just showing them the result.
Figure 4. Milestone wizard
The generated diagram, as shown in Figure 5, shows the order in which the milestones execute, including any steps that "fan out" to multiple steps, and anyplace that they "fan in" from multiple steps to a single step. It also is automatically annotated to present real-time information to the dashboard user, such as whether each milestone is on track (green), at risk (yellow), overdue (red), or complete (blue), and showing that milestone's key value and the amount of time spent at each milestone.
Figure 5. Annotations for the milestone diagram
Milestone diagrams are supported at both the instance and the aggregate level. Figure 5 shows an example of an instance-level diagram, where the annotations in the diagram vary depending on which row is selected in the Instances table above. Instance-level diagrams show how long that particular instance spent at each milestone, and milestone key values specific to the selected instance. The milestone diagram generator will also produce a KPI-level diagram, whose annotations shows aggregate data across instances, such as the average amount of time spent at each milestone and the number of active instances currently at each milestone.
It's now dramatically easier to perform end-to-end monitoring across your
enterprise, tracking the thread of execution across a variety of disparate
event sources. In past releases, this was only feasible if a common key
existed throughout everything being monitored, such as an
orderID, but in V8 it's easy to monitor
environments where each thing being monitored has its own unique key
value. All you need to do is answer a few questions in a wizard, as shown
in Figure 6, telling your monitor model how to correlate an instance of
one root MC with an instance of the next, and the system automatically
uses that information to follow the thread of correlation at runtime as
those instances are monitored.
Figure 6. Multi-key correlation
For example, imagine you're monitoring travel expenses. You might have a Flight MC keeping track of your airline expenses, a Hotel MC keeping track of your hotel expenses, and a Car MC keeping track of your rental car expenses. The wizard will generate a global Travel MC for all travel expenses (and by default will mark the original MCs as hidden - though you can override this if desired), and will generate a (hidden) UUID as the key for the global Travel MC, and will keep track of the mapping of the key values of the Flight, Hotel, and Car MCs to that UUID.
Bringing it all together, if you had a milestone per MC, the generated dashboards would show a box for each original MC, annotated with its key value, in the generated milestone diagram underneath the Instances table for that generated global MC. So, for example, if instance #4 of Flight corresponds to instance #8 of Hotel and to instance #15 of Car, your dashboard users would see a picture with a Flight box annotated with #4, a Hotel box annotated with #8, and a Car box annotated with #15, as shown in Figure 7. The dashboard is able to track and display all of this information even though each Flight, Hotel, and Car is unaware of each other and there is no common Travel ID metric present in the MC for each.
Figure 7. Annotated milestone diagram in dashboard
You can now quickly and easily define your dimensional reports at authoring time. Just give your report a name, pick a measure and a dimension, and choose a default chart type, and you're done - it's that quick and easy to create a Cognos report now!
Figure 8. Report authoring
You can define as many reports as you like, and they'll all be present in the generated dashboard, pre-drilled down to the first level of the specified dimension. For example, if you have a Location dimension that consists of country, then state/province, then city, the report in the generated dashboard will use the specified chart type and will be automatically drilled down to show all countries; you could then drill down on one of those countries to see the states/provinces within it, and so on. These generated reports, based on what was specified at monitor model authoring time, will automatically be configured to show 3D shading and other customizations, so that you end up with a page of professional-looking reports per (non-hidden) monitoring context.
Also new in V8, the choice of cube measure types is no longer constrained to those supported by AlphaBlox (now that AlphaBlox has been replaced by Cognos Business Intelligence 10.1.1). This means new aggregation functions are available, including median, count distinct, and variance. Median is not as affected by outlier values as Average; for example, given values 1, 2, 3, 4, and 90, the median is 3, whereas the average is 20, which clearly was heavily influenced by that one outlier value. Count distinct will return the count of the unique values of a list; for example, if you have 100 instances, and 20 of those have a Status metric with a value of Available, 30 have a value of In Progress, and 50 of which have a value of Completed, a count of the status metric would return 100, whereas a count distinct would return 3, since there are 3 distinct values of the specified metric. Variance is a measure of how far apart a set of values is; similar to standard deviation, it can help you understand how close the values are to the average. In V8 all of these new cube measure types are now available in your reports.
Business Monitor now enables you to easily define how to detect time-based business situations, so that you can take action not only when something happens, but also if something hasn't happened yet that should have. It's often just as important to alert someone about something that should have happened by a certain time and hasn't as it is to alert them about things that have happened.
There are two new options available in V8 when defining a time-based trigger: daily and specific date/time, as shown in Figure 9. Daily will cause the situation to be evaluated at the specified time of day each day; this can be useful if you need to check things an hour before the markets close each day, or before your packages are picked up each day. The specific date/time triggers allow you to check something at an exact date and time of your choosing, such as at 6:00 AM local time on May 4th, or at a calculated time, such as when something else occurred plus four hours.
Figure 9. Time-based triggers
In past releases, such functionality could be simulated by having each
active instance check once a minute whether the desired time has arrived.
However, that had serious performance implications if you had a large
number of active instances, since evaluating a time-based trigger costs
roughly the same as processing an inbound event. For example, the new
daily trigger is over 1000x more efficient (checked once a day, rather
than every minute of every hour of the day). Also, it makes it easier to
specify what you want at authoring time since you don't need to add gating
conditions to your triggers to compare the current time to some
dateTime literal value.
The dashboard Alerts widget also offers some new features in V8, as shown in Figure 10. You can now filter or sort on the monitor model that generated the alert, so if you only want to see alerts related to your Loan Processing monitor model, you can do so. Alerts can also have a default owner, so even if no one has subscribed to the alert, you can be assured that someone will receive it. Alerts now have a priority, so you can filter out low-priority alerts, or see them sorted to show the highest priority alerts first. Finally, alerts now have a status, which can have values of Available, In Progress, or Completed, and you can filter or sort on these values as well.
Figure 10. Alerts
In this article, you've seen how IBM Business Monitor V8 lowers the bar on skill requirements, improves time-to-value, and provides a rich experience for your business users. Regardless of what kind of event source you're monitoring, you can take advantage of all of the new features described here by migrating to this release. You can also take advantage of newer levels of prerequisite products, such as IBM Integration Designer V8, WebSphere Application Server V8, DB2 9.8 pureScale, Oracle Data Guard 11g, and newer fix levels of browsers and operating systems. IBM Business Monitor V8 provides your business users with powerful and compelling dashboards that provide visibility and insight into the performance of their business as it runs across their enterprise.
- Participate in the discussion forum.
zone: Get the latest technical resources on IBM BPM solutions,
including downloads, demos, articles, tutorials, events, webcasts, and
Journal: Get the latest articles and columns on BPM solutions in
this quarterly journal, also available in both Kindle and PDF versions.
John Alcorn is the lead architect for the IBM Business Activity Monitoring (BAM) platform. He has worked as a software engineer with IBM for 19 years, with more than 14 years on WebSphere products, including roles in both product development and software services. John has been a technical leader with the IBM Business Monitor product for seven years, and works closely with the wider IBM Business Process Management (BPM) team.
John is IBM-certified in XML technologies, SOA technologies, and in multiple WebSphere® products, and is Sun-certified in Java™ programming. He is currently privileged to work with an excellent team of software engineers at IBM's Research Triangle Park lab in North Carolina.