I have found (in the 6 years or so of working and building solutions in Power Platform) that it is very easy to implement poor designs and non-scalable or non-reliable processes.
I got to work, searching and reviewing any guidance material available on this subject and found what I believe is a great starting point for many – the Power Platform Well-Architected Framework.
Power Platform Well-Architected is a set of best practices, architecture guidance, and review tools to help you make informed decisions about the design, planning and implementation of modern application workloads with Microsoft Power Platform..
If you’re familiar with other similar frameworks in Azure or the like, you will know that these frameworks are built upon architectural pillars. These help structure the guidance and map to foundations that ensure patterns and principles are delivering across all pillars.
The Power Platform Well-Architected (framework) has structured 5 pillars.
For me, this is the most important pillar. Reliable solutions should deliver enduring value.
If your solution fails to process records, recover from an outage or provides little to no monitoring of failures, then the solution can’t be relied upon and it will bring the solution, and maybe the entire platform into question.
A reliable workload must be resilient so that it can detect and recover from outages and malfunctions and consistently deliver functionality.
It must be capable of recovering from failures within a reasonable timeframe. It must also be available so that users can consistently and reliably access the workload during the agreed timeframe and at the agreed quality level.
Can you say your solutions can perform even after recovering from a total failure? Have they been designed with replay-ability in mind? Do you use dead letter queues or messaging platforms to persist failing workloads?
I am stickler for resiliency. Testing unhappy paths, exception handling and enforcing good practice to replay and recommence operations during an outage. This framework does a great job of highlighting the importance of reliability – an often overlooked principle.
I should say this is the most important principle, Security.
I know for many that I work with, Secure by Design is the goal we work towards but reality has proven otherwise. A low code or no code solution may expect security to be covered by the platform itself. Is Microsoft ensuring your solution is secure?
The platform does provide advisors and solution checkers but what about misconfigured access roles, poorly designed workflows or misused shared components?
A secure workload is resilient to attacks and incorporates the interrelated security principles of confidentiality, integrity, and availability (also known as the CIA triad) in addition to meeting business goals
As you design your system, use the Microsoft Zero Trust model as the compass to mitigate security risks.
The Zero Trust model is referenced in the framework and does provide a set of principles to determine your posture, but there’s more here than the guide provides which I will look to cover in a future article. For now, planning your security readiness is a helpful exercise and will provide a number of actions which will help strengthen your system and any custom built solutions.
The Operational Excellence pillar defines processes for development practices, monitoring and release management.
This pillar is one of my favourites. It brings the framework closer to the customers needs and asks questions that we otherwise may miss if we just concentrate on just the technical implementation.
Apply operational excellence guidance to your workload to ensure workload quality through standardized processes and team cohesion.
This pillar defining standards and having clear leadership, so that workload teams don’t resort to methods that don’t follow best practices, which can lead to poor user and support experiences. I’m sure we’ve all been there.
Having a good culture, deployment practice and credible documentation are a must. If you neglect any of these areas, you’re skating on thin ice.
Poor performance can frustrate users, reduce productivity, and increase costs. To avoid these problems, you need to design your solutions with performance in mind from the start.
Testing for performance can be difficult. You have to define clear and measurable test plans. Test scenarios have to incorporate all paths and test data needs to reflect data expected within our production system.
It can also be rather costly.
We have to have dedicated environments for testing, periodically refreshing test data and maintaining a mirrored environment among other aspects which can all be equally challenging.
The checklist provided by the framework is helpful. It starts you off and allows you to build upon it, checking your progress and alignment with the rest of the pillars.
A big takeaway is that we have to sustain performance of our systems as they grow and scale. This is not a one-off activity.
Strive to understand the needs, experiences, expected outcomes, and desires of the users of your workload, and tailor the design of the workload to the users' specific requirements.
Poor performance can frustrate users, reduce productivity, and increase costs. To avoid these problems, you need to design your solutions with performance in mind from the start.
Testing for performance can be difficult. You have to define clear and measurable test plans. Test scenarios have to incorporate all paths and the test data needs to reflect data within our production system.
It can also be rather costly.
We have to have dedicated environments for testing, and periodically refresh test data and maintain a mirrored environment with production, among other aspects which can all be equally challenging.
The checklist provided by the framework is helpful. It starts you off and allows you to build upon it, checking your progress and alignment with the rest of the pillars.
A big takeaway is that we have to sustain performance of our systems as they grow and scale. This is not a one-off activity.
Overall, it’s a brilliant piece of work to bring architectural standards and design principals to the Power Platform. It is continually being updated, with the latest changes to the framework being focussed around Copilot. Give it a read and if like me, you prefer to read a document, I have this ready-made for you:
GitHub Link: ppdocs/Governance/Power Platform – Well Architected Framework (WAF).docx at main · gblunden/ppdocs (github.com)
Welcome to my blog! I'm Gary, a Microsoft solutions expert specialising in Microsoft business applications, data and artificial intelligence - working with Microsoft tech for over 15 years. Here, I share tutorials, case studies, best practices and industry trends to help the community harness the power of these technologies. Join me in exploring the transformative potential of Microsoft products and services.