 Good morning everyone. Welcome to our session. Today we are going to talk about our journey into the developer experience My name is Ravi. I currently work at US Bank I lead the API engineering team and developer experience team and I'm here with Poonam my colleague Poonam Welcome to our session as Ravi said and thank you for Ravi passing me along So my name is Poonam Kirk and I'm currently a vice president engineering leader within US Bank And I carry a 15 years of experience and I lead a DevOps team within US Bank I'm a speaker at multiple conferences, which includes open source North and Grace Harper In addition to that I'm a here I'm a community leader of the WIT network, which is founded by the Microsoft and I'm a huge technical advocate for open source technologies and tools and clouds DevOps practices In addition to that I hold a technical membership for IEEE senior member plus BCS fellow Little bit about us Yes, bank. We are the fifth largest bank. We operate globally. We have offices in US Canada and Europe We are heavily regulated industry. You all know that finance industry is one of the heavily regulated industry and at US Bank We are all about Empowering people and to reach their potential and this is the journey How we are trying to empower our developer internally to reach their potential This is all about the developer experience how we empower our internal developers to reach the potential Thank You Ravi. So before I we jump into this Happy Diwali to those who celebrated today and happy Hello in advance and let us know in our Q&A. Is it a trick or treat for you guys? So so here is a thing is like we started this journey as a I think like three or four years back with the mission is like make it easier to create and manage best-of-class software products and And how we started like we were a technical head of the leader and we Questioned ourselves like whom should we take care first and the one thing which stood out immediately is our engineers that we care most Now question is why because in the past three years or four years I miss I say that we have seen that like we have huge talented engineers and Developers that comes with all skills But where did come but when they are building a solutions for us They come across so many challenges that we will see into the next slide What are those and so that's where they struggles with it and in addition to that we all witnessed COVID-19 was there so it adds more complexity to it and I believe most of you felt the same like what we felt So here are as we stated in a previous slide like we put our people first That's where our mission started and now questions are what are common engineering challenges and as we all know there are thousands of different technologies systems and applications are available for business and Integrating the third-party systems or custom applications such as your ERP or through using APIs add Substantial complexity to your project and which even and the bigger challenge for these integrating third parties are They are not even they never they are hidden during the start of your software development process They always be visible when it is their end and that leads to what extra cost compromised quality plus sometimes even entire failure of the project and the question is how So these are the various forms that you have been witnessed in your space They comes in terms of process as an onboarding these tools Plus adding certain rules and regulations which ties back to your as compliance and which term as a frictions to our engineer and our engineers cannot focus to a single task and material and they eventually become Overwhelmed and that's where it is they their experiences unhappy now within our space we kind of sit back and try to We tried list out all those common engineering challenges and divided these challenges into a two-bucket overall One is technology bucket another one is a culture bucket. So you might see these two goes By parallel together. They are intervening. So so for example savory lack of centralized technology and services and Registry which slows down our onboarding process and sometimes it compromise our quality At the same time if you see that limited feature in approved enterprise tools hinders development it against ties back to our culture that calls that technology silos and which immediately bubbles up at as a duplicate effort across in our sub-arts So, okay, you know, you might say that like, okay, you guys have these challenges Frictions, etc. Etc. We just know it. So what did you do? So as an engineering leader, we tried first Okay, let's build out a custom how custom develop solution. So we build really a custom based solution It uses an add it uses the template based approach and it supports multiple languages and it does have fully integrated Dev Ops pipeline and that and it really helps our engineers in terms of building a innovation So they they can focus on to building a solution for our problem rather than going with those onboarding processes and other thing is the The other thing is like it is provides the uniform adoptions of languages in tools that we are using in our bank But it comes with some opportunities like when we build this application. We just care about CLI personas so we care about, okay, you know, let's build this tool Let's figure it about like come come online user interface So it just it just currently supports CLI and rest of the personas are still work in progress It lacks little bit application inside. We have it, but it is not fully integrated. We try to add compliance and security still it's a work in progress and One thing that I would like to call it out here It is a complex solution because when we build this application we build this application on towards one of the Commonly used language who's language that you might all use Java and plus additionally we use that plug Eclipse start vertex plug-in which is which supports to only I believe like Ruby Kotlin and other languages Not entire language tool that we were looking for so that's where we say like it's a very complex solution It's hard to maintain and scale So what is the outcome then we build this with this as we see as a Entire organization like what we achieved with this building this tool So there are certain wins once first win is like we try to empower our engineers with the mindset of like Okay having innovation. Secondly, we have this automation piece. That's awesome. We try we give a leverage to our engineers to adoption of new technologies plus we try to Bring all of those integrated third-party components into a central place So that's one of the way like we have adopted new technology We adopt centralized piece and we bring the uniformity within our back, but there are certain opportunities So opportunities are we have still some places for other part other third-party components like manual process Then we as I call it out the user experience is just only for CLI not other personas still there is an improvement over centralized technology and removing the technology silos and Insight and compliance were there But it's not fully developed and we need to bring the standardization overall to entire organization in terms of using tools So this is the engineering development No, so this is how our journey is and no matter how big or small and Solving a software development Challenges never comes easy from challenges in requirements to integrating the new tools in technology from ensuring end-to-end securities in and To challenges of duplicating efforts software product development Requires you to be clear and stay focused what you have set out to solve in order to achieve What do you have set out for your mission? That's what it is and now I'm gonna pass to Ravi Thank you, Poonam With what we learned from the our internal experience. We looked at it. What is the real problem? We have we want to provide it wells Tooling for the developer. We want to solve the developer experience at the end-to-end So we in the beginning of the year We looked around what is the thing that is missing from the our internal experience? So that's where we come away. We want to provide a single-pane glass experience to reduce the cognitive load and make it easy the goal is make it easy for the developer as Backstay says happy developer happy outcomes So we kind of looked into Our problem area into three different buckets one is How do we help developers to create and manage solutions? How do they make the solutions faster creates faster and the other bucket is kind of discovering We have a kind of little bit challenge. We have multiple different Catalogging tools we want to bring all of them together to make it easy to discover and to Encourage the reuse across the teams and the last one but very important We are very highly regulated industry We want to provide a tool that will provide a lot of insights about the application It may be for the developer. It may be for the manager It and it is for the auditors and compliance teams because that's the biggest factor in our industry and When we took this holistic approach, we we haven't stopped at the developer Persona we looked at the fullest spectrum of things that we have to do So we looked at the developer persona. We looked at the managers. They have to manage the team effectively we looked at the Compliance and risk factor, which is very huge and audits are very huge We because we are globally we are audited by many many different government entities So audit is a big thing We want to solve that also because at the end of the day developers journey won't stop at coding It's goes beyond so that's where we we want to build a holistic approach So now we are at the crossroads of what we do We learn something with our new tool internal tool We like what we saw but we still discovered few factors there So then we kind of looking at what we need to do either we want to extend one of our internal tool or whether we want to create new from the scratch and Whether we need to buy something out commercially available. That's where we kind of saw backstage Backstage and this is where I will show how we are using backstage. We started our journey with the backstage We saw there is a natural match with what we are looking for and what is backstage was offering to us So but we are still skeptical so that's where I want to give a big shout out to Francisco and Carl here from the American Airlines We had a great conversation with him and we saw what they did with the backstage and also we had conversation with a couple of Spotify team members from the backstage. That's where we thought okay This is the right approach that we can use the backstage where it has a mix of things like where you can implement your own stuff extend with the plugins and adopt quickly So from here, I will show how we are going. We are using the backstage in our journey As I said, this is a journey. We are still into the journey. We are in the very early stage, but we are accelerating very fast So the main bucket that we want to solve was create and manage we want to make it easy so With the new technologies coming day in and day out It's always challenging and we want to end being a regulator industry We want to have the application create and follow certain standards so that we will meet meet our regulatory standards That's where we want to use that create and manage feature we want to provide and We kind of solve this using the two features of the backstage one is the Templating feature software template. That's where we created some of the templates and this is a space where When we presented that internally to our organization, there was a lot of excitement in the house and Lot of teams they came forward and they want to create more and more plugins. So this one actually accelerated our Inner sourcing model also. I have here my colleague, Martel There they their team is also adopting this to build more templates and the other one is It's common quite common that Day-to-day you need to navigate through multiple systems a developer or a manager. You need to look at your like Tickets in the service now. You may need to look at your issues in the JIRA You may need to look at so we want to bring everything So if I go back our goal was to make it easy and provide a single-paying gas experience So we are creating a dashboard where the developers or managers are any persona based on the persona You will render the information where they can easily look at the system and the status That could be their outstanding trainings or any security kind of thing So this is a great place where they can land here and they can navigate from here If they have to take any actions into it The next one is Discovery is very important like you need to know what you have in your organization and having a Multiple cataloging systems. We have catalog for applications. We have catalog for APIs We have another catalog for the libraries So we want to bring all of all these things into a single place Where you have a centralized view of what you have in the organization so that you can extend the Reusability across the team and the sharing the information and This is our catalog information. We right now what we are doing is we are first Bringing all the three different catalog system into a single Source kind of thing where you can discover more information and the Last one I said it's not last in the priority But it is very important like insights as I said having your catalog cataloging your item is okay But you need to know the real fact about your application. That's about the insights so we want to make it easy to get the application insights and Catalog is the best place we saw like we want to extend Providing CACID status. We want to provide the application vulnerability is bringing from various systems We have a lot of code scans happen static dynamic and all those things We want to bring everything so that they can drill down into each application how the application health is going on and that is very helpful for many many reasons like we all know that and Another factory is the big thing about is technical documentation It's common in any organization probably name it you have multiple ways you can document your Application like you have a code in your repository and your documentation may be in the SharePoint Maybe in wiki or somewhere else and what happens and what we saw is even though The developers maintain properly. There is always a gap between what your code is doing and what your documentation is so we want to bring the culture of a document as a code and That's where we are using the tech doc plugin to bring technical documentation into a central place and To put it all together. This is our view of that we are doing we we are right now tackling the Main pillars like a technical documentation We are software templates cataloging and we are still working on our insights part of it If you look at this this architecture at the center We have the backstage and it is connecting to the various other systems and also you can see We have another we are building a centralized Asset systems and risk and vulnerability Database and insights database. We are bringing all of them into the backstage to show as a single point single pane glass experience and So with that What we are getting out of it? fewer individual systems day to day you can probably rely on backstage or Our solution developer experience solution so that you can manage your day to day work with fewer systems and consistent user experience Whether it is a developer experience or the management or the auditor they all go to the same place They all look at the same information. It's provide the reliability of the information and Automation and standardization. That's where the tech doc Sorry templates will help us to automate our application creation with a standard way of doing so that we can trust that the applications that are built use following the standards and the secure methods and All in all also onboarding. It is easy to onboard So it solves our challenge of onboarding an application from weeks to probably in a couple of hours you will have with the template we want to enable the developers to have a starter application to deploy within no time and All in all easier access of information and the other thing is self service So we still evolving in the self service area where you can probably trigger your CACD pipeline or you want to create your cloud resources those kind of things We are still evolving that space, but our goal is to provide the self service so This is how backstage helped us to take our goal and mission or dream whatever you say to help us with a cataloging features and template and tech docs and the other like a lot of open source to tooling available our plugins. They are helping us to Make our reality our goal as a reality with that I will pass it on to Puno. Okay, so as you all know, we are still in this journey. We are still improvising our tool So we are hiding and please join us in this journey. That's what I'm gonna welcome you all We love it. We love it to me. Yeah. So, okay. So my question and answer is is it a trick or treat for you guys? Yeah, you're making me around today Hello, this is Rodrigo. Thank you very much for presenting my question is for This implementation like how big is your team and the skills required to manage deploy the system? That's a good question. How big is the team? So when we started we started with one person and now we are Roughly around the seven to eight. It depends on how you count it. We include in the product manager I'm the technical manager for that and we are still expanding So my team is a core team that is will take care of the platform the internal developer platform And the way we are looking at is we are Going in the inner sourcing model so that any other team can contribute to that. So that's how we are so evolving Hope to answer see your question Just a follow-up what experience is needed to like how much knowledge that you need on backstage? So backstage how much dollars so that we That's a tricky question. So we started looking at the backstage last year. Actually, we We kind of we have one cataloging system that we catalog for API is my team managers So we want to kind of looking at alternatives. That's where we started looking at the backstage You need to understand the backstage philosophy because the core skills I think no JS react and typescript is a core skills But you need to understand the ecosystem and how to use your backstage backstage is a tool Like you need to understand deep if you are going into full blown and there will be a small learning crowd I won't say small there will be a good learning car to understand What fits best to your organization, right? Someone can start with a simple one tech doc to give a quick thing quick wing And if you are going into a deep cataloging, maybe that's a bigger area I would say that requires more attention and Scaffolding I think it's a relatively easy to adopt So if anyone trying to start small, maybe I will say start with the scaffolding that we actually that will provide a lot of Value and next one is tech doc then you can venture into the catalogs I'm my team is the first user of Backstage in US Bank and just to put in context, right? so I have a seven engineers and It took us we thought that discovery wise on on how to look how you know what backstage is Because at first I I didn't trust Ravi on what he was saying But but we said that now we have to see it, right? so we went to all the documents and everything and and I gave my team like one sprint our one sprint is one week and It didn't take a while for them to really learn it because the following week Someone was pinging me saying at Murrell. I I've got to show you this and Well, can it not wait and he said he was just so excited that he was able to create a UI in Backstage and that is really awesome for for the engineers themselves. So I just want to share that Yeah, exactly. I echo what my toes is don't trust Ravi So because my team also uses just a one person and he was just like okay I want to explore backstage because we already have this in house app. It matches what we are doing So I was like, okay, go ahead and within I think like a couple of hours. He was like, you know what? Pune it's nothing It's like you and I can go and just do it and as you are asking for experience for the position that we are looking if you are Really curious to learn and new learning new technologies and tools. We are not looking for back to the experience So, that's what I'm gonna say that like if you are very curious to learn new tools and technology and contributing back to this big community of the backstage And we are ready to hire you. That's what I'm gonna say Can I can I ask another question? So Talking with many Adopters or people interested in backstage Especially in highly regulated sectors like you represent, of course and there are Believe me lots of banks, but also in the pharmaceutical insurance one of the most recurrent question is okay, how We can deal with highly regulated sector and all the constraints that we have in terms of security processes and I mean this kind of tool that for example as part of Spotify we use in a very open Manner because we don't have any constraint everyone can do almost everything. There is a completely different philosophy So it would be very very interesting for me to hear what's your experience of being a Great example of a highly regulated sector. How did you manage the challenge? How do you manage to make it work in your environment because I'm pretty sure it will help a lot of people here in the room and not only in the room Yeah how we so it's Initially, it was a lot of Like we even don't know whether this is the right tool and whether when we pitch this idea to our management and Executives we don't know whether this will fly in but The way we were We approach this one is actually it complements what we are trying to do or it will help in the regulatory industries That's where I was talking about Providing a standard way of building application. You are guaranteeing that right now I was talking to one of other my colleague. He is saying that yeah, they they hide a lot of engineers because of the new feature and each one is building their microservice in a different way and That's where it solves all right if you are talking about the regulations and all those kind of things If you create your template in a standard way and if you add all your bells and whistles That's where it helps in that regulatory environment You are guaranteed or rather you are making sure that the applications that are building is following the best Standards, of course, it will not come easy Some of the regulator that's where we have like we are We have other ways we collect the evidence and we show the evidence of how this is all happening under the knee In the backstage of it more questions This is my first speaking engagement And And we want to give it back like I said I really appreciate Carl here He spent a lot of time with us Explaining their solution and I will highly recommend you all to go to the YouTube and search for American Airlines backstage implementation That's must watch if you are getting into the backstage. Thank you call. I appreciate what you do I'm Sorry Thank you so much for presenting. This is really helpful and I've been a similar situation I think as you are in an in a regulated industry You mentioned in terms of adoption you mentioned how you guys have software templates that you're defining in terms of the organization that you're in how much traction have you got in defining and not what you feel like is enough and How much more do you have you mentioned inner sourcing? Are you are you able to get teams to contribute to get engaged? Yeah, so from the couple of things I want to mention so as poonum initially mentioned the in-house tool that's her team was initially managing that one and actually we are replacing you inner sourcing not inner sourcing the In-house built template tool of course that The inner sourcing it's all depends on what is the mindset of the organization? So if you ask me probably couple of couple of years back We are not that open right now. We have a lot of excitement in the inner sourcing We are promoting our leadership and everyone we encourage inner sourcing and right now that my situation is right now There are too many teams they want to contribute to the our solution, but we are not ready to Help them out because we are also kind of Establishing ourselves as I'm growing the team and I'm adding new team members too So so we are kind of taking a cautious approach right now. We are working two to three teams Right now on the inner sourcing model because we want to create a model for others to come in So I we are only taking few teams right now in the inner sourcing model on the my journey So that we establish fully the process for others to come and we want to create the guides How to also so that if someone want to contribute to the new template We want to so-called golden path blueprints whatever you call it So we want to create a well documented process internal process how they can add to the solution There was another question Yeah Considering the size of the US bank how it's a very large company I'm curious what the size of your catalog is how many assets would you say in general you're ingesting and do you expect it to Keep going up. Yeah, we expect to keep going up and because We have thousands of applications and if you open the hood underneath that we have probably multiple thousands of services And if you extend that back to like what is your approved we all We need to look at what is your approved open source libraries? So we want to catalog that also so if you look at it Multiple thousands. I don't have the correct number here, but we feel that it's a large and also Like we want to catalog everything anything possible kind of thing For example any cloud assets like cloud firewall. It's kind of a deployable asset We want to catalog who is the owner though. So we we are still looking at it So if you ask me maybe after a year probably it will be a huge number. I will say Hey, how's it going? I was wondering Since you started using backstage have you guys tried using it for incident management metrics? So like as an engineer is troubleshooting an issue and he's completely lost as an idea what's going on It's hard to find information sometimes and I feel like backstage would be perfect for that and Was wondering if you guys may be tracked mean time to detect or fix metrics after Implementing backstage. So we had a lot of conversations about that metrics boils on to not only that what are like We want to capture other metrics, but we are still debating. What is the right matrix, right? We are right now all about enabling the developer that then we want to just Track them then we will want to go in to see what is the real data looks like for example incident We have a our instant management system that is we have all the metrics there So that's not a major problem for us But we are looking at the overall like there are so many developer efficiency metrics. We right now We have that as a probably target for later But we want we are looking at what we want to monitor and log so that we can measure properly and What makes most we we are still evolving on on that one We don't want to make this tool to make developers pressured about their metrics We are all about when we are talking about making developers happy We don't want to put another matrix showing that see your scorecard is like this your scorecard It's not about that. So our goal is to make it easy right efficient That's where we think naturally the matrix will help them Hi Got a mic over here so especially in a highly regulated industry and also with Multiple catalogs that you're trying to put together and a lot of content in your catalog How are you guys looking at the accuracy and are you guys using catalog info YAML for that? Are you doing certain things to help with the accuracy of the catalog or anything like that? Yes, so that's a good question. I Don't think we solved I will explain this I will take you back this way So if you see that there is a central asset system cataloging, right the way we are looking at is When we are creating the new Assets through back the developer experience portal backstage you are creating a new asset So the asset journey starts from the backstage developer experience platform and then we want to send it to a central repository also because we want to do some Reporting and all those things Likewise, we still know that there are other assets generate from some other catalog kind of thing so we are using the entity provider to Sync asynchronously like the initially we kind of did a hard buy it into the other catalog system But which changed it to like a read and write Asynchronous model so first we will write into our own backstage Catalog if it is generating from the cat our developer portal then it will sink into the through the custom entity processor To the other central asset likewise, we are trying to Asynchronously read that one that's working for us We have time for maybe What was the first version or the first use cases that you enable your developers right to become to be agile with the project Like what was the first things that you wanted to achieve? Okay, so the first version he started with using my app so in house Yeah, so it's like Yeah, so it's like our my project when It's in a house app as I stated and it just builds a scaffolding of your project And so our engineers can focus on building the business logic So he asked me like can I use your template because it matches with what backstage is using as an approach and That's where he use like Java That's you that's where he used our template and try to see that whether it works And it's it sounds like it was done in a days, right? It was done in a days and which and for building us for that template itself took almost like for us Three or four or maybe probably a month for that. So that's where we see like, you know backstage is an opportunity to add Any any developers means any developer which has like even I see like a fresher graduate who is really to learn Can you easily create templates and start working on it? And I think one of your question is whether you're agile. Yes, we are Sometimes we went into the daily sprints to weekly sprints now we were to because the way it is is We are learning we are trying to solve the solution. We are selling it out We are coaching others. So many things are happening at the same time. So we are Very I would say okay. Thank you so much big round of applause