We’ve looked at the All-In-One and Component Solution Architectures and now we’re going to talk about the Feature Solution model.
As shown below, the feature solution model is based upon areas (features) that you deem to make sense to your organization. Although Marketing and Service are highlighted below as PowerApps terms, these features could include tables and structures from other entities not generally known as service code but that make sense to you and your teams.
What is the Core?
You’ll notice before we get into each feature area the “Core” box. I’ve found over the years that when implementing this feature solution model, you need to have a core solution that everything builds upon, otherwise your inheritance model goes wonky as it becomes more of a daisy chain effect.
When implementing the core solution, you are thinking about components that all the other solutions leverage AND might want to extend.
The implementation of a core solution is where you want to take advantage of all those fancy Managed Properties available on your solutions and think of it as a product you are delivering to each group (in a managed form) so they are not modifying it and changing it as they see fit.
The Core is a delivery to every group and must be treated as such.
In the case where I’ve had to use third-party solutions. If these solutions have been unmanaged code, we have looked to roll them into our Core solution so they are seen as base layer implementation to what can be consumed by other features.
| Pros | Cons |
| Teams that are already broken out by feature area can continue to operate as such. | You can still encounter dependencies between other feature solutions based on your relationships resulting in unplanned dependencies. |
| Teams are responsible for the totality of their area and not only certain components. | More effort is required in table structure design to ensure components are going in the right place. |
| Features can be delivered and built independently of one another. | 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?
Unlike the Component Solution Model, whatever you need to add to your feature, you add to that feature. Whereas some features might be relatively simple – tables and rules – others might have more detailed integration points and third-party extensions.
The Feature solution model is almost akin to the building of mini-products within PowerApps that you can either expose to other apps or ship on your own.
In implementing this model, we have sometimes found that a team that has delivered a cool and interesting widget in their feature solution, we pull down to the core delivery to make available to everyone should they wish to consume it (much like the generalizing of a feature in code, once you realize its value).
ALM and DevOps Delivery
The ALM and DevOps delivery model (structuring of dependencies and integrated test environments) is very similar to the Feature Solution Model as it is to the Component Solution Model.
The only difference when implementing the feature model that I like to consider is the use of the Core Solution with multiple developer tenants. If you are using multiple developer tenants, I strongly suggest the notification/pushing out of changes in your core solution to developer tenants so they are always working with the latest and greatest solutions.
This might require some additional work on your DevOps pipelines to let people know when changes have been made, publish them as artifacts, etc, etc. But once implemented, the system should run smoothly and minimize integration test time.
What Team Size Does This Work Best For?
As far as team size goes for the Feature solution Model, the best team size I can think of is for this to be geared towards large teams, even highly distributed times that work in different zones or locations.
The reason for this is that depending on the features you are building (and perhaps even the security context of what you are deploying – i.e., separate business units) – the feature model, apart from Core, allows teams to work relatively independently.
If you are a large organization with 5 – 10 teams working in PowerApps, you might find this solution works well as teams generally work out of their own sandboxes and areas. When done right, the only integration point should be your Core solution.