Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

0:00 Welcome everybody to the M365FM podcast where we explore the people ideas and technology shaping the M Microsoft 365 power platform Azure AI security governance and modern workplace. Today we are going behind one of the most common descriptions of Microsoft power platform, low code. Low code has opened application development to much broader group of people. But what happened when the application becomes business critical when you need to integrate APIs, Azure services, complex data model security automated deployments, monitoring performance and multiple development teams working on it.

0:44 At this point, power platform is in simple a low code tool anymore. It's become an enterprise application platform and architecture starts to matter. My guest today is I'm 3D solution architect and senior technical consul and specialized in power platform Azure and technical delivery in helps organizations designing practical secure and efficient solutions that solves real business problems with particular focus on architecture automation deliver leadership and making technology work for the people today. So we are going to explore what happens when power platform goes beyond the low code architecture complex solutions and so on to pro code and so on.

1:32 So yeah, welcome to the M365FM podcast. Yeah, thank you very much. Yeah, I do spend a lot of time looking at when we want to build something with the power platform and it is a fantastic tool for getting 80% of that business value. But nearly always when we come across an enterprise solution, there is that 20% that is unique to that particular organization that that particular organization needs where you have to go beyond that, that kind of no code into the low code nest of the. And it's an important thing to recognize is the fact that it is a low code platform and what we mean by that is there's not 50,000 lines of code, but you may have 100 200 300 lines of code and it's important to recognize that and if you if you treat it as a form here is much for you out of it.

2:28 That's interesting, but before we keep that into the topic here before you we make it really technical, I hope we get deep in it. How did you end up working with the power platform? Well, so I did a bit of a data role and then I've done a number of different roles over the last 20 years are starting off with service desk and running my own freelancing consultancy to building websites to then getting a job doing data in a government agency analyzing data and looking at how that data was moving around.

3:14 Then I touched the dynamics as it was known then for the first time I was still known as dynamics, but we all know it's just the first, but it's just a power act. But don't tell that too much to the dynamic people might get upset. But, but you know when we were looking at dynamics building custom tables, then I moved off that and I moved into the world of office 365 migrations and as your migrations, which was quite you know a little journey I took about 2015 and I became an IT manager. And looked at moving largest rates to the clouds and then did consultancy off the back of that for a little bit certainly during COVID I moved a large number of organizations to the clouds because people were contacting us and saying look, you know we're closing down our office in two weeks time.

4:04 We've got a server it's sat there in the room, what do I do, how do I get it into the cloud, I don't really want to I can't really bring it home, it's not going to run on my internet connection and you know these kind of you know quite interesting migration jobs and then I kind of went back towards the power platform in a way looking more or more around how data was moving and kind of these apps side of things. So I kind of I kind of been all over the place a little bit I even touched something called asterix and build telephone systems for a little bit of time. Why quite an interesting dimension, but I've settled really on the power platform and really I I sent her around how business uses technology. So more business using technology and and kind of going and the power platform is just one of the current thing that enables that it's not going to take either things ever but I think it's the current thing that enables that.

4:56 You have a lot of people to question you say some things interesting you say power apps can or it's normally I don't know. So you have a lot of codes, whether you do it and you also say dynamics is also built a bit of power apps and I think it's as a little bit more code. Is there any limitation? How many code we can write in one application in in. Before we get trolled by all the people who do dynamics is it's a real what what part of dynamics we're talking about because in true Microsoft style there is more than one product dynamics although branding is is quite quite well done.

5:41 But if we think about sales and customer service is there they're now known but at the time when I was playing with them, you know, it was dynamics and dynamics see our. So when we look at it on top of the power platform and opened up it's kind of self underneath and said look you know you can build stuff that isn't just sales or customer service or really just piece of marketing in terms of limiting code that there are your operating inside of a sandbox really you operate in inside of a safe space. So you can't just write what you want that you can push quite far so with PCFs you can do an awful lot with power pages you can do more and we're seeing that really come to life now.

6:28 You know up until recently you can only do client side logic now we're starting to serve a side logic creeping. With things like plug-ins and custom custom connectors you can reach out and do a bit more things but it's more about looking at the right solution for the right situation and the other thing I tend to find a lot is. When we're building automations or we're building the right solution we need to be executed because if we just plummeload a JavaScript in and we are going to make some critical business decisions based on that JavaScript we need to remember that that's going to run client side and someone could manipulate it.

7:18 And if they do manipulate it what's the impact for that going to be you know if it's something that has to be right and always must be accurate then we need to execute that server side and then do we need to execute it synchronously so the question can be vastly different as to where you got. But when you see or when those power platform solutions stop to being a local application become an enterprise software. So I don't think there's a difference between low-coded and enterprise I say there's there's where they become more complex is really when you're when you've got multiple.

8:04 Multi would different user flows or user journeys running through them. And you're doing more than just something as simple as looking at desk. We've got multiple people interacting with multiple different teams and you've got all these streams coming together you have to start thinking about your architecture and you need to break it down into modules or features. And you need to decide how those modules or features going to interact with each other and you need to start just seeing the principles of clean architecture you know if you Uncle Bob and some of the stuff he's written over the years. And you may look at it with that only applies to a pro code world it doesn't it applies in the low code world and it is a low code world not a no code world.

8:50 And when we're applying it in that low code world we have to think about you know how are we going to make this not. It's nest how are you going to make it so that when support get hold of it they can understand where the problem is how are we going to make it to reach feature or reach module rebuild. And it's clearly interacts with other features of modules you know other parts of the solution but also has only one single purpose it doesn't try and do everything as soon as we try to make a module or feature do everything it becomes really difficult to build really difficult to develop and really difficult to test.

9:30 Yeah, what I see I have developed a long time on on my own for the podcast for my own solution since I think it's seven or seven months or so. And I have started with with local then oh oh I can use co-pilot in it it's really cool. And it's become yeah critical to handle I say one back there I say fix it next back there fix it then the next back is there it's it's it's really. It's feel a little bit depression so.

10:13 So for me is it's it's the change I know I use the I as co-pilot studio no I'm an original studio and now I have downloaded to visual studio and you use use it there I also use. And I'm on the bottom side so I'm on the bottom here boring that lazy lazy guy so did you think there is a line between local and pre-ocort or is that distinction becoming meaningless. I don't think I think there is a distinction in terms of skill set and I I don't look at a business problem.

11:01 You know look at an assistant we are building and say oh that's a low code a no code or a pro code solution I look at it and say well what what features what modules do we need to develop to deliver this and can that feature or module be developed. And you know what's the best way of delivering that feature or module and you know you talk there about you know you had a bug over here and he had a bug over there and then a bug over here. And what we what we tend to find is when we if we don't split up our architectures into separate parts separate features or modules. And then we end up with this whack-a-mo problem where we fix a problem over here but then a problem pops up over here so we fix that one and then something else breaks over here and this is why it's really important to break down your architecture because if you break it down and you practice those principles of clean architecture which aren't my principles you know they're there.

11:59 And then you know from from Uncle Bob and various other you know architect obvious we're far more experienced than me what what they what they tell you is you when you break things down and you give some clean interfaces between them that it takes sending an email is a really simple one. Okay we're going to send an email are we going to use a connector to send emails in every single blow that we have where we need to send an email. We need that but then we're quite closely couple thing our flows to our sending of emails. Well what happens if we need to send emails in a different way what happens if we need to use sends grid instead of outlook or what happens if we need to use a different method.

12:46 Well could we call a child flow every time we want to send an email could we call a child flow yes we could but what happens if it errors how do we test it effectively how can we break apart those tests and almost conduct unit type tests. Well let's say well instead of sending an email directly from our flow let's dump a record into a table and we'll call that our emails amp bound table just like outlook does. And if we do that we then can have something else that comes along and says right how many emails are in this outbound top 50 and I'm going to do that every five minutes and the reason I'm going to do that is because my current API limits limit me to sending 50 a minute or whatever.

13:33 And what you've done there is you've separated out your features so that if one thing breaks it doesn't break something else and also if you need to change something you're only changing that one feature you don't have to change everything else so you don't end up with this whack emote effect and this ripple impact effect in your whole a whole environment. So it's not I know it's not really a good description but I try when when so the difference is is we have the power platform and it assesses framework and then I have another architecture.

14:15 So the different one or a complex one is this the different from from from local to to pro code. You should you should break them you should break them down into to sensible chunks you should break them down to to usable components and I don't want to say components I'm not talking about the individual components you find inside the solution. Yeah talking about these modules so you you could up something where you've got a front end that is using canvas app. And you know well then calling a power to make power to make flow is then calling a connector that custom connectors then calling a whole load of stuff going on.

15:01 But you you'd set out those separate parts so code is you could just be 20% if your whole application in fact I've seen systems been involved with systems where the low code element is looked after by one team and that really represents 20%. And then you all pro code type stuff going on you know AWS and Amazon and so AWS and as you're and better GCP and you got these other components sitting out there that are then doing other bits of work and really the power platform is used as a front end. Interfacing with a very small part of the system now why does that work well power platform is very easy to change and edit.

15:46 So if you've got your small 20% front end if it's receiving 4 bits of information and it's output in 6 bits of information to another system. Then that's all that you need to worry about. Your business process will change far quicker. So if you've got if you imagine you've got your inside of a company and you've got a power platform application which your team are using. But it's receiving 4 pieces of information and transmitting 6. But it's chatting to some kind of pro code solution that's been built by some other teams.

16:27 Your local solution or no code solution can move forwards as your team needs change let's say you just are going to change your team's business processes. You can change your business processes within side of your team and you can update your power platform solution your little part of the jigsaw puzzle. So long as you're receiving those 4 bits of information still in your transmitting those 6 it doesn't matter you can iterate your your part of the jigsaw puzzle. And I think you know I go back to your question of you know you got this pro code world in the local world. I don't see it as pro code and local I always see hybrid model is possible.

17:08 And as soon as you start making that decision oh that's a low code system that's a pro code system you go and do out this situation. So you're trying to make you know you're trying to fit a square peg in a round hole. Yeah awesome. I think also that's also a bad word but I think the local stuff is really cool to build an MVP are I mean minimal viable product the might of data. I think it's also nature over the time so I think more as first we have all builders and we have only one one solution and then came the data.

17:56 The data. Data model apps are the renames of it's it's like something like when you look at a data worse than a implement data worse. I think also as I started it's called common data service I don't know or it was something wrong. I really run with the names I don't know I'm so overwhelmed with the renaming. So there it's not the hard line we say that's it's more liquid to get there. But I think that's a little bit better to low code developer and pro code developer and I also think okay.

18:44 You say the 80% can develop in low code. But the I think you. What what a lot of people misunderstand it's it's coding it's not only to do right good code it's also to understand the architecture. And how will you say. Yeah. We have these other tools and this is more more implemented. So I think a little bit about Azure and all all these I don't know 100, 600 services.

19:24 And so on. What did you think when we need in real architect and or should we start every time with architecture. What when that's what what the best solution and yeah, how how we can this this figure out the liquid line. I I do think it's not an easy question to answer. Because you know you have to think about why we. We want to sit as developers in the power platform. Why do we want them building these business applications.

20:08 Well, the reason is because of translation. Often these people live and beat breed these processes. So they know how to make the application fit their needs better than anybody else. Because you've got less people involved. If you go back to school and you think Chinese whispers. And how something can change when it goes through 10 different sets of years. We have the same problem when we're building solutions. The more people involved from user requirements to building the solution. The less reliable that's going to be.

20:51 However, as you pointed out we have another problem. That's used to building a business application. The person is the more likely they are to architect it in a way that isn't necessarily efficient. If we think about normalization. You know I came across a project where someone had created more than 450 fields on a dataverse table and applied 40 business rules. And they are. And they should work. But it's a bird's nest. Bit like that. And actually would be far better off looking at normalization.

21:34 So you have these two forces at play. And that's where you've got to think about. No, when is the right time to have just enough architecture at play. And I think that that role of reviewing what is going on is important and looking at the number of users. What is being built is going to impact and what the criticality of off that service. You know if it's something that's critical and is is needed to deploy something that's life saving. Or is going to impact the finances around the business. Then you need far more governance and architecture involved. If it's something that is you know if it doesn't work. It's a nice to have.

22:14 And then you probably don't need to involve the architects and you can let them get on with building you know 400 fields on a table and applying 30 business rules and crying when it doesn't work. But you have these two forces to play. And the reason why we love the power platform is not only can you get an awful lot of business value very quickly in a very safe place. But also you can hand the platform over to people who are not you know not hardcore developers not not as experienced in that development world. And that's extremely experienced in what they do day to day. But the problem is you do need to meet somewhere in the middle. You know we've all seen really horrific Excel spreadsheets and that's in Excel.

22:55 We've all seen horrific access databases you know you know they still exist out there. So you do have to you do have to draw a line and it is a weekly line. And it comes down to organizational risk. What's the risk profile about organization? How willing are they? The things to go wrong and what's the business criticality? And you can't strangle an organization because if you strangle an organization you say why every single app that someone wants to build must go for this rigorous process. What happens is you end up with a little cottage industry growing up and you get this cottage I.T. industry that springs up where you know.

23:36 Someone over there in the corner as the stylist make this Excel spreadsheet and there's put some some VBA in some horrendous stuff like that that isn't supported properly or isn't really accepted anymore. And there's built this thing and before you know it's used business is become business critical. So if you're too strict in your architecture governance. What you do is ever cottage industry and it happens you see people you work around with human beings human beings will always find a way around the problem. You know we would hear today if we weren't really good at that. I think the question you have asked is really interesting. I think why we have citizen developer's not I think it says two reasons.

24:20 So for me or for my department I can make things simpler. But the other thing is we have external and implement knowledge in a company. So and when I don't know I say I'm a flat manager in the company with 10 cars. Then I can build this simple solution and everyone can book with some rules behind the management level or something else. And I think that's really cool and also we don't lose this knowledge from this guy because I don't know why he knows.

25:02 This was I work on for we company and all they have the expenses blackberry dudes that was the people there are first draft in this time. It's a lot of time ago. There was people don't know blackberry anymore. But I think then but when you have you know the fleet manager you have a or what's the word like six and six and so on these big car companies. Then you need different kind of handling you need. I don't know you have I don't know thousands of stations and it's a more complex system.

25:45 I think yeah that's the city they want about and that's for me then enterprise you can it's built like in. Yeah like these MVP example how does this process work at my station I show it to you and can you implement it to I don't know to the rule system. It's yeah it's not the blueprint I say for I don't know it's good I love I don't have a driver license or another expert that example but I think okay I living in Germany and on on we need this in the contracts for cars but it could be completely different in the US or in Spain or UK or Berlin.

26:28 No and I think did this is also be a thing where I need a fast really good working solution because when everyone builds their own thing and give it to a big system it could be I don't know it could be a lot of day job that's our. Similar but that only one field and I build it every time and it's better to have a concept that are an architecture could this be the sometimes of difference. So if we think about common situation is where business has a couple of common things they need to communicate amongst the whole organization.

27:17 But they they also have a couple of things where everyone does their own thing and this is where using the right architecture and the right system and power platform can be really helpful so if I think to when I used to work with government funding. So quite you know many many moons ago we would have national requirements for government funding and what needed to be recorded but also we had much more local requirements as to what we needed to know for the funding in our particular area.

28:02 Now the national items existed inside of a national database but we couldn't add our local items to that database. They weren't interested in us adding you know we want five fields here and you can understand why because if everybody that was giving out you know every single you know sub body or sub organization was giving out this funding added their own you know 20 fields to it it would be a mess. And it would be a nightmare to manage so what does that mean well right then that meant ended up with two systems in double entry.

28:44 And one of the challenges I had at the time was how do we make that one system with single entry. I can't dig too many mean extremely details as to how I achieved that but you can achieve that with something like the power platform where you can extend and you can get you know if you can get an API interface up to that central system then everyone can do their own things their own way and just report back or communicate almost those those five or six fields where they have to be recorded in central system or five or six you know entities. But they've got to be in the central system and I think that that's a real option in the power platform because you can develop in that way but you have to think about your architecture in the right way you've got to you've got to consider what what is you going to do how it is you're going to allow communication and and you have to be open to democratize your environment.

29:50 Now I can see this really coming into life with things like AI because not only are we got more capability to develop those solutions more locally. But also you're starting to see organizations create internal mcp servers you know we look at say time shooting for instance something which in the consultant world we all have to deal with. Whether we like it or not we we we were starting to the mcp servers being created on the back of those time sheet systems which then means that we can write something to win a face with that mcp server.

30:33 Which means we don't have to use the time sheet and software that maybe we're not a big fan of. Or is it you starting to see this this almost democratization take place and I think you with the right architect sheet and see that happen. But you almost have to build a system so it's open to that the central idea has to be where we're open to time sheet insistence being interface with people with that and applications and we're going to put these governance around it but ultimately you know as long as you've got the right to open to communicate with it you can update whatever you want. It's a really interesting part what I often see it's now a lot of a lot of developer also proc what you're supposed to start with was tokens and and evolve and I think it's a good idea.

31:23 But then we have processes I say what process can we take let's take the mcp. I say share point I can do it with mcp I pay for for tokens or I used to graph API for doing I know no governance stuff it's pretty nearly free when I see the price difference so it's it's I think the I don't know the wipe coding code be also getting more expensive in the world time when when I doing simple processing. With mcp or AI and use all the tokens every time in every process I think that's it's for for me an interesting architecture question because I don't know a lot of people especially linked in a post oh I have spent this week 80,000 dollars in in tokens yeah I'm the best guy and I'm the expert and I think okay you feel you're not expert because if you have used.

32:31 This or that you have paying nearly three dollars for computing. Yeah this this this this I think a good example for for architecture but I will look a little bit into the Azure platform and I think power platform has has really good integrations to the most of the tools but there are also tools like I don't know. So tools like I don't sphere or a foundry but when I look into foundry you can doing so much more than you're doing in power apps.

33:15 Can can power apps first can power apps be a pro code tool or did I need like. So you if you need your preferred idea really so if you want to use visual studio use visual studio you want to use VS code use VS code if you want to use a terribly different idea you want to use no pants and you feel confident enough to use no pants. You can the advantage of course with with your idea is they provide help you know they find little tools to help you debug what it is you're trying to do they will tell you when you've got something wrong so you can use a lot of different tools but it just comes down to what's what's your preferred idea what's your preferred method of editing those text files.

34:22 But there's no need to necessarily buy something particularly expensive but like with anything you know people are paying money for these tools for a reason and that's usually because these tools help them. Now if we go back to thinking about some of your points there around people burning 80,000 tokens building a solution in a week or 80,000 pounds worth of tokens building a solution in a week and not just a token is a pound by the way that would be extreme because you imagine it none of us would be touching this stuff the the question I would be asking is are we splitting down the solution that with you know the system that they're trying to build to a stage where we've got lots of features or modules each doing a single purpose and then communicating in the right way you know communicating in the facing with each other or are we just working everything in a one prompt and you know it's spewing out this big blob of code and we're going to say it's a magic box and it does that thing but we don't know how well it does that thing we're just crossing our fingers and hoping for the best and if we go and look at it it's all spaghetti you know is that what we built and I think the follow question is do we care now I think we should care I think we need to care because at some point something in that he's going to become deprecated something's going to need replacing something is going to need to communicate with it all we're going to need to extend it.

36:01 And if we need to extend it or change it or alter it we want to be able to just also that one piece not rebuild the whole application you may say it's a small application doesn't matter we can just rebuild it every time well if it's just one of applications rebuild it every time I'd argue it's probably a single feature in which case you're doing exactly what I want you to do and what I think you should be doing is building things are small enough so they're modularised or featureised so they're building blocks that can then slot together it and you know if we go back to the platform. And if we think about Nissan Nissan so Nissan just up the road from me here in the northeast of England and you know Nissan get assembled parts of cars to put together.

36:46 They don't build the whole car in that Nissan factory they don't produce tires in that factory now someone somewhere making shoot me down but I'm fairly sure that they don't get all the various materials arrive at the factory in trucks they get you know glass from somewhere they'll get tires from somewhere they get these components and they put them together and I think sometimes with the power platform and sometimes with some of these. We go around them go well we've got these tiny little pieces of Lego and we're going to try and build a solution with them and I'm like hang on a minute.

37:27 That's bad what we need to do is we need to make our tiny pieces of Lego in a steering wheel we need to make our tiny pieces of Lego into wheels we need to make our tiny pieces of Lego into gearboxes into engines. And then once we've worked out what we're going to make our engine look like we then go drop our engine into every single car that needs that engine. We don't try and build entirely from just the little building blocks because if you do that and you do that on scale you know let's say you're running an app factory and you build every single app in its own individual way. There's going to be someone downstream from you in support who's looking after 400 applications that all have a slightly different case management system.

38:12 They're all running a slightly different way that don't follow any kind of patterns or practices and they're going to cost a fortune to maintain developing upkeep so. It is important to try and feature as modularized our solutions you can't just you know put your fingers in your ears and try and build this spaghetti and hope for the best whether you're building with your ride coding something or whether you're building something on powerful or whether you're building something you know as a developer you know just right in C sharp and you've got 50 developers on hands. You have to still break these things down into their their their features their modules you can't just expect to try and build the whole thing in one go it doesn't matter what it is your building I think those core principles this core architectural principles don't change and haven't changed for years.

39:06 Yeah the first thing I have think more in England and mini Android's but this is also a good example okay it's both no BWM but yeah. What I see or I sometimes feel a little bit uncomfortable it's it's that so many logic list in power apps and not I say in in as a function or so what actually stop to work it's it's too hard code. Something into then they say oh you you cannot hard code it and I use the keyboard no I have to use the keyboard of course it's not working when I use a IP I saw something I think that's also an interesting part.

39:57 What did you think where do is the I say the happy management fit in is happy management something more power platform architect should understand and should they use error or it's fine to have it in I don't know in power platform. Interesting question so we're thinking about where we should store secrets and keys. The question I would always ask is is where we're storing it reversible.

40:42 If we're storing it in a place that's reversible then we potentially shouldn't be storing it there unless it's somewhere like key vault where it's got the right governance around it. So I've unfortunately over my career seen people store secrets as environment variables that's always a bit risky because anyone is an administrator on the system can look at it. Environment to take environments variable is ultimately a table under the hood and I could accidentally be exposed. We could not execute in a way that there is a way to store secrets as an environment variable because you essentially store them as they're address inside of the usual subscription which is like subscription slash resource group slash key vault I can't remember it off the top of my head I left it out but there's a right way of doing it.

41:38 So what's the governance around it what's going to be the need to understand the usage of that's do you need know each time it was accessed and when it was accessed or do you not and if you need that tighter governance around it then yeah spinning it up as you know you climbing it by and as your function and exposing that as your function using a PIM into your power platform is probably the right way to do it. So you're doing something that's that that complex and that you know that secretive you are going to want all that logging around it and you're going to want to expose that as you know an internal API but then that internal API is going to have a secret.

42:23 So even if you expose it from API and you're still going to want to expose it with the secret you're not going to just expose it onto public in and then hope for the best idea because you know you haven't really achieved anything there. And when you do expose it you're all you've potentially done is you've just moved you've just doubled your problems so if you're going to have it exposed as a function and you're going to have you know you're going to access key vault from your function. And then you have to ask yourself why you're doing that. What is what is the business need for doing what's the need from from an InfoSec point of view because are you just going to have two sets of keys.

43:05 Now one of the answers could be that you're going to publish this as a service you know that say you've got a service to access a certain type of information and you're running an out of factory. And you want to build this once and the direct access to this particular system you're going to keep in a key vault and you're going to have and as your function go and fetch it from that system. And then you're going to expose it to the power platform through API and then you're going to limit how much usage all your environments can have against that and that gives you obviously things like mocking as well.

43:46 So it's about doing it in the right situation. The right particular for the right problem. Don't just do it because you can't because if you just do it because you can't know we've spun up a function because we you know we want to store in a key vault yet but how are you going to access your function. All you've done is proxy proxy your connections to your key vault you're still going to ultimately store. You know that secret somewhere and if you have to store that secret inside of your power platform inside of a connector which is you know you can't necessarily reverse it out of that. Then what why why were you unhappy with storing it just there directly so it always comes down to like what why is it you're doing this can you think through what your logic is and you could have some good logic or you could have some not super logical.

44:35 So it's always fascinating to ask that question but what is it what's the problem you trying to solve by doing this. I think we have the citizens in Budapest or I think they're a better word it's the power platform makers I think Microsoft use it. What did you think about show day understand using gifts so they understand CI CD or. It's okay to do it. I did it my way I frankly not as well. It depends if they're using if they're working with any other you really and what it is they're developing on if you're developing something like power pages.

45:19 It can be really handy to do that using it because your conflict it's very easy to accidentally conflict with someone else. Unfortunately when you're working the power pages. You're really just editing lines in the table because power pages is still stored as lines of a table. I don't think it's a difficult thing to understand. I do my architecture on most projects using a get repository and usually with less than half a day of workshop.

46:02 People who are non technical like bays who are usually quite non technical. I can get into a comfortable position using markdown files and pull requests and they seem quite happy with it. I don't think gets a particularly complex thing to understand. I think you've got to use it in the right situation. I think one of the issues with power platform is. How do you how do you use that with get because you're all editing the same source. So are you going to just have one person inside of that developer or build environment. And then are you going to you know, ask them to commit you know, you know, run a pipeline and say a do to pull those changes into a get repository and then you can mark those changes being part of that particular ticket.

46:53 Well, yeah, you could for what's the benefit of that. Well, start an approach. If I can take I do tend to try and push towards is that we. We keep our features separate in separate developer environments and we bring those in to a get repository and then we deploy them into the other repositories. But you have to be really careful if you're going to do that because you'll need to watch out for cross dependencies. So you have to I get back quite carefully and you have to think how are you going to make sure you don't. And you can't across dependencies. But if you can split up your solution.

47:35 And you can get it independently deployable. Then your father better to give one developer one environment and one get repository. And that way you know that person's responsible for everything in that. But it's not always possible to do you have to look at the size of the solution you're trying to solve. And there's there's I always say there's a least worst option. There's never a best option with this. You know this one's really be worth and you know, a common common pattern I tend to use for doing this is we'll have two or three developers inside of a build environment. And we'll have run two pipelines off that build environment.

48:16 And then they finish a sprint or they're happy to do a release, you know, we've reached the end of a piece of work. We'll do we'll run it as your DevOps pipeline that will take the latest version of that. And that will be that that sprints build and we'll put that into the test environment from with that is, you know, you can get to all three different things in there, which can upset, you know, a lot of the, you know, it does go against that kind of a pull request should only contain one one particular thing. So you can go back the other thing I tend to do. If we're using a shared build shared development environment is I will take our separate pipeline, which will take a copy of the build environment and run it on a schedule into a Git repository every six hours.

49:07 So 12 o'clock and at six o'clock every day. And what that means is we've got a copy of what happened in that environment, unpacked in source control. Should we need to know, oh, this power automate flow changed with it's go find that flowing source control and it's see when it changed. Within six hours you can go to get, but like I say it's a least worst option. There is no perfect way of doing a proper source control with our platform. You have to really take your least worst option. And someone somewhere I know that will shout at me and tell me, oh no, there is and yeah, there is, you know, you can build your objects separately, but I think that's probably quite complicated for a lot of users.

49:54 Yeah, I think when we think about this, we have to set guardrails and also we have to talk about governance and I think the power platform governs often create tensions, the business ones is on their freedom. I T wants the control. How do you balance those both religions sites? I always think about it is in terms of friction. You know, how can we allow people to do what they need to do with least friction possible.

50:38 Now governance is a funny thing because some people see governance has been, you know, we're going to spell out every single thing you must do. And if we haven't told you to breathe in that way, then you're doing it wrong. I'm not a big fan of that because I think create yourself a big headache and you, you get to a situation where people stop thinking for themselves. And you have to ask yourself, you know, why are you employing developers if they're going to paint my numbers?

51:18 I think for me governance has to be around intent and giving the power to the makers and the developers to tell you how they're going to reach that intent. How they're going to make it as safe as possible in their way or to build a power or to make flow that isn't eight levels of nesting and 450 actions. And you have to review what it is they're doing and how they're doing it.

52:00 I'd say it's more of an art than a science. Now, I don't particularly tend to get involved with governance in terms of the LP policies and that sign of things, my, my, my tend to center around, you know, the governance of of architecture in terms of how we, how are we going to, how are we going to build this? And we're building it the right way. I'll be using the right type of automation tool and I think we've all come across those builders, those developers that see power to make as the answer to every single solution and showing them that it's not the right answer to every single solution and why it's not the right answer to every single solution is always an interesting exercise.

52:50 And I've been some pretty interesting environments. I have one a couple of years ago where someone had built 450 parrots make clothes and they asked me if I could help debug it. And I was like, yeah. I think I'll have long if you got how much budget do you have because it's going to cost a lot. So you've got a priming sample of where if governance has gone wrong there and we haven't broken things down properly and we haven't thought about things to services and things is features and what things are doing to other things because everything is, you know, something is serving something else is the way you got to think about it.

53:35 When we talk about Ian's really this architecture playbook, how does it look like the Bible, the novel or more than a comment? So for me, my architecture playbook is very much break things down into modules and features and with power platform they very much have to be kind of integrated layers. So what do I mean by that is you don't end up with a separate feature as much doing the front end.

54:15 And the separate feature as much doing the back end you feature tends to be molded together so you've got a piece of functionality in your feature. So we're going to have a functionality that's responsible for I don't know pushing stuff to a queue that sits on as your and all it's going to do is it's going to look for look for objects in this table and push them to a queue in a deal. And then you know, a function, you know, a feature that's going to look for emails that are in the outbound email table and it's going to send them based on the schedule that we've already set. Or it's going to text messages in that way.

54:55 My playbook very much is around splitting up the desired solution into features. And once we split up into features, ask yourself what's the reason for that feature to exist is there more than one reason for that feature to exist. If there is any question, you know, is it decoupled enough or is it one big blob of mess and if we can get one read down to one reason we can decouple it so that's that's ultimately what it what it looks like. I think there's other things that sit in that playbook around, you know, practices, if you think about practices, think about you know what type of automation should be used to solve this problem.

55:40 Now often people will go well, let's use some JavaScript to make sure these fields are populated. That's awesome. What happens if someone breaks that JavaScript or someone edits that JavaScript in the web browser because users can be pretty cheeky at times. What happens if we're building power pages and we've got some very important business logic that relies on JavaScript, but ultimately we can just write stuff straight to the database. You know, ultimately we can we can edit that and we can then put in whatever we want. You know, that's that's a problem. So.

56:22 There's another part of it is to are we doing the right thing in the right place, but that comes after the featureisation, but the first thing for me is always how do we break this thing down into features, how do you give these features one purpose to exist. And then how do we test these features. So when we put Humpty Dumpty together Humpty Dumpty, these slots together nice and neatly, we don't end up with big facts cracks because we got cracks in Humpty Dumpty, we've got a problem. Okay, yeah, cool. Yeah, we're running a little bit out of time. I have every part I have a rapid fire around so I give you a statement and you tell me whatever you agree disagree or say it depends or new, my short answer. Every enterprise or actual use data.

57:07 What enterprise app should use data verse. It depends. I don't know. It depends. It comes down to down to what what it is we were trying to do, but it depends. So yeah, I'm not very good at quick fire because my house is probably depends. Yeah, it's a typical answer on my every he comes up. Can you build up a candle mission critical applications? No. Power automate can replace logic apps. No, because you have to have stuff like using a logic app.

57:49 When I get in the old castle and you castle, what is your short, short, I order? I'd go middle, but I order order palm. I because palm is the greatest food in the world. Newcastle will be a curry. Definitely. Are you for Newcastle? Did you say, I think local reviews taking full that? No, doesn't automatically reduce technical doubt. Papa came for the replay is traditional application development.

58:34 No, because I believe that those principles still that the principles you have a play inside of core application development still exist. When in such an earlier quality, I'll give you all the resources, money you need to develop a feature. What should it be? What feature would I want? I don't know, that's something. I would want probably a feature to make forms. If I could have any feature in power platform would be something that would render a Jason definition as a form.

59:18 I can have dynamic forms and then store data dynamically. Like almost like your table storage where I can just chuck any Jason added in or thanks. Okay. And who shall I write next to the power? The MC65 podcast and what questions shall I ask? I can believe that although application development is different in power platform, those core principles still play. He is definitely a far more than expert in A.L.M than I am.

1:00:02 Thank you for joining me. One of the important things from this session is that the local doesn't mean low architecture. Power platform makes it possible to build application automation incredibly quickly. But those solutions become larger, more connected, more important to the business of the fundamentals of software engineering. And then it disappears. Data architect, governance, AI integration, monitoring, dev ops and all this matters. And perhaps most importantly delivery measures.

1:00:42 And then it's a real power, full platform and yeah, and yeah, choosing between local and pro code is more to understanding when to use each concept and how to combine power platform, Azure automations and so on. Thank you for all the listeners. I say thank you for listening today and you find all the information for me and Judy in show notes. And yeah, thank you for staying here. And yeah, thank you Ian for spent nearly an hour would be.

1:01:24 Well, thank you very much for having me. It's been a pleasure to be on the show. So thank you.