« The Objective of Setting Objectives | Main | Competency, Competing, and Strategic Behaviors »

September 23, 2005

When is a system not a system?

Peter Senge kept coming to mind after a handful of exchanges with some colleagues about organizations being systems.

To grab a really crisp definition of systems that I knew I'd seen from him, I checked in at Frank Patrick's blog Focused Performance where lots of crisp things get presented in great context.

Frank quoted Peter:
A system...is anything that takes its integrity and form from the ongoing interactions of its parts...Systems are defined by the fact that their elements have a common purpose and behave in a common way, precisely because they are interrelated toward that purpose. - Peter Senge

What's tricky about this definition is the ease with which it's clarity seems self-evident. I can run with the statement up to a point, but only through another point first. Let's be sure we know that when Peter says "interrelated", he's giving us a verb and not an adjective. The elements of a system don't inherently know that they have a common purpose. That is, they have to be "told" about their commonality somehow. The telling involves a lot of things like engineering, configuration, assignment, regulation, and so forth. In other words, we "define" a system by deciding what purpose and behavior it is that the elements have in common. What Peter is really indicating is that if we see a bunch of "elements" and can't decide what is common in purpose and behavior, then we haven't identified a system. In another case, though, we might recognize what we'll call a "natural" system -- in which case we're just saying that the force dictating the system is not our willful invention.

Which brings up another question: how do we know something is an element before we have actually "created" the system by defining it? Usually this puzzle can be solved by taking what we can readily detect, and imagining it as a component that has the potential to be an "element". Once we give the component a job, it can become (or at least contribute to) an element of a system. Even if the inherent capabilities of the component is what gives us an idea for a system, the job actually comes from our idea of the system and may not even ask the component to do what it otherwise might do best. (I really ought to get that PC monitor off of those old phone books, but you know the monitor height is just perfect with them...)

Something related to this is that the more parts the system has, the more chance there is that a subset of the system's parts can develop a new interrelationship and behavior, diverging from the overall system model. So even when we know what components "belong to" a system, we might find that the elements are not sufficiently available.

This gets to the other important thing to think about: the system might be invented or it might be discovered. When it is discovered, it might not be the system that we wanted to find. Then there is the challenge of what to do about the difference. The reason why this is finally so important is that we often invent and activate systems that develop unanticipated dynamics and become different systems from the one we thought we invented. In effect, the system might "find" its own purpose. When that happens, how quick are we to detect it? Just because something's parts are "interrelated toward a purpose" doesn't mean it is cooperating with us.

This reminds me of my working definition of "mythology", which is "occasions when prescription substitutes for description." And therein lies the wariness I have about Senge's definition of a system. I don't disagree with the definition, but I worry about it's use. We should all be careful to find the system that is really there, and not just the one we expected or wanted to see.

The usual practical interest in systems comes from an interest in control. But between engineering a system versus training or coaching one, and between discovering a system versus synthesizing one, the variability in what we should do about systems is pretty vast; thinking in terms of systems gives a distinctive point of view but it's probably the view from the tip of an iceberg. We can be pretty sure that controlling an organization is an iceberg.

Posted by Malcolm Ryder at September 23, 2005 7:37 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/138

Comments

Post a comment