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