Leverage Points: places to intervene in a system

Posted by Dave West on Jul 29, 2010

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

Modeling ,

Architecture ,

Design ,

Change

Tags

Architecture Evaluation ,

Architecture Management

A key decision for software architects and designers involves where and how to introduce change into a system in order to effect a desired change. Leverage points are those places where micro changes can result in macro results. The business enterprise is a system that can be changed by the strategic introduction of computing technology at appropriate leverage points. IT is also a system that can be altered by making key changes at leverage points. In both cases it is necessary to identify leverage points and determination of the type and value of the change to be introduced.

Donella Meadows is the author of Thinking in Systems: A Primer, a Pulitzer Prize nominee, and recipient of a MacArthur Foundation “genius” award and her work, Leverage Points is still considered to be a classic reference for those seeking to implement system change. Donella Meadows died in 2001, but her ideas about leverage points are summarized in The Solutions Journal.

This idea of leverage points is not unique to systems analysis—it’s embedded in legend: the silver bullet, the miracle cure, the secret passage, the magic password, the nearly effortless way to cut through or leap over huge obstacles. We not only want to believe that there are leverage points, we want to know where they are and how to get our hands on them. Leverage points are points of power.

Meadows identified 12 categories of leverage point, listed below in ascending order of effectiveness.

• 12. Numbers: Constants and parameters such as subsidies, taxes, and standards
• 11. Buffers: The sizes of stabilizing stocks relative to their flows
• 10. Stock-and-Flow Structures: Physical systems and their nodes of intersection
• 9. Delays: The lengths of time relative to the rates of system changes
• 8. Balancing Feedback Loops: The strength of the feedbacks relative to the impacts they are trying to correct
• 7. Reinforcing Feedback Loops: The strength of the gain of driving loops
• 6. Information Flows: The structure of who does and does not have access to information
• 5. Rules: Incentives, punishments, constraints
• 4. Self-Organization: The power to add, change, or evolve system structure
• 3. Goals:The purpose or function of the system
• 2. Paradigms: The mindset out of which the system—its goals, structure, rules, delays, parameters—arises.
• 1. Transcending Paradigms

Experienced business managers, software architects and software developers will recognize these leverage points in their own work - especially "Numbers." Lean Software Development has a lot to say about 11, 10, and 9 - eliminating waste in unneeded or bloated buffers, value chains in "Stock and Flow Structures," and the waste associated with intrusive "Delays." Optimizing "Information Flows" is essential to good business and systems architecture design.

An understanding of "Self Organization" as a leverage point leads to a core issue - and at number 4 on the list, a very powerful issue - of Agility, i.e. the self organizing team. In fact, the entire concept of Agility can be seen as an attempt to exploit the number two leverage point - "Paradigms."

 

There is yet one leverage point that is even higher than changing a paradigm. That is to keep oneself unattached in the arena of paradigms, to stay flexible, to realize that no paradigm is “true,” that every one, including the one that sweetly shapes your own worldview, is a tremendously limited understanding of an immense and amazing universe that is far beyond human comprehension. It is to “get,” at a gut level, the paradigm that there are paradigms, and to see that that itself is a paradigm, and to regard that whole realization as devastatingly funny. It is to let go into not-knowing, into what the Buddhists call enlightenment.

As mystical as this sounds - "Transcending Paradigms"are not foreign to software development. Kent Beck, in the first edition of eXtreme Programming Explained notes that XP has three stages: out of the box, adapted, and "transcended."

 

Another important element in the summary of Meadows' work comes from Jay Forrester of MIT:

although people deeply involved in a system often know intuitively where to find leverage points, more often than not they push the change in the wrong direction. The classic example of that backward intuition ... [was] a computer model [tht identified] a clear leverage point: growth. ... Growth has costs as well as benefits, and we typically don’t count the costs—among which are poverty and hunger, environmental destruction, and so on—the whole list of problems we are trying to solve with growth! What is needed is much slower growth, different kinds of growth, and in some cases no growth or negative growth.

An example closer to the IT and business world would be the leverage point of cost - an instance of "12- Numbers." Cost is clearly a leverage point, but too often, in both business and IT, it is leveraged in the wrong way - reduction only. This leads to all kinds of problems that might have been avoided if, perhaps costs for certain things had been increased - like paying more for more highly skilled developers and finding that you needed fewer of them.

 

An understanding of systems and of leverage points that can be exploited when designing systems is essential for all software architects, designers, and developers. The work of Donella Meadows, coupled perhaps with the Systems focused work of Jerry Weinberg, is a good starting point for obtaining that knowledge.

• Older >