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
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.
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.
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.