HPSU 2009 - Part 6 - What is OMi?

OMi - What is it really?!
There's been a lot of confusion (on my part as well, I must confess) about what exactly OMi is, and how it works. On the plus side, I've just had a great chat with one of the developers & two of the solution architects to help me finally understand what it is, how it works, and why you might want it.

First things first - OMi is a name only appreciated by the marketing team because it has caused mass confusion - OMi is NOT the next version of OMW in the way that NNMi is for NNM. OMi is a "layer-on-top" tool that enhances your troubleshooting & root cause analysis capabilities for OMW/OMU (and OML?) and comes as part of the BAC suite. By purchasing & installing OMi you get BAC, and must install & operate the BAC server. So this loops back to those still running OVIS and wondering about what they'll need to do about moving off of it (topic for upcoming post - OVIS migration to BAC).
If you want to make use of OMi you need to do a couple of things...
1. Have OMW or OMU running with all requisite SPIs
2. Get your NNM up to NNMi (unless you don't have it, then skip this step)
3. Install BAC & OMi (kind of one step...)
4. In installing BAC & OMi you by default install uCMDB, which must now be configured
5. Run the automated configuration tool to pull the data from your OMW/U tool to populate the uCMDB
6. Start to configure your dashboards and views

Of course, I've grossly over-simplified, but it's a roadmap to get you started. As always - if you have specific questions you'd like me to answer or thoughts you'd like to share on any of this please reply to the postings!

HPSU 2009 - Part 4

OK, I'm taking a change of my normal pace here and I'm going to be a bit brutal. I just attended a breakout session by Paul Salamone, Technical Architect with Lockheed Martin on BAC optimisation tips & tricks.

Clearly naming conventions are the key tip &/or trick Paul has to share with us. Paul’s not a very dynamic speaker, and out of the gate we were getting some pretty obvious information; I suppose it's good for anyone who hasn’t played with BAC before. A lot of discussion centred around object and BPM naming conventions for the first 10 minutes…

Tips like:

Adopt a naming scheme

Distinguish your objects from o-o-t-b objects

Use biz unit names in your object names

Use app identifier acronyms

BE CONSISTENT

Profile Related Objects

Add the full name for objects seen by users

Just the acronym for objects not seen by users

An interesting conversation spun out of Paul's comment to "Put a BPM in your data centre (as well as distributed) – use it as a baseline to compare WAN performance vs. LAN performance." Now while this is standard info provided in any BAC training it triggered an interesting discussion in the Q&A session at the end. Question came up to be hypothetical about having your BPMs only centralised and whether this would be effective, which is a moot point because centralising all your BPMs defeats the purpose of having the BPMs. The only reason I can see for this is saving money by having fewer BPMs. I give Paul full points for arguing against this principle as I agree whole-heartedly with him on this

More of Paul's advice is to use the first couple of weeks to set a baseline for your thresholds and adjust quarterly (I question this, because you should really measure against known business cycles – i.e.: retail, finance, manufacturing, etc.) Al said, it's still standard practice with any implementation.

On the topic of the dashboard Paul advised to restrict the dashboard to trained users – why? To keep users from panic if they don’t understand how the app works. Well, if you set your thresholds well & have a solid promotion and knowledge management supporting the deployment this shouldn’t be an issue.

If you want to use the Geographical Map set the BPM Source Adapter to Transaction/Location – RTFM.

Paul discussed the use of worst-child vs. percentage rule, and why one would be used versus the other – again this is beginner stuff because any experienced OMW/NNM person understands the difference and why it’s important to reduce false positives.

A useful tip from Paul was to use profile names as a way of hiding objects – placing (HIDDEN) or some other key word in the front of the name allows you to use filters to block those items from general public view.

Back to discussion about naming schemes, this time for scripts.

Two useful tips came up under the scripts discussion:

Add logic to script to fail all transactions if one fails

Use multiple service accounts IDs with long password expiration

Paul completed in 30 mins; once we got to Q&A, a question came up about SLM actual response time vs. % good transactions – Paul suggested that they use the actual response time for SLM instead of % good transactions. But didn’t explain why. Conversation moved to principles around how to organise SLAs.

Qty of servers was queried because two disparate environments built up & they are In the process of merging.

Asked about their mechanism for deploying BPMs, and the response is that they build them centrally & ship them out physically with a monitor as a desktop system. Ideally it should be more of an appliance build of a system. They allow the BPM systems to receive any updates/patches that any other workstations do. Again no explanation of why the decision was made. There’s certainly very strong arguments against using the methodology of treating ALL your BPMs as standard corporate desktops…

All in all, I was disapointed - I think the title of Paul's session had me expecting more of a deep-dive into technical gotchas, not advice on naming conventions.