In my opinion, one of the biggest dangers to any Power Platform setup is technical debt.
Technical debt is the implied future cost of reworking software caused by choosing an easy, fast, or suboptimal solution today instead of a better, more robust approach. It acts like a financial loan; while it speeds up initial development, it accumulates "interest" in the form of harder maintenance, increased bugs, and slower future development.
Reading the above definition its easy to think that low-code tools like the Power Platform decrease the impact of technical debt, and that's kind of true:
It's easy and fast, but robust
but the risk of tech debt in low-code tools is there, just in a different format
- The Risk
- How To Manage It
- Low-Code and AI
1. The Risk
Low-Code technology builds on a foundation of re-use. Components are standardised, so custom code is minimalized and the risk of tech debt is drastically diminished.
The problem is there are 2 sides to tech debt, code and implementation.
Reading the code is one part of it, working through the choice of structure, functions, libraries etc, most of which is pre-created in the Power Platform.
But then we have implementation, its the next level up:
- Why use an action in a loop instead of a filter
- Why use a variable there
- Why chose a flow instead of in app
and although implementation has less impact then code Low-code introduces 3 magnifiers:
Quantity
What's great about the Power Platform is its free (excluding premium functionality) for E3 and F3 licenses, so it's available to almost everyone, and that means volume.
Each flow or app maybe simple, and have minimum complexity, but the sheer number can break any CoE team. Just figuring out what something does takes effort, and dealing with so many diverse solutions can be tsunami.
Lifecycle
This is the real kicker, Power Platform solutions generally start as personal or small scale, so there is no plan for the life of it. And in the life of every Power Platform solution you are going to have 2 potential big life events:
Growth - adoption grows, new features are needed
Ownership - the developer moves on
Both mean implementation goes "wonky", as growth means building on top of something that wasn't planned to be built on (imagine a house with single story foundations having a second story added). And ownership changes often means that any updates are done in a totally different way. With design patterns/styles mashed together, making understanding even harder.
Engineering Mindset
An engineering mindset refers to the values, attitudes, and thinking skills associated with engineering. Engineers solve problems using systematic, iterative processes.
Low-Code allows people who don't have the time or opportunities to learn the deep technical knowledge to be a developer, and that's a massive pool of talent which makes Low-Code so valuable. But it also allows people who, without being rude, maybe shouldn't be developing.
The engineering mindset is key to being a good developer, and generally that ensures a foundation of design decisions that allows others with the same mindset to gain a quicker understanding.
So you will often find solutions that are even harder to understand, as although they solve the problem, it maybe in a very unique/unconventional way.
As the risk is still there, what is the possible negative outcomes. If you don't manage technical debt then your Power Platform will run great for a couple of years or so, but in that time 2 things will happen:
The solutions will become critical - roles taken on extra responsibility so can't handle the manual workload anymore. They also scale from personal/team to broader departments.
The original developer moves away, they get promoted or leave the business. The solution gets handed over a couple of times, but each transition is to someone less interested and knowledge is lost.
It starts off as one or two, but soon the CoE is undated, solutions that are too big to fail, with no team available to own it anymore, they are what we called orphaned.
And now you are desperately trying to figure out how they work, the issues that were manually handled, and how to make them stable and scalable.
And trust me when I say this, it will be a tsunami, and every solution you take on means less time to support new, often more critical, solutions being delivered.
2. How To Manage It
As a CoE you need to get ahead of this risk, and ensure that there is no technical debt. As no matter how hard you try and how many agreements you have, that orphaned solution will keep going up the leadership pyramid and until there is someone high enough to override all your agreements.
Standard Operating Procedures (SOP)
Every Power Platform CoE team should set up their standard operating procedures, these are the agreed way to do things. Often there are many different "right" ways to solve a problem, but to ensure easier understanding and less tech debt one right way should be agreed. This is your SOP, it should cover things like:
- Naming Convention
- Design Styles
- Integrations/Connections
- Environment Variable design
- Solution Setup
- Access Management
Having this documented ensures that every developer can start on the right path (if they decide too that is).
Training and Certification
MS Learn is great, and has some fantastic modules, but it's not enough. YOu need you own foundation training process. It should cover the nuances of your setup, your SOP's, and broader governance. Ideally you will mix in some MS Learn modules (but be warned Microsoft loves to change them with new features that you may not have enabled, I got burnt by a rogue Power Automate Desktop module in middle of a Power Automate Cloud module).
Lock Down The Default
Unfortunately Microsoft created the Default environment which means you can't easily get involved with the developer before they start building. But what you can do is limit the scope. The DLP policy should be very limited, only unblockable connectors, Dataverse should be moved to the non-business group so that it can't be used with anything else. No credits should be assigned and premium user licenses only given to makers who have completed training.
If you are able to make in a managed environment then do it, limit app shares to max 5 and flows should not be shared with security groups.
You should add what I call "Platform Flows", these are Power Automate flows that retrospectively fix issues that managed environments cant (and what you should use if you don't have managed environments). Examples I have include deleting Copilot Studio Agents and Agent Flows, and limit the number of flows a developer can have, any more they get turned off.
Automated Process to Prod
Now you have limited the risk in Default you need a pipeline to scale, and I don't mean automated deployments. You need a process where developers can:
- Submit idea and CoE validate it (Intake Review)
- Arch & Security Review
- Review proposed design (Design and Impact Review)
- Review code to ensue meets Arch/Sec/Design suggestions and SOPs
- Document Solution
- User Acceptance test Solution
- Deploy to Prod (Separation of duty and change control)
There are lots of out of box solutions for this, but you also have one of the most powerful development platforms at your disposal, so a custom app, automation, and database to handle this is at your fingertips.
Documentation
Linked to the above and a necessary evil, but so important. Solutions need to be documented, the should include at least a Simple Design Doc and Simple Design Goal to help explain what the solution does. Additional information about NPROD environments, environment variables, and access is also key.
Monitoring
The final thing we need to do is keep close eye on our platform (not that easy with the Power Platform), we should be looking for solutions that are scaling or growing beyond our controls. Identifying them early and moving them through the process is key, as no matter how good your setup, new unique scenarios will emerge.
3. Low-Code and AI
Now here is the big picture, AI tech debt is Low-Code on steroids.
- You think the volume of Low-Code solutions is high, wait till developers make 10 apps/automations per day
- You think the volume of Low-Code developers is high, wait till there are 10x more developers
Then the real kicker, the foundation of reusable components that Low-Code is built on is gone, now layers of spaghetti code trained on non-quality controlled code.
So the volumes are higher and the code harder to understand. And I know the expectation is that AI can fix tean create documentation, but:
- There will always be outline requirements/bugs that AI just can' solve
- AI lacks the understanding of the solution, so it's docs are always skin deep.
Tech debt isn't a Pro-Code problem, it's not a Code problem, it's a development problem, everything developed creates tech debt, you just need to manage and mitigate it.
Top comments (0)