Pragmatic Software Design

Too many projects wait till the very end to think about supportability. Your system or solution will not magically become supportable overnight. It is critical that your design efforts meet support needs. Here are some questions that will influence your design:

• How will production support get notified of exceptions/incidents? Do they need notification real-time or periodically? You might need a notification component. Depending on your requirements, the component might need to send alerts/messages to one or more parties. You might also need to support sending messages to different destinations (mobile phones, support consoles).
  
• What information needs to be provided in the application-specific logs? Error location, error code, stack trace, possible causes, and resolution information needs to be captured. Additionally, application specific logs might also capture time of error, machine name, and runtime statistics such as heapsize/thread usage etc.
  
• How will an exception get resolved? Are there errors that need human intervention? Is there a need to pause transactions and resume processing when exceptions are resolved? Returning contextual and actionable information is essential in these cases. Depending on the volume and error categories you might want to design a facility for viewing exceptions and resubmitting failed transactions.
  

Equally important is the need to include as much detail about errors as possible. Without adequate details on the error it is not possible for your support staff to act on an issue. These needs become even more critical when pursuing SOA and BPM initiatives. Your supportability needs to extend beyond a single application and your ability to track events and transactions across multiple applications become critical. As more systems get integrated, it becomes imperative that your support staff is educated about error detection, resolution, and escalation.