Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Patterns-Based Engineering: Successfully Delivering Solutions via Patterns

Patterns-Based Engineering: Successfully Delivering Solutions via Patterns

Patterns-Based Engineering: Successfully Delivering Solutions via Patterns book, by Lee Ackerman and Celso Gonzalez, focuses on how to improve efforts in identifying, producing, managing and consuming patterns – leading to better software delivered more quickly with fewer resources.

InfoQ spoke with Lee and Celso about the book, patterns for working with patterns, MDD and the promise of reuse. We are also making an excerpt (Chapter 9 – Introduction to the PBE Patterns and Guidelines) from the book available for our readers, published by Pearson/Addison-Wesley Professional. For additional information about the book including downloads such as the PBE Practice and a sample automated pattern (Subsystem Façade) we encourage you to visit

InfoQ:  You are advocating pattern based engineering.  Is engineering the right metaphor for what we do as software developers?

Ideally, the answer is yes. As we create our solutions, we are giving thought and analysis to what is being created. We are systematic, disciplined and look to quantify the impact of the choices that we make. But having such an approach doesn’t mean that there’s just one right path forward. We each need to find the right level of formality that’s necessary for the project and team that we are working with.

InfoQ:  The "correct" format for documenting a pattern (e.g. Full Alexander, Gang-of-Four) is still a controversial issue.  Your description of a pattern is pretty minimalist.  How much attention should be spent on documenting a pattern?  Which model of pattern documentation do you find most useful?

We both tend to be quite pragmatic and we hope that this is reflected in the book and the approach we have taken in describing patterns in general and the patterns that we have authored. Whether the discussion is over code style (where should that ‘{‘ be placed?), which text editor to use (vi or emacs?), which operating system is better (Mac OS, Windows, Linux?) – it seems that we as an industry like to have our heated discussions. However, these discussions can often take us away from the important aspects of what needs to be done.

Currently in the industry, we are still scratching the surface of what we can achieve via the use of patterns. We struggle both with the production of new patterns AND even more with the consumption of existing patterns. In addition, the use of automation in working with patterns is still in early days. We’d prefer to focus our attention and effort on these bigger problems rather than getting bogged down in semantics. Yes – we need to spend time in documenting (and automating patterns) – however, the majority of the focus should be on ensuring that we are capturing the essence of the pattern and supporting the users of the patterns.

There is no one size fits all pattern template. So regardless of the template we choose, we should focus on writing for and communicating with our target audience.

InfoQ:  Your book is not of patterns, but is about the process of discovering and using (re-using) patterns as a kind of asset.  Does the process you describe exhibit its own patterns?  Any kind of meta PBE patterns?  Would there be any value in such patterns were they to exist?

We dedicate a significant portion of the book discussing a set of patterns and guidelines that support Patterns-Based Engineering. In the case of the PBE patterns, these are indeed meta-patterns - that is, patterns for working with patterns. The PBE Patterns and Guidelines provide support as we identify, design, create, package and consume patterns.

We also leveraged other related meta patterns, such as the Patterns Pattern language by Meszaros and Doble, as we wrote the PBE patterns. We hope and expect that the set of meta-patterns will continue to grow over time.

InfoQ:  One of the criteria for a pattern being a pattern is its recurrence in multiple contexts.  Your book seems to suggest that patterns can be found, documented, and reused based on experience with a single project.  Can you talk a bit about this apparent conflict?

We’d argue that there’s not a conflict. As we look at a project, there are often situations that are unique to the project, yet occur many times within that project. Upon further analysis, we may find that a best practice approach to the situation is recognized, and needs to be applied consistently across the project. Over time, we will continue to look for situations where that pattern may be applicable. It may need to be modified or updated as we are exposed to more projects and possibly more organizations. On one hand, it would be great, if the applicability continues to grow and is recognized and used across the IT industry. However, there still is significant value in identifying and then using this pattern within a project, an organization or an industry.

In addition, every project team brings much history and experience with them. Although we may create and then use a pattern on the same project – we are likely to have come across similar situations in the past, and see that a pattern opportunity has arisen. So there is a recurrence in multiple contexts.

InfoQ:  The pattern concept has been applied to many different aspects of software development and you note several of these, e.g. coding patterns aka design patterns (GoF), architecture patterns, and analysis patterns (Fowler).  But the concept has also been applied to team structure, social patterns, business patterns, etc.  What role might these "non-software engineering" patterns play in PBE?

We explicitly set out to keep our writing focused on software development as a way to manage scope. With that in mind, we’d change the question around a bit to state: “What role might PBE play in non-software engineering situations?”. And our expectation is that there is a strong role to play – patterns have wide applicability. In looking to use patterns within these other domains there is value in being systematic, being disciplined and looking to quantify the value and impact of using patterns. In doing so, we need to have support for identifying, designing, building, packaging and consuming these patterns.

With that said, those patterns can be used in combination with the PBE patterns. Again, our focus with PBE is on being systematic, disciplined and quantifying our work with patterns. The patterns used can be GoF, Architectural, Analysis, or from other areas. For example, in the book’s case study the development team is following the “Conway’s Law” pattern from Coplien et al. Organizational Patterns of Agile Software Development.

InfoQ:  You note that a simple library or catalog of patterns is not as useful as an inter-related, mutually supportive patterns - what Alexander called a Pattern Language.  Is there a pattern language in your book?

At this point, we have provided a catalog of PBE patterns (and related guidelines). In describing the patterns, we have documented the relationships between the patterns. The use of the PBE Practice provides additional guidance in regards to pattern relationships to other patterns, tasks that are performed and workflow timing.

However, this is an area that is ripe for further research as we look to go beyond catalogs of meta-patterns and recognize, organize and disseminate pattern languages that focus on meta-patterns.

InfoQ:  PBE is an example of Model-driven development (MDD) mostly as a result of using the engineering metaphor as a philosophical base.  Throughout the book you mention the possibility of automating PBE and the use of patterns.  To what extent do you share the core intent of MDD - create a formal model and mathematically transform that model into correct and executing code?

We’d actually start with a simpler definition of MDD, whereby we focus on using model as abstractions – hiding details that are not necessary at a particular moment in time. Automation can be a boon to productivity – but is not a necessity in performing MDD. We could use pen and paper, white-boards, or simple software applications that allow us to model.

When working with PBE we encourage and support the use of both pattern specifications and pattern implementations. Pattern specifications are the formal, written documentation such as what we find in GoF book and many others. A pattern implementation is the codification and automation of a pattern in tooling. There are a number of ways that this can be accomplished and many tools that support the creation of such automations.

Tooling to create and work with pattern implementations is continuing to mature. To date, the most impressive results that we have seen have been through the use of Java Emitter Templates (as found in Eclipse). The tool simplifies the effort that goes into analyzing exemplars – those reference solutions that will serve as the basis for the automation. In analyzing the exemplar, JET simplifies the pattern creation process and makes this capability something that anyone can learn to use. Ease of use, and speed of delivery are some of the important aspects of driving adoption of pattern implementations.

We’d also caution against unreasonable expectations of having a bit of modeling, a few patterns, and then being able to generate 100% of a solution. Such thinking at this point will lead to issues in over investment in pattern development and modeling. Better to look to build out a pattern repository, use compound patterns and recognize a role for seeding the code and incorporating user regions where code can be augmented after generation.

InfoQ:  The very first benefit of PBE in chapter 17 is increased productivity via reuse.  Reuse was the great promise of object-oriented development.  It did not pan out.  Why will pattern-based reuse have a better chance of succeeding?

We struggle with the idea that reuse has not panned out. We’d agree that the idea of reuse was oversold and oversimplified. However, we need to keep in mind the significant amount of reuse that has been achieved by using OO concepts and related ideas (e.g. frameworks, libraries, components, etc).

Patterns not only help us in sharing and consuming best practices, but also take us forward in the next step of coarse-grained solutions. And in taking that next step forward, it’s not that the components are larger in size, but that they provide points of variability that allows us to customize the pattern as we apply it to our situation.

With that in mind, one big difference between patterns and OO reuse is that patterns are reuse of design in contrast to reuse of code. Due to its higher level of abstraction, patterns are often more reusable than code.

And last, but not least, we also need to focus on pattern consumption. Today there are already thousands of patterns available for reuse. However, we struggle to find the right pattern at the moment of need. As we improve our ability to find patterns (according to requirements, relationships, workflow) we will see a subsequent increase in reuse and ROI.

InfoQ:  You advance a strong argument that PBE offers potential economic advantage to an adopting enterprise.  Will it be possible to make an accurate economic determination that "the use of pattern X in project Y saved the company Q hours and R dollars?"  Or more generally, can PBE be integrated into the software economic models like those first advanced by Denne and Cleland-Huang in their book, Software by Numbers?

There are two key things that we’d like to highlight in answering this question. The first is that as we develop solutions we need to account for the impact that pattern specifications and implementations can have on the project. This includes using patterns that already exist as well as looking at those that we would build and then consume within the project. In far too many cases, the discussion about patterns and their impact is not occurring. Many projects use patterns – at multiple levels in their solution, but the impact of the choices is seen only as part of the technical solution. We need raise the level of this discussion.

The second thing we then need to look at is a determination of how much we want to invest in calculations. How accurate do we need to be? How accurate can we be? How much time and effort do we need to put into the calculations? How much data do we have that we can use in the calculations? Being precise (or appearing to be precise) without also being accurate provides little value.

The impact and importance of following an agile, iterative and incremental approach cannot be understated. We can start with estimates of expected impact, but as we work through our iterations, we can update and refine our calculations with real world data on the impact patterns are having in our context. This is especially important as we continuously look for opportunities for patterns across each of our iterations.

InfoQ:  Alexander viewed pattern languages (and therefore patterns) as a "gate" to pass through before one could truly practice the "Timeless Way of Building."  Kent Beck, talking of Extreme Programming, also said that XP best practices need to be transcended before one became truly Agile.  Is PBE as presented in your book also a first step that needs to be followed almost by rote, then adapted, and then ultimately transcended?

We see great importance in having a small, core set of ideas that are easy to remember and act upon and then provide additional guidance and practices that can be used and customized to meet the needs of an organization. To this end, within PBE we provide 3 constructs: a set of core values, a development practice and a set of patterns and guidelines.

The PBE Core Values, include the following:

  1. Patterns are best used in combination, rather than in isolation
  2. Always identify and build new patterns
  3. Patterns can be built and used within the same project
  4. Make your patterns live
  5. Focus on making patterns consumable
  6. PBE can fit into many different development processes

We can then build upon this base with the PBE Patterns and Guidelines and the associated PBE Practice. We’ve already mentioned the Patterns and Guidelines, so we’d like to take a minute to discuss the PBE Practice. The idea with a practice is that it is a development process component. Within this component, we detail the roles, tasks, work products, deliverables and workflow associated with PBE. We can take this component and integrate it with other practices – such as a Scrum practice, or an XP practice – and create a development process that meets the needs of a specific project. We’ve authored the practice using the Eclipse Process Framework Composer – and have licensed the content using Creative Commons. The goal being to make it simple for someone to download, review and then customize the content. At the end of the customization effort, you can publish the content as a set of HTML pages that can be accessed and referenced by the entire team.

About the Book Authors

Lee Ackerman, a Distinguished IT Specialist at IBM, and Celso Gonzalez, a Senior Developer in the IBM Rational development team are the co-authors of Patterns-Based Engineering: Successfully Delivering Solutions via Patterns. Together they have over 25 years of experience in delivering software solutions and have written numerous articles and IBM Redbooks on best practices related to Patterns, MDD and Software Architecture and Development.

This excerpt is from the book, 'Patterns-Based Engineering: Successfully Delivering Solutions via Patterns', authored by Lee Ackerman and Celso Gonzalez, published by Pearson/Addison-Wesley Professional, July 2010, Copyright 2011 Pearson Education, Inc. For more info please visit this link.

Rate this Article