Wardley Mapping Technical Debt of a System

A friend of mine brought a question, can you map technical debt of a neglected system (edited) with Wardley Mapping.

I'm not sure it's possible in a single slide, mostly because the Wardley Map would require a time axis (or even a worker knowledge axis) to depict it in one slide.

To explain the entire idea, I'm going to use 8 slides such that the entire thought may be followed.  Please keep in mind, that this is entirely theoretical in nature.

For starters, Wardley Maps does have a couple of mechanisms that are useful for this depiction (See Figure 1 upper right).  The first one is inertia, represented as a solid bar and the second is a fat arrow indicating acceleration and deacceleration.

Figure 1 is a starting value chain map, with a system between the electricity anchored in the Commodity (+utility) area and a user need indicated in the most visible position.

Figure 1.  Wardley Map of system with Inertial marker identified

I'm placing the characteristic of Inertia in the middle of the system, with the supposition that there are no other forces acting on the system (like in physics).

Let's suppose then, that a deaccelertion is applied to the system by forgoing a technical upgrade in a part or all of the system.  See Figure 2.

Figure 2.  Stalling Update of System to N-1

This will impose an inertial movement from current position to the left.  See Figure 3.  Also note the "shadow" of Technical Debt in this drawing behind the system's inertial reference.

Figure 3.  System in N-1 State

The system is still within the Product (+rental) space and therefore there is no significant harm to how the system provides for the user need.

Imparting another deacceleration to the center mass of the system by forgoing the next generational needs of upgrading the system again shifts the center of mass of the system to the left.  See Figure 4.

Figure 4.  Forgoing update of system to N-2

See Figure 5, the system now sits on a precarious boundary between Product and Custom.  The possibility that the functions of support and management are greatly increased and the system itself may need some parts of its structure custom maintained.  The "shadow" of Technical Debt has grown with respect to the movement of the system.

Figure 5.  System in precarious boundary between Product and Custom

Forgoing another generational upgrade of the system imparts another deacceleration to the overall system.  See Figure 6.

Figure 6.  Further neglect of System to N-X

Continuous neglect of the system eventually leads to complete failure, where the massive "shadow" of Technical Debt of this neglect leads to system collapse through the technological inability to upgrade or loss of knowledge necessary to upgrade. See Figures 7 and 8.

Figure 7.  Continued neglect until system breaks

Figure 8.  Broken system (fully in Genesis) with Total of Technical Debt

Once the center of mass passes the Genesis boundary, the system is likely incapable of accurate function.  The user needs will no longer be met and that also may need to shift along with the center of system inertial movement or more likely be removed altogether.

As always, if you've any additional thoughts on this topic, I'm active in the twitter-verse @abusedbits

https://threadreaderapp.com/thread/1068822023126827010.html

Technical Debt, and Wookiees™, in a Star Trek™ world

In information technology, the goal of design is 100% uptime, be it of the equipment infrastructure (and oh by the way we shouldn't be doing this anymore) or the application (it's really what we care about).

I often think of this as the Star Trek™ conundrum, where the desire is to have something absolutely perfected.  In this way, it will work the way you want it to, when you want it to, each time you want it to.

The components ideally fitted at the subatomic layer for exactness.  Software tested to be infallible. The entire system redundant with tolerances that leave no excuse for failure.  All parts upgrade-able and replaceable within a specification that meets the test of time.  Ultimately, the ideal of the star ship Enterprise.

In other words perfect.

This perfection ends up being quite expensive, so the tolerances are loosened.  The software is released in stages of development.  The parts have finite longevity with future specifications not well understood.  Redundancy placed where traditional mechanisms fail the most frequently.  Sort of like the Millennium Falcon.

So, there will be a really tall and hairy guy with an intergalactic spanner wrench banging on the console of a component that is failing due to something else failing in the power room, 100 meters away under the floor.  It is inevitable.

As the Wookiee™ is banging on the console, just remember that at some point it did the Kessel Run in less than twelve parsecs.

Maybe it's time to establish a new Kessel Run record.