There are so many things that can be described in this part. There is no straightforward approach in software design. It’s all about finding the right balance between many factors. However, if you’re writing SCOM report for yourself or for your fellow IT Pro sitting at the desk next to you, don’t worry – skip this part, get your vision and do it. If this is not the case, you’ll need to invest lot of time (sometimes even more than implementation takes) into planning.
Here are some tips:
- Think about the target audience. Who will use your report – IT Pros, executives manager or, probably, both?
- Think about the user’s intent. What is the most likely user’s intent when (s)he opens your report? What about very likely one? Or just likely? Or unlikely?
- Think about report’s scope. Are you going to report about any kind of object or some specific classes? Is your report generic or specific? Does it correlate with most/very likely user’s intent?
- Think about terminology. Some terms may seem obvious for you, but may mislead others.
- Think about reporting interval. Should it be just one point of time or an interval? Should it be in the past or in the future or both?
- Think about report parameters. Are you going to make your report flexible (many parameters) or easy to use (less parameters)? Where is the right balance? (Hint: don’t forget that you can hide some parameters using linked reports, so you can build both full version and lightweight version without duplicating efforts.)
- Think about design and layout. Are you going to build just one report? Or, probably, two? Or, may be, many? It is always useful to have your design guide handy. Don’t have one? Write it. You’ll need at least following: margins, fonts and colors for headers, footers, texts, links, tables, borders, charts (and many more).
- Think about your data retrieval strategy. How are you going to deal with SCOM specialties like data aggregation, different time zones, values that are not stored and should be calculated, data gaps, etc.?
- Think about performance. What amount of data should be processed? What is the affordable report rendering time?
- Think about extensibility. Are you going to reuse some calculation logics in other reports?
- Think about things that you never thought before. Don’t have any? Then rethink everything in this list twice. It is also a good idea to get another head (or two) also thinking about all this points.
Done? Congratulations, you have the deep understanding of what you’re going to do! And now you’re really ready to rock!