Systematic Reuse Success Factor #6 – Address Support Needs

How often you have worked on a project that didn’t consider support needs? I bet your quality of life as a developer was largely influenced by this factor. A supportable application makes a world of difference. Your reusable assets are no different in this regard. Reusable assets need to be robust against failure, scale up to handle additional volume gracefully, and provides relevant runtime metrics for diagnostics and troubleshooting.  Here are some common requirements for support:

Handle errors appropriately – this could mean logging, notification alerts, integration with existing support tools, or even calling a particular person.

Instrument reusable assets – log error information, runtime data parameters, processing/transaction metrics, system variables and provide an interface to access all this stuff

Design for things to handle runtime failure – can you use an alternate path to fulfill a request? Can you store requests and process them after a time window? Even if you cannot do any of these, throw the error and report it. Never swallow exceptions

Report metrics – provide standard metrics reports as well as ability to perform ad-hoc queries.

Integrate errors with issue tracking when applicable – Link known errors happening in production with the relevant issue from the issue tracking system. Make it easy for the support person to know that it is a known issue, possible workarounds, and escalation paths.

Regardless of whether your team or an external group supports your applications, the support requirements need to be addressed. Without addressing supportability your reusable assets won’t be reliable, robust, or dependable.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

3 Responses to Systematic Reuse Success Factor #6 – Address Support Needs

  1. […] file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their […]

  2. […] Unwillingness to question key design assumptions (e.g. not considering ill effects of tight coupling between entities or systems) and not addressing support needs. […]

  3. […] Think about logging, remote debugging, tracing, reconstructing incident state, etc. and provide integration with tools that they are already familiar with for existing apps. You may not need to or want to expose too […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: