Azure operations can be divided into 2 categories:
Control plane (or Management plane) - used to manage resources in azure subscriptions, e.g. creation of a virtual machine or a storage account
All requests for control plane operations are sent to the Azure Resource Manager URL. For Azure global, the url is: https://management.azure.com
Data plane - used to manage capabilties exposed by instances of resource types e.g. using remote desktop protocol (RDP) to interact with a virtual machine, or reading/writing data in a storage account.
Requests for data plane operations are sent to an endpoint specific to the instance of the resource type e.g. https://myname.blob.core.windows.net
I recently read this book “Making work visible” by Dominica Degrandis which explains how to facilitate work organization by making it visual. It also nearly explains some recurrent problems which corporations overlook while designing work processes - the time thieves. The 5 time thieves prevent getting work done efficiently and can be identified (and minimized) when work is surfaced visually.
The 5 time thieves or categories of problems are:
Too much Work in Progress - this happens usually when demand exceeds the capacity of the team. Too much work in progress (WIP) leads to context switching and decreases the quality of items and things take longer to finish overall. WIP is a leading indicator of cycle time. The fact that excess demand has an impact on delivery is explained neatly by queuing theory - Little’s Law.
Agile projects come with their own challenges. While the tech industry has increasingly adopted agile, practical experience about agile methods is not always available. Certain consultancies and third parties have made roaring business out of the agile coaching usually solicited by corporations while embarking on agile transformations. In many cases, the corporations did not have a system of follow-up and in others the consultants did not help adapt the frameworks to the specific case at hand. In the end, teams end up without understanding the agile values and “whys” of using agile and focus on ceremonies like the stand up meeting or having a kanban board. Along with misconceptions and lack of clarity about the methods to be worked with, these are some of the main reasons I’ve seen agile projects fail.
Microsoft has been instrumental in pushing the envelope on managed self-service BI with it’s Power BI SaaS platform. I wrote about this back in 2009 [1], when Microsoft was working on Project Gemini (later PowerPivot) used SQL Server Analysis Services as an in-memory engine, with data compression to really bring BI to the masses, so to speak. Since then, Microsoft’s vision of self-service BI evolved from providing Excel plug-ins viz. PowerPivot, Data Explorer (later renamed PowerQuery) and sharing bulky Excel files on SharePoint (with Power View [2]) to a manageable managed-self-service BI with the launch of Power BI in 2015. Today, Power BI is powered by Azure, and deployed as a SaaS across datacenters in Microsoft regions across the world.
Agile planning is different from predictive planning done in traditional project management. Often we come across posts by certain agile evangelists who claim that agile doesn’t need planning. To believe these claims would mean there would be endless iterations with a fully-funded product development team to get to a perfect end-state without concern for time or cost. This is utopian and untrue. Usually these claims are made by developers or people far removed from business. No business runs without planning or without any estimates of how much a product/service would cost. Agile projects also plan.The difference is in the planning.
