Any organization that develops software creates multiple software applications that have some characteristics in common. Some software has the same application architecture, some run on the same execution platforms, and others support the same segment of the business. Whatever the commonalities are amongst the software applications, it is important that these commonalities be managed properly so that the organization can realize the highest economy of scale. The software product line practice was designed to manage software products, and their commonalities were designed to maximize the benefits to the organization. These commonalities among software systems are embodied in artifacts called core assets. Core assets are reusable and can be any of the following:
Each core asset shares an architecture that all products in the product line will have in common. In addition, a process is attached to each core asset and prescribes the optimal method of using the asset to build a product in the product line. Test cases, design documentation, and other documentation are also attached to the core asset to guide its use in products. Why is this important? Every organization builds products that have aspects in common. Design patterns have been a method of describing design similarities in software artifacts for about a decade. Design patterns are an excellent means of documenting designs that work across multiple applications with the same or similar characteristics. Product lines take this concept further. A core asset documents not only a software design that works, but it also includes the software that implements that design. The asset is not just sample code that explains a design idea; it is working code, components, and systems that can be used directly in other applications. One of the great assets of design patterns is that they are applicable in a wide range of applications. Core assets are not as widely applicable, but they can provide enormous benefit to applications that have the desired characteristics. A product line also provides a means of characterizing products that have similar characteristics. They can take advantage of core assets that were built to provide benefit in the context of a particular product line. What are these benefits? When an organization decides to fund a new project to deliver some benefit to the business, what is the state of the project at the moment of inception? Is there a technical infrastructure available to begin development? Can any existing software architectures, components, frameworks, or libraries be leveraged? In a typical organization, when a new project is started, one of the following is done to acquire these assets:
Not only is it more expensive to acquire or build new assets for every new project, but it also produces yet another product to maintain that has little or nothing in common with the other products in the organization. An organization that continues this process over and over will find it extremely expensive to maintain all these applications. A product line treats these core assets as separate from the products into which they are assembled. The product line core assets are acquired, created, and managed separately so that every product that is built in the product line can do the following:
If managed correctly, the bottom line is that an organization that is oriented around a product line method of creating and maintaining software can dramatically reduce expense and dramatically decrease the time to market for new applications. The key phrase in the previous sentence, however, is "managed correctly." For example, creating a product line with a single product in it has a negative benefit. There is also a negative benefit if the core assets in the product line don't meet the needs of new applications. This chapter will give you some advice on implementing product lines that make sense and provide benefit to your organization. |