Chapter 18. Economic Considerations of PBE
So far we have been looking at PBE from a technical perspective, which is an important perspective for a technical book. But writing software is not only about technical information and discussions. The cliché “Build a better mousetrap and the world will beat a path to your door” is not entirely true. Patterns and PBE provide us with a great mousetrap, but we need to look at and understand the economic considerations of these approaches if we aim to be truly successful.
Key Economic Aspects of PBE
As we start this chapter, it’s fair to ask, “Why should we look at the economics of patterns? Patterns are only a technical concern.” As we work through this chapter, we will see that while patterns are part of the technical domain, they have an economic impact on projects and the companies that use them.
We begin examining the economic considerations of PBE with a definition of economics: “Economics is the study of the use of scarce resources which have alternative uses.”1 This definition is a nice fit as we look at the enterprise. We have limited time, skills, resources, and money, and often there are many alternatives available to us. We need to be able to understand the options available and the impact of our choices as we decide which alternatives to pursue. Knowing how PBE can impact the economics of a project, we will be better armed to get the most from pattern adoption and application.
The economic considerations that we discuss are organized according to the following PBE aspects:
• Pattern sources. Where should the patterns that we use come from?
• PBE adoption. What needs to be considered when we adopt a PBE approach?
• Pattern implementations. What needs to be considered when creating pattern implementations?
• PBE projects. How does PBE impact our projects?
Each of these aspects will be discussed further in the following sections.
Pattern Sources
Many developers consider the Design Patterns2 book to be the source of patterns available to use. The book provides a set of patterns that are well known, proven, and easy to follow. However, this set of patterns is just the tip of the iceberg. If we search the web or online booksellers, we find numerous books and articles describing the many patterns that are available. There are thousands of patterns that we can use within our projects. Having a large number of patterns available from a variety of sources is a good thing.
However, we should not be content knowing that there are a lot of patterns out there that we might be able to use. In order to fully benefit from PBE, both from a deliverable and an economic point of view, we need to focus on the sources of the patterns and establish that we are leveraging the correct sources and the correct patterns. To simplify our thinking about the sources of patterns, we can group them into three main types, as shown in Figure 18.1:
• Vendor. When building our own solutions, we typically use runtimes, languages, and code libraries provided by a set of vendors. Each vendor leverages experiences in building and supporting its products. Typically, a vendor makes a set of patterns available that codifies these experiences. As customers, we benefit from a vendor’s expertise and experience with a wide-ranging set of projects. However, the patterns produced are still quite generic, as the vendor works to support a wide variety of customers. The goal of the vendor is to provide best practices to as wide an audience as possible.
• Community. The community, whether an open-source community, a user group, or individuals, is another external source of patterns. The community comes together based on a shared interest and discusses successes, failures, and challenges; over time a set of patterns and best practices emerges. Usually the patterns that emerge from such a community, while useful, tend to be more general. The community realizes that there is a benefit in coming together to identify and codify best practices. However, there needs to be a level of generality in the patterns; otherwise they would not be applicable across the community. In addition, the community can include people who are from rival organizations. They benefit from sharing some knowledge, but they also have best practices that provide a competitive advantage and are kept private.
• Our own organization. Although we are using tools from vendors and the community, some aspects of the project and approach are unique to our organization. Over time, the organization (whether it is our team, our division, or the whole company) develops its own best practices and patterns. In many cases these represent key intellectual assets that provide the organization with a competitive advantage. The patterns developed by an organization can vary in terms of whether they are generic or very specific. If they are general, it can be beneficial to find ways to publish and share the results of the work; the community can then work with you to increase the quality and usefulness of the patterns. Patterns that are specific to the organization and provide a competitive advantage usually are not disclosed to outside parties.
Figure 18.1. The three sources of patterns
Selecting the right patterns from the right sources is one of the keys to increasing a project’s ROI.
Pattern Selection Criteria
Regardless of the source of patterns, we cannot look at just the total quantity. A focus solely on quantity can lead us down a path where we believe that a large selection of patterns means that they’ve all been identified and we just need to pick the ones for our project. We need the right patterns for the work we are doing. So the question we need to ask is, how do we find the right pattern(s)? There are a number of attributes and characteristics that we should consider as we begin to select our patterns. As with other architectural discussions and decisions, there isn’t a single right answer. We need to review the different considerations and determine which are most important. We can then use the selected criteria to help us decide on the patterns to select. Often we find that this is a balancing act—the importance of one criterion will impact the selection of another. Some of the pattern selection criteria to consider include these:
• Maturity. Is the pattern stable and mature enough that we can predict productivity and quality benefits? Have related antipatterns been identified?
• Support. Is there any support available to help deal with issues that could arise while using the pattern, especially with pattern implementations, or must we rely only on our own resources for assistance?
• Education. Are there educational resources available to assist in learning how to properly identify opportunities for using the pattern? Do the materials explain how to apply the pattern properly?
• Cardinality. Is the pattern part of a set? Or does it exist unto itself?
• Relationships. Have relationships with other patterns been identified and documented?
• Category. At what level is the pattern applicable? For example, is it an architectural pattern? Design pattern? Idiom?
• Strategic impact. How does the use of the pattern align with business goals? How important is the pattern to overall success?
• Vendor dependence. Is the pattern dependent on a specific vendor or is it vendor-independent?
• Fit. How closely does the pattern fit our context? If the pattern does not have 100% alignment, how much effort will it take to improve the fit? What is an acceptable level of fit?
• Cost. What is the cost to obtain and use the pattern? In addition to any acquisition costs, we should also assign a cost to the other criteria.
Table 18.1 examines the three main pattern sources, using some of the criteria just described, and lists some of the advantages and disadvantages of each. The goal is to help us define the mix of patterns from the different sources. Successful projects focus on finding the right mix; success is unlikely if we focus on only a single source.
Table 18.1. Pattern Sources Comparison
Pattern Source Recommendation
As shown in Table 18.1, each source has advantages and disadvantages. So as is the case with many other decisions, the source we select for our patterns will depend on the circumstances surrounding the decision. In general, the best advice regarding the correct source is “It depends.” The selection criteria provided in previous sections should help us evaluate both the pattern and its source.
Depending on the project and even the stage of the project in the lifecycle, we will choose patterns from different sources. For example, architectural patterns are often abstract enough that we can receive positive benefits by taking them from the community. In contrast, when we get into the design of components, we would probably mix vendor patterns with our own patterns, or refine vendor patterns to adapt them to our specific context. A little more specific than “It depends” is a view that we should strike a balance among the three sources, leveraging community and vendor patterns as much as we can and developing patterns where it is necessary. As shown in Figure 18.2, successful PBE projects find that their patterns overlap the three sources; the degree of overlapping, as we might expect, “depends.”
Figure 18.2. Balancing sources in pattern selection
PBE Adoption
When looking to adopt a PBE approach, we also need to give some thought to the resources required to adopt and implement it. As shown in Figure 18.3, to successfully adopt PBE we need to consider issues such as tooling, methodology enhancements, training, cultural changes, pattern acquisition costs, and time and effort associated with pattern development and support.
Figure 18.3. Elements impacting the economics of PBE adoption
Tooling3
With respect to tooling, we need to consider both the production and the consumption of patterns. For consumption, we want to make it as simple as possible for those within our teams to be able to find and leverage the patterns that are available.4 Helping to fill this need is a category of tools known as asset repositories. If we have only a few patterns, we can likely skip a productized repository and use simple tools such as a web server or a wiki. We do need to ensure that the simple tools allow us to share information about the pattern. However, if there is a large number of patterns, as well as other assets to use, we will need more sophisticated tooling.
When looking for a repository, some features to consider include the following:
• Asset search and discovery. Pattern users should be able to quickly and accurately find patterns. Ideally, ease of searching supports us in relating patterns to one another as well as to requirements.
• Feedback and usage information. We should be able to see feedback provided by Pattern Users as well as details on pattern usage. We should also be able to track who has downloaded which pattern.
• Governance support. The repository should assist us in enforcing our pattern governance policies. The repository should not be a free-for-all or a dumping ground. We need to be able to manage how patterns get put into the repository and how they are made available for use.
On the production side, we need to find and leverage tools that support capturing pattern specifications and, where appropriate, building pattern implementations. In capturing a pattern specification, our tool needs are quite simple; we can use an editor or word processor along with a standard template to ensure that we capture the specification consistently.
Things become more interesting when we address creating pattern implementations. At this point we require development tooling, preferably tooling that provides a platform for working with models and using those models to drive automation via patterns. There are multiple tools available in this space, some from commercial vendors as well as some open-source alternatives. Here are some tooling capabilities to consider:
• Exemplar support. Does the tooling under evaluation help with the analysis of exemplars? Does it help to automate the work as it progresses from an exemplar to a pattern?
• Packaging. Does the tooling provide support for packaging the patterns that we create?
• Pattern implementation types. What types of pattern implementations does the tooling support? Model-to-model? Model-to-text? UML patterns?
• Compound patterns. Does the tooling support the creation of compound patterns?
And on the pattern consumption side, we need to think about the related runtime tooling for our pattern implementations. Some capabilities of the runtime tooling to consider include these:
• Input model. What mechanisms does the platform provide for creating input models for the pattern implementation?
• Pattern documentation and guidance. How does the tooling support Pattern Users and guide them to the correct application of the pattern? Is the pattern documentation easily accessible? Are there additional capabilities provided to help guide the Pattern Users?
• Install, update, uninstall. How simple is it for the Pattern User to install, update, and uninstall the pattern?
• Indicating pattern use. As the Pattern User creates solutions with patterns, how does the platform record and indicate the use of those patterns?
• Exemplar creation. Can the tooling be used to help create exemplars?
• Patterns in combination. When Pattern Users create solutions, they will use multiple patterns in combination. Does the platform support the use of multiple patterns within a single solution? Can the patterns share parameters? Can the output of one pattern serve as the input for another pattern?
Methodology Enhancements
As discussed in Chapter 8 and Appendix F, PBE is a software development practice, not a process unto itself. As such, the PBE Practice is combined with other practices to form a complete process solution. As we look to adopt PBE, we need to keep in mind that we will need to incorporate the PBE Practice into our existing development process. This is a straightforward cost that we incur as we enhance our development process.
An aspect that is new when incorporating PBE is that we need to continuously monitor and adjust our process as we build our pattern collection. Typically a pattern will automate one or more steps related to the process, and in doing so it might impact roles, workflows, or artifacts. Based on the pattern and its impact, we will then need to update and republish the process.
Training
Regarding the costs associated with training, there are a number of perspectives to keep in mind. The following are some of the key skills that we need to develop:
• Identify patterns. We expect that the entire team will be able to identify patterns related to their domains of expertise. Everyone on the team should be contributing to the effort and supporting this creative and valuable aspect of the PBE effort.
• Write pattern specifications. A subset of the team will need to develop specialized skills that support the creation of pattern specifications. They will also need to be able to apply these skills in reviewing pattern specifications that others create.
• Create pattern implementations. A small subset of the team will need to develop skills related to creating pattern implementations for the selected tooling platform. This includes learning how to create one or more of model-to-model pattern implementations, model-to-text patterns implementations, and UML pattern implementations.
• Manage pattern assets. A small subset of the team will need to learn how to set up governance policies for the pattern assets and enforce the policies via practices and automation.
• Apply patterns. The team should be taught how to use the development tool to apply pattern specifications and pattern implementations.
Cultural Changes
Chapter 19 discusses the challenges and misconceptions that need to be addressed when looking to adopt PBE. A number of these issues are related to the cultural challenges associated with PBE. Thus, we need to influence and change the culture of the adopting organization so that we
• Encourage creative thinking to solve recurring problems. Channel creativity and problem solving into solving the right set of problems.
• Continuously look for new patterns. Recognize recurring and proven solutions and ensure that they are codified as patterns.
• Seek opportunities to use patterns. Reuse proven solutions instead of reinventing the wheel.
Pattern Acquisition Costs
There are usually costs associated with acquiring a pattern from an external source such as a vendor. The obvious cost is the purchase price of the pattern. However, there may be additional costs in terms of professional services support, maintenance contracts, training, and associated tooling.
Pattern Support Costs
Regardless of the sources of our patterns, there will be support costs. Obviously, each of the patterns will require documentation and support. However, there are relationships between patterns and we use them in combination. We need to recognize that there can be costs associated with supporting patterns used in combination.
Pattern Development Costs
In cases where we determine that it is in our best interests to build a pattern ourselves, we need to recognize that there will be costs. If our current tooling does not support PBE, we need to look at the costs associated with acquiring any necessary tooling. The tooling may be used for pattern development, testing, or deployment. We also need to recognize the costs associated with designing, developing, testing, deploying, managing, and maintaining the pattern.
Pattern Implementations
When should we create an implementation? The answer to this question is not a set time in the project lifecycle. Rather, we need criteria to help us judge when we should build a pattern implementation. Recall from the definition of economics that we have limited resources and alternatives available in regard to how we use those resources.
Let’s start by reviewing a few of the PBE Core Values:
• Always identify and build new patterns.
• Patterns can be built and used within the same project.
• Make your patterns live.
If we accept and work according to these values, will we find ourselves building every pattern that we discover? Will we spend all our time enhancing and embellishing the existing patterns? Of course not; our goal is to ship software that meets our business needs, not to specialize in pattern creation. To make the right decisions, we need criteria that we can use in applying these core values. Some relevant criteria include these:
• Expected cost of the pattern. What is the cost for the initial development? What is the cost for validating that the pattern is indeed a best practice? What is the cost for consuming the pattern? How much will it cost to maintain and support the pattern?
• Expected benefit from using the pattern. How many times will it be used? How much effort will be saved each time the pattern is used? How long will it take to successfully learn to use the pattern? Is there an expectation that the pattern can be reused in other instances? Other projects? If so, is it quantifiable?
• Project-specific factors. What other work will not get done if we develop this pattern? What impact will this have on our overall project deadlines? How will it impact the intermediate milestone deliverables?
We can use these questions (and the associated answers) as a guide in determining when it makes sense to develop a pattern implementation and when it makes sense to defer. As with most other development discussions, there is no simple answer, and it will depend on the specifics of the situation.
PBE Projects
When looking at the economics of software projects and the impact of patterns on those projects, we need to consider the type of organization that is building the patterns. For example, a systems integrator (SI) will have some considerations and factors that differ from those of an internal IT organization. Then, depending on the organization, a number of different situations and scenarios need to be analyzed, including the status of the project, the type of project, and other factors.
Systems Integrators
SIs face a number of challenges when it comes to their projects and PBE. However, they also have a chance to reap the greatest rewards from adopting PBE.
In regard to challenges, there are two main perspectives that we need to examine. The first pertains to how the organization bills for its work. Traditionally, an SI adopts one of two models for projects, either to bill per hour or to bill on a fixed-price basis for project completion. In the case where the organization is billing per hour, there is a great deal of pressure to ensure that the number of billable hours is maintained. Adopting PBE and seeing a significant reduction in time to completion is in direct conflict with this pressure. In the case of per-project, fixed-rate compensation, there is a strong incentive for the SI to adopt a PBE approach.
Other considerations besides billing rates come into play when considering whether to adopt PBE. SIs, like other organizations, are also concerned with quality, skill shortages, and governance. A decision on when, where, and how to adopt PBE needs to take each of these aspects into account.
Another perspective that needs to be considered when looking at SIs and PBE surfaces in situations where an SI builds a pattern based on consulting efforts. This makes a great deal of sense, as a pattern is supposed to be based on experience. However, an SI needs to consider how it manages its customer relationships and the contracts it uses for its engagements. In these discussions and negotiations, consideration must be given to who will be the owner of intellectual capital (such as patterns) that is developed during the engagement. In addition, for the organization that brings in an SI, how will the access to proprietary company patterns be handled?
IT Organization
Shifting our focus to an IT organization, the issues are much simpler than those for an SI. The biggest consideration (aside from those discussed earlier in this chapter) is that of project estimation.
As we start out in adopting PBE and building out our catalog of patterns, there can be great uncertainty about the impact patterns will have on our project plans. However, as our collection and experience with patterns mature, we can act with much higher confidence about which patterns to use, the likelihood of new patterns being discovered, and the impact any new patterns will have on project timelines.
When getting started with PBE, we should ensure that an iterative and incremental approach is adopted. Within each iteration we need to consider the patterns that may be available and what their impact will be for the current iteration. In addition, we need to be conservative in the way that we incorporate this analysis into our estimating.
As we estimate the project, we need to look broadly in terms of the activities and roles that are impacted. We may find that new tasks are introduced while other tasks can be minimized or eliminated. For example, we may have an opportunity to add new tasks such as further requirements validation due to the use of DSLs and patterns related to the business domain. Or we may see trade-offs when looking at the underlying code quality. For example, we need to ensure exemplar quality while recognizing that this can reduce efforts needed in testing the resulting solution.
Independent Software Vendor
An independent software vendor (ISV) needs to calculate the value of candidate patterns. What is the value to the organization? Customers? Partners? In performing these calculations, the ISV will examine the impact patterns could have on professional services, customer adoption rates, product pull-through, customer satisfaction, and competitive differentiation. The answers to these questions will help an ISV determine whether to create the pattern, how much to charge, and when to make the pattern available.
Summary
Leveraging and succeeding with PBE is not just a technical concern; economic considerations also come into play. We have limited resources and many choices as to how we can use those resources. We need to make sure that we are aware of the implications of PBE activities and how they can impact our projects and organizations. We need to consider pattern sources, PBE adoption, pattern implementations, and PBE projects. Each of these presents factors that can impact our success. We need to take a disciplined and systematic approach to leveraging patterns, bearing these considerations in mind as we quantify the impact of our choices and the steps we take.