After many years of building apps on the Dynamics/PowerApps platform, I still get asked about how to architect PowerApps solutions.
How do I group components?
What’s the best solution for pipelines?
What solution model works best for big or small teams?
How do we future-proof ourselves so we never have to change our solution ever again?
There is No Future Proofing your Solution from Technology Change
No matter the technology, what you build today, is already one step closer to being obsolete. It’s the modern fact of technology, everything we do is depreciating at an increasing rate. I remember when .NET introduced the WCF and WPF frameworks – both frameworks were incredibly powerful but had so much to learn, to become an expert in both was a daunting task (and most of us couldn’t do it).
Just like any other service code you are working on, the project structure you come up with today, might want to change in a year.
THIS IS A GOOD THING.
Therefore, in answer to this question that gets asked many times, in regards to PowerApps – you cannot future-proof your solution – the platform is designed to grow, change, and evolve.
This is going to be an going series over the next few months where I’m going to talk about the three solution frameworks that I’ve used over the past 10+ years in Dynamics/PowerApps development irrespective of the requirements I keep coming back to.
I won’t be touching on Managed vs UnManaged solution deployment – my thoughts on this topic are well-versed here and should be applied to anything going outside of Development accordingly. Therefore, for every solution delivery model I tackle, I will be keeping things focused on these 3 questions;
- Some Pros and Cons
- How are components grouped?
- How does this model assist/hinder ALM (Application Lifecycle Management) and DevOps delivery?
- What is the impact of working with small or large teams?
Let’s Get Started.
The All-In-One Solution Model
This was the first solution model ever created for Dynamics and still exists as the “Default Solution”. However, even though the Default Solution exists, you should still create your own.
The All-In-One Solution Model is basically the Kitchen Sink – anything and everything you need, you will throw into one solution. When you go to deploy, you will deploy that one solution, each and ever time. There is no room for confusion as to what is being deployed because every time it is the Kitchen Sink.
In terms of “architecture”, there isn’t a great deal to say here – If you want components added to your solution, you add them into the solution.
| Pros | Cons |
| It’s all in one solution, you never have to worry about forgetting anything. | Because everything is in one solution, the size of your solution can grow quickly. |
| When it comes to deployments, updating the solution number is all you need to do, export and import. | The bigger the solution, the longer the deployment. You might find you are having to put guidance around what people should be adding to the solution. |
| Complexity in deployments is reduced because you will know immediately if you left anything out. | Small changes cannot be patched, the entire solution needs to be pushed out, depending on your testing practices, this can increase QA regression time. |
| Great for small teams that are starting to work together and/or if you are doing Proof of Concepts. | As your team grows you might find they are stepping on each other’s toes to get work done and potentially overwriting each other’s work. Think of it as though they are all working on one text file from all their own laptops. |
How are Components Grouped?
In this model, components aren’t grouped at all, they are all thrown into one solution – forms, views, cloud flows, plugins, processes, javascript, tables, fields, etc – everything. On the surface, it would seem like there are very little architectural decisions to make but when it comes to your code – plugins, javascript (other web resources like typescript), flows, and process – there is still plenty of room to determine how you will organize and structure that content.
ALM and DevOps Delivery
When you are deploying one solution, it can take longer to deploy as the solution grows. For this reason, you want to be very decisive when it comes to what to and what to not include. I.e., do you need all those views and fields from built-in components? Probably not, don’t bring them in.
The beauty of the All-In-One solution is your pipeline model is drastically simplified as PowerApps handles all the dependencies within your solution itself and all you need to worry about is getting your solution from Point A to B. You might have had to do some complex pipelines in the past, but now with built-in PowerApps Pipelines you can offload this to the platform relatively easily.
What Team Size Does This Work Best For?
Definitely a small team of around 5 people or less. With 5 people, you still have lots lof communication going on with your team – everyone is chatting about what they are doing and the impact is minimal on one another. When you start to go above 5 people, presumably your workload is increasing and you will invariably start to see collisions in the work being done, people overwriting one another and general frustrations at waiting will start to emerge.
No matter what you are developing, the All-In-One solution model is great for getting your project started and is where many projects start. I like to use the Visual Studio analogy because it first perfectly here and brings it back to many developers entering PowerApps development. Your first product solution won’t be a massive undertaking with tons of projects, it will have one, it will accomplish the goal you are working on and then as you grow, as the needs of your users grow, you will add more projects and keep growing the solution.
Or, if your team size stays the same, and your requirements are pretty steady, this model might continue to work well for you going into the future. Like any of the other models we will be discussing, this is all about picking the right solution for the right problem.