Our clients are always looking for ways to improve agility. Most cannot simply “move fast and break things” because the consequences of failure can literally be life and death. On the other hand, responding too slowly to changing market conditions is also an existential threat to a business these days.
Many people assume that the primary risk of moving too quickly is the release of inferior quality products. This is certainly a concern but it can be effectively mitigated (at least in software-powered industries) with a variety of now well known agile processes and techniques. What is harder to assess and apply when moving too quickly is governance, risk, and compliance (GRC) policy.
This puts companies in a very tough spot to either:
The third option is super popular because it’s comfortable and reduces personal risk within an organization. You might get fired for choosing options 1 or 2, but option 3? Well hey, that might net you an entire org chart and budget to match! The problem of course, is that large-scale enterprise-wide efforts like this rarely succeed (I’d find a link to the study but if you’re reading this, you already know).
Platforms are excellent vehicles for transferring responsibility and risk. Amazon Web Services or Microsoft Azure are happy to take on the responsibility of running core infrastructure and services for the digital economy. Aside from SLAs, they tout their many certifications which customers inherit when using their offerings. This is a great “feature” because it transfers risk and significant costs over to them (some, not all).
Enterprises can use the same dynamic to drive platform adoption within their organizations. Adherence to internally mandated GRC policies is generally seen as a tax to individual lines of business. You’re not going to get credit for implementing them, but you’ll likely lose organizational or customer trust if you don’t.
A well thought out enterprise platform should have flexible, extensible, and fully automated features that help enforce good GRC hygiene.
Some examples we’ve helped develop in practice:
While the application of GRC policies by the platform can be scoped or consistent and shared, the development of these policies can and should always be decentralized. Successful companies allow for the authoring and application of platform level policies to be run like a good open source project with decentralized reviews, pull requests, etc. As policies are added or changed, teams that leveraged the platform automatically have their applications, data, and configuration kept up to date.
Simply by using a shared platform, enterprise developers are freed from the burden of implementing or even understanding large swaths of the enterprise GRC labyrinth. This saves time and actually lowers risk. It removes the now unnecessary tradeoff between agility and GRC controls.