2 Pattern Palette Adoption

Upon project inception, move quickly to adopt a coherent Pattern Palette. Continue to mature your team palette throughout the project life cycle.


Based on experience with “the Company,”[1] we submit that successful “Pattern Palette adoption”[2] is: inherited from a coherent pattern language, aligned with application architecture, a conversation best started during project inception, and never “frozen” after initial codification.

Coherence is a necessary condition for a set of patterns to be considered a Pattern Language, that is, patterns that “work together to solve problems.” (Manns and Rising 2005, 14)  A team Pattern Palette can inherit the coherence of its parent language, and thus become a “dialect” of the original. Ideally, the pattern language should be “proven”— it has been previously used with success to deliver similar (business) solutions in equivalent (technical) contexts.

Some patterns carry architectural implications, while others do not.  For example, a Business Facade class contains reusable logic that belongs within the business layer, whereas a Helper class could “reside” within any layer in the code base. Therefore, a team Pattern Palette is established in concert with the application architecture. Vetted patterns (or preferably a vetted pattern language) nudge a team towards application architecture durability while stimulating design inspiration. A suitable Pattern Palette incorporates “just enough” (and no more) up-front architecture as a foundation for long-term adaptability, and demonstrates “just enough” (and no more) richness and variety to kindle design insight.

Pattern adoption is a team design exercise that begins the process of aligning divergent technical perspectives. There is no need to wait for key stakeholders’ to fully articulate their complete set of project requirements. Technical alignment is particularly important for newly constituted teams during their “norming” phase.

We have observed project teams benefiting from face-to-face conversations when reflecting upon patterns from the PED Unified Pattern Language Collections, while similarly enriching their team palette from other sources.[3]  We concur enthusiastically with the sixth principle of the Agile Manifesto: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”[4]  A mature self-organizing team will leverage its collective wisdom by seeking opportunities to maximize the amount of work not done; collaborative adoption of patterns that guide effective development realizes one such opportunity.

Consider acknowledging a team champion to promote pattern adoption

A pattern champion should be well versed in the target technology platform (i.e., Java/JavaScript) and savvy about application architecture, design and testing. An effective pattern champion possesses pragmatic knowledge of commonly used industry patterns and is familiar with the enterprise pattern language.

The roles of a pattern champion may include:

  • Suggesting a viable initial palette
  • Responding with palette adjustments for team consideration as business requirements emerge
  • Making the pattern adoption process “big and visible”
  • Ensuring that the pattern selection conversation within the team begins early
  • Facilitating the revisiting of assumptions as circumstances warrant
  • Focusing the team on closing emergent gaps between the Pattern Palette and the code base
  • Leading a team towards discussions concerning the positive and negative consequences of implementation choices among design alternatives

We refer to patterns that the team has agreed to use as “on-palette,” whereas other patterns that are reflected in the code are labeled as “off-palette.” There is a natural tendency for the Pattern Palette and the code base to diverge over iterations, giving rise to two risks worth noting.

First, a team member may feel compelled to code to an on-palette pattern when an off-palette alternative is a better fit for their user story. The pattern champion helps the team recognize that, at times, an “off-palette” approach is appropriate. For example, if using an on-palette pattern would constitute its misuse, the champion may encourage an off-palette alternative.

Secondly, when an off-palette alternative is appropriately implemented, it may be unknowingly picked up by other team members. Unplanned reuse of an off-palette pattern may constitute a good reason for including the pattern on the Pattern Palette. Should such circumstances materialize, the pattern champion facilitates a discussion about whether the pattern warrants promotion to the Pattern Palette, or remains a valid, albeit off-palette, alternative.


[1] In 2002, Java was adopted as the standard platform for in-house development at a successful large automotive manufacturing enterprise (“the Company”).

[2] The metaphor of a Pattern Palette suggests an artist’s palette, and implies an adaptive, non-prescriptive adoption of patterns from one or more pattern collections, for use on a project.

[3] We are not arguing for the PED collections, uniquely. Our bias is, of course, that PED be consulted as a starting point, but the inclusion of other patterns may provide additional inspiration for a team adopting its own Pattern Palette.

[4] http://agilemanifesto.org/principles.html

Manns, M. L. and L. Rising. 2005. Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley