Why business policy and IT policy-as-code is the next intersection in ERP
Moving commercial business policy forwards into the digital age requires a deeper reliance upon cloud-native automation control from the IT function. For this to happen effectively we need to form a new intersection between traditional business policy and a new breed of IT policy controls.
This is the birth of Policy-as-Code at the technology infrastructure level, an approach to system operations designed to enable IT services to work correctly, even when under severe pressure to adapt, or in the face of cybersecurity threats.
One of those IT industry terms without a definitive definition, Policy-as-Code is as perplexing as serverless computing at first, but in fact comes from the same notion of system virtualisation.
In serverless computing, there are plenty of servers all located in our chosen cloud service provider’s datacentre. We use the term to denote an application whose server allocation is decided upon only when it is actually needed. Through virtualised server provisioning we can (in theory at least) save resources and increase efficiency.
A defined set of network mechanics
Policy-as-Code stems from the same breed of virtualised system level control that has given us serverless. It enables us to stipulate a defined set of network mechanics in the form of policy rulings to govern how data services, applications and their related components and connections act in relation to compliance, operational excellence and security.
In the most basic terms, Policy-as-Code comes down to a system level evolution of ‘if, then, else’. For example: if a security alert occurs, then apply this patch or raise this warning, else (otherwise) if it has already been installed, take no further action.
Why the need for Policy-as-Code in the first place? Because as shiny as it looks on the surface, real world deployment of cloud computing has never been a perfect science. Analyst house IDC estimates that just over two thirds (67 percent) of cloud breaches are a result of misconfigured applications or instances of clunky misconfigured infrastructure.
In the modern era of Infrastructure-as-Code (IaC), one would hope for greater harmony given that IaC also leans heavily towards security best practices, but even in cloud automation, the whole process starts with a human in the loop or has human administration and management involved at some stage.
“Whether for regulatory purposes or internal business requirements, policy enforcement is now an integral part of many operations teams’ responsibilities,” says Deepak Giridharagopal, CTO at Puppet. “However, if compliance depends on human effort, it is impossible to keep up with the rapid pace of change that is inevitable within a modern IT infrastructure. This is why we need continuous compliance, which is best achieved through Policy-as-Code and applying the principle of control loops.”
If compliance depends on human effort, it is impossible to keep up with the rapid pace of change that is inevitable within a modern IT infrastructure – Deepak Giridharagopal, Puppet
What can Policy-as-Code control?
The question is, how far can Policy-as-Code go and what level of control should it be able to exert across an organisation’s IT stack? In a world of distributed IT teams working across an estate of multi-cloud services using different programming languages with different configuration protocols and techniques, all spanning varying workflow methodologies, the penetration of Policy-as-Code arguably needs to match both the diversity and security stance of the environment it is actually applied to.
By adopting Policy-as-Code, an organisation is able to lay down controls that will translate directly into system-level operations decisions. Always fairly binary in nature – there’s a right way and a wrong way, there is no middle way – Policy-as-Code lays down the law for IT decision making.
These decisions can be used to govern where and when (or indeed, if) applications and services can be exposed to external connection points via application programming interfaces. They can also govern which software protocols and code structures are permissible, or they can be used to adapt system behaviour to keep the IT stack compliant in the face of legal and regulatory compliance requirements.
Achieving continuous compliance
Giridharagopal explains how codifying technology policies as code makes them amenable to auditing, testing, sharing, reuse and peer review. This, he suggests, means that software application code can be fed to intelligent systems that can apply those rules across a fleet, not just when systems are first provisioned, but continuously for their lifetime in service.
“This enables us to progress to a point where humans can focus on the policies themselves, while software focusses on applying them and fixing any anomalies encountered in the process. For all the reasons that Infrastructure-as-Code is an indispensable part of modern systems administration, so too should Policy-as-Code be a modern fundamental,” he says.
He reminds us that given the progression point we are on today with automation, the more we can automate, the more time, cost and risk can be reduced. So, surmises the Puppet CTO, the latest generation of continuous compliance systems can also include automatic repairs of detected policy issues, such as through reconfiguration of the affected system.
Mapping down Policy-as-Code
Implementing real world Policy-as-Code deployments into a functional IT deployment involves what we can call a mapping process. Starting with a human interpretation of system rules, best practices and compliance requirements, the operational conditions that these guidelines stipulate are codified and then mapped to a state where they can be digitally interpreted and ultimately enforced.
Explaining Policy-as-Code as what he calls a “very natural extension” onward from corporate business policy, CEO of infrastructure software company Progress, Yogesh Gupta, champions this approach as a means of finally getting traditional IT policy guidelines actually implemented.
“For too long, there has been a lamentable gap between what IT policy actually represents, features and contains in any given organisation and conversely, what is physically implemented,” says Gupta. “When we work in a world with Policy-as-Code, technology policies must be both human-readable and machine-enforceable.”
When we work in a world with Policy-as-Code, technology policies must be both human-readable and machine-enforceable – Yogesh Gupta, Progress
Looking at the reality of moving organisations towards a Policy-as-Code advantage, Gupta is realistic but sanguine in the face of the challenges that firms will face across different business verticals. He says that an IT policy instruction written by software engineers that can only be interpreted by machines and other technology department employees is good, but not quite good enough. He insists that a broader instruction format is required in order for subject matter specialists, domain experts and line of business managers to be able to understand it as well.
According to a GigaOm white paper, ‘The [Policy-as-Code] space is evolving quickly and has heavy dependencies on exactly how infrastructure is provisioned and managed, along with how applications communicate. [Enterprise organisations] should consider their existing infrastructure and application development tooling roadmaps when seeking a Policy-as-Code solution to ensure it will be interoperable in the coming years.’
The as-code effect
Given the penetration of cloud computing with all its layers of virtualised and abstracted entities, this whole discussion falls in line with current approaches to AI-charged automation and IT systems that now benefit from a level of autonomous management.
From applications, to databases to complete computing fabrics, the as-code effect is penetrating every level. Logically then, a higher level policy coding process should also now come into place.
Where firms already have a customer service policy, an investment policy and a workplace behavioural conduct policy, they can now have an IT policy that features a deeper level of automated internal digital management in the form of Policy-as-Code.
Can we go any deeper than Policy-as-Code, or does this represent the internal mantle of our planet’s IT functions as we stand today? The answer for now is no, this is the base layer. But let’s not close off the wider possibility of an as-code approach evolving to be applied to something even more granular, cerebral or perhaps human.
Inevitably, we can expect You-As-Code at some stage, so make sure you remain human-readable and machine-enforceable.
