How do you structure a team around product lines? Largely, it depends on the size and scope of your organization and product lines. A small organization (30 people or less) can use a development department. Larger organizations use business units to focus on the different functional and technical areas of the project. Another option is a domain engineering unit, in which multiple business units share a central domain engineering unit. In extremely large organizations, you might have multiple domain engineering units that specialize in their respective product lines, as well as a central domain engineering unit. In A Practical Guide to Enterprise Architecture (Coad Series)
Development Department
A development department is where a single team creates both the product and the core assets. The benefit is improved communication and less administration overhead. This works for small teams, but is difficult to scale. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
This structure is one where both product and core asset software development is performed by a single department. This department creates products and core assets together. Staff can be assigned to work on any number of products or to develop and evolve core assets. This type of structure is common and most useful in small organizations (less than thirty staff members) that cannot justify the expense of specialized areas for core asset development.
Business Unit
In a business unit, teams structure around a product. Multiple business units share the core assets, and all business units are responsible for the core assets. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
This structure specializes development around a type of product (Bosch 2000). Each business unit is responsible for one or several products in the product line. The business unit is responsible for the development of the product, as well as for the development, evolution, and maintenance of core assets that are needed to create the product. Multiple business units share these core assets, and all business units are responsible for the development maintenance, and evolution of the core assets.
Business Unit Model (Unconstrained Model)
In this model, all business units are responsible for all the core assets and each business unit is responsible for funding features specific to its individual product. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
In an unconstrained model, all business units are responsible for all the core assets. With this type of structure, it is difficult to determine which group is responsible for which parts of the shared assets. Each business unit is responsible for funding the features required by its individual product. Features of the core assets that do not apply directly to the product under development usually fall to the business unit that needs the feature. A large amount of coordination is necessary for this business model to work. Typically, components will suffer from an inconsistent evolution by multiple project teams with different feature goals.
Business Unit Model (Asset-Responsible Structure)
In this model, a single developer or responsible party is responsible for a single shared asset. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
A second type of structure within the business unit model is an asset-responsible structure in which a single developer or responsible party is tasked with the development, evolution, and maintenance of a single shared asset. In theory, this model should solve the problem, but the developer is part of a business area and subject to the management priorities of the project not the shared assets.
Business Unit Model (Mixed Responsibility)
In this model, a whole uit is responsible for different core assets. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
A third type of business unit organizational model is mixed responsibility. In this model, a whole unit is responsible for different core assets. The other business units do not have the authority to implement changes in shared component for which they are not responsible. This model has advantages over the other two. However, business priorities still trump core asset priorities. The high priority requests of one group for changes that is responsible for the core asset and is attempting to deliver a product as well.
Domain Engineering Unit
In this model, there’s several business units and a central domain engineering unit. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
This structure contains several business units and a central domain engineering unit. The domain engineering unit is responsible for the development, maintenance, and evolution of the core assets. This model is the recommended structure for product line adoption in product line literature for large organizations. This structure benefits from a separate group that is focused on creating the core assets, process, and architecture for the product line. The group can focus on high quality components that support multiple projects.
Hierarchical Domain Engineering Unit
In this model, there is a central engineering unit and each product line has a separate domain engineering unit. The central engineering unit is responsible for core assets that span product lines. Each engineering unit takes care of specialized core assets for the product line. McGovern, Ambler, Stevens, Linn, Sharan, and Jo write:
In extremely large organizations, it is likely that multiple domains engineering units are necessary to provide specialized core assets to projects. To accomplish this, each product line can have a separate domain engineering unit that is responsible for specialized core assets for the product line in addition to a single cenrtal domain engineering unti that is responsible for core assets that span product lines.
Processes that Can Be Reused Across Projects
Since multiple engineering units can beneift from shared process, you should figure out which processes you can share. McGovern, Ambler, Stevens, Linn, Sharan, and Jo suggest evaluating the following processes for reuse:
- Analysis
- Requirements gathering
- Design and development
- Software configuration management processes
- Software maintenance
- Release management
- Quality assurance
Key Take Aways
Here’s my key take aways:
- The main structure as a development unit, business unit, and a domain engineering unit.
- A development unit works for small teams (up to around 30).
- A business unit structures around a product.
- A domain engineering unit includes business units and a central domain engineering unit.
- There’s three types of business unit models: unconstrained, asset-responsible, and mixed responsibility.
- Extremely large organizational include both a centralized engineering unit and multiple domain engineering units.
My Related Posts
You should have a look at Accurev. It excels at managing multiple software development release processes graphically, while also allowing personalized departmental views of the software development process to see only those projects one cares about, even when the organization has thousands of streams of concurrent development.
http://www.accurev.com