The focus and usp of LowCode is it increase in productivity by decreasing development time. Unfortunately this can be misconstrued as decreasing beyond the actual development. Development is just one piece in solution delivery, it also includes:
- Archecture Review
- Design Review
- Security Review
- Code Review
- UAT
- Life Cycle Managment
- Support
and more.
Just because its LowCode doesn't mean you can skip the above, in fact with the prevalence of citizen developers they can be even more critical.
Key to a good solution is the 4 reviews
- Archecture Review
- Security Review
- Design Review
- Code Review
Code reviews
I've spoke about code reviews before (Power Apps and Power Automate), they are a key gate keeper to ensure that the solutions will be stable and easy to maintain.
Security Reviews
Security reviews are self-explanatory with the value they add, and just because its LowCode doesn't mean they are 100% secure. I've spoken about security vulnerabilities (again for Power Apps and Power Automate) in the past. Add in data (what you are collecting, how you are storing, how access is controled, business visibility, etc) you can see that a security review is critical.
Architecture Review
Architect reviews should really be your first review in the process. They check that Power Platform is even the right solution, what impacts business controls will have (e.g. DLP, licenses, addons, usage). Additionally they will know what changes are coming, not just for the Power Platform but all the systems that are key components. A good architecture review will save you lots of pain, and potential wasted effort, just imagine if you have to can the whole project because that connector you need is blocked.
Design Reviews
The benefits of a Design review are often not as visible or understood (and why this article is focused on it).
A design review should go in tandem with the arch review, I like to think of it as the same as building a house. The architect will design what it possible, the engineer will tell you if its practical and the best way to build it.
During a design review the developer will explain to a senior dev how they plan to cover key design aspects. So what should a good design review cover:
- Device
- Site Map (access / navigation)
- Connections
- Key Components
- Stack (e.g. flows and tables)
- Solution design
What it shouldn't cover is:
- Site Map (screens / layout)
- UI
- UX
- Theme
- Standard components
- Code
Device
This is kind of obvious, but the design review should understand the device (mobile/tablet/desktop) and how the app is suitable for it.
Is it responsive, how will it scale on larger devices, what will the impact of non-targeted devices be.
Site Map
Again another easy one, how are the users going to navigate through the app, does it need a consistent menu, should that be a custom component. If required how and when will the app elevate privileges to certain users.
Connections
The power from Power Apps is all about its connections. But is the developer using the right connections, are there too many (security will want a justification), are those connections using right permissions (does your app really need to delete the user's emails?).
Often developers feel more is better when it comes to connections, the more connections the more features. But that is not only a security flag, but can make the app slow, and difficult to use.
Key Components
What is a key component I hear you ask, well any component that is non-standard (and by this I can mean a collection of standard components used to create a component e.g menu). Why would that mean its key, well if you are putting effort into making your own date picker when there is an out of the box one it must be critical.
The developer should be able to explain why the component needs addition dev time, why the standard wont do, and hows it going to be built. Key components drive complexity, and a design review is all about simplicity, optimization and sustainability.
Stack
Another kind of obvious one, what else is going to be in the solution export and why. Does it need flows, if so why not use in app connections. Does it need Dataverse table, again why, are you prepared for premium license costs. Where are you going to use environment variables, etc. All key decisions that should be made before development and all should have justification.
Solution Design
And this is the big one, this is the practical logical approach. Similar to UI and UX this could easily be subjective, with there being no wrong answer. The key to the solution design is the developer knowing the options and explaining why they chose that solution. As a developer it is far too easy just to think there is only one solution, and once you have found it move on. When actually there is always multiple, and you should think of as many as possible, then chose the right solution.
An example would be a date selector, it could be
- Simple input which uses regex match to enforce format.
- Out of the box date picker
- Template date picker (gallery based)
- Completely custom
They all have strengths and weaknesses in specific situations, the developer needs to know them all and demonstrate that knowledge and decision making.
As you can see there is so much benefit in a good design review (and the other 3 key reviews), just getting your lead/experienced dev's to share their expertise alone is a long-term benefit beyond measurement.
Top comments (2)
Wow such an insightful article about software management with power apps. I'm curious if experienced developer actually enjoy working with low code platforms like power apps and what the benefits and limitations are compared to traditional development.
Hi z2lai,
Thank you, there are definitely things I like and things not so much. I would say that the main benefit is how easy it is to spin up full stack solutions (one solution). All the APIs you need, authention (at enterprise approved level) and flexible databases all available. Even the limitations of lack of flexibility can be an enjoyable challenge as it makes you get extra creative. The biggest limitation for me is the platform is driven by a single company, Microsoft decides where and what to improve.
The interesting thing for me is LowCode and traditional development are getting closer, LowCode is adding more and more traditional elements and traditional is going towards single solutions (Frameworks and companies like FireBase bring same benefits as LowCode)