Sept. 2, 2026

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

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

Key Takeaways

  • Low-code does not mean low architecture; as Power Platform solutions scale and become business-critical, traditional software engineering and design principles remain essential.
  • Breaking enterprise solutions down into clearly defined features and modules with clean interfaces helps eliminate the frustrating whack-a-mole development problem.
  • A hybrid architecture approach allows teams to leverage Power Platform for fast front-end iterations while utilizing pro-code services, APIs, and Azure where appropriate.
  • Balancing maker empowerment with just enough governance and technical review prevents environments from descending into unmaintainable chaos or shadow IT.
  • Successful enterprise Power Platform development is about choosing the right technology for each specific feature rather than forcing a one-size-fits-all solution.

Microsoft Power Platform is often described as a low-code platform. But what happens when the applications you build become business-critical, highly integrated, and too complex for a simple maker-first approach?In this episode of M365 FM, Mirko Peters talks with Power Platform Solution Architect Ian Tweedie about what happens when Power Platform moves beyond simple low-code applications and becomes part of a serious enterprise architecture.

LOW-CODE DOESN’T MEAN LOW ARCHITECTURE
Power Platform can deliver a large percentage of business value quickly, but enterprise solutions almost always contain requirements that go beyond standard low-code capabilities.Ian explains why low-code should never be confused with no-code — and why traditional software architecture principles still matter when building with Power Apps, Power Automate, Dataverse, custom connectors, APIs, and Azure services.

WHEN POWER PLATFORM BECOMES ENTERPRISE SOFTWARE
There isn’t necessarily a clean line between “low-code” and “enterprise.”Complexity starts increasing when applications involve multiple user journeys, development teams, integrations, security requirements, business-critical processes, and interconnected services.At that point, architecture becomes essential.Ian explains why solutions should be divided into clearly defined features and modules with clean interfaces instead of becoming one large interconnected application.

ESCAPING THE WHACK-A-MOLE DEVELOPMENT PROBLEM
Fix one bug and another appears somewhere else.That familiar development problem is often a symptom of tightly coupled architecture.Ian discusses how modular design can isolate functionality and reduce unintended dependencies. Using email delivery as an example, he explains how separating business processes from delivery mechanisms can make applications easier to test, maintain, replace, and scale.

LOW-CODE + PRO-CODE = HYBRID ARCHITECTURE
Power Platform doesn’t have to compete with traditional software development.A Power Apps frontend might represent only a small part of a much larger application using Azure, AWS, GCP, APIs, or custom services.The important architectural question isn’t whether something is “low-code” or “pro-code.”It’s which technology is best suited to each feature.

CITIZEN DEVELOPERS, MAKERS AND ARCHITECTURE
Citizen developers bring something extremely valuable: deep knowledge of the business processes they work with every day.But business expertise doesn’t automatically translate into good application architecture.Ian discusses the balance between empowering makers and introducing enough architecture, governance, normalization, and technical review to prevent solutions from becoming difficult to maintain.

GOVERNANCE WITHOUT KILLING INNOVATION
Too little governance creates chaos.Too much governance creates friction — and can drive employees toward unsupported workarounds, spreadsheets, VBA, and shadow IT.The challenge is finding the right level of governance based on organizational risk, application criticality, users, and business impact.

POWER PLATFORM, APIs AND AZURE
Where should business logic live?Should secrets be stored inside Power Platform? When should Azure Key Vault, Azure Functions, or API Management become part of the architecture?Ian explains why architecture should always begin with the problem being solved rather than adding Azure services simply because they are available.

GIT, SOURCE CONTROL AND CI/CD
As Power Platform development becomes more collaborative, traditional development practices become increasingly relevant.The conversation explores Git, repositories, development environments, pipelines, source control, feature isolation, cross-dependencies, and CI/CD.There may not always be a perfect approach to source control in Power Platform — sometimes the goal is choosing the “least worst option” for the project.

IAN’S POWER PLATFORM ARCHITECTURE PLAYBOOK

Ian’s core principle is straightforward:Break solutions into features and modules.Each feature should have a clear reason to exist and ideally perform one specific responsibility.Then determine how those features communicate, where logic should execute, how they should be tested, and which technology is best suited to implementing them.

THE RAPID-FIRE ROUND
Mirko puts Ian through a series of quick questions:Should every enterprise application use Dataverse?Can Power Platform build mission-critical applications?Can Power Automate replace Logic Apps?Does low-code automatically reduce technical debt?Can Power Platform replace traditional application development?And perhaps most importantly: what should you order when visiting Newcastle?

KEY TAKEAWAY
Low-code does not mean low architecture.As Power Platform solutions become larger, more connected, and more important to the business, the fundamentals of software engineering remain relevant.Architecture matters.Data modeling matters.Governance matters.Security matters.API design matters.DevOps matters.And successful enterprise Power Platform development is increasingly about understanding how low-code, pro-code, Azure, APIs, automation, and traditional software engineering practices work together.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

  • 🎙️ Be a podcast guest and share your story
  • 🎧 Host your own episode (yes, seriously)
  • 💡 Pitch topics the community actually wants to hear
  • 🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

Frequently Asked Questions

What happens when Power Platform applications become enterprise-grade?

When applications grow to involve multiple user journeys, cross-functional teams, and complex integrations, standard low-code approaches are no longer enough, making proper architecture and modular design essential.

Is there a clean line between low-code and pro-code development?

There is no rigid line between low-code and pro-code; instead, modern enterprise solutions often use a hybrid model where different features are built using the technology best suited for them.

Why is modular architecture important in Power Platform?

Modular architecture ensures that features have a single responsibility and clean interfaces, preventing changes in one part of an application from breaking unrelated functionality elsewhere.

How can organizations balance governance and citizen development?

Organizations must implement just enough governance based on organizational risk and application criticality, avoiding overly strict rules that drive employees toward unsupported workarounds and shadow IT.

1
00:00:00,000 --> 00:00:08,640
Welcome everybody to the M365FM podcast where we explore the people ideas and technology shaping the M

2
00:00:08,640 --> 00:00:16,880
Microsoft 365 power platform Azure AI security governance and modern workplace. Today we are going behind one of the most common

3
00:00:16,880 --> 00:00:26,440
descriptions of Microsoft power platform, low code. Low code has opened application development to much broader group of people.

4
00:00:26,440 --> 00:00:44,280
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.

5
00:00:44,280 --> 00:00:54,440
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.

6
00:00:54,440 --> 00:01:17,320
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.

7
00:01:17,320 --> 00:01:32,600
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.

8
00:01:32,600 --> 00:01:36,520
So yeah, welcome to the M365FM podcast.

9
00:01:36,520 --> 00:01:48,920
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.

10
00:01:48,920 --> 00:02:04,520
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.

11
00:02:04,520 --> 00:02:28,520
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.

12
00:02:28,520 --> 00:02:40,520
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.

13
00:02:40,520 --> 00:02:46,520
How did you end up working with the power platform?

14
00:02:46,520 --> 00:03:14,520
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.

15
00:03:14,520 --> 00:03:24,520
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.

16
00:03:24,520 --> 00:03:28,520
But don't tell that too much to the dynamic people might get upset.

17
00:03:28,520 --> 00:03:43,520
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.

18
00:03:43,520 --> 00:04:04,520
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.

19
00:04:04,520 --> 00:04:25,520
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.

20
00:04:25,520 --> 00:04:33,520
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.

21
00:04:33,520 --> 00:04:43,520
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.

22
00:04:43,520 --> 00:04:56,520
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.

23
00:04:56,520 --> 00:05:07,520
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.

24
00:05:07,520 --> 00:05:17,520
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.

25
00:05:17,520 --> 00:05:20,520
Is there any limitation?

26
00:05:20,520 --> 00:05:26,520
How many code we can write in one application in in.

27
00:05:26,520 --> 00:05:41,520
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.

28
00:05:41,520 --> 00:05:55,520
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.

29
00:05:55,520 --> 00:06:16,520
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.

30
00:06:16,520 --> 00:06:28,520
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.

31
00:06:28,520 --> 00:06:34,520
You know up until recently you can only do client side logic now we're starting to serve a side logic creeping.

32
00:06:34,520 --> 00:06:54,520
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.

33
00:06:54,520 --> 00:07:18,520
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.

34
00:07:18,520 --> 00:07:38,520
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.

35
00:07:38,520 --> 00:07:52,520
But when you see or when those power platform solutions stop to being a local application become an enterprise software.

36
00:07:52,520 --> 00:08:04,520
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.

37
00:08:04,520 --> 00:08:08,520
Multi would different user flows or user journeys running through them.

38
00:08:08,520 --> 00:08:12,520
And you're doing more than just something as simple as looking at desk.

39
00:08:12,520 --> 00:08:24,520
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.

40
00:08:24,520 --> 00:08:38,520
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.

41
00:08:38,520 --> 00:08:50,520
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.

42
00:08:50,520 --> 00:08:58,520
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.

43
00:08:58,520 --> 00:09:10,520
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.

44
00:09:10,520 --> 00:09:30,520
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.

45
00:09:30,520 --> 00:09:44,520
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.

46
00:09:44,520 --> 00:09:53,520
And I have started with with local then oh oh I can use co-pilot in it it's really cool.

47
00:09:53,520 --> 00:10:08,520
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.

48
00:10:08,520 --> 00:10:13,520
It's feel a little bit depression so.

49
00:10:13,520 --> 00:10:31,520
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.

50
00:10:31,520 --> 00:10:51,520
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.

51
00:10:51,520 --> 00:11:01,520
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.

52
00:11:01,520 --> 00:11:18,520
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.

53
00:11:18,520 --> 00:11:28,520
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.

54
00:11:28,520 --> 00:11:37,520
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.

55
00:11:37,520 --> 00:11:59,520
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.

56
00:11:59,520 --> 00:12:16,520
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.

57
00:12:16,520 --> 00:12:26,520
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.

58
00:12:26,520 --> 00:12:35,520
We need that but then we're quite closely couple thing our flows to our sending of emails.

59
00:12:35,520 --> 00:12:46,520
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.

60
00:12:46,520 --> 00:13:01,520
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.

61
00:13:01,520 --> 00:13:13,520
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.

62
00:13:13,520 --> 00:13:33,520
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.

63
00:13:33,520 --> 00:13:53,520
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.

64
00:13:53,520 --> 00:14:15,520
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.

65
00:14:15,520 --> 00:14:27,520
So the different one or a complex one is this the different from from from local to to pro code.

66
00:14:27,520 --> 00:14:44,520
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.

67
00:14:44,520 --> 00:14:51,520
Yeah talking about these modules so you you could up something where you've got a front end that is using canvas app.

68
00:14:51,520 --> 00:15:01,520
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.

69
00:15:01,520 --> 00:15:19,520
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%.

70
00:15:19,520 --> 00:15:37,520
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.

71
00:15:37,520 --> 00:15:46,520
Interfacing with a very small part of the system now why does that work well power platform is very easy to change and edit.

72
00:15:46,520 --> 00:15:59,520
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.

73
00:15:59,520 --> 00:16:03,520
Then that's all that you need to worry about.

74
00:16:03,520 --> 00:16:07,520
Your business process will change far quicker.

75
00:16:07,520 --> 00:16:16,520
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.

76
00:16:16,520 --> 00:16:21,520
But it's receiving 4 pieces of information and transmitting 6.

77
00:16:21,520 --> 00:16:27,520
But it's chatting to some kind of pro code solution that's been built by some other teams.

78
00:16:27,520 --> 00:16:40,520
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.

79
00:16:40,520 --> 00:16:48,520
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.

80
00:16:48,520 --> 00:16:57,520
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.

81
00:16:57,520 --> 00:17:03,520
And I think you know I go back to your question of you know you got this pro code world in the local world.

82
00:17:03,520 --> 00:17:08,520
I don't see it as pro code and local I always see hybrid model is possible.

83
00:17:08,520 --> 00:17:16,520
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.

84
00:17:16,520 --> 00:17:22,520
So you're trying to make you know you're trying to fit a square peg in a round hole.

85
00:17:22,520 --> 00:17:25,520
Yeah awesome.

86
00:17:25,520 --> 00:17:40,520
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.

87
00:17:40,520 --> 00:17:56,520
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.

88
00:17:56,520 --> 00:17:58,520
The data.

89
00:17:58,520 --> 00:18:07,520
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.

90
00:18:07,520 --> 00:18:15,520
I think also as I started it's called common data service I don't know or it was something wrong.

91
00:18:15,520 --> 00:18:22,520
I really run with the names I don't know I'm so overwhelmed with the renaming.

92
00:18:22,520 --> 00:18:32,520
So there it's not the hard line we say that's it's more liquid to get there.

93
00:18:32,520 --> 00:18:44,520
But I think that's a little bit better to low code developer and pro code developer and I also think okay.

94
00:18:44,520 --> 00:18:49,520
You say the 80% can develop in low code.

95
00:18:49,520 --> 00:18:53,520
But the I think you.

96
00:18:53,520 --> 00:19:03,520
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.

97
00:19:03,520 --> 00:19:08,520
And how will you say.

98
00:19:08,520 --> 00:19:11,520
Yeah.

99
00:19:11,520 --> 00:19:17,520
We have these other tools and this is more more implemented.

100
00:19:17,520 --> 00:19:24,520
So I think a little bit about Azure and all all these I don't know 100, 600 services.

101
00:19:24,520 --> 00:19:27,520
And so on.

102
00:19:27,520 --> 00:19:37,520
What did you think when we need in real architect and or should we start every time with architecture.

103
00:19:37,520 --> 00:19:49,520
What when that's what what the best solution and yeah, how how we can this this figure out the liquid line.

104
00:19:49,520 --> 00:19:55,520
I I do think it's not an easy question to answer.

105
00:19:55,520 --> 00:20:01,520
Because you know you have to think about why we.

106
00:20:01,520 --> 00:20:08,520
We want to sit as developers in the power platform. Why do we want them building these business applications.

107
00:20:08,520 --> 00:20:11,520
Well, the reason is because of translation.

108
00:20:11,520 --> 00:20:15,520
Often these people live and beat breed these processes.

109
00:20:15,520 --> 00:20:21,520
So they know how to make the application fit their needs better than anybody else.

110
00:20:21,520 --> 00:20:24,520
Because you've got less people involved.

111
00:20:24,520 --> 00:20:29,520
If you go back to school and you think Chinese whispers.

112
00:20:29,520 --> 00:20:34,520
And how something can change when it goes through 10 different sets of years.

113
00:20:34,520 --> 00:20:38,520
We have the same problem when we're building solutions.

114
00:20:38,520 --> 00:20:46,520
The more people involved from user requirements to building the solution.

115
00:20:46,520 --> 00:20:51,520
The less reliable that's going to be.

116
00:20:51,520 --> 00:20:55,520
However, as you pointed out we have another problem.

117
00:20:55,520 --> 00:21:00,520
That's used to building a business application.

118
00:21:00,520 --> 00:21:08,520
The person is the more likely they are to architect it in a way that isn't necessarily efficient.

119
00:21:08,520 --> 00:21:11,520
If we think about normalization.

120
00:21:11,520 --> 00:21:22,520
You know I came across a project where someone had created more than 450 fields on a dataverse table and applied 40 business rules.

121
00:21:22,520 --> 00:21:25,520
And they are.

122
00:21:25,520 --> 00:21:27,520
And they should work.

123
00:21:27,520 --> 00:21:29,520
But it's a bird's nest.

124
00:21:29,520 --> 00:21:30,520
Bit like that.

125
00:21:30,520 --> 00:21:34,520
And actually would be far better off looking at normalization.

126
00:21:34,520 --> 00:21:36,520
So you have these two forces at play.

127
00:21:36,520 --> 00:21:38,520
And that's where you've got to think about.

128
00:21:38,520 --> 00:21:43,520
No, when is the right time to have just enough architecture at play.

129
00:21:43,520 --> 00:21:49,520
And I think that that role of reviewing what is going on is important and looking at the number of users.

130
00:21:49,520 --> 00:21:54,520
What is being built is going to impact and what the criticality of off that service.

131
00:21:54,520 --> 00:22:01,520
You know if it's something that's critical and is is needed to deploy something that's life saving.

132
00:22:01,520 --> 00:22:04,520
Or is going to impact the finances around the business.

133
00:22:04,520 --> 00:22:08,520
Then you need far more governance and architecture involved.

134
00:22:08,520 --> 00:22:12,520
If it's something that is you know if it doesn't work.

135
00:22:12,520 --> 00:22:14,520
It's a nice to have.

136
00:22:14,520 --> 00:22:23,520
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.

137
00:22:23,520 --> 00:22:25,520
But you have these two forces to play.

138
00:22:25,520 --> 00:22:33,520
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.

139
00:22:33,520 --> 00:22:42,520
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.

140
00:22:42,520 --> 00:22:47,520
And that's extremely experienced in what they do day to day.

141
00:22:47,520 --> 00:22:50,520
But the problem is you do need to meet somewhere in the middle.

142
00:22:50,520 --> 00:22:55,520
You know we've all seen really horrific Excel spreadsheets and that's in Excel.

143
00:22:55,520 --> 00:23:01,520
We've all seen horrific access databases you know you know they still exist out there.

144
00:23:01,520 --> 00:23:06,520
So you do have to you do have to draw a line and it is a weekly line.

145
00:23:06,520 --> 00:23:09,520
And it comes down to organizational risk.

146
00:23:09,520 --> 00:23:12,520
What's the risk profile about organization?

147
00:23:12,520 --> 00:23:13,520
How willing are they?

148
00:23:13,520 --> 00:23:17,520
The things to go wrong and what's the business criticality?

149
00:23:17,520 --> 00:23:27,520
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.

150
00:23:27,520 --> 00:23:36,520
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.

151
00:23:36,520 --> 00:23:48,520
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.

152
00:23:48,520 --> 00:23:53,520
And there's built this thing and before you know it's used business is become business critical.

153
00:23:53,520 --> 00:23:57,520
So if you're too strict in your architecture governance.

154
00:23:57,520 --> 00:24:07,520
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.

155
00:24:07,520 --> 00:24:11,520
You know we would hear today if we weren't really good at that.

156
00:24:11,520 --> 00:24:15,520
I think the question you have asked is really interesting.

157
00:24:15,520 --> 00:24:20,520
I think why we have citizen developer's not I think it says two reasons.

158
00:24:20,520 --> 00:24:27,520
So for me or for my department I can make things simpler.

159
00:24:27,520 --> 00:24:32,520
But the other thing is we have external and implement knowledge in a company.

160
00:24:32,520 --> 00:24:39,520
So and when I don't know I say I'm a flat manager in the company with 10 cars.

161
00:24:39,520 --> 00:24:48,520
Then I can build this simple solution and everyone can book with some rules behind the management level or something else.

162
00:24:48,520 --> 00:25:02,520
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.

163
00:25:02,520 --> 00:25:14,520
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.

164
00:25:14,520 --> 00:25:18,520
It's a lot of time ago. There was people don't know blackberry anymore.

165
00:25:18,520 --> 00:25:31,520
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.

166
00:25:31,520 --> 00:25:36,520
Then you need different kind of handling you need.

167
00:25:36,520 --> 00:25:45,520
I don't know you have I don't know thousands of stations and it's a more complex system.

168
00:25:45,520 --> 00:25:54,520
I think yeah that's the city they want about and that's for me then enterprise you can it's built like in.

169
00:25:54,520 --> 00:26:05,520
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.

170
00:26:05,520 --> 00:26:28,520
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.

171
00:26:28,520 --> 00:26:51,520
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.

172
00:26:51,520 --> 00:27:05,520
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.

173
00:27:05,520 --> 00:27:17,520
So if we think about common situation is where business has a couple of common things they need to communicate amongst the whole organization.

174
00:27:17,520 --> 00:27:41,520
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.

175
00:27:41,520 --> 00:28:02,520
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.

176
00:28:02,520 --> 00:28:14,520
Now the national items existed inside of a national database but we couldn't add our local items to that database.

177
00:28:14,520 --> 00:28:31,520
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.

178
00:28:31,520 --> 00:28:44,520
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.

179
00:28:44,520 --> 00:28:52,520
And one of the challenges I had at the time was how do we make that one system with single entry.

180
00:28:52,520 --> 00:29:21,520
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.

181
00:29:21,520 --> 00:29:50,520
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.

182
00:29:50,520 --> 00:30:03,520
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.

183
00:30:03,520 --> 00:30:16,520
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.

184
00:30:16,520 --> 00:30:33,520
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.

185
00:30:33,520 --> 00:30:39,520
Which means we don't have to use the time sheet and software that maybe we're not a big fan of.

186
00:30:39,520 --> 00:30:48,520
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.

187
00:30:48,520 --> 00:31:08,520
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.

188
00:31:08,520 --> 00:31:23,520
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.

189
00:31:23,520 --> 00:31:33,520
But then we have processes I say what process can we take let's take the mcp.

190
00:31:33,520 --> 00:32:02,520
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.

191
00:32:02,520 --> 00:32:31,520
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.

192
00:32:31,520 --> 00:32:37,520
This or that you have paying nearly three dollars for computing.

193
00:32:37,520 --> 00:33:00,520
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.

194
00:33:00,520 --> 00:33:15,520
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.

195
00:33:15,520 --> 00:33:24,520
Can can power apps first can power apps be a pro code tool or did I need like.

196
00:33:24,520 --> 00:33:53,520
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.

197
00:33:53,520 --> 00:34:22,520
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.

198
00:34:22,520 --> 00:34:32,520
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.

199
00:34:32,520 --> 00:34:47,520
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

200
00:34:47,520 --> 00:35:11,520
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

201
00:35:11,520 --> 00:35:32,520
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

202
00:35:32,520 --> 00:36:01,520
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.

203
00:36:01,520 --> 00:36:30,520
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.

204
00:36:30,520 --> 00:36:46,520
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.

205
00:36:46,520 --> 00:37:15,520
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.

206
00:37:15,520 --> 00:37:27,520
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.

207
00:37:27,520 --> 00:37:40,520
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.

208
00:37:40,520 --> 00:37:49,520
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.

209
00:37:49,520 --> 00:38:04,520
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.

210
00:38:04,520 --> 00:38:12,520
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.

211
00:38:12,520 --> 00:38:24,520
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.

212
00:38:24,520 --> 00:38:47,520
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.

213
00:38:47,520 --> 00:39:06,520
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.

214
00:39:06,520 --> 00:39:18,520
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.

215
00:39:18,520 --> 00:39:39,520
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.

216
00:39:39,520 --> 00:39:57,520
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.

217
00:39:57,520 --> 00:40:20,520
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.

218
00:40:20,520 --> 00:40:35,520
Interesting question so we're thinking about where we should store secrets and keys.

219
00:40:35,520 --> 00:40:42,520
The question I would always ask is is where we're storing it reversible.

220
00:40:42,520 --> 00:40:56,520
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.

221
00:40:56,520 --> 00:41:10,520
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.

222
00:41:10,520 --> 00:41:18,520
Environment to take environments variable is ultimately a table under the hood and I could accidentally be exposed.

223
00:41:18,520 --> 00:41:38,520
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.

224
00:41:38,520 --> 00:42:03,520
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.

225
00:42:03,520 --> 00:42:23,520
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.

226
00:42:23,520 --> 00:42:35,520
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.

227
00:42:35,520 --> 00:42:51,520
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.

228
00:42:51,520 --> 00:42:56,520
And then you have to ask yourself why you're doing that.

229
00:42:56,520 --> 00:43:05,520
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.

230
00:43:05,520 --> 00:43:18,520
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.

231
00:43:18,520 --> 00:43:33,520
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.

232
00:43:33,520 --> 00:43:46,520
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.

233
00:43:46,520 --> 00:43:51,520
So it's about doing it in the right situation.

234
00:43:51,520 --> 00:43:55,520
The right particular for the right problem.

235
00:43:55,520 --> 00:44:05,520
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.

236
00:44:05,520 --> 00:44:11,520
All you've done is proxy proxy your connections to your key vault you're still going to ultimately store.

237
00:44:11,520 --> 00:44:22,520
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.

238
00:44:22,520 --> 00:44:35,520
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.

239
00:44:35,520 --> 00:44:43,520
So it's always fascinating to ask that question but what is it what's the problem you trying to solve by doing this.

240
00:44:43,520 --> 00:44:52,520
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.

241
00:44:52,520 --> 00:45:03,520
What did you think about show day understand using gifts so they understand CI CD or.

242
00:45:03,520 --> 00:45:06,520
It's okay to do it.

243
00:45:06,520 --> 00:45:10,520
I did it my way I frankly not as well.

244
00:45:10,520 --> 00:45:19,520
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.

245
00:45:19,520 --> 00:45:31,520
It can be really handy to do that using it because your conflict it's very easy to accidentally conflict with someone else.

246
00:45:31,520 --> 00:45:35,520
Unfortunately when you're working the power pages.

247
00:45:35,520 --> 00:45:45,520
You're really just editing lines in the table because power pages is still stored as lines of a table.

248
00:45:45,520 --> 00:45:50,520
I don't think it's a difficult thing to understand.

249
00:45:50,520 --> 00:46:02,520
I do my architecture on most projects using a get repository and usually with less than half a day of workshop.

250
00:46:02,520 --> 00:46:06,520
People who are non technical like bays who are usually quite non technical.

251
00:46:06,520 --> 00:46:14,520
I can get into a comfortable position using markdown files and pull requests and they seem quite happy with it.

252
00:46:14,520 --> 00:46:19,520
I don't think gets a particularly complex thing to understand.

253
00:46:19,520 --> 00:46:21,520
I think you've got to use it in the right situation.

254
00:46:21,520 --> 00:46:26,520
I think one of the issues with power platform is.

255
00:46:26,520 --> 00:46:34,520
How do you how do you use that with get because you're all editing the same source.

256
00:46:34,520 --> 00:46:40,520
So are you going to just have one person inside of that developer or build environment.

257
00:46:40,520 --> 00:46:45,520
And then are you going to you know, ask them to commit you know, you know,

258
00:46:45,520 --> 00:46:53,520
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.

259
00:46:53,520 --> 00:46:56,520
Well, yeah, you could for what's the benefit of that.

260
00:46:56,520 --> 00:46:58,520
Well, start an approach.

261
00:46:58,520 --> 00:47:04,520
If I can take I do tend to try and push towards is that we.

262
00:47:04,520 --> 00:47:14,520
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.

263
00:47:14,520 --> 00:47:22,520
But you have to be really careful if you're going to do that because you'll need to watch out for cross dependencies.

264
00:47:22,520 --> 00:47:29,520
So you have to I get back quite carefully and you have to think how are you going to make sure you don't.

265
00:47:29,520 --> 00:47:35,520
And you can't across dependencies. But if you can split up your solution.

266
00:47:35,520 --> 00:47:38,520
And you can get it independently deployable.

267
00:47:38,520 --> 00:47:43,520
Then your father better to give one developer one environment and one get repository.

268
00:47:43,520 --> 00:47:46,520
And that way you know that person's responsible for everything in that.

269
00:47:46,520 --> 00:47:53,520
But it's not always possible to do you have to look at the size of the solution you're trying to solve.

270
00:47:53,520 --> 00:48:01,520
And there's there's I always say there's a least worst option. There's never a best option with this.

271
00:48:01,520 --> 00:48:13,520
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.

272
00:48:13,520 --> 00:48:16,520
And we'll have run two pipelines off that build environment.

273
00:48:16,520 --> 00:48:23,520
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.

274
00:48:23,520 --> 00:48:30,520
We'll do we'll run it as your DevOps pipeline that will take the latest version of that.

275
00:48:30,520 --> 00:48:45,520
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.

276
00:48:45,520 --> 00:48:50,520
So you can go back the other thing I tend to do.

277
00:48:50,520 --> 00:49:07,520
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.

278
00:49:07,520 --> 00:49:17,520
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.

279
00:49:17,520 --> 00:49:26,520
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.

280
00:49:26,520 --> 00:49:41,520
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.

281
00:49:41,520 --> 00:49:54,520
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.

282
00:49:54,520 --> 00:50:13,520
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.

283
00:50:13,520 --> 00:50:15,520
I T wants the control.

284
00:50:15,520 --> 00:50:23,520
How do you balance those both religions sites?

285
00:50:23,520 --> 00:50:28,520
I always think about it is in terms of friction.

286
00:50:28,520 --> 00:50:38,520
You know, how can we allow people to do what they need to do with least friction possible.

287
00:50:38,520 --> 00:50:52,520
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.

288
00:50:52,520 --> 00:50:58,520
And if we haven't told you to breathe in that way, then you're doing it wrong.

289
00:50:58,520 --> 00:51:13,520
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.

290
00:51:13,520 --> 00:51:18,520
And you have to ask yourself, you know, why are you employing developers if they're going to paint my numbers?

291
00:51:18,520 --> 00:51:34,520
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.

292
00:51:34,520 --> 00:51:51,520
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.

293
00:51:51,520 --> 00:52:00,520
And you have to review what it is they're doing and how they're doing it.

294
00:52:00,520 --> 00:52:05,520
I'd say it's more of an art than a science.

295
00:52:05,520 --> 00:52:26,520
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?

296
00:52:26,520 --> 00:52:50,520
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.

297
00:52:50,520 --> 00:53:05,520
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.

298
00:53:05,520 --> 00:53:13,520
I think I'll have long if you got how much budget do you have because it's going to cost a lot.

299
00:53:13,520 --> 00:53:35,520
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.

300
00:53:35,520 --> 00:53:48,520
When we talk about Ian's really this architecture playbook, how does it look like the Bible, the novel or more than a comment?

301
00:53:48,520 --> 00:54:06,520
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.

302
00:54:06,520 --> 00:54:15,520
So what do I mean by that is you don't end up with a separate feature as much doing the front end.

303
00:54:15,520 --> 00:54:25,520
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.

304
00:54:25,520 --> 00:54:39,520
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.

305
00:54:39,520 --> 00:54:52,520
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.

306
00:54:52,520 --> 00:54:55,520
Or it's going to text messages in that way.

307
00:54:55,520 --> 00:55:08,520
My playbook very much is around splitting up the desired solution into features.

308
00:55:08,520 --> 00:55:16,520
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.

309
00:55:16,520 --> 00:55:29,520
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.

310
00:55:29,520 --> 00:55:40,520
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.

311
00:55:40,520 --> 00:55:50,520
Now often people will go well, let's use some JavaScript to make sure these fields are populated. That's awesome.

312
00:55:50,520 --> 00:56:01,520
What happens if someone breaks that JavaScript or someone edits that JavaScript in the web browser because users can be pretty cheeky at times.

313
00:56:01,520 --> 00:56:12,520
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.

314
00:56:12,520 --> 00:56:16,520
You know, ultimately we can we can edit that and we can then put in whatever we want.

315
00:56:16,520 --> 00:56:19,520
You know, that's that's a problem.

316
00:56:19,520 --> 00:56:22,520
So.

317
00:56:22,520 --> 00:56:34,520
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.

318
00:56:34,520 --> 00:56:36,520
And then how do we test these features.

319
00:56:36,520 --> 00:56:46,520
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.

320
00:56:46,520 --> 00:57:01,520
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.

321
00:57:01,520 --> 00:57:07,520
Every enterprise or actual use data.

322
00:57:07,520 --> 00:57:20,520
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.

323
00:57:20,520 --> 00:57:24,520
So yeah, I'm not very good at quick fire because my house is probably depends.

324
00:57:24,520 --> 00:57:31,520
Yeah, it's a typical answer on my every he comes up.

325
00:57:31,520 --> 00:57:43,520
Can you build up a candle mission critical applications? No. Power automate can replace logic apps.

326
00:57:43,520 --> 00:57:49,520
No, because you have to have stuff like using a logic app.

327
00:57:49,520 --> 00:58:04,520
When I get in the old castle and you castle, what is your short, short, I order?

328
00:58:04,520 --> 00:58:12,520
I'd go middle, but I order order palm. I because palm is the greatest food in the world. Newcastle will be a curry.

329
00:58:12,520 --> 00:58:16,520
Definitely. Are you for Newcastle?

330
00:58:16,520 --> 00:58:22,520
Did you say, I think local reviews taking full that?

331
00:58:22,520 --> 00:58:27,520
No, doesn't automatically reduce technical doubt.

332
00:58:27,520 --> 00:58:34,520
Papa came for the replay is traditional application development.

333
00:58:34,520 --> 00:58:46,520
No, because I believe that those principles still that the principles you have a play inside of core application development still exist.

334
00:58:46,520 --> 00:58:56,520
When in such an earlier quality, I'll give you all the resources, money you need to develop a feature. What should it be?

335
00:58:56,520 --> 00:58:58,520
What feature would I want?

336
00:58:58,520 --> 00:59:12,520
I don't know, that's something. I would want probably a feature to make forms.

337
00:59:12,520 --> 00:59:18,520
If I could have any feature in power platform would be something that would render a Jason definition as a form.

338
00:59:18,520 --> 00:59:30,520
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.

339
00:59:30,520 --> 00:59:34,520
Okay. And who shall I write next to the power?

340
00:59:34,520 --> 00:59:49,520
The MC65 podcast and what questions shall I ask?

341
00:59:49,520 --> 00:59:56,520
I can believe that although application development is different in power platform, those core principles still play.

342
00:59:56,520 --> 01:00:02,520
He is definitely a far more than expert in A.L.M than I am.

343
01:00:02,520 --> 01:00:11,520
Thank you for joining me. One of the important things from this session is that the local doesn't mean low architecture.

344
01:00:11,520 --> 01:00:17,520
Power platform makes it possible to build application automation incredibly quickly.

345
01:00:17,520 --> 01:00:26,520
But those solutions become larger, more connected, more important to the business of the fundamentals of software engineering.

346
01:00:26,520 --> 01:00:38,520
And then it disappears. Data architect, governance, AI integration, monitoring, dev ops and all this matters.

347
01:00:38,520 --> 01:00:42,520
And perhaps most importantly delivery measures.

348
01:00:42,520 --> 01:01:04,520
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.

349
01:01:04,520 --> 01:01:14,520
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.

350
01:01:14,520 --> 01:01:24,520
And yeah, thank you for staying here. And yeah, thank you Ian for spent nearly an hour would be.

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