I have seen many times the which to fix the number of levels in the decomposition hierarchies (like for example in the maps of business capabilities), with the reasoning that it would make things easier by always having known number of levels. One result of this approach is the appearance of branches with single elements oncertain levels.

There are such hierarchies, where theelements with just one sub-element will make sense, and there areother hierarchies, where this doesn’t make sense.

For example in case of taxonomy, eachelement is representing a set of features – it is a classhierarchy.

In the class hierarchy it makes sense to have even singlesub-class for a particular class, because this sub-class represents adifferent set of features than its super-class. It also could make sense in classhierarchy, if needed, to have a fixed number of levels – because oneach level of each branch you have different set of features (which you can distribute evenly).

It makes sense to have:

either , or .

On the other hand, in case of functional decomposition,like hierarchy of business capabilities or application components, each element is awhole – it is a composition hierarchy.

In the composition hierarchy(which consists of instances, not of classes) it doesn’t make senseto have an element that has only one part, because these are then thesame thing.

It makes sense to have:

, but not .

It also would not make sense inthe decomposition hierarchy to have fixed set of levels – becausethis would either enforce the designers to come up with "dummy" levels just to follow the scheme, and results decomposition that is not natural, causing branches with single elements just to „fill“ the levels ofhierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise tocreate for example business capabilities with only one sub-capabilityor application components with only one sub-component.