Creating a corporate dashboard (using OData and Microsoft PowerBI)

Building a corporate dashboard so that you have key management information at a glance

(This article was first posted on 17 June 2017 on a different blog site, but migrated here 05 Feb 2018).

I have recently been building some corporate dashboards (as recommended by Daniel Priestley in his best selling book “24 Assets: Create a digital, scalable, valuable and fun business that will thrive in a fast changing world”). From chapter 15 of the book:

A key asset is a dashboard that allows the team to see how the business is performing. Carefully select some of the metrics that drive performance and make sure they show up prominently on your dashboard. You might select metrics like cash at bank, payments collected, expected invoices, revenue per employee or monthly users; the general rule is that whatever you measure will improve.

Accessing your valuable and key data

Dashboards need data, and this data will almost certainly need to come from a variety of sources in your organisation. There are lots of different ways of exposing your data sources so that the key information can be pulled into your dashboard. I reviewed several different options (including direct connections to databases, WebApi or MVC from websites and OData). My conclusion was that OData seemed the best current approach. Your data is valuable, so whatever method you use needs to be secure (i.e. with access protected via encryption and passwords) and you can do this with OData (and the other methods I have mentioned too). (Contact us if you need help with this. )


Migrating to the cloud (Microsoft Azure and Office 365)

(Posted by Patrick Lee on 22 Apr 2016 at a different location, but migrated here on 05 Feb 2018).

I thought I’d share a few thoughts from our experience of moving from Windows servers on which both our corporate and client websites and email were stored to the cloud, specifically Office 365 and Microsoft Azure.

The process itself was relatively painless (particularly for migrating email to Office 365). The only problems we experienced were in migrating some older websites, and some web-based software which, for reasons best known to its manufacturer (whose blushes I will spare by not naming here), needed to be installed as a desktop program (albeit one with a web interface). Both of these needed to be installed on a virtual machine (a windows server within the cloud) rather than as stand alone web apps (or app services as they are now known) in Azure. We also had a few teething problems moving some databases from SQL Server 2012 or 2014 to SQLAzure, but found solutions to these after a bit of experimentation.