This guide is an overview to help you understand hierarchies, attributes and the difference between attributes and hierarchies. The guide also touches on why and how to use hierarchies instead of attributes and when attributes may work better than hierarchies.

Why should we care about attributes and hierarchies for data?

We use Hierarchies and attributes every day, but how to structure them is not well understood. Hierarchies include our organizational structures, chart of accounts, sales territories, bill of materials and even our fiscal calendars. Attributes provide details about our products and services, roles and responsibilities, as well as items like location, credit limit or payment terms.

If you wanted to look at geographical sales revenue for a certain product or products globally, in North America, in the South-East region, in Florida or even as specific as Miami you would need to be using attributes and hierarchies. What if a certain vendor or customer has financial difficulty and you’d like to know your exposure? These questions are answered by using hierarchies and attributes.

As data grows in both depth and breadth, it is very important to see beyond your current challenges and even systems. Many organizations are struggling with the influx of unstructured data, sensor data or third party data that they want to leverage for their business users. This is especially impactful is your organization is undergoing a merger, acquisition or even a divestiture. You need to have a strategy for structuring and defining your current and future data so that regardless of what data is getting added or removed you can adapt and the business can utilize the new data paradigm.

Ultimately, all data needs to relate back to your business processes to have real value. Through creating a data strategy that focusses on integrating the data with its hierarchies and attributes with your business process to answer how and why could the business use the data to glean valuable information, you will have data that will grow and adapt as your business changes. Many times, companies get caught up with a current system challenge or focus on a new system and don’t look beyond today’s challenges to see what is possible in the future. Data crosses all systems and all business processes. If you approach your data strategically across the enterprise, It can be a unifying force. If it is approached system-by-system or process-by-process, gaps or silos of data will hinder success.

Common Definitions

Hierarchy – a system or organization in which people or groups are ranked one above the other according to status or authority

Attribute – a quality or feature regarded as a characteristic or inherent part of someone or something

For our discussion, we’ll be using the generic term “Item” to represent data, such as, customer, product, supplier, and organization unit.

Definition in plain language

Hierarchies establish relationships between items or groups of items. They are how we organize items to bring structure for helping us more easily understand how the business operates. Hierarchies are separate from the items themselves. Items are assigned to a level or node in the hierarchy.

They are like a family where the node is the family name and each element below the node can be found by referencing the family name. A node name is a core attribute for the node and can be used as an attribute for searching, filtering etc.

Because hierarchies do not change the item’s information, it is common to have items used in multiple hierarchies. A customer’s location could be used in a sales territory hierarchy as well as a separate distribution network or customer service hierarchy.

Attributes define and describe the item. They are core to the item itself and do not generally change.

There are two types of attributes for an item – Material & Informational. Material attributes, if changed, require a new item to be created. For example, a change in a material attribute of an item that is sold by “size” would be the size attribute itself, e.g., a 3×5 piece of paper vs. 8×11 piece of paper. Informational attributes, while important, do not require a new item to be created if they are changed. For example, a change to customer contact data (informational attribute) is just part of the customer’s information and would not require a new customer to be created.

If these definitions are clear, then why do many organizations struggle with how to structure their attributes and hierarchies to get consistent and easy-to-use information out of their systems? This comes down to understanding the art behind the science of information. Let’s look at an example where one characteristic of a product is used as an attribute and in another situation it is used as a hierarchy.

Product Example – Attribute vs. Hierarchy

Is “blue” an attribute or a node within a hierarchy?  It depends

How does your business use it and why?  If you are a paint manufacturer and sell many types of blue paint with different subgroups, then it could be a node (named “blue”) within your hierarchy. 

However, if blue is one of many colors in which your product is offered or one of the colors used on your product then it would be an attribute.

Attributes give you the ability to look across products regardless of the hierarchical family in which they reside.  For example, an apparel manufacturer may want to know what color is trending across women’s and men’s clothes for tops and bottoms. 

If you supply replacement parts that are specific to a single original equipment manufacturer (OEM), then that OEM or even one of it’s models could be a part within your hierarchy.  However, if you supply a generic part to multiple OEM’s or models then the “manufacturer” or “model” would be an attribute of the part.

Attributes and Hierarchies are unique by organization

How and why the business uses the information drives the decision on if the element in question is a hierarchy.  Each organization uniquely answers ‘how’ and ‘why’ their business uses their information. Defining the right level of granularity for attributes is also critical. For one company the attribute “color” and the value “blue” may suffice. However, for a paint company they will require much more granularity. This in turn begs the question “do you need a structure to help organize the data?”.

One caveat to hierarchies is they are a separate element and must be created and maintained. This is generally done in a Master Data Management tool or even a spreadsheet. As a separate element, there needs to be the same level of resources and governance that the rest of your data receives.

Below are some questions that can help guide you through the process of understanding the right levels of attributes and hierarchies for your organization.

Questions to help drive better attribute and hierarchy usage

• Do we have all the attributes needed to answer today’s questions and support our strategic goals for tomorrow?
• How is the data used?
• Do we use this data to help organize?
  • Do we want to roll up our data and see it aggregated and multiple levels?
  • Do we drill down from higher levels to find discrepancies?
  • Do we want to look across different areas at a certain level to compare data such as a sales territory or product lines?
• Finding specific answers
  • Do we have a need to search for this type of attribute?
  • Would we filter based on this attribute?
  • Would we rank or sort on this attribute?
• Does adding this attribute require us to create a separate item? Or can we have multiple values for an attribute that gives us the information and flexibility that we need?
• Is your hierarchy redundant? Do you need the organization of the data to add clarity or do the existing attributes already easily accomplish what you need?

One question that arises is how to handle an item has an alternate name such as “Bob” for Robert or “Jack” for John. In general, it is best to use additional attributes to hold “common” or “alternate” or “DBA” or “previous” names. This works well if there is no difference in the alternate name. For some companies it could be a substitute part number or different vendor part numbers.

There is an art to asking the right questions to obtain the best answers for your organization. There is a science to validating that these answers will meet your current and future business needs. At Tongere Partners we have found that focusing “how and why” data is used in your organization addresses the art side of the equation. Defining your available data and aligning it to answering the “how and why” delivers on the science. Blending the art and science approach ensures that you will have a successful blend of attributes and hierarchies to meet your business needs.