I am thinking about deploying QDF but after reading the Container Architecture examples from the Operations Guide, I still cannot decide which architecture I should put in place.
Anybody would have feedbacks on the "parameters" they took into consideration when deciding which Container Architecture they should implement? (Number of applications, security access based, Business departments...)
Hi Jean-Christophe, the great thing with QDF (based on global variables) is that redesigning containers after implementation is easy, you can almost freely move applications between containers,move/rename containers and add new containers when needed. So the biggest step is to adapt your current applications for the framework.
If we address the architecture, I personally like having a separate substructure with individual containers for all the data sources/views and marts (1000.DataSources\1.DataMart).
I also creates individual containers for each BU/OU where the end applications are stored. Transformation steps and KPI's needed for this BU/OU only are stored in the same container,so that associated business logic is in the same place.
Hope this helps
Thanks for your input Magnus.
It may be a silly question but what is the advantage of using a dedicated container per data source instead of using the default 99.Shared container for example since the data may be shared by multiple BU/OU?
If I try to put your logic into perspective for, let say, a company which has Sales, Marketing and R&D departments with 2 sources of data:
- Would you put Marts shared by Sales and Marketing into 1000.DataSources\1.DataMart even if R&D is not using it? Basically, in 1.DataMart you would store any Mart used by more than one BU/OU, otherwise it would go in the BU/OU container?
- Where would you put KPIs shared by Sales and R&D only? Same logic as for previous question? (Maybe it does not make sense from Business point of view, it is just to illustrate BU/OU relationships )
Sorry, I am just trying to have a better understanding of concrete implementations and rules/choices which led to them.
Hi JC, I would separate every data source in its own data source container so that its easier to reuse data than it is to create a new connection string and load directly from the source. R&D is not using the source today but what happens when they decide to start using it? They have no clue that there are data in a sub folder under the Sales container. But the natural thing todo is to check under DataSources for the data before creating a direct connection. And no problems during company restructuring, the data is not associated to any organization.
Also the sub function LoadContainerGlobalVariabes('SourceSystemName','QVD') in the beginning of all end user applications creates a very good understanding what this app is doing just by looking at the first lines of code.
When it comes to KPI's there are two good ways, one is to store all KPI's in the shared container the other is that related KPI's stores in "his" container (owner), to reuse from another containers you need to connect to the owner container and "borrow" the KPI.
Hope this helps?