TBSM v4.2 GA’d last Friday. Are you ready? Have you thought about what your plans are? Just another upgrade? Keeping things status quo? I advise you to not do that.
TBSM’s fundamental operating dependency is the Netcool/ObjectServer and its core operating principle is one being primarily event driven. A limited use license of THE leading event management platform is provided with TBSM v4.2 so in all realities, you will need to become proficient in two industry leading products and not just one.
Events can be ANYTHING. I view events merely as the vehicle for communicating something – data, information, metrics, KPIs, state, status, etc. ANYTHING. Netcool/OMNIbus offers very broad capability for collecting and consolidating events from hundreds and hundreds of sources. Using our “Swiss Army knife” probes, the sky is the limit in terms of what you can collect events from. Something blinking green in the datacenter, a valve, refrigerator, generator, business process/activity, whatever, we likely have a way to get event information. Netcool/OMNIbus SHOULD NOT BE considered just an IT monitoring tool, reserved only for network or systems monitoring event collection!
If you believe this, and your end state goal is to establish a consolidated operations environment where we abolish silos of information and consolidate the islands into an aggregate repository, your long term success with Business Service Management is heading in the right direction. In the case of traditional IT organizations, collecting events, alerts, messages, traps, notifications, etc. from any of the various silos in IT is crucial. Check the politics at the door and reach out to your colleagues and figure out how you can leverage this new TBSM platform to start on this integrated and consolidated journey.
Every client’s goal using TBSM should be to leverage the features that enable the automatic creation and maintenance of the complex service models within their environment. If you fail to find ways to use these features, your patience with TBSM will wane over time. You do not want to manually build and maintain service models! IT environments change too dynamically for you to ever have a chance to keep up. If you’re fortunate to have made investments and had successful deployments of application (or network) discovery and mapping tools or successfully deployed a CMDB, asset management, inventory or other repository/database that enables you to establish relationships and dependencies between things in your environment, you’re on your way to a pleasant TBSM experience over time (assuming you can negotiate permission to access those data repositories).
Chances are though, that you don’t have the fancy discovery tool or the CMDB project is in its third year of a five year project and you can’t get access. Your company probably frowns on the use of open source tools that may help get you started and the ‘hit by the bus’ scenario just happened to the one guy who knew everything about anything.
How can you get started? Let me chat about a few very important things you can think about doing.
Establish a uniform, standardized event format
Spend some time getting a basic understanding of how you will establish the various hierarchies within your environment (organizational, service, architectural, etc.). The goals here are to establish an event format that can help us build these hierarchies automatically.
Start looking into your existing monitoring and management solutions, their capabilities and the event information generated. How could you best configure these products or parse raw events to establish a normalized event format that will enable the use of TBSM’s autopopulation feature? As you learn about Netcool/OMNIbus, the alerts.status schema and probe rules files and lookup tables you will find numerous techniques for parsing and populating fields in your normalized event format.
Think about adding fields for each level of your hierarchy:
LineOfBusiness | BusinessService | BusinessApplication | Location | BusinessImpact | BusinessSLA | TransactionName | BatchJobName | CommonName | etc.
I’ve talked extensively on the importance of events numerous times in my past blog postings. Every ounce of effort and energy you put into this area will pay off enormously when it comes to service model creation and maintenance. I can almost guarantee it!
Establish an internal “CMDB” of sorts
The most successful implementations that I’ve seen of the TBSM product include integration with some sort of relationship repository. It doesn’t need to be any of the big CMDB solutions out there, and in all cases I’ve seen it’s not. These successful clients are building simple databases with simple table structures to capture the most important relationships in their organization. If you’ve made the effort to map some of this out within your organization, build your snazzy spreadsheet or Visio drawing, get that data into a repository where it’s usable to TBSM!!
There are two main classes here. The business perspective (top-down) and the IT perspective (bottom-up). These databases are establishing the key relationships and touch points between these two perspectives. Most clients are starting out with the containment model approach for technology and migrating into service and application oriented containment models. None of the most successful clients are implementing the end-to-end service or data flow model concepts where detailed relationships and dependencies are captured. This approach most definitely requires investment in application discovery and relationship mapping solutions, detailed instrumentation across the entire end-to-end service delivery architecture and a detailed data model for storing within the consolidated repository.
When we have something like this available, we can make use of standard event enrichment capabilities of the Netcool/Impact product to help build our normalized event format or utilize the powerful TBSM ESDA feature to build and maintain the service models automatically.
Investigate Tivoli Discovery Library Adapters (DLA) and other Vendor Product Data Export
From a Tivoli product perspective, the Discovery Library Adaptor is a powerful mechanism for extracting key information and relationship information that can be consumed by products like TBSM and TADDM. In TBSM’s case, if you’ve got significant coverage using the standard ITM 6 monitoring product across your open systems and mainframe environments, you could use the DLA to do much of the heavy lifting associated with service instance and basic containment model creation within TBSM.
In most cases, you’re probably going to have many other vendor tools and products across the environment. I’d recommend taking an approach of exporting core configuration data from these tools and consolidating it into the central repository mentioned above. The DLA’s from Tivoli products could also be merged into this repository rather than TBSM directly enabling creation of a consolidated “CMDB” for the monitoring tools organization and TBSM.
Closing Thought
Just let me say one more time how critically important events are for your TBSM implementation. If you have them, and they’re in a useless format or are not communicating a useful message, you’re in for headaches in numerous TBSM development areas. If you don’t have events for everything (monitoring gaps), you’re not going to be able to build the complete picture within TBSM. If your events aren’t trustworthy and reliable, I promise that the end users will not use your solution after the “crying wolf scenario” plays out a few times. If you show something to an executive and it’s not accurate, forget about getting any value from this investment or getting that maintenance renewal.
Shameless plug
IBM Tivoli Services and our TBSM AAA Accredited Business Partners are always available to help advise and consult with you in these areas. Please do not hesitate to contact me at anytime and I can help arrange further discussions.
Comments on this entry are closed.
Great write-up on the importance of events. Can you generate events from TBSM which are enriched with TBSM’s correlation information, for consumption by some reporting tools. We would like to see if any BI tool can consume those events from TBSM.
regards
Raj
Yes, absolutely. We’d just archive those off from OMNIbus using an ODBC gateway to Oracle, DB2, etc. From there you can use BIRT, TCR, Jasper, Pentaho, Crystal, etc.
Doug
Hi Doug,
I was searching some information on TBSM on google and happen to get to this site and found quite a lot inputs. and thanks for sharing such a good information..
I’m working on providing Netcool solution for one of he prospective customer, where in we have a requirement to Integrate TBSM with BMC Atrium CMDB haiving data populated by BMC topology discovery tool, I could not get anything on this sort of integration on the internet, can you let me know if we can integrate TBSM with BMC CMDB from where we can create/automate Service Modeling if /possible who easy or difficult to achieve this integration?
prashanth
Prahanth,
The best option at this time is to export data from Atrium into your own database structure representing the level of detail needed for building service models. From there, you can easily use the autopopulation or ESDA rules to build out service models automatically.
Look into the Atrium Integration Engine as a more elegant way to get data out of or integrate with TBSM. I do not know of anyone doing this directly at this time.
HTH,
Doug
Hello, Doug,
D o you have any update information on how to integrate Atrium CMDB with TBSM ? Now we are working for a project and this is the largest issue for us.
Thanks
Jerry
No formal integration planned at this time. The current recommendations are to export needed information from Atrium via the Atrium Integration Engine / API to a simple database & schema that can easily then allow datafetcher based AutoPop and ESDA rules to work. If you have the information on Atrium (schema, API, etc.) I’d be happy to help you.
Doug
Hello Doug,
I have a Challenging situation for me with respect to TBSM,
Current Configuration ::
i have 10 process ( situations) created for a server… if one of the process is down a event is triggered & TBSM picks it from omnibus and changes the colour of the server to red.
Required Configuration ::
however the requirement is if all the 10 process goes down the server should be down ( or turn red). if any of the process goes down it should turn amber and
please throw some light on this…is this possible in the TBSM ???…….. it would be of great help for me. if possible plz let me know your mobile number i will call you and i have a project deadline of next week plz…help.
Many Thanks in Advance
@naveen,
If the processes are very important, you could simply create a new template and associated instances for processes and have them as children to the server. Then you can simply use a child dependency rule with a % based configuration to control when the server is red or yellow. You’d need a specific event for each process instance for this.
If you do not want additional instances and children beneath the server, you’ll have to write more complex rules to look for and track the number of process events you have active for the server and then set the output state red or yellow as appropriate. You can do this within an internal formula rule with a policy. The policy would contain all the logic to query OMNIbus, find process events, and determine whether to return a red or yellow state to the parent. Much more complex than the above approach.
HTH, ping me if you need more help!
Doug
I’ve integrated TADDM with TBSM and Impact is used for correlation and event generation in Object Server. Though I can see the event is generated in Object Server and can see them in the AEL or Event Summary but this is not reflecting the Service View. Do you know what could be the reason