AI, Power Platform & Developer Experience: The Next Frontier with Reza Niroomand [MVP]

Yeah, welcome back to the Ampest 65 podcast. Today we are diving into one of the most interesting shifting happening in the Microsoft ecosystem. While everybody is talking about a I co-pilot, low-code development, there's another movement gaining momentum bringing software engineering principles back into power platform. Our guest today is Riza Nimor, but solution architect software engineer, creator of XMR truodes and PS data and servers and someone who spend years helping the developer's building better, more reliable, Microsoft solution. We'll explore why code thruers development matters more than ever, how AI is changing in way of developing solutions, why everything as code is being essential and what the future of power platform development looks like. Wherever you are a power platform maker, professional developer solution architect or simply curious about where Microsoft development ecosystem is heading, this conversation is practically inside. So let's start. Welcome Riza to the show. - Hello, thank you for having me. - Yeah. Can you tell us before we start with these interesting topics a little bit about yourself and what you are organically attract you to the Microsoft ecosystem? - Right. In fact, I had a very long journey. I started since I was a kid, started writing codes. I mean, the goal was to create a game probably for myself. I don't know how I ended up building business applications and enterprise solutions. But yeah, it was, it all starts with coding normally. - Yeah, awesome. Yeah, I think there is one guy that have made some games in the power platform. But I forgot who boiled it. Yeah, I'm as half, I've seen those. Yeah, and also Sandra Kiel, she makes sessions about gamification in power apps. It's also really interesting. But yeah, you have work across.net, SharePoint, Adrien Power Platform. How has your journey shaped your architectural thinking? - Yeah, in fact, I started with the hard one. I started with SMD language because at the time, that was the only way to have fluid graphic. I think I started with mouse. I wanted to have a pointer. That was when Microsoft Windows was not really an operating system. So I had to deal with the pointer and detect when mouse moves and stuff like that. So you realize very quickly that with those low level languages, you cannot do a lot. You can have very focused things. So you start learning a higher level language like C. And then you go and see, okay, even that is not enough. You go to something higher. Like at the time, it was visual basic. So we had a nice marriage of visual basic and C++. So if something needs to be done in really high quality or extreme good performance, that would have been C++ or special components. So the low code of the time was visual basic. I think before that, the low code was a cobalt. So it was supposed to revolutionize the world, you know? You just write no code and everything is done. It never happened. So you met, they kept trying and trying the low code, the train and then here we are. You know, we have the low code which looks more like Excel for Mulas, for example. So I went along with the industry everywhere. So I came from that area to .NET and then .NET tried to bridge that gap of productivity like within language, that set of languages, in fact, that tried to be everything. Low level, high level, mid level, maybe not too low, but somewhere there. So you don't have to learn a lot of languages in your remaining one language and you can pretty much do all the stuff. There was several light, if you remember. You could use the same language even in the browser. Didn't last long, though. And that's for good because the technology came along. So I went with it. So normally in enterprise application developments, you ask yourself, okay, we are using really professional tools like we are writing code, we start from scratch these applications, but the security model of the big enterprise doesn't shift overnight, right? It remains stable. There are certain things that remain stable and they are kind of accepted unofficially across the enterprises. So it kind of feels boring. You want something that you can do it a lot faster. At the time, it was SharePoint and SharePoint had something called InfoPath. With that it would be like mini applications, like large data entry forms, things like that. And you could have public facing applications. So you can't see I'm still doing the same. It's the technology that changes around me. I still continue doing the same. So then SharePoint stopped trying to be everything because Power Platform came along and it was basically defined as the low-cut platform before the AI era, right? It's still accurate, but it's no longer sufficient because Power Platform is becoming something broader in an enterprise application and agent platform for humans and low-code makers and products. And AI agents can all participate in building and operating business solution. Yeah. Here I am again doing the same thing in a totally different way. Yeah. When Power Platform first appeared, what did you think about it? Right, well, I didn't go exactly the first, I mean head on to it. I usually stay cool and relax and wait until something mature enough, right? So a lot of people are normally go head first and try, thanks to them, we learn the pitfalls and everything. The platforms are not something that I embrace since the beginning. So software development itself, yeah, I go fast and I try to learn before, everything becomes revolutionary, but the platforms I wait. So at the beginning, yeah. I was working for one of the biggest insurance companies in the world, I think. And then, so we have probably, I remember from one of the architects we were using more than 300 technologies in the enterprise. And, but, you know, we did all sorts of things. I could see that whatever we do, we are wasting a lot of time and resources. I'm to a platform like Power Platform, you have a lot of things that you take for granted, but for an outsider like me, just watching the platform shape, I could see, okay, there is a very, very mature security model. There is deployment in place. It might not be the best in the world, but it's there and it's maintainable and you're not responsible for all of it. You can be more focused on the business problem at hand. And if ever you build something like a pro-devil kind of component, it's for good because you're building it since the beginning to be reusable, even better, you, well, preferably you are going to share it with the rest of the community as well. So that caught my eyes. Okay, I said, okay, this is the one thing that I need to jump into. Yeah. Yeah, what defines a great Power Platform architecture from real-perfectors? Yeah, well, that's also shifting, you know, it's shifting a lot because, you know, the Power Platform itself is shifting. So maybe a good way to see it, I don't know if you will agree with me or not. But I would see it like three generations. So I have my generational perspective. So the first generation was the low-code productivity. So Gen 1, let's call it Gen 1, the low-code productivity. So that first generation was focused on democratizing software creation, right? So Power Apps gave organizations a faster way to create internal business applications. That was a title for SharePoint, I guess, but it was stolen by Power Platform. Mates? Allow to automate repetitive tasks, nobody likes. Power BI and made analytics more accessible. Dataverse offered and managed business data platform. I don't think we have that anywhere else. Dataverse is the business data platform, with security and metadata and relationship and all the things and the business logic in one place, right? The central value proposition was, I think, speed, right? Instead of waiting months for development team, a default could build a useful app in a matter of days or weeks, done right? This was a major step forward, right? That's what I was sold on, right? The professional developers sometimes sell this low-code as too restrictive or insufficiently disciplined, measures found the traditional software development, too complex, I think. And the department worried about uncontrolled application growth and weak lifecycle management and duplicate data and stuff like that. Then you had Gen2, which is the fusion development, my favorite. That was the second generation, until recently. So you had the idea was that you have a fusion team that combines business experts, low-code makers, IT professionals, architects, and software developers and each participant had to contribute to an appropriate abstraction level, right? Then a business expert may define the process, the maker built the initial app, a prototype, creates the custom connector, plugins, components, API, and then the administrator establishes the security and governance. Now the architect, in that era, ensured the overall system remains coherent among all of them, right? This model recognized an important reality. So the person who understands the business problem, best or better than everyone is not always the person who should implement every technical component, right? So Power Platform became the shared environment in which these rows could collaborate. Now we are starting the third gem, which is the AI native fusion, right? So we are still fusion-deving, in lack of a better word, but it's AI native. So we are now entering a third generation where AI joins that fusion team. So AI can help, so it's in every layer, you know? - Uh-huh. - Help describe the requirement, generate the data model, create the app, formulate a power-effect somewhere, an expression, build a cloud flow, generate code, document it, inspect metadata, query the data, operate even the business process. So this does not eliminate the existing roles. You still have the same roles. Instead it changes how they spend their time, basically. So the maker moves from manually placing every control on the canvas to describe the outcome and check the results, basically. The developer spends less time writing repetitive plumbing and more time on the architecture. So somebody is entering that area, right? And the domain logic, the integration, quality, and the performance, so they have more time for these things now. The architect now, Purgayk, must find not only the application and integrations, but also the boundaries within which these agents can reason and act. The administrator as well. So they must govern both human-created solutions and autonomous or semi-autonomous agents, right? They reason as well. So this is the emerging model now. Business users express the intent. AI accelerates the implementation. Developers add precision and extensibility, the quality and the platform provides again, security, governance, data. So if you look at it with AI, we can do more, but there is more for everybody to do as well. - Let's more to govern, more to handle. What mistakes do you see actually in this power platform? The company work with, is there, yeah, rapidly mistakes? - Well, each company is in a different, because it moves fast. And companies are still the same companies. They didn't change their speed, right? So the adoption, depending on the complexity of an enterprise, is different. And also the risk level they can accept, right? Some enterprises are even built in a more modern way that they can absorb the risk. So they can allow mistakes to happen. That's the best enterprise to work with, right? They, even if they cannot take the risk, they have some way to allow the risk to happen to learn from it. That would be the best. But some enterprises, like, for example, if you look at banks, they are very, they are very, and they're competitive. They don't want to be the first for good reason. So, if you ask a company that is where, like a bank, for example, they are probably a little bit behind. But if you look at a company with repetitive tasks, like customer facing scenarios, even if it's an interest, because insurance is a little bit, less risk, ever standing bank, they understand this proposition better and they are able to absorb the risk in some departments. So they are going ahead with it. But the governance is creating the biggest problem. So we are making everybody faster, but we need some kind of oversight and we are realizing that agents are not exactly humans and they are not going to be very similar to human. Kind of anytime soon. So everybody is seeing that. So Microsoft is changing their approach a little bit. So they are giving us more tools. We understand more that these agents are behaving differently and how different they are. There are mistakes happening again in every layer. So because AI itself is in every layer, it's in the interface helping the business users of filling the forms. It's automating the task, it's helping the developers to move faster, but you have this concept of shadow IT, which has returned in the, still in the town, making problems for everybody, administrators, an architects, everyone. So we need to build tools that better keep us against these problems popping up everywhere. Yeah, I have a direct two questions, but the first one is we have, the old problem was in scalability was, I need more developers to get my project faster. Now I think scalability has a little bit changed because everyone can do an app, I don't know, in a few minutes. So how has scalability changed and what must companies or IT under IT guys understand when they're new, a lot of scalability? Very good question, because all of us been watching. So I think one of the catchphrases or the marketing was that, okay, the AI is going to democratize app building, but app is just a small piece of it. So if you look around now, if the AI has been around for a while, you have even all these platforms like Lovable and everything else that allow you to build apps, but now the industry is full with these apps that are kind of grickets did, because creating app was not the biggest problem. You could build apps fast, right? It's a lot faster now, of course, but there is a discipline to it. Like how are you going to maintain it? How are you going to secure it? What is your target audience? What is the architecture? Where do you want your app to do your app to be like in five years? Which arts are going to change? So you see, all those concepts are still there, and AI cannot help you with those. So you have a lot of apps now that are a bit overnight and forgotten over a week. Or there were security issues and even a good guy who was behind it, he's over there now with the number of problems that he has received, starts from scratch, doing another app again. So I see them everywhere, but still those teams that are already equipped with like a LEM in place, with good vision, with discipline, they are the ones moving faster than before. So you can't see the teams that are benefiting more, like 60% of their job is done by AI, they claim, are doing the discipline teams. Because they have this control and everything in place. They know how to scale their app because they were prepared for it, and AI is just making them much more productive. Yeah. And the second question is, yeah, I, or how looks a clean architecture in the power platform and for this new time of revenue development. - It's one of those hard questions. It all depends on the enterprise that you're dealing with. So because the picture for a small company is a bit different than the picture for a big enterprise because of complexity that you will have to deal with. I mean, even the estimations, probably the most important factor that can affect your estimation for building a solution is the complexity of the enterprise. - So you still, the old concepts are still there. You have to answer questions of how you are going to build an app and you should prepare as an architect to answer why. So every piece of the architecture that somebody looks at, you should be able to answer the why question in every layer, why you are building it that way. And most of the time, the answer is not because this is the best way. The answer is the right answer is that because it fits better. Because some pieces of your solution you are building maybe as a throw away because the maturity of the business is not there, for example, to sit. So you invest less time on that. You don't waste the time of your developers and your customer. Some of them are like mature pieces, for example, for performance, you will have to deal with more complexity because the performance of that part was critical. I'm just throwing some examples. So still need to answer questions like why in every layer, you still need to have a good, organized, disciplined way of ALM. There is no customer where you don't need ALM, for example. You need some sort of ALM because if you cannot package a software and deliver it, it's like that software doesn't exist. You should be able to do it in a repetitive way. Developers should not spend time on figuring out how to deliver. They should always spend time on building because this is their happy moment. If you ask a developer to not develop and do something else, you're asking him to change his job, right? You still need to answer the same old questions. - Monty. - I think a little bit, we have also talked about the business logic, especially in this time. Where should the business logic live? How can we handle the business logic for these times? - Yeah, that's a very good question. So in a traditional approach, some people might not like the choice of word, but you have the classical or you can call it traditional way, where you start from scratch on application or a software solution. You would normally try to complete the separate business side of the things from the technical side of things because they change differently. Their lifespan is different than the rest of your solution. So I'm talking about, for example, you have the cross cutting concerns like security, scalability and so on. And then you have like the specific business areas of your application like the, it could be domains, for example, and within those domains, you have business pieces that you would try to separate them. But when you are building in a platform, like for example, an empower platform, the first thing you need to respect is how that platform is already architected, right? You cannot start as if you're starting from scratch. You should see how the security works. So your architecture should fit that one. So the place is that Microsoft sees for your business logic in multiple layers. So you have the plugins that is basically the native place for your business, logic. And if it's a process oriented, you have the power automate or cloud flows. So you have these normally two major areas, the plugins and business process flows, probably a little bit different, so I will not bring that to the picture. You have the plugins and power, but some parts of your business logic would always leak to other layers because of an end user experience thing. For example, you have rules that might say, okay, this number should be between x and y or if, for example, another number is between something else, that would live in your plugin, somewhere in the back end. But you would still want that to be on your presentation layer. Why? Because it's easier to stop the end user entering a wrong number than to allow him to enter it and later on, show him a pop-up that complains about it. So for several reasons, like for enhancing the user experience, that business logic might leak up to other layers, but the primary area that it lives in is in the back end, if you're asking the discussion more specifically about Power Platform in your plugins and Power Automate. - Yeah, and I think, topic, zero topic, I think, let's talk about the code first. It was that actually mean and how would this Power Platform and especially how clean code into the code from AI? - Yeah, yeah. So, in the past, which is not long ago, you had this divide between Pro Code and Low Code. So, most of the people called it now, Code and Low Code. But now it's more about that fusion model. So there is no divide anymore. So it's more about a platform where code and low code and AI can basically contribute to one another. So they are basically reinforcing one another. So you have the low code, which is basically designed based on the pieces are built using Pro Code developer. A Pro Code sits there and creates those components like Lego pieces that you put them together and build enough. AI is actually another contributor within that fusion team. So I see it more like that, but what happened with AI is that code is becoming easier to produce, right? And you can produce a lot more code, a lot faster. So it's now more about reviewing the code and understanding the code faster, right? And we are sometimes losing that oversight. So I see more and more that people, I mean, you don't even, you know, you're trusting it more, you allow it to produce more. And now you have, you're entering another area where basically you have multiple agents running in parallel in Luke generating the code. So you have to basically review a lot of code. You have to make sure you're not introducing security issues and you know, you're not going against best practices. Like the hard problems are still hard. Like race conditions that can be only happening in the scenarios that you have a lot of load on your systems. Exactly the moment that it's too late to catch them. So you still have those problems, but you know, with AI, producing the code itself is becoming easier for everyone. So you can see like the makers in pairing that area, the same way that developers are also entering the architecture area more and more. It's becoming more shared responsibility than before. But I'm not expecting everybody to become interested in, you know, the entire business of building software. So that gives more responsibility to people like architects and the products to have better oversight, to be better to review those produced codes. But the tooling also coming to help, you know, every day I see more and more tooling coming to help us go through a lot of code, a lot faster as well. Again, AI is helping there too. And I think we have also topics we have developed how we have think about it's, I say the first one is what I think is this versioning, how have this just changed? Yeah, but the thing is you have AI, I think, in two areas, I mean, coming from our perspective. So you have the AI that is basically for the bin there, let's call it, that is the kind of AI that you are using to create the app using natural language descriptions or generate or explain a power fix formula or creating like a power ultimate flow conversationally. Or for example, suggesting user interface, helping developers understand the data model, for example, right? So power apps, co-pilot, for example, can generate an app and its data model from the description of the business require. What power ultimate co-pilot allows a maker to describe a workflow through natural language and then these experiences are intended to reduce the distance between the idea and that working, let's say, working first version. So the goal is not necessarily to produce a perfect production system from a single product, right? But to see the value there. Then you have, in this area, so without AI, the developer or the maker begins with a blank sheet but with the idea begin with a draft, which is better. Then you have the AI that is inside your solution, which is a second category. So the example is like, for example, summarizing a customer record or extracting information from a document or classifying an email, I don't know, or commenting the next action or monitoring an event and producing actions after it. So this is a different area. Like a user, for example, expecting to do things like, okay, summarize this current state of the customer or show me the open cases that requires escalation or prepare like a response that I want to send about this account information. I have to explain why this application was rejected, you know? Things like that. But these are two different AI's that we are dealing with, which is totally different. You should not mix them. Each has its own problems and tooling and everything else, right? - And what roles do the ICD pipelines play in improvement or improve our platform projects? - Right. If you see more and more with the platform itself, we are coming closer within the shared platform. Like you have now the pipelines within power platform that makers can also use. So I am hoping at some point, everything comes to Git, basically, so everybody only uses Git as a backend because what I have learned is that you cannot, you know, meet developers halfway to meet developers exactly where they are. So a lot of tools fail because they didn't realize this. So we have to bring everything to Git. But we should make it so easy for the makers to work with it. I see a lot of activities happening in power platform for that. You can now integrate it with Git, but there are limitations. But it's the fact that everybody is recognizing, okay, we need CI/CD for everybody, the LM concept is the same. It's just a user interface that needs to be suitable for this target audience. And you still need to be able to develop, test maybe within a sandbox environment, whatever, build and ship it to the environment that the end user is using it. It doesn't matter if you are a pro dev or a simple maker, well, it's just the same thing, the same concepts apply. You need reliability and productivity to be able to ship fast and with peace of mind. So if you are in a situation, when everybody is scared of pressing the release button, you have a problem within your LM. So everybody should be able to happily press that button because they have the confidence, okay, at this, we have done it before and it always works. There is no reason to worry and we have tested it. You don't have that confidence, there is room for improvement in your LM process. - Yeah, I don't like it. I'm more dev-optic guy. But yeah, yeah, okay. The developer house, yeah, they have front-assetting against me and we have a good integration. - We can process sometimes, I see, for example, you have too much segregation of responsibility that might be that the guy that presses that button doesn't even know the responsibility behind me. So he presses the button, but things get growing after and it's the developer who will be called, right? - You don't want to be in that situation. - Yeah. - What would you say, what should always be stored in the source control? - Well, the source control should be the source of truth. So I have seen over years that Bore platform has come a long way, right? We have gone from the time that nothing was in the source control to the area that, okay, we realized that, okay, things should be in the source control because of the traceability. But now we have fully realized that Bore platform is not an exception. So just for the same reasons that every other technology needs a virgin control, not just for traceability, for many other things, powerful platforms should also use Git as the source of truth for everything. So the things that are built and designed, they should go to Git. - Go. - But you normally take that source code or metadata and configuration and you build something, right? That build is supposed to be repeatable. So if you, for example, you have the build server or the build process, if you feed in the same source, it should give you back the same binaries that you can deploy, right? But those binaries should not end up in your Git because a moment you have two places that things leave like in your artifactory or in whatever area that you store and ship the binaries to the end user. If you have that same binaries in the source control, that's not good because then you have the question of, which one is the latest? Or which one is pointing to this virgin in the source control? So we always try to, when we build the CI/CD, pipeline or the ALM, a gear picture, we always try to make sure what is buildable should not end up in Git. Like for example, in Power Platform, we have the DLLs of the plugins, the assemblies, or we have the new Git packages or we have these JavaScripts or PCF components. So these things that are built, build is the output. They should not end up in the repository because the traditional way to look at Git for Power Platform, the developers was like, okay, this is just for traceability so we can go back and see the code. No, you should be able to take the Git repository and using only that, be able to spin up quickly an environment and deploy everything and have a development environment very quickly. So it's not the idea to have just the history in there. Everything becomes traceable, you should be able to go back and roll back to your changes, correct things, you should be able to reason why something has changed. So that means that even things that are coming from your Power Platform environment, you create a form, great view, then you should take that view and form whatever you build, push it to Git and describe what you did. So it means that 10 years from now, but 10 years is a long time, maybe two years from now, you should be able to come back to that project and but just looking at your Git, be able to know what happened in these two years that you were not around, right? And then with confidence, you should be able to create a development environment and simply your Git to spin it up. - I think for other guys, we have this infrastructure as a code topic, PowerShell, and the graphic, and so on, is that a similar idea for the Power Platform? - Yes, yes. Oh, you have provided for a Terraform, normally the most popular one, 'cause there are different options. - My sub-sign. (laughing) - I haven't seen in big enterprises where like the ones that have several technologies because this Terraform, for example, is more open, supports more technologies like it can go from Azure to AWS to Google, and now in Power Platform. The problem is that, well, it's open source, right? But it doesn't cover everything. So if you see something missing, you are welcome to contribute to that. And it's always nice to have more contributors, one of the problems is that Power Platform itself is moving fast. So you have DLPs. For example, now you have an easier way, but that easier way needs API behind it. So it needs to become accessible to Power Platform API. Then we can have it in the Terraform provider one day, it doesn't cover everything now, but it's the nature of the business. So it moves fast, takes time to get there as well. I like this idea of having a way of just defining the environment to be, and it becomes like that, rather than writing the description of what to do in PowerShell Scripts to build that environment. But it's not that difficult. For now, because Power Platform is not like Azure either, in Azure you have to do a lot more than Power Platform. Power Platform building the environment or configuring it is not that difficult. You have the environment groups now, that makes it easier. And you have this blueprints that you can apply, and there is more than before, and it's easier to manage now. But Terraform is always welcome, because in a big solution, you most likely have a lot of Azure components as well. You have Event Home, you have Azure Service Boss, you have Functions that and other pieces. So having Terraform also for your Power Platform would make it more coherent and easier for the Devob Go is who are used to your Terraform approach to also deal with Power Platform. But it's not far from that. You have, I don't know if you are familiar with the CDS approach, which is basically, so previously you had the code components, which were totally isolated from artifacts that you would build visually in Power Platform, but they are basically closing the gap. So all the things that you build in a Power Platform and the environment can live under a project that you basically can build. So you just queue a build operation, and it can produce your Power Platform solution, which is ready to deploy. I'm not trying to say, okay, it's perfect, and you install it and everything is done. There is still more work to be done after your deployment. And Terraform is a very good glue that can fill that gap. - Yeah, that's what was really fantastic, but I also will take the chance to talk about your tools, or your tools. You have built XM-Arch rules. What is it? What inspired you and what problem are you trying to solve? - All right, it actually started with an experiment. So I saw the way that we are developing a Power Platform solutions in the past. And coming from, because I transition from different technologies, I normally move horizontally. When I get bored, I start with another technology. So when I arrived at Power Platform, I was expecting better tooling, let's say. For example, in SharePoint, you had better tooling, so you would always build everything in Visual Studio. It was marketed long ago as the integrated development environment, so it's more than a coding tool, right? You should have been able to do everything in Visual Studio. And you could do everything for SharePoint. But when I arrived there, I thought, okay, there is a lot of room for improvement. So there is like an action, I think, from Microsoft that you can install on Visual Studio. So there is a lot of problems in it. It's clear that it's not maintained as much or Microsoft is not really invested on that one. When I asked Darab, who is using it, I didn't see any hands going out in any company. Some people tried it, that disappointed. It's documented how to use it, but it's not doing a lot. And then the modern approach for software development is basically defining everything as code. And we are seeing the benefit a lot more now, by dates with AI, because whatever that could be defined as code, can be produced with AI as well, right? But there is a lot of pieces in Power Platform that couldn't be defined as code. Like you write a plugin, but you have to go somewhere else to define what your plugin does, and then it should be activated, and what should be sent to your plugin, so the configuration, the context. So if you touch your code in your plugin, you have to go back. And for custom APIs, which is a more sophisticated plugin, you can have all sorts of inputs and outputs. It gets even more difficult, because on top of that, you have the input and output of the API, and God forbid, if it changes, you have to again, jump back to the tool. And there is not one tool, but many to work with. That means developer is losing their site, well, you know, they come out of the Zen that they are developing fast. And after a while, which is basically what is even worse, they get used to it. So they just accept it as the nature of the world. But when I came to that area, I noticed there is a gap to be filled. I didn't want the developers to go outside to define what could be already visible in the code. So I saw there were some attempts at doing it, but you know, bringing these things to Visual Studio, Visual Studio is very extendable, but it's very difficult to extend it. And not everything is documented. So somebody had to bite the bullet and sit down and learn how to work with Visual Studio, and it was difficult. So I just, I didn't make any promises to anybody, not even to myself. I said, OK, let's try it. Could be a fun site project. That fun project took a year. I think I spent more than 1,000 hours. Virgin. So I was even at that time to be, you know, you just put some attributes. This is the way that every C# developer works in the world. You add attribute to your plugin. Why? Because that's directly related to the code that you're writing, but it's about the code that you're writing. What is the place? If you ask any C# developer, they will answer C# attributes. It even exists in other languages, like Go and many other languages, Java, for example. So there was no question. That's the right place. So you can now be the external tools. You just add some attributes. It's a like, this is the step. This is the image. And then you just right click on your project and register. But think is some magic happened at that moment. Because the moment you put that in your code, that becomes, first of all, a single source of truth in reality, not in marketing in the moon. You define your API input and output. You define the registration of plugin right beside the business logic there in a clean way. And now not only visual studio can understand what it needs to do to register your plugin in a single click. And also maybe another advantage is that the entire thing is a transaction. So if it faves in any moment, it will road back the entire thing. It doesn't happen in any other tool. But then I noticed, wow, the analyzers, you might be familiar with them in that then. And code fixtures, they also see it. So they can complain if you are doing something wrong. And as your intention becomes clear to visual studio, it can do a lot more. So it knows, for example, in your plugin, you have a dependency on which table and which columns. So you have a type safe target. There is no way you can make a human error even if you try. So your code will not compile anymore. So it becomes a lot safer. It becomes a lot faster. Or like common problems, for example, you're not allowed to use state within your plugin. Why? Because the plugin can run again and again. And the context will be different each time. It can be a different user with a different permission learning event. So it's even dangerous to keep things in your properties of your class, which is your state, but not with external tools. Because we have dependency injections. So it brings all these concepts that existed outside of our platform for everybody else. Now we need power platform. Your bit becomes safe. You just right click and register. It takes care of the build if it's required. Then I bring all these things that are in power platform as native services. You can just open a new fetch file and write a query. And it compiles and generates code for you. So whenever I see opportunity that this is a code that is always looking the same way, the boring stuff, XRM tools should take care of it. But there is a lot more coming to it. I talked about CDS project. Like CDS project is nice project model. But you cannot even open it in Visual Studio. But I'm not going to tell you a lot more than that. But there is a lot of stuff coming to XRM tools that makes it also a first class citizen in Visual Studio very soon. Yeah. You have spent 1,000 hours on work. Can you have me be? And now for the next year, you have a newer product, the PS data worse. That's a power shell to the data worse. So can you a little bit tell us about this? Different tools with different goals. So for XRM tools, because it's built for Visual Studio and for the developer target audience, the expectation of the quality is extremely high. For example, in XRM tools, there is no simple way to-- for example, you might look at Visual Studio and say, OK, everything should have the same theme. If it's dark, everything should be dark. But when you create an extension for Visual Studio, it looks like Windows 95. It takes the default colors of-- and you have to do a lot of work just to bring the theme of the Visual Studio to your extension. And every single piece is important for me because I don't have a release date that is announced to anybody. I take a lot of time to make all these little corners perfect before I release. The PSDTWR is a different word. So that's basically there. You can use PowerShell to create a record or two in Power Platform. But nobody is using that for data migration. Why? Because you might need to move massive amounts of data in and out of Power Platform. PSDTWR is for that purpose. So you basically generate a JSON, which is extremely easy in PowerShell, probably with one line of code now. You can connect to any data source, be it Postgres,QL, or SQL Server, or a KEL whatever. It's always not more than a line of code. And probably one more line of code to read massive amounts of data. There is always a module for that. It doesn't matter which data source. Then the problem is here. How are you going to move that massive data into Power Platform reliably? So PSDTWR fixes that missing piece. So you are able to load large amounts of data, give it to PSDTWR and point at the table to move that data. So with that in place, you can do a lot of magic, basically. It takes care of connecting to your Power Platform securely, creating parallel pipelines to your Power Platform and send massive amounts of data in transactions. So it's actually matching them and running them in parallel. And because the runtime is very light, you are not within a SIS, which is itself very large. And because it's code-based, you can run it anywhere, a code can run in the cloud, hosted or within a VM or from an unprem-service or a VM. You can just move that amount of data to the target environment. I have samples written there that shows you like real production scenarios. What happens, for example, if in the middle of the data migration for some reason network outage, everything is stocks. You should be able to receive them. You don't want to start from scratch. So it addresses all those common problems and we use it in different teams to do huge data migrations, to spin up environments, feed pre-existing data. If it's like 20 records, it's very easy. You can do it manually or with an extension. But what if you need like 10,000 records in 50 different tables with dependencies on each other, right? With the UI, it will be a nightmare. But if you can convert it to JSON, poor PSD-towers can move it to Power Platform. And vice versa, you can move it outside of Power Platform in JSON format and storage somewhere. So you might be immediately thinking about, wow, we can transfer data between environments reliably. Because before you had the data flows, it's going to become obsolete soon. And they are not able to move reliably data more than 10,000. And maybe with some tricks, which I have also shared in some blog posts in the past, you can go up to 100,000 records. But more than that's probably not possible in a normal way. But with PSD-towers, you can have millions of records in different tables and reliably moving them to the cloud or back. Yeah, awesome. Thank you. Yeah, we are a little bit running out of time. So let's jump in the ref at FireRun. That's, I make a short question and you give us a short answer. Oh, I know who. Dotnet Java, C# or PowerShell. Ah, maybe Dotnet. Visual Studio or VS Code? Wow, that's a different tool for a different job. But yeah, I would say Visual Studio. Rest or graph QL? Ah, nice one. Graph QL. Can myself some model driven X? Modern driven X. Power on automated or Azure functions? Azure functions? To encode or fastcode? To encode. General or agree? Ah, that's a very difficult one. agree. Text or spaces? Spaces? That would or light mode. Dark mode, certainly. The first back you ever fixed? The first back I ever fixed. Oh my god, that's difficult one. I don't really remember that. OK, when Microsoft can, you get all the money and resources you need. What feature ability build? In Power Platform, you mean? Yeah, you're free in the Microsoft ecosystem. You know, one of my favorite technologies within Microsoft's large ecosystem is Azure functions. Because I cannot imagine in any of the other Microsoft products, you don't need a simple to build compute runtime, where you can write code and run it easily and ship it easily or easier than Azure functions. I would have liked to see Azure functions everywhere. So within Power Platform, not outside. So you could write plugins and deploy them. But if you look at Azure functions, you have triggers. They could be your plugin engine. They could be your API engine. They could run within SharePoint. They could run within every technology in Microsoft ecosystems everywhere. Then that would have made it easier for everybody to learn because you would learn just Azure functions and you are able to develop for every technology in Microsoft ecosystem. And for Microsoft, it would be easy because you would just connect Azure functions to AI, where now you are going to connect all these different technologies to AI. Yeah. Then my last question, favorite keyboard, short cut. There is a lot of there. Or maybe a five for the developers. Yeah. Hita, thank you so much for joining me today. I really enjoyed this conversation because we went beyond the usual Power Platform discussions and enjoyed how modern engineering development productivity, AI solutions are coming together. It's really, really cool. So I hope we can do another session because I have so much more questions, especially to the governance stuff. We're a little bit short figure. Yeah. And yeah, thank you so much for being here. Thanks for having me. I really enjoyed it, too. .