QlikView does an excellent job of evolving with an organization as it can move faster than an organization thinks. As clients work with their data, their business understanding grows.
QlikView ETL capability can be used to create a rapid-prototyping space to lower the risk associated with making changes to an ETL process by using it's native QVD file format as a temporary substitute for virtual data warhouse tables. When these stabilize, the client can integrate them into the ETL process without unnecessary time pressure.
Application development is highly flexible. This pairs well with an agile methodology allowing for requirements to necessarily flex as the client evolves. If done well, it generates high user acceptability levels.
QlikView provides excellent time to value in that dashboards can be created and deployed quickly. The product has a fully functional scripting language to support all ETL functionality in addition to a fully flexible interface design capability. The ETL piece can be used to quickly bridge gaps in the data.
Ideal state processes can be created by deploying mulitple QlikView files to work together.
Architecture is highly flexible allowing architects to design in constraints at appropriate points to control scope creep.
Simulateous development is difficult as development goes on in one qvw file. There is no check-in/check-out functionality to protect against changes being overwritten. There are third party products that can bridge this gap.
It can be too flexible in that an inexperienced team can fall victim to user whims. This happens when developers implement changes without an appropriate methodolology.
It's not a true platform solution. Integrating with single sign-on solutions as an example, is unnecessarily difficult.
QlikView's achilles heel is RAM. Handling "big data" requires complex, multi-tiered architectures spanning across several applications to maintain performance.