Add a paragraph on developing the function and form views at each level of disaggreagation/re-aggegation as the process moves along.
What is Dis-aggregation/Re-aggregation?
Breaking a system down into chunks, sub-chunks, sub-sub-chunks and so on, until a level of simplicity is reached where the chunks we’re looking at are understandable is powerful way to deal with the daunting complexity of a system. This works for the problem-system that launched the CSD project, the solution-system that will extinguish the problem, as well as for the solution-discovery system that will create the solution . This process of breaking down until understandable simplicity is reached is called Dis-aggregation. At the level where understanding becomes possible, decisions can be made, either about understanding the problem in its dis-aggregated view, or with focus on the solution, beginning to decide what the solution might be. Then, Re-aggregation begins, assembling the system by working back up through higher and higher levels of organization, reaching at the top either full understanding of the problem or a full description of a possible solution. In this process, certain heuristics apply so that dis-aggregation is effective in getting to understandable chunks while preserving overall system characteristics, and the re-aggregation is successful in developing a full picture, without missing important features or introducing anything spurious.
This is not a reductionist stance, because causality flows downward in the hierarchy as well as upward. In reductionism, causality flows upward only; understanding all the elementary bits at the bottom of the hierarchy is considered sufficient for understanding everything above the base. But that is not so with systems. It is true with systems that the functions and structures at higher levels are composed of and caused by those at lower levels. But what exists at lower levels is determined from above, by what is necessary so that necessary higher-level functions and structures can exist. The purpose of a system is determined at the top, and that purpose-driven causality flows downward.
That means the dis-aggregation and re-aggregation happen primarily in the Form and Function views of the system, but it may be useful to track other views as well. Starting at the top, what are the top-level functions that define the overall behavior of the system, and what are the top-level form elements that make up the structure or architecture of the system? Then, at the next level of dis-aggregation, what lower-level functions accomplish each higher-level function, and what lower-level form elements make up each higher level form element. Further and just as important, what elements at each level are involved in performing each of the functions at that level?
This process requires careful knowledge management. As dis-aggregation proceeds, keep track of all the lower-level function and form elements associated with each higher-level element of the same type, and all the interrelationships between elements at each level. As re-aggregation takes place, be sure all lower-level elements are gathered into the proper higher-level elements, that all interrelationships at each level are properly identified and made, that all higher-level functions are fully supported by the lower level, and that no unexpected and undesired functions are introduced as each level is assembled from its constituent elements.
Doing Dis/Re-aggregation
Dis/Re-aggregation is carried out with two goals in mind.
- Maintain the “whole-is-greater-than-sum-of-parts” nature of the system.
- Define the chunks, sub-chunks, sub-sub-chunks etc. so the work on understanding and/or creating each one can be allocated to various separate teams within the project while preserving the property that they all fit and work together for successful re-assembly.
How is the “whole-is-greater-than-sum-of-parts” nature of the system maintained?
Fundamentally, this is a job of keeping track of how the emergent behaviors at higher levels are caused and maintained by activity at the levels below.
In dis-aggregation we start with the top level view of the system and its behaviors. This can be either the intended behaviors of a purpose-built system we are creating, or the actual existing behaviors of a system we are analyzing and diagnosing. What are these top-level functions or behaviors, and how are they executed by the top level form elements? Then, dropping down a level, what functions and form elements must be there (when we are creating a system) or are there (when we are analyzing an existing system. Either in the design process of creating a new system, or the analysis of an existing system, continue this all the way down to bedrock where the functions and elements become so simple that that they become transparent to our understanding.
In re-aggregation we start at the bottom and work up. As each level is assembled, does it deliver all the behaviors necessary at that level, and does it avoid unnecessary and undesired behaviors?
How are the chunks defined?
Achieving the goal of creating or identifying suitable chunks at each level of dis/re-aggregation is more art than science, requiring a degree of judgement and discrimination. At each level in the dis-aggregation process, seek out regions of higher complexity and interdependence, surrounded and connected by regions of relative simplicity. The high-complexity regions are likely candidates to be chunks, and the simpler regions are the interconnections. So, slice up the system into the chunks, joined by interconnections, but be careful that the slicing does not sever any important system features.
Another heuristic for defining the chunks is doing it so just one or a few disciplines are needed to understand and/or design any particular chunk. To illustrate, think of a building. The structural elements would be one kind of chunk, requiring architectural and structural engineering expertise. Related to that would be the surface materials that make up floors, walls and ceilings, requiring architectural and interior design expertise. Also related would be windows and doors. The plumbing, electrical, and ventilating-heating-cooling elements would be still others, each with its own type of specialist. It is left to your imagination to envision what types of chunks would make up a human activity system, such as one intended to provide a full menu of social services to the residents of a community.
Human Anatomy as an Example
Human anatomy provides an example. We understand our bodies as composed of various organs and tissues – heart and circulatory system, lungs, gut, bones and muscles, brain and nervous system, etc. When we are ill we usually go to a specialist in the particular part of the body that is causing complaint. The Muddle Buster, in accessing medical care, finds this to be so, but also finds it important to have a head of the caregiver team, a general practitioner, who coordinates care among various specialties and makes referrals to specialists with needed expertise.
Black-box White-box Viewpoint
Another approach is to view a system as an assembly of black boxes. Your entertainment center (if you have one) is an example. It is literally a stack of black boxes – receiver, amplifier, DVD player, video program recorder, video monitor, speakers, and maybe more. They are all connected together by a tangle of cables, and controlled by one or more remotes. What’s inside the black boxes is unknown, and pretty much a mystery.
However, for the engineers who design them, aficionados who delve deeply into their performance, and technicians who repair them, these systems are composed of white boxes (more accurately, transparent boxes, but that makes the terminology awkward). These experts understand what’s inside the boxes, and find the next level of dis-aggregation accessible. Still, even these experts might consider the bits inside the boxes, the circuit boards and mechanical components, as indivisible chunks, that is, black boxes at a lower level.
Localized and Distributed Sub-Systems
The chunks that are identified may be either localized sub-systems, or distributed. In the human anatomy example, the heart is localized, but the circulatory system is distributed, the brain is localized but the nervous system is distributed.
The same can be true of systems you might concerned with in a CSD project. Regional transportation is a hard-system example. Distributed components of that system would be the various trails, roads and streets, rail lines etc, that span the region, on the other hand, a regional transit hub where various transportation modes intersect would be localized. Likewise a soft system like regional social services delivery system would have localized systems for delivering certain specialized services like child care or job training, but would also have a distributed system for coordinating and tracking a suite of services assembled to meet the needs of a particular client.
Keeping Track
Dis/re-aggregation requires a lot of bookkeeping to keep track of all the chunks and their characteristics, all the interactions among chunks and what structures carry those interactions, who is working on what at any time, and who else they need to coordinate with. So, take a look at the branches on Focused Representations, Mapping and Tracking Interactions, and Knowledge Management where you will find ideas to support this need.