Introduction
Many things have been said about which architecture to follow when developing Qlikview Apps. The overall winner so far has been the 3-tier architecture. This is simple 3 apps that do different things. The first 2 apps act as an ETL process and the third app will be the visualisation layer. Therefore, the first app, Tier 1, will only get source data from wherever and store it into different QVD's. The second app uses the QVD's from Tier 1 and does all the modelling and transformations and stores this into a more star schema structure. Tier 3 will then just read these QVDs and display the analytics as we need.
The above process is the basic 3-tier process followed in developing Qlikview Apps that are reusable and mostly for long term projects that will need maintenance and are going to be used long term. but, what if you need to complete a quick POC for someone. One wonders if this process is still necessary. In this post, we will discuss the merits of using a 1-tier architecture as well as the situations whereby this would be needed.
When to Use
When is it advantageous to use a 1-tier architecture? The answer should be never as we are trying to build scalable, maintainable Qlikview Apps and we need to separate processes. It is also important that Apps are separated for debugging purposes as well as code refactoring for future use. However, the above mentioned are in the case where a project has been accepted and ready to be implemented. What happens if you must create a simple POC for a client?
This, changes everything because you should ask whether you would need a proper 3-tier architecture for this, especially is the source is simple excel sheets. Therefore, in this case, a 1-tier architecture is warranted especially if the code will not be re-used and you just need to show the client some of the benefits of Qlikview. This is the elevator speech of Qlikview. It also highlights the power of Qlikview should get an App up and working relatively quick.
Another place where a 1-tier architecture can be used is when the source is already in a good schema state. Basically, when we do not need to make any transformations to data and would like to just display the data in the database in a business-friendly manner.
So back to the question of using a 1-tier architecture, the answer should be, “Sometimes when needed”.
Advantages
· To get a POC off the ground
· When there is limited data to analyse
· Perfect to use when dealing with excel data
· When just loading from one source data (When transformations are not needed)
Disadvantages
· Depending on the data, performance could be impacted
· Maintainability and re-use of the script could become complicated
· Many points of failure without being able to know what exactly failed
· Script could become complicated if transformations are needed to be done on the data
· Transformations will impact overall user experience
Conclusion
In conclusion, there is a use for a 1-tier architecture. It is useful when conducting a potential POC as well as when the database is already in a good schema – sits on top of the database for visualization purposes - when all that is needed is to import data and use it to answer business questions visually. It is not useful when we need to conduct an ETL process because this could make the process cumbersome and make the code unreadable and difficult to maintain.
