What happens when your software goes crazy? Does your customer see it? Do their customers see it?
To illustrate the importance of monitoring and management, I’m going to use a story. This story is entirely fictional, but many aspects of it are entirely real for anyone who has a couple of product launches under their belt.
You choose the best and lose the rest
No one likes it when their products break, so architects typically design some fail safes into their systems. These mechanisms monitor problems, and help in the diagnostic process. If they are really good, the architect might even design the system repair itself when possible.
Then features start getting cut, because inevitably, your company only has so many development resources . . . In this process, most companies end up forgoing manageability for a few pieces of shiny functionality, like a better splash screen, or more sophisticated SFDC integration.
So, your architect designed your product with a maniacal focus on the most important features. Your team delivered on target with a few expected hiccups. You’ve exceeded sales forecasts. The future is bright.
A quality issue strikes
Just when you were planning your first project post-mortem, the support crew gets a call. A unit in the field stopped working, and a customer is on the phone. Your support staff and engineering teams huddle around a speaker phone, troubleshooting the issue remotely, trying to guide the non-technical customer through the process.
After a week has passed, you have made a plane trip to the defective unit and figured out it was a fan in the system that failed, and then the system ended up overheating. You’ve had three more customer calls, but haven’t diagnosed them yet.
Your mind starts racing . . .
- Will more units fail?
- If so, when?
- How will I know when they fail?
- Do I need to wait for each customer to call me with a failed unit?
- If I do a replacement campaign, how will I track which units have been fixed?
- Maybe I have multiple issues?
Is there a better way?
Yes.
At this point, it would be nice if there was a way to interrogate the products in the field and take an inventory of their components. It would be even better if the systems could notify your support crew each time a fan failed – and you could call your customer proactively. You could even dispatch a replacement part anytime the thermals in the system began to increase – in anticipation of a fan failure.
Luckily, your supplier anticipated this event and built remote management of the hardware right into the box. After discussing the issue with your supplier, you find out they supplied standards based interfaces to allow every piece of functionality you needed to get control of your products after they were installed at your customers’ facilities.
To top it off, your supplier even provided a management console that allowed you to do all of this right away from your home base.
After the product is launched, it keeps living
The best part about this story, is that because your supplier laid the foundation, you can continue to extend your products capabilities well after product launch. These capabilities can continue to complement your current support pains and minimize customer downtime.
The moral of the story
If your supplier isn’t as kind as the one in this story, you need to take matters into your own hands. Implementing the basic capabilities of monitoring, diagnostics and repair into your system can set the stage for delayed development. In turn, that development can adjust as your product’s weaknesses become more apparent to you, and before they become apparent to your customers.
The 2nd moral of the story
Make sure your supplier isn’t already fixing your problems before you invest your precious resources in duplicating them!
You can follow Josh Neland on twitter @joshneland
