Chapter 17. Benefits of PBE

This chapter discusses the benefits of adopting PBE and its Core Values, Patterns, Guidelines, and Practice. We will also touch upon some of the associated PBE Patterns and Guidelines that can help achieve those benefits. Details for the Patterns and Guidelines were provided in Part II, starting in Chapter 9.

The following sections discuss the benefits of PBE according to the area that they impact, starting with the benefits commonly associated with patterns and automation, namely, productivity, quality, and communication. Later sections look at the benefits of PBE with respect to leveraging skills and expertise and improved governance.

Keep in mind that these benefits do not exist in isolation. They can impact and reinforce one another and lead to an upward spiral of success. For example, productivity enhancements from using and applying the patterns can free up time for other efforts. The team can focus on the specifics of the domain and unique aspects of the problem they are working on while leveraging patterns from already solved problems. This leads to more interest in the project—more creative and interesting solutions, better quality, and yet higher productivity.

Increased Productivity

In this section we’ll look at how the adoption of PBE increases productivity and enables us to develop and deliver software solutions more quickly and efficiently.

Reuse

A good place to start discussing increased productivity is the concept of reuse. Why would we want to repeat work and effort that’s already been done?

Patterns and Reuse

Patterns allow us to codify our best practices and to reuse them (manually or via automation) on different applications. We are able to invest once in the creation of the pattern and then use that solution many times over; we avoid effort associated with reinventing the solution. In addition, with patterns we look to reuse the design, allowing us to apply the best practice many times over while tailoring the solution to our context. Design reuse allows us to work at a higher level of abstraction, providing a further boost to productivity.¹ PBE Patterns and Guidelines that assist us in supporting patterns and reuse include Limited Points of Variability (Chapter 12), Pattern Implementation (Chapter 12), Pattern Implementation Extensibility (Chapter 12), and Pattern Specification (Chapter 13).

Timing of Reuse

Historically, reusable assets were often created at the end of a project. The goal was to then use those assets on future projects. This practice led to criticism that the benefits of reuse are always seen on the next project. It’s like investing for the future, the first project “paying the price” of the reuse. However, we are able to create and use patterns within the same project, and so the productivity benefits of using a pattern specification or a pattern implementation can be achieved in the same project in which the pattern was created.

Consider a project that involves persisting business entities using Hibernate. We could develop the Hibernate-related elements for the business entities that are within the scope of the current iteration. Alternatively, we could write a Hibernate persistence pattern specification or, even better, develop the related pattern implementation, so all the other developers who have to persist a business entity would apply our pattern. Note that we are not trying to build out for some potential but unknown reuse. When we create the pattern, we know how many times it will be used and where. The pattern approach would definitely be a huge timesaver if there were a large number of entities to persist on our project. And as the architects, we spend significantly less time answering the same questions over and over again, such as “How should I persist my business entity?” or “How do we implement a Hibernate-based solution?” Such a scenario does, however, place an onus on the developers within the organization to be familiar with PBE Patterns and Guidelines such as Communicate Design with Patterns (Chapter 16), End-to-End Pattern Use (Chapter 10), Pattern Opportunity (Chapter 11), Pattern Search (Chapter 10), and Single Pattern–Varied Use Cases (Chapter 10).

Systematic, Disciplined, and Quantifiable Nature of PBE

An important part of PBE is to be systematic, disciplined, and quantifiable. As we plan our projects, we analyze the possibilities and potential for patterns. Once a list of candidate patterns has been identified, we review and evaluate each of the patterns to determine and ensure that an appropriate ROI can be achieved. We recognize that we have limited resources, time, and expertise; we need to invest these resources in the areas where they make sense for the organization. Over time, we will identify many more patterns than those that will actually be acquired or built; however, we build only those that make sense based on our analysis. Productivity can be negatively impacted if we lack discipline and build any and every pattern that is possible. And as we move forward in consuming and working with our patterns, we capture metrics related to the impact of the patterns. We can leverage PBE Patterns such as Determine Business Impact (Chapter 11), Pattern Opportunity (Chapter 11), and Pattern Selection Driven by Requirements (Chapter 16) to help us focus on achieving success with patterns and reuse.

Patterns in Combination

We can boost productivity by using patterns in combination. This can be accomplished by recognizing and leveraging pattern categories, or through the creation and use of compound patterns.

Pattern Categories

A pattern captures the best available solution to a given problem in a specific context. This applies whether we are looking at a pattern with as small a scope as the Singleton² pattern or a larger-scale pattern that impacts the architecture of an application, like the Broker³ pattern. In itself each of these examples provides a productivity boost, but we certainly expect the Broker pattern to more significantly impact the application than the Singleton pattern. Some of the common pattern categories, as seen in Figure 17.1, reflect the different levels of scope, impact, and abstraction that patterns support. Larger-scale patterns, such as an architectural pattern, have a greater impact on the project, as they directly drive a greater proportion of the overall solution.

Figure 17.1. Leverage patterns systematically, selecting large-scope patterns first, followed by patterns successively addressing smaller scope.

We can leverage pattern categories systematically so that we consider and select our larger-scale patterns in advance of those of smaller scope. Such an approach improves our productivity because the selection of larger-scale patterns will influence and constrain our choice of smaller-scale patterns. In contrast, not following any approach and selecting an assortment of patterns in an ad hoc fashion could lead to pattern mismatches, rework, and a longer path to a solution.

Compound Patterns

The true productivity multiplier comes not only from the use of larger-scope patterns but also from the use of compound patterns. Recall that in a compound pattern we encapsulate a number of patterns that work together inside a larger pattern. A synergy is provided by the patterns working together within the compound. In addition, Pattern Users are able to more easily and quickly use the combined set of patterns. Patterns such as Compound Pattern (Chapter 12), Pattern Selection Driven by Requirements (Chapter 16), and Select Large-Scope Patterns First (Chapter 16) help ensure that we are systematic and following best practices in regard to pattern scope and pattern compositions.

Pattern Implementations

Using automation in the form of pattern implementations can significantly boost productivity. It is not necessary for each member of the team to internalize a pattern specification and then apply it (ideally, consistently with how the rest of the team will use it); a pattern implementation reduces the amount of knowledge needed to successfully apply the pattern. And the pattern implementation will apply the pattern consistently for each user in the organization.

This could become even more critical in the context of compound patterns. The pattern implementation is able to use encapsulation to hide the details (as necessary and desired) of the patterns within the compound pattern. Thus, the user of the pattern need only be concerned with the exposed, simplified interface of the compound pattern.

Last, but certainly not least, a pattern can be both applied and reapplied much faster with automation than manually. A pattern implementation can generate hundreds of elements in seconds, all according to best practice. Performing the same work manually is time-consuming and likely to lead to the introduction of errors. PBE Patterns such as Compound Pattern (Chapter 12), Model-to-Model Pattern Implementation (Chapter 12), Model-to-Text Pattern Implementation (Chapter 13), Pattern Implementation (Chapter 12), and Simple Solution Space (Chapter 10) help guide us in creating effective pattern implementations.

Increased Quality

By definition, a pattern represents a proven best-practice solution to a recurring problem. Given that, by getting our team to adopt and use patterns, we will end up with higher-quality solutions. Such higher-quality solutions are easier to understand, support, and test. In cases where we can create a pattern implementation, we can take this even further and aim to eliminate human error with an automated application of the pattern. Automation will apply the pattern exactly the same way it did in all previous instantiations (except allowing for the pattern’s points of variability). If we discover an issue with a pattern implementation, reapplication is much quicker than manually updating multiple applications of a pattern specification.

Consistency is another facet of quality; the greater the consistency in the system, the easier it is to understand and maintain. In the case of patterns, we are not just consistently applying any solution; we are consistently applying the best practices codified by the pattern.

These benefits can be realized only if the use of the pattern is systematic and disciplined. Consistency will not be realized if only a small number of people in the company are using the patterns. The PBE Practice helps in tackling the adoption issue by defining the roles, tasks, and work products associated with PBE, and it does so in a format that can be integrated with other process components. Additional support for quality is provided via PBE Patterns and Guidelines, including Design Solutions with Patterns (Chapter 16), Integrated Patterns and DSLs (Chapter 15), Pattern Testing (Chapter 13), Refactor with Patterns (Chapter 16), and Use Pattern Definitions to Understand Existing Solutions (Chapter 16).

Beauty of Software Architecture

Another more fundamental and subtle aspect of quality that we want to impact is referred to as the “beauty of software” or the “beauty of (software) architecture.” To explain it, let’s take a quick detour through the civil engineering domain. We have all probably experienced the feeling of beauty of architecture while looking at a building, a cathedral, or a bridge. Christopher Alexander⁴ explains this feeling by referring to the perception of the “quality without a name.” For him the beauty of architecture is more a mix of color and form, fitness to purpose as well as fitness to the environment, elegance, and simplicity—the little something that makes the building “alive.” It’s close to what mathematics teachers used to call the beauty of a demonstration: simple, clear, fit to the purpose.

According to Grady Booch⁵ and others, this same definition of beauty can be applied to software systems and their architecture. Patterns, particularly patterns used in combination, are an important factor contributing to that beauty. Their organization as a cohesive set makes the overall system glow and live; or, as Christopher Alexander writes, “The more living patterns there are in a thing—a room, a building, or a town—the more it comes to life as an entirety, the more it glows, the more it has this self-maintaining fire, which is the quality without a name.”⁶

When creating software solutions, we strive toward results that are fit to their purpose and environment, that have a sense of simplicity and elegance. Patterns, whether in civil architecture or software, increase our odds of attaining these goals. PBE Patterns and Guidelines such as Compound Pattern (Chapter 12), Pattern Density (Chapter 16), and Pattern Implementation (Chapter 12) help us to work toward beauty in software architecture.

Improved Communication

We have seen in the previous sections that patterns positively impact productivity and quality because they codify, and, in the case of pattern implementations, automate, best practices. Patterns can be seen as an abstraction of the design as they can summarize a complex set of design and architecture elements and interactions. In the context of communication, we leverage the capability of patterns to provide useful abstractions and a simple and meaningful vocabulary for working with those abstractions. Tens of pages of description can be replaced with the names of two or three patterns, considerably reducing the size of the solution documentation. This reduces the volume of the information that needs to be exchanged, while still maintaining its integrity and comprehensibility, improving the communication between the project members as well as with stakeholders.

A benefit of using pattern specifications is that they document design decisions in a clear and well-defined format, making these decisions easier to communicate. The pattern specification describes the problem, context, and the corresponding solution. Someone reading the pattern specification can easily understand the design decisions and the rationale behind those decisions. This improves communication among project members both during and after the project.

This last aspect, documentation of the application at the end of the project, is growing in importance as more and more systems are getting older and the people who developed them are retiring. A quote from Galileo comes to mind: “All truths are easy to understand once they are discovered; the point is to discover them.” When we are given an existing application to learn and support, it can be difficult to learn its intricacies. The code describes what the application really is, but not why it is what it is; it is therefore difficult (sometimes impossible) to answer questions such as “What are the design decisions that led to the actual architecture and design?” The challenge is to discover the truths behind the system; once discovered, they are usually easy to understand.

Modeling is a good way to capture design information, but we often find it challenging to keep the model and code synchronized. In those situations it’s always the code that wins out. In some cases we find that if we’d like to see the model maintained, we need to keep the modeling simple and to a minimum. The bigger and more complex the model, the more likely it is that it will quickly get out of sync. Patterns can help summarize some of these design and architecture decisions, reducing the amount of model elements to maintain. In addition, as tooling continues to advance, we will see additional support for patterns to be understood by the platform. Thus we will be able to examine existing code bases and have our tools recognize and record instances of pattern instantiations.

Using well-known patterns (public or internal) also simplifies design and architecture discussions. Rather than spending time drawing a complex diagram or describing details of the element design, referring to a pattern helps each project participant understand the related design or architecture. This fact highlights another characteristic of patterns: they need to be publicized. To obtain this kind of benefit, we need to make our patterns known and easily accessible so that designers and architects can familiarize themselves with them and use them in their discussions as easily as we use metaphors in our day-to-day life.

A number of PBE Patterns and Guidelines can be used to achieve improved communication, including Communicate Design with Patterns (Chapter 16), Embedded Pattern Implementation Guidance (Chapter 14), Integrated Patterns and DSLs (Chapter 15), Simple Solution Space (Chapter 10), and Use an Asset Repository (Chapter 16).

Better Leveraging of Skills and Expertise

The benefits we have considered so far are commonly associated with patterns usage, with the exception perhaps of the notion of beauty of architecture. The next benefit, leveraging of skills and expertise, although an important benefit, is often overlooked.

When looking at the current configuration of our software delivery organizations, we can relate them to the effort and support needed to build a human pyramid. When the pyramid is only 10 feet high, probably four or five people would be enough to build it. However, looking at Figure 17.2, we see that when building a pyramid that reaches 20 to 30 feet, we start to face some significant challenges in terms of the huge number of people needed to support the pyramid.

Figure 17.2. A mass of support is needed to reach the goal of the team.

Photo by Alex Castella. Reused under the Creative Commons license.

Similarly, in today’s software delivery organizations, in order to help the business reach new heights we need a large number of experts. However, that is one of the key resources that most teams and organizations lack. Experts are usually shared among projects, often generating contention and sometimes even bottlenecks. As a result, we struggle to find our way to successful project results. We certainly have tried a number of approaches to help us along, such as better tools and better documentation and communication. However, we still manage to come up short because of the lack of availability of these critical resources. What we really need to do is find ways to invert the pyramid, as shown in Figure 17.3, and have a small number of experts at the bottom who in turn are able to support a large number of other members of the organization (business and IT alike).

Figure 17.3. With patterns we invert the pyramid in order to better leverage available expertise.

Patterns help by enabling experts to codify their experiences and solutions in a manner that is easy to consume and leverage by others. Pattern Users need to know only how to use the pattern, not all of the details that went into its creation. They also get to bypass all of the trial and error that went into determining the best-practice solution. So, even though we have a small set of experts, the rest of the team is able to more efficiently leverage them and their knowledge by using patterns to solve common problems while calling upon the experts to help with new or more complex problems.

We also need to consider cases where a number of patterns are composed together; it may turn out that Pattern Users are not even aware that some of the patterns (and solutions) exist, never mind that they can be used together. In contrast, the expert can better determine that a composition of patterns is indeed the solution. An expert can fast-forward the effort in using these patterns by packaging them all together as a compound pattern. PBE Patterns and Guidelines that help us to better leverage expertise include Compound Pattern (Chapter 12), Integrated Patterns and DSLs (Chapter 15), Package Related Patterns Together (Chapter 14), Pattern Creation Lifecycle (Chapter 12), Pattern Implementation (Chapter 12), and Simple Solution Space (Chapter 10).

Improved Governance

Earlier in this chapter we considered a simple example of using a Hibernate-based solution for implementing object-relational mapping for a solution. In that case the architect chose this mechanism and the best-practice approach for using the mechanism.

When building a solution, how do we ensure that it is built according to design and that the selected patterns, best practices, frameworks, and standards are used? In addition, once such constructs are used, how do we ensure that the instantiations stay true to their original specification? For instance, if a pattern implementation is used to generate some portion of the solution, how do we ensure that the generated content is not changed? How do we prevent “undesirable creativity”? Clearly, we want our teams to be creative, but we also want them to channel those creative energies into the appropriate areas of the solution.

Pattern implementations can help by automating the initial application of best practices. However, as noted previously, this doesn’t solve all the problems we run into. The variability points provided by a pattern help in that they allow us to customize the solution that is generated, so that the solution fits our context. We can take things a step further by having “user-modifiable” regions that specify where in a generated solution the Pattern User can augment the solution.

There are two additional ways in which we can leverage automation. The first is through integration with an automated build system. Each time we build the application we can have the build system invoke the pattern implementation, ensuring that the generated portions stay true to the best practice. In such a situation all generated output is overwritten except for that which is located in “user-modifiable” regions. A second approach that we can use is automated pattern detection solutions, which verify that certain patterns are used in the solution and that the instantiations are true to form.

The use of PBE and an asset repository also help us govern our pattern catalog and guide investment in the right patterns, maintaining only the ones that are used, giving us more time to invest in discovering and codifying new patterns, and validating the patterns that are made available. PBE Patterns and Guidelines that support governance efforts include Antipatterns (Chapter 11), End-to-End Pattern Use (Chapter 10), Limited Points of Variability (Chapter 12), Pattern Implementation (Chapter 12), Update Existing Patterns (Chapter 11), and Use an Asset Repository (Chapter 16).

Support for Globally Distributed Development

Another dimension that increases the complexity of governing the software delivery effort is when we have a globally distributed team. Ensuring that all the members of a team are headed in the same (and correct) direction can be challenging enough when everyone is in the same building. Things become even more daunting if the team members are distributed throughout the world, across multiple time zones, and we’re dealing with multiple cultures and languages.

All the benefits of PBE mentioned earlier in this chapter are also applicable to this kind of development, but the following benefits are specific to this situation:

• Communication. In some cases not every member of the team has a common first language. There can be challenges in communication, based on both understanding the language as well as cultural references. Patterns help to address these challenges by providing a common vocabulary that is documented according to well-known principles.

• Automation. Providing all team members with a relevant set of pattern implementations ensures that best practices are consistently applied by all the team members, wherever they are located. This will increase the cohesion and maintainability of the application.

• Detection. Using patterns as input into software analysis and detection tools can ensure that deliverables adhere to and leverage the correct set of patterns and best practices. This is particularly applicable when the application is architected in one location and then implemented elsewhere. Detection for pattern use and adherence can be integrated into an automated build process.

PBE Patterns and Guidelines that support globally distributed development include Communicate Design with Patterns (Chapter 16), Design Solutions with Patterns (Chapter 16), and Use Pattern Definitions to Understand Existing Solutions (Chapter 16).

Summary

In this chapter we looked at the benefits of adopting PBE, where we use both pattern specifications and pattern implementations in a systematic, disciplined, and quantifiable manner. We looked at some of the more obvious benefits, such as increased productivity, improved quality, and improved communication. These are benefits that are often mentioned in other literature that discusses patterns. However, this is not the full extent of the benefits that can be achieved through the use of patterns. Three additional benefits need to be considered as we seek to leverage patterns within our projects. These benefits include support for governance, support for globally distributed development, and increased leveraging of available expertise.

The chapter highlighted how some of the PBE Patterns and Guidelines can help us achieve the benefits associated with PBE. Full coverage of these patterns and guidelines begins in Chapter 9.

It is also important to note that PBE can provide us these benefits, whatever development process we are using. Chapter 8 describes how to adopt PBE into an organization and highlights the relationship of PBE to some well-known processes and process frameworks.