Contact Us
Partner Portal
Help Desk

A Deeper Dive into Qlik’s Statement of Direction: How Check In/Check Out Enhances Continuous Integration

Qlik Sense announced the addition of check in/ check out to their statement of direction, a huge step forward in applying Continuous Integration to your BI practice. At a technical level, Continuous Integration is the process that monitors the project’s source code repository. When a change is detected, a clean copy of the source is pulled, rebuilt, and regression tests are run on it. Any errors are quickly made visible, so developers can detect issues at a much faster pace. This process saves you money because defects and incompatibilities cost less to fix when they are caught within minutes of their introduction.

Continuous Integration is a commonly applied methodology in software development, but not that widespread in the BI practice. However, successfully implementing change is key in creating the most accurate and reliable Qlik implementation possible. The harmony between check in/ check out and version control can be aligned to the good old American classic- peanut butter and jelly. Two great spreads alone, but together they invent a new flavor.

Peanut Butter

Allow Qlik Sense’s check in/check out functionality to be the peanut butter in our culinary example. The check in/check out functionality is autological and we are curious how Qlik is going to apply it in their platform.

In the current Qlik environment, different users can check out the same application at the same time and override each other’s changes when publishing it. Obviously, there are some standard versioning tools that could help prevent the override but they put a huge burden on the BI tool and introduce bureaucracy. Check in/check out should allow users to literally check out a Qlik app so nobody else can work on it. Once they are finished with their edits, they check it back in as part of the publication. so that other people have the ability to work on it. Check in/check out will improve the workflow because users are not overriding each other’s work and communication within the team is improved.

Jelly

Now we add the jelly- zero touch version control. Your organization prevents people from working on the same apps, but it does not have a clear understanding of who has worked on what, and when. For several reasons, it is crucial that you are able to record all the changes made.

First of all, version control is essential for root cause analysis. When a problem comes to the surface, you need the tools and information to understand what was causing the problem, how long it has existed, and how to solve it.

Second, version control allows you to roll back when a mistake is made or something is deleted by accident.

Finally, version control plays a crucial part in providing audit information. Your Qlik application reports critical financial (and other business) information that needs to be audited internally or by external organizations. The entire history of the app is contained in one place. It is also reportable through a Qlik app! Compliance to audit requirements will never be easier.

Quick & Easy Sandwich

Check in/check out and version control is a pairing that should create efficiency and a safety net without creating overhead. Peanut butter and jelly not only tastes good, it’s also great in a pinch when I don’t have time for lunch.

Request a demo to see how zero-touch version control can improve your way of working in Qlik Sense!

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
White Motio Logo Image
Solutions
Products
About Us
Resources
Contact
  • Tel:1 (972) 447-9595
  • Toll Free:1 (833) 855-3073
Follow Us
Youtube Linkedin Twitter
© 2024 Motio. All rights reserved
Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.