Microsoft’s recent acquisition of Datazen has brought it to the forefront of the conversation about data visualization, particularly with their plans to integrate Datazen with SQL Server 2016. Datazen is a data visualization platform that presents data integrated from multiple sources including Excel, SQL Server databases, OLAP, SharePoint, Web Services, ODBC, and others. For the purposes of this blog post, the data sources with which we initially experimented were two SQL Server databases.
A major benefit when using Datazen is that it allows for different views of the data on different devices. For example, when creating a dashboard the author can specify how the dashboard should look on a laptop, a tablet, or a phone. After the dashboard objects have been configured in the master view to display the appropriate data, it is a simple process to adapt the layout to display them on different devices. Nevertheless, there are several significant limitations that Microsoft will need to address before this platform will be ready to be a significant player in the data visualization market. Those considerations are:
1) Speed of integrating data sources
The integration of data sources with Datazen works through one or more ‘Hubs’ which connect to the data sources. The connection criteria are simply entered into the Datazen Control Panel and the user is connected to the data source. Actually importing the data into Datazen Publisher, which is the application used to create a dashboard, is accomplished through the use of data views. Data views are created by the developer in the Control Panel through queries and manipulate the data in ways that Datazen can understand. However, the queries cannot be too complex or they will take too much time to execute and timeout. It would be very useful to have the Control Panel automatically integrate existing functions and views, executing them the same way they would run in SQL Server (e.g. similar query plans, etc.). This would save developers the time of recreating the views in the Datazen Control Panel.
2) Data Volume when importing data into Datazen Publisher
When importing data views into the Datazen Publisher application, the developer must be very aware about the amount data they are trying to incorporate in the dashboard. Too much data being pulled into too many objects can cause the application to crash. Instead, the dashboard should be limited in the number of objects on it, while still conveying the appropriate information to the end user. One way to limit the number of objects on a single dashboard is to link one or more objects to another dashboard through a drill down and then display further information without cluttering the first dashboard. After data has been imported into the Publisher application, the developer can set any existing parameters, ensuring that selections made by a user on the dashboard will be reflected in the objects.
3) Limited configurability of Dashboard Objects
The available dashboard objects seem rather straightforward at first glance. However, it can be tricky getting them to display the extracted data the way the developer desires. For example, there is currently no way to display two types of information on a single graph, such as a number and a percentage. Likewise, it can be difficult to link different sets of imported data to a single object, for instance a single table showing clients and projects. Aggregations and filters can be applied to the data though Publisher, but any real manipulation of the data has to be performed in the original query in the Control Panel. Also, there is no existing date or calendar option. To create a selection list that includes years, months or any other date options, the developer must create a query and import the resulting data set that includes the desired dates. It would be beneficial to have an existing object that will display years and months, and could then be configured to user specifications in the Layout View.
4) No ability to save a Dashboard locally
One major difficulty in development is the inability to save a dashboard locally while working on it. The only way to save something is to publish it to the server, and if the application crashes, any changes since the last time it was published to a server will be lost. Though this is rather standard for any computer program, it is inconvenient to have to constantly publish the dashboard to a server because any other user would be able to see the incomplete dashboard. The ability to save an in-progress dashboard locally would allow for a developer to complete a dashboard before publishing it for others to view.
5) Lack of Third Party Documentation
Because Datazen is a newer technology, it lacks the extensive third party documentation that can be found on a competitive and mature technology like QlikView or Tableau. Therefore, it can be difficult to find a source with a solution for a specific problem, as most existing documentation is simply an introduction to Datazen. Also, much of the existing documentation deals with simpler queries and less complex data than a normal business would typically have.
In its current state, Datazen is not ready for a professional software development life cycle. There is no consistent way to promote changes from development to test to production, and source control is currently unavailable. The ability to locally save a dashboard will begin to resolve this, but further development of the software development life cycle would be the best option. Additionally, streamlining the integration of data sources, importation of these sources with Datazen, and the configuration of the dashboard objects is likely to increase the number of users. In turn, this will increase the amount of third party documentation. Therefore, if Microsoft continues to develop Datazen’s capabilities, and fully integrate it with the 2016 SQL Server release, it has the potential to be a very powerful tool
. and could be a viable answer to data visualization within the Microsoft space.