Workspace for Data Hub

1454884

How do we decide/suggest customer that we need a different workspace for data Hub?

Do we have any other benefits of having different workspace for data hub other than User segregation?

JaredDolich

@1454884 

yes! yes! Great question. One that many of us face, especially after the first model has been built.

There are so many benefits of a data hub beyond segregation of duties. Recommend you read this article first by @guillaume_arnau - short and sweet.

Some rules of thumb that help build the case for a DH (besides segregation of duties)

• If you feel you need to reuse the data in other models
• You need tighter governance on the master data
• The transaction data is very sensitive (meaning only a few people should have access)
• Your management team is willing to invest in the support of a data hub.

There are some "gotchas" though (my opinion only)-

• Despite all the great benefits you must be prepared to have someone support it. That includes automation, audits, saved views, actions to build hierarchies, etc.. Don't underestimate the time it will take to have someone admin this. A good data hub will have a model architecture in a way that makes support easy - use best practices. Lots of articles on that.
• You must be fully committed to keeping your spoke applications in sync with the data hub. This means you have to have a VERY good partnership with the modeling team for the spoke applications that they will not deviate from established lists and transaction data. You'd be surprised how many times I found people adding to lists or manually loading transaction data into the spoke apps (even with ALM - although that can help)
• Remember, at least for now, there's no way to "push" data. You have to build the actions at the Target and (hopefully) with automation using preferably a CA certificate.
• Invariably you will have to use a calendar for your transactions (see @rob_marshall definitive guide on transaction modules - quite possibly the best article out there). This then suggests you'll have to either maintain the annualization of modules OR you will have to contend with actions that prune your transactions as they become obsolete or your modules grow too big.
• The time hierarchy introduces some additional challenges with your system modules or your output modules that don't use time as a dimension or are out of sync with the Target module in the spoke application. A little advanced but it's an inevitability which really brings us back to my first point, the support.
• Lastly, avoid turning the data hub in to a data mart. While anaplan can scale to amazing sizes and handle the data sub-second, you want to avoid turning the data hub into the source for point solutions outside of Anaplan for non-planning data. That should be procured from a more formal data lake or data warehouse. Reasoning: you will have to build all kinds of interfaces and maintain them for non-Anaplan related activities. Very distracting and difficult to support!