As a part of my job I spend a lot of time on thinking not only about some particular MP design aspects, but about the user experience provided by management pack in general. My typical questions are:
- How will customers adopt the Management Pack?
- Will it be a smooth user experience?
- How will SCOM Admins collaborate with other teams during planning and implementation phase?
I’m asking me. I do that because I don’t want to see a forum thread titled like “How did they think I should use this <censored>“. I do that because someday I may meet guys who are using the product I have designed, and I don’t want to get pale or find myself seeking for a place to hide just because I missed something in the product’s design.
I can recall some days in the past when I was tuning SQL MP for a production environment. What I faced is the lack of knowledge of how it really does the monitoring. I had to do a reverse-engineering to get a better understanding of what I can do. Also, I had no tools to measure the overall health of the environment. I couldn’t say if I’m doing better or worse. I had nothing to guide me through that journey. I had a strong desire to start a thread like one I have mentioned above.
Product. It’s a key word for this blog post. As far as I understand, there are three typical kinds of SCOM Management Packs:
- Developed by the vendor of the product being monitored. These are usually distributed for free. Microsoft MPs are good examples here.
- Developed by 3rd party vendors. There are many MPs of this kind as well: For Oracle and DB2, for VMware and … hm… VMware :), good and not-so-good, big and small.
- MPs developed by community members and private in-house made solutions.
I’m not going to discuss #3 here, let’s concentrate on #1 and #2.
MPs developed by the vendor of the product being monitored
Who is the owner of all knowledge about the product being monitored? Who have all details about how it was designed? It is the vendor. But, unfortunately, vendor may have an internal segregation, teams may have their own goals and KPIs. Their own deadlines and plans. And the truth is: Management Pack may be handled as a low-priority feature.
It’s great when MP is considered as a feature and not as just “something that should be done somehow”. It’s great when product team understands who is the target audience for the MP. It’s great when product team tries to introduce a new value via SCOM Management Pack.
MPs developed by 3rd party vendors
From some points of view, these guys may be better than previous. 3rd party vendors may afford concentration on the market and target audience. MP is their product, so they could manage it accordingly. These vendors tend to offer full coverage, cool features and shiny interfaces. But they are focused on those who buys and rarely give a glance on those who work with their MP, their Product.
So, generally speaking, 3rd party vendors may do a better job in terms of providing better coverage or better MP design. Nonetheless, if they do not consider all kinds of activities related to the use of their product, they are not better than those guys from the group #1.
Where is the sin? Where is the worst practice?
The problem I try to outline here is that many vendors do not consider SCOM Admins, those guys who install and configure MP. Many vendors do not provide enough details (if they give any) of how the Management Pack works, how this or that monitor or rule is built, how that given workflow can be tuned, what is the meaning of that overrideable parameter, etc., etc., etc… Many vendors do not share knowledge. And that is exactly what their product is. SCOM Management Pack describes the monitoring model. It is the knowledge about how monitoring could (not should, but could) be done. It is the knowledge.
For me that looks like a portion of product’s target audience has not been considered. That looks like vendors offer “enabling the monitoring” as their product, but do not think that a management pack itself should be a part of the product too. And the funny thing is that this product strategy makes a Management Pack unmanageable.