Policy-as-Code might represent a paradigm shift in enterprise software development
When I first learned about Policy-as-Code, I was under the impression it was all about policing your Infrastructure-as-Code deployments.
Later, I realized it could be used to help mitigate some of the complexities involved in compliance and compliance audits.
Someone used Policy-as-Code to build out a loan approval rules engine.
More recently, I was introduced to the concept that it has value in implementing Zero Trust architectures.
And then the other day, someone in a heavily regulated industry described a use case where they want to use Policy-as-Code to implement a “Policy Brain” (for lack of a better term) - basically a centrally managed set of regulatory behaviors that all of the organization’s services and applications should honor.
These use cases are all quite different from each other. Which is somewhat unusual for new technology. So I started thinking about why this was the case. What makes Policy-as-Code potentially so different from other frameworks I’ve worked with in the past?
Note: if you’re not familiar with Policy-as-Code, this is not the article with which to start. I suggest:
What is Policy?
The first step was to think deeply about the concept of policy, in terms of software. What is a policy? How is a policy different from other things in the software space?
What I eventually concluded was: In the context of software, the definition of “policy” is extremely broad.
It isn’t just about ‘regulations’. If that was the case, much of the IaC policy rules wouldn’t make sense. And it isn’t just about security - since security has nothing to do with loan approvals. Realistically, policy encompasses all sorts of rules - security , corporate , legal , compliance , process. Eventually I came to the conclusion that “software-implemented policy” was a fairly significant subset of the general concept of “software-implemented business logic”
Business Logic in Enterprise Software
I’ve worked most of my life in enterprise software development. There are two common kinds of enterprise software1 - software that provides services to customers, and software that provides services that help the enterprise function efficiently. I’ve worked on both, in a lot of different programming languages, on a lot of different platforms, in quite a few domains. One thing that has been consistent in all of this is that developing this software requires the implementation of a significant amount of policy. And, just as importantly, a significant fraction of the testing of the software was focused on ensuring that the software implemented the policies correctly.
Which raises the question: Does it make sense to use a Policy-as-Code solution to implement some of this business logic?
Note: I am emphatically not saying *all* of the business logic should be considered a candidate for Policy-as-Code. Just *some*.
Candidate Business Logic
What kinds of business logic might be effectively implemented with Policy-as-Code?
Security
Authorization / Access Control
Logic that changes frequently
Logic that is implemented in multiple ways
SaaS “Modding”
Third-Party Componentization
Auditability
We’ll discuss each of these in turn.
Security
Security is famously hard to get right, and it often requires dedicated experts to implement it effectively (if you can’t use libraries). Certainly PaC isn’t going to address all security-related problems, but consider problems like: “We have to use a certain hashing algorithm consistently across all of our systems”, or “We need to generate and validate JWTs consistently across all of our services”. Problems like these might benefit from having a Policy-as-Code style implementation strategy.
Another potential benefit of using PaC is in the management of confidential information (shared secrets, private keys, etc). While there are systems that can hide this from the software developers until the moment the calculations need to be made, there’s a risk (perhaps small) that the developers might be able to copy the confidential information. If the calculations are done inside a Policy-as-Code agent, the application developers will never have access to it in the first place.
Authorization / Access Control
Policy-Based Access Control is one of the more famous uses of Policy-as-Code. Having a central, consistent-yet-flexible way to make decisions about access is clearly of value to many organizations. It allows access policy to change without having to rewrite the applications, and it provides valuable audit / compliance benefits. It allows for interesting edge cases or sophisticated rules, without having to implement the rules in the application code2. It is also easier to manage than Role-Based Access Control, especially as the number of resources, and the corresponding number of roles starts to grow.
Logic that changes frequently
Consider sales tax calculations, climate-related regulations, or chemical-related regulations (pharmaceuticals, illegal drug precursors, etc). These are just some examples of areas where regulatory changes happen fairly frequently. If you’re working in such an area, you might save yourself time and energy by implementing the logic in a Policy-as-Code framework. In this model, teams can focus on implementing the overall software solution(s), while a different team can focus on keeping the software in compliance with the regulations. The best benefit - these teams generally don’t have strong dependencies on each other, so they don’t become bottlenecks for each other, even when things change. Imagine a situation where the laws in your province or state changes, and updating the policies doesn’t require fighting for a slot in the upcoming application release cycle.
Logic that is implemented in multiple ways
The movement to allow teams to implement APIs in whatever language they prefer has been an interesting one. It has a lot of benefits, but it has potential drawbacks as well. One of those is the consistent implementation of business rules across all of the different implementations. A separately-managed Policy-as-Code implementation can be used in every API implementation, regardless of what language it is implemented in, or what platform it is using. This also has a significant impact on testing - instead of each team having to test the same business logic in their own implementation, one Policy-as-Code testing team can verify the correctness, and the separate API implementations just use the common code.
Software-as-a-Service “Modding”
Most everyone who has played a PC game has probably encountered mods: the careful modifications to a game to change the way it works in both minor and major ways. Often using a separate language (such as Lua), and with a certain amount of cooperative design work from the original game designer, it opens the game’s architecture and allows enthusiasts to change the logic in various ways.
I now assert the argument that in the Software-as-a-Service world, Policy-as-Code infrastructure can provide an analogous capability. If the SaaS provider is thoughtful about deferring certain types of decisions to a PaC agent, it opens up the possibilities that the customer can adapt the PaC logic in certain limited ways. Two specific benefits come to mind:
Access Control
Support for a customer’s “rigid” business logic
Access Control
In the SaaS world, as a customer, I’ve run into a consistent problem - none of these offerings implement access control in a way that is well-aligned to my organization’s structure. Sometimes it’s a minor annoyance. But sometimes it isn’t. It stands to reason that every organization struggles with this, in their own unique way.
It’s clearly possible for SaaS provider to use Policy-as-Code to implement their access. Once that’s in place, it’s straightforward to “federate” the access policy, and allow each customer to implement access policy according to their own organizational model.
Rigid Business Logic
Many larger enterprises have various business processes that have become hardened from years (or decades) of continuous use. The way an organization manages accounting and financial records, for instance. Using a Policy-as-Code framework, the SaaS provider can create a ‘default’ mechanism for calculating and organizing certain types of business data (primarily the ones that are heavily customer-facing). This then allows the customer to potentially reorganize or recalculate those calculations as required to align with their internal business processes.
Ultimately, this would allow customers to “modify” the behavior of the SaaS product in a safe and isolated manner.
Note: This is not a ‘turn it on tomorrow’ type of initiative. This will take some time and thought to get right. But it is possible with Policy-as-Code, in a way that would be difficult using the ‘normal’ approach.
Third-Party Componentization
Componentization was considered a potential paradigm shift in software development back in the ‘80s and ‘90s . This didn’t really happen, for a variety of reasons (versioning, obscurity, potential for complicated network requirements, etc.) Using a Policy-as-Code model potential mitigates some of those concerns. For example, a component implemented via Policy-as-Code doesn’t need to be implemented in multiple languages, it isn’t implemented as a hard-to-read compiled library, and it can be relatively easily integrated into your current network architecture.
Auditability
When teams are implementing software in many different ways, your ability to properly audit that the software is making the correct regulatory decisions can be exceptionally difficult. Policy-as-Code solutions centralize those decision logs, and improve the consistency of those logs as well.
Paradigm Shift?
Could this be a new way to write Enterprise software? I’m pretty sure that Policy-as-Code opens up some new ways to develop software that weren’t really around before:
Before PaC, it was complicated and time-consuming to set up a server that could perform dedicated logic. With PaC, the server (agent) is readily available and proven to be robust. All that you need to focus on is getting the logic correct.
Before PaC, standalone services often required a tremendous amount of architectural sophistication to get right. With PaC, the agents are small, easy to deploy, and easy to manage.
Before PaC, it was basically impossible to consider allowing customers to change the behavior of a third-party system. With PaC, this becomes a possibility.
To me, the fact that these things were basically extremely difficult before, and are now more achievable, strikes me as an indicator that yes (shocking, I know), in certain types of software development, this could represent a better way to design and implement that software.
Isn’t this just a rules engine?
I’m sure that this has occurred to many readers. And technically, this is correct3. In my experience, most rules engines are centrally managed behemoths, optimized for allowing business users to properly describe their business processes. If you need a graphical tool to map out business processes, I don’t think a Policy-as-Code solution is (necessarily) correct. That may change in time (for example, PlainID offers a graphical front-end to a Policy-Based Access Control system). If you have more narrowly-focused business logic, which needs to be highly performant, the Policy-as-Code paradigm of small, distributed agents is a better fit.
Arguments against my assertion
Even with the agents being ‘nearby’, they may still impede performance enough to represent an unacceptable additional delay.
If you’re only implementing things in one language/platform, migrating logic to a Policy-as-Code agent is just moving stuff around.
The implementation of Customer-modded Software-as-a-Service might be so messy and complicated that it is a non-starter.
The addition of policy agents might make the system architecture, or the development/testing process (or both) too complicated, wiping out any time/effort benefit from isolating the policy logic.
These are all fair concerns. I would expect that practice, rigor and shared experiences will help identify how these issues can be mitigated.
Summary
There are several potential real-world benefits in orienting your thinking towards a Policy-as-Code implementation model:
One (tested) implementation instead of many.
Allows experts (in all the various domains) to focus on doing their part well.
Flexible implementation based on customer’s (internal and/or external) needs.
Consistency (in logic and operations).
These benefits could save your organization time and money, in the following ways:
Fewer implementations of the same logic.
Dedicated expert teams allow for faster implementations (both of the policy and the infrastructure).
(SaaS) Customer-driven implementations reduce the demand on your internal teams to make custom changes.
Can outsource complicated rule implementations, while still maintaining code oversight.
Less demand on your development team(s) during audits.
Reduced risk of confidential information being compromised.
If you’re a software architect/development manager/director/etc, and you find yourself frustrated because you’re running into any of the problems I’ve described above, perhaps this would be a good opportunity to explore using Policy-as-Code to attack the problem in a new way.
Feedback?
Thank you for getting this far. I appreciate it. Want to explore these concepts further? Disagree completely with my assertion? We would love to hear from you at: info@paclabs.io
There are also research/experimental projects, and employee-oriented projects that are only tangentially related to organizational efficiency
Example: Car salespeople with less than 1 year of experience can’t sell expensive cars w/out management approval, except on weekends or holidays
The best kind of correct!