“Mission critical refers to any factor of a system (equipment, process, procedure, software, etc.) whose failure will result in the failure of business operations. That is, it is critical to the organization’s ‘mission’.”
Unisys systems are the backbone of many businesses and financial, transportation, communications, and social infrastructures around the world. For many people, the link between the systems and the mission’s success or failure is well understood. But for others, this mission critical relationship is not readily apparent… at least until the right learning opportunity comes along.
My first lesson in mission critical was during a lengthy field test of a new, completely redesigned operating system at a well-known financial institution. I was a young, snot-nosed engineer venturing out from the lab for the first time; while I was excited about the opportunity to gain some real-world experience, I also had the tendency to approach situations from the development perspective familiar to me.
The field test was going smoothly all-in-all. In the middle of a rather busy on-line processing period, the system took a halt and the DP manager was immediately alerted. He grabbed me and off we went to the machine room. As we surveyed the situation, he began the restart procedures. I asked if I could have 10 minutes with the system in order to diagnose the situation further. He responded with a very polite but firm “Ah, no.” I understood the heat of the moment and his responsibility and did not question him further.
As the automated restart procedure began doing its thing, he said “Here, let me show you something.” We walked over to one of the front-end data communications processors and he pointed out one of the statistics displayed on its console. It was a rather large, 4 digit counter that was incrementing rapidly. “Know what that is?” he asked. “It’s the number of bank tellers apologizing to the customer at their window that the system is down. And you’d like 10 more minutes to play with the system?”
I then did my best deer-in-the-headlights imitation; I was shocked, amazed, and embarrassed all at the same time.
Putting a face and business impact to a queued transaction counter was a powerful lesson that was responsible for a fundamental shift in my software development mindset – my first realization of the critical link between what I did and the effect it had on the businesses and the end-users that depended on it.
During a design review shortly after returning to the lab, an engineer was asked what they would do if a particular error condition manifested itself. The answer, as was common practice back then, was to stop the machine. I’m afraid that my suggestion that he needed a better means to handle the error came out rather strongly, but the ensuing explanation of why it was necessary was my first opportunity to relay the lesson learned.
My personal definition of “mission critical” has been shared with several generations of engineers since then. It has been my small contribution towards enabling our systems to fulfill the mission critical roles that they have today… and my never-ending apology to all those bank tellers and their disappointed customers.