Location and Lifecycle in software systems Part 2 When in the lifecycle

This article is in 2 parts. Part 1 deals with the KT “Where on the Object” question. Part 2 considers “When in the Lifecycle”. Part 1 and part 2 are pretty much mirrors of each other.

Some participants in KT Problem Analysis workshops express a puzzled look when trying to answer the Where on the Object and When in the Lifecycle Problem Analysis process questions for software systems. They really get it for the case studies and physical systems, but transfering the thinking to software which has no physical form can be a challange, [ Let me disclose that I did not really get this questions when applied to software until I did my Programme Leader training in 1999. Later I had a process wobble when I started thinking about using KT process for Cloud systems which took a few weeks to iron out. Back in 1999 computing was at least 10th the size it is in 2025 plus cloud or virtualized systems are an order of magitude harder to get your head around to start with. ]

I went back to the source of all wisdom, the New Rational Manager book. Little is said about these 2 questions and what to look for, but did give good physical systems examples.

So I had a look at the Concept Rationale for KT programme Leaders and for WHEN lifecycle it says

To correlate the timing of the deviation with specific events in the object's history, and to help narrow the search for relevant changes and causes.        

To identify the points in the production, use, function, testing, shipping, etc when the deviation 1st appeared        

To identify the steps, stages, speeds, operations, functions, etc, associated with the object when the deviation occurs.        

Thats pretty useful, but still needs some translation to a complex virtual world of IT. So I am going to suggest that for systems which have a software component and/or are distributed, we take Whene in the lifecycle to mean

Trace the flow of control of the operation/action the object is undertaking. What is the system doing when we 1st observe the defect?

For example, if corrupt network packets are reported, where do we see network packets 1st becoming corrupt. If there are 3 routers that the packets traverse and we only see corruption after router 2, then the answer to the when in the lifecycle question becomes after the 2nd router.

An other example might be a failure to send an email, the logs suggest that the email server recieves the request, but the destination does not recieve the message. In this case the last place we can see the email message is in the email server, so the answer to hen in the lifecycle would be after the email server. We could choose to gather further and possibly deeper information around the email lifecycle, but this is a good place to start. We have eliminated the client and the network between the client and server. Leaving the target and the network between the server and target, progress indeed.

[ The rest is a repeat of Part 1 ]

For the discipline of Problem Management, a mental model of the system under investigation is needed to answer these process questions. The Problem Manager can not use their senses to understand the system and build their mental model as they would with a physical machine they can observe and touch. This means exploring their powers of systems thinking which is the core reasoning style for understanding complex, interdependent systems. It involves seeing how parts relate to the whole, spotting feedback loops, and understanding emergent behavior. Systems thinking ts a key skill in asking “what happens if…” and seeing second-order effects, a key skill in problem avoidance and risk management, both activities which add huge value as part of the problem management itinerary.

Engineering thinking is quite different in that it delves into an understanding of how various subsystems or components work in detail, how the components operate and how they interact to produce the emergent behaviour. A key part of engineering thinking is making a subsystem behave in a reproducible way. Systems thinking only seeks to observe and understand the behaviours of each subsystem, not the inner workings.

Systems thinking involves the abstract identification of components and their interactions at a high level, what components and what interactions. This skill applies equally well to business systems as to computer systems. I am using Systems Thinking to work through why a subset of  University Students don’t attend lectures later in the term and why Help desk staff are prone to social engineering and being fooled into changing email passwords for fraudsters [think MGM Grand hack]. No problem manager with a business background would have any fear of building a similar model, but include a database, a network switch, some virtualisation and a web server, some problem managers it becomes a opaque system where only 3rd party vendors should tread.  I have seen the great specifications built by non technical problem managers (called Stuart or Peter) who were excellent at Systems Thinking and building mental models, but had no technical background in the systems they were working with. The specifications were key to identifying missing data and key differences which lead an subject matter expert to find root cause they would not have considered with the scope reduction  and clarity a good specification brings.

Systems Thinking skills can be developed in professionals no matter their technical background or absence of such. Some problem managers are confusing systems thinking with technical or engineering thinking. System thinking is a key problem manager skill that can be applied to asking really good questions of Subject Matter Experts, Engineers and yourself. You don’t have to be technical to ask really good questions often it helps not to be to avoid bias.

Some people claim they are no good at maths. Lack of confidence maybe? I can’t  derive  eigenvectors or plot the path of a space craft, but I can use linear regression, means and apply the Kolmogorov-Smirnov statistical test. I could not  provide a proof  that 1 and 0 are not the same. I can apply a system of numbers and manipulate them to solve wider problems, even if I don’t understand where they came from. If I need to learn a new statistical test (or remember an old one) I will do it to solve the problem in hand. Problem managers get huge value from bringing the same approach to the systems where they are responsible for problem resolution and avoidance. Understand the subsystems and their interactions, not inner workings.

A fear of system thinking among the IT problem manager community is holding the discipline back and as a consequence holding up their own careers and the value delivered to the business and its stakeholders from problem management.

I thought I was pretty good with blood and such things. I nearly fainted while having a  blood sample taken by a student doctor this week. Note to self don’t watch someone poking around in your arm to find a vein, it's not that interesting. They body is a complex system, I don’t need to understand Vasovagal syncope (emotional stress causes the nervous system to overreact, leading to a drop in blood pressure and heart rate), but it is useful to know that looking at someone spending a few minutes poking around with a needle in your arm to find a vein, triggers a response you don’t want.

If you recognise this fear of system thinking around building models of technical systems, give me a shout. It would be great to have a virtual cup of tea on zoom around the subject.