See also FocusGroupOrganizationPatternsChiliPlopTwoThousand
are to the architecture of a social organization as DesignPatterns
are to software architecture and design.
believes that ProcessPatterns
are closer to the spirit of ChristopherAlexander
's patterns even than DesignPatterns
are, because they deal with more basic daily social needs of people, as Alexander was trying to do with his architectural patterns. Social structures are to the social well-being of the workplace resident as architectural structures are to the social well-being of the home dweller.
founded a research program at AT&T to study organizations using techniques borrowed from object-oriented analysis. Sociometric data were gathered from an organization using CrcCard
s; the data were visualized as a social network, with each card being a node in the network, using techniques similar to those pioneered by WimDePauw?
, and JohnVlissides
. These visualizations helped highlight a wide variety of social patterns in these organizations: the tools helped us act as organizational anthropologists. (Anthropology is the study of patterns of relationships in a social structure.)
Coplien took this work forward with collaborators such as BrendanCain?
, and others. Neil in particular did some amazing statistical analyses on properties of the social networks; these will be published in Volume 2 of the AnnalsOfSoftwareEngineering?
) and have appeared in the Summer 1996 issue of the BellLabsTechnicalJournal?
). In the mean time, the patterns were captured in Alexandrian form: instead of just looking at the patterns in an organization, we designed the patterns to be installed
in an organization to fix organizational problems. These patterns can be found in http://www.bell-labs.com/~cope/Patterns/Process/
In 1993, DavidWeiss?
devised taxonomies of ProcessArchitecture?
have also built substantial ProcessPattern
languages; see  and , respectively. BrianFoote
have a pattern language that also has a strong process component; see . SteveBerczuk
has some great organizational in their own right, but is a master at weaving organizational and design patterns together into a unified language. [Any of these on-line?]
has built a set of RiskReduction
, some of which are ProcessPatterns
. Some were published in SurvivingObjectOrientedProjects
. The largest set are on http://www.bell-labs.com/~cope/Patterns/Process/
, the original set, with commentary from other readers are at http://members.aol.com/acockburn/riskcata/riskbook.htm
Running through all of these is the thread that software construction, research, and most of the really interesting work activities are fundamentally social
activities. For a good guide to the different cultures one has to deal with, including executives, operators, and engineers (in the general sense -- I'd suggest the more general term quants
), I'd suggest Edgar Schein's working paper [http://learning.mit.edu/res/wp/10011.html
] at MIT's Center for Organizational Learning.
The MIT Center for Organizational Learning is closed. The above URL to learning.mit.edu is dead.
Edgar Schein's home page appears to be [http://web.mit.edu/scheine/www/home.html
], but the above link doesn't really give enough of a clue to figure out which of the publications there it's referring to. -- SJO
See also a talk from MarkWeiser about the reality distortions when engineers and management try to communicate [http://www.ubiq.com/weiser/icse/], very entertaining. -- SteveFreeman
I agree with Cope that process and ProjectManagementPatterns
fit the pattern form extremely well - project management consists of little else than resolving forces. Also agree with Ken about software development as a social activity. References are to KristenNygaard
in a 1986 paper "Program Development as a Social Activity" (http://www.ifi.uio.no/~kristen/PDF_MAPPE/F_PDF_MAPPE/F_IFIP_86.pdf
), and PeterNaur
's wonderful paper, "ProgrammingAsTheoryBuilding
, which is the best analogy I have yet seen. My version is called SoftwareDevelopmentAsCommunityPoetryWriting
Also the title of a book by ScottAmbler
. See ProcessPatternsBook