This message was deleted.

One of the common problem is all services are distributed. Employees in company don't even know what all services they already have and what tools we use and all about services. Best is to use backstage as it is very easy to setup and gives value much faster. This improves new developer onboard (that helps you save money, as developer become productive faster). This helps create single pane of glass for all employees across company that in turns improve productivity. You can save time on rewriting services that can be reused as now everyone has higher visibility.

thank u!

Also looking into this now as we plan for our IDP, we have a bunch of docs right now but then are planning to spend or buy certain platforms and integrate them to have it more of a platform. How do we justify that especially as the economy tightens. The biggest spend is salary. Right now we're identifying all the costs/toil spent by developers because a solution doesnt exist to the problem. eg time spent setting up common infrastructure, time spent figuring out the golden path. bugs in production because they modified config/code which is not easy to use

@Andre Marcelo-Tanner - yeah, that’s what I am working on as well.

If this is just to manage multiple services and build a catalog, you can checkout this tool : https://www.opslevel.com/ (Never tried this tool)... Read about this somewhere in comparison to backstage. Not sure if this fits the criteria but just sharing.

Thanks Mitesh, will check it out.

@Andre Marcelo-Tanner This looks interesting. How are you able to quantify this in terms of cost?

Mitesh, yup, that ROI is what I am trying to quantify as well.

Mainly via interviewing users, but also by tracking time spent on tickets and pull requests and estimating the overall work before the developer starts coding their business logic Another metric is the time platform teams spend updating everything to a new version or patching security issues. These are the kind of problems we hope to make quicker to resolve with a platform

I am looking at it in terms of 1. improvement in time taken to complete various tasks 2. total number of operational details abstracted away from the developers 3. Improvement in service discovery 4. Improvement in MTTD and MTTR 5. Reduction in number of support tickets 6. Improvement in governance/compliance @Andre Marcelo-Tanner - anything else you can add to this?

We are also tracking time to onboard a new engineer, time to first commit, time to create a new service

Yeah, those i clubbed in under “various tasks” - if i were to elaborate, it would be • time to create a new service • time to upgrade an existing service, underlying dependencies (we have IaC, so upgrades to terraform is an example) • training is a separate one that I did not mention earlier -that would be similar to onboarding new engineer? i still need to work out how the training can be quantified in the ROI

@Andre Marcelo-Tanner how do you measure “time to onboard”?

@Daniel Serodio - taking a shot at answering your question. Who is spending time in the on-boarding: 1. Mentor/peer (single person or the entire team pitches in?) 2. New team member 3. Any other cross-functional teams (IT for example to get them set up with accounts etc) What activities are included in on-boarding: 1. Setting up accounts and permissions (IT, new member and at least one existing member may be involved if the process is not fully automated) 2. Training - is this a recorded training? 3. Creating and maintaining training content 4. Setting up labs for training, reviewing labs, etc 5. Anything else Then you measure the time taken for all these activities across all teams and sum it up.