Looker is a BI application with an analytics-oriented application server that sits on top of relational data stores. It includes an end-user interface for exploring data, a reusable development paradigm for data discovery, and an API for supporting data in other systems.
N/A
OpenText Magellan BI & Reporting
Score 7.3 out of 10
N/A
The OpenText Magellan BI & Reporting (formerly OpenText Information Hub (iHub)) component of OpenText™ Magellan™ Analytics Suite is a scalable analytics and data visualization platform that enables IT leaders and their teams to design, deploy, and manage secure, interactive web applications, reports, and dashboards fed by multiple data sources. Magellan BI & Reporting supports high volumes of users, and its integration APIs enable embedded analytic content in any app, displayed on any…
Quick dashboards from Google Sheets - Easier to do the graphs than in Google Sheets - Operational dashboards to be used in the day-to-day work - It is good both for retrospective data and to do a pulse check of the current status - Better for not giant amounts of data and not multiple data sources. - If you need a lot of graphs to be displayed on the same page, it can be a bit glitchy during configuration (then the use works fine).
iHub is a decent enough environment that it serves our needs. We can have unlimited users and it can tie into AD although we do not use that feature currently. It is a decent place to store all of the reports in one location, even though for us it is not visually appealing to the end users. iHub is not a place where you want to create robust/interactive dashboards for end users to drill through and follow a "story".
Filtering - you can filter across different dimensions and metrics to get a more specific "cut" of data
Refreshing - data automatically ingests into Looker which allows reports to be updated and backfilled in real time
Conditional Reporting - you can leverage Looker's reporting features to flag when a given metric or KPI falls below or above a specified threshold. For example, if you had a daily sales benchmark in a SAAS organization, you could use Looker to flag whenever daily sales falls above or below the benchmark
Looker is less graphical or pictorial which makes it less attractive
Consumes a lot of memory when there are multiple rows and columns, impacts performance too
At times when we download huge chunks of raw data from Looker dashbords, the time taken to prepare the file is enormous - The user fails to understand if Looker has frozen or if the data is getting prepared in the background for downloading. In turn, user ends up triggering multiple downloads
Setting up a "dashboard" is extremely lacking in functionality. The different chart widgets you place on the page do not interact with each other. When you select an item from one do not expect it to highlight or filter another.
The speed and stability are not great, but maybe that is just our environment not being up to snuff...even though we are above the "recommended" settings.
The main GUI for a user is TERRIBLE. You log into a File Tree format where you have to navigate folders to reach the correct dashboard. There are ways around this, but it would either require an expensive payment to the Professional Services team to revamp to UI or another option they gave us was to create the "Default Dashboard" and provide that link to users and in that Dashboard, you use a new tab to include the navigation back to the main screen so that at least on the initial load the user is taken to a friendly looking dashboard instead of a file tree.
We've been very happy with Looker so far, and all teams in the organization are starting to see its value, and use it on a frequent basis. It has quickly become our accessible "source of truth" for all data/metrics.
Looker is relatively easy to use, even as it is set up. The customers for the front-end only have issues with the initial setup for looker ml creations. Other "looks" are relatively easy to set up, depending on the ETL and the data which is coming into Looker on a regular basis.
Never had to work with support for issues. Any questions we had, they would respond promptly and clearly. The one-time setup was easy, by reading documentation. If the feature is not supported, they will add a feature request. In this case, LDAP support was requested over OKTA. They are looking into it.
Looker is an off-the-shelf, free tool for Google business users. Other than the internal cost of time to build, we had no costs to set up what we needed to do. Knowledge sharing internally and using templates greatly reduced this cost, making the overall cost very low.
Our instance of iHub does not stack up against the other larger BI tools out today. It is a good place to store reports in a central location that allows users to run very specific reports on demand, but it is not a place I would want to store all of my "dashboards". As far as holding individual reports that are specific to an individual need, it is a great tool. If you want to create a report that will be used as a Template for a Form or a Label, iHub is a good choice to store and schedule the report or call it via API to generate it and return it to your calling app.
Allowing others to self-serve their own analytics and connect it to Looker simply and easily has helped unblock the central data team so they can instead focus on validated dashboards whilst stakeholders manage their day-to-day analysis themselves. Countless engineering hours have been freed up by not having to manage every user permission for each BI tool; we have a BYOBI approach; Bring Your Own BI
Creation and management of a semantic layer (LookML =Looker Modeling Language ) allows peoples sandboxes and production databases to become clutter free. Minor adjustments, conditional fields, and even some modelling can all be done in LookML which doesn't need oversight or governance from the central data team.
LookML, specifying drilldown fields and their sub-queries, as well as generally creating dynamic parameters with Liquid are all great features, but can have a steep learning curve. it may take some time to understand how to create this middle layer correctly, or even pose a risk of inheriting complex code from another source which can be unmaintainable if it becomes too big. Some level of governance is recommended if Looker is used by a large number of editors.
