Most of the discussion in the previous article was about operational issues. Something is broken, something is affected, something has gone wrong somewhere and it needs fixing now or soon.

This is known as incident management.

Apart from the usual “fixing what’s broken”, when we get time we look at old issues that results in ongoing incidents. After a while we can see patterns in incidents as they are raised and we group them into problems. We create a problem record, we perform root cause analysis and we either fix it or we don’t. If we don’t we record a known error and move on with our lives.

Interested in more? Download an ITIL book from somewhere as its all in there. We follow that framework to about half of the extent we tell people we do.

We get a multitude of requests from our end users be they internal or external to our organisation. Sometimes we get requests for items that are nothing to do with us but we helped them previously so they expect we can do everything (a common side effect of being customer focused and good at what you do).

It’s our job to keep the lights on. Sometimes that is fixing what is broken. Other times it’s replacing something that someone else has broken. When we have numerous interfaces to other organizations we can’t go through life expecting everything to stay constant. An old Greek philosopher once said “The only thing that is constant is change”. So we are somewhat at the mercy of other organisations with our budget and workloads as they do their own upgrades and decommissions and we have to adjust our systems and business processes accordingly. Sometimes with little notice. Sometimes with no budget (we call that creative accounting).

Enhancements
One of the most time consuming task that I involve myself  in is the enhancement request. End users have a myriad of ideas on a better way to do things. Some of them are valid, some of them are invalid and some of them are just “out there”. But each one of them requires (deserves) a response. The end user has taken the time out of their day to put together a request so they at least deserve a response and a purposeful one at that. As an IT department that is trying to justify its existence to the business we have to let the users know we are there and listening to what they say and more importantly responsive to what they want.

Do I do all of the enhancements? Do I do none of them? The answer is actually somewhere in the middle (but closer to the none end). My support officers record each request into our register and give it the status “Pending Review”. Then when time permits we evaluate it in more depth by asking the requester some more questions (first point of contact that shows we are listening). We may engage someone else from the business who is familiar with this area to get a “second opinion”. They may agree with the suggestion or they may not. On occasion this has revealed that its not required and is perhaps a training issue and the correct functionality already exists. Its rare that we don’t pick this up and somewhat embarrassing when we don’t since we are the super-users (but it happens, and we smile apologetically).

If it turns out to be a valid suggestion,we hand it to our development team to do a technical evaluation. At this stage it’s more of a Order Of Magnitude (OOM) assessment determining if it is a small, medium or large piece of work. This translates to free (part of a support release), within our budget capability (meaning a paid package will be generated) or expensive (meaning funding will need to be sourced and a project will need to be stood up).

Sometimes when the upper management decide we need to be more responsive they will give us some funding to do a group of enhancements on a single system. After all its cheaper to run a single block of test cases, requirements documents and implementation plans than to create one for each enhancement. So we pick a system, contact the business owners and start the process to commence a project.

I have to be clear that this then falls outside of my unit and becomes part of the project world. We aren’t part of the project world. We are part of the operations world. Generally the two only intersect during transition from project to support.

So back on topic. The developer has done their technical assessment and comes back with an assessment that says we can squeeze it into a support release. These are usually changes to a drop down menu, a screen label or some very minor functional change. It’s from here we assess the total business impact. A requester may ask for a field to be made mandatory to assist them with their reporting requirements. Sounds fairly innocuous but imagine if everyone wanted a field made mandatory. It then turns out that filling in a form that used to take 5 minutes now takes 3 hours as you have to fill in everything even if you don’t have an answer for it. Our end users will make something up and can be quite imaginative some times. Provides hours of laughs but gives the reporting guys a fit as it throws out all of their forecasts.

Once we determine its a fairly small effort and consequence we scheduled it in and get moving on it. Even if its not a small consequence we may still make a start on it. It just usually requires more stakeholder management and communication to make it a successful enhancement.

Our list of enhancement requests grow and we are currently going through some business change to only time will tell how we fair getting them all done.

In the meantime we can continue our assessments and schedule them accordingly and wait.

So what do I do in application support? Support the applications is the obvious answer. A more realistic answer is support the end users by maintaining and enhancing the tools they use to do their job.

The environment I support is a wide array of integrated applications that are built on numerous platforms, in multiple languages and not only talk to each other but across multiple other organisations to their applications.

What could possibly go wrong?

Scenario 1: Sometimes we send data to another organisation, they store it, manipulate it and when it comes back its not always in the pristine validated condition it was as when we sent it. Our system doesn’t like it any more as it no longer matches the record we have at our end and throws a hissy fit on the way back in. We have to repair it. Those are data fixes. They are frequent and numerous and make up a large portion of what our developers do on a day-to-day basis.

Scenario 2: As good as you make an application, and for all of the testing you do, there is always some scenario that you miss or don’t test thoroughly enough. The end result? Bugs. Bugs aren’t always simple to fix and aren’t always within our domain to fix. The problem could be across an inter-agency interface or embedded in a Commercial Off The Shelf (COTS) product and as a result unfixable. Or some could be just a result of the risk based testing you did (or didn’t do) and will require analysis, coding, testing and pushing through the various environments before releasing back into the wild.

Scenario 3: Patching or upgrading of underlying operating systems often introduce changes of functionality (or the application just stops working completely). Without the patches and upgrades though the operating system or COTS product may not be supported by the vendor. Any issues and the first question they ask is “Have you installed the latest updates?”. If the answer is No then the response is generally consistent across vendors. “Then that is what you need to do first”.

Scenario 4: User errors that can’t be reversed through the user interface (with generic permissions). If the user can’t fix it then it goes to a tier 1 support group who have power privileges to the application and can do things the end users can’t. Sometimes its a data fix, otherwise it may be a process that is locked up for whatever reason and the support crew (who are superusers) can remedy through their admin screen or admin account and wind back the process or just reset a status.

Scenario 5: Sometimes applications just stop responding, Sometimes they just won’t start. Sometimes they become slow beyond being usable.

Everything needs analysis before further action. And that is part of what my team does.

Apart from bug and data fixes………

Next article will be What else do we do?

What is a wet sphere?

It is a hard sponge type material used by florists to provide a stable foundation and some temporary sustenance.

This blog is going to “try” and perform the same function for those who work in the application support area including me. It’s my way of formulating some idea’s, explaining what I do, how I do it and why I do it and perhaps get some feedback from others in similar roles that want to bounce some ideas around or just tell me what I am doing wrong (and perhaps sometimes right) and build a solid foundation for other application support areas to work with.

As an aside I find it stimulating and somewhat relaxing to read blogs or other articles and perhaps learn something. That is my temporary sustenance as it wears off pretty quick and reality sets back in when the phone rings and there is another issue to deal with.

I will start off with What does App Support do.