I have seen many times the wish 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 on certain levels.

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

For example in case of taxonomy, each element is representing a set of features – it is a class hierarchy.

In the class hierarchy it makes sense to have even single sub-class for a particular class, because this sub-class represents a different set of features than its super-class. It also could make sense in class hierarchy, if needed, to have a fixed number of levels – because on each 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 a whole – it is a composition hierarchy.

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

It makes sense to have:

, but not .

It also would not make sense in the decomposition hierarchy to have fixed set of levels – because this 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 of hierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise to create for example business capabilities with only one sub-capability or application components with only one sub-component.