Why Darth Vader Needed a Problem Manager - Episode II

Episode II: Problem Management: It’s Not a Trap!

Yesterday we recalled the fate of two DEATH STAR battle stations and how Problem Management could have helped Darth Vader avoid repeatable mistakes in the future. Today, let’s take a look at some of the key aspects of this story and how they relate to the ITIL definition of Problem Management.

Identifying the Root Cause

The Empire clearly did not know or understand the key flaw in the DEATH STAR. After the first model was destroyed, Darth Vader as the only survivor was ricocheted into the abyss of space in his TIE fighter. No one was present for the exploitation of the actual flaw. Had the empire really understood that the reactor core in the center of the ship was so volatile, I highly doubt they would have used the same design when construction began on version 2 off the forest moon of Endor. After the initial Incident, Vader should have convened key stakeholders together to first identify what might have happened and then developed a course of action to mitigate against that in the future.

Identifying the Root Cause is the most-important aspect of any Problem. If we don’t do, or don’t get it correct, we’ve done nothing to stop the same Incident occurring in the future.

Missing Related Information

Oftentimes in Problem Management, we identify information that is seemingly completely outside the scope of the systems that experienced the original Incidents. DNS issues may affect email, but never actually touch our Exchange components. Memory leaks in enterprise applications may only occur twice a year during Daylight Savings Time. Wi-Fi connectivity may be inhibited by sunspots, over which we have no direct control.

In my trash can example from Episode I of this blog series, I like to mention that perhaps the bin overflowed because perhaps the janitor didn’t empty it, and perhaps it’s because those nights all had a home team playing and perhaps the janitor is a big fan. By looking around for seemingly un-related data, making assumptions and then testing those assumptions, only then can we actually understand the full picture of what’s happening. (E.g., the janitor left early to watch the game).

Darth Vader should have put together that:

1) The plans for the DEATH STAR were stolen, stored in R2-D2 and sent in an escape pod to Tatoonie, a related security Incident weeks earlier.

2) An unknown spacecraft – the Millennium Falcon – docks on the DEATH STAR. They search the ship, but clearly don’t check the logs. Had they, they would have realized the ship’s last destination was none other than Tatoonie.

3) The DEATH STAR’s tractor beams are manually disabled – another related Incident – and done by the same perpetrators.

4) Years later, Bothins again steal plans for the DEATH STAR, which should have been an indication of another planned attacked.

Making too Many Assumptions Based on Prior Culture

Prior to the DEATH STAR, the empire’s main Starfleet consisted of massive, triangular Star Destroyers. Because of the technical characteristics of these ships, it’s apparent that their biggest risk to destruction was another similarly-sized ship. It’s also apparent that small, fighter-style ships did not pose any threat (To be fair, I do applaud the SWOT Analysis that was obviously completed on the fleet).

These characteristics became fact and law over time and clearly were engrained within the military culture of the Empire.

These tactics were then transferred over to be implemented in the defense of the DEATH STAR, probably because, “that’s the way we’ve always done it.”

The DEATH STAR, however, was completely new technology and worked completely differently. This new technology was highly susceptible to an X-Wing fighter attack, a strategic flaw missed by the Empire and exploited by the Rebel Alliance.

A way to avoid these mistakes can sometimes involve bringing in outsiders. Darth Vader could have invited experts not associated with the Empire to do an independent audit or security review. By looking at the project without the colored glasses of the current team, they might have helped change strategy and design from the planning phase.

Check out Episode III: How You Can Use Problem Management as a Force for Good for the conclusion and wrap-up of our epic discussion.