Use Case: Customizable Build Rules
You provide a service to customers, allowing them to build complex digital artifacts. You have a set of policies that represent good practices of build discipline (for example, version numbering for included artifacts, verifying that the sub-artifacts have been properly scanned and analyzed, etc)
The Problem
This space is changing very rapidly. New types of rules are coming out very quickly. And different customers will have very different needs and concerns here - many will be happy with ‘default’ rules, but some will want to make a variety of customizations.
The Old Way
You’re pouring a tremendous amount of effort into a customizable policy system. OR you’re building an API and making the customer spend lots of time on implementing their own custom solution. New technologies keep forcing your API to change, and your customers are taking so long to implement their desired rules that they are falling behind in the market. No one is happy, except the bill-by-the-hour consultants.
The Policy as Code Way
You write up policy using a Policy as Code agent. The rules are modular, clear and easy to follow. Your system reaches out to the PaC agent as needed to verify that the rules are being followed for given artifacts. If a customer wants to change the rules, you provide them with a copy of your policies. The customer can change the rules, and upload the changed rules into their local agent.
Evaluation
Are the rules still complex and changing?
Yes. But that would happen no matter what.
Is it easier to change the rules?
Generally yes. You might have to include more information in your queries to the policy system, but it’s very likely you’d have to do that no matter what. The rules themselves will only have to change as needed to address the new requirements.
Is writing easy-to-read rules difficult?
No, not if you have sufficient practice in good software development techniques.
Do customers still have to do work to customize their solution?
Yes. But instead of complex custom infrastructure, or long waits for updates to a centrally managed policy system, they can customize the rules on a case-by-case basis. They don’t have to re-implement all of the rules, they just have to change the particular rules as required.
Do the customers have to learn a Policy language?
Yes, or they can hire an organization that is already well-versed in writing policy to implement those changes.
Result
Your time to market is faster, because you didn’t have to write an elaborate policy enforcement mechanism.
Your ability to adapt to changes in the underlying technology is faster, because you can update the rules in the policy language, instead of having to update your elaborate policy engine.
If your customers need to change the policies for their approach, they can do so quickly, without any significant investment in infrastructure.