Creating Hierarchical in Datahub

Hi All,

 

Recently i've started Level 2 Model Building and one of the topics in Datahub says -> it's best to create Hierarchical lists in Spoke model by taking data from views created by Flat lists in Data hub but what i feel is it's better to create Hierarchical list directly instead of creating Flat lists and then importing it into Hierarchical list in Spoke Models

 

I feel this will cover Necessary part in PLANS.

 

Please let me know whether this thought process is correct or something else needs to considered?

 

Thanks & Regards,

Sai Bharadwaj

linkedin.com/in/sai-bharadwaj

V.Sai Bharadwaj

Connect on LinkedIn

Tagged:

Answers

  • Hi @Sai_Bharadwaj_Venati ,

     

    The idea of data hub is to hold data, serve as the single source of truth. Having said that, it is ideal to design the spoke models in such a way that entire planning activities can be done there itself.

     

    If you create hierarchies inside the data hub, the problem is you have to go back to Data hub to "update hierarchy" if a new transactional data comes in. And then run the process again in Spoke model to get it updated. Why do the same operation twice? Segregation of duties is a "Logical" part of PLANS, which is getting violated here.

     

    Hope this helps!

    -Nagaraju

  • very often the DH is used to control the validity of data.

    How can you control the validity of data without hierarchies ? No user I know can.

     

    Also the DH should be the place where subsets are created/maintained. Very often on a COA or list of cost center,you'll need a hierarchy to be able to properly define a subset (is this account revenue, is this cost center profit center etc)

     

  • @Sai_Bharadwaj_Venati 

     

    I would say a big NO. Apart from what other champs said you are more likely to see ignore messages as and when you load hierarchical lists of Spoke models from hierarchical lists of DH. There is no way you control what can be pulled.

     

    "Import from List to List is a big NO"

     

    Hope that helps

    Misbah

  • @Sai_Bharadwaj_Venati ,

     

    If you haven't already, please take a look at this article:  Data Hubs and Peak Performance  where I discuss some best practices.  Back to your question on hierarchies in the data hub, as usual, it can be viewed in different ways and while @nathan_rudman  was on one side of the coin, @Misbah was on the other.  Actually, both are correct, in certain instances.

     

    What is a hierarchy really used for?  Really, they are for aggregating data up and reporting and 99% of the time, this should not be done in the data hub.  The only time this should be broken (creating hierarchies in the data hub) is when you are consolidating data sources and creating one source module/view for the data.  All other times, you really shouldn't have them as they just take up space and, except for administrators, no one see's/uses them.

     

    With that said, I do create them using views and actions at the beginning of projects, but that is only to make sure my views/actions are setup correctly.  Once they have been validated, I delete the lists and actions, but still keep the views for the spoke model(s) to use.

     

    Hope this helps,

     

    Rob

  • @Misbah 

     

    Just want to clarify my understanding on what you're saying -> If i have hierarchical list in datahub and if i'm importing it into Spoke model list it will completely import all the data even if i don't want them and show it as ignored items.

    By following this way basically i will lose some time for importing which is directly related to Performance

     

    Kindly let me know if my understanding is proper and what do you mean by this statement - "There is no way you control what can be pulled" is this related to same (Pulling everything and ignoring of data) or something else?

     

    Thanks for the Reply.

     

    Regards,

    Sai Bharadwaj

    linkedin.com/in/sai-bharadwaj

    V.Sai Bharadwaj

    Connect on LinkedIn

  • @Nagaraju 

     

    Just a clarification -> In Level 2 MB this is the flow on how a product gets updated 

    1. Update a product in a flat list with code

    2. Go to system module and update all the details

    3. Import the data into Spoke model Hierarchy list

    What i'm trying to say is : -

    1. Update Product in Anaplan hierarchy list with all details mapped there itself

    2. Import Hierarchical list into Spoke model directly.

    Though i'm understanding there might be some issues but in both places i have to update in Datahub first then take the data into Spoke model. Where is the duplicacy in the above mentioned operation? R u referring i have to manually search and add the product into hierarchy? whereas with Anaplan suggested way i don't have to do the searching i can directly add them (I think it will save time if there a some many items in a list)

     

    Thanks for the Reply.

     

    Regards,

    Sai Bharadwaj

    linkedin.com/in/sai-bharadwaj

    V.Sai Bharadwaj

    Connect on LinkedIn

  • @Sai_Bharadwaj_Venati 

     

    What I meant was that you can't apply filters on Lists to **** out Parents. Its like "Take all and Go" :). That's why its recommended to create hierarchical views in Modules and then pull it.

  • @Sai_Bharadwaj_Venati 

    You've got it. You're thinking is correct. L2 is a game changer IMHO.

    You build the list flat in the DH.

    You build a system module in the DH with all the details about the list including the code, name, and parent.

    You build an import from the system module in the DH (source) to the spoke list (target)

    Build the parents first and work your way down.

     

    As @Misbah  mentioned never import list to list - he covered all the reasons why.

    As @rob_marshall mentioned read the data hub peak performance best practice. It's the best article you'll ever read, trust me.

     

    One Exception:

    • Sometimes you need to test the data in the DH so you might need to build a structured list there. But once you're done with your test, remove the structured list.