In order to ensure that the plug-ins within the Practice Framework library fit together nicely and to maximize reuse across elements, specific plug-in types are defined. Such a consistent approach for how plug-ins are structured allows true plug-and-play between content authored by different groups and ensures that remotely authored content integrates seamlessly into the overall library. To support this, individual plug-in types can be defined to define each the important separate areas of concern. Plug-ins can then follow a consistent packaging structure for the actual content based on the plug-in's type.

Figure 1 summarizes the types of plug-ins that should be defined when defining a practice framework library, as well as the allowable dependencies between these plug-in types.

Figure 1. Practice Framework Library Plug-In Types and their Relationships

The plug-ins shown in Figure 1 and  described below are "logical" plug-ins. As described in the "Plug-in parts" section below, each logical plug-in may be represented by a number of individual "plug-in parts". In other works, for every logical plug-in, there may be more than one physical plug-in.

Core plug-ins contain the elements intended to be shared between other plug-ins in the framework.  They provide the foundation of the framework and enable reuse across the elements in the framework (e.g., Practices and processes). The core elements serve used as a foundation for defining how the various different types of content will fit together. Specifically, include elements that serve as the interface between practices (Work Product Slots), as well as key reusable elements such as work products or guidance that are intended to be used in a variety of different practices (i.e., shared across practice plug-ins).

Practice plug-ins contain the practice elements. There is a Practice plug-in per practice. Practice plug-ins only depend on Core plug-ins (thus enabling them to be plugged and played).
Exception: Some practices are defined by reusing content from other practices (e.g., booster practices). For example, a practice may be defined to pre-configure a set of practices into one and then provide some value-added extensions to the whole.

Process plug-ins contain the elements that define cross-practice processes that are intended to be shared across configurations (practice-specific processes are contained in Practice plug-ins and configuration-specific processes are contained in Publish plug-ins). Cross-practice processes are assembled from elements (tasks and/or processes) contained in Practice plug-ins and possibly other Process plug-ins. Process plug-ins include the processes themselves, as well as any process-specific extensions to existing elements that are needed to make the various parts of the process work and fit together. There can by any number of process plug-ins; however, an attempt should be made to group similar processes that always appear together in the same process plug-in. For example, you may define a Process plug-in for a particular process family, for a set of processes that share a common lifecycle approach/style and/or for all of the processes included in a specific method asset.Process plug-ins can depend on Core plug-ins (for shared elements), Practice plug-ins (for practice-specific elements to included in the process) and Process plug-ins (for shared processes).

Publish plug-ins contain method elements that are unique to a specific configuration that is being published. For example, a Publish plug-in might contain some configuration-specific navigation views, roadmaps, a welcome page, an so on. A Publish plug-in may even include process, if that process is configuration-specific.

In summary, the practice framework plug-in types represent how the key concepts are implemented physically (i.e., how the practice framework library is organized around practices):

• The practices themselves (Practice plug-ins)
• The elements that are shared across practices (Core plug-ins)
• The processes that are assembled from the practices and that are shared across configurations (Process plug-ins)
• The elements that support a specific Publishable configuration (Publish plug-ins). For more information on Publishable configurations, see Concept: Practice Library Configuration Types.

The separation of shared elements (Core plug-ins), practice-specific elements (Practice plug-ins) and cross-practice elements (Process and Publish plug-ins) maximizes reuse between the elements in the framework (practices share core elements and cross-practice processes share practice and core elements)

Plug-in parts

In order to improve the configurability and navigability of the practice framework library (as well as to implement Delayed Assignment), the concept of plug-in parts was introduced.  For more information on this, see Concept: Practice Library Plug-In Parts.

Core plug-in subtypes

There are a number of different types of elements that are intended to be shared across the framework (i.e., are contained in core plug-ins). However, several of these items need to be reused independently (i.e., I want to share tool definitions, but I want to define my own domains). Thus, in addition to the above primary plug-in types, the Unified Method Framework (UMF) also defines a number of Core plug-in subtypes.

Slot plug-ins contain the Work Product Slot definitions, as well as any associated guidance.

Common plug-ins contain common reusable elements such as work products or guidance that are intended to be shared across plug-ins. It is possible for different practices to utilize the same underlying work products and basic guidance even though they have alternate approaches with different techniques to produce the same work products. Instead of creating unnecessary dependencies between practices that are peers, shared elements are defined as common. Common elements, by their very nature, as defined in a practice-independent way so that multiple practices can share the common content. They are written at a generic level with the expectation that they will be further specialized as needed for a particular practice and/or process. Work products should be with the content that supports them. Only truly common work product definitions should be in common. A litmus test for deciding whether a method element should be placed in a common plug-in or not is whether the content is applicable across all contexts for which it applies.

The following are some examples of the use of common elements:

• A light weight architecture practice and a heavy weight architecture practice can share a common definition of an architecture work product, but not share tasks (the tasks are defined in the practice).
• Two different types of development (e.g., Greenfield vs. reverse engineering approaches) produce the same work products, but they go through different state changes, have different tasks, etc.

Role Definition plug-ins contain the roles (and optionally role set definitions) that are intended to be shared across practices. Since practice frameworks usually implements a Delayed Assignment approach for roles, the Role Definition plug-ins do not contain the assignment of roles to work products or tasks.

Category Definition plug-ins contain category definitions that are intended to be shared across practices. In the UMF, this includes discipline, domain, work product kind and possibly role set definitions (if they are not in the Role Definition plug-in). Since practice frameworks usually implement a Delayed Assignment approach for standard categories, the Category Definition plug-ins do not contain the assignment of elements to these categories. Tools are defined in separate Tool Definition plug-ins, as these were envisioned to be separately reusable from the other standard categories.

Tool Definition plug-ins contain tool and tool mentor definitions that are intended to be shared across practices. The assignment of tools to tool mentors not generally delayed assigned, so the Tool Definition plug-ins contain the assignment of the included tool mentors to the tools. Practice-specific tool mentors and assignment of the practice-specific tool mentors to the tools are defined in Practice plug-ins.

Navigation View Definition plug-ins contain navigation view definitions that are intended to be shared across plug-ins (e.g., generic navigation views and navigation view building blocks).

Release Copyright plug-ins contain the release copyrights that should be used for the plug-ins in the framework. There may be any number of Release Copyright plug-ins. Every plug-in should have the appropriate copyright plug-in associated to it.