From Traditional Coding to Power Platform Prowess: The Developer's Guide to Innovation and Adaptation

Mark Smith: 0:32
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. Welcome to the Power Platform Show. In this episode I want to talk about ProCode. What's the on-ramp for ProCode developers in the context of the Power Platform? Why should ProDevelopers, or let's say, net developers, c-sharp developers, etc. Consider the Power Platform as part of their tooling? What do they need to know? What are the risks of it?

Mark Smith: 1:17
And this is going to be a part of a five to 10 part series where I interview pro developers, people that come from a NET type background or a very much code first experience and how they've come to the power platform and what are the advantages disadvantages. Now they've come to the Power Platform and what are the advantages, disadvantages, cliffs and walls that you don't want to run into. So today's guest is from Texas in the United States. He's a chief executive officer at Bowdark Consulting. He is a bestselling author and SAP mentor. His 20 years of software engineering experience, a deep understanding of SAP products and technologies, of software engineering experience. A deep understanding of SAP products and technologies, as well as how that integrates then to the Microsoft stack. You can find links to his bio, social media, et cetera in the show notes for this episode. Welcome to the show, James. Thanks for having me. Good to have you on the show, James. I'm interested in embarking on this journey of unpacking the story with you. Before we start there, though, tell me a bit about food, family and fun.

James Wood: 2:20
Yeah, food I enjoy too much. So I'm definitely a foodie. I like to cook a lot, so I have varying degrees of success, but I like to try a lot of different types of cuisines and experiment, much to my family's chagrin, I guess let's segue into family. So my wife and I. So we actually started the company together. We've been married since 1999. We have four kids, so we keep pretty busy Our kids. We have two in college and two in junior high right now, and so that pretty much takes up the balance of everything else.

Mark Smith: 2:58
Wow, wow, and tell us a bit about the best things to do in Texas.

James Wood: 3:04
You know Texas is, it's miserable in the summer but for the other nine months it's pretty great. You know it's not uncommon to be in shorts at Christmas and you Christmas and they kind of have a fairly moderate climate throughout. So yeah, there's always struggle when people say what should I come visit? I mean there's kind of your not a whole lot to really sightsee, but it's a good time. We've got a pretty diverse ecosystem here so you can go east and see lots and lots of tall trees. You can go west and run into the desert pretty quickly. So it's kind of choose your own adventure.

Mark Smith: 3:42
Nice, nice. Tell me when you're not working, what do you do for fun outside of family?

James Wood: 3:49
Well, you know I'm a techie so I do actually program outside of work for fun. Fun, I'm just, I guess, nerdy that way. So, um, enjoy kind of maybe some of the technologies that don't get a chance to do in an enterprise setting. So you know, I'll tinker with, uh, you know, raspberry pi devices and python and all that kind of stuff. So nice.

Mark Smith: 4:11
Yeah, how did you? How did you get to the point because I know you got a very strong sap background how did you get to the point of working on the microsoft stack?

James Wood: 4:23
yeah. So it was kind of a strange confluence of events. Um, sap actually tapped me this is probably 2013, I suppose to write the book on what is now known as SAP Cloud or well, sap Business Technology Platform. But you know, and that's kind of the SAP version of Azure for those going at home. But you know, as we were kind of getting integrated with that team, as they were getting that solution off the ground, they were working pretty extensively with hyperscalers, including Microsoft, so, you know, kind of early adoption into the Azure world. And then, sort of simultaneously, we were working with SAP's OEM group at the time and kept bumping into Salesforce but also Microsoft.

James Wood: 5:10
And you know, back in the XRM days, you know, looking at you know, sap was trying to bring in a lot of people into the SAP ecosystem that were kind of for low-code was really much of a thing.

James Wood: 5:22
That's kind of what people were on the lookout for from a platform perspective. And so we got an up-close look at dynamic CRM and the whole XRM motion CRM and the whole XRM motion and we were really impressed with what we saw and, you know, kind of spur of the moment decided. You know this is something that we think can really, you know, extend the reach of what we do for a lot of our customers and started our Microsoft consulting practice and I've kind of been at it ever since and you know what was kind of interesting. You know, for first several years we're kind of off in our own lane. We had our SAP projects going on over here, dynamics over there, and then the past three or four years we've just seen a ton of convergence, working with either Power Platform or Dynamics to extend the reach of SAP or maybe even zooming out and looking across the enterprise. So it's a little bit of SAP and Workday and Salesforce and everything in between, and Power Platform is kind of the glue, if you will, that kind of connects everything together.

Mark Smith: 6:23
Yeah, amazing. I've spent the last couple of years doing a lot around SAP and the Power Platform and that story in market and, of course, your name came up early on and it seems to be the gurus globally in the space and the work that you've done between SAP and the Microsoft stack. I would like to have you back and we do an episode just around that. Let's unpack that SAP Microsoft story from your perspective. I know you've created a bunch of tooling and stuff in that space, so let's take a look at that. But today I would like to unpack the story of pro developers and the power platform, and the reason the story is topical for me and has been something brewing for a couple of months now is that I started my career in 2003 with MSCRM right, and so it was the very early days of Dynamics, before it was called Dynamics, and there used to be heaps of resources from Microsoft about how a NET developer could start to use this technology to build apps, because it meant that apps could be built faster and the business value gained a lot quicker when the plumbing had been taken care of in building those solutions and Microsoft used to have training material etc. For you know, if you're coming from the dot net world. How did you on board? Because back then there was a software development kit um, you know, it was all on prem days, before the cloud, etc. And it was quite different and there were very tight rules around. You weren't allowed to do SQL injections and things like this. You had to follow the process to create a stable platform and it came across many scenarios where NET developers would look at it go, hey, I know NET, it's a Microsoft test tool, it's written in NET. Man, let's get in there, no worries. And they broke it back in those days. So Microsoft released a lot of content, a how-to for developers in the traditional sense of developers could build solutions rapidly on the Power Platform. Fast forward to today, none of that seems to exist anymore.

Mark Smith: 8:24
You've got developers, let's say you know, in some case I'm seeing being forced onto a Power Platform project. You know, let's say they're in a big financial institution, they're part of the development team, maybe a team of 60 odd developers in that team and they're like hey, we're going to adopt the power platform. Now you need to learn it. And the first thing, they're like you, what this is, restrictive, this is going to.

Mark Smith: 8:43
You know, stop me doing what I do as a developer, and I feel that I want to kind of, because I've seen the other side of it, where I've seen pro developers that understand the Power Platform and its history from XRM perspective and they go oh my gosh, this is going to allow me to get time to value so much quicker is, where are those cliffs where it doesn't play like they would expect it to play?

Mark Smith: 9:16
Where are those you know walls that they're going to run into and bloody their nose on and then get disheartened with the platform because it's almost like they didn't know and so they had to fall over or stumble into it to get to that point. And so, with that in mind, if you were talking to a pro developer, how would you tell them the benefits of the Power Platform and that it should be part of their tool set, being that part of their tool set will be Azure, m365, and then any other you know outside the Microsoft ecosystem tooling that they might be working with as well, outside the Microsoft ecosystem tooling that they might be working with?

James Wood: 9:55
as well. Yeah, you know, I think for me it really boils down to productivity. You know, I think anytime you're dealing with an opinionated framework like this, you know you're going to have pushback from Proko developers. That you know. I remember I got my programming start in the Java space and I remember working with a gentleman that he was amazing with assembly language and he swore up and down that you know, give me any requirement and I can code circles around any C, c++, Java developer in assembly language. And you know maybe he could do that, maybe he couldn't, but you know it was always.

James Wood: 10:31
You know this conversation around the level of abstraction. You know, if I can have a framework, a toolkit, something like the early days of XRM and kind of what was provided there, then I'm eliminating a lot of that boilerplate stuff that I think a lot of Proko developers like to talk about. Oh, I can plow through that really quickly. And I think the reality is when you start to look back. Developers like to talk about oh, you know, I can plow through that really quickly. And you know, I think the reality is when you start to look back and you know the amount of time it takes to build a web app from the ground up. You know even proficient reactor. You know laser developers. You know there is, I think, a lot more there than I think a lot of Proko developers really account for, and so you know what we've kind of looked at is okay.

James Wood: 11:18
You know there are places where low code doesn't make sense, but you know, when we take a project as a whole, you know how many different areas of that project can we knock out just for us. I mean, at Bowdark, since we've started down this path I mean I would say conservatively we've seen a 60% increase in productivity in terms of the types of projects that we're delivering. And so now the question becomes what do I do with that excess time? Whereas before it might have taken me three months to build a responsive web app, now maybe I can get it done in half that time, and now I've got some additional time on my hands.

James Wood: 11:54
Some customers may just pocket that money, but others might be willing to go a little bit further. Now can I unlock, maybe, some opportunistic AI injection and try to push the envelope in terms of innovation a little bit more. And so I think there's. It's understandable for developers who have just been accustomed to having infinite freedom to build solutions the way that they like to have that natural bit of resistance. But is it, at the end of the day, that fundamentally different from a lot of frameworks out there Even programming environments Python is very, you always hear is that the Pythonic way of doing this? It is very opinionated, and so I think sometimes it just takes a little bit of recalibration in your brain of maybe this is not as foreign as I think it is at the end of the day.

Mark Smith: 12:47
So when we think about time to value or business benefits realization in any software development project, benefits realization in any software development project, what are the advantages and disadvantages you're getting here by using the Power Platform over building from bare metal, or maybe not that low, but you know?

James Wood: 13:06
Yeah, I mean one that comes to mind initially is just, you know, the amount of investment that Microsoft is putting back into the framework. You know, if I build a model-driven app two years ago, just the innovations that have come about in the past 18 to 24 months, I'm getting that constant modernization, the new look and feel, additional controls, additional pieces of functionality to where the overall O&M of these apps? I think it's changing quite a bit. There's just so much there that I can maybe stretch my budget a little bit further with these investments and building on these tools. I think Microsoft has done a very good job of. I've heard Charles Amana talk about that no-close philosophy and just the idea of always getting an escape hatch. I could always throw in some C-sharp, I can call out to Azure, I can do other things that make sure that I don't code myself into a corner, and that's been my experience since I've worked with the platform.

James Wood: 14:11
I mean, like any framework, I think you have to learn to think in that framework to a certain extent. From a user experience perspective, I think one of the things we struggle with a lot is how much of this is synchronous versus asynchronous. There's maybe several different ways to get to end of job. What's the most optimal user experience? Because there are going to be some things that I don't know. Do I incorporate custom pages into my model-driven app, and what sort of complexities that come with. And you know, like any framework, there's some trade-offs there. But I think you know, once you kind of learn to think in that framework, that you can really stretch those investments, I think, further than you can. Just a pure bare metal, you know, procode-style solution.

Mark Smith: 14:57
What about you know, procode style solution? What about you know? No software these days stands alone. It's always part of an ecosystem of applications where you know back-end solutions has to be integrated. What's the integration surface like from a pro-developer's perspective, using or adopting the power platform?

James Wood: 15:17
yeah, I mean the tooling of course you know is I think microsoft has done a good job of taking some of the alm innovations in and around power platform and continuing to incorporate those into azure devops so that you know your, your makers and your Proko developers can kind of coexist in the same ecosystem and maybe use some of the same tooling. I mean, it's not that it's perfect, but I think that's been a major benefit. And I think, at the Azure level in particular, when it comes to integration, connectivity, just the seamless way that things like Azure API Management, I have very simple wizards essentially that can take some of these complex APIs that we might be surfacing from on-premises back-end systems, things like that, and easily incorporate those into the Power Platform. So there's that nice separation of concerns between Pro Code developers and makers, makers, so that I think each can kind of play to their respective strengths. And I'm excited to kind of see where Microsoft continues to take this.

James Wood: 16:24
You know, I've seen some demonstrations of where they're trying to go with tooling and you know Power App Studio, for example, having more of that collaborative authoring experience. You know, I'm hoping that's kind of the beginning of much more to come there to where you know we can have some of these different experiences because you know at least in my experience, I mean the types of solutions we're building. You know Fusion Teams is absolutely the name of the game and we have, for example, with our SAP development. You know we have SAP architects, we have power platform architects, in some cases, azure business analysts people coming from all different walks of life and being able to pull all those resources together. It's a different motion because no one person necessarily has the complete picture, end-to-end, of how the solution is going to work, so that collaboration becomes much more imperative than it might have been in the past. I think.

Mark Smith: 17:17
What are the limitations, as in if you're talking to a dev going into this and you said listen, just be aware, there's this, this and this you need to be aware of and you need to consider how you would work around these limitations.

James Wood: 17:42
I think for us you us a lot of times it's managing expectations on the part of customers understanding that a power platform solution might not be 100% low-code.

James Wood: 17:49
I can certainly try to take advantage of Canvas apps and PowerFx and a host of low code type tools.

James Wood: 17:56
But I think once you get to a certain level of complexity, you know, for us it's it's approximately 70, 30 between low code and pro code. You know there there has to be some level of architecture in place. I think you know, once you get past, you know, your basic three screen canvas app or you know one off more simple solutions, the minute we kind of put a toe into the enterprise space, now it's going to be a little bit more of a collaborative experience. It's going to require more of that deep architecture. And so does that change, at the end of the day, the value that the Power Platform brings? Personally I don't think so, but I know for some customers it's like well, you know, now I'm kind of in this hybrid model and you know maybe there's some feelings that they're not getting the full value. You know, I thought this was going to be purely low-code and I could park any citizen maker in front of it and that's probably not a realistic expectation.

Mark Smith: 18:53
Yeah, so what else? What are?

James Wood: 18:58
the other limitations, I think, as it relates to scale with licensing, a lot of times that's something that we run into where if I build a solution from the ground up with ProCode, I have a lot of flexibility in terms of how I distribute that. So a lot of customers that are new to Power Platform I think they have a hard time understanding the difference between Power Apps and, say, power Pages for building something that might be customer-facing or kind of a mixed audience of users that are coming in, and so there's some challenges there in terms of how far can you take the platform. But I think a lot of that can be mitigated just with some of that careful, upfront architecture and understanding of this is kind of where the platform has its strengths and how do we fill in the gaps with Pro Code. To get to end of job.

Mark Smith: 19:55
Any application that you build is going to need some type of storage in some shape or form data storage, dataverse. A lot of people coming outside touching this for the first time are like what is this? Is it SQL? Is it just you know what is it? So, once again talking to a developer, how do you set up a premise dataverse and its function in in the development mix?

James Wood: 20:23
you know I I think it's it's looking at it from a more business object level in my opinion. You know, for years we've always had, you know, just our basic sql access. You know azure, azure SQL or on-premises SQL server, and maybe, if I'm doing C-sharp development, I've got some different libraries that I can bring into the mix to abstract away some of that. But even if I'm talking about ORM, there's a fundamental difference between some of those database-level libraries versus a full-fledged business object framework, and that's really what I view Dataverse as I mean. Sure I've got all the storage capabilities you can imagine, but the power of being able to create custom tables and the minute I activate those, have them be part of a robust RESTful API OData v4 that I can access. You know I don't have to necessarily go through the local tools you know Power Apps et cetera to access that, you know. So that's a very powerful capability and I think you know what Microsoft's done a really nice job of is just stacking more and more functionality on top of it.

James Wood: 21:30
You know I can define business rules. I can define, you know, graphical interfaces. I can define graphical interfaces. I can take advantage of some of the deep integration that's there with Azure services. So if I want to extend the reach, for example in Cosmos DB, and create tables, virtualized tables, things like that, that's a place where that level of abstraction that exists with the business objects really gives me a lot of power to maybe shield my citizen makers from some of the complex ugliness that exists back in business systems and kind of provide everyone with a level playing field to draw from as they're building apps. Short answer to your question I just think there's so much there that goes above and beyond SQL storage that I think Dataverse almost gets a bad rap. People don't quite know what to make of it, but there's so much powerful functionality there.

Mark Smith: 22:31
You touched on the word virtualization there and in the context of Dataverse. What does that mean? What's the opportunity? We touched on SAP at the start and of course, most organizations, I assume, don't want to, as a rule, either mirror their data or replicate their data, because now you're paying for at least storage costs twice. Right, Tell us about why Dataverse virtualization is important and what's your lens on it.

James Wood: 23:00
Yeah, I mean I think you know, as you touched on you know there's just a natural hesitancy on the part of customers to mirror their data, and you know I think of course there's so many different virtualization options these days. But take, for example, the recent innovations around being able to integrate virtual tables from Fabric. Now I've got if I'm a customer that's built a modern data lake house in Fabric and I've got all my data there. It's such an accelerator for power platform development.

James Wood: 23:30
Where the data is already accessible, I can very easily tap into what's already there, my pre-existing investments in Fabric, and now it's a little bit of just add your low-code magic and maybe some one-off connector API calls to really build a full-fledged solution so much faster than going back to your question of limitations before. Even though there's 1,200 connectors out of the box for a certain level of complexity for an app, if I'm having to build all my interactions with the backend system through connectors, it's messy, you know I've got to. You know hydrate data from a lot of different sources and you know there's performance implications that are associated with all of that. And so that virtualization really does take away a lot of that complexity to a point where I've already got my data now it's just I need to plug in my application logic and maybe I have a few connector call-outs to do an update on an equipment record or something like that, as opposed to having to build it all from scratch.

Mark Smith: 24:36
So you touched on another interesting thing there, which is performance, and I suppose part of performance then is also scale. What if I have an application with 10 terabyte of data? Is it going to be slowed down when I'm going to run reporting or other business logic across that? What are your thoughts?

James Wood: 24:57
Yeah, I mean, performance is always a major consideration and getting back to the fabric thing, I mean that's one of the things that we've been so excited about is, you know, being able to really harness the capabilities of that engine to, you know, mitigate some of those challenges. I mean especially, you know, for the type of work we do in the SAP space. It's uncommon to tap into tables that have literally billions of records in them and so, helping a citizen maker understand that a search box on top of this you can't run a wide open search on that data You're going to really start to crawl. We can smooth out some of those rough edges on the back end and take advantage of some of the capabilities in Azure to maybe paginate through the data a little bit more smoothly, define more intelligent filters, all those kinds of things that probably don't want to do that in Power Fx. You want to have a layer underneath that. That's kind of brokering that communication, I think.

Mark Smith: 25:58
And sizing data storage directly within Dataverse. I know you've got the ultimate unlimited extensibility when you go to Fabric, but do you see any limitations? And where you're you know if you're architecting a solution you're going to go. You know what. We're going to bring Fabric into the mix early rather than later. If that's not even you know a strategy of the customer, how do you decide that type of thing where you feel that you're going to go beyond the capacity of what you want to do in Dataverse?

James Wood: 26:28
It's an interesting question, I think one of the interesting things we've seen. I mean it feels like every customer you walk into kind of has a different take or approach to this. Walk into kind of has a different take or, you know, approach to this. But you know, as the power platform, environment concepts has become a little bit more well understood. You know, among customers we're seeing a lot of breakdowns of data.

James Wood: 26:49
Mart is not quite the right term, but you know, imagine environment per department within the business being able to kind of slice and dice it along those lines and then use either APIs or other measures of integration to. You know, instead of having kind of the traditional monolithic, massive ERP-sized database experience, it's a little bit more composable ERP, if you will. You know we're kind of bringing a lot of these solutions together across these different departments and you know mixing and matching them in a lot of pretty clever ways. You know it's kind of interesting to see how that has evolved and you know it's probably a little bit too early days to really have a clear. You know those old enterprise integration patterns books that used to exist, that talked about. You know the best practices around this and you know I think it really does vary and, you know, I think people are coming up with a lot of creative ways to approach that.

Mark Smith: 27:45
So another thing I've come across quite a bit in the industry is that you go into an enterprise organization. They've got their own development teams. They have been developing on XYZ applications Generally, sap is always in the mix of that and they want their developers to cross-skill and be able to build solutions and I'm talking about solutions that are way more complex than a citizen developer is ever going to do. They might want to rationalize their app landscape. They might want to get rid of apps that are still on-prem. They haven't and they don't want to just lift and shift them to the cloud. They want them to be, you know, if you like, pacified or sassified at least. And if we look at those developers and let's say they could have, as I said, they could come from SAP, they could come from Pega, they could have come from any one of those.

Mark Smith: 28:37
You know Oracle how do you best guide them into a skills development path to get them up to speed as quickly as possible, while not teaching them to go? You need to go learn low code Because they're like what you know, like nah, you're kidding me right. Like how do you get? Like, if you're like, be respectful of their knowledge already and not try and teach them to suck eggs, and taking them back to what a citizen developer would, because you know it's offensive to them. So how do you take them on that journey, or what would you recommend?

James Wood: 29:13
You know, I think and your mileage will vary here, but I think you know one of the things that we've talked about with a lot of developers both our internal developers as well as developers and customers is let's take a step outside of the little biospheres that we live in, in our case.

James Wood: 29:31
A lot of times it's SAP. Sap COEs typically exist in a bubble and they don't necessarily play well with others. When you zoom out and look at this from the enterprise perspective, we kind of liken it to a solar system a little bit. You have all these different constellations and SAP is an enormous planet that has this gravity. Well, that sucks in a lot of stuff that it probably shouldn't at the end of the day. But if we start looking at this holistically, I mean the reality is all these different little pockets of COEs are not able to keep up with the demands of the business. And so how do you start to reimagine what this looks like? And, of course, from our perspective, maybe we drink the Microsoft Kool-Aid. But thinking about putting Azure and Power Platform at the center of a lot of this, now I'm starting to reimagine what scale looks like If a customer has SAP, workday, salesforce, all these different systems, on-premise, homegrown, etc. If I put something at the center of that and I start to cultivate those common skill sets, then I'm not taking away your Proko development, I'm probably unlocking all kinds of new opportunities, and so it's a matter of redistributing that load, I would say, and maybe getting a lot of Pro Code developers out of some routine tasks that aren't really value-add and they're probably not enjoying at the end of the day anyway.

James Wood: 30:59
I'll use SAP as another example here. I mean, there's so much proprietary stuff in SAP to build forms and workflows and all these different things and those technologies. I mean there are people that have literally made a career out of all I do is forms development and I've learned this proprietary framework to the fullest extent possible, and those developers you're going to have a hard time convincing to reimagine things. But for others the name of the game is building APIs, and if I can let them focus there, then all of a sudden I've unlocked their time to work on all kinds of other interesting, more value-added kind of things. And so it's, I guess, a little bit like economic theory is am I taking away jobs or am I actually creating jobs?

Mark Smith: 31:49
So the use case that's jumping to mind for me is the developers don't really have a choice outside of resigning and leaving the company If they're that anti. You know this journey, that these enterprise accounts are going on, and so let's say I'm a dev, I've got, you know, 15 years experience in something else Might not even be Microsoft, it might be NET as well. How quickly can I be super productive and adopt all the rich benefits of the Power Platform if I'm coming from that kind of lens, and is there any kind of resources that you would recommend go do this? Or have you got any stories from the field of where perhaps you've got a use case that you could talk about, that, where you've taken people on this journey?

James Wood: 32:38
I would almost say I think it depends on your willingness to really jump in with both feet. There's so many opportunities. It's absurdly easy to get set up in your own development environment and Microsoft documentation. Having worked in a lot of different ecosystems, the stuff in Microsoft Learn is fantastic. You can have guided study. There's detailed documentation to kind of walk you through. You know whichever lane you want to go down. You know, in terms of Power Apps, you know Canvas apps, power Automate. You know whatever your preference is. So much video tutorials. I mean YouTube is a, you know, wonderful resource. You know YouTube is a wonderful resource. That was a lot of how I got started.

James Wood: 33:23
Quite frankly, is started kind of tinkering with this, and there's so many in the space that are just talking about the community in general. I think it's a pretty special community. I think that there's just so much of a willingness and maybe it's a function of that ProCode, lowcode, unite concept where you have people that are coming at this from a lot of different angles and they like to share their knowledge and they like to showcase. This is what I'm working on. Here's some challenges I face and all of those things journey in terms of timing to your question. I think we've seen some of our Pro Code developers really come up to speed and be pretty productive within a month. But it depends on motivation. If they're fighting it every step of the way, then maybe not so much. But a lot of these concepts are. Microsoft has done a good job of kind of building on. You know.

James Wood: 34:19
You think about Power Automate. Well, it's basically logic apps at the end of the day. So if you're an Azure developer that has exposure to some of those technologies, it might not be as big of a leap as you might think, and I think that's another part of this that your skills start to translate. Well, power Query may be tinkering in Excel and all of a sudden I find very productive in Power BI too, and now Fabric and Data Factory and all of that. I think the same thing goes for Power Facts.

James Wood: 34:49
There's a lot of this that just kind of builds on top of it. Of course, you always have that escape hatch out Our C Sharp developers. The way they approach some of the solutions are a little different. I mean there's maybe a little more tendency to I'll just write a plugin for that and I don't know that there's a right or wrong way to do some of this, depending on the level of complexity, and I think the framework is very forgiving in terms of providing three to five different ways to solve any given problem, and so you just kind of have to find the one ways to solve any given problem, and so you just kind of have to find the one that plays to your respective strengths.

Mark Smith: 35:29
Yeah, epic James, it's been great talking to you and it'll be great to have you back to really just unpack the SAP Power Platform story. Before I let you go, I'll let you have the final word around. What haven't we discussed that we should have today?

James Wood: 35:40
That's a good question. I think you can't go to any podcast these days and not touch an AI base at some point, so I think that's something that's starting to add another dimension to a lot of this. And, of course, Copilot is front of mind for all things Microsoft, but those tools I think are probably I still feel like we're kind of early days, but I can't tell you how amazed I've been being in GitHub Copilot, some of these different tools and for myself I'm not a data engineer by trade, but being able to get into Fabric and fire up a Jupyter notebook and kind of have Copilot walk me through Spark development and things like that. I think the future of this, if we have this conversation five years from now, I would submit it's probably going to be even more ProCode friendly than it is today.

Mark Smith: 36:32
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.