Home > Articles > Software Development & Management

The Pattern Challenge: How to Successfully Deliver Software Solutions via Patterns

  • Print
  • + Share This
Lee Ackerman and Celso Gonzalez, authors of Patterns-Based Engineering: Successfully Delivering Solutions via Patterns, offer some practical ideas for dealing with the obstacles that organizations typically encounter when attempting to use patterns in the software development lifecycle.
Like this article? We recommend

We Still Struggle with Patterns

For a couple of decades now, we've had access to patterns—proven best-practice solutions to known problems within a specific context. Searches via the Web, bookstores, and dedicated IT sites show that thousands of patterns are available. With this vast and increasing body of knowledge, proven best practices, why are we not more successful in creating software? We still struggle with solution quality—providing solutions that are flexible and reliable, meet performance goals, and are delivered on time—areas where we expect patterns to be able to help.

Following are some of the challenges we face in working with patterns:

  • Scope. Often we unnecessarily limit the focus of our pattern efforts. We're familiar with a small set of patterns, to be used in a narrow area of focus. And that's it. We limit our pattern thoughts to design and implementation. Although these aspects of software development and delivery are important, they're just a portion of the overall effort. What about management? Testing? Architecture? Requirements? A narrow scope limits the impact of applying patterns within a solution.
  • Team utilization. Organizations typically struggle to ensure that they have enough expertise available to complete the project at hand. We have a limited number of experts, and often find that they become a chokepoint in the project, limiting the speed at which others can go. We fail to capture our expertise as patterns, and we struggle as organizations to use patterns that already exist. Even in cases where we succeed with a handful of team members using patterns, we've struggled in scaling out to the larger organization.
  • Finding patterns. Thousands of patterns have been created and are available to be reused. How can we find those patterns that meet the needs of our current situation? How much time must we invest to find and then use a pattern? For existing patterns, how do we relate our requirements to the characteristics of a pattern?
  • Limited use of automation. In most cases when we've tried to use patterns, we've focused on using pattern specifications—the formal written documentation that describes the pattern. We haven't taken advantage of opportunities to use automation to help us in applying patterns to our solutions.
  • Measurement. We don't know where and how we're effectively (or ineffectively) using patterns. How long does it take for us to find a pattern? What's the cost of acquiring and using the pattern? What impact has a pattern had on our solution? on the overall business?

How Patterns-Based Engineering (PBE) Can Help

To address the challenges of using patterns, we look to patterns-based engineering (PBE), a systematic, disciplined, and quantifiable approach to the use of pattern specifications and implementations throughout the software development and delivery process. With PBE, we focus on efforts that help us to succeed in identifying, producing, managing, and consuming patterns. In the following ways, PBE helps to increase our effectiveness in using patterns:

  • Scope. When following a PBE-based approach, we create and use patterns across the software development lifecycle, considering how patterns can help us with design, implementation, testing, management, requirements, and so on.
  • Effective team utilization. Who is responsible for identifying opportunities for using or creating patterns? Ideally, everyone on the team should take some ownership in ensuring that proven best practices such as patterns are identified and used. If we're not explicit in this effort, and we don't create such a culture, we're likely to get disappointing results. With an agile and iterative approach to development, we have many opportunities to review requirements and progress to date, adjusting accordingly. Part of this review should include a look at patterns that can be used or could be created.
  • Finding patterns. To succeed with patterns, we need to create a culture that searches for patterns—ensuring that we have mechanisms in place to help pattern users find the patterns that will address the problems at hand. Our development process must include steps in which we look for opportunities to use patterns and plan for their use in our efforts. As we acquire and create patterns, we also must manage these assets, ensuring that the patterns are available from a known location, well described, and searchable, and that they map to known constructs and requirements.
  • Automation. Pattern specifications have been the most common form of patterns to date. However, as in any situation where we're looking to transfer a written, natural-language specification to a solution, we encounter challenges in ensuring the integrity and quality of the application. At a minimum, we need to account for human error—but we also need to watch for cases where the pattern is misinterpreted. This challenge increases as we look to reuse a pattern multiple times across a team—more so when the team is distributed.

    Pattern implementations—the creation of automations that codify the pattern in tooling—help us to apply a pattern quickly and consistently. In doing so, we can drastically improve productivity, reduce human error, and increase consistency. By using points of variability, we also can flexibly configure and apply the pattern in a manner specific to our situation.

  • Measurement. We need to leverage measurement as we apply a systematic and disciplined approach to using patterns. As we start a project or an iteration, are we thinking about what patterns may come into play? Do these patterns already exist? Are they available as pattern specifications or implementations? Must we purchase these assets, or can we acquire them from the community? Are these patterns unique to our organization—and, if so, do we have to create them? For those patterns that we must create, are we best served by creating specifications or implementations?

    We also need to consider the impact that patterns will have on our project. What are the expected benefits associated with using the pattern? What was the actual benefit? Have we positively impacted the project and the overall results of the business? To what degree?

Resources for Success with Patterns

With our book Patterns-Based Engineering: Successfully Delivering Solutions via Patterns, we introduce a resource to help individuals and organizations succeed in using patterns. To support the proper scope, effective team utilization, finding patterns, automation, and measurement, we introduce these resources:

  • PBE Core Values. A short list of values that we can use as the foundation for our pattern efforts. By embracing the six Core Values, we have a short and easy-to-remember list of values that we can use day-to-day in guiding our PBE efforts. In striving to be agile, flexible, and dynamic, we cannot overwhelm the team with too many rules, too many concepts, and too many things to remember.
  • PBE Patterns and Guidelines. The Core Values provide a good starting point—an easy way to get the team moving toward a common set of behaviors, thinking, and culture. However, we still need more support in the work to be done. What are the best practices in identifying, managing, consuming, and producing patterns? The PBE Patterns and Guidelines provide a set of patterns and advice on how to identify, manage, consume, and produce patterns successfully. As with other patterns, the PBE patterns provide best-practice solutions that solve recurring problems within a given context. However, these patterns apply within the domain of patterns. Guidelines provide further input and advice on how to address aspects of patterns in a less formal way, again covering pattern identification, production, management, and consumption.
  • PBE Practice. Going one step further, the PBE Practice provides details on the PBE roles, tasks, work products, and workflows. It builds on the Core Values and the PBE Patterns and Guidelines, discussing how these elements come together to support the roles, tasks, work products, and workflows within the practice. The practice can be merged with other practices, customized, and then published as a set of web pages that can be consumed by the team.

Combined, these resources define a rigorous approach to using patterns in software development. With a focus on consumability and agility, these resources can easily be understood, integrated with current practices, and then rolled out across an organization.


To date, individuals and organizations across industries and locations worldwide have adopted the concepts found within PBE. Many of the organizations themselves span multiple locations. We've seen boosts to overall team productivity, increased quality in the resulting solutions, and the ability to leverage the skills within the team more effectively than ever before. Whether you use Scrum, XP, Unified Process, or other approaches to software development, patterns-based engineering can be integrated to deliver tangible results to your development efforts.

For More Information

  • + Share This
  • 🔖 Save To Your Account