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. |
|
| 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. |
|
| 3. |
Redundant Logging. Rapid utilization of free space on disk. |
|
| 4. | Configuration changes are not dynamic. |
|
| 5. |
Lack of Administration tools. Support teams either perform application administration manually or spend time and money on developing tools. |
|
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).
