Expert Guide to SAP and Power Platform Integration with James Wood

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. In this episode of the Power Platform Show we're going to focus on SAP and its relationship to the Power Platform and why customers are choosing to use these technologies together. Recently I had our guest on the podcast talking about a totally different topic, but he has some deep insights into the SAP Power Platform story. So our guest is from Texas in the United States. He's a co-founder and CEO of Bowdark Consulting. You can find links to his bio, social media etc.

Mark Smith: 1:23
In the show notes for the episode. If you want to listen to the last episode, just go back to the podcast site and you will find at podcastnz365guy, those details there. Otherwise, james, welcome back to the show. Thanks for having me. Good to have you back on the show and really to really unpack your experience around SAP. And I suppose in the last episode what really resonated with me is that you've written a book on SAP and there's not many partners that have got this deep into the SAP Power Platform story. That, if you like, started on the SAP side and then really leaned into the Microsoft technology, and so I'm interested in this episode to really unpack that. So, to start with, can you just give us a bit of background on your SAP experience and your Microsoft experience as well? Sure, yeah.

James Wood: 2:16
So I got started in SAP you can probably tell by the gray hair back in 2000. So I've been in that space really ever since. It was kind of funny at that time a lot of my fresh out of college, a lot of my friends were getting jobs at coolcom startups and I got this job doing this SAP thing that had this ABAP language that looked kind of like COBOL and I wasn't quite sure what I was getting into. And fast forward, 24 years later I guess I'm still in the space. But my background prior to that I was a computer science major in college and I'd kind of grown up around well, a little bit pre-dotnet but Java and some of those languages and so I guess my approach to SAP was a little bit different than maybe some of my counterparts at the time that maybe came from a more business background that kind of trained themselves up on ABAP and SAP kinds of things you know. So I was always sort of coming at it from the tech perspective and the early days, especially pre-NetWeaver you know there's a pretty limited tech stack to work with really. You know it's talk about low-code. You know SAP it's all about. You know 4GL programming language and some of the things built into ABAP and the surrounding stack. And so there's always kind of this foot-in-two-worlds phenomenon where, on one hand, I think SAP was built at a time when there really wasn't anything in the market that really was able to do a lot of the things that it did, and while it's not maybe the sexy technology, there were some really important lessons learned as far as how to build enterprise solutions at scale. I mean, I've always been amazed at just the sheer amount of code that SAP maintains, going all the way back to, I think I heard a couple of years ago they finally turned off their last R2 system. But you've got customers in varying releases around the world and it's just a big, big universe.

James Wood: 4:21
And so, you know, for myself, getting into Power Platform, it was, you know, on one hand, you know a very, very different world and another, you know, I think you know, sap for years and years has been trying to come up with low-code-ish things that could maybe simplify this process and all of a sudden, with Power Platform, I felt like, okay, that's what we've been looking for for years and years and now we have this thing and what's kind of funny is as different as those two worlds feel I mean sap. Really, for the past 15 years, maybe a little bit longer, you know odata has emerged as the lingua franca of almost everything you know, and so you start to kind of look under the hood on both sides and all data versus very odata focus, and you know there's a lot of synergy where you might not think there is. You know, between the two stacks are very're very complementary and so, yeah, it's been an interesting journey to kind of figure out. You know what this path looks like and it varies from customer, obviously, but a lot of rich synergy.

Mark Smith: 5:25
So Microsoft sees there's an opportunity to have SAP and the Power Platform play together. Some years ago, the CEOs of the companies, including Adobe, all got together. They talked about a model of doing business around, a common data model and how business data. I haven't really heard anything since. That photo op Got real quiet, didn't it? Yeah, about that tie together, but one of the things that have obviously risen, and with the time that I spent at IBM, I saw it. Yeah, about that tie together, but one of the things that have obviously risen, and with the time that I spent at IBM, I saw it a lot as well.

Mark Smith: 6:00
Ibm was a big SAP implementer and I was actually hired into the business by the SAP practice because of my power platform experience, as well as with our colleagues. Because there was this identification of changes happening in the SAP landscape with the move to things like S4, hana and moving it to the cloud you know from an on-premise environment, whether it be on AWS or Azure and as part of this transition, what started to bubble out is this concept of clean core that I was hearing from SAP. Can you explain your understanding of that and that transition, of? What are the moves SAP are making around reducing the amount of code bases they have to support deployed all over and on-premise environments, and start to get to a point of allowing them to upgrade and roll out changes at a probably greater frequency that the world's expecting a lot more now than they could when everybody was dispersed in on-premise worlds.

James Wood: 7:07
Yeah, the ABAP workbench is simultaneously a very powerful and a very dangerous tool. Basically, the minute you log on to an sap system you have full access to the entire body of code, maybe have to acquire an access key, but for all intents and purposes I can go in there, I can edit anything, I can customize anything. You know I really have, at least historically, complete control over that environment and you know that that's one of those things where a lot of times you know it gave customers enough rope to hang themselves. You know, there's always kind of this distinction between core modifications which you know SAP would frown against. But then there was also, you know, the other side of that coin with enhancements where you know I can make very deep surgical enhancements and still follow the letter of the law. I'm not modifying anything. It's technically upgrade safe.

James Wood: 8:02
But over the years you see the gymnastics that some of the developers will pull to let me shoot some data into shared memory and then I'll catch it on the other side in a user exit and I'll do all these things and it's a house of cards just waiting for the next release to just blow everything up. And so CleanCore was an intent for SAP to sort of say okay, we're not quite at a SaaS level yet, although they're certainly pushing that, but let's start pulling all those enhancements out of the core. Let's keep whether you're on-premise in a private cloud, managed cloud, rise, whatever let's keep that environment as clean as possible. We'll provide some very limited in-app extensions, kind of what they refer to as some of their different frameworks, but otherwise I'm going to do that outside of the framework and of course SAP would love to tell you that that needs to happen in their BTP cloud platform and do it there. But I mean the reality is there's a very open architecture, even BTP cloud platform. You know, and do it there.

James Wood: 8:54
But I mean the reality is, you know there's a very open architecture even within BTP. You know the idea is, you know we're moving towards RESTful API consumption and you know that's a place where Power Platform can play very well. So yeah and it's. You know the story has gotten bigger. I mean you know Google's in the picture now and you know I see a lot of customers doing things in GCP and AWS and of course there's plenty of competition in the low-code space. But I think a lot of SAP customers are kind of at an inflection point trying to figure out. Okay, you know, especially if they've gone through this S4 upgrade journey. I just renovated 25 years worth of ABAP. Let's never do that again. So, whatever that looks like, you know whether let's never do that again. So, whatever that looks like, whether it's Power Platform or something else, I think that's where a lot of customers' heads are at.

Mark Smith: 9:40
So with that how I'll give you my experience. So what happens is that you're working with a customer. They've got SAP and you say, hey, we want to plug this other technology into it. And all of a sudden people start to get a little concerned. Right, okay, you're going to plug something into our SAP.

Mark Smith: 10:00
And keeping in mind, customers that are running SAP are generally at the top end of town, right, their mission-critical, you know, sap is the backbone of their business. They cannot afford for one data corruption, they cannot afford for it to go down, they cannot afford for it to be broken because it runs their organization. And so now you're saying, hey, we want to plug something in from a totally unrelated ecosystem. And I'll tell you the objections I have had come up and I'm interested in your opinion on them. So one is what's the licensing implication of this? And I'm not talking about the licensing implication from microsoft, um, because we know to make a connection like this, you're going to need premium. You know licenses related to the Power Platform.

Mark Smith: 10:47
But the issue is around what are the licensing exposure that I'm opening myself up to by connecting to this? And of course, I've heard wild figures in how big these licenses are Over a million to all of a sudden. Oh no, there's no license required for that right, but of course, the first thing the SAP seller does is fire up this whoa, hang on a second. The first thing they'll go. We have a low-code platform which they announced about two years ago. Right, right, but apples for apples comparison Maybe not. So, anyhow, I've given you a bit of stuff to work there. What are your thoughts?

James Wood: 11:27
Yeah you know.

James Wood: 11:27
I mean maybe for a Microsoft audience it's probably not unlike the conversations that we have around dynamics in terms of multiplexing and those types of things where, as long as you have licensed users, be it a principal propagation type scenario, single sign-on or communication user account that's set up for the purposes of integration. So for a Power Automate scenario, ad hoc workflow, those types of things, it's kind of the right license for the right job, which, admittedly, can be confusing and tricky for customers. But I think for the most part, I mean the good news is you know it's not as scary as I think a lot of customers think it is. You know, I know there are some stories that hit the Wall Street Journal some years ago about you know the SAP license monster coming up and you know performing audits and doing things. But I think you know usually, if you kind of look underneath the hood there, it's a case where a customer is really trying to cheat the system in some form or fashion and I'll just get one license and that'll be the entire company.

James Wood: 12:40
That's not really what this is about and I think for the power platform side it's recognizing, for example. I think for the power platform side it's recognizing, for example, the SAP Connector supports via S&C end-to-end single sign-on. There are other ways of facilitating the same thing. The trick is how do I get my SAP administrators and my Microsoft administrators on the same page? Sap is very they love to introduce proprietary protocols all over the place, so it's not always the typical setup and some weird exchanges that have to take place, but all the tools are there. It's just a matter of getting on the right page.

Mark Smith: 13:19
Yeah. So a couple of things in what you just said there. One is the multiplexing component, and I wonder multiplexing was written in a very much on-premise world. It's always written in a yesteryear time and, you know, for me it's like copyright law. Copyright law was created a hundred odd years ago and now we live in a world where you know ai, train models, etc. Is it copyright infringement when it was something you could consume naturally and just? We've got tech now that can do it at scale.

Mark Smith: 13:49
I think there's some laws that were written for a time that this is no longer the time, and multiplexing is one of those ones that I question. In a modern API-driven world where every system needs to talk to every other system, if we're going to get the level of automation and productivity improvements to every other system, if we're going to get the level of automation and productivity improvements. I know nobody's ever going to pull the multiplexing rules out because it's kind of like, hey, well, it's a safety net if anything goes wrong, right. But my question to you is is multiplexing really the thing it was in your experience in the past that we've got to be concerned about, without, of course, I like what you said when someone's deliberately gone out of their way to flout licensing to do something.

James Wood: 14:31
Yeah, I think you said it well just in terms of kind of that backstop, if you will, for really that specific case where the customer is just going way out of their way to cheat the system in some form or fashion. And I think the hard part for SAP if they did decide to try to put a stop to this is to your point of there's so many different systems connecting via APIs and if I really look at an apples-to-apples comparison between the way that Power Platform consumes SAP versus SAP's own cloud platform or some of their proprietary tools, it's almost identical underneath the hood. The SAP connector provided by Microsoft is built on SAP's NET connector, which has been there for years. Customers have been consuming BAPIs and RFCs this way for really 25 years. So I mean it would be.

James Wood: 15:24
You know, and we have seen you know odd little cases. You know, as Fabric has kind of popped up. You know there's been some SAP notes. You know, and we have seen you know, odd little cases. You know, as Fabric has kind of popped up. You know there's been some SAP notes you know saying well, we really don't want you to use this framework. It's not a technical reason for it, it's maybe Microsoft and other players are starting to get infringed a little bit on that territory, and so that's been a gray area that we've seen kind of crop up of late. Interesting. Put a little challenge on Microsoft engineering. I think, okay, well, this is an open framework, so now what?

Mark Smith: 15:54
Yeah, yeah. So you've talked about connecting and it's been happening for some time. Let's just unpack. Microsoft had a V1 connector, the SAP ERP connector for the power platform. That has been superseded. There's now a load balance connector. It has, you know. As you say, bapi is now supported. Rfcs are supported. I think BAPI was supported in the first one, but not RFCs, from memory. There's new stuff coming out right. There's the OData connector. My understanding is waiting in the wings, about to drop Putting my SAP or getting you to put your SAP hat on. And, looking from that side of things, what is your SAP architect most comfortable when it comes to integrating to SAP from a CRUD perspective and the implications of that, like, what license is doing it? What are their permissions? Are they honored? You know, if someone's only got read permissions, they should only have read permissions in the Power Platform. If they have, you know, more open permissions, that is also supported. What is your view on this?

James Wood: 17:04
That's an interesting question. I mean, I think you know, from a protocol perspective, rfcs are the devil that a lot of SAP administrators know. Rfc just for those that may not be familiar remote function call it's not unlike a lot of different you know RMI type technologies proprietary to SAP. It's built on an old mainframe protocol. It's been around for years and years and years. So we talk about RFC functions, you functions, it's basically just that. Remote function calls. Bapis are basically standard interfaces built on that same technology and so just given how long and established that framework is, that's usually the number one. Okay, we're comfortable with that. We've done this a million times.

James Wood: 17:46
Power Platform is just yet another consumer that showed up at our door. Here's kind of what we expect in terms of communication user accounts and it gets into the security side of things. I mean, most SAP security teams are pretty comfortable with understanding. I need a communication account that's going to create equipment records, update work orders and do this other thing, and so they'll basically start from zero level of access to the bare minimum of requirements. It's very rare that you get an account like that that has got access to do lots and lots of things, and so usually when we start there, we don't get a lot of pushback.

James Wood: 18:25
The web protocols, odata, things like that.

James Wood: 18:30
That's where things start to get a little tricky, because now you're asking some of these administrators to dip a toe into some newer web and security standards that might be a little bit outside their comfort zone.

James Wood: 18:42
Oauth is not a typical thing that happens in an SAP environment, although in Microsoft land it's just kind of part of the day-to-day. So you know there's some struggle there, we'll get some pushback and you know that's usually where we just have to, you know, kind of get both sides together and kind of help map you know this is, you know intra-ID is on the front side and this is how we're going to be issuing, you know and kind of draw those pictures you know big animal pictures to kind of help everyone understand and get on the same page. And then, you know, as that relates to security, now we're starting to kind of get into that principal propagation, single sign-on where, yeah, things can get messy, you know, and you know it's usually what we've run into there. It's not so much a limitation of the framework or the technology, it's more of a customer may have established some standards, that no particular reason. It's just kind of our preference. This is how we initially will say no, you're going to have to convince us to say yes, yeah yeah, yeah.

Mark Smith: 19:45
What I've noticed is that in a lot of the presentations that I have done with customers, there's an appetite from the business to adopt the Power Platform and the ability to rapidly produce apps. That can reduce the time it takes to do so many things in SAP, right by producing those. And then they're excited about it, but they're going to pay for it and then your SAP architect enters the scene and pretty much computer says no, right, they're like they start from a. My defenses are up of why we can't do this rather than why we can't. You know, I find and I'll probably get shot for this but there's a kind of.

Mark Smith: 20:29
You know most IT departments are not known for their innovative you know posture. They're there for governance, they're there for compliance, they're there for security, they're there for maintaining the status quo. They don't look at their role as let's help our organization go to the next level and innovate on these technologies. And you know I've been involved in companies I've worked for that have IT departments and anytime they see something new, they know that means their learning has to increase. And come on, we've been doing our role for 30-plus years. We don't learn something new. We're just waiting for pension to click in and retirement, and now you're wanting to play with something like and they've got that, we don't want to. You know, really type attitude. How do you overcome this? How do you get beyond that kind of resistance? Can you educate beyond it? How do you handle it?

James Wood: 21:21
Well, you know, I think for us I mean one you know kind of unique factor is that, you know, because we have resources that can speak to both sides of it what we really try to do is, before we ever have those conversations, come prepared with architectural diagrams, you know, any sort of documentation that we can put together to assuage any concerns and kind of you know, walk everyone through. All right, these are the five steps it's going to take and these are the different responsibilities and roles that are going to be involved and things like that. And even there, sometimes there's some resistance just from we don't have time for this. We've got our day job and this is all that that implies. But I think the more that we're able to kind of show or provide examples I think that's one thing we found that's very powerful is okay.

James Wood: 22:12
yes, Power Platform is new, but it works just like this If we can kind of map that over to so like, for example, the on-premises data gateway in the Microsoft world. There's a similar component in SAP called the SAP Cloud Connector. So if I can connect those dots and show you, you like this is the same thing, you've installed it over here. That's all we're asking. That goes a long way towards kind of okay, you know, now people's guard is down a little bit more and we're able to really talk through just a practical project plan.

Mark Smith: 22:41
Yeah, so I know that you've built your own connection framework between the Power Platform and SAP. What brought that about? What was your objective? How is it different than what Microsoft provide with their premium connector? What problems are you solving with it?

James Wood: 23:00
Yeah, you know, for us it's all about right tool for the right job and I think you know Microsoft has an excellent connector. It's all about right tool for the right job and I think Microsoft has an excellent connector. But even with the advent of the OData connector, in both cases we're talking about very, very technical connectors. If you think about, how do I enable citizen makers, which might be a stretch in the SAP world, but for those that may not come from an SAP background, I don't speak in five-character German abbreviations. I don't understand in five-character German abbreviations. I don't understand.

James Wood: 23:28
You know some of these protocols and you know some of these BAPIs are enormous. I mean, you're talking about, you know, every possible field that could be related, all one big, huge. You know JSON or XML payload. You know that's beyond the capabilities of a lot of makers working in the power platform space. And so what we tried to do is introduce, you know, abstraction layer that helps us take that functionality out of SAP and graft it into Dataverse, which is a much more comfortable place for a lot of these developers to be in, and then from there it's a little bit more of a choose-your-own-adventure. I mean, you know the connector facilitates single sign-on automatically. So you know.

James Wood: 24:05
So, whether I'm coming at it from Power Apps or Power Automate, what have you?

James Wood: 24:08
To me it just looks like another table in Dataverse behind the scenes. All those abstractions around protocol handling, security, caching, pagination with large data sets, a lot of that is something that we can kind of push that behind the scenes, and so the makers are what know what they're seeing hopefully, you know, if we do our job right is a virtual table that has, you know, human, readable names. And you know, if I want to build a model-driven app, I can just start dragging and dropping and, you know, putting things on the screen and magical things you know happen behind the scenes. And so that was kind of our thought, is providing kind of our thought is providing kind of another view of how to access SAP data without having to write OData queries. I mean, that's not something people necessarily know how to do. I know a lot of power platform makers have Fetch XML Builder open all the time and maybe they're a little more comfortable, but there's a lot of complexities here that you have to account for.

Mark Smith: 25:07
So is the unique element compared to what Microsoft are offering the virtualization in Dataverse.

James Wood: 25:14
Yeah, I think we felt like Dataverse kind of provided a level playing field. For take, for example, I want to build a power app to manage my timesheet I can 100% do that. I can build a Canvas app and I can timesheet I can 100% do that. I can build a Canvas app and I can use connectors and I can make all these RFC calls, but I'm ultimately responsible for all those calls. I'm having to deal with some very complex data types. I'm having to write some very advanced Power Facts to kind of build collections and filter and all those sorts of things. And then the flip side of that is, if I virtualize and I pull that into Dataverse now, then that, whether it's canvas model driven, I can basically just bind to that connection and I'm off and running in a much more power platform centric kind of development. And so for us a lot of it was about scale. Sure, we can build one or two of those apps reasonably fast, but how do I get to a place where I'm doing wholesale SAP enhancement work at scale across the enterprise?

Mark Smith: 26:14
Yeah, my understanding of the SAP ERP connector from Microsoft was it interfaced with Power Automate as its starting point and then off into things like Power Apps. Do you know about the OData connector? How is that still having that? You must have Power Automate in the mix, and does your tool have to have Power Automate in the mix, or is it not needed as the first integration point?

James Wood: 26:40
Yeah, I mean Power Automate is not technically needed.

James Wood: 26:43
I think the challenge there is just the complexity associated with the calls and how I deal with you know. So, taking into account the single sign-on aspect, you know how do I build my RFC connection to take advantage of S&C, which is kind of their protocol for single sign-on and all of that for single sign-on and all of that, and so a lot of times you know that work would end up in Power Automate because you might have more technically focused individuals. You know, almost like a logic app building. You know here's a call out to SAP and here's this magical cloud flow that you can call and you know, put in these inputs, you'll get these outputs and then you know, go off from there and build your Canvas app. I think OData connector it's a similar kind of thing. It's easier to set up the connection but you have to understand the OData protocol to really be able to understand how do I build my filter query, for example, and things like that, and so there's a little bit of abstraction there, but it's still very much a technical connector.

Mark Smith: 27:45
Yeah, We've talked about authentication a few times. Did I read rightly? A couple of months ago SAP came out with that they were moving to EntraID as their main authentication layer. What's the implication to SAP customers for that? Is there like a life window that they have to do that migration in?

James Wood: 28:10
life window that they have to do that migration in or um. Well, so that that referred to a btp service, you know. So sap kind of tried to um and they still have some different versions of it. It gets. It's pretty complex but they had an identity management service that was kind of built to be an abstraction around. You know most any saml2 oauth compliant open id. You know most any SAML 2, oauth compliant OpenID Connect. You know back end. So you know it's not uncommon to BTP to federate with InterID or Okta or you know a lot of these different providers.

James Wood: 28:35
But you know when they started building this, you know one size fits all framework.

James Wood: 28:41
I mean I'm speculating on SAP's part, but I think it got to a point where every customer is kind of coming with a different provider and different idiosyncrasies and things like that. And I think the move towards inter-ID was that inter-ID can handle all of the above in terms of federation and things like that, and it was by far the most common scenario that I think SAP customers were coming to the table with, and so maybe a little bit of a raising of the white flag on SAP's part. I mean the story of their cloud platform has been an interesting one. I think in the early days they were looking to compete on the same level as hyperscalers and then slowly pivoted over the years towards how do we differentiate from more of a business-centric perspective? So we're not going to compete with Azure in terms of cloud backing services, but maybe we can offer more business-centric services or services that help specifically SAP customers do things, and so you've seen a bit of a shift in their services model there to let's let the hyperscalers do the stuff that they're good at.

Mark Smith: 29:49
How do you handle a scenario that you're engaged with the customer? You've introduced the concept of the power platform is going to solve a bunch of their business challenges. We're migrating in two years' time to S4 HANA and we don't want to do anything else now. We're going to wait until that future date, which is how do you handle it?

James Wood: 30:13
That is a tricky one. I think we've seen some customers really dig in and we're in year two of a five-year window of moving to S4, and we're really not going to do much of anything. Our counter to that is don't take our word for it.

James Wood: 30:27
Take SAP's word for it, I mean this CleanCore movement is something they've been pushing forever and if you really believe in that, then if I'm following best practices around CleanCore and RESTful API consumption, this is the optimal outcome for the business, because, I mean, we've had many conversations with S4 customers, where the business I mean we can't wait three years. This journey could take a very long time and we need innovation now and there's no technical limitation or risk of upgrade that's blocking this. This is purely a you know, if I may say so scare tactics on the part of SAP sales and really convincing customers that you know we need to. You know, follow a certain process and it's just. You know it's frustrating.

Mark Smith: 31:22
And if you follow those principles of clean core, anything that is built is going to be usable, isn't it, um, once you have gone through your migration, so it's not like it's wasted. You know you build something, you only get three years use out of it. Um, you can extend well beyond that because, yeah, okay, we've covered some ground. Anything else you'd like to add?

James Wood: 31:42
you know on that, on that topic of you know what do businesses do in that scenario? Yeah, I think another thing that we've seen that's kind of interesting is, you know a perception that you know not only is it maybe technically risky to do this stuff now or during the upgrade process, but on the other end of that process, you know what, if I build this power platform solution and there's this SAP functionality that supersedes it, and I think that's something again that there's a bit of a misnomer among customers. And I think one thing that we've heard pretty much on repeat with a lot of our S4 customers is certainly there are parts of the system that have been renovated and then the other parts that they're surprised at how much it's pretty much status quo from where they were in ECC. And so you know those roadmapping journeys, I think a lot of times the thought is let's get through the end of S4, let's maybe do a technical upgrade and then we'll revisit all these things.

James Wood: 32:37
Now is kind of the perfect time to be really investigating. You know, what does my gap coverage look like? You know, am I going to get to the end of this journey and realize I've got larger gaps on my hands that you know could have easily been filled by Power Platform in the meantime. That's something we've been really talking to a lot of our customers about is you've got a lot on your plate, obviously as part of this upgrade process, but you know, renovating 25 years worth of ABAP code for this Power Platform or something else, renovating 25 years worth of ABAP code, whether it's Power Platform or something else.

Mark Smith: 33:11
those are conversations that need to be had now. Yeah, yeah, so a couple of follow-ups. What's your thoughts on the SAP low-code story that they acquired a company from memory and they have a low-code tooling? How do you answer that?

James Wood: 33:23
Yeah, I think you know we'll see where they they get to. I mean, I, I think you know we get questions all the time. You know why power platform and I think you know one of the things we point to is, you know, if you look in gardner, you know whatever section you want to look at to us, you know power platform is one of one in terms of, you know, being grown up and built on azure, which you know I, I think when you start to do a, you know side-by-side comparison, you know a lot of what SAP has built. There is, let's repurpose an open source framework and put a little polish on it and things like that. And so is there a Power Apps equivalent? Well, kind of you know, is there a workflow equivalent? You know, I mean all the packaging is there. But you know, I mean all the packaging is there. But you know, in terms of the breadth and the depth of the functionality than power platform it's power platform is, you know, just, it's a much more mature product, no doubt about it interesting.

Mark Smith: 34:18
what about sap? Uh? Developers that say listen, we can build this ourselves in bTP. We can create this type of same functionality. We don't need this another tool, we can do that ourselves.

James Wood: 34:33
I mean I would kind of put it back to just thinking purely in Microsoft terms. It would be like your NET development team telling you oh yeah, we can build apps just as fast from the ground up in C, sharp and ASPNET and whatever. And sometimes that might be true and other times I think, the ability of those teams to really keep up with low-code. I mean just for us here at Bowdark we've seen I would say conservatively a 60% increase in productivity from doing I mean, we're in the weeds doing.

James Wood: 35:08
You know ProCode development and SAP every day and there are times when ABAP makes a lot of sense. But you know, when it comes to your garden variety enhancements, you know reports and interfaces. You know just the common stuff that gets built every day. You know it's such an accelerator to have a tool like that to really start to work down those backlogs, which creates some interesting conversations at IT, kind of what you were talking about before. We're just here to keep the lights on. It changes that equation a little bit. We can get more of that backlog knocked out in this environment.

Mark Smith: 35:43
Nice, If folks listening want to reach out to you. What's the name of your connector that you've got?

James Wood: 35:52
So we call it Bowdark Fuse. We've got information on the website, we've got a video that kind of demonstrates how it works. I think we did a live demo out on the SAP on Azure podcast as well. So there's some information out there for people to see and kind of play around with it, and of course we're happy to have those conversations and facilitate a trial.

Mark Smith: 36:16
Excellent, and so, whether you're a Microsoft partner or working for a Microsoft partner or a customer, both use cases can reach out to you and you can provide guidance.

James Wood: 36:27
Absolutely yeah, we love talking all things Microsoft and SAP.

Mark Smith: 36:32
Excellent. Are you going to be at the upcoming conference in Vegas for the Power Platform?

James Wood: 36:37
We will be there. Yeah, we're looking forward to it. Year three Awesome, James.

Mark Smith: 36:42
thank you so much for coming on the show.

James Wood: 36:44
Thanks for having me Appreciate it.

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