Postings in the same series:
Part II – How about DAD?
Part III - Do’s and Don’ts
Part IV – Tips & Tricks
----------------------------------------------------------------------------------
Even though DAs can be hyped, they really have a lot of added value. But there are certain things to reckon with when using DAs. In a series of postings I will talk more about DAs and share some best practices.
But first things first. In this posting I will talk about DAs in a more general way. Later postings will be more technical.
Why should one consider using DAs?
I mean, you’re already monitoring your servers operating systems, Virtual Infrastructure, network, SQL, IIS, DNS, AD and the lot. So monitoring is already in place. Why add more like DAs for instance? Because it looks sharp? Has a nice ring to it?
No way. Because until now you’re monitoring components. A whole bunch of them. But many times business critical processes, applications and ICT environments are groups of those very same components. Wouldn’t it be nice to know when SQL server A bites the dust that Business Critical Application XYZ is still functional but when SQL Server B bites the dust it’s time for some action in order to prevent a real outage of the same application? 
When one is monitoring components, the logic behind it all and the knowledge which SQL server is part of what business critical application or process is hard to find. If lucky at all, some people know it. But many times, they don’t. So how to translate the severity of a SCOM Alert to a level which reflect the business?
Things change dramatically when some monitored components are logically grouped/combined. Now everybody knows what components do make up a certain business critical application or process. And this is where DAs do come in and have a lot of added value. 
Bringing SCOM to the business
At the end of the day, SCOM is facilitating Monitoring. Helping out the organization. So SCOM should go to the organization instead of the other way around. Many times ICT departments are approaching many things over the technical axis and expect end-users of SCOM to do the same. Approaches like these are doomed to fail simply because SCOM doesn’t add much value here. Only for the technical staff.
But what about Service Managers? They don’t give a sh*t whether a disk is full or not. Whether SQL dies or not. They want to know the status of ‘their’ services, are they still available and functional? With a single glance on a screen without the requirement to cycle through all kinds of Views.
So SCOM has to facilitate that in order Service Managers do get the kind of information they really need. This way SCOM will hit a different layer in the organization, outside the technical areas.
Which is good, since many times the decisions for the budgets are made here, not on the technical level. So when the (Service) Managers are aware of the added value of SCOM changes are that budgets will be available for it as well. Whether you’re talking money or resources, both are really needed in order to get SCOM to the next level and keep it there…
Are DAs magic?
No, they aren’t and sometimes outright a bit buggy. But when one knows these potential pitfalls and how to address them, DAs can be shaped to your will, or better, requirements of your organization. 
Even better, DAs aren’t the last station. When one builds DAs in a smart kind of way, the components of the DA or the DA itself can be reused in Dashboards so the way DAs are displayed is totally up to you, thus removing the Diagram View limit in the SCOM Console. For more about Dashboards, check this series out.
How to go from here?
Easy! Just follow my blog and soon new postings in this series will come out, all about building DAs and how to use them to their fullest extend. So stay tuned and start building DAs!
No comments:
Post a Comment