Continuous Integration For Qlik Sense

Post: CI For Qlik Sense

Agile Workflow for Qlik Sense

Motio has been leading the adoption of Continuous Integration for agile development of Analytics and Business Intelligence for over 15 years.

Continuous Integration[1]is a methodology borrowed from the software development industry which incorporates new code as it is developed. Continuous Integration was one of twelve practices proposed by Kent Beck’s Extreme Programming in the 1990s for agile software development. Benefits of the process include reduced errors in integration and the more rapid development of a unified piece of software. The process doesn’t eliminate bugs, but it makes finding them infinitely easier because you know where to look – the latest code that was checked in and integrated. Plus, the earlier bugs are identified and fixed, the less cost. Defects which make it into production are much more costly to fix.

Once you have Continuous Integration, you are one step closer to Continuous Deployment. For practical purposes, Continuous Delivery comes between Continuous Integration and Continuous Deployment. Continuous Delivery is the process of integrating software changes so that it can be tested as a whole. Continuous Deployment is the ability to get changes into production and into the hands of the users.

Martin Fowler remarks that, “The key test [of Continuous Delivery] is that a business sponsor could request that the current development version of the software can be deployed into production at a moment’s notice – and nobody would bat an eyelid, let alone panic.” So, Continuous Integration, Delivery, and Deployment is the sustainable ability to quickly and safely get changes in software code to the business users. That’s the gold standard for software development. Analytics and Business Intelligence development has adopted these processes for managing agile delivery of insights to stakeholders.

Motio has been leading the adoption of Continuous Integration in Analytics and Business Intelligence for over 15 years. Soterre was developed by Motio to fill the gaps in the already excellent tool, Qlik Sense. Soterre for Qlik Sense is a solution that enables version control and deployment management that is necessary for the Continuous Deployment and Continuous Delivery pieces of the agile BI lifecycle..

The purpose of Continuous Delivery in Analytics and Business intelligence is the same as for software development – to support an agile development process by providing end users with real-time changes to reports, dashboards and analytics. We’ve seen that many of our clients have distinct Development, QA/UAT and Production environments to support their Analytics and BI development workflow. Soterre supports the Continuous Deployment workflow with a flexible deployment process. The tool allows you to connect multiple environments and safely promote targeted content between them. .

Soterre’s zero touch version control contributes to change management and audit support. Version control is the first step in Continuous Integration – managing collaboration from multiple authors. Soterre’s version control supports integration with GitLab (as well as GitHub, BitBucket, Azure DevOps, Gitea). GitLab is an open source collaborative project management software that owns two thirds of the Git self-managed market for source code maintenance.

In one case study, Qlik Sense with Soterre improved the production rate of Qlik apps, reduced duplicate and similar content, provided a safety net for developers needing to revert to a prior version and improved throughput of deployments, a key administrative task.

If your business is serious about analytics and business intelligence, you’re already trying to implement proven practices and industry standards. Those standards require an agile development framework. Agile requires Continuous Integration, Delivery and Deployment. The only way to do that with your analytics and Business Intelligence in Qlik Sense is to use Motio’s Soterre.

  1. https://www.martinfowler.com/articles/continuousIntegration.html

 

Interested in learning more about Soterre for Qlik Sense? Click HERE.

 

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.