Software teams—and the internal platform they use—do not exist in a vacuum. Quite the opposite. They are often inserted into a bigger system and can rarely have complete independence from other parts of the business.
Smaller organisations may only have limited requirements, for example security and billing checks for any software that intends to reach production. Larger organisations likely need to introduce more complex structures. For example, they may verify a specific list of allowed licences in open-source software, certain regulations that need to be followed, and a set of policies that must be enforced for particular types of software.
These requirements usually result in one of the following scenarios:
Playbooks: teams around the organisation write down sets of instructions to be manually checked and verified every time a new version of the software needs to be released. Teams building software consume those playbooks and execute the steps.
Siloed automation: give a repetitive set of tasks to a group of software engineers and someone somewhere will start automating it in scripts. Different teams in the organisation will eventually codify the playbooks in scripts and add those scripts to their development process.
In both scenarios, there's a lot of waste. Following step-by-step guides is, besides being slow, very error-prone. Multiple teams writing the same set of automation is a lot of waste. If the guides and scripts are derived from policies published by other departments, a lot of teams need to stop focusing on their mission and update their own versions of the policies.
In the midst of this is the platform. Ideally, the platform provides ways where the Platform team can inject those business requirements easily, taking the automation one step further and making a single source available by default for the platform users.
A core aspiration for Kratix is to enable organisations to codify their business requirements in the Request Pipeline. The Pipeline is a series of containers that are executed in response to a new request to the platform. The containers used in a pipeline are reusable. This allows Platform teams to codify certain rules only once and apply them across all the services in the platform.
Kratix has no opinion on how the Pipelines should be written, so the Platform team is free to choose the tooling that best suits the team. Furthermore, the lifecycle of the Pipeline images can be controlled individually, making it simple to immediately apply updated policies throughout the platform. Platform teams can even off-load the responsibility of managing those images to the team responsible for the policy, like allowing the Security team to fully manage and publish the "Vulnerability Scanning" Pipeline image, used across the Platform.
Besides centralising the efforts and having a single source of truth, another advantage of codifying the business rules as a central part of the platform is that it raises the value line of the platform. Like any product, users need to see value in the platform before they decide to run their workloads on it. Removing these sets of concerns from their plate might be the nudge they need to adopt it.
This blog is the sixth in our series, The 12 Platform Challenges of Christmas. Check back daily until January 5th, 2023 for new posts!
Comments