Traditional IT Governance is viewed with some level of organizational contempt by the people who are beholden to its sometimes rigid structures.  That doesn’t mean that IT Governance is the wrong choice for an on-premises solution.  Governed IT resources and employees fit well under the governance umbrella.  Teams feel disempowered and untrusted when the same concepts are subjectively enforced in Azure.  The same controls and policies that are meant to free them of active participation in concepts such as the budgets and security may not be well represented when enforced traditionally. 

In the cloud the strategies involved in operationally creating resources as you might on-premises using a trusted team through ticketing systems and validations may require that operators in Azure go through needed change control, change advisory, UAT, QA, and maintenance windows to achieve deployment goals.  This represents a total loss of agility in the cloud, and places everything behind an opaque wall.  Some of the reasons for this are around isolating concerns with developers accessing production resources in Azure. 

I have worked in an organization where our product was given a “release budget”, meaning that when our team was ready to ship to production, we had a budget that would be applied for the isolated team who released the application out to Azure.  The release budget allowed for about 3 releases per quarter.  As our team gained experience and maturity, we increased the frequency for which we shipped to “per sprint” for production, and for QA/UAT, per story.  Within the first month of our increased frequency our team has already burned through our release budget. Our team and product immediately became artificially expensive to maintain because the team was not empowered to keep moving.  As we demanded to keep releasing changes to the product, we had a lot of push-back from both the release team in a time and materials context, and our upper stages of management from a budget shortfall perspective. 

Azure has IT Governance tools which would have let us solve this problem.  We could have used isolated subscriptions, like “dev”, “test”, “uat”, and “prod” to isolate our resources to specific environments.  We could have used management groups to control those who can access the subscriptions and limit access to higher level environments like UAT and Production to service principals who could act on our behalf.  With management groups we could control more mature concepts as well, such as break glass procedures to gain more dedicated, and monitored access to higher level resources when circumstances were warranted. 

There was organizational fear around letting us codify our governance in Azure so that we could follow a better and more mature DevOps practice and enable our team to succeed.  Most of our team, feeling disempowered and unable to help grow organization maturity left what we felt was a project stuck in a traditional governance quagmire, and with not enough critical mass to carry the project forward the entire business division was sold at a loss to an organization more interested in carrying that project forward. 

Today’s fast pace world demands that teams be able to act with increasing agility and speed, InCycle has the tools and abilities to elevate you to the next level.  Download our Cloud Governance Playbook to learn more about modern governance.