Two approaches to ragged hierarchy

Author: Taichi Amaya, Certified Master Anaplanner, and Financial Planning and Analysis Specialist at Pasona Group, Inc.

In Anaplan, we consider it a significant feature that lists are hierarchical. Hierarchical structure allows for smooth and meaningful connections from the parts to the whole and gives flexibility to the planning process. I hope to share my experience as a Certified Master Anaplanner working with hierarchies as briefly and logically as possible.

What are ragged and balanced hierarchies?

To explain this, I have to define two things about the hierarchy. First, the 'top-level item' is an item that has no parent. The second is the bottom items. We sometimes call them leaves or detail items. They're items that are not the parent of any other member. In a balanced hierarchy, every bottom item is the same level away from the top item. The opposite, a ragged hierarchy, is a tree structure in which the distance between the top and bottom varies.

One of Anaplan's attractions is its flexibility to accept data from other systems for Connected Planning. When we import data from other systems than Anaplan, is the hierarchical structure always balanced? Not necessarily. I have experienced in some applications that the hierarchies are ragged. Sometimes it isn't immediately apparent how many levels there are in the hierarchy. It is because programs often describe the hierarchy as an adjacency list. To receive such data correctly and to handle it in Anaplan in an understandable way, we consider it better to parse the hierarchical structure from ragged to balanced. (See Planual 1.05.08: Use composite lists rather than ragged.)

A composite list is a method of creating a line item for each level (L1, L2, L3...) and connecting them as a parent hierarchy. You may be familiar with this method from the training course on Composite or Hierarchical Lists. To create a composite list, it's necessary to have a balanced hierarchy (however, the balanced one is not always composite).

How do we go from ragged to balanced? Go back to the balanced explanation: the distance from the top to all the bottoms is equal. Thus, if the parent-child hierarchy is shorter than the furthest leaf, we can transform it from ragged to balanced by inserting a dummy item into the branch. For instance, in a hierarchy where the longest top-bottom distance is four, and if there are leaf items two levels away from the top, we have to insert two dummies between the top and the bottom.

Two approaches to fixing the hierarchy

Where do we insert those dummies in the branch? I believe there are two approaches to this.

We will take the following ragged tree as an example. The longest distance is three for ALL -> L1_A -> L2_A -> A1. Bottom items other than A1 are two levels away from the top.

1. Top-down approach

In the top-down method, for an item, we settle the distance from the top to any parent item and insert a dummy hierarchy below the original parent. In this example, we insert dummies between L1_A and A2, L1_B and B1, and L1_B and B2. By inserting these three dummies, we now have a symmetrically balanced list. (* Learning・305 is also basically a top-down method, but it appears that the dummy is added below the item that actually exists to balance.)

2. Bottom-up approach

In the bottom-up method, first we line up all leaf items and insert a dummy hierarchy above to maintain the number of levels from the bottom. Since L1_A is two levels up counting from A1 but one level up counting from A2, a dummy (D2_A) is inserted above A2 to balance this point. And because L1_B is both one level up from B1 and B2, we don't need to insert a dummy in L2. We create a dummy item (D1_ALL) in the parent of L1_B to make the distances from the top to bottom two from one. The outcome is also a balanced tree since the distances from top to bottom are all two. However, it's asymmetrical and may be intricate for end users, as there is a division named "L1" in the L2 hierarchy. It seems to be a disadvantage.

Then why is it necessary to use the bottom-up approach? To reduce the computation cost. In the top-down method, we inserted three dummies, but in the bottom-up, we had to create only two dummy items to balance. The larger the hierarchy becomes, the greater this effect will be. The example below is the number of items after fixing the hierarchical list that occurred in my company's case, where the top-down and bottom-up methods almost doubled the total items (parent item alone, 187->710, or about four times the number of items).

Note that the top-down method will result in a "correct" (easy to understand) hierarchy compared to the bottom-up, but this will result in unnecessary summary calculations. If end users agree to use the hierarchical structure created by the bottom-up method, I believe there is merit in choosing this approach.

Do you have feedback on this content? Let me know in the comments below!