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

----------------------------------------------------------------------------------
Postings in the same series:
Part   I – Why use them?
Part  II – How 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.