It's your turn for the dreaded rotating assignment: application support. Just thinking about all the things that could go wrong strikes fear and dismay in the heart of every technology professional. No one wants to spend hours searching through log files and exchanges between departments and with end users, investigating load failures and data issues.

Supporting applications is challenging work that can be made manageable with the proper approach. The keys include a clear process flow, a well-documented notification/communication plan, proper operational documentation, adherence to development standards and capturing critical information during incidents. This column focuses on some of the things that can help deliver top-notch application support, especially in a multiapplication environment.

Support issues and incidents arise from many different sources and might require help from more than one resource. Often, a case will be passed between multiple groups. A well-documented process flow illustrates when and how exchanges should happen. Process flow diagrams help clarify responsibility so the right group is working on the right tasks. Different flow diagrams should be created for different tasks, for example, user access requests, report creation requests, report schedule requests, user-reported data issues and internally raised data issues.

Support personnel will encounter a wide range of application problems and exceptions. Resolving these issues quickly and accurately helps instill end-user faith in the application. In some cases, good communication is as important as fixing the issue quickly and correctly.

Understand and clearly document the ways that different issues, will need to be handled, for example login issues versus questions about data. In a typical flow diagram, each bar represents a department. The tasks, decisions and communications are connected by arrows that depict movement in the same group or between groups. Flow charts like this work well to explain support process flow.

The communication plan, closely tied to process planning, should be well-defined and thought out. Communication occurs between groups on the IT side and also among different user groups. The plan should list the groups to be notified when specific events occur, the frequency of those communications and what the messages should contain. Keeping involved parties informed and updated about progress and expected completion and resolution is the most important piece of the communication plan.

At a minimum, the centralized document repository should contain the following operational documentation for each application: the required software, user/password information, operations manual, contact list, communication plan and process flow diagrams.

New application development should adhere not only to development standards for ease of code support, but also to standards for notifications for both success and error handling. When individuals support multiple applications, especially applications they may not have been involved in developing, the document repository plays a valuable role. A consistent approach to finding documentation, displaying what sections exist in an operations manual, locating log files and pointers to error resolution will make a positive difference.

What do you do when those who came before you have not adhered to the same coding standards in legacy applications? Sometimes not much can be done to fix existing code, but new independent processes can be put in place to make up for shortcomings. Independent scripts and code that check data after processing and alert operations to potential issues can be quick and easy fixes for code that lacks proper notification functionality.

There should be a centralized location to record incidents and document the steps taken to investigate and resolve problems. This is not a new concept. A lot of software applications (many of them free) handle this task. But as is true for all manual data entry, you'll get out of it what you put into it. Spend time thinking about the information that should be captured - what tables or programs were involved, the underlying problem (e.g., source data or program bug) and how the issues were resolved. Name the programs where the problem was found - name the tables and fields that were involved. Thorough documentation ensures that if the issue is encountered again, everyone can understand how it was fixed last time.

One of the best ways to gain application designer or architect skills is to learn from support responsibility, so think of your application support assignment as a career experience, a chance to become a better architect and developer. Compiling the processes and documents above will make the tour more successful. As with everything, searching for ways to continually improve processes will also help.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access