Life Cycle

It might seem obvious, but the word "cycle" means going round in a loop. In biology, this means the cycle of birth, reproduction and death. In business, talking about product lifecycles or technology lifecycles carries the expectation that every instance of PRODUCT or TECHNOLOGY has a finite life expectancy, and will be replaced by something else.

But there are two common misuses of the word lifecycle. In the first misuse, people say "cycle" but mean something else. This is illustrated by Gartner's concept of the Hype Cycle, which is not even drawn as a cycle, but as a curved graph going from left to right. See discussion in my Software Industry Analysis blog.

In the second misuse, the concept of cycle is used inappropriately. This is illustrated by a Disaster Lifecycle found on the FEMA website. This appears to show each instance of DISASTER producing new instances of DISASTER.


(via Presentation Zen)

(Of course the ongoing purpose of FEMA assumes a continuous supply of fresh disasters, just as rat-catchers rely upon a continuous supply of rats, but it is really bad PR for FEMA to imply that they are helping to create the disasters they are supposed to be managing.)

The Presentation Zen blog suggests that "Perhaps FEMA would have been better advised to show the stages in a more linear way?" and refers to product adoption lifecycles being presented in left-to-right manner. But the problem (both here and elsewhere) is not just that a given concept has been inappropriately drawn, but that it was the wrong concept in the first place.

Attenuation

A number of people have been talking about attenuation recently, and it links to some aspects of business intelligence I've been researching. When James Governor complained that the word was geeky, and asked why we couldn't just use the word filtering, I thought I should try to answer him.

I think the important difference is this. Attenuation is an outcome (black box), whereas filtering is a mechanism (white box). Filtering generally involves some device or subsystem (hardware, software, clerical or hybrid) that performs a filtering function - letting some items through and not others. Although it is possible in complex systems for filtering to happen by accident, and it is certainly possible for filtering devices to perform incorrectly, the filter is an architectural pattern that is normally implemented as a deliberate design decision.

In contrast, attenuation simply means that some data or information are just not getting through. This can occur as an emergent effect of the interactions within a large complex system, without being specifically located anywhere. It may be deliberate or accidental, it may be predictable or random. Filtering is certainly one possible mechanism for achieving attenuation, but there are many other possible causes of attenuation including distance or impedance mismatch. Simple aggregation also produces attenuation, and this has led some people (I think misleadingly) to bundle the two concepts. (See for example O'Reilly).

When I am looking at a complex system or organization, I can often start with the observation that attenuation is happening, but without knowing where or how. I infer attenuation when I see a system that is failing to respond to significant events in its environment, or when I see systems that cannot coordinate properly.

In some cases, of course, this inferred attenuation leads to the discovery of a specific filter - perhaps a communication channel has got blocked, or adapted for some local purpose that conflicts with the objectives of the whole system. But often the root cause is not the presence of a filtering mechanism but the absence or inadequacy of a communication mechanism. Or even a fundamental incompatibility between different systems or viewpoints.

Attenuation is often a desirable effect - particularly when dealing with information overload or complexity overload. Matt Webb praises maps, and points out that "the taking of a position in a landscape of information flow" produces attenuation. (Thus attenuation is a necessary consequence of perspective.) IT architects practise two forms of attenuation in particular - Modelling and SeparationOfConcerns.

• Modelling is a form of conceptual attenuation - reducing a complex situation to an abstract model.
• SeparationOfConcerns is a form of parallel attenuation - creating a series of simpler views of a complex situation.

However, there are many situations where attenuation needs to be overcome: I want more detail / context in the data than I'm being given. When attenuation occurs in my system, I may be able to get inside the system to detect and alter the causes of the attenuation. Matt Webb describes these as algorithms, and advocates "co-production of the algorithms with the people who sit in the information flows".

This is fine when it's available - but it usually isn't. Because sometimes the attenuation is happening in someone else's system. So I have to find a way to amplify the data I can get access to - using statistical inference to deconstruct aggregations and reconstruct detail and context - which help to connect and explain the attenuated fragments of data that are available. A lot of what happens under the heading of Business Intelligence can be understood as a form of archaeology - piecing together patterns of market behaviour from large quantities of extremely attenuated data.

Finally, I should acknowledge that James is not alone in equating attenuation with filtering. Stafford Beer uses the term attenuator as if it were equivalent to filter, and his Viable Systems Model (VSM) describes variety attenuators as if they were devices for filtering out complexity. And yet he says: "The lethal variety attenuator is sheer ignorance." and it is hard to see ignorance as a filter. [See this presentation on VSM by Trevor Hilder (pdf).]

My dear James, if you think that attenuation is geeky, you should try implicature. (Sources: Matt Webb, Lloyd Shepherd.) Perhaps someone could explain to me how this usefully differs from either framing or perspective. (See also Brian M Dennis.)