Boosting Developer Efficiency with Power Platform Innovations

Mark Smith: 0:01
Welcome to the Power Platform Show. Thanks for joining me today. I hope today's guest inspires and educates you on the possibilities of the Microsoft Power Platform. Now let's get on with the show. Today's guest is from Montreal, canada. He works at Manulife as a lead power platform reliability engineer. He's passionate about DevOps and the power platform. His current goal is to try and help empower every power platform developer to do more. You can find links to his bio in the show notes for this episode. Welcome to the show, raphael.

Raphael Pothin: 0:46
Thank you very much for the invitation. I'm really happy to be here and to have this chat with you.

Mark Smith: 0:51
This chat has come about because we've had a discussion about the need for empowerment of pro devs on the Power Platform and I really wanted to have this discussion, as you being a developer, to understand kind of why, why the Power Platform, why you chose it, how come you, what benefits do you see from using the Power Platform. So, with that frame of reference in mind and of course, you've been on the show before, so if the guests don't know who you are, they can go and check out one of the past episodes that you've been on the air with but as we jump straight in today, in fact before we get straight in today, what's top of mind for you right now? What are you working on? What excites you? What's your focus?

Raphael Pothin: 1:41
At work.

Raphael Pothin: 1:42
I would say, due to my title and my position in the organization, I'm focusing on the governance, so we already have kind of a good footprint on Power Platform and good adoption in our organization.

Raphael Pothin: 1:54
But the reason I joined is to kind of to accelerate our governance effort to try to have a better understanding of what's going on with Power Platform at Manunife and to try to streamline a better understanding of what's going on with Power Platform at Manunife and to try to streamline all our governance work.

Raphael Pothin: 2:09
So from providing service to our internal end users, a kind of creation of environments and also all the monitoring to be sure that all the assets created in the Power Platform are compliant with some rules we put in place from a security perspective and health perspective, kind of number of administrators in an environment or things like that. So trying to build a portfolio of tools to try to simplify the work of my team as the team I'm working with and I'm lucky because I have the chance now to work not only on poor platform but we are also in charge of of microsoft fabric, uh but also have the chance to touch the ecosystem approach, to just not take a look only on poor platform but broader microsoft cloud and how we can leverage both Microsoft Fabric and Microsoft Power Platform to help all the segments in the organization.

Mark Smith: 3:08
This is cool. This is cool.

Raphael Pothin: 3:10
On the personal side. Currently I have kind of a passion about the Terraform provider for Power Platform. It's kind of a thing we discovered last year with other MVP friends and I'm trying to play a bit around it and explore what we could achieve from a governance perspective with this Terraform provider, because it's a technology used on Azure side by some customers and perhaps we could extend the capabilities of Terraform to the rest of Microsoft Cloud like Pro Platform. So trying to explore a bit this side.

Mark Smith: 3:45
Tell me more about that.

Raphael Pothin: 3:47
So, for example, I published and was working on an article recently to try to introduce the idea of, for example, not going to Power Platform Admin Center to manage your DLP policies, for example, because all this point click approach is error prone so your administrator can go and ask just to change one dlp policy to add an environment.

Raphael Pothin: 4:12
So to move an environment from one dlp to another, you have to go through two dlp policies and two many different screens. To achieve that, taking an infrastructure as code approach, to achieve that, taking an infrastructure as code approach, to do that you would be able to just change one or two files inside your repositories, go through an ALM process, pull request or peer review and just push your change and after that it would be deployed automatically. So it will allow to simplify, from my perspective, the process, even if obviously people need to learn how to use Terraform infrastructure as code. But it will provide some reliability on the process. So you will know what you have to change, not going to many screens in PPAC and then just to be sure that you go through the same process every time to deploy your changes. So DLP policies is one example. You currently, as a provider in experimental phase already have billing policies, for example. I'm not sure if it's used at many places, but kind of take the same approach for billing policies.

Mark Smith: 5:21
Interesting, interesting. I'll need to take a deeper look at that. I've not come across it before. One of the focuses, as I said, of this episode is to understand why do pro developers and we'll use that term broadly but people that cut code right as in, why, in your perception, do some love the power platform and then others feel like, oh, it's going to be too restrictive?

Raphael Pothin: 5:54
I think for some people it could be. It could come to the control perspective, because when you come to a sas platform like that, you don't have the control on all the layers of the application you are building. You cannot fine-tune all the, for example, the SQL part of Dataverse. You don't have the control here to fine-tune the performances and things like that. It's managed by Microsoft for you. Microsoft at least on the Dataverse side. I like the way they are doing that. So you lose the control on this part. And I guess some developers like to control all the layers of the application they are building, all the stacks from the front end to the back end and even sometimes the hardware they are working on. So for this kind of developers, they will need to accept to let go some of this control to be able to accelerate the time to market of what they are building.

Raphael Pothin: 6:45
And I think it's a trend we see in the industry right now when you take a look at platform engineering, all these kind of approaches. The goal is to simplify the work of developers. So take away the things. Perhaps they are less used to, or perhaps doing less often and to some. Another team used to, or perhaps doing less often and to some another team, and then they can focus on on the value they are providing to the organization building applications. So it could be for front end, it could be for back end, but they are focusing on on their expertise and they are both provide value quickly.

Raphael Pothin: 7:19
And I think if you draw a line with power platform, it's kind of the same. It's not really a platform engineering. You have it's Microsoft handling all the EV lifting for you on the compute side. The API you don't have to build yourself the API on Dataverse. It's already built for you when you create your tables and things like that and then you can quickly build your application on top of that. So I think for people who don't want to move to Power Platform, perhaps one of the reasons could be the control side. People who are used to use containers, virtual machines and handling all the stacks they have issues say, okay, I will just focus and create a Canvas app on top of the database and it will work and I will be happy.

Mark Smith: 8:04
But of course, ultimately, if you're creating an enterprise app, that would be a lot of work just to maintain an environment if you had to build it yourself. As you say, Microsoft's doing the heavy lifting. When you have conversations with developers and you're wanting to show them the light of the value of the Power Platform, what do you talk to them about? I think.

Raphael Pothin: 8:27
Personally, coming from a Dynamics 365 background and if I need to talk to developers, the best thing I find in the Power Platform is Dataverse. I find it complicated to build and maintain a good data layer. So even if you use a data service in Azure, you need to build all the things around kind of API to communicate to your data service all the security capabilities that it has provided. You need to build all these things from scratch. With Dataverse, you have this up and running for you and you can quickly start to build your applications. And it's not only you need to build it on Power Apps or things like that, but you can also use Dataverse only and build something in Azure Azure Functions, azure Logic Apps to communicate with your Dataverse, but you still don't have to maintain all these data layer APIs to communicate with this data. So I think you already gained some time on this part, and after you can pick and choose the elements available in Power Platform to where perhaps you have some challenges on your side. If your team is really good in backend development but I have some struggles with frontend you can use Dataverse, build a model-driven app on top of that and push all your back-end work inside Azure, in Azure functions, choosing the language you want. It's not something impossible and part of the things I remember correctly you discussed in the ecosystem podcast.

Raphael Pothin: 10:01
Microsoft has made a choice at the beginning to target a citizen developer and now perhaps some developers think it's not enterprise-ready platform.

Raphael Pothin: 10:12
But if you take a look at Dynamics 365 World, many customers have built huge Dynamics 365 implementations on top of Power Platform Perhaps not always in the right way, but at least the platform is able to handle the load and able to handle all the business logic you put into this kind of application used by the entire organization. So I'm not sure that currently the discussion should still be is Power Platform Enterprise ready? Because if you are smart enough and take a look around you, you could find examples of showing that it's a case. But you need to convince your developers and the right division in your organization to choose the right services in Power Platform. If you have front-end expert developers, you don't need to go to Power Apps, but you can still use Dataverse for your data layers and if they have some backend development challenges, you can also use CloudFlows behind that. So just choose the one that will help you, help your team go faster and get more value quickly.

Mark Smith: 11:22
So what about the developers that say, listen, I don't feel that there's enough, for example, alm rigor or source control or versioning practice? You know that's not up to standard. What's your response to that?

Raphael Pothin: 12:06
I'm not sure. I would try to give an answer for the low-code part because things are changing a lot right now around the low-code part with the introduction of pipelines directly inside the platform and more capabilities announced at build this year. Work I've done recently. All the pro dev or code first work you can still do around Power Platform. I would say, for example, pcf controls for the front end or if you want to build some Azure functions related to Dataverse, you can still follow for this kind of development similar practices you are doing on your usual code first projects, the back end side. If you are not touching plugins and things like that, you can follow 100, I would say, a usual lm process. If you are trying to playing with pcf controls only at the end of your process you will need to just integrate with power platform to deploy your pcF to an environment. But you can do all the first phases of development, I would say, locally or in GitHub code spaces implementing your PCF, doing local testing, implementing your unit test, running your unit test in a pipeline or workflow. You can do all of that without touching Power Apps or Power Platform. So you can do your work just like usual and then at the end of that. You just need to have the right team in-house to help you do the last mile, so be able to push your PCF to Power Platform. So after that the rest of the team if we are talking about Fusion team for example so local developers will be able to use your PCF component to integrate that to their front-end app and take advantage of that.

Raphael Pothin: 13:57
But I believe that if we are talking about kind of the fusion dev approach and you have pro dev contributing to to this team with mixed profiles, you can kind of follow on the ProDev side usual ALM approach almost up to the end. And because the ALM story around Power Platform is, from my perspective, really different of what you can find in the code-first world, I would not encourage ProDev to go straight to. Okay, I will play with the LM story in Power Platform because you still need to kind of relearn a lot of concepts, solutions, solution, layer dependencies, all these kinds of things you will need to learn if you want to really play with the LM process on Power Platform. But I'm not sure it's where you will be able to bring more value to the organization. You can still contribute as a pro dev to your Power Platform footprint, without trying to think about all the specific Power Platform concerns.

Mark Smith: 14:58
Yeah Is in your mind. Once again. Pro dev comes to you says listen, I've heard about the Power Platform and I want to know where the cliffs are. Where am I going to run into a wall and not being able to do what I would traditionally be able to do? What's your advice?

Raphael Pothin: 15:16
Everyone joining kind of the platform ecosystem to build something will need to understand that they are building applications or solutions on top of an existing platform. So you still need to play around the platform constraints themselves. An example Dataverse API. So you cannot kind of push data to the Dataverse API without limit. If you think that you should definitely read the docs, you have a threshold, so you have a small time window where you need to limit the number of API calls you are doing and even on the 24-hour period you need to consider the number of API calls you are doing with an identity. So this kind of limit I think are with all SaaS platforms. So any developers joining this ecosystem who want to play around that need to be aware of these limits and constraints. And after that, I think it's more around architecture principles.

Raphael Pothin: 16:19
Since a few years now, many people in the community talk about the fact that you can do almost or perhaps everything with Power Platform. I think it's true. I believe it's true, but I don't think we should build everything with Power Platform. There are some things that are less performant on Power Platform side and even if you can do that here, you should perhaps move to another side where you will gain on the performance, on the security, all these kind of things. So you need to play with all the components in Microsoft Cloud to achieve the goal. But, like I said earlier, I love Dataverse, so I will always start from that. But after I will perhaps, for example, try to implement something in CloudFlows. But if I have a CloudFlow that will run for seven hours, I know that I perhaps have something not perfect here trying to improve the performances, because you don't control the compute behind the scene or the scaling behind the scene. You have autoscaling and we know Microsoft say we have autoscaling. It's a case, but sometimes you need to fine tune it and you need some controls around some business logic. You implement it's a case, but sometimes you you need to fine-tune it and you need some controls around some business logic. You implement and you will, in this case, need to move to another platform.

Raphael Pothin: 17:37
So, being aware of what you can achieve and what you should not do with power platform, it's an important concept and I think it's more on the architecture side of the developer job. But when you design your application and when you think, okay, I need to implement something, you can start with Power Platform because it's quick and it's perhaps easier. But if you don't reach the non-functional requirements, where you discuss with your team on your Power Platform implementation, you need to stay open-minded and try to take a look around and see if there are no other tools you can use for this specific task, because, being in a SaaS solution, you can have limitations and I think more than the Copilot Studio it's perhaps also the case. You can do many things with Copilot Studio. You can build many things with Copilot Studio.

Raphael Pothin: 18:29
You can build many things, but Microsoft is already telling people that when you reach some requirements and when you have some needs, you should go to Azure, ai, openai to be able to achieve more things perhaps, or in a more efficient way. That's what you could do in Compiler Studio and obviously a citizen developer will perhaps not have this choice and we hope that they will not reach the limit of what a Power Platform can provide. But on the pro-dev side, you need to keep this information in mind to be able to say, okay, we've reached some limits on what a Power Platform can offer in terms of performance, security or design, so we need to consider perhaps another approach for a specific task.

Mark Smith: 19:18
Nice. Are there any resources that you recommend for pro developers that are coming across to the Power Platform that they should get you know to help them learn, get up to speed as quickly as possible? What do you normally refer them to?

Raphael Pothin: 19:35
That's a good question. I didn't, to be honest, I didn't add too many opportunities to refer them to resources, I would say I guess, because I'm not often there. I guess Microsoft Learn has some path for ProDev with Power Platform. So it would be definitely a good start, at least After that, staying in touch with people in the community, because in the BizApps community I would say Power Platform and Dynamics 365, we have people focusing more on the ProDev side. So these stories already exist somewhere, so you can take a look at blogs or content people in the community are sharing regarding their own journey. Because we already know inside the committees and even with the MVPs, people coming from a pro-dev background and who joined late the Power Platform ecosystem and now they like playing around Power Platform and developing applications on the Power Platform ecosystem and now they like playing around Power Platform and developing applications on the Power Platform. So finding these people in the community on top of what you could learn as a starting point in Microsoft Learn, could definitely help you engage with Power Platform as a product.

Mark Smith: 20:47
I like it. At the start. You mentioned you're going down this path of Microsoft Fabric with Dynamics and I see it's a massive growth area. We've been talking about it a lot recently, in recent months. What's your foray into bringing Fabric into the mix in what you're doing?

Raphael Pothin: 21:09
Yeah, in my previous experience I remember one scenario we had. So we had many integrations pushing data to a Dynamics 365 environment and on top of that we wanted to do some calculations on some data you have in your database environment and you push them through integrations and doing this calculation into an integration process is not really effective. One scenario I really liked when I see it in Fabric is the fact that when you integrate the Dataverse environment with Fabric, you can then build other tables where you will do your calculations on Fabric's side and then, using a virtual table, you can bring this information back to Dataverse. So you push the EV lifting you could have in your integration layer to Fabric and I think Fabric is perhaps a better tool for this kind of workload compared to your integration route. So it's what we discussed earlier choosing the best tool perhaps for each task, and in this case I like having Fabric in the loop.

Raphael Pothin: 22:17
One other thing I've personally convinced Fabric will help is that for big organization, if you're able to bring most of your data in Dataverse.

Raphael Pothin: 22:26
But it's also the case with Data Lake and things like that.

Raphael Pothin: 22:30
But One Lake approach allows you to have a global view of your data so you will be able to analyze what you have, combine what you have, perhaps clean things, eliminate redundancy of data in different environments and things like that.

Raphael Pothin: 22:46
So for everything we see regarding AI and the need of good data to be able to drive AI, one leg could be at the center of this, because it should give you the right visibility on your data in your organization to be able to clean, prepare your data for AI after that. So I remember because just before Fabric, perhaps, some organization had to build something similar in Azure, for example, where you add many data lake communicating between together to each data lake for each data domain and things like that. Now you can achieve that in an easier way from my perspective. Inside Fabric, obviously there is a cost, but because it's a SaaS, so you don't need to think about the cost one-to-one, because after that, if you had an entire architecture in Azure, you had the cost to maintain your infrastructure, the teams working on the infrastructure, and with Fabric, you push that to sell Microsoft because they're under the infrastructure, they're under the people managing the infrastructure and after that you can gain.

Mark Smith: 23:55
I like it. I like it. Before I let you go, tell me a bit about Manulife. I first came across Manulife when I was in Hong Kong and I was talking with the Manulife team in China at that time and then I also came across it in Singapore and then a couple of other Asian countries where Manulife were growing. So just first of all, what does Manulife do as a company? And then let's just jump in and talk about just first of all what doesn't. What does manulife do as a company? And then let's just jump in and talk about the sizing of the type of things that you do on the power platform uh, yeah, um.

Raphael Pothin: 24:27
So money life is uh in the finance industry, mainly on insurance, but also we I think we have a small bank uh part footprint, at least in canada, and we are present worldwide, so mainly Asia, north America and from a scale perspective, currently, for example, we have a bit more than 300 environments on Power Platform side and the story on Power Platform started, like, I think, many organizations, on the Microsoft 365 ecosystem. So you extend what you can do in SharePoint list with Power Apps and things like that and also a lot of cloud flows to automate and increase the productivity of people in the organization. And now we really see the value of Power Platform and it's why I wanted to join. It's to kind of accelerate the great work the team has already done internally to be able to get more and more value from Power Platform, for example, perhaps working more with Dataverse to be able to move away from SharePoint for some more important, I would say, applications and then continue like that using Copilot and all Power Platform capabilities.

Mark Smith: 25:39
Nice, and I know that data sovereignty is a big thing in the financial sector. Has Power Platform met those needs across the various countries that have those geographical requirements around where their data sits?

Raphael Pothin: 25:57
In most cases, I think. Yes, I'm not at Moneylife since so long and I don't know exactly what I can say, but we work mainly on three regions in Power Platform. So most of the time for shared assets, for example, we will be able to provide things in our three regions. And then for specific needs, when a team come to us and ask for a set of environments, they will need to provide in which region they want to be in the three we provide. And I know that, for example, there are some limitations right now due to the platform and the data centers presence. We are, for example, if I'm not wrong, dynamics on-prem instance that we cannot yet move to the cloud because we don't have the right data centers available from a data sovereignty perspective. But I'm sure Microsoft increasing their presence across the world at some point with this region and we would then move to a cloud approach because I think it's part of Manulife's strategy to move most of the things we can to the cloud.

Mark Smith: 27:03
Nice. Any final words you want to say to pro-divs?

Raphael Pothin: 27:07
Try our platform and try first Dataverse. Play around it and see how it's great to have this API available. So personally, I find it's great to be able to create a table from a UI or if you want to try more exotic ways, you can, but being able to have a table and after that all the APIs available to work with this table without doing anything more is I find really great. So I would encourage ProDev to start from there and then, if you want to increase your own productivity, explore Power, automate and Power Apps. I personally use Power, automate and Power Apps for my own productivity at work. So sometimes if I find I have some struggles to gain performance, I would try to automate something or try to explore there and you will be able to gain some knowledge around the platform, doing that and increasing your own productivity. So it's a double gain.

Mark Smith: 28:09
Hey, thanks for listening. I'm your host business application MVP Mark Smith, otherwise known as the NZ365 guy. If there's a guest you'd like to see on the show, please message me on LinkedIn. If you want to be a supporter of the show, please check out buymeacoffeecom. Forward slash NZ365guy. Stay safe out there and shoot for the stars.