Power Platform Elephants

A few things happened recently which got me thinking about things we usually don’t talk about in the Power Platform world:

• Steve Mordue mentioned Dunning-Kruger Effect in his recent podcast/blog post:  https://stevemordue.com/microsoft-marching-masses-to-peak-of-mt-stupid/
• Another fellow MVP, Olena Grischenko,  posted this interesting comment on Linkedin: “Doing lots of error handing in Power Automate recently Feels more and more like a real dev :)” Check out her blog if you have not done so yet – there is some seriously fun stuff there: https://msolenacrm.blog/blog/

And, yet, somebody posted an issue to my PCF components github repo asking if it’s correct that I don’t have a managed solution there

This all got me thinking about… well, about the elephants:

Although, not just about any elephants, but about those which are, sometimes, in the room.

So, maybe, let’s reveal some of those.

When it comes to the PCF components, there are lots of great PCF components in the PCF Gallery, and I’m sure every one of us can find at least a few there which might be useful on the projects we are working on. Those components can improve user experience, they can take away some awkward out-of-the-box customizations, and they can add features which just would not be possible otherwise:

And, yet, what do we do if one of those components misbehaves half way through the project, or, worse  yet, once it’s all in production? With the open-source components, there is no guarantee we’ll be able to get any support from the original developer, so the only option would be to hire a developer to figure it all out.

Which is my elephant #1: with all the good PCF components can bring about on the Power Platform projects, there is one inevitable evil that will come, too… which is the professional developer.

Is it really that bad? Surely not, it’s just  something you can count on if you are staring to use PCF components irrespective of the fact that those components might be developed by a third-pary originally.

Now, how about low-code development with Flows and Power Apps? Originally touted as something that business users will be able to do, I think it’s now becoming a thing Citizen Developers would rather be doing. And, yet, as Olena somewhat jokingly noted, this is already starting to feel like real development. You have to know how to handle errors, how to use connectors, how to parse json, how to orchestrate canvas apps and flows so they work together, how to use FetchXML, what is Web API and how to build queries there… that list never ends. And, of course, you have to keep up with all the changes Microsoft keeps pushing.

Which is my elephant #2:  so-called low-code application development tools are still development tools no matter what, and those who have more experience with them yet who are willing to toy with such tools will usually be able to develop better applications. Besides, one you start talking about git repositories, ALM, solution layering, etc… it’s very likely  you need a person who does not mind talking that language. And, of course, that’s almost a definition of what a “developer” is. Now, whether it’s a “citizen” developer or a “professional” developer… I’m not sure it matters. You won’t hire a .NET developer to work on Power Automate Flows/canvas apps development except, maybe, if he/she is willing to change their career.

This misconception might be one reason why a lot of clients might be marching towards that peak Steve mentioned.

But, I think, there are more elephants hiding there.

My #3 elephant would be licensing and limits.

Licensing has always been painful, it still is, and a lot has been written about it. What licenses do we need? Will we run into those limits? If we will, what do we do? How much will it cost us?

It seems to be almost impossible to get precise answers to those questions – instead, clients will often deal with this by taking a leap of faith approach.

 

And this all brings me to the elephant #4 for today: quality Power Platform implementations will rarely be fast, furious, and cheap

I’m glad most of the projects I worked on so far were big enterprise projects. And it’s not that the projects were, always, big. But the enterprises were definitely big enough to deal with the unknown. This unknown comes from the overall depth and breadth  of the platform, from the rate of change, and from the licensing uncertainties.

Out-of-the-box functionality, even though it’s quite powerful, will usually have to be extended. This will all but ensure that developers will be involved (professional or “citizen”… for what it’s worth, I usually see them being the same people). End users will want features. Business groups will not agree on the security. SSRS report won’t work, so Power BI will be required, and not just any Power BI but a Premium one.

It won’t be long before you need somebody who can help you navigate those waters, so you’ll be asking for some help from the community, partners, consultants, Microsoft services, etc.

 

And, yet, with all that said, those are just elephants hiding around. They are nice animals, and they are easy to spot. Besides, they have thick skin, so it won’t hurt them if you name them, deal with them as best as you can, and, then, proceed to building awesome projects with the Power Platform!

 

Have fun!

 

PS. Just realized it’s Thursday, and this post came out as a bit of a rant… which means  “Thursday rant” is becoming a bit of a tradition. Not sure if it’s good or bad:)