I was looking for a reporting engine for JIRA and came across the two. Do you have comparison of the above two and why is eazyBI better than ADP?
Here is an answer we got:
Unfortunately, we do not have a side-by-side comparison table because eazyBI and Arsenale Dataplane are conceptually different, event though both look similar at the first glance.
In short, Arsenale Dataplane greatly extends JIRA Reporting functionality by adding dozens of report templates and greater report customization possibilities. If you want to get basic or slightly more detailed reports as quickly and easily as possible, Arsenale Dataplane is probably your best choice. If, at some point, you’ll require anything more specific and customized, you won’t be able to do that with Arsenale Dataplane.
eazyBI provides an interface and tools to build almost any report you can imagine. Creating simple reports is really easy, while advanced reports might require some know-how, understanding of your data, and understanding of multi-dimensional cubes.
With eazyBI you can build all the same reports that are available in Arsenale Dataplane and way more, but with Dataplane you will get to those first reports quicker. In simple words – eazyBI is a very powerful tool, but you have to apply it to reach a solution. Arsenale Dataplane aims towards most common solutions out-of-box.
COMPARISON
-
Sample reports Arsenale Dataplan: Dozens
-
Sample reports eazyBI: Few (More available in Demo accounts, available for export and import)
JIRA Software reports: Analyze - Jira Demo - eazyBI
JIRA Service Desk reports: Analyze - Jira Service Management Demo - eazyBI
GIT Log analysis: Analyze - Git Log Demo - eazyBI
SQL, Google Spreadsheet, CSV, and Excel data reports: Analyze - SQL, CSV, Excel, Rest Demo - eazyBI
those reports into your own accounts. -
Chart types Arsenale Dataplane: Table, Column (Stacked column), Bar (Stacked bar), Area, Line, Pie (Specific charts only)
-
Chart types eazyBI: Table, Column (Stacked column), Bar (Stacked bar), Area (Stacked area), Line, Timeline (zoom in/out), Pie (Specific charts only), Scatter (Bubble scatter), Gantt, Gauge, Map
-
Chart structure Arsenale Dataplane: Limited to pre-defined combinations
-
Chart structure eazyBI: Unlimited – user any dimension, measure combination. Use hierarchies, custom calculations, dynamic page filters etc.
-
Interactive charts Arsenale Dataplane: Limited to pre-defined filter sets
-
Interactive charts eazyBI: Custom page filters, custom filter calculations, drill-in, drill-across, cell highlighting by value, filter by values, filter by regex etc.
These are just a few examples highlighting the core functionality. At the end your choice should be based on your requirements.
Arsenale Dataplane = easy to use, speed to solution = quick, basic to advanced reports, limited report types, less interactive, limited flexibility
eazyBI = more challenging to use, speed to solution = slower, basic to very advanced and customized reports, many report types, unlimited flexibility
The overall goal for Dataplane is to allow anyone in an organization to be able to create reports giving them access to common business metrics, without requiring that users be business analysts or requiring advanced training.
Installation and Ongoing Maintenance
Dataplane was designed for JIRA from the ground up, with a zero-configuration, one-click installation process. Want to provide PDF exports of reports with scheduled report sending? That’s built-in to Dataplane from day one with no extra configuration required. Some of our competitors require you to create separate databases, modify JIRA memory, configure child Java processes, reconfigure Tomcat connectors, install separate server-side JavaScript packages, and configure custom fields, dimensions and measures. If you maintain separate production, staging and development instances of JIRA with change management controls, this type of installation can easily cost you several person-days of work.
In comparison, the single real installation requirement for Dataplane, other than to be using a database that already is in the list of standard JIRA-supported databases, is to install a set of Asian fonts if you require report exports using Chinese, Japanese or Korean character sets. That’s all. Thus, deploying and managing Dataplane across production, staging and test instances is extremely simple.
Of course, Dataplane also supported JIRA Data Center from the first day that JIRA Data Center was available.
Permissions
As a JIRA-native application, Dataplane natively respects common JIRA concepts such as project permissions and user-level security:
Some competitors import all JIRA data into a BI “cube” and all access control is completely stripped. With the cube model, the administrator must define a separate and parallel set of permission controls which grant access to cubes. Even then, access is not granular: you typically either get access to an entire cube, or not at all.
For enterprise instances, this becomes a critical problem. Permission to individual projects can easily change over time, and individual issues can have issue-level security set, but the cube model overrides all of those permissions in a black/white manner. If the JIRA administrator is not extremely careful in tracking all project permission changes over time and mirroring those in permissions granted to the cubes, or if any issue-level security is used at all, then cube-based products will create a hole in your JIRA security model.
In Dataplane, instead of using a completely independent model for accounts and permission access, Dataplane users are simply JIRA users. Users are only ever able to see the projects and issues that JIRA grants them permission to see, and no special configuration is required. From the Dataplane report directory, it is easy to see which Dataplane report was created by which user. Reports can all have names and descriptions and they are visible in a central report directory.
Reports can be either private, or else they can be shared with members of JIRA user groups (which is usually linked automatically to your AD/LDAP) or with users who have access to other JIRA projects. All of the permissions are JIRA-native, so they are always up-to-date as your project configurations change.
Reports are also contextual: if user “A” runs a single saved report, the report will be evaluated in that user’s own context and only the projects/issues visible to that user will be shown. If user “B” runs that exact same saved report, they will get a potentially different set of results depending on what that user is allowed to see.
If you want to recreate this setup in a competing product using the cube model, you would typically have to define a separate account for each user, and then duplicate the same report in each account, multiplying this by the number of different permission permutations you have.
Native Access to JIRA Filtering
Dataplane easily and quickly supports searching and reporting based on JQL queries, JIRA projects, project categories, saved filters from the Issue Navigator, and JIRA Software boards. Cube-based products typically use a non-JIRA mechanism for selecting issues, including as their proprietary menu selection interface or MDX queries.
In Dataplane, you can very simply write queries like this (or just select existing projects, filters and boards from a simple dropdown):
project=ABC and created >= “-24h" and fixVersion >= “1.1” and assignee was in (“martin”, “bastian”) during (“2016-01-01”,“2016-06-30”)
The alternative with some competitors is to try to write this in MDX, which may be difficult for average JIRA users.
As a JIRA-native add-on, this means that you can also leverage JQL functions bundled in other installed add-ons (like ScriptRunner’s extensive set of filters).
Performance and Scalability
We get a significant number of Dataplane clients who have “graduated” from other products due to server performance problems. Some competitors package third-party BI servers and attempt to run them on your JIRA server, which results in a very “fat" add-on that consumes a lot of memory on the JIRA server. The “cube” analysis model also makes it very easy for users to create report requests which create excessive demands and take down the JIRA server.
Dataplane is a 100%-native Java application that runs direct Java bytecode on the JVM, which makes it very fast. Dataplane was born out of Arsenale’s past work as Atlassian Expert consultants starting in 2009. In heavily-loaded JIRA instances, the bottleneck is almost always the JIRA server, and the database server is often sitting around doing nothing. We used this knowledge when building Dataplane in order to offload the vast majority of the reporting workload onto the database server.
This has two main advantages:
-
if you need to scale part of your system, it is vastly cheaper(*) and easier to scale your database server than it is to scale to JIRA Data Center, and
-
in the event that you get a huge influx of simultaneous users and the capacity of your system does reach the limit, Dataplane may get slowed down, but the rest of JIRA will stay up and continue to perform well.
(*) with a possible exception for Oracle databases, although you should still check your pricing agreement with them!
General Reporting Topics
-
Want to report on some standard third-party fields that you use in the rest of JIRA, like Valiantys nFeed or ScriptRunner Scripted Fields? Dataplane supports these fields natively and out of the box. You are out of luck with many of our competitors.
-
Dataplane indexes your JIRA data in real time. Cube-based reporting products are usually limited to doing periodic ETL transformations of JIRA data, which means that you need to wait for the next scheduled import (10 minutes, 1 hour, or whatever the administrator has configured) in order to see updates.
Often, users will be trying to create a report, but they will find that a specific issue shown on the chart was accidentally tagged with the wrong Fix Version, Component or some other data. Once you fix the data in JIRA, the updated chart is available immediately and it can be exported to send to the management team or integrated in the desired presentation without having to wait.
With competitors, your users need to wait for the next ETL before running the report again and their workflow is interrupted. On larger instances with many issues, administrators typically configure the ETL to happen at longer intervals for performance reasons, so this can be a long time.
Summary
Dataplane’s set of built-in reports was designed to meet the vast majority of end users’ needs out of the box and without requiring them to be data experts…and we think we have succeeded.
In addition, many different reports that might seem impossible with Dataplane can actually be done, sometimes using ScriptRunner’s Scripted Fields, Dataplane’s Customizer Scripts, or some other methods. Our support team is responsive and we’re more than happy to help you out. Try us!
Of course, Dataplane also comes with a free 30-day trial and we highly recommend that you try it out for yourself. Our experienced support team is ready to step in and assist as needed during your trial period.
We had a webinar webinar with David Goldstein from Arsenale Systems about JIRA visualization with Dataplane, eazyBI and other solutions:
Check it out!
This week we recorded a Webinar - eazyBI vs. Arsenale Dataplane: What Makes eazyBI Different about the comparison as well:
@Arsenale, I guess your answer is in regard to the eazyBI product. I understand that you avoid name them, but this brings a new issue: If you want to highlight the most important drawbacks about how eazyBI supports an Analytics system for Jira, then I agree you about all those drawbacks. However, you use generic concepts like “cube”, then you are totally wrong in your assertions.
I think it is important for users to highlight this issue as this might bring a lot of confusion to people reading it: perhaps eazyBI implemented a tool with a lot of drawbacks, but those drawbacks are not intrinsically associated with an analytics system implementation based on cubes, dimensions, etc.
You speak about the drawbacks of a product based on “cubes” in general, and this is not true in general. It is possible to build an analytic system fully integrated with Jira out-of-the-box, fully honoring Jira permissions, with full support for Jira native filtering (JQL queries) and without the performance and scalability issues that you mention and isolating users of the complexity of configuring cubes, dimensions, etc. And even I would say without the drawbacks brought by Dataplane either.
The link below is the living proof of such no-drawbacks implementation of a full-featured Analytics system for Jira:
Analytics Client - Business Intelligence.
Disclaimer: I work for the company that developed this app. But on the other hand, everybody can verify by themselves that is is possible to build an analytics system for Jira based on cubes without all the drawbacks brought by eazyBI.