Keith Atherton's Journey from Pro-Code Development to Embracing the Power Platform

Mark Smith: 0:01
Welcome to the Power Platform Show. Thanks for joining me today. I hope today's guest inspires and educates you on the possibilities of the Microsoft Power Platform. Now let's get on with the show. Today's guest is from Edinburgh, the United Kingdom. He works at ANS Group as a Power Platform Solution Architect. He's a Microsoft MVP for business applications, a published LinkedIn Learning Instructor, power Platform Community Super User, public Speaker and host of the On Air in the Cloud podcast. He's a blogger and a mentor. So here's a full dance card. As you can see, he's trained and experienced in project management, leading teams, coaching and mentoring and, above all, he is a NET developer. You can find links to his bio, social media, et cetera, in the show notes for this episode. Keith, welcome to the show.

Keith Atherton: 1:00
Thanks, mark, great to be here. Good to see you again.

Mark Smith: 1:03
Good to see you again, good to have you on the show, and this is an awesome topic we're discussing today. Which is why should developers, net, c Sharp, let's call them a traditional developer, somebody that cuts code for a living, works inside tools like VS Code and Visual Studio for their job? Why would they consider the Power Platform as a tool to build solutions on? Why did you and we'll unpack why did you take that journey of moving from very much pro-code to using a platform that allows you to build a lot of the solution using low-code? The constraints, the blessings, the things that one needs to be aware of if you're going to take that journey. But before we start food, family and fun what do they mean to you?

Keith Atherton: 1:58
Yeah, love all of them, Love my food. It's tough to narrow down what food I enjoy the most, but, yeah, I love mixing all those as well. You know, going out with family enjoying the food Japanese food is a highlight for me. There's so many, it's really where to begin. So, yeah, I love spending time with family.

Keith Atherton: 2:18
I live here in just near Edinburgh in Scotland, as you mentioned, with my wife, lorraine, who's from here I'm not originally. We had a conversation before about Nottingham, where you started Certain Things, which is my hometown. That's where I'm from. Ah, nice, yeah. So, yeah, many moons ago, as we were talking about there before the show, about, you know, being in bands, being in audio design and music and so on. So, so, yeah, from there originally, I live up here in Scotland and that is a blessing because it's such a beautiful place to live, gorgeous countryside, so much to see and do, so, yeah, that's where I am.

Keith Atherton: 2:56
In terms of fun, there's so many things I enjoy, uh, again, enjoying the outdoors that we've got here, which is amazing. I often enjoy, uh, trying to be creative and making time to be creative, importantly as well. Sometimes that blurs into the community work where I can crowbar it in. Yeah, but sometimes it could be painting or drawing and you know kind of hands-on, tactile, creative side of things. In fact, during the pandemic I was lucky enough to illustrate a business book as well. That's on Amazon so. So that was taking the hobby to another level. It was great fun, loved it.

Mark Smith: 3:32
That's so cool. It's interesting. Yeah, I started the podcast in Nottingham when I think it was 2017. Also, no, in two months time it's a seventh year anniversary of this podcast, so it's been going a while, but in Nottingham they claim the oldest pub in England, right, the one that's kind of under the castle there.

Keith Atherton: 3:50
Yeah, that's it. Your trip to Jerusalem rumoured to be the oldest, which, just as you say, is built into the sandstone, the rock that the castle sits on top of. And I'm sure you know this story, mark, when you're in there. We didn't. We didn't pre-plan this, we're just talking about this, so it's quite funny. But one story came to mind is that when you go in, you've got all the big wooden beams that hold up all the rock above it and you can tell the locals to do to the people who are tourists have you heard this before? No, no, so the people who go in there. When you go in and you see people at the bar and they've got a pint and they've got the beer mat sitting on top of the glass yes, because so much of the sandstone can drip into the drink. Yeah, yeah, yeah, but people who've been there before are aware of that. So, yeah, when you walk in and you see all these beer mats on top of pint glasses, that's why See all these beer marts on top of pine glasses.

Mark Smith: 4:44
Yeah, that's why that's it. I hadn't observed that, because I did go. I definitely went back then. But the other Edinburgh, I mean what a beautiful city. The first thing that took me there was the Fringe Festival. That was the first reason Meg and I went there. And boy doesn't that city come to life when that festival's on.

Keith Atherton: 5:01
It really does, and it's on this month as well, it's on right now.

Mark Smith: 5:04
Is that?

Keith Atherton: 5:05
right. Yeah, it's pretty much all of August, as you say. You've got all the festivals, you've got the fringe. There's things like book festivals, film festivals, which is one of my favourites. It's another part of the fun for me as well. I do love films and movies as well, and there's just so much to see and do. It's incredible. You get the military tattoo up at the castle as well. Yeah, that's right. The performers from all over the world. So, yeah, it's just incredible. It's such a great place to live.

Mark Smith: 5:35
Yeah, we went back again because it was so good. In fact, we've been there, I think, three times, so we went back twice for a second French Festival and then we went back another time. I mean, it's just so easy to grab an Airbnb, so you even get to live very authentically in one of the old buildings and stuff, which is what we did. So it was a great time. Definitely loved that city. So let's talk about what we're talking about today, which is tell us a bit about your developer roots, that you've done across your career.

Keith Atherton: 6:06
Yeah, absolutely so. A short bit of background for me was when I went to university I actually studied physics but as part of that one of the modules was programming. It was using C++ and talk about going at the deep end with the language. There's a lot of memory management and lots of deep concepts with that. It was quite far removed from certain scripting languages you know, whether that be Python or Power Fx. So really I kind of started that way, took my interest and really from the get-go I was working for consultancies. My first was one based in London, and while I was working there it was a great place to join because they were looking for people with any kind of technical degree and they would provide training. So actually the projects we were on, either the technology had already been picked or we were pairing with a bigger organization a KPMG or a Capgemini or whatever the case was at the time that had already architected and decided the frameworks or the technologies and we would get training to skill up and use those. So it was a great learning curve for me, one to be in professional development. I had to learn to play catch up with all these IT computer science graduates who joined, and I was. I was back foot so I had to play catch up. But there was also that project. My first was actually Java with Oracle, the next was VB6 with SQL Server and so on and so on. The tech stacks changed per project and we would get some training, either a brief amount of training or time to upskill and then join the project. So really that helped me learn fast and adapt. But over the years it was really using the Microsoft technologies. That became the common thread. It became the common theme. When I changed jobs and I kind of veered towards that one because they had high market usage. It moved from that VB6 world into NET, even from version one. I remember actually having the preview version on a book of CDs, you know, for that version one, the beta version, and it was all about web services. I remember it's ASPNET web services and you know what we'd see as APIs typically today. So it was learning that from the start and keeping NET throughout the career for almost all of it.

Keith Atherton: 8:25
There's another organization I did join that had their own low-code system. This was about 10 years ago but for the most part it was NET and surrounding technologies. So some web frameworks, lots of WinForms and lots of things like SQL Server. So really that's kind of been the journey up until maybe the last three years or so. I joined another consultancy and that's kind of been the journey up until maybe the last you know three years or so. I joined another consultancy and that's when, from day one, they said, okay, could you look at this thing called power apps? We've got a customer, they're using some legacy I think it was access or info path apps but they need to modernize to something that is still a low code, no code option. They don't need fullnet apps built from the ground up. Could you upskill in this and use it? And that was really how I got started into the low-code side of things.

Mark Smith: 9:12
Wow, okay, so only three years ago, so very recent. How was that? You know, when you asked and it's interesting because you've had a history of updating or transferring developer skills to new languages over time For you, when this came up, what was that initial feeling around using the tech? And I'll preface this by I remember going into a project it was actually a rescue project. It would have been 16, 17 years ago where they had implemented Dynamics CRM and back in those days it was pre-cloud, so all on-premise, and their NET team had looked at it and said how hard can this be? It's built on NET, we can tackle it, no problem.

Mark Smith: 9:58
Why it was a rescue project is because they ignored the software development kit and the SDK that was in place and they did things like SQL injections and all sorts of things that back in the day, those were all absolute no-nos in the way the platform was architected and because they perceived it as a NET solution, they thought they could just apply and hack it to whatever they wanted, of course having massive implications. When you took on this technology, was that your similar thought that well, it's NET, I can do whatever I want with it. How was your perception of it and what was that learning process for you?

Keith Atherton: 10:44
Yeah, that's a great question and it's good to hear that story as well, because when I first looked into the uh power apps, I didn't even know it was development in the browser. I knew it was cloud-based. But I was like, hey, what do I install? You know, I'm so used to, you know visual studio code or visual studio, or even sql server management studio. You know traditional client installs that would put on the device and get ready to use. So when it came around to that, I realized, okay, this is a brand new mindset. You know, I need to look to see. Okay, what tools do I need to use? What can the tools do? How does it work?

Keith Atherton: 11:21
But yeah, initially my gut reaction, my instinct was, okay, well, hopefully I can just lift the bonnet. Uh, you know, lift the hood and start tinkering around with with the engine. You know, I've done that with game development, I've done that with line of business apps. Okay, let's, you know, dig under under the hood, let's write some custom javascript here, let's write this there. So my first thought was that. And then when I realized it had its own language I'm talking about maybe canvas power apps primarily here. So that was my natural transition, say, from dot net web apps from the ground up, wow over to something that was a pixel perfect. You know, uh, you know blank canvas. I can move those controls wherever I want. I can write the code behind them and, to be honest, when I first saw power fx and the excel formula type nature of it, I did get concerned that this might be too limiting. You know this is I've used c-sharp to a fairly high level I would say fairly advanced. You know whether you're using certain design patterns, interfaces, memory management, whatever the case may be be, you know, I don't know, don't know at all, no one does. But I've used it to such a level that I'm so used to, almost, like you say, here's some clay, I can mold it almost any way I want. If I can't, I need to fill the gap in my knowledge and learn how I can do that.

Keith Atherton: 12:40
So when I did see the Power Fx and the relatively short list of functions and commands possible to use with it, at first I did think, wow, this might be a bit limiting. But when I took a step back, learned more, I did realize, okay, there are different ways of tackling it. When I then took it further to say okay, I really hit what I feel is a limit here. That's when I started to read up on how to use development tools and extend the platform, and by extend not just dot net, I might push a few things into azure, azure functions or something and offload it there and do the work there. Then I can use my c-sharp or another language with functions or you know, other approaches are available as well.

Keith Atherton: 13:24
But it was really again the more I uh, the more I learned, the more I realized, oh, I'm not so constrained, it maybe can't do everything I need, but I've not hit anything yet. Line of business that's held me back. And so the more I learned, the more I kept digging and digging and then I enjoyed personally, I enjoyed that new learning curve as well. And it's a bit like this with those creative things we talked about in the fun, which is when you've got constraints, it's like, oh, I've got to use problem solving now. How can I make it do this with a limited tool set?

Mark Smith: 13:53
so, so that made it more fun for me as well so now, with your knowledge of things, how does the power platform sit, integrate with dot net and the ecosystems that surround dot net?

Keith Atherton: 14:07
yeah, that's a great question. I think one of the primary ones I think of with dot net and really with the power platform. I think there are so many other languages you can use to extend it dot net based and others primarily for dot net. One of the prime candidates I go for is really dataverse plugins. So you know these may be playing more of a part. You know taking a step back with power apps, let's say, model driven apps. These are mostly uis auto generated based off the data model. But sometimes you can't tap into every feature that you need that you may want to with the code behind. So in some of those cases, writing a plugin using c-sharp can be a great option, and that's typically at the moment.

Keith Atherton: 14:50
You know a way of like an event driven action that happens on the dataverse. A new account is created, fire off this piece of C-sharp code that does this work almost like a trigger on a SQL server database. It's there and it's auto-generated, it's event driven. So that's one of the primary ways that works really well. There are a few other ways. I think another way as well.

Keith Atherton: 15:11
Again, I mentioned Azure Functions before. You know that's a way you can offload processing to an Azure Function. If you want something that's going to be scalable, or you want the C-sharp or that language to do something a bit more complex with the logic call other APIs, call other other functions might have an orchestrator in there, then they're all you know ways of calling that as well, really, really powerful. And the great thing with functions as well, even though we're talking about dot net, you can write it using python or javascript or java or another language as well, so it's kind of fairly agnostic to an extent as well. So they're the two kind of fields I really think about. And then we do have other languages like JavaScript and others, not part of NET, but you can use those to extend the Power Platform as well.

Mark Smith: 16:25
Nice. So, in your opinion, why would a traditional developer add the Power Platform to their tool?

Keith Atherton: 16:33
set. One of the main benefits that I've seen, as a sometime business owner and a manager as well, is really the speed of development. It's really something that I think when I got over my initial learning curve of what is this, what can it do, I realized that you know the drag and drop, the low code, sometimes no code. Nature of this means I can spin up something very, very quickly. And again, if I'm running a business or a business unit and I'm looking, if I have people proficient in NET, low code and many other areas, if I was going to write it from the ground up using code let's say, c, sharp, sql Server for the back end, maybe a React framework or something on the front end for the web app, I'd be looking at more sprints.

Keith Atherton: 17:20
I really would. It would take more time, take more work. Um, there's pros and cons to both. Uh, you know paths for sure, but I think for many line of business applications, if you want grids, you want forms, you want buttons that perform actions, you want automation and things that send emails or drive efficiencies within an organization, then really 80, 90, if not 100% can be achieved with the Power Platform.

Mark Smith: 17:44
In my experience, so what about limitations? Are there limitations with the Power Platform that developers, specifically, should be aware of in their use case scenarios, or are there really no limitations because you have the full ability to extend wherever you need to using traditional means?

Keith Atherton: 18:05
That's a great question, and the reason I say that is because I think with any stack there are limitations, and there certainly are with the Power Platform. I mean, being able to extend and use developer tools is fantastic, but there are also limits. So I think, in terms of the limits, some of the issues I've come across are this was an early learning experience for me, which was that I was writing a Power App using Dataverse as the data platform behind it. But one issue I did find with that is Dataverse. If using relational tables, that side of it, the Power Platform's using Azure services behind the scenes, it's an abstraction on top of it, you can get into those services if you need. So Dataverse was great. You can create tables using click and drag. Create table, add column Fantastic.

Keith Atherton: 18:56
But because it was Azure SQL database, I did find that I did miss some of the fine tuning I could do with the SQL server. If I want to place an index on a specific column, create the phone keys where I need them, create user defined functions. Taking it to that level is something that again with the Dataverse, I'm not able to get to that level, something that again with the dataverse, I'm not able to get to that level. But then the other option, the workaround may be, instead of using data versus the data platform, considering moving to azure sql. Using that connector does require premium, but you can then reach into that. So again there is a workaround, but you know there may be limit. Oh, now you need licensing. You know well you would for dataverse anyway. But if you need licensing, you know well you would for dataverse anyway.

Mark Smith: 19:38
But if you already had dataverse, you'd be licensed for it.

Keith Atherton: 19:40
Yeah, good point. So I think there can be. You know, the more learning you go through and realize where these limits are. Dataverse it has a two minute timeout on operations. Now, for most you know transactional usage, that's fairly acceptable. You know you want something sub-second or only a few seconds. You're probably going to be fine, right. But on the occasion you you're running I don't know something silly here a year-long report, you know a quarter and financial something that needs a bit of grunt to it. You might offload that to azure functions so you can bypass that two, two minute timeout limit and do the work, then bring it back. But then there may be cost implications because it's it's serverless, it's pay-per-use. So yeah, there are workarounds, but being aware of them and knowing well what is the cost of that, or the potential forecast cost of that, is important, and some of the other costs or tax might be.

Keith Atherton: 20:33
When you extend the power platform, you might need to know about these azure services, like functions. How do webh power platform? You might need to know about these Azure services, like functions. How do webhooks work? You might need JavaScript to do some client-side scripting on a model-driven app. Again, for the times when it doesn't quite do everything out of the box that you need. Okay, that's another language I need to learn. Okay, what else? Oh, there's something called Fetch XML. Okay, what else? The list can go on the more you want to extend it. So then some people I know have given me feedback on training I've given before which is saying I'm learning so many languages I'm almost becoming a pro dev here, and they've got a good point.

Mark Smith: 21:10
You mentioned Fetch XML there. How do you explain that? Is that something 100% unique to the Power Platform? Is it something that a developer coming into it.

Keith Atherton: 21:22
What do they need to know? Great question, yeah, another good one, because it's something I've only used with a Power Platform Fetch XML, the way I see it. There's probably a better explanation. It is a way of performing a query and because I come from the SQL server world, using Transact SQL, I almost always exactly translate that SQL query and there are tools in the XRM toolbox and others that do this as well that translate that query.

Keith Atherton: 21:45
What entity or table you're going to, how many records you're bringing back? Are you joining to other tables or entities? Are you sorting or ordering, doing an order by again speaking in Transact SQL language of that result that gets returned. So, yeah, you can see in model-driven apps within Power Apps. It's also really useful for Power Automate Cloud Flows. So another limitation this will bring us back to with Power Automate Flows, it might be API limits, it might be usage limits or your paper execution, depending on the licensing, of which there are many that you may go through. If you go to a table with a thousand records, but you only need to run some actions on only the 10 active records, fetchxml is a great way of providing that query so you can really target just those records and now you're only looping around 10. You're not doing API calls for all thousand records of the table. Yeah, I don't know. That's in a nutshell no, no.

Mark Smith: 22:42
So this is interesting because you know, I've interviewed a few people now in your similar position and you're the first one that's really giving me a really good breakdown of the limitations, because I know the limitations are there, but often people have worked with the platform so long that they have kind of glossed over those. And my question is why? Why fetch xml at all? Why don't? Why couldn't you do it using, as we say, the traditional ways of doing the querying? Why do we need fetch xml in the mix?

Keith Atherton: 23:14
you're right, it's almost another addition, and certainly with Power Automate Cloud Flows. You know and thanks for the compliment as well, by the way, I'll take it. You know, I know we've had some excellent technical people on from, you know, raphael to Scott Giroux and many others, but you know it's an interesting one because you can use OData syntax as well. There are many ways of providing filtering. Again, it does feel like is this another bolt on, another thing to learn? It certainly does feel that way for me at the moment, and I do get that feedback from, from others that I've coached as well, saying well, I know sql server, can I not? Just we can't, just yeah, it's, you know. Unfortunately, you know, another translation there is, you know, going to a Dataverse table and creating a view, hey, it's great, you can filter it and do it at a sort but it's quite limited where when you go and write a SQL query, you can take it as far as you want.

Mark Smith: 24:07
Typically, I'd be interested in if any of the guests want to feedback on it. But I have a feeling from back in the day when Fetch first came out that I remember the reason it came about was a security reason and whether it had to do with we had this thing called sandbox environments back at the very early days of going to cloud so much more. And when I say sandbox, it was sandboxing your code in production. We're not talking about a dev test type environment, but specifically around protecting rogue code from damaging other people in the same cluster within azure. Now I that's you know, reaching back into my memory and I don't know if I'm absolutely accurate in that. It'll be interesting to get feedback, but that's why I think FetchXML actually exists or in the mix. I mean you know. The person of course to ask would be our Swedish friend who's the number one XRM toolbox developer, jonas. He would know why, because's his, his number one tool is on fetch xml. Isn't it within that um tool set?

Keith Atherton: 25:24
I believe it is uh yonas rap. Um, yeah, that's a good person to ask because, as you say, it almost translates exactly like a transact sql query for me. But the way you've explained the secure processing almost like some chips can do these days with enclaves and different ways of working does feel like a way of, as you say, keeping that in a safe silo, a sandbox. So yeah, it doesn't reach further out. Yeah, almost like the web service days, you keep it encapsulated behind the wall. You send your request, request, you get your response interesting.

Mark Smith: 25:58
Okay, I'll have to look into that. Yeah, I'm not 100, but I just I. That's. That's what um pokes out from the shadows back there. Um, how much of your work nowadays involves still using traditional code in the applications that you build? Now, the first example you gave, which was an InfoPath upgrade, is what I really saw. Squarely Canvas apps was designed to do, right, an InfoPath replacement. Infopath, by nature, wasn't a mobile solution. It was built in a time where nobody had mobile devices. By nature, wasn't a mobile solution. It was built in a time where nobody had mobile devices and so it was end of life on the SharePoint environment. For that reason, and you know, we saw particularly that Canvas app model come out into play. But you've come a long way since then and I assume that you've been on some very large projects. And I have a thing that I say I have never seen an enterprise implementation of the Power Platform that didn't involve Pro Code. It always does. In my experience, it always needs some form of Pro Code development. What would you say to that?

Keith Atherton: 27:06
Yeah, I completely agree. I completely agree, and to the extent whether it is 80-20 in favor of low code, you know, or whether the lines could be blurred. Now, for some of those, I guess, examples, it may be again back to my early days. The tech stack has already been chosen, it's already in SQL Server or Azure SQL database. It's already hosted up in the cloud. Already. We're using that. That, compared to, say, dataverse and the storage limits and the costing of Dataverse to extend those storage limits, could be a great reason to keep its SQL Server either in Azure or maybe even on-prem. Still, I know there are several customers still using on-prem and it still works great. You can use an on-prem data gateway, communicate with it and it works absolutely fine. I think you mentioned there as well the other you know pro code options could be okay.

Keith Atherton: 28:04
Well, 90% of these user-facing apps can be done with model-driven. Again, that might save a sprint or more when compared to canvas canvas. So background there as well, many of us might know that with canvas being pixel perfect, that's fantastic, but you've got to build your own responsiveness if you really want that. Yeah, luckily recently offline uh, you know, features came in which made offline capabilities much easier than the code-based way we had to do, as of you know, a year ago. Previously you'd almost have to code your own within power effects. Cache what you want, sync it the way you need it. Now you can actually turn it on, create a profile that manages this. How often does it keep in sync? It manages so much more. But anyway, I'm digressing.

Keith Atherton: 28:49
Interesting, you know, you might choose, okay, a model, a model-driven app. It's responsive, it's accessible out of the box. You've saved a bunch of time. All your apps are going to have a consistent look and feel, unless you tinker with the UI too much or create a load of custom pages. But again, some of those limits. With a model-driven app they bring all those benefits. But the amount of times I've had to open up to use javascript to do client-side scripting or again create some plugins because when it gets saved at the big, powerful server on the back end, trigger something automatically or do some other complex logic is very, very common. Now with the canvas you can probably write much of that in the power effects yourself. You have almost full control of the code and what the buttons do, the code behind on those. But with model-driven it comes with lots of benefits but sometimes requires those extensibilities as well. Some trade-offs.

Mark Smith: 29:40
Do you know that we had offline access over 10 years ago and what we built is and I'm talking so it used SQLite back in those days on the device and so we're talking about serious offline right. Serious, I think SQLite did. Two gigs was its limit.

Keith Atherton: 30:00
Access was as well, that was two gigs for a time.

Mark Smith: 30:05
That was a serious amount of offline right. This is much more than cached offline. So, yeah, back in the day day there used to be a com object that plugged into Outlook and you used SQLite and that allowed you to go online offline and run the full back then Dynamics experience in offline mode, and then it had a bunch of rules that when you came back online, two people had updated a record right down to a field level like last on, last off type thing, like how that would work. But it's interesting that it's taken this long for a real robust offline solution to come about again, since that, you know, com object wasn't the way to do it anymore.

Mark Smith: 30:49
But yeah, we had a very large implementation that involved road workers going to remote locations that had no mobile coverage, nothing, and they had to collect data around roading infrastructure like bridge decay, road surface decay, that type of thing, and we built the entire thing on Dynamics and they had these tough and tight devices inside their roadwork trucks with touchscreens even back then, and so they would be able to mark a defect on the road and be able to draw a circle and say, let's say the defect was three meters wide and select from what type of defect, which would then create, ultimately, a bill of works materials to come and fix that. But until they went back to the office and got Wi-Fi connection and re-sync that device, that would then update into the central system and create the work order and fire off all the rules. And so, yeah, this was well over 10 years ago. That type of functionality was there, um, in the platform that's impressive as well.

Keith Atherton: 31:57
Um, it's funny because I used to work in construction uh organization and this was before low code, and I remember actually building that from the ground up using code with dot net apps, with sqlite on ruggedized android tablets yeah, cheaper end because accidents happened, yeah, yeah, and it performed the same thing. In fact, when we rolled it out, we didn't have Wi-Fi hotspots within our workshop, which was spread across many fields, so we did the same thing that when you get back to the hub, the sync happens at that point and it was quite interesting to build it from the ground up. But to think about the syncing, what design patterns are using exactly the merge conflicts you just mentioned is it the last one wins or do you flag? It's a merge conflict that you have to resolve. There's a lot of problems to be solved, lots of technical challenges yeah, yeah, yeah, back there.

Mark Smith: 32:47
I think these were hp ruggedized devices. They're expensive, you know, and like we've got photos there these guys were, you know, the hivers never used a computer in their life. Everything had been done on paper, and so even the adoption training for them to all of a sudden go to this type of experience. Full ArcGIS integration back then as well, because that was the detailed mapping technology you had to have, but just phenomenal. But once again, it was cheaper to build that on the Power Platform predecessor, which was, if we translated to what we have today as Dynamics 365, sales is what we used. We just ripped off, we didn't need account, we didn't need contact, we got rid of all that and we built all our own tables. Back then we called them entities and on top of that and used it. It was still cheaper than buying an Oracle system for that government agency to buy an off-the-shelf roading management system or infrastructure system, because it's more than just roads. It was like roads, bridges, culverts, power, any power lighting, you know, on the network, traffic lights, all that kind of stuff was all owned by the roading agency. So, yeah, asset management really at scale and the full maintenance of it. Interesting project.

Mark Smith: 34:08
Yeah, keith, it's been great talking to you. You've definitely dropped some very telling insights about the Power Platform, which is exactly what I wanted to get out there, like kind of lay it bare. For years, microsoft has used this concept of no cliffs, and it's funny there's no cliffs until you absolutely step over one and then you realize that there was a cliff, and now you've got to backtrack and figure out how to solve something, and so that's why I like some of these candid conversations to really, as we would say, call a spade a spade and say, hey, there'll be dragons there. It's the edge of the world or what we know, and you need to be aware of these things, and I just think it makes us all smarter, stronger, better to be able to create great things on the Power Platform. So, yeah, thanks for coming on the show.

Keith Atherton: 35:01
My pleasure. Thanks for having me back, mark, it's been a lot of fun.

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