We define ‘hassles’ as daily/weekly/monthly/yearly inconveniences in your work or personal life that are irritating or frustrating and prevent you spending your time more efficiently and most of all in a more enjoyable way. We even built a system to tackle these hassles, called our ‘Hasslehoff system’. We use this system to gather, prioritize and fix any hassles that are present. Since being lazy is actually considered a good treat for developers, we try tackling ‘the four D's of Robotization (Dull, Dirty, Dangerous and Dear)’ by using automation as much as possible.
Lately, we’ve been enjoying the benefits of the deployment of CI/CD (continuous integration & delivery) in our client projects, so it was about time to take a look at what we could improve in our own internal processes. Also, automation does not only prevents repetitive and somewhat boring tasks but also reduces the risk of human errors. By now it’s clear that we live by our motto: “automate once, always enjoy!”
Server less
Another trend we've been embracing for quite some time is going server less. Basically, this means that instead of maintaining complex IT infrastructures we split up our applications in micro services and make use of cloud services wherever possible.
Over the past few years, Microsoft has come a long way from forcing OS and web browsers releasing a lot of great software to the open source community for free and offering a truly impressive, complete and integrated Azure Cloud services. The pace at which Microsoft is adding services to their Azure Cloud offering is nearly impossible to keep up with.
What is better than solving your own hassles? Solving the hassles for your colleagues of course ;). One of our yearly hassles is the rapidly approaching ‘end-of-year period’.
For our finance colleagues, this means ‘inventory’ counts and the calculation of various KPI's, usually gathered manually by combining data spread across various data sources and formats in awfully large Excel sheets.
So let's see how we can apply our data-driven approach to our own financial reporting processes (which is actually a good excuse to play around with the latest Microsoft Azure services).
One of the currently hidden gems is Microsoft Flow. As Daniel Kahneman mentioned in ‘Thinking, fast and slow’, getting in the flow is our ultimate goal to achieve superhuman productivity.
Microsoft Flow allows you to connect any combination of the supported services without writing any line of code. Microsoft offers support for all kinds of services out of the box in terms of so-called ‘Connectors’ from email to Salesforce. This is enabled by first selecting a ‘trigger’ that actually starts your ‘flow’, for example, use a trigger as ‘email received'. Simply connect your office365 email by using the interface wizard. After you configured a ‘trigger’, you have to set-up an ‘action’ that follows up the 'trigger’. For example, after the ‘email received’ trigger, you can configure to add a Salesforce CRM entry. Basically, you could say it's an IFTTT.com clone, but for a developer, it's so much more in terms of flexibility and configuration.
For example, you can define multiple steps and even add conditional logic to your ‘flows’. By mixing & matching connector triggers, actions and logic you can create an (almost) infinite amount of server less applications without writing a single line of code or even ever having to worry how to maintain it in the future.
Of course, Microsoft Flow offers a broad range of flow templates that you could use or customize. Such as the ‘send notifications of the flow blog’ flow template and configuration UI as shown below.
Microsoft even released a pretty neat Flow iOS and Android app so you can easily monitor and manage your ‘flows’, wherever you are. Their native app also allows you to set up a great feature called ‘flow buttons’. Basically, it allows you to add buttons to the app which you can control to manually trigger one of your ‘flows’. For example, I use this to send out quick ‘notes to self' directly as Jira stories are coming in on my personal Jira Board.
Okay, nice! So we can now make use of ‘flow templates’. But is Microsoft Flow really versatile enough to support a real-life business scenario? Well, only one way to find out…right? For example, we need to be able to keep track of CMS modules used by our customers across various hosting infrastructures for reporting reasons.
This is one of the yearly reoccurring manual ‘inventory' count hassles we face. So I’ve set up a ‘flow’ with an HTTP Connector trigger. A few lines of code were added to create a small CMS module that posts this data as JSON object to my existing ‘flow’. As an action a Power BI connector is configured to store the JSON object which is received in a Power BI data source (the avid reader might notice that strictly speaking, the setup of a ‘flow’ was not necessary since we can HTTP POST JSON directly into Azure Power BI data sources, but that's not what we're trying to prove here).
Power BI is Microsoft's business intelligence tool that allows us to aggregate and analyze data across different data sources. In Power BI we can now generate a beautiful report of the modules used by our clients, any time of the year.
Azure logic apps
Just in case Microsoft Flow ‘no code’ approach turns out to be not flexible enough, you could always move to its ‘big brother’: Azure Logic Apps. Actually, ‘flow’ is built on top of Azure Logic Apps, and they share the same workflow designer and support the same connectors. Azure Logic Apps can be seen as a ‘pro’ version of Microsoft Flow, supporting more advanced integrations and DevOps scenarios.
Azure functions
Where Microsoft Flow and Azure Logic Apps are design-first approaches, Azure Functions is the code-first approach. So, in essence, you can host any piece of code in a server less Azure Function (well at least it's not YOUR server). You can create your Azure Functions directly from the Azure portal by choosing the type, for example, ‘timer based’.
The Azure portal offers some nice configuration options for setting up your Azure functions and connecting it to, for example, data sources. It even has a full online code editor to write, save and run your ‘function’ code. We could debate if that is something you would want to do but you can of course also write, run and even debug your Azure Function code from Visual Studio. A thing to remember is that by default Azure Functions have an execution timeout of 5 minutes.
We use Harvest for our time tracking. Although Harvest has some nice reporting features, our agile finance department wished for #nextlevel reporting this year, which is not supported by default. Instead of manually importing and exporting Harvest data every week, I wrote an Azure Timer Function that periodically checks the Harvest API for new/changed time entries and stores these JSON objects in an Azure Cosmos DB. Azure Cosmos DB is Microsoft's globally distributed, multi-model database.
We can now connect Power BI desktop to our CosmosDB data source and even combine other data sources to create #nextlevel (nearly) real-time reports and insights.
Instead of having yearly hassles between Christmas and New Year's Eve, we now have real-time insights all year long and a happy finance department! And at the same time, we had great fun playing around with: Microsoft Flow, Azure Logic Apps, Azure Functions, CosmosDB, Harvest TimeTracking API and Power BI.
The Hoff approves and so does our Finance Department ;)!