#WorstPractice – SCOM Management Pack Design: Too narrow, too wide, too complex, too simple

How do you choose new shoes? Cheap or expensive – which is better? What do you prefer: change the pair every quarter or have one for years? There is no answer that will fit everyone. Probably, a good answer is “it depends”. It depends on the overall climate and current weather; it depends on how you commute – by foot or car; it depends on what is your personal need and your personal preference. And if you have access to a good local store, you just go there and make your choice. (Or do that online if you’re an ubergeek.)

The same story about monitoring solutions and management pack – everybody wants MP to meet their needs. However, the market is different. In many cases, you will not see any competition here. If product’s vendor gives a complimentary SCOM Management Pack for free, each and every product’s consumer will at least give it a try. Because it’s free. If that’s not the case and there is no free version of the MP, you’ll probably find someone who chased the “partner opportunity” and sells the solution you want. But the key question here is: will it meet your need?

The sad thing about both free and paid options is that, most probably, they were designed with some “average requirements” in mind. Do your requirements belong to “average” zone? Nobody knows. Neither you nor MP vendor. (Did you ever met with MP developers in person? I mean developers, not those folks who do support or sales or management. No? Neither they did.)

When you choose shoes, you put it on and just feel if it fits or not. What about SCOM Management Pack? Okay, you know how to put it on, how to deploy it into your lab environment. But how to “feel” that it is what YOU need?  I’m the guy “from the other side”, who discusses features to be implemented on a daily basis, who sometimes has to say “let’s postpone it” or “okay, we will not support this configuration”. In this post, I’m sharing some tips about how to “feel” a Management Pack.

Note: You will not find many technical details in sections below. These sections contain some thoughts about things I recently referred to as “worst practice”. These worst practices are about MP as a product, not about MP as a set of bits. Although management pack should be technically well-designed to simplify IT operations, reduce mean time to resolution and so on, it is not technical design that makes MP not just good, but great.

Things we’ve never thought about

Worst Practice: Ignore “corner” cases.

Who does Management Pack development? Developers. Who uses it? IT Pros. Developers and IT Pros are guys with different experience, with different view point, with different needs and priorities. Sometimes they do not understand each other, and someone should play in “interpreter” role. Someone should listen to end users, keep an eye on current demands and drive an evolution. The major point here is that an “interpreter” (project/product/program manager) needs someone to tell him if something wrong or missing. They can’t give you a proper tool if they don’t know what you need.

Let’s assume you don’t like something in a Management Pack. SQL Server Backup monitor, for example. You need it to support some other monitoring scenarios. But if you’re keeping silence, “interpreters” will never know about your needs. I can recall many cases when some great ideas were found on community forums or even engendered from night dreams. After some time, these scenarios may seem obvious, but nobody knows that it is really required before it is brought on the table.

Call to action: When you test a new MP or a new version of old MP, evaluate your needs as well. Does the MP give you exactly what you need?

Back to the Future

Worst Practice: No ways to do historical/retrospective analysis.

It’s like food: when you don’t have it, you dream about it. When you have plenty of food, you want it to be tasty. When you have a lot of tasty food, you want it to be delicious. 5 or 7 years ago it was great to have visibility. Probably, not 100% and not exactly what we need, but it was reducing the workload. Now, when we have better tools, we need more. We have accumulated historical data and we want that data to do the job. We want insights on the infrastructure, we want to measure the change, we don’t want to guess anymore. We heard many words about growing data and shrinking budgets this year. Indeed, blind guessing is not an option today, confident decision is a mainstream demand.

Unfortunately, SCOM reporting part hasn’t changed a lot since 2007, so we’re still playing in the same sandbox. Some months ago I’ve heard the opinion that users don’t need it. I’ve recently started a survey about SCOM reporting and dozens of people already responded. Why would people do that if they don’t need it?

Call to action: When you test a new MP or a new version of old MP, check out reports as well. Can you analyze your historical data in a way you need?

Important me

Worst Practice: Ignore user and user experience.

Do you work overtime? I did when I was a DBA. Of course, there are always things that cannot be done during normal business hours. But there are also tasks that just take too much time. Your time. The “see alert context” approach is a good example. I know many other examples and I feel really sad when some guys tell me something like “in this case user can click here, open another windows, switch to the third tab and get that information”. That could be okay when you need to walk through that path once a month, but how could we know that someone else will not need to go there dozens of times per day?

I believe that IT monitoring and manageability solutions should not ignore user experience. Of course, senior admins can do everything via command prompt or powershell. But what about non-senior or even junior guys who haven’t obtained that skill set yet? I think that their families and work-life balance are also important and shouldn’t be ignored.

Call to action: When you test a new MP or a new version of old MP, verify that it provides sufficient level of User Experience for all users, not just those guys who know things by heart. Also, pay your attention to the number of manual actions required to troubleshoot typical issues.

It’s all about balance

Worst Practice: Too narrow, too wide, too complex, too simple

This is the last “worst practice” in my list. The most important and the most tricky. Indeed, the management pack shouldn’t be:

  • Too narrow – few organization need just basic monitoring with no insight on historical data;
  • Too wide – nobody likes noisy MPs which raise an alert for every invaluable event;
  • Too complex – do you have time to read hundred pages to understand how MP works?
  • Too simple – do you still think you do not have any “specific” requirements? Do you still think you will be satisfied with the lack of monitoring flexibility?

Finding the balance is tricky, many things should be considered, many voices should be heard and many lessons should be learned.

There is no call to action in this part. I just hope that my voice will be heard too. I prefer SCOM Management Packs to be rich and flexible, yet easy to deploy and use. I want every and each user to be considered by development teams. I hope that we’ll see many great MPs next year. Not just good, but great.

… Finally …

In this post, I tried to share some tips about how to “feel” a Management Pack. Though I’m not using SCOM Management Packs on a daily basis and in most days I do not touch SCOM console; I spent most of my time thinking about MPs and SCOM end-users. That’s my job and my passion. Want to help me? Then follow the final “call to action”.

Call to action: If you feel that Management Pack doesn’t suit your needs, if you want a given MP to bring more value for you, then don’t keep the silence. Get on the stage and make sure “other guys” hear you and listen to you. Make sure that your new shoes will not be too tight. Because YOU are important.

What about you? Tell your story in comments!
More worst practices.

One thought on “#WorstPractice – SCOM Management Pack Design: Too narrow, too wide, too complex, too simple

  1. Here is one question that ALWAYS merits consideration when determining management pack value and scope… “What am I going to do about it?” (Whether you are the developer or the customer)

    For example:
    Monitoring _Total CPU usage is a “great idea” but “what am I going to do about it?” In my experience, many don’t know. 1) reboot 2) close the alert and hope it doesn’t come back 3) this is normal so do nothing.

    A rule or monitor without an accompanying action is useless. Even if you can’t “fix” an issue…If there is no review of the trend, it is still valueless. This is a good place to leverage company knowledge as a customer and Product Knowledge as a developer.

    In the case of _Total CPU, even if you can’t do much about the CPU issue at hand, you can see the trend and use as a diagnostic and thus performance collection is a great value where the alert “might” not be.

    Review the rules/monitors one by one and ask yourself “What am I going to do about it?” When the monitor/rule raises an alert… now what?. The balance between simplicity and complexity is met where corrective action can be taken or knowledge gained by being able to analyze the data. If you can’t/won’t correct it, review it, or do anything with it then disable it.

    As a developer ask “can my customer take an action on this or learn from collected data?” As a customer, if you keep disabling rules/monitors and writing your own, give feedback.

    (NOTE: Even when Performance Data is valuable, collecting it comes at a cost and should be realistically evaluated as to what will be used and what wont be)

Leave a Comment