Continuing from our previous post on Solution Architecture in PowerApps, we’re going to move forward into the Component Solution model. It should be noted that these names are not written down anywhere and are merely created by me.
I’ve used the Component Solution model many times over with great success as it works with small and large teams and scales gracefully as you grow your team and content.
Essentially, when building a Component Solution Architecture you are looking at all the components you are using in your Solution Development and placing them into logical buckets that make sense for you and your team(s). The idea is to reduce dependencies and relationships between the different solutions so they can be deployed independently. You will invariably have some dependencies (i.e., the table solution needs to be deployed first before solutions with workflows, but this should be the extent of those dependencies).
In the following diagram, I’ve grouped my solution architecture into 4 core solutions – Tables, Extensions, Security and Processing – you can do more or less – whichever fits your problem set.
Under tables, I have tried to group logical PowerApps components where someone working directly with the UX of PowerApps would focus. As you move towards Extensions and Processing, you can see it is broken out by areas of workload – Extensions being for components that interact with other systems and Processing being for event handling. Lastly, I bundled security separately because often the roles don’t change very much, but I’ve found over the years that sometimes I need to add an App role quickly without having to deploy any new components.
But you can build this out any way that works for your team.
What I thoroughly enjoy about this model is that I can let the versions between solutions drift to be what they need and don’t need to deploy every solution with every release.
I.e., If we have a release focused on adding new tables and security roles, I only make changes to those solutions and run up the line. If I’m fixing bugs in plugins, but no field changes have been made, I deploy changes in that solution and run up the line.
This allows me to deploy only what is necessary and minimize QA regression time.
| Pros | Cons |
| Solutions can be deployed independently. | Requires an “integration” environment where all solutions are validated against one another before pushing out the door. |
| Developers can work on different solutions without bumping into one another. | Things can be placed into the wrong solution and then need to be updated. |
| Teams know what goes where without having to think about it. | Need to manage dependencies in the deployment of solutions (i.e., tables must exist before security roles can be deployed) |
| Deployment times are minimized due to not having to deploy everything all the time. |
How are Components Grouped?
As I said, this is completely up to you and your team. I have a default set of components that I go to in my head that is constantly evolving, but otherwise, the goal should be a clear and clean break in what you deploy.
There will always be dependencies in any type of software (i.e., to run Node, I need the Node SDK installed), the same applies here.
ALM and DevOps Delivery
The Component solution model works great with your ALM strategy. You will want a pipeline for each solution and through your pipelines, you will need to manage the order of deployment in functions.
When using the Component model, we would typically have a nightly build that would run and take the latest of each solution, do a test deployment, and validate how it ran. If there were conflicts or errors, we would find out about them ahead of time.
Also, because not everything is in one solution, you can deploy each solution independently of one another. They might all start out at 1.0.0.0 but give it 6 months and you’ll see where your time and effort is being placed as the version numbers shift.
What Team Size Does This Work Best For?
I’ve used this model with small teams (2 – 3 developers) and then scaled up to 15+ developers and QA. Because this model allows for separate skills, you will definitely see a difference in how fast people are able to adapt and focus their work. With so many components and structures in PowerApps now, you will have a variety of skill sets on your team and this is a great way to identify leads/experts that can own the solutions they are working on.
An indirect result of this model is that teams aren’t “guessing” where stuff goes, they can intuitively look at the solution and go – “that goes here” – and off they go.
I’ve had great success over the years with the Component Solution Model, primarily because of its simplicity in getting new and existing developers on board to what goes where and then making it that much easier to move forward with. A great option for a new or existing project.