Chapter 10. Foundational Patterns and Guidelines

If we could have only a small set of patterns and guidelines to use in helping us with our PBE efforts, which would they be? What would be the most important things to do and remember? Could such a set provide us with a foundation that we could then build upon as we use the other PBE Patterns and Guidelines?

This chapter provides such a set of PBE Patterns and Guidelines, a set that focuses on a range of topics that are core to the PBE discussion. Although the set is small, we will touch upon pattern identification, pattern production, pattern consumption, and pattern management. These foundational patterns will play a key role in our success in adopting and following PBE, reinforcing a disciplined, systematic, and quantifiable approach. This set of patterns helps us to answer questions such as these:

• When looking at the development lifecycle, where should we use patterns?

• Where can we find patterns?

• What type of patterns should we look for?

• How should we use patterns?

• What approach should we take when building patterns?

• How do we support the consumption of patterns?

• Last but not least, what are some of the factors that we should consider as we calculate the impact of our patterns?

Patterns

The patterns discussed in this section focus on a number of topics, ranging from where in the development effort we should use patterns to how we create patterns and then simplify consumption. The tie that binds them is their importance in providing a foundation for our PBE efforts.

End-to-End Pattern Use

Context

The organization recognizes that there are multiple stages and disciplines within the software development lifecycle. There is also recognition that there is a range of skills and capabilities across the team. And there is a need to increase productivity, improve quality, and better govern the software delivery effort.

Problem

Many aspects of the SDLC are tedious and error-prone. Efforts are further complicated by best practices that are not recorded adequately, communicated, understood, or followed. How do we get the organization to follow best practices in a consistent and enforced manner? How can we do so while also accelerating the speed of the project and improving overall quality?

Forces

• The entire development organization needs to be involved in adopting and using PBE.

• A separation of roles can ease the rollout of the PBE effort.

• We must ensure that we are keeping patterns up to date and reflective of current best practices.

• We must recognize that patterns do not exist in isolation. There are numerous roles, tools, and tasks within the SDLC.

• Culture increases in importance as we expand the scope of pattern impact.

• We need to make sure that there is the capability to author, update, and distribute process knowledge.

Solution

Use patterns with an end-to-end focus across the entire SDLC. We should not artificially restrict the areas where we use patterns.

Why would we use patterns for only a single aspect of the SDLC? No matter how efficient we become in using patterns for design, we still have a limited impact on the overall success of the project. Consider, as shown in Figure 10.1,¹ that the design discipline is just 15% of the overall effort of building a software solution. Perhaps we could have a greater impact with the implementation discipline, which accounts for 25% of project effort. However, “[c]oding is only the fourth most expensive activity when building large software applications. Maintenance, testing, and defect repair, documentation, and even meetings and communication can be more expensive.”²

Figure 10.1. Effort allocated to each of the disciplines within the SDLC

We need to broaden our scope and look beyond a single discipline as we adopt PBE. We should build and use patterns across as many of the disciplines of the life-cycle as possible. Why limit ourselves to one narrow slice of the overall effort? That sounds reasonable, but the question is, how do we make this happen?

The first obvious step is to consider as wide a scope as possible. As we look at each of the disciplines, we need to consider where patterns could be used and where new patterns may exist. However, we cannot force all of the roles, tasks, work products, and tools to revolve around patterns. Rather, we need to find ways to fit patterns into these elements—enhancing them, supporting them, and improving them. Here are some strategies that we can apply:

• Skills and expectations. Be aware of the skills and expectations of the target Pattern User community.

• Pattern implementations and specifications. Within PBE we use pattern specifications and pattern implementations. Where possible, we use automation, so there is a preference for pattern implementations, but there is great value in both types of patterns. We need to focus on capturing the patterns of value and then determine the best approach to building and using them. For instance, some roles and tasks may not be well suited to automation. In such cases it would make sense to focus on pattern specifications.

• Culture. Create a culture not only of pattern production but also of pattern consumption. Even if we create the best patterns in the world, if no one uses them, we have failed. We need to ensure that this culture is nurtured beyond just the people involved in design.

• Development process authoring. The organization’s software development process should define the roles, work products, and tasks that detail how software will be delivered and call out the patterns to use. The set of patterns will change over time, so we need to update the process to account for the latest set. In addition, the use of patterns may lead to a reduction in process tasks and steps.

• Tooling. Each of the disciplines has tools that are specialized for certain tasks. For instance, the testing team has a set of tools that enable them to create and manage test cases, test the software, and manage defects as well as the associated patterns. We need to be aware of the artifacts that these tools work with, as there are many cases where we can use patterns to consume or generate them.

Example

In the case study, Oslec creates a pattern that starts with a focus on design, then increases in scope to include implementation and assessment. More specifically, as they create the Subsystem Façade pattern implementation, they increase the scope of the pattern to include the following:

• Design. The pattern brings together a number of design patterns, including the Session Façade and the Data Access Object patterns.

• Implementation. The pattern is enhanced to support the implementation of JPA code generation.

• Assessment. In addition to creating the design and implementation, the pattern generates a set of test cases.

In future iterations they could also use patterns to support the deployment of the LogoAuction application, further impacting the overall SDLC. In addition to having coverage across 70% of the SDLC, they would find that the use of patterns helps reduce defects, improve communication, and make maintenance easier.

Related Patterns and Guidelines

Determine Business Impact (Chapter 11), Pattern Opportunity (Chapter 11), Piecemeal Pattern Creation*³

Piecemeal Pattern Creation

Context

The organization plans to create and use patterns. There is time pressure on the project, and the organization is hesitant to make investments in reusable assets.

Problem

It can be difficult to figure out all aspects of a pattern during its initial design and creation. In addition, the scope of the pattern can be quite large. How can we deliver an effective pattern in a timely manner and positively impact our project?

Forces

• Not all patterns can be found, designed, built, and delivered within a single iteration.

• Risk is an issue when we do not use patterns or if we select patterns that end up not delivering the expected results.

• Increasing the scope of a pattern to touch upon a greater portion of the SDLC can have a positive impact on a project.

Solution

Take a piecemeal approach to creating patterns. We analyze and prioritize the development of the pattern features. We then map that prioritized effort across a set of iterations and incrementally deliver the needed pattern functionality. Such an approach allows us to deliver value to the project sooner; we are able to grow the scope of the pattern, easily adapt to changing requirements, incorporate lessons learned, and minimize the risk associated with the overall project. To guide our efforts, we can ask these questions:

• What are the most important aspects of the pattern that need to be delivered? What aspects can show up later? When does the pattern need to be used? How can we best minimize risk while delivering the most benefit?

• What areas of the pattern would provide the most significant portion of the ROI⁴? As a rough guideline, consider the 80/20 rule. Often we spend 80% of the effort on the last 20% of the functionality. Do we get the ROI we need from that remaining 20%? Where does the true value of the pattern come from? Can we focus on those areas first, release the pattern, and then use feedback and real-world experience to determine when and if further investments should be made?

• Consider the target audience that will be working with the pattern. What are their requirements for the pattern, and how do they prioritize those requirements? Taking things a step further, how will the pattern impact the solution being built? How does the pattern impact the key requirements and deliverables for the project where it will be used?

• What are the Pattern Users’ current skill levels in comparison to the skill level needed to work with the pattern? If training is needed for using the pattern, when will the training occur? How does such a training plan align with the timing of feature delivery for the pattern?

• Are there related patterns? How will this pattern interact with those other patterns? Are the related patterns already built? If not, what is their delivery schedule and how does that impact the delivery of the pattern that is currently being analyzed?

We use the answers to these questions to guide us in creating a plan for building the pattern. We want to ensure that the early iterations provide us with a usable and useful pattern that delivers an appropriate ROI within the current project. In addition, we want to ensure that we are aware of how the pattern could be enhanced for use in later iterations or even future projects. The decision on when and where to build the enhancements can be made at another time that is convenient and logical.

For the Pattern User role, we need to keep in mind that the catalog of available patterns is updated continuously. As a result, the supply of patterns continues to evolve, be enhanced, and grow. Ideally, our projects will leverage an iterative and incremental cycle so that we can take advantage of the most recent pattern versions.

Example

An example of using this pattern appears in the case study when Jordan implements the Subsystem Façade pattern implementation in two steps. First he implements the JET component, which can be made available for reuse. Then he implements the model-mapping component, in which he could incorporate feedback received from those using the JET component.

Jordan also focuses on current requirements and core capabilities of the pattern, for instance, in Chapter 5 when he looks to a future version of the pattern to incorporate Gwen’s enhancement request to generate the exposed business methods from the domain model. An additional requirement that surfaces in Chapter 7 is a request to support SOA-based services. This requirement is also set aside for a future release of the pattern.

Related Patterns and Guidelines

Determine Business Impact (Chapter 11), Pattern Creation Lifecycle (Chapter 12), Pattern Search*, Update Existing Patterns (Chapter 11)

Simple Solution Space

Context

We build solutions using multiple models and levels of abstraction. The development process is too complex, and skilled resources are at a premium.

Problem

Productivity is not high enough and the quality of the resulting solutions is insufficient. How can we leverage models, abstractions, and best practices without overwhelming the team?

Forces

• We need an expert-level understanding of the solution space, including the business and technical domains.

• We need to have an understanding of the skill level of the development team.

• Pressure can surface to get the project done by any means necessary.

• A holistic view of the development approach, domain, skills, and best practices is needed.

Solution

Simplify. Reduce the number of moving parts. Review and reduce models, DSLs, diagrams, and elements within diagrams. To assist and accelerate the effort, ensure that you are finding, creating, and applying the correct set of patterns.

As shown in Figure 10.2, if we look at a typical solution space, we use many models, and then within a model we use multiple DSLs and numerous types of diagrams. Digging a level deeper, we also see that within a DSL we use many language elements. There are too many moving parts, too many things to keep synchronized, and too many things to learn and remember.

Figure 10.2. Solution space and the many elements needed within to represent the solution

Figure 10.3 displays a simpler solution space. In this case we’ve reduced the number of models. In addition, as we look within the model, we see that there are fewer DSLs and we use fewer diagram types, and within the DSLs there are fewer elements. To reach this point we need more than just intent. To help us reach this simpler state, we incorporate patterns, both specifications and implementations.

Figure 10.3. Simplified solution space highlighting the role that patterns can play

Patterns help us to simplify the solution space in three key ways:

• We are able to use both pattern specifications and implementations to help us inject best practices into our solution. We are able to create solutions that are based on best practices, eliminating incorrect and extraneous elements. We are creating a solution that is as concise and correct as possible.

• Pattern implementations can be used to automate the creation of the solution. Yes, we are automating the application of the best practice, but we are also encapsulating details, rules, and assumptions within the pattern implementation. The net result is that we are able to reduce the amount of modeling that we perform, leading to fewer elements in the solution space.

• In general we can use patterns to reduce the elements in the solution space. We do not need to show all details and aspects of a pattern in the solution; the pattern, being a known element, allows us to abstract away details.

Example

As we follow Oslec in the case study, we see that they are looking for ways to create a simple solution space. They want to identify and then use patterns, from both external and internal sources. When using pattern specifications, they are mindful of how much detail needs to be modeled and how much is implicit because of the use of the pattern.

In the case of pattern implementations, we see that the Oslec team identifies, creates, and then applies the Subsystem Façade pattern. By using this pattern, the Pattern User is able to define a solution for a subsystem with a simple DSL and a domain model. In their efforts to simplify the solution space, the project team has been able to remove the need for a more detailed model, such as an analysis or design model. In addition, although UML provides many elements and diagrams, they are able to direct the team to stick to a subset of the available elements. With this simpler solution space the team is better able to focus on the task at hand and meet the needs of the business.

Related Patterns and Guidelines

Integrated Patterns and DSLs (Chapter 15), Pattern Creation Lifecycle (Chapter 12), Piecemeal Pattern Creation*

Single Pattern–Varied Use Cases

Context

Patterns from a number of sources are available within the organization. We currently use patterns to help us create artifacts and deliverables.

Problem

How do we maximize the investment made in a pattern? How do we maximize the impact of our patterns?

Forces

• We need to measure and track the pattern investment and impact.

• Tooling limitations and a lack of standards can limit pattern ROI and impact.

Solution

There are a variety of use cases for how we use patterns. We need to consider the many ways in which we can use a pattern to support our development efforts. To maximize the ROI and impact of a pattern, we want to use it as often and in as many ways as possible.

In the discussion of the End-to-End Pattern Use pattern, we mentioned using patterns across the disciplines within the SDLC. However, what does it mean to use the pattern within a discipline? Do we apply the pattern only to solve a known problem? That’s a common approach, but it should not be the only approach. Figure 10.4⁵ highlights a number of different pattern use cases, that is, the different ways in which we can leverage patterns.

Figure 10.4. Examples of some of the ways in which we can use patterns in our development efforts

In delivering a software solution, we can use patterns in many ways, including these:

• Apply. Starting with the most familiar approach, we can apply a known pattern to artifacts. The pattern helps us to solve a known problem and leads to a set of artifacts or deliverables that adhere to the pattern.

• Detect. Using definitions of known patterns, we can analyze a solution and discover occurrences of the patterns. We can use such information to help us with Pattern Density (Chapter 16).

• Refactor. We can refactor existing solutions using known pattern definitions as a guide and end point.

• Visualize. Using definitions of known patterns, we can analyze a solution and visualize instantiations of the patterns. Such an approach can help us to better understand the solution. We are able to rise above the details and view higher-order concepts.

• Harvest. We mine and codify new patterns from occurrences, using the existing collection of patterns to help in the discovery of potential uncharted patterns. In analyzing existing solutions, we can use known pattern definitions to highlight whitespace areas in the solution as well as possible compound patterns (Chapter 12).

• Create. We can create new patterns from scratch or create new compound patterns.

Example

Consider the case study of Oslec’s LogoAuction application. Once the application is completed, it still needs to be maintained and supported by Oslec. The development team based in Boston, led by John, has been asked to create a fix pack to address a number of defects for the currently released version. John and his team now need to understand and work with the entirety of the code base. They could spend time reviewing the design documents and the code base. However, this would be time-consuming. Instead, they can use known pattern definitions to analyze and visualize the code base. In this way they can learn what patterns were used and generate diagrams that show where and how the patterns were used. With such information they are able to quickly understand the code and start on the bug fixes.

Related Patterns and Guidelines

Design Solutions with Patterns, Refactor with Patterns, Use Pattern Definitions to Understand Existing Solutions, Use Patterns to Find Patterns (all discussed in Chapter 16)

Guidelines

The following guidelines provide advice regarding the domains that we should consider as we identify patterns to build, as well as how we support the management and then consumption of patterns.

Domain-Driven Patterns

Summary

Create, acquire, and use patterns focused on meeting the needs of a domain as well as providing a bridge between domains. Typically, we would look to patterns in the business domain, technology domain, and crossing between these domains.

Introduction

As we develop solutions, we are usually provided with a set of functional requirements, that is, requirements stated from the point of view of the business, not in terms of technology. How do we ensure the use of best practices when dealing with issues and challenges related to the business domain? How does this fit with the needs of the technology domain? How do the two come together? Considerations to keep in mind include these:

• Although nonfunctional requirements are important, if the solution does not meet the needs of the business, the project has failed.

• We need to effectively and efficiently use the technology at hand.

• A well-built solution is able to support the business needs today and provide the flexibility for future requirements.

• We need to involve business representatives in the building of the solution, while not overwhelming them with technical details.

Explanation

With a technical background and focus, we can get caught up in looking for best practices only within the technical domain. However, it is important (perhaps more important) to look for best practices that allow us to solve the problems of the business. To do so, we need to use the PBE Core Values, Patterns, Guidelines, and Practice to ensure that we are creating, acquiring, and using patterns that have a business focus.

We also need to ensure that we are looking at how business-focused patterns are related to and can be used in combination with technically focused patterns. A successful project requires us to think in terms of the technology used to deliver the solution; but what is the value if the solution does not meet the needs of the business? And conversely, what is the value of producing a solution that adheres to the needs of the business but cannot scale, is not stable or flexible?

Business patterns may have less reusability. At a minimum, they are usually limited to the organization as they are seen as a competitive differentiator. We may also find cases where patterns are applicable only to a specific project. We’ll need to keep this in mind as we consider investments in business patterns. Also, this limited reusability may limit the opportunities to acquire business-focused patterns from outside sources. The situation will have a different outcome depending on the role of your organization. In a business organization, the reuse opportunities are limited to the organization. However, for a systems integrator, a software vendor, or a trade organization, a business-specific pattern may apply to a group of businesses—across an industry or possibly across a set of industries. In such cases the dynamics of the decision and associated ROI calculations will change.

Technology patterns can address a range of problems such as providing support for deployment descriptors, caching approaches, or even object creation. Each of these is key to how the solution is built, but it is not necessarily derived from a business’s functional requirements.

In contrast to business patterns, technical patterns are easily transferable to other projects. Thus, the investment that we make in specifying and/or implementing a pattern can be recouped both on the current project as well as on other projects. In addition, external sources often provide an abundance of technology-focused patterns.

Usage of this guideline is shown in the case study as Oslec determines which patterns to build, acquire, and use in building the LogoAuction application. Some patterns, such as the DAO or the Subsystem Façade pattern, are too technical in nature to use in discussions with business stakeholders. In addition, these patterns, while useful in creating the solution, are not tied directly to a business requirement.

In contrast, patterns such as the Self-Service⁶ pattern, which focuses on user interaction and reducing time to market, are more business-relevant. Additional examples include the Role and Quantity patterns,⁷ as they map primarily to business concerns.

Related Patterns and Guidelines

Determine Business Impact (Chapter 11), Pattern Selection Driven by Requirements (Chapter 16)

Pattern Search

Summary

We know that we should be using patterns as we build our solutions. However, it is hard to find patterns to address a problem. Where and how do we find the patterns that we should be using? The short and simple answer is that we need to search for patterns.

Introduction

Finding patterns to address a problem can be difficult. Where and how do you find the patterns that you should be using? As we attempt to answer this question, consider the following:

• We need to ensure that the organization has governance in place to support the patterns available. Pattern Users will assume that any pattern returned from a search is valid for use.

• Different roles and situations dictate which sources we consult as we search for patterns.

• We can find ourselves overwhelmed as a large number of patterns are available. It would be difficult and time-consuming to browse all the existing patterns to find the one(s) addressing a particular concern.

Explanation

Consider the effort saved when we can select from known problem/solution pairs rather than experimenting with numerous different solutions. However, this approach assumes that we have a catalog of patterns and are able to find the patterns that we need. Experience has shown that we are able to produce patterns (we only have to look at the impressive number of books about patterns), but so far we’re not that good at consuming them. This is partly because of some cultural challenges, like the “not invented here” syndrome. But perhaps the primary difficulty is finding our way through the thousands of existing patterns. How can we easily identify the right patterns to solve our problems in our context?

A first step is to identify a collection of patterns and make them easily accessible. We can then build on this foundation by providing a way to guide project members through the pattern selection process. This could be achieved by using metadata to

• Describe the pattern, including details about the problem, solution, and context

• Link the pattern to all of the elements that constitute the pattern, such as the specification, implementation, DSL, model template, and documentation

• Link the pattern to related patterns

• Connect the pattern to typical requirements that the pattern can address

Team members should be able to search and then retrieve a set of patterns corresponding to a specific, defined context, simplifying decision making and pattern acquisition. Using visualization techniques to display the information can further facilitate this search and selection process.⁸

For patterns that have been published externally—from vendors and the community—we can look to outside sources. Searching the web is one option; however, a general search engine usually leads to general results. You need to consult sources that are specific to patterns; some to consider include

• Hillside.net pattern collection⁹

• Handbook of Software Architecture website and its patterns catalog¹⁰

• The Pattern Almanac¹¹

• Sites dedicated to the domain on which we are focused (Java, .NET, UI, etc.) and the patterns that are discussed there

• Sites that are dedicated to the frameworks that we are leveraging

• Vendor websites

We can also simplify the search for external sources by taking time early in the project to identify a subset of external sources to leverage on the project. Based on experience and an initial understanding of project requirements, we can compile a list of sources that may prove useful. This list then serves as the starting point for external pattern searches. The list may change over the project lifetime. In addition, we can go beyond the list as needed. The goal is to produce a best-effort list that serves as a starting point for external searches.

When it comes to finding patterns that our own organization has built, there are two main sources to consult. The first is the organization’s development process. The process should detail the tasks, roles, and work products needed to successfully complete the project. In detailing the tasks, the process should provide guidance and pointers to relevant patterns. The second source to consult is an asset repository. Additional advice for working with a repository is provided in the Use an Asset Repository guideline (Chapter 16).

Technical approaches to driving pattern consumption are successful only if we also address cultural issues. The entire team needs to be made aware of the need to search for patterns and be enabled and encouraged to do so.

Chapter 4 of the case study shows Oslec following Pattern Search as they create a list of external pattern sources to be consulted for building the LogoAuction application. In addition, Chapter 7 shows one of the development team members searching for the Subsystem Façade pattern implementation.

Related Patterns and Guidelines

Pattern Packaging (Chapter 14), Use an Asset Repository (Chapter 16)

Summary

The patterns and guidelines in this chapter focus on how we can identify, produce, consume, and manage patterns in building a foundation for our PBE initiative. We’ve touched upon the scope of our PBE efforts, looking at the relationship to the SDLC as well as how patterns come into play for business and technology domains. We can connect these ideas about scope with a piecemeal approach to building our patterns. It’s one thing to have the right ideas and requirements for a pattern; it’s another to ensure that the right aspects of the pattern are delivered. In addition, we looked at how we can improve the productivity of the team by creating a simple solution space, one that better leverages automation and abstraction. And all of this would be for naught if we ignored the topic of finding patterns. Pattern consumption is a topic that is frequently overlooked, and that ends up hurting our PBE efforts.