Shouldn't Software Governance Practices be more Descriptive than Prescriptive?

In the current world of DevOps, Continuous Delivery, Microservices, and PaaS many organizations want to know how Software Governance practices and requirements fit.  Some of this comes from a regulatory perspective, ensuring compliance (e.g HIPAA/PHI, SOX, PCI) and auditing requirements are met.  Another perspective focuses on existing technology standards, design practices, and application architecture.  At the same time developers and teams are being told to be more agile, adaptable, and self-directed.  How do we achieve the latter while mitigating the risks associated with the former?

I would argue that a "Descriptive" approach to Software Governance is required.  In my perfect world, Solution Architectures are monitored for exception as they progress through the delivery process.  The technical underpinnings of systems, in terms of infrastructure and software, are "described" in code and configuration that can be easily audited against established policies.  The runtime implementation of a particular solution is then transparent to all interested parties.  In many ways, this is just an extension of Open Source practices to the delivered solutions and systems themselves.

Pie in the sky you say?  I know of several organizations in the health care and financial services industry that have at least pieces of this in place, where infrastructure or applications will be pulled from production in real-time that don't meet defined governance policies.  To achieve this result, policies must be clearly designed and understood, then proactively put into practice during delivery.  One of the key benefits is that the focus during delivery is exception management, driving identification and resolution as far forward in the process as possible.  Isn't this just like what Agile/Continuous Software Delivery practices already advocate?

A good way to get started in this direction is to put even a basic Enterprise Architecture framework in place, that again describes not prescribes, the patterns and organization of solutions and systems delivered.  Once that is in place, focus can be given to the areas where the most risks or opportunities exist that would benefit from more consistent governance.   Here's an example that one of my mentors developed, and I have continued to use and refine:

It uses a Zoning/Planning Commission metaphor to begin to describe solutions by Zone, identifies how Zones can/should interact with one another, and provides a basis for defining supporting policies.  Visualizations of solutions that describe how they match up against the defined governance at runtime is key.  The idea that teams will keep static documentation updated that can be truly audited is at best quaint.  The challenge is that there is no "universal governance and reporting" solution out there.  Integration of existing and in-house developed solutions are needed, as is why Open Source and supporting Standards will play a big role in organizations that want to see the benefits of Descriptive Software Governance.