5 Things to Look For in Your Next Business Intelligence Platform
Business intelligence engineers are responsible for building out the architecture and infrastructure that meets the organization's needs. Here are five key areas to evaluate when trying to determine which business intelligence platform is right for you.
- By Troy Hiltbrand
- July 9, 2021
The terms business intelligence (BI) engineer and business intelligence analyst are often used interchangeably. This causes great confusion because the job requirements and needs are different. A BI analyst uses the existing infrastructure to build reports and analytics to answer questions for management decision making. A BI engineer often assists in this effort as well but is also responsible for establishing and maintaining the infrastructure and architecture that supports this ongoing analysis and reporting.
As a business intelligence engineer, you are responsible for looking at different tools and identifying which platform will best support the needs of your business and which will work with your overall organizational architecture. As you start to evaluate these BI platforms, you will quickly realize that they are much more than a simple report-building tool; they are an ecosystem that supports data synthesis, data analysis, and data delivery. It can quickly overwhelm you as you try to assess which platform will work best for your organization.
As you compare these BI platforms, here are five key features you should assess to determine fit for your use case and for your environment: data visualization, data delivery, data cataloging, automated insights, and access management.
Data visualization is one of the first things to evaluate when looking at different business intelligence platforms and will become the measurement by which your team's success is evaluated. Your users will judge your success by how well the end results turn out. They will care about the aesthetics as well as whether the reports are timely and accurate.
In evaluating the data visualization component of the different BI platforms, evaluate what options are available for displaying results to your end users. What types of graphs and charts are part of the platform? Can these be aggregated into a dashboard of tiles that each shows different parts to the overall performance story? Are these dashboards configurable by the end user? Are the visualizations clean in terms of the available colors and shapes? Users will spend a lot of their time interacting with your business intelligence platform and these factors will be the yardstick that determines whether they are satisfied with the tool.
As part of data visualization, you will need to understand and assess the platform's ability to provide effective navigation in the environment and between data visualizations. Does the toolset allow a user to interact with the data? (This could include the ability to filter and sort the data as they try to understand what it is telling them.) Does the platform allow them to drill down into the detail, drill up to look at summaries, or drill across to see related sets of data? This is where the power comes for your BI analysts to explain why some aspect of data is the way that it is.
Dashboards are an amazing method of getting information into the hands of your users, but they are not the only way. Dashboards are just one way to satisfy pull-based demand. They do, however, require that the user come into the system periodically to consume the available information. If you have busy users, you know that you need to have a secondary strategy to get data into users' hands using push-based methodologies as well. This requires a different set of capabilities in your business intelligence platform.
Even in our highly connected digital world, there are still many users who like to have their reports delivered in print form. This means that the tool needs to be able to support pixel-perfect reporting. When evaluating platforms, you can ask questions to see how it handles offline reporting. How does printing handle pagination? How does it handle report headers and footers? How does it scale graphics so they lay out nicely on the page? In addition to printing, determine if the reports can be exported to another format, such as PDF or Excel to be sent electronically as attachments with the possibility of being converted into a physical format in the future.
As you assess the push-based capabilities, determine what triggers the delivery of data. The standard time-based delivery mechanism is the most common, but does the platform take into consideration the time zone of your recipient or does all information get delivered based on the server time zone? Can it implement more complex threshold-based triggers to deliver the data only when certain events happen or when the nature of the data changes warrants action?
Being able to refine when users get reports delivered can decrease their desensitization caused by information overload and increase their response when it is needed. The more powerful the platform's delivery rules and thresholds, the more complex the environment is to manage. This complexity must be weighed against the potential business value of delivering the right information at the right time and eliminating the buildup of information noise that just causes distraction.
In addition to supporting report consumers, you will be responsible for providing a platform that gives your BI analysts tools that will make them effective at performing their information generation and analysis activities. As data becomes more democratized across the organization, this set of capabilities will expand beyond the boundaries of the BI team. You will have power users and data analysts from other departments who need to interact with your platform at a much deeper level.
To assess this, you need to understand the metadata framework built into the business intelligence platform candidates. The metadata components critical to your evaluation are the business layer and the technical layer.
The business layer abstracts your users from having to know the technical details of where the data lives or how it is structured at the database level. This includes naming conventions and definitions that are familiar and comfortable with your business users and that create consistency in the corporate terminology that supports analysis. The business layer should be easily consumable by data analysts and power users and should give them clarity about what data components can be aggregated and used as measures, and what data needs to be used as dimensions that provide slicing and dicing of the data. This layer also needs to set the guide rails of what relationships exist and how data can be compared without creating incorrect and misleading results.
The technical layer is the translation layer between the business layer and the technical structure of where this data resides. A solid technical layer will transform business questions into the query language appropriate for your technical architecture. This needs to take into consideration not only the technical restraints of your environment but also mechanisms for optimizing data retrieval from your source systems.
As analysis becomes increasingly powerful with new algorithms and new, advanced analytics methods, platforms are constantly looking for ways to automate this process and democratize its utility. This includes the ability for platforms to support automated insights. This can also include features such as automatic selection of chart types to match the data, automated selection of data attributes, regressive trend identification, and natural language processing to extract structured data elements from unstructured data sources.
As you evaluate these platforms, find out what features are available to automate the surfacing of insights, what skills are needed to leverage these automated insights (both in the production and consumption of them), and what needs to be configured on the back end of the platform to fully support their utilization in a production environment.
Automated insights are amazing advances in business intelligence technology, but make sure your end users know what to do with the results once they are created. Your tools might be able to perform incredible feats of engineering execution, but if the results produced are not easily consumable, your end users will fail to realize the promised value.
As with most enterprise-level tools, you will have multiple types of users working within your environment. Assess what tools support a security model that effectively keeps the wrong people from accessing the wrong data, while at the same time granting access to those analysts who can expose valuable data for decision-making activities.
When evaluating the security of the platform, assess how it handles user configuration and role-based access controls. Examine how authentication into the system is performed and whether it can be integrated into your other security systems to reduce the duplication of management effort.
At the data level, determine if the tool can do both row-based and column-based filtering to manage what data end users can see. As you expose the business metadata layer to more analysts across the organization, make sure this user-based filtering extends across all layers. This will allow your users the freedom to find valuable insights without the fear of exposing sensitive data.
In addition to controlled access, ensure that the platform has effective auditing to track when security boundaries are breached or alert administrators when security profiles are misconfigured.
A Final Word
As a BI engineer, establish your questions for potential platform providers to cover these five areas. Make sure you match your platform with your end-user needs. At the end of the day, your success as a business intelligence engineer will be measured by having the right platform and configuring it correctly to enable analysts to get at the right information to enable a data-driven organization.