A Framework for Software Product Line Practice, Version 5.0

Structuring the Organization

This practice area is about how the organization forms groups to carry out the various responsibilities inherent in a software development effort. All organizations have a structure, even if it's only an implicit one, which defines the roles and responsibilities appropriate to the organization's primary activities. Particular organizational structures are chosen to accommodate enterprise goals and directives, the culture, the nature of business, and available talent. The organizational structure reflects the division of roles, responsibilities, and authority.

In a traditional organization (one that isn't oriented to product lines), individual product teams tend to be fully responsible for technical decisions that affect their products. Even in a matrixed organization, once engineers join a project from their specialty groups, the projects run independently. Specialization might require each product to have its own development group, with no sharing of personnel. The role of the organization's management in this case is to gather and allocate resources and provide high-level oversight–all with the end goal of supporting product teams.

Aspects Peculiar to Product Lines

A product line approach entails new roles and responsibilities related to the creation of core assets and of products from those assets. This practice area deals with placing those roles into the appropriate organizational units to most effectively support the product line approach.

In a product line context, the dual development of core assets and products dictates an organizational structure that is not product-centric. Beyond that, management must be concerned with identifying the organizational charter and boundaries, identifying functional groupings, allocating and assigning resources, monitoring organizational effectiveness, improving organizational operations, establishing interorganizational relationships, and managing organizational transitions.

Product line organizational structure goes hand in hand with product line operations (see the "Operations" practice area), because it is the embodiment of the roles, actors, and responsibilities defined there. Structuring the organization is like assembling a symphony orchestra–determining how many of each type of instrument will be in each section, selecting the musicians, and assigning people to the appropriate chair in their sections. "Operations" is the practice area that provides the music everyone will play together and guides them through performances. Both practice areas, obviously, are necessary. They result from an overall vision of how the product line will operate on a day-to-day basis. The job of organizational structure is to make sure that each responsibility and function of the product line operations has a work unit in which to reside.

An organizational structure should be chosen to assign at least the following tasks to the appropriate organizational unit or units:

Determine the production strategy (see "Core Asset Development").
Determine the product line scope and associated business case and refresh both in a routine and ongoing way.
Produce and maintain the architecture for the product line.
Determine the requirements for the product line and product line members.
Design, produce, and maintain the product line's core assets and associated production plan.
Assess the core assets for their utility and guide their evolution.
Produce products.
Determine the processes to be followed and measure or ensure compliance with them.
Maintain the production environment in which products are produced.
Forecast new trends, technologies, and other developments that might affect the future of the product line.

Application to Core Asset Development

A first-order choice that must be made when choosing an organizational structure is where to assign the people who develop, maintain, and evolve the product line's core assets. Typically, organizations take one of two approaches: (1) they form a separate unit for the developers and maintainers of core assets or (2) they house that effort in the same unit or units that build products [Bass 1997a, Bass 1998a].

Both approaches have their advocates. On the one hand, having a dedicated core asset development group makes the core asset developers one level removed from the pressure of project deadlines, making it more likely for them to produce assets that are generic and not too biased toward the individual product that happens to be under development at the time. Their loyalty is to the product line, not to any one product. On the other hand, having product engineers produce the core assets ensures that the core assets will be truly useful for products and ensures that people who build the core assets are not too far removed from the day-to-day realities of product production. In either case, there must be someone with a cross-product perspective and authority who can identify useful assets for the core asset base and encourage (if not direct) the appropriate product group to produce each core asset for use by other products.

When choosing whether to establish a separate core asset group, consider these factors:

the size of the effort and the number of products: In a product line with many product groups and/or a large number of developers, distributing the core asset task results in an untenably high number of communication channels: every product group will have to talk to every other one. In this circumstance, it helps to have a dedicated core asset group.
new development or mostly legacy-based development: In product line efforts where the core assets are built based on mining legacy systems, it makes more sense to have product developers (who will probably be more familiar with the legacy systems) be responsible for mining core assets that will be generic and fit the scope of the product line.
the funding model: Funding a core asset development group can be problematic. Who pays for it? When working from legacy systems or when the product line approach matures, it may be hard to justify a separate asset development group when the product development groups are adding product-specific features to the core assets.
the high or low effort of tailoring core assets: How much development has to be done to get from the core assets to the products? If the amount of tailoring and new development is small, it may make sense to have most people work in a dedicated fashion on the core assets. If producing products requires substantial tailoring and new development, the asset development job is small by comparison, and integrated groups may be the answer.
the volatility of core assets: Having core assets that evolve frequently and substantially argues for having a dedicated group to manage them, rather than overwhelming the product builders.
parallel or sequential product development: If products are built sequentially, it makes sense to have an integrated team working on them. When several product development projects are performed in parallel, there is a stronger need for a separate core asset group to avoid the multiple redevelopment of the same functionality.

An evolutionary organizational structure resolves the choice essentially by having it both ways. The approach starts the product line effort without a core asset group so that the engineers can assume the full responsibility for turning out a real product under the product line paradigm. However, as soon as there are parallel developments in progress, product development is separated from core asset development. Other approaches that seek a middle ground include frequent staff rotation and processes that require close communication among the groups.

Whichever way this issue is decided, the product line core assets must be managed to bring long-term benefit to the entire organization, rather than to just one specific application. The organizational structure chosen for product line production must assign the decision-making responsibilities for these functions.

And while managing the architecture and other reusable software-related core assets is an obvious product line responsibility that must be assigned to the right organizational unit(s), the management of non-software core assets must be allocated also to achieve the full benefit of core asset reuse. For example, where, how, and by whom will core assets such as product plans, schedules, and budgets be maintained for use across the product family?

Application to Product Development

Product line systems are developed and managed according to a life cycle that differs from the norm. Building products from core assets places greater emphasis on software integration and the testing of interfaces across components. For the unit or units assigned to product development, responsibilities include the following:

making sure that each new product uses the core asset base according to the production plan
working with the core asset owners to evolve new capabilities if the core assets are deficient in some way for a new product
providing feedback to the core asset developers concerning the suitability and quality of the core assets

The product unit(s) may also negotiate customer requirements to situate new products within the scope of the product line to the greatest degree possible, although some organizational structures assign the management of product line requirements to their own units.

The organizational structure must assign responsibility for these roles, as well as for the more traditional product development roles.

Example Practices

Organizational models from a Swedish product line survey: Jan Bosch described four separate organizational models [Bosch 2000b] after studying a number of product line corporations. He discriminated between the models based only on organizational size and did not take into account other factors. The four models he identified were

development department: In this model, all software development is concentrated in a single unit. Each member of the unit is expected to be a jack-of-all-trades in the product line, performing core asset development tasks or product development tasks when appropriate. This model appears in small organizations and those that provide consulting services. Although it is a simple model with short communication paths, it has a number of distinct drawbacks. Bosch wrote that it probably works only for units of up to 30 people. But in very small organizations whose product lines are commensurately small, it can be a viable starting-out approach.
business units: Each business unit is responsible for a subset of the systems in the product line, which are clustered by similarity. Core assets are developed by the business units that need them and made available to the community; collaboration across business units to develop new core assets together is possible. This model has variations depending on how much flexibility a business unit has in developing (or modifying) a core asset. With no constraints, the products tend to spiral off on their own evolution paths, negating the product line approach. At higher levels of maturity, the responsibilities for particular core assets are assigned to specific business units. These units are constrained to maintain their core assets for the general use of the entire product line, and other business units are required to use them. Bosch estimates that this model could apply to organizations with 30 to 100 employees. However, this model suffers from the obvious risk, mentioned above, that a business unit will focus on its own product(s) first, and the good of the product line will take a back seat.
domain engineering unit: In this model, a special unit is given the responsibility of developing and maintaining the core asset base. Business units build the products using those core assets. Bosch writes that when organizations exceed 100 employees, the n-to-n communication channels among separate business units become untenable, and a focusing channel to a central core asset unit becomes necessary. In this model, a strong and disciplined process becomes much more important in order to manage the communication and ensure that the overall health of the product line is the endgame of all parties.
hierarchical domain engineering units: In a product line that is very large and/or very complex, it may pay to regard it hierarchically. That is, the product line may consist of subgroups that have more in common with each other than with other members of the product line. In this case, one core asset development unit may turn out core assets for the product line at large, and another may turn out core assets for the specialized subgroup. This example has only two levels, but the model could be extended indefinitely if the subgroup has a specialized subgroup within it and that specialized subgroup has another within it and so forth. This model works for very large product lines built by very large organizations. Its main disadvantage is its tendency to bloat, reducing the organization's responsiveness to new needs.

Organizational structure for a reuse business: Jacobson, Griss, and Jonsson call for organizing a reuse-based business around a set of competence units, which contain "workers with similar competencies and entity object types that these workers are responsible for" [Jacobson 1997a, Ch. 9]. They prescribe the following units:

requirements capture unit
design unit
testing unit
component engineering unit
architecture unit
component support unit

The component support unit is responsible for "packaging and facilitating the reuse of component systems, and [is] mostly concerned with maintaining the facades and distributing the component systems so that reusers can access the desired components" [Jacobson 1997a].

Workers from these competence units are drawn to form an application family engineering team, one or more component system engineering teams, and a group of application system engineering teams. Application family engineering is where product line decisions are made such as which applications to develop and when. It also crafts the broad product line architecture. Component system engineering is responsible for the detailed architecture and design of a component system. Application system engineering builds products for individual customers.

Small, distributed core group with component representatives: In choosing whether the core asset group is separate or distributed throughout product groups, at least one company we know has opted for a hybrid approach. This company, which has about 50 employees building a product line of information systems, has a set of product groups that revolve around a small but central core group. In this model, the core group is responsible primarily for common support activities such as configuration management, maintenance of the core asset base, some process definition, and the like. An architect for the entire product line would also normally reside in this group. However, in this company, the architecture is not being evolved, and the architect has been reassigned. In each product group, a component representative has the joint responsibility of ensuring the use of core components and creating and evolving the software core assets. A strict protocol is enforced in which any candidate for inclusion in the core asset base must have at least two component representatives sponsoring it. This protocol ensures the asset's reusability across at least two products.

Structure for a distributed or globally dispersed organization: Work force distribution and globalization present additional challenges for organizing a product line effort. Some organizations are addressing these challenges in these ways:

virtual core asset development teams with leaders in one location and dedicated core asset developers in other locations
core asset development teams in one location and product development teams in other locations

Practice Risks

choosing a structure that is inappropriate for the organizational context at hand: An inappropriate structure–one that doesn't match the talent base and/or culture of the organization–will cause the organization to fail to achieve the compromise between building overly generic core assets that are too general or expensive to serve any specific product and product-specific software that is too customized to serve in a product line.
lack of ample feedback and communication mechanisms: Any organization's structure requires ongoing monitoring. These mechanisms are necessary to insure that the chosen structure is working as intended or to raise signal flags when it isn't.
one size fits all, for all time: Many organizations report changing their organizational structure as their product line organizations mature. If your organizational structure is no longer adequate, it doesn't mean that it was wrong–it may just be a sign that it's time to change it.
reorganizing too often: On the other hand, nothing seems to disrupt an organization like a reorganization. Make sure it is necessary before putting everyone through that stress.
ignoring key success factors: Some key success factors in implementing structural change according to Myers, Maher, and Deimel¹ are described below. Failure to account for any of these factors constitutes a risk.
- the current level of organizational stress: How much stress is the organization currently under as a result of previous changes or other stress-inducing factors?
- the implementation history: How effective or ineffective has the organization been in effecting change in the past?
- sponsorship: How effective is the key executive in obtaining commitments to change, communicating the support for change, and managing change?
- resistance management: How will the organization address the inevitable resistance to change?
- culture: Does the proposed change conflict or align with the organization's values, behaviors, and unwritten rules?
- change agent skills: Are the change managers and staff equipped with the skills and motivation needed to implement the change?
adopting an organizational structure without an accompanying operational concept: An organizational structure is just a wiring diagram. Without a clear articulation of the roles, responsibilities, and day-to-day operating procedures, any organizational structure will fail to meet its product line needs.