By Design for Supportability (DFS), I mean designing a product with adequate features  to facilitate administration, support, maintenance  and problem diagnosis. DFS is not just a methodology, it’s a way of thinking for design and development.  This post will pertain to Application Software Design. The basic principle of DFS should be applicable to all product designs.

Benefits of DFS:

  • Increases probability of error detection in the testing phase, thereby leading to a better quality product.
  • Quicker resolution times for incidents and root cause analysis, thereby leading to an increase in customer satisfaction.
  • Smaller support teams, thereby leading to a reduction in the total cost of ownership (TCO).

    Given below are some typical problems experienced by Application Support teams and how they may be addressed/avoided by DFS:

SL# Problem experienced by Support Team How it may be addressed by DFS
1. Inadequate logging. No errors in logs.
  • Use a good logging framework and a well-structured log syntax (eg. log4j) for application logs.
  • Segregate application and server logs.
  • Handle all application exceptions and log descriptive errors, rather than allow errors to be directed to standard error/output.
  • Add debug to critical paths/exit statuses within the application to facilitate troubleshooting problems when debug is enabled.
2.

Logging severity levels cannot be changed at runtime. e.g. to enable debug for the application, the application needs to be redeployed or the underlying server restarted.

  • Use a good logging framework which permits runtime changes (eg. log4j)
3.

Redundant Logging. Rapid utilization of free space on disk.

  • Log adequate details, as required by the severity level. Nothing more, nothing less.
  • Data logged must be in accordance width data privacy/confidentiality laws.
4. Configuration changes are not dynamic.
  • If the application is customizable and driven by configuration files, then as far as possible, dynamic changes to configuration at runtime must be allowed. The more changes to an application that can be made without redeployment/server restart, the better.
5.

Lack of Administration tools. Support teams either perform application administration manually or spend time and money on developing tools.

  • Some applications require ad hoc administrative actions to be performed (eg. process a backlog of messages, resubmit messages, track messages, restart data feeds, etc.) or regular maintenance (eg. housekeeping).
  • Application administration tools must be part of the application deliverable. Spending time and effort on these tools during the design and development stages will pay rich dividends for the in-life support of the application. Also, the designers and developers will be best placed to build such tools.
  • As far as possible, application administration tools must be built to be customizable and automated (eg. as scheduled jobs). The lesser manual intervention by Support teams, the better.

 

How to implement DFS?: If you understand the concept of DFS, you’ll know what’s required to implement it in your project. Here are some guidelines to assist with implementation of DFS.

  • Design for Supportability requires dedicated resources across all teams (design, development, build, testing and support) to work together with utmost cooperation, bearing in mind the ultimate objective – a superb application.
  • Design and Development teams must involve Application Support teams in the early stages of application design (a key requirement for DFS). This will enable the Support team to get an early and good insight into the application and provide feedback with respect to Support requirements. Typically, design and development teams feel it unnecessary to involve Support/Testing teams during the design phase and Support/Testing teams feel it unnecessary to spare resources for the design phase. For DFS to work, this mindset must change.
  • Application Support teams must be involved in the testing phase wherein apart from normal use cases, as many abnormal use case scenarios as possible must be tested. This testing must also cover application administration tools. The Support team must follow a systematic approach to simulate real-world scenarios and test various aspects of the application from a Support perspective and provide feedback to the Development team.

    To all you Application Support folks out there: Spread the word on DFS among your design and development communities. It will make your job easier. DFS should help achieve economies of scale in your Support projects and open the door to new opportunities. Well, there will always be some human presence required (customers won’t want to interact with machines).

VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)