In order to improve the configurability and navigability of a Practice Framework library, the concept of plug-in parts was introduced. “Plug-in parts” basically says that each of the Practice Library Plug-In Types is actually implemented as more than one physical plug-in. Specifically, any plug-in that is intended to be extended, or has method elements that are delayed assigned (e.g., contains work products and/or tasks) can be considered a “logical” plug-in that has one or more “physical” plug-in "parts":

Figure 1 shows the plug-in parts and their relationships. In this diagam, [Plug-In X], [Plug-In Y] and [Plug-In Z] represent logical plug-ins.

Figure 1. Plug-In Parts and their Relationships

The relationships shown in Figure 1 can be described as follows: 

Base plug-ins contain the base definitions of the method elements of the logical plug-in. 

• A logical plug-in only has one Base plug-in (this makes it easy to see where the base element definitions "live"). 
• Base plug-ins may depend on other Base plug-ins (dependencies between Base plug-ins represent dependencies between the logical plug-ins).

Extend plug-ins contain elements that extend (i.e., customize) elements in the Base plug-in. 

• A logical plug-in can have zero or more Extend plug-ins (a plug-in does not have to be customized and it may be customized in different ways). 
• Extend plug-ins depend on the Base plug-in that contain the elements being extended. 
• Since there may be more than one Extend plug-in, the plug-in names should be qualified.

Assign plug-ins contain the assignment of method elements in a Base or an Extend plug-in to those things for which delayed assignment is supported (it does NOT contain all assignments). For more information on delayed assignment, see Concept: Delayed Assignment. 

• A logical plug-in can have zero or more Assign plug-ins. If a Base (or an Extend) plug-in does not contain any elements that need to be delayed assigned, then there is not an Assign plug-in.
• Assignment extensions. If the logical plug-in is extended (there's an Extend plug-in) and those extensions include things that are delayed assigned, then there needs to be an Assign plug-in for those extensions (and the Assign plug-in is dependent on the Extend plug-in).
• Alternate assignments.  If there are alternate assignment approaches that apply to Base or Extend plug-in elements, then there will be separate Assign plug-ins for the alternate assignment schemes.
  Note: In actuality, only one assignment scheme should be included in a method library (or workspace) at a time and those that are there, should always be selected (that's why these assignments are "under" the logical plug-in).
• Assign plug-ins depend on the Base or Extend plug-ins that contain the definitions of the elements being assigned. For example, an Assign plug-in may depend on the Base plug-in that contains a task, the Category Definition Base plug-in that contains the discipline the task is being assigned to, and the Role Definition Base plug-in that contains the definition of the role that is being assigned to the task. 
• Since there may be more than one Assign plug-in, the plug-in names should be qualified. Specifically, if the assignments are for an extension, the same name qualifier should be used as was used on the Extend plug-in, so it is easy to see why the Assign plug-in is extended. If the assignments are for a particular assignment scheme, use a qualifier that indicates that scheme (e.g., maybe a specific context and/or Practice Configuration).

The benefits of the plug-in parts concept are:

• The separation of concerns between the: (1) base method element definitions, (2) extensions to those base definitions, and (3) delayed assignment of the elements
• Alternative assignment approaches are easy to define.  Assign plug-ins are easily replaced with alternate assignment plug-ins. That way authors can define their own role assignments to implement specific governance processes and/or may define their own categorization schemes.
• Logical plug-in extensions and assignments appear together in the library and are easy to select when defining a configuration. The definition of these plug-in parts and the implementation of an appropriate naming convention means that all parts of a plug-in are listed together in the library and can be selected together when defining a configuration.