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
MS SharePoint / SQL
Score 8.0 out of 10
N/A
MS SharePoint / SQL refers to Microsoft Sharepoint, a web-based collaborative platform, being used in tandem with Microsoft SQL Server to provide business intelligence analytics and reporting. They can provide BI content such as data connections, reports, scorecards, dashboards, and more.
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).
A simple and important scenario well suited is that you can configure alerts to notify you when the production server fails. another best feature is the report server is the central component of reporting services. For me something less appropriate is that the admin must ensure optimal performance for farm operations, they recommend that you install SQL Server on a dedicated server that does not run other farm roles and does not host databases for other applications.
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
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.
This was a long-term buy-in from a corporate perspective, to remain in the SharePoint space. Migration is certainly possible, which is good for planning and having options further out. At this point, the only planned migration is to eventually move the architecture up to SharePoint/SQL 2013. At that point, we will be able to leverage some greater efficiencies, some enhanced content design and management features, and some more current social features. It is well worth a full consideration in any shop looking at a new implementation of or migration to SharePoint (although you will probably be considering 2013 versions or beyond in those discussions), but the platform should be a strong competitor to any alternatives. Realizing the capability of a fully-branded and customized website was not part of the original choice for the architecture at Lincoln, but seeing it implemented and functioning now with this capacity far beyond original expectations has certainly cemented plans to continue using it.
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.
SharePoint is very complex. This makes usability somewhat difficult from an IT perspective. An IT generalist will be able to pick it up and run with basic tasks. More customized functions would require significant specialized training and therefore limit what a standard user would be able to achieve. From an end user perspective, it's pretty straightforward to use.
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.
It's been fantastic in terms of Premier Support so far. If there is an issue and if you report if the product has an issue, they will act upon it immediately. In some cases, if you design/develop something using the platform, Microsoft appreciates it and... publishes it on their public website. But you have to wait for some time if it is a non-Premier Support issue as you may experience delays.
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.
At the time of the two large projects, SharePoint was the enterprise solution so we were required to use that. We have since lobbied the enterprise teams to review and consider Atlassian Confluence and were successful. Confluence is cheaper than Sharepoint which is why we wanted to bring that in. The enterprise has now made Confluence an enterprise solution as an alternative to SharePoint. After using both I think SharePoint has many more add-ins than Confluence. It has much more customization ability than Confluence. SharePoint is not good for mobile readiness. Confluence is so there is a difference that might lead you to Confluence over SharePoint. I would also say that SharePoint is very document-centric and that Confluence has better KM than SharePoint does. even with the use of SQL Server. We were told that we could not use Google Drive even though it had features we liked.
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.
I've installed SharePoint in many different industries and each industry has seen greater collaboration among their teams both locally and nationally. The ability to collaborate more efficiently has reduced the need to have employees centrally located.
Companies which have used SharePoint in a end user training portal have had great ROI, since they can create the content once and share with all their users who subscribe to their training service. The web content management aspect of SharePoint is a very helpful feature.
