The Missing Patterns
The SCM Pattern Language as it appears in the book software configuration management patterns, and the other patterns that are in the streamed lines pattern language and other places do not solve every problem the development team faces. Often, the most important patterns to document and disseminate are the ones that the expert practitioners use regularly and talk about, but never take the time to formally write-up in a book or paper that will be readily accessible to users who need it most. Here are some areas for which additional patterns would be useful. Some of these come from the list of patterns that Brad and Steve didn't include in the book for a variety of reasons. Many come from questions that we've been asked, either on the SCM patterns discussion list, or in private.
We invite you to think about practices that seem to work well in your environment, practices that seem to solve problems in a good way and that balance many difficult tradeoffs. Maybe you know the basis for another pattern that hasn't been documented yet.
- Build management: For using or structuring make/ANT files and their corresponding rules (maintaining build dependencies, building all or part of a system, supporting multi-platform or component-based building, parallelizing builds or using a build-ring, standard sets of Make/ANT targets (i.e., clean, install, update, test, docs, etc.)
- Physical software design patterns (a.k.a. code architecture): Best practices for how to store and organize assets under configuration management across one or more repositories, and across directory-tree structures within a repository in order to assist not just software design/architecture, or to minimize build-dependencies or build-times, or assist traceability and/or configuration auditing
- Change Control: Setting up, chartering, and running and facilitating a CCB (see patterns from Ellen Gottesdiener's book Requirements by Collaboration ), deciding policies for obtaining stake-holder buy-in
- Configuration audit/review: Conducting or automating audits and reviews of builds and baselines
- Configuration status accounting/reporting: Tracking and managing the status of requests, changes, and baselines the face of multiple releases and/or variants, change propagation and coordination with multiple codelines and/or sites and/or vendors/suppliers, devising and implementing promotion lifecycle models
- Distributed and/or multi-site SCM: Including integration coordination/ synchronization topologies for distributed parallel development
- Multi-component and/or product-family SCM: Effective strategies for working with multiple versions of multiple components being integrated into a system, and/or for families of components with subsets of components and component versions being combined and configured to build/package/ release multiple products in a product-line
- SCM Solution selection/deployment/architecture: Plotting the particulars of how SCM will operate within your organization, defining an overall process framework and governance, evaluating SCM tools and technology, administering and deploying/upgrading tools and processes across a network of servers and repositories and workspaces, coordinating and synchronizing upgrades of repositories and workspaces
- Database CM: CM of databases, stored procedures, database schemas and views, queries and reports; configuration and use of database workspaces and production sandboxes and database code integration.
- Web SCM: Configuration and content management of websites and web software, including all artifacts (code, HTML/XML files, XML schemas and ontologies, JavaBeans and EJBs, managing JAR/WAR/EAR files)
- Service-Oriented SCM: SCM for service-oriented architecture, and service-oriented architecture of SCM itself (i.e., CM services model of dart )
- Enterprise CM: Managing change across the enterprise, CM of enterprise architecture, CM with and for business processes, workflow, B2B and EAI
The Pattern Language Angle
As previously mentioned, patterns describe individual solutions to a recurring problem in a context. A pattern language is more like a seasoned "trail guide" thru a set (or family) of related patterns that build upon one another. They help "connect the dots" to realize a more complete overall SCM domain solution. Documenting more proven SCM patterns is important, but so is being able to successfully select from and navigate through a growing body of SCM patterns. In addition to inviting you to document and disseminate more SCM patterns, we also heartily encourage you to help others see how patterns work together. Possible topics include:
- Connecting and inter-relating patterns: Taking some existing named best-practices and showing how they work together to create a larger solution (where to start, where to go next, what factors to consider in choosing the next stop on the destination). One possible example would be to take the patterns in the software configuration management patterns, and in AntiPatterns and patterns in software configuration management  and relating them all together to "connect the dots" between them.
- Sharing experiences with power of pattern names to convey an SCM concept in a tool-independent way, and/or with a suite of patterns to create a shared language in one's own shop for discussing and disseminating SCM problems/ solutions and process
- Relating patterns or pattern-languages across domains: For example, taking a set of SCM patterns and relating them to a set of software testing patterns, or a set of project management patterns, or a set of requirements management/ analysis patterns, or software architecture patterns.
- Rationale for using patterns and pattern format (and pattern languages) as an effective means of naming and sharing knowledge of SCM best practices (as opposed to the approach currently taken by BOKs such as PMBOK and SWEBOK)