We’re in this phase of enablement and scalability. I’ve had a variety of conversations with architects, developers, and business owners over the past couple weeks, and a common topic kept emerging. How do we scale the Power Platform whilst minimising technical debt?
My Perception of the Problem
Over my career, I’ve established a personal perspective on why Power Platform projects either fail, lag, or suffer technical debt. It’s my personal take on it, but I like to highlight these three areas:
Adoption
The Power Platform is not something you just turn on. It requires adoption, processes, and frameworks within a company. It requires change management, innovation, and enablement. Your end users can make or break change management, and thus creating a champion environment with an eager culture to adopt positive change is crucial. Alongside this adoption strategy is setting up a Power Platform governance framework. This includes configuring your admins, environment strategies, DLP policies, and various other processes that not only govern your ecosystem but also drive innovation from end users safely.
Data and Security
Data, clean and centralised data. This is a crucial factor when adopting, architecting, and building Power Platform solutions. Often, data is scattered and unstructured. There needs to be a clear definition at the start of a Power Platform journey that data drives success. With all the talk about AI and Copilot, companies need to be aware that if you feed AI bad data, you’re going to get bad feedback. The same applies to a solution. You need clean data for a process or solution to function effectively. It may unfortunately mean there needs to be a data cleanse and data migration involved at times. Second to that, there needs to be a sense of security. SharePoint is great if you want to build some basic processes, but once you start adding complex access rights to solutions, it becomes slightly more difficult to apply security to datasources like SharePoint.
Furthermore, as the solution progresses through its lifecycle, your data and security model need to be structured in a way that allows for scalability when required.
Quick Wins
A term that people who know me know I hate. I have nothing wrong with the occasional quick win, to the extent where I can even justify it. Architecting and building Power Platform solutions is not always just about the solution; it also involves commercials and business understanding. There is a very fine line balancing a commercial quick win against the technical debt one may incur. Agile projects are becoming a common thing as well. The idea around an agile approach is that you deliver repeatedly on requirements to ensure stakeholders can see tangible results. However, there is a misconception. Agile represents flexibility but is not the same as chaos. In an agile project, there is a visioned roadmap that aligns with the milestones and sprints to help deliver repeatedly. These milestones may be smaller bits of a bigger solution, or they may even be unrelated projects that form part of a bigger digital transformation. The chaos emerges when structure and processes fall away. Change management reflects a process that allows re-prioritisation within a sprint, but often this is skipped and items are just added, increasing capacity, but due in the same timelines. Chaos becomes visible when you become more responsive than being preemptive. Technical debt happens, but building up this debt to achieve small deliverables that cause more problems in the future becomes unsustainable.
In reference to my first opinion around adoption, the Power Platform is a great resource to allow user enablement within a structured and governed ecosystem. With the idea of enablement, technical debt is clear and expected. I am referring more to the larger projects where we solutionise. The projects where business analysts and solution architects work together to design something special. With enablement, the idea of Low Code is encouraging. With stakeholders, this idea of low code can be dangerous.
I came across this LinkedIn post by an Australian page called Solutions Architects (here). The meme made me laugh as I resonated with some of my agile and waterfall experiences.
My Four S Principle
My idea around the Four S Principle came to mind in the midst of a responsive situation around 173 dependency errors during a deployment. Since then, I strive to incorporate these principles into all my projects. I am not just referring to the technical side; I ensure to include it in the project management side as well. Let me break it down:
Secure
Security applies to both the Microsoft ecosystem as well as data. With a successful adoption strategy, appropriate security measures would have been put in place to ensure a viable environment strategy, governed access to control to environments, solutions, and functions, as well as other protection policies such as DLP policies. These fundamentals enable users to safely innovate with the Power Platform.
Furthermore, we can apply security to a data level. We live in a world with various data protection acts that keep us as developers safe, our companies safe, as well as end-users and customers safe. Applying data security to a solution is imperative. It ties back to my SharePoint example. SharePoint is a great place to store basic information that is used for small, ungoverned processes. It’s not ideal, but you get your “freemium” aspect of the Power Platform. But thinking long term, the complexity around SharePoint security you may need to apply to a solution may not be viable. What if you setup a variety of sites with weird names in an attempt to “hide” them from users? You think Copilot won’t find them?
Understanding the security layer of a solution needs to be a priority during a requirements and architecture stage. You need to ensure that you are not just designing a structured data model but a security RBAC model in parallel that fits directly on top.
Stable
The next pillar I focus on is the concept of stability. Alongside the governance piece, I always like to introduce some basic processes that should be used in any project. These may align with some of the frameworks implemented in the Secure piece, but that’s the idea for these principles to all align with each other. Stability is governed through a structured process. This includes having established standards to follow, processes to qualify solutions with quality control, and pipelines to deploy solutions efficiently whilst maintaining version control artefacts and source control. The idea is to ensure that you are constantly delivering top-quality solutions on a stable platform.
From a project perspective, stability also refers to documentation. A developer’s worst nightmare. I, for one, love documentation. To ensure a stable development lifecycle, documentation is imperative. At the start of any project, I always like to initiate a designated project folder with a variety of subfolders. With this structure, I am able to clearly store related information for any stage or process, effectively ensuring that if there ever were hiccups, everyone would know where to find the answers. It also acts as a centralised repository for all the project and solution information that is not code-based. Items like ERD’s, process maps, and workshop recordings all become accessible instantly.
Sustainable
It’s no secret that one needs a PhD to fully understand Microsoft’s licensing guides. I’m not just talking about Power Platform. You need to be aware of the cost factors throughout the ecosystem. Sustainability is a principle that allows me to propose the most cost-effective solution while maintaining architectural integrity. As Power Platform people, we sometimes get locked in this box, thinking a solution needs to purely be Power Platform. I wrote a blog post recently on using OpenAI’s API in a Power Automate flow. Although the topic was very basic, I enjoyed doing the cost analysis of this method against using an out-of-the box AI Builder prompt. If we’re staying in the box, AI Builder is the answer. If we expand further, you will see that using OpenAI can be up to 50% more cost-effective than AI Builder. Azure AI can be up to 30% more cost-effective. That incorporates sustainability. Ensuring that the solution being built does not create excessive overhead for the stakeholders to maintain. (I do need to add that when I say sustainable, I do not mean use Excel as a database. I mean making strategic decisions to keep a solution sustainable without mitigating best practice.)
Scalable
Lastly, the most common discussion I’ve had the past few weeks. How do you ensure solution scalability? I like to think that one of the many ideas behind the Power Platform is its capability to be flexible and extensive. But as you acquire more and more technical debt within a project, the vision of a scalable deliverable starts to slowly fade away. In reference to the fore-mentioned meme, the start of any project may appear to be stable; however, as you continue to be responsive and reactive during the project’s lifecycle, scalability becomes a problem. Our responsive instincts often result in impulsive “quick fix” decisions that may come back and haunt us in the long run. A simple hard-coded value to solve an immediate problem could potentially block scalability or result in unnecessary technical debt.
I like the concept of a form engine. Say you have a list of requirements based on 20 forms. You know as the architect/developer that the client is bound to make changes to some forms and possibly add new forms in the near future. The smart thing to do at the start (again, based on my opinion) would be to identify if there is either a critical need for each form to have its own table, i.e., a more fixed data model, or if it would be more viable to create a form engine with some configuration tables that gives the end user the ability to edit/create forms on their own in the future. The more complex and large your data model gets, the more security you need to apply, and the more user control you need to govern, the less manageable the solution is to scale.
My Two Cents on Agile
Don’t get me wrong, agile is great. Especially in lengthy and complicated projects. It’s redeeming to see deliverable progress at times. My biggest problem with agile is the approach to the requirements and architecture. I strongly believe that in any agile project, the first sprint should be double, if not triple, the standard sprint time to ensure that the majority of requirements are understood and a related and structured data model is designed. Your data model drives the entire solution. From your security to your user experience. As the legendary Mike Gowland says, “You get your data model right, you get your security roles right, the solution builds itself.” Obviously you won’t get it 100% right the first time around, but the approach you take to design your model, be it a configurable data model or a fixed data model, can either make or break its potential scalability.
Conclusion
This topic is a very personal approach to architecting and building solutions. It’s an approach I’ve established after seeing projects both succeed and fail. It’s an approach I’ve used in both waterfall and agile projects. I structured the four principles in a way that allows for me to focus on those areas individually, knowing that they are ultimately intertwined. These principles directly impact one another should one fail. They’re principles that allow me to deliver quality solutions.
What are the principles you follow when it comes to architecting and building Power Platform solutions that ensure you always deliver beyond expectations?
I hope you enjoyed this post and found it insightful. If you did, feel free to buy me a coffee to help support me and my blog. Buy me a coffee.
