This message was deleted.
# platform-blueprints
s
This message was deleted.
p
Most important thing is to make sure there are at-least a handful of clear pain points that are impacting the business that your team can actually completely solve for. If you are looking at golden paths for example, how often are you shipping new services, what does further automation here actually save? If its saving time for devops team but the actual devops team does not have anything higher value to do, this might not even be necessary. Likewise, can the problem at hand be solved with a template repo + ci automation + documentation. Maybe a brute force low-tech approach to solve the problem first can create clarity on whether an IDP is even required.
a
Another thing is suggest is making sure to decouple implementation from interface. What you need today will likely change. So keeping your cost of initial implementation low matters, but keeping your cost of change low is even more important.
n
For two people? • Process docs for others to follow (eg: instead of automating a flow, write it down in an easy to follow list) • Templating configs to automate initial setup and make it easy • Build tools that give people extra powers/access instead of giving people the access directly (eg, a lambda that can run a deploy, then people only need access to run that lambda)
code is expensive, docs are much cheaper, so start by writing things down adn having people follow it. For small teams, this works remarkably well and is easily updatable. Then start adding some light, reusable automation around the time consuming, tricky, or privileged bits. After about a quarter you should have a good feeling about where you should invest more (proliferation tools, sustaining engineering efforts, governance, etc..)
j
Solid feedback. Thank you, everyone 🙂