I notice that software design patterns are classified as Creational, Structural or Behavioral in the Design Paterns book (Gamma et al. 1995). It occurred to me that all the 42 design patterns described in your chapter in "A Generative Development-Process Pattern Language" could probably be classified under the following three dimensions: Structure, Process, and Behavior. These three characteristics are common to all organizations. Further, if we clearly define what is meant by structure, process and behavior, it might be possible to classify software patterns described in the Design Patterns book using the same three dimensions: Structure, Process, and Behavior. Outlined below is an analysis of why I feel that this classification factors out the analogies between software design patterns and organizational patterns. '''Structural Patterns''' Structural software patterns deal with how classes and objects are composed to form larger structures to realize new functionality (Gamma et al. 1995). Structural organizational patterns would cover established patterns of interacting and coordinating technological and human structure of an organization. Both software and organizational structural patterns refer to more than just fixed relationship among elements. In structural software patterns, the added flexibility of object composition comes from the ability to change the composition at run-time which is not possible with static class composition (Gamma et al. 1995). Similarly, in organizational structural patterns, factors like human behavior and interaction cannot be placed on a static organizational chart. For example, "Buffalo Mountain" appears to be a structural organizational pattern based on communication and human interaction. The Design Pattern book (Gamma et al. 1995) classifies creational software patterns as distinct from structural patterns. However, it might be possible to consider creational patterns as structural patterns at a specific point in time - object creation. They deal with object composition at creation time. '''Process Patterns''' Process software patterns could be considered as patterns that are concerned with communication flow. These would include patterns that describe how peer objects cooperate to perform a task that no single object can carry out by itself (e.g., Iterator, Memento, Mediator, Observer). Process organizational patterns would be patterns relating to informational flow, communication and decision making in organizationsb(e.g., Group Validation, Review the Architecture). '''Behavioral Patterns''' Software behavioral patterns characterize the way in which classes or objects interact to distribute responsibility (Gamma et al, 1995). Software patterns in this category could include those patterns that involve delegation heavily (e.g., State, Strategy). Organizational behavioral patterns could be considered as patterns which deal with delegation in organizations. The key components of delegation could be considered as responsibility, determining priorities, accountability, planning, directing, authority and establishing feedback. Examples of organizational behavioral patterns could be "Architect Also Implements", and "Code Ownership". Listed below is an attempt on my part to classify your organizational patterns into structure, process and behavior. Aesthetic Pattern Structure Application Design is Bounded By Test design Process Apprentice Structure Architect Also Implements Behavioral Architect Controls Product Structure Buffalo Mountain Structure Code Ownership Behavioral Compensate Success Behavioral Coupling Decreases Latency Process Conway's Law Process De-Couple Stages Process Developer Controls Process Behavioral Developing in Pairs Structure Divide and Conquer Structure Domain Expertise in Roles Structure Don't Interrupt an Interrupt Process Engage Customers Structure Engage QA Structure Firewalls Structure Form Follws Function Structure Gatekeeper Structure Group Validation Process Hub-Spoke-and-Rim Structure Interrupts Unjam Blocking Process Mercenary Analyst Structure Move Responsibilities Structure Named Stable Bases Process Organization Follows Location Structure Organization Follows Market Structure Patron Behavioral Phasing it In Process Prototype Process Review the Architecture Process Scenarios Define Problem Process Self-selecting team Structure Shaping Circulation Realms Structure Size the Organization Structure Size the Schedule Process Solo Virtuoso Structure Take No Small Slips Process Three to Seven Helpers Per Role Structure Work Flows Inward Behavioral If you see any merit in these ideas, I would really appreciate your feedback. I am very interested in doing research in this area and would like to know if there is any way I could help you with your effort in tying organizational patterns to existing research and theory in organizational psychology. My email id is ukaul_99@yahoo.com. -------- Very Nice work! How would you like to try applying these thoughts to the RAPpeL pattern language by BruceWhitenack that's in the same volume? I have a feeling it might also have a similar taxonomy. -- KyleBrown ---- Here is the same list organized alphabetically by grouping: Behavioral * Architect Also Implements * Code Ownership * Compensate Success * Developer Controls Process * Patron * Work Flows Inward Process * Application Design is Bounded By Test design * Conway's Law * Coupling Decreases Latency * De-Couple Stages * Don't Interrupt an Interrupt * Group Validation * Interrupts Unjam Blocking * Named Stable Bases * Phasing it In * Prototype * Review the Architecture * Scenarios Define Problem * Size the Schedule * Take No Small Slips Structure * Aesthetic Pattern * Apprentice * Architect Controls Product * Buffalo Mountain * Developing in Pairs * Divide and Conquer * Domain Expertise in Roles * Engage Customers * Engage QA * Firewalls * Form Follws Function * Gatekeeper * Hub-Spoke-and-Rim * Mercenary Analyst * Move Responsibilities * Organization Follows Location * Organization Follows Market * Self-selecting team * Shaping Circulation Realms * Size the Organization * Solo Virtuoso * Three to Seven Helpers Per Role