Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Sense methodology similar to Tableau Drive

Hi Community,

Is there any equivalent in the Qlik world to the Tableau Drive methodology ?

Has any Sense user ever tried to successfully follow this approach ?

http://www.tableau.com/drive

http://mkt.tableau.com/files/Tableau-Consulting-Services-Drive-Discovery-Workshop.pdf

I think it is still a challenge to traditional developers - including those coming from QlikView - when it comes to providing real self-service BI to business users.

A framework can definitely be useful, and the Tableau approach seems pretty mature... I mean they were successful in this area before Qlik Sense was even launched...

Your input is welcome.

Thanks,

Jean-Philippe

1 Solution

Accepted Solutions
MichaelTerenzi
Partner Ambassador
Partner Ambassador

Hi jphlaurent‌,

Thank you for sharing this link and asking your question. I'll give you a short answer and a long answer, both of which are strictly my personal opinions.

Short answer: No, we do not have an Agile methodology marketing equivalent. We do, however, have a framework that has been around for some time. Have you had the opportunity to explore the Qlik Deployment Framework? If not, stop by and check out this great space: QDF

Long answer:

Drive is a beautiful marketing instrument designed to encourage and leverage consulting services. Like they say - the whole thing revolves around Agile methodology developed in the 90's (which is also how long Qlik has been around by the way) . Having the opportunity to compete with Tableau on a regular basis, I have a lot of respect for their company, product, and marketing. They have been able to do incredible things in a short span of time and have helped open the eyes of people everywhere to the power of data visualization (something both companies have in common). No matter which product one ends up using, the important thing is that you are able to turn data into information, in an approachable, governable way - satisfying both business and IT at the same time. That's the end game, and there are many roads to get there. The devil is in the details however.

There are a few things that stood out to me as I was reading through the whitepaper and manuals for Drive. I think the first and probably most important thing to me, was that it took me about 10 minutes of reading before I actually understood what the prescriptive workflow would look like with the rebranded Agile methodology. I'm not keen on fluff, and it took me a while to get to the meat.

  • They are placing a SME in the center of their Agile workflow circle. This is purposed to fill the gap of Requirements elimination, which is not part of the picture and a fundamental to their workflow. I agree, Requirements definitions can sometimes cause more time and work than desired, but putting a Subject Matter Expert in the center of the team brings with it a heavy dependency that doesn't necessarily align with true self-service.
  • There are a few roles required to implement the Drive methodology:
    • Executive Sponsor. Based on this, it doesn't look like Drive is geared towards the small or mid-markets. Rather, it's setting the stage for Enterprise and the services packages that come along with it to get stood up.
    • DBA -

      "The Drive team will call on the DBA for appropriate database drivers, logins, and access to the data set. In certain situations, the DBA will model or structure the database in a manner that enables optimized integration with Tableau." I'm going to go out on a limb here and say this isn't Agile at all, but a fundamental need for Tableau deployments to help streamline their lack of ETL within the product. Try getting a DBA to model or restructure a database during a sprint and see where the delivery bottleneck is. I fundamentally disagree with this requirement, simply because with Qlik, you don't need it.

  • Which leads us to the sprint itself. I found this segment interesting:

    • Drive Sprint

      • "Paying homage to Agile methodologies, we call the process of working collaboratively through problems a Drive Sprint. During a Drive Sprint, the Drive Team will meet face-to-face to create a set of reports, analytics and/or dashboards in short order.Each Team member should:

        • • Have Tableau Desktop installed "

It was at this point that I really had concern, and is where our two solutions diverge dramatically. License implications aside, Tableau is promoting desktop development over server-side development, even though they recently introduced this capability on server. Desktop development is necessary at times of course, but it also removes a lot of the guardrails set in place by IT in a server deployment. Is it a scalable solution to govern everyone's local desktop installation? Ask the DBAs to setup ODBC drivers and connection privileges for these development sprints on each machine? The beauty of Qlik Sense is that you implement this same methodology if you wanted, and develop it all server-side in a governable way, without the excess. It is my opinion that you could actually implement the Drive methodology with faster time to delivery, less roles, and completely governed, on Qlik Sense Enterprise. Thank you again for sharing this question.

- Michael Terenzi

View solution in original post

2 Replies
MichaelTerenzi
Partner Ambassador
Partner Ambassador

Hi jphlaurent‌,

Thank you for sharing this link and asking your question. I'll give you a short answer and a long answer, both of which are strictly my personal opinions.

Short answer: No, we do not have an Agile methodology marketing equivalent. We do, however, have a framework that has been around for some time. Have you had the opportunity to explore the Qlik Deployment Framework? If not, stop by and check out this great space: QDF

Long answer:

Drive is a beautiful marketing instrument designed to encourage and leverage consulting services. Like they say - the whole thing revolves around Agile methodology developed in the 90's (which is also how long Qlik has been around by the way) . Having the opportunity to compete with Tableau on a regular basis, I have a lot of respect for their company, product, and marketing. They have been able to do incredible things in a short span of time and have helped open the eyes of people everywhere to the power of data visualization (something both companies have in common). No matter which product one ends up using, the important thing is that you are able to turn data into information, in an approachable, governable way - satisfying both business and IT at the same time. That's the end game, and there are many roads to get there. The devil is in the details however.

There are a few things that stood out to me as I was reading through the whitepaper and manuals for Drive. I think the first and probably most important thing to me, was that it took me about 10 minutes of reading before I actually understood what the prescriptive workflow would look like with the rebranded Agile methodology. I'm not keen on fluff, and it took me a while to get to the meat.

  • They are placing a SME in the center of their Agile workflow circle. This is purposed to fill the gap of Requirements elimination, which is not part of the picture and a fundamental to their workflow. I agree, Requirements definitions can sometimes cause more time and work than desired, but putting a Subject Matter Expert in the center of the team brings with it a heavy dependency that doesn't necessarily align with true self-service.
  • There are a few roles required to implement the Drive methodology:
    • Executive Sponsor. Based on this, it doesn't look like Drive is geared towards the small or mid-markets. Rather, it's setting the stage for Enterprise and the services packages that come along with it to get stood up.
    • DBA -

      "The Drive team will call on the DBA for appropriate database drivers, logins, and access to the data set. In certain situations, the DBA will model or structure the database in a manner that enables optimized integration with Tableau." I'm going to go out on a limb here and say this isn't Agile at all, but a fundamental need for Tableau deployments to help streamline their lack of ETL within the product. Try getting a DBA to model or restructure a database during a sprint and see where the delivery bottleneck is. I fundamentally disagree with this requirement, simply because with Qlik, you don't need it.

  • Which leads us to the sprint itself. I found this segment interesting:

    • Drive Sprint

      • "Paying homage to Agile methodologies, we call the process of working collaboratively through problems a Drive Sprint. During a Drive Sprint, the Drive Team will meet face-to-face to create a set of reports, analytics and/or dashboards in short order.Each Team member should:

        • • Have Tableau Desktop installed "

It was at this point that I really had concern, and is where our two solutions diverge dramatically. License implications aside, Tableau is promoting desktop development over server-side development, even though they recently introduced this capability on server. Desktop development is necessary at times of course, but it also removes a lot of the guardrails set in place by IT in a server deployment. Is it a scalable solution to govern everyone's local desktop installation? Ask the DBAs to setup ODBC drivers and connection privileges for these development sprints on each machine? The beauty of Qlik Sense is that you implement this same methodology if you wanted, and develop it all server-side in a governable way, without the excess. It is my opinion that you could actually implement the Drive methodology with faster time to delivery, less roles, and completely governed, on Qlik Sense Enterprise. Thank you again for sharing this question.

- Michael Terenzi

Not applicable
Author

Hi Michael,

Thank you for this very detailed answer.

I've never used Tableau myself, but I've already heard some of the drawbacks you mention: no embedded ETL, poor scalability,...

On the other hand, I like their idea of putting a Subject Expert at the center of the process, even if it means starting small. After all, if you really want the end-users to take over most of the visualization part, you must not underestimate things like learning curve, tool (and data) appropriation, and change management...

And talking about scalability and product maturity, I'm still eager to see a real-life, complex data model exposed to a business user using the current version of the Master Items in Qlik Sense 3 - say a model made of 10 dimensions with 5 levels each, and more than 100 KPI's.

I'm still frustrated to have no hierarchy and no folder structure in the Master Items...a flat listing of 200+ items, with only tags to help the user find his way...not very cool

Jean-Philippe