Platforms usually start as an experiment. “What would it be if we group these and these features used by so many teams in this one common platform?”
Needless to say, they don’t look very pretty in the beginning, most likely hacked through during an internal hackathon or during the spare time of one or a few enthusiastic developers. Also needless to say, they don’t have much automation in place.
Automation comes out of emerging patterns while the platform is being built, ran and used for a while. Struggle points for the users or repeated actions required for the platform team are some of the common sources of inspiration for automation. But in the beginning, you don’t really know what those are (except the obvious ones). So investing a lot of time in automating potentially useful things without the platform not getting any usage doesn’t make a lot of sense (again, except the basic obvious use cases).
This doesn’t mean you cannot prepare for upcoming currently-unknown automation use-cases. Even though you don’t have a clear picture of what you will need to automate in the future, you should still invest in a good foundation for automation before launching the platform widely. Otherwise, you will never get the time to do it.
In my view, there are 2 areas that such a foundation should be build around:
- Usage information
- Automation technical setup
Usage information
If you don’t know how your users are using your platform, how can you know how to prioritize the different features to automate? How would you know which features are most used? Which issues occur the most?
On a small scale, you could get this information manually through direct communication with your users, but doing only this will stop scaling quickly.
A few idea of what a platform team could do around this are:
- Implement basic tracking of user interaction - a simple event logged in a database, no fancy stuff
- Create a self-service catalog where your users can request themselves the different services from your platform - even if many of those are still handled manually and the catalog is just creating a ticket in your support backlog, you are getting usage information of your features for free
- Embed some kind of interface that asks users for feedback when they perform certain operations (if your platform has some kind of UI) or have a bot reaching out to users asking for feedback in certain situations.
All of these are important not only for prioritizing what to automate next, but also for knowing how to prioritize any kind of improvements and fixes on the platform. They don’t have to be implemented perfectly, even something very basic can go a very long way.
Automation technical setup
This is a huge topic, so I will just mention it here. It is about making some early decisions on what technologies to use for automation and setting them up. Decide on pipelines, scripting language, notifications and any other tooling, aspect and guideline that would be used when automating. You want to be ready to automate when the need comes and then you might not have the time to make all these decisions. They will likely change along the way, but having this starting point will be useful later on.