Enabling Power Platform in a Pro-Code IT World

This content originally appeared on DEV Community and was authored by david wyatt

For me the Power Platform was launched from a business user angle, not a IT user. It was very much like Excel and the Office Suite:

• Everyone can use it
• Uses the owners connections
• Require right to create to use
• No ‘Out of the Box’ admin sharing controls

But over time the Power of the Power Platform became more evident, with IT admins wanting better control and governance over it, that lead Microsoft to enabling controls and key things like ALM, pipelines and managed environment features. This moved the platform more towards IT experienced/minded users, with developers now having to understand additional controls and processes a Excel developer (yes they exist, VBA is a coding language ) never had to deal with.

Now that the Power Platform feels more IT enterprise ready you would expect IT teams to embrace it, yet there still seems to be an inertia for ‘Pro-Code’ IT departments to understand and embrace Low-Code technologies like the Power Platform. A lot of this is for good reason, the simple fact is when comparing Low-Code and Pro-Code solutions, Pro-Code is better. But that to me is the issue, you shouldn’t be comparing them, they are complementary, Apples and Oranges.

And this is to me the fundamental challenge Low-Code adoption has, IT teams treat platforms like the Power Platform the same as solutions built in React. This highlights the deficiencies of Low-Code without the benefits. But the irony of this is that with the explosion in AI dev tools and ‘Vibe Coding’, IT teams are going to potentially make the same mistake.

So what are the differences.

Pro-Code solutions are top heavy investments, they require time and cost to build and then get their ROI over time, the longer they are used the better.

Low-Code is the opposite, little to no up front cost and time, but with license costs the longer they are used the more costly they are.

We can see now where ther divide should really be:

3D Printers

I love analogies, it’s how my mind works and how I like to explain things, and I was racking my mind for what a good analogy for Low-Code platforms like the Power Platform, and I came to 3D printers….. trust me.

Comparing 3D printers to ejection mold printing is my analogy for Low-Code and Pro-Code.

Injection mold will in most situations be a better quality, but it requires upfront investment in machines and molds.
3D printers has small upfront cost, but generally don’t match the injection mold quality and per unit price is higher, but they are a lot quicker and easier to iterate over. This is exactly the same mentality we should be taking to Low/Pro-Code.

Getting Your IT Team to Understand Low-Code

Understanding the differences and benefits are key to getting IT teams to engage with Low-Code tech.

Enterprise Architects

A great place to start is your Enterprise Architects, they have a holistic view of all tech in your org, and are the first stop when planning solutions.

As a Power Platform CoE/admin, you need to be working with your Enterprise Architects, ideally have your own Product Architect just for the Power Platform and ensure they work closely with the Enterprise Architects about new features.

The simple fact is Low-Code tech, particularly the Power Platform, moves fast.

The pace of change has never been this fast, yet it will never be this slow again.
Justin Trudeau

There are new updates almost daily, roadmaps only stretch 6 months, and they are anything but thorough. Expecting Enterprise Architects to keep upto date with them will only lead to missed opportunities. The very landscape of architecture is moving from enterprise strategies to integration strategies across different business department strategies. With the Power Platforms strength being integrations, particularly within M365, it should be one of the biggest benefactors to new the shift.

And guess what is also moving even faster, yep AI. If your Architects can’t keep up with the Power platform what chance do they with all the Latest LLMs.

Tech Approval

The next place is your technology approval/procurement process. The standard approach to this is Request – Approve – Procure.

But this approach is totally wrong for Low-Code, think back to the 3D printer, you don’t buy a printer because you want to print a specific thing, you buy it to be able to print anything.

It’s the challenge I see, let’s take Power Apps as an example.

Business team need a simple app, quickly for a specific issue. Power Apps is perfect, they can build quick with no need to acquire funding. But as Power Apps is not approved they go through approval process, this takes time, which removes the key benefit. So the team has to find another solution (cough, Excel, it’s always Excel).

But if we had approached it differently, where Power Apps was approved to be ready for use cases, then we can have everything ready.

You need to work with the team, getting approval for future opportunities/enabling future problems.

And here’s the next synergy with AI, if you focus on waiting for the perfect use case to enable AI tech, you are leaving so much potential on the table. AI will solve problems you don’t even know you have, so its key to have it approved ready to go, as that approval process will inevitably be longer.

Security

Security is often a after thought it Low-Code, but it should be at its heart, the fact is Low-Code is more secure* (big asterix there I know). When things like authentication and sql injection protection is handled ‘Out of the Box’, things are so much easier. Engaging with Security to highlight this is key, as once they understand they will often default to recommending it, as by its very nature Low-Code is patterns, and that’s what security love.

But here’s the asterix, Low-Code does have risks, but very different risks. Generally around developers and admins experience, citizen developers are unlikely to understand PoLP, Defence in Depth, or Security by obscurity is not security. Working with your Security team so they understand how the risk landscape is different will again push the benefits of Low-Code.

Realted again to AI, the risk landscape is different, with things like Prompt Injection, Security teams need the ability to pivot to new risks.

Upskill Pro-Code Teams

The final piece of the puzzle is working with the Pro-Code teams directly. Ensuring they understand it’s not a replacement but just another tool in their arsenal.

This needs to be done through training and enablement, IT teams will need/want to have a very different training plan compared to citizen developers. Likewise they will want the opportunity to embrace more control in their part of the platform. This could be as simple as providing their own managed delivery process, to having their own environments, DLP, and admins.

Yep another AI synergy, use of AI tools like Copilot and Cursor is not as simple as just click and go. Understand where AI tools add benefits, how they hallucinate, and how best to prompt are all new skills that IT teams need to learn.

As you can see the 2 pillars to this strategy are:

1. Explaining the difference of Low-Code (and AI) to Pro-Code (get out that 3d Printer )
2. Engineers building within the Power Platform (and any AI/Low-Code platform) have to share up all the new features, as the rate of change is simply to fast now for top down knowledge sharing

And the similarities with Low-Code and new AI tools are high, so getting one right benefits both.

 
Subscribe to David Wyatt

This content originally appeared on DEV Community and was authored by david wyatt