An organization is a system and, like most systems, it has structure. In particular, it is a social system. What does it mean for a social system to have structure?
The study of human organizations goes back thousands of years, and many of the schools of this nascent organizational science looked at structure. The Chinese classics like The Art of War [BibRef-SunTzu1989] talk much about organization structure--the organization of armies, some of the earliest large groups of people that needed guidance from organizational principles. The primary structure in a classic militia is one of hierarchy, authority, and top down control; most other structures respond to that.
These structures are part of culture (see AnthropologicalFoundations). A friend of ours in Siemens-Nixdorf claims to be able to trace the hierarchical structure of the company back to its founders, who were military officers in the Bismarck era in Prussia--a very hierarchical culture. One finds such overt hierarchy in much of German culture and in its companies.
But there are other kinds of culture that reflect different kinds of structure, and that structure comes about from the patterns that generate it. Another extreme is the contemporary Linux culture in software. It is an extremely shallow and broad hierarchy; that structure in turn leads to different processes (see BeyondProcessToStructureAndValues).
Culture is important. While engineering organizations traditionally seek technical missteps in their postmortem analyses, the contributions of culture are usually ignored. If you are in a culture, it's hard to see the culture, and that causes us to miss the important cultural roots of failed projects again and again. But we are getting better at it. The Columbia Accident Investigation Board lays blame for the Challenger disaster on the NASA 'culture.' Elements of that culture included its value system of funding, schedule, and safety [BibRef-Recer2003]. We don't need to wait for disaster to strike to take proactive steps to grow and repair corporate culture. That's what organizational pattern languages do.
Organizations are complex; we might define complexity as proportional to the number of distinct, meaningful views of a system. In software, we sometimes use the word architecture to describe the articulation of system structure. We can also talk about the organization as a system, a system that can be described by architecture, where an architecture comprises the structures in the organization and the relationships between them. The "structures" are patterns, and each pattern documents its relationships to the other patterns in the language. In this book we talk about four interrelated architectures of an organization. Each one has its own pattern language:
ProjectManagementPatternLanguage: This pattern language has to do with the work of the organization and how to structure it. It focuses on schedule, process, tasks, and in particular the structures to support good work progress.
PiecemealGrowthPatternLanguage: This pattern language describes how to grow the organization and process together; it is reminiscent of concurrent engineering approaches that grow the process and product together.
OrganizationalStylePatternLanguage: This pattern language looks at the structure of role relationships in the organization and what they portend for different organizational styles.
PeopleAndCodePatternLanguage: This pattern language is an expansion of the famous Conway's Law, that states that there is a close relationship between the structure of an organization and of the artifacts it builds. The pattern language offers further insight on organizational structuring in light of growing insight into the system architecture.
Each of the pattern languages reflects a domain. These domains came from our analysis of the patterns. We grouped the patterns according to how they worked together in sequences and, modulo a small number of pattern duplications, we just ended up with four groupings. There's nothing magic about the number "four," but it's nice and manageably small.
In practice, one uses all of these pattern languages in parallel. Each one describes a different architecture of the organization. Each of these architectures must be tended to. There are of course relationships between the pattern languages; in particular, some patterns are common to more than one pattern language. In this book we present each pattern only once, in the pattern language where it best seems to belong, and the other pattern languages make reference to that presentation of the pattern.
These patterns come from a wide variety of organizations, large and small. We feel that most of the patterns can be considered for most organizations, large and small. Large organizations almost always comprise a composition of several smaller organizations; almost all of these patterns were collected from identifiable groups that were cohesive in their own right, though they all had effective coupling to external agencies, organizations, and individuals.
The PeopleAndCodePatternLanguage is particularly applicable to small organizations, and those readers who have a particular interest in small team dynamics might find that chapter particularly useful. (However, neither of us believe in "large teams;" we don't believe they exist! The word team means something, and the spirit and effectiveness that come with the word team can't be sustained across large populations.)
With each pattern language we provide a story--from real life--that illustrates how patterns from the pattern language might fit together to achieve organizational growth, improvement, or maturity. These stories are a form of what we callsequences. A sequence is an architect's tour through the structure about to be built. It is a path through the pattern language; when you use the patterns in a given order, that is a sequence. For example, one may begin a new project by appointing an architect design the overall product (ArchitectControlsProduct). Because it is a big project, the architect gets help (ArchitectureTeam), and then they sequester themselves to come up with the initial architecture (LockEmUpTogether). This shows a small piece of a typical sequence of a new project. A given path, or sequence of patterns, results in a particular system, or whole. At the end of each of the four languages, we give a story that illustrates a sequence through the pattern language.
These sequences should help you get a feel for what the language is trying to build; what it's trying to achieve. They should give you a better feel for what pattern languages in general are about. They should help you see how the patterns tie together, depend on each other. As you read the pattern languages and consider your own experiences, you will be able to see sequences through the pattern language--your own stories.
Of course, all the possible sequences are implicit in the structure of the pattern language. You can and should generate your own sequence by going from pattern to pattern, working your way through the language. The pattern language diagrams presented at the beginning of each pattern language can be a guide. And sometimes you may find a place to apply a pattern in a way that's a bit out of sequence; as long as the context is suitable for the new pattern, let common sense rule and try the pattern if your instinct leads in that direction.
Near the end of the book we also present some case studies. These are like the sequences in the stories we present with each pattern language, only they are less structured. The case studies come from organizations we have studied and modeled, so we have less insight into their process of growth than we do for the examples given with the pattern languages. But one can still imagine what process might have taken place, and one can still see the interworking of the patterns in those stories.