Platform Engineering to Product Engineering: Enabling SaaS through Developer - Experience - Sarath G

This talk addresses the challenges of client onboarding in enterprise applications despite significant investment in platform engineering. The speaker discusses the importance of standardization and consistency across APIs, data models, and integration processes. He highlights that while platform engineering establishes foundational components, it often falls short in providing a seamless developer experience and facilitating faster client onboarding. The session also emphasizes the vital role of product engineering in connecting and orchestrating these components to enhance user experience. In addition, the speaker explores how AI can streamline onboarding processes and improve developer-guided interactions with the platforms, ultimately reducing the time required for clients to engage with services.

All of us here in this group directly indirectly involved in building the enterprise get applications, correct? You may be from a development team, you may be in a state, you may be a product person, or you may be from the business also. You're all involved in this. And enterprises are investing heavily in building the platforms. Correct? They are spending a lot of time building to bring the

standardization, consistency, to build the enterprise applications. I'll talk about platforming, you don't worry if you don't know about it, okay? But still, despite all the investment, why this is taking months, sometimes weeks to months, to onboard the client into your system? You agree? So, where is that exact gap is there? Why a developer who wants to leverage even today is struggling to make use best of the

platform today? So, that's where we are going to talk about the four layers today to have What is the the whole context of discussion is okay, move to the next slide, which is good. The whole context of this discussion is What are the four layers to to ensure we can uh we can have the client onboarding quickly. Maybe, if possible, within hours also, not even days, I

would say. What kind of environment is needed? How do I bring the better developer experience today? For that, what is needed? How do I ensure that client themselves can onboard into our organization to start using our services today? That's a whole discussion about. For that, if you're not aware, I'll be introducing what is a platform engineering, what we do in general, every organization is investing in, and

what is then the product engineering is required, and then we'll talk about how do we improve the developer experience. That's the whole session, right? How do we improve the developer experience? And then, how can AI help here to make it possible? That's a whole summary of the discussion. At the end, we'll conclude what is SaaS today. What is SaaS? We all know SaaS some maybe we may

be thinking SaaS is means everything is in the cloud, you have a single UI, we can dodge dodge using. That is not the SaaS we are talking about. We are talking about the SaaS provide the environment to the client where they can onboard what they want into our environment. Okay, that's what exactly I'll explain this. No need to worry. Sorry about that. Okay. Look at this slide.

This slide talks about what we do today in everyday day-to-day work. You all will be part of some development work, right? You may or may not knowing, but you are dealing with when you want to build any software, it could be a simple Java function, anything, you're actually calling some multiple APIs. You are calling some cloud services, you are calling some on-prem applications, you are talking to

your partner applications. You're also using some third-party libraries. Do you see we all do that today? And this so this is so complex because when there are multiple APIs, every API has their own nomenclature, every API has their own data model, every API their own standards. It's so complex for a developer even to build a small software in an integrated environment. That's where so thinking knowing these

organizations have started investing heavily in one thing called platform engineering. What if I standardize everything? You have a trade API, for example. Create a standard API. This is the data model you need to follow. This is how the API structure looks like. This is how you have to send the payload to me, for example. That's the standardization. The API, same for data model also. How it is

going to be stored in the database, for example. And how do you expose the API, reporting API? That should be standardized. That's the standardization I'm talking about. Then we all have shared data models. A data model once for a trade, I'm just taking an example for trade, right? Trade capture. You know, what happens? You You capture a trade in a typical business when when you buy or

sell trades, right? In in a any trading platform today. When you buy or sell anything, the entire organization should follow the same trade data model. That's called standardization I'm talking about. That's it, standardization. And then we also have reusable services. What is a reusable service? A reusable service can be two multiple things. One is a common logging mechanism. How do you log whatever you want to log

the errors or whatever is happening behind the scenes. And also some authentication authorization mechanisms. Why to have multiple authorization authentication mechanisms across the organization? Standardize it. Let the entire organization use that standard authentication module. Dark in you. They just call it user service, do the authentication or authorization, whatever is required in a configurable way. All these kind of things bring the This leads to the the platform

engineering I'm talking about. So, is not just about having a infrastructure only. Platform engineering also talks about having the the software, the APIs, data models also Right? So, we have the complex system here, and we are standardizing now so that the entire organization uses certain standard models there. Now, the question comes, is that enough? Still, the clients are saying today, "I know, excellent. You have very standard

model. Still, if I have to leverage any of the services in your organization, it is still taking weeks to months, and sometimes years, also." There is something fundamentally wrong, right? Platform is doing engineering is doing a wonderful thing here. But, still it's not sufficient. So, what platform engineering is bringing is the your standardization and consistency. Everyone follows certain data data format, for example. This pretty much I

covered. Now, an architect is saying from the platform side, he said, "Hey, we have standardized everything, integrates, you know." And then, product guy says, "No, but it is still integration is very complex. I cannot integrate to another application using because you have a standard API all the time. At the same time, the business says, 'Adoption is very tough.'" Client is still figuring out. I'll I'll give an

example, for example. In a trade application, you will have, for example, uh when whenever you're buying or selling something, and you have a trading cap trade capture software that captures it. Okay? It goes through the trade capture software API, and then it calls a risk API. Risk API is mostly how much risk the trader is okay to take, 10% deviation here and there. And then, you will

also have, uh you know, the settlement because the money has to be transferred, for example, the settlement API. And there is a reporting API. These four APIs have to be integrated in the right way. Still, this standardization is not helping. Well, it's not defining any workflow The the APIs are independent. They're not talking to each other in the right way. Client still has to talk to each

and every API if they have to onboard it anything. So, the adoption has become very slow. So, still the business is complaining, "No, I'm not happy. This is not enough for me. Still the client onboarding is taking a lot of time today." That's what this slide is all Okay, this is a very simple analogy I just want to bring it. Try to see how much effort you

put in and you see very big text, big images. Let's take a very simple transportation example. Imagine there is a city. The city mayor has decided to have a very beautiful transportation system where they want to build nice roads. They want to build trains facilities, train stations and facilities, and they also want to have the the traffic signals there. Oh, beautiful components. Roads are very well good,

very well well designed and very smooth. And the trains are really efficient, and the traffic signals are well optimized. they're not designed in such a way where the roads are really leading to the stations with the shortest path. They're not well connected. Still you have to take some long route, whatever it is. The signals are not optimized the you know, they're not designed based on the traffic.

When the traffic is less, signals should behave differently. When the traffic is more, it should be fit. So, this is a very simple analogy. What I'm trying to say is other components are not considered into view when this transportation system is built in the city, for example. The similar simple analogy, if you apply to a trading system which is there, we have built the platform, the data

platforms are there, we have the APIs are there. If you look at this particular slide, we have the settlement, everything is available. You have a great platform design, but still you see this this this three point few points. We have data format, data rules. What do they mean? As I explained in a trade capture system, you will have a trade API, a risk API, you have a

settlement API for money transaction to happen, then you have a reporting API. The client we say we expose a trade API. There is a column called quantity. Instead of quantity, it's defined as QTY, quantity. And in the risk API, it was defined as quantity Q A N T X Y. And in a settlement API, it is defined as volume for example. They're all good. They're independent, they're

working well. When someone calls the API directly, they work, but they have to integrate, they have to be integrated well integrated, right? Now, because of these variations, various various data the columns are defined in different way, even the the data types also. In some place, it could be a numeric, in other place, it could be a you know, a decimal for And for And there could be

rules also would be different. In a trade capture system, it is okay not to send the currency along with the quantity, but set your settlement system expects I need the currency also because it's a settlement is where the money transfer will happen here. What is happening? There are different rules, different formats. It's too confusing for the client to onboard a to a trade service This is leading

a lot of confusion independently, the trade API, risk API, settlement API, they're all well defined, but there is no coordination when they are defined, but they are working in silos, sir. So, platform is standardizing everything, but the connectivity is not happening among them. That's exactly the problem I'm trying to highlight today where platform engineering alone is not enough unless the product team comes into picture try to

solve that particular problem. That's one of the problem statements we are going to solve, you know, is what we are trying to say. So, we have not We did not build one trade system. You see this line, we build many systems that process our trades. So, I'll explain this in a little bit in the next slide. So, what is missing in the platform beyond platform engineering? So

far you you you understood what is a platform, right? Standardization and consistency. And in the next slide, now we are trying to we have also seen the example of the various date for data formats and the various rules that we are defining across each APIs. when everything is there and we have built the components, what the product team says is we have not given the right product

experience. What is an experience here? Please pay attention to this experience. Experience means how I feel talking to your system. What is my experience? How easily I can onboard my requirement or what the client onboarding of a particular product into your system. That is the experience. The experience is not good. I'll give you a very small example. For example, imagine they get in one error. They are

trying to call an API, they get an Each of the APIs, there are four APIs, right? We spoke about We have spoken about the the trade capture API, risk API, and settlement API, reporting API. There is one error that has come. That error messages are different from each other. There's no standard. The client doesn't know what exactly the error is, what exactly he has to solve that.

That's a reality today in the enterprise When these are working independently, even client doesn't even know what exactly they need to correct on this when they are calling our API That's exactly I'm trying to drive Okay? These are very practical challenges, especially if you're a developer or a product guy, you'll be seeing all these kind of challenges in day-to-day work. So, platform helps definitely to standardize consistency.

And this is where the product engineering is very important in an organization. They help to connect the dots on built on top of the platform engineering today. And then, once the product engine is solves this orchestration related stuff, and then the developer experience comes into picture. I will talk about what is a developer experience here. How a developer can seamlessly use the platforms that is available so

that in a self-guided way. And then, AI agents, of course, I will have a dedicated slide for AI agents in next in few minutes. Okay? To implement all these, the mindset is very important. It's called Kaizen mindset. We need to continuously improve our systems, not at one go. It's not technology, it's more of the thought process here. So, I pretty much defined this platform engineering just for

the as a flow because I'm defining the four layers. I repeated it. Just see this. Platform engineering provides the standardized APIs and dev tools, reusable components like logging, authentication, authorization, and automated process operation, security, governance, and all other aspects. So, it has everything, but it doesn't fully solve the usability, it doesn't carry the adoption This will be the actual session starts. Now, we know what is a

platform engineering. Now, we're going to talk the product engineering. What platform engineering says is the capability is there. Means, you can capture the trade. That there's a capability, but it's not an experience. What product says is, I will get you to something get something done. I will ensure that your trade is completely processed in the right way. That's where the product engineering took a look at this

a very small comparison. If platform is your factory machinery, right? In a machinery you'll have various machineries, various components, right? Unless they are assembled and ready to sell, your factory has no means here. Correct? That's where the product engineering plays a vital role here, actually. So, I'll jump to this very small slide. So, how do we get into the product engineering from platform engineering? The first thing

is, yes, you have only the platform, then you will try to connect all to the all the APIs so that the APIs are connecting to each other. And the third stage is, how do you orchestrate it? Which API should call when? How it they should call with each other? And the level four is productized experience. You probably can expose only one API. There are four APIs underlying.

You have not just a trade API, you also have your risk API, settlement API, reporting API. But the your client doesn't need to worry. They only call one API at a time. That is called the productized experience. Or you just give it one user interface to them so they can do all the required field mapping at one go. The entire flow is taken care. That's where the

product teams are very important to do understand the client problems, what client is experiencing And the final stage is AI. I'm skipping it because AI is a different thing which I'll cover in the next few slides. So, this is just an example for your understanding. You With the platform engineering, we have all these kind of, you know, APIs are there. They provide the reusable services, except standard

interfaces, and strong foundation. But they are not ready to trade. If I want to trade, my platform alone is not enough. I need my this fully configured workflow to be available. That is possible only the Please stop me if I'm going fast on So, so far we covered two things, platform engineering and We're good. So, product is good, client is good, client is happy. But, how about

our poor developers? Right? They struggle a lot. Yeah. They struggle a lot. So, our developers still need doesn't know which API to talk and when. Right? They're struggling cuz they don't have the clear information. There's no self-guided way. They don't have a way they can ask, "Hey, how do I call a particular API? Which API should call in which format?" For example, and they don't have a

sandbox, for example. This is what the platform team need to provide a a sandbox so they can test it directly. Rather than after integrating everything in the UAT, doing the final testing, they should have a sandbox to be available so developer can test it, look at the logs, which is the third one, where they can say, "Oh, this is how if I call this API, this is

what the message I'm getting. Probably I should pass a different parameter, for example." This is where the developer experience is very important. So, we need to focus on not just the product and platform and product in an order, also need to focus on the developer Very big slide. Don't get annoyed with this. Very huge slide. I know I I just had a few minutes to capture this.

But, I'll definitely make it easy for you because this is an AI of power of So far, we have built This is a manually, right? We have client will when whenever they want to uh onboard a trade, they do they want to make use of the trade service, they manually submit the data and do the data mapping, field field level mapping, and they do all these kind

of setup manually. Which is good. We have the product engineering, we have the platform engineering, we have everything Very good. But, what if I have a system which can do the mapping automatically? I know in one of the sessions, I mean the previous session also, you might have heard the if you were there if you heard the word ontology framework. Which automatically maps what is the relation

between the two tables, for example, or two domains. How can you do the automatic mapping? You have to create the knowledge depository. Let the AI agent decide, okay, if the client is sending QTY as a column in the when they're doing the mapping, AI will decide for the QTY and in your application it's a volume, it will automatically understand that this is the same. It will do

the automatic mapping. That is the agent we are talking about. Similarly, we can have a I know there are many things that we can do. We can give a knowledge depository. You can give a self-guided way of whenever client wants to onboard uh their product into our application, it keeps on helping, "Hey, if you're doing this mapping, this field to field mapping, you also have to map

other fields." This is where AI comes into picture. This is beyond what we have spoken today. AI is always there as a mentor next to you, which is helping you, "No, do this, do this, do this." Probably this is what you were looking for, probably. It will guess. It will try to help you there. So, have the AI agents across all areas. I will share this this

slide and this is a very bigger one. I thought it will be bigger screen, but uh it's not readable. Sorry for that, but this is where the beauty of AI comes into picture. I'll show you a very simple example how this helps the a developer also. Look at this stock bot. Very simple, right? I want to call a developer is asking, "Hey, I want to call risk

API. How do I call my API?" It is helping. It is giving a complete example there itself. Developer doesn't need to worry. It doesn't have to figure out what is the structure of the syntax of the API, what to pair, what values they need to pass, etc. etc. It is helping there If this knowledge repository can be built in the system and we dynamically call that through

the A agent, it will take care of it. This is where the power of A agents come into picture. Now, this is a summary of everything that we discussed, right? We have the fragmented systems like cloud, multiple APIs, etc. etc. We now we have built the platform. Organizations are heavily investing in this. They create the standard models, shared capabilities, and then then as we learned well, they

are not enough. They have started working on simplified APIs, all the pre-integration, whatever needed to do. Then they're also having these self-service guides, feedbacks, sandboxes, etc. etc. All this together will reduce the client onboarding time and also improve the So, when you're building you're talking working with your organizations, if they say platform, we have a platform, think of the product also, product engineering, think of the developer

experience as well. Then only then of course is an additional thing which came in the recent two time in the recent times. Think of the AI ensure that you bring the right experience to the client and save a lot of money and time for the client. Instead of we we can be in a position where instead of taking 6 months or you know, 1 year, if really

an organizations can provide this kind of environment, trust me, we need to go into minutes also to onboard any service into our platform. That's the power of this combination of platform product DevEx combination and of course powered by AI although not mentioned here. So, this is a conclusion. So, what we are trying to summarize is we don't have a component problem. It's not about building the APIs

separately. What we have is we have a system design Understand the system design very, very important to build enterprise grade applications. And then we have So, we have to design the systems end to end. Focus on usability and adoption. How easy it is to call an API today? That's very important. And is the workflow is is the uh is orchestrated end to end or not? Treat platforms

as products is very important. Your platform is exposing API is also product itself. It's not just an API, right? It is also has to be well maintained and continuously improve the experience. So, SAS becomes simple for the clients because of strong engineering underneath intelligence on top of it. That's the conclusion. So, we have a created with the platform, you know, with the platform engineering, create the standardization,

and build the more intelligence layers on top of it. You can onboard a client within no time, With that, I'll end the session considering the timelines. Thank you. >> [music]