Senior Consultant David Eagle explains the pitfalls of citizen development and how to avoid them by taking a professional development approach.
The Power Platform journey; from Citizen Developer to Professional Development
There is a lot to be said for the citizen development model. Low code / no-code platforms such as Microsoft’s Power Platform can empower talented users to build their own apps, perform their job more efficiently, help the company save on operating costs, and help reduce IT backlog. It is a well-trodden path. And rightly so.
Where the model falls down, is its reliance on the Citizen Developer. When they leave or change roles, it can be hard to maintain and enhance apps and processes. In the past, this has manifested itself during the application build using Microsoft Access, a process that is still critical to some companies today.
Your Microsoft Power Platform will be a combination of Power Apps and Power Automate flows that have been built up over time. They are likely to be interconnected. A simple change will impact the application/process whilst also having a downstream impact, breaking something else that had a dependency.
One way to reduce the reliance on the citizen developer is to adopt an Application Lifecycle Management approach (ALM).
ALM like a Pro
In professional development the concept of moving apps through a set of environments, performing tests, and validating functionality are commonplace. A typical flow would be:
Development > User Acceptance Testing (UAT) > Production
During development, you are likely to be using a source control system to track changes so that you can revert to a working version if there is a problem. Ideally, the deployment between the environment would be automated in a deployment platform to eradicate mistakes and provide a role back mechanism.
This can easily be done in a Power Platform environment. Take all the elements that make up your business-critical “application” and move them into a Solution in a Power Platform environment so that everything is contained in a single deployable package. If you choose to develop multiple solutions for your application, ensure that you package common components together for development and deployment.
Use environment variables to ensure that the data source and reference data can be easily updated and maintained in development as well as UAT and production.
The Power Platform Development environment is where the citizen developer can make their changes. They use a source control system to track any changes and revert where required. When they are happy the solution is exported as a package for deployment to another environment for testing.
Whilst this can be done manually, I would recommend using an automated DevOps pipeline because it is repeatable and minimises errors.
UAT is where the newly updated solution can be tested for functionality and usability. It can be tested manually, although I would recommend an automated test framework. If it fails the tests, then there is no problem. The solution is removed so that the issues can be resolved in the development environment.
Once you are happy, the solution can be deployed to the production environment with the knowledge that it has passed all the tests and can also be retracted should issues be identified.
Four Pro tips for using the Microsoft Power Platform
- Don’t develop using live data
Developing with live data is an easy trap to fall into. Power Platform solutions can be used with a variety of data connections – SharePoint, Dataverse, SQL are examples of this. You can avoid pointing to live data when developing applications, by using environments, solutions, and variables to point your application at different datasets for each environment.
- Refresh your development data
By using UAT and Development data environments you can refresh from the appropriate source.
Where SharePoint is the data source, you can achieve similar synchronisation using an appropriate synchronisation tool, such as ShareGate or using scripting such as PnP PowerShell.
For SQL based projects a common practice is to have regular data ‘refresh’ whereby tables, records or sometimes the whole database is pushed from Production to UAT (and less often – Dev).
- Automate
In most cases, these data refreshes can also be automated using DevOps pipelines or scripts. This helps with creating realistic test and development data. Remember that your audience and security in a development and UAT environment is not usually the same as a Production environment. Therefore, it may not be appropriate to copy data from Production, especially if it contains any personal or business-sensitive information.
- Plan
There are some important things to consider:
- Quite often the initial PowerApps and Flows are created in the tenant default environment. Don’t create development solutions here, as they can be edited by everyone.
- Take time to design the environments and define who has access.
- Environments use up Database capacity – this may or may not be an issue depending on licences purchased in the tenant
- Where possible automate deployments. They can be hard to set up in the first instance, but the payback in the long term is worth the effort.
I hope this insight helps. If you have any thoughts or feedback, then email me at David.Eagle@triad.co.uk
