Platform engineering and compliance as code

The role of platform engineering in automated compliance solutions

Platform engineering can do more for your business than simply help you release code and create easy-to-follow deployments. You can leverage it to ensure your compliance requirements are adhered to.

When your release process becomes consistent, you can incrementally improve various components such as adding tagging to enable better cost visualisation or ensuring a base level of security on all services. You can take this further: for example, you could integrate monitoring and incident management into your platform and have incidents raised automatically, incident response channels created, automated escalations, automated resolutions and much more.

When should you consider a platform engineering approach?

Platform engineering is typically a good idea all the time. If you are in the early days and have a very small team, it may not make sense to start with this when you could get similar successes with a good individual contributor. But once you are managing multiple products on a regular basis, it starts to make a lot more sense.

Some organisations get into trouble when they begin their cloud journey because they can start off enthusiastically and, several months later, there are 30 DevOps Engineers across 30 different teams with 30 different approaches. The result is no one knows who owns what any more. Some of the core principles of platform engineering are to ensure each application or service is tagging resources consistently, and that your release, support, rollback, and scaling processes are consistent.

When you think about it, essentially your platform team are taking actions humans perform and putting constraints on them or automating them so they become consistent, much in the same way as any compliance activity would need to.

How does it ensure compliance with security, architecture and financial controls?

By having the compliance centralised and codified, you now have a repository that represents the implementation of the compliance (not just the documentation) and, unlike human computers, does not deviate so adherence is more consistent). There may be gaps initially, but these gaps will be plugged programmatically and scientifically through a continuous improvement process with provable, repeatable results, not simply asking someone in development to log a ticket, tag their instances, or even to secure their code better.

The main challenge with compliance-based activities is they are the ones that fall by the wayside quickly. This is either because they are hard to implement (so they are implemented partially or poorly) or they are deprioritised as while they mitigate future risks they also hinder the delivery of immediate value, resulting in compliance shifting to phase 2 or the bare minimum being done. This can’t happen with a platform engineering approach as it’s all or nothing. To ensure that it’s the all, and not the nothing, the platform engineering team need to consider themselves a product and ensure the barriers to adoption of their tools and services are as simple as possible to consume and that they remove or significantly reduce internal challenges such as seeking approvals.

One great example of this is logging. Everyone wants it and the ideal solutions these days include multiple systems that chunk up the logs, index them, monitor them, and give tangible feedback. These systems can take time to configure and setup, but your platform team only need to do it once so it becomes another good reason to consume the platform. The same is true of monitoring, alerting, support, and, of course, compliance.

How do you ensure adoption?

While it’s easy to think that something that is easy and takes away some pain will be easily adopted, it just is not the case. In general, people will do things that are not comfortable because they enjoy them or enjoy how it makes them feel. Take exercise as an example. Not everyone enjoys doing it but many people still do it because they understand the long-term value and eventually they end up enjoying it.

Another consideration should be around how you are allowing the engineers to have freedom. As humans, we are terrible at doing the same thing repetitively. We’re inquisitive and we enjoy creating things, not just following a process. So when designing the platform engineering approach, it is important to consider how and where a developer can express themselves and customise their solutions.

One way of achieving this is to internally open-source your platform and allow teams to extend your platform. This way, if a new tool comes along (such as serverless) it’s on your backlog but you can’t get to it, then allow the team who wants to use it to do so but they also need to help write the module for the platform team so everyone can benefit. Another is to simply allow a choice of tooling for certain tasks like configuration management.

Everything is permitted within boundaries, but the boundaries need to be clear and concise. “You can use any configuration management approach you desire as long as ….”

Dealing with edge cases

As we just mentioned there are always going to be new things and old things, and these will cause situations that do not comply with your current policy or approach. But by having permissible workarounds, you are not stifling innovation or saying “No” and instead saying “Yes, but”.

Initially keeping track of the edge cases as technical debt will help you choose what features to prioritise for those willing to wait. For those who are not willing to wait, they can always contribute as above. The net result is the whole platform for them and the organisation gets better incrementally and the overall attitude is better, with a lot more yeses and a lot fewer noes.

Conclusion

While platform engineering can be all about the automation of releases, it does not have to be and, in fact, should not be. By encouraging the compliance elements into the platform engineering product team, you are ensuring a consistent approach to it. This does not mean the platform will solve all of your compliance issues but it is one tool among others such as RPA and AI that can help ensure that compliance is more likely adhered to and more consistently.

Approach it in small steps and always give an alternative way to achieve something so it’s never a “No” and instead a “Yes but”. Encourage teams to support the platform service, to give back to the service they are consuming. This way they can take on a small increase in effort but deliver significantly more for the whole business and not just for themselves.