The last solution architecture we are going to look at is very similar to the Feature Solution Architecture but instead puts a twist on it – the Team Solution Architecture.
In the Team Solution model, solutions are deployed by the teams that create them. The teams can be of any size, but generally, their deliveries rarely mingle together so they are always separate. In the above example, we have a Systems, Integration, and Reporting team. Very simply your reporting team could be responsible for creating dashboards within CRM, integrating data with Power BI, or creating custom visualizations inside or outside of Power Apps. The Integration team is more heavily involved in creating integrations into and outside of PowerApps while our Systems team’s focus is on everything that is Dynamics.
You can see in the Team solution, that even the All-In-One solution finds its way here where the System solution could even be seen as purely Dynamics.
These are only examples and if you had teams that were called “Communications” or “Contact Center” you might break it up differently again as to what your teams are.
Generally, when I see the team solution model at play it is for very large organizations that keep their workload and user base separate from other teams. The groups share the same Dataverse Tenant but the linkages and relationships between the different solutions are near zero.
| Pros | Cons |
| Can be good for large teams that don’t work together. | Very little sharing of components could introduce unintended overlap. |
| Leverage the same tenant for many different uses. | There is always room for unintended dependencies. |
| Teams can deliver and build solutions independently of one another. | Can lead to lack of Communication amongst other teams. |
Looking at the Team Model, you could introduce concepts from the Feature model that implement a Core Solution that everyone must use, with the idea that you are keeping that very tight and focused around only the artifacts that everyone uses.
How are Components Grouped?
With the team model, all components that you need are grouped into your one solution. Your tables, your Apps, everything, it’s all yours. When building a Team Solution, you are very close to building a Team App and running that as a Managed Solution that others can consume and use.
Because no one outside your team should be touching your solution, you will always be deployed as managed but less likely to deploy as managed properties.
ALM and DevOps Delivery
To date when we have discussed ALM and DevOps delivery we have done so from the viewpoint of one team delivering solution(s) to their users/customers. When looking at the team model, you might have teams that have their own separate DevOps implementations where how they deploy their solutions differs slightly.
If I were implementing a team solution model today, I would definitely be looking to leverage the PowerApps Pipelines so that at the very least all the teams could see what we are working on and moving towards.
Like the Feature Solution Model, you might want to consider the use of a “Core” solution that everyone consumes as a base layer to ensure that core entities are being used the same way or all teams are using the same libraries and not introducing 17 different libraries into the system.
What Team Size Does This Work Best For?
I think we’ve covered this already, but when looking at the Team Size that generally implements this solution model – it’s an organization with a larger number of teams, sharing a single tenant, but with very disparate goals and user bases that prevent it from having what the Component or Feature models might be viewed as in terms of being evolutionary.
In the new PowerApps world where teams can basically build REACT apps and host them on PowerApps and leverage PowerApps as a back-end with a dynamically updating API out of the box, this can be a great solution to ensure data is all in one place, but teams are in control of what they are delivering.