Your IT Group is going to be on top of general IT governance practices such as access, security and backups. However, I'm often asked about Good Governance Practices specific to Sisense. To address those requests, this post provides an overview of Practices I've found valuable. Some of the Practices I've listed can also be considered good Design Practices. I list them under Governance, because they help ensure you are able to govern your Sisense installation as it scales and your staff changes. A number of these Practices are covered in detail in separate blog posts. Links are provided for them. My Sisense Good Governance Practices are:
Create and Follow Your Vision
For successful BI delivery with high user acceptance you need a clear Vision of what you want to achieve with BI, a thoughtful, easy to use and understand design, and a plan on how to get there. I won't attempt to present a Program Management primer here, but it is key that you create and document your Vision and Plan to disseminate across your organization. This ensures that all stakeholders are working from a common understanding toward a common set of goals.
Start ElastiCube Tables Names with dim_ or fact_ prefixes
This is a major point of emphasis during the Sisense' Onboarding Process. Examples: dim_Staff, fact_Sales. Also, give the tables Friendly Names. These two practices will help your data model and dashboard designers more quickly orient themselves and become comfortable with the data model. Sisense shows you the original table name in the info box that loads when you hover over any table in the Data Page.
Name the Columns in your ElastiCube(s) with Friendly Names
This is another point of emphasis during the Sisense' Onboarding Process, but is well worth mentioning again. If you are a database developer/admin, you are very comfortable with naming your EC tables and columns with all lower case, no spaces, abbreviated descriptions, etc. Something along the lines of: sales_rev, ops_hrs_fail, etc. I encourage you to follow Sisense' recommendation and be strict in using Friendly Names. Examples: Sales Revenue, Operational Failure Hours.
This practice will help ensure that your non-developer dashboard designers will not be confused about which columns to use in widget creation. It also greatly reduces the amount of renaming required in widgets and helps ensure the same metrics have the same names across multiple widgets. Sisense shows you the original column name in the info box that loads when you hover over any column in the Data Page.
Use the Data Dictionary to Document your ElastiCube
Starting with v7.2 you have data dictionary capability in the ElastiCube Manager. This allows you to define descriptive information for tables and columns. Tables also allow you to define tags to make it easy to designate types of data or related data. See an example in screen shot below from the Sample Healthcare EC. This is a very nice feature and really the only thing missing is the ability to export this information en mass or present it on a Sisense dashboard like a conventional data dictionary. Note: please check out our blog post on our Data Dictionary application: Sisense Data Models Data Dictionary. Also beginning with L2023.6 Sisense Data Model adds a list view that provides an overview of the Data Model with shows a tabular view of the model and supports the ability to view and edit the Tags and Descriptions for both tables and columns.
Hide or Don't Import unused Columns and Tables
Yet another point of emphasis during the Sisense' Onboarding Process. Non-developer designers can be confused if the same column names are present in different tables. Don't import or hide columns you will not be using to reduce the amount of data a dashboard designer has to search through to find the correct column. Once data model validation is complete, be sure to hide join columns. Not importing columns is better than hiding if you will not use a column in dashboards in the future. Not importing reduces EC space and build times.
Employ Consistent, Repeatable Dashboard Designs
Defining and using consistent dashboard visualization Patterns will improve User understanding and engagement. Consistent placement, types and sizing of widgets will help your users orient themselves more quickly when they open a dashboard. As a result, they are more at ease and more likely to stay engaged with your dashboards. I covered this topic in a prior post: Using Dashboard Design Patterns to Increase User Engagement
Pick a Standard Color Palette or create a Custom Palette
Part of having a consistent, repeatable design is the color scheme deployed. Selecting a standard Sisense Color Palette or creating one helps you toward a more consistent metric presentation. This consistency helps with user recognition and retention of widgets and dashboards. I recommend creating a custom palette that matches your brand colors for all the reasons that make branding successful. I covered this topic in a prior post: Success with Sisense Color Palettes
Use Sisense Dashboard Widget Calculation Favorites
Nothing destroys user confidence more than finding that a dashboard/widget is presenting incorrect information. Reduce this risk by using Widget Calculation Favorites to save a calculation once it has been validated. This is easily done by clicking on the star and giving the calculation a name as shown in the screen shot below.
This is a really simple task that I'm sure everyone reading this is familiar with. The point is, if you don't use it, it doesn't help. This example is so simple that you might not utilize a favorite here, but favorites are hugely helpful for calculations with more terms to ensure that the same metric is not presented in different widgets from different calculations. It's also important to think carefully about the naming conventions you employ to make similar named calculations easy to distinguish from each other.
Remember that favorites don't inherit after changes. This means that changing a favorited calculation in a widget and naming it with an existing favorite name does not affect existing widgets using that favorite. Only new widgets use use the new calculation. You'll need to clean up existing widgets' calculations manually. I have heard a rumor that centralized favorite management is on the feature road-map. I've got my fingers crossed on that one.
Implement a multi-Tier Sisense Environment
Prior to go-live, a single tier Sisense installation is perfectly fine. By single tier, I mean a single Sisense server that used for development, testing and ultimately go-live. However, once you are live, the risk of continuing to do development and testing on a production environment is usually not acceptable.
I have a number of customers who use a two-tier environment consisting of Test and Production Servers. I favor a three-tier environment that consists of Sandbox, Test and Production Servers. The Test server allows me to develop and test with no risk to production. It also ensures that development activities don't impact the performance of Production Dashboards. The Test server's dashboards are usually exposed to Users that support Testing of new Dashboards and features. The Sandbox server supports the trialing of new versions of Sisense, plugins and scripts without risk to ongoing Development and Testing activities.
The costs of hardware and software will certainly influence which model is most appropriate for your organization.
Develop a Documented, Repeatable Promotion Process
Now that you have a multi-tier Sisense environment in place (or even if you are still single-tier), it is important to establish a standard, repeatable process for promoting dashboards from Test status to Production status. Often this is a simple checklist covering the sign-off item, who signed-off and the date. The list below covers the key steps:
Dashboard design complete and tested by Designer
Validation of widget calculations complete
Sign-off that design standards, patterns and colors are employed
Info tips on widgets have been completed (if used)
Business Owner sign-off on dashboard
Please see the Testing and Validation topic below for some thoughts on creating dashboards to validate calculations. You may have other check-offs in your organization, but the key is that they are followed before a dashboard is promoted to Production Status.
Organize Sisense Dashboard Navigation to support your Processes
Set up folder structures to organize your Sisense dashboards to support your ongoing development and your Promotion Process. It is important to organize your dashboards so that your know which dashboards have been promoted to Production, which are Ready for Production, which are In Progress, etc. I often use some variation on the folder structure below for Test Environments.
I vary this organization based on the number of tiers in the Sisense environment and the Tier it was created for. I also often use sub-folders to further organize dashboards across different business functions once I have more than fifteen or twenty dashboards.
Implement Testing and Version Logs
Keeping track of version updates and the testing of Sisense, plugins and scripts is important to reduce the risks associated with updates. To that end, I recommend you create logs for:
Sisense version updates
Plugins and their testing status
Scripts and their testing status
I typically create a log for each server like the screen shot below:
This log was created when my customer moved from a single-tier to a two-tier model after go-live. Note: The issue with the v7.1.1 install was caused by a VM cloning problem, not an issue with Sisense.
I also create logs for the installed plugins and scripts and use them as a checklist for new versions or when new Sisense versions are installed on Test. See the example below:
Create Testing and Validation Processes and Dashboards
Your dashboards are built and you are ready to go live. How do you know that the metrics and KPI's you are presenting are correct? How do you ensure confidence continues as your system grows? Each time Sisense is updated or a new plugin is added are you able to quickly validate that your metrics are still correct and that scripts and plugins function correctly? Answer: by building Testing and Validation dashboards. I covered this topic in a prior post: Good Governance: Dashboards supporting Testing and Validating your Sisense System
Document Dashboards and ElastiCubes
How should you document you Sisense system to support maintenance, enhancements, future growth and failure recovery? I covered this topic in a prior post: Good Governance: Documenting your Sisense system
Archive Dashboards and ElastiCubes If your Sisense system crashes or corrupts, IT will restore your last backup to recover. What do you do when someone says:
we need to revert to a previous version of a widget
we should restore the old version of this dashboard
what did we do in the Acme ElastiCube a few months ago
I need the old version of that dashboard calculation
The answer is to pull an archived version from your source repository. I covered this topic in a prior post: Good Governance: Archiving your Dashboards and ElastiCubes
I hope this post is helpful as you think about setting up your own Sisense specific Good Governance practices. Please comment if you have ideas on additional practices that are valuable for your organization.