Monday, June 27, 2011

Distributed Applications (DAs) – Part III: Do’s and Don’ts

Postings in the same series:
Part   I – Why use them?
Part  IIHow about DAD?
Part IV – Tips & Tricks  

In the first two postings of this series I talked about DAs in general and what role DAD (Distributed Application Designer) plays here. The third posting in this series will be all about the do’s and don’ts when creating DAs. There is much to tell, so let’s start.

Do’s and Don’ts
Would be cheap to start a header with the Do’s and another with the Don’ts since these two are the opposite of each other so I have grouped them together under one header. I leave it to your imagination whether a certain item is to be grouped under Do or Don’t :).

  • Communicate
    When you create a DA you want it to be successful. The DA will be created in order to serve a certain purpose so it’s key to communicate with the stakeholders in order get a clear picture about:
    • Out of what components/servers/services is their service/application made of?
    • What do they expect from the monitoring solution? (Manage their expectations as well. (Better to start small and grow bigger than to start with a castle and deliver a plain house. The latter won’t be understood and kills the DA in the process since it doesn’t live up to the expectations.)
    • What do they want to be monitored?
    • Do they need monitoring on a functional and/or technical level?
    • What do they expect to see in their Monitoring Views? Performance Views? Alert Views? State Views? Diagram Views? Dashboards?
    • Do they expect integration with SharePoint?
    • Do they expect third party tools like Savision LiveMaps or – closer at home - Visio?

  • Documentation
    • Write down what has been communicated;
    • Make some mock-ups like drawings (PowerPoint is a great tool here) so the stakeholders know whether what they told landed properly. It’s easier to change a drawing than chancing a lot of DAs;
    • Based on the drawings you’ll also know what’s already in place in SCOM and what isn’t. This way a list of action items can be created in order to cover those as well (or not, based on the required investment in order to get the missing objects into SCOM).
    • When the initial building of the DAs starts, document it like the DAs, Components, whether some Monitors have been changed or not.

  • Divide and Conquer
    When creating a DA covering a certain service/application look at your mock-up: can it be covered in one DA? Or is better to work with Top Level DAs, Aggregate DAs and Sub-DAs? This way a service/application can be cut down into the parts that are crucial like certain services, databases, scheduled jobs, workflows and so on. When something goes wrong with a certain part, it’s easier to pinpoint the issue as well.

    Again, PowerPoint can be a great aid here, like this:

  • Naming conventions, Descriptions, Management Pack, Versioning
    • Naming Convention
      When creating DAs and Components keep in mind that Objects will be created. For SCOM the name isn’t leading but the GUID. So one can create tons of Objects (DAs and DA Components) with the SAME name! This creates much confusion. Therefore think up a naming convention so every DA and DA Component gets a unique name WHICH also tells what it’s meant for.
    • Description
      Every DA has a field for a Description. USE it! Seriously. This way you’ll still know the what the DA was meant for, even after a year. Also think up a convention here so the descriptions will have the same syntax.
    • Management Pack
      Put the DAs and the lot, meant for covering a certain service/application into a dedicated MP. That way the DAs and its related components can be used to their fullest extend.
    • Versioning
      I know. Version numbers are only enforced in SEALED MPs. But even in unsealed MPs version numbers play an important role. This way one knows what is happening with the MP containing all the DAs. It goes without saying that Versioning only works when good documentation and saving/keeping the previous versions is looked after as well.

Basically, when you want to create crappy DAs which are short lived and looked upon something nasty to be found under your shoe, DON’T communicate, DON’T document, put everything in ONE DA, DON’T use naming conventions, descriptions, versioning and don’t design anything. Just open DAD and be surprised how fast a flawed DA is created! In the matter of seconds! :)

In the fourth and last posting in this series I will share some good tips and tricks, like avoiding some potential pitfalls and how to get the ‘flow’ (health rollup) going when things seem not to work as intended.


Anonymous said...

Marnix, I really like this series about DA's. For some time now I was looking for a way to create basics for my Service Level report. The way you describe it seems very easy. Could you please state what you mean with the process and workflow aggregate in the Powerpoint sheet?
Please also explain how I am able to change the default behaviour of having only availability in the rollup as stated in part II. I also need the performance items in my toplevel/sublevel components.
Kind regards and keep sharing!

Marnix Wolf said...

Hi Fonz55.

Thanks for your comments. The fourth and last posting in this series will take the deep dive and explain (among other things) how to involve performance items as well.

About the PowerPoint sheet, with the aggregates for Process and Workflows I mean items which are going to be monitored in a given DA. I have made this sheet up, so it's a mere 'fanatasy' used to ilustrate what I mean. Customers wouldn't be happy with me when I share their stuff, so I have to make things more general.

But for what I have seen, sometimes DAs have to monitor an inhouse build business critical application which exists out of many different layers. In situations like that it's better to carve the DAs in such a way that they reflect those very same layers. A layer could be workflows for instance. This would become a DA as well. Since that DA will contain ALL the the workflows used by that same business critical app, I look upon that DA as an aggregate DA for ALL workflows. This DA is put into the top level DA as well which is a kind of an aggregate as well but more at toplevel than detail level.

Hope this clears things up a bit. Let me know when more information or clearification is needed.


Marnix Wolf said...

Hi Fonzz55.

One thing to reckon with is that DAs by default don't collect data for Reports, simply because DAs don't contain Rules but 'only' Monitors.

Rules are required for data collection in Reports.


Anonymous said...

Hello Marnix,

chee you are blogging early :-) Thanks for the clarification. I agree with your experience at other companies. Some applications can have a complex architecture with many layers. So if one could create some kind of hierarchy in the DA structure one can link them in the master or toplevel DA.

Having read more Service Level articles on this blog (amongst other subjects it is getting more and more clear to me what type of components/objects/terms to use in our SCOM configuration.
Anxiously I await the fourth and last posting in this series.