In this next post in my series on solution architecture we’ll start of the next chunk of posts in this series where we look at different considerations solution architects need to make when it comes to designing Power Platform solutions for implementations. In this post, we’ll focus specifically on some of the first considerations an architect has to make during the solution design process around ‘considering the product and toolset’.
What should a solution architect be aware of?
So first before discussing what considerations a solution architect should be making during the solution design process, let’s step back and think about the things a solution architect needs to have knowledge of to be able to carefully make the considerations we’ll talk about…
- Knowledge of Dynamics 365 First-Party Products / Solutions
- Extensive Knowledge of the Power Platform Products and Capabilities
- Knowledge of other Microsoft Cloud platforms and services i.e. Microsoft Azure Services
- High-Level but not necessarily a deep technical understanding of programming languages – i.e. understanding of where professional development languages can support the building of solutions
Let’s talk considerations
Okay people, so now lets start to talk about the first considerations a solution architect should be making once they have requirements captured. Well, I say once requirements are captured, but all of these things should be being thought about during the requirements capturing process too. There will be elements where an architect should manage expectations and persuade for requirements to move in a certain direction based on what is sensibly achievable. Anyhow, let’s dive into a few things…
Considering the use of Dynamics 365 First Party Solutions
So one of the first things a solution architect should be thinking about it the potential for a Dynamics 365 first-party application to be something that could serve as a successful solution for the problem attempting to be solved or improved.
Solution architects should have a good understanding of the realm of Dynamics 365 solutions and what the purpose that each of them serves. The use of a Dynamics 365 product may mean highly reduced development time allowing a customer to go-live and improve their business processes a lot faster! Depending on how much a customer would utilise the features in the relevant solution too it may mean a Dynamics product would result in lower costs to the customer than the same put into development time to try to rebuild an extra large sized bespoke solution.
It may even be that there is a Dynamics 365 product that has a level of additional custom functionality built in by Microsoft unachievable with Power Apps or the Power Platform, say Omnichannel for example, where the Dynamics solution would be the option to go down in this case i.e. the implementation of a digital contact centre.
So, solution architects, make sure you know your stuff around Dynamics 365!
Considering the appropriate tool to build the thing
Now one of the things a solution architect should be able to do is look at the broad toolset that the Power Platform provides to build low-code digital solutions, and they should be able to advise the most appropriate tool within the set that would provide the best outcome for the requirement whilst delivering the best possible experience for the user. Remember friends not everything has to be an app!
A solution architect should come in here, and decide where we might use Power BI, or Copilot Studio, where we might use Power Pages etc …
Consideration outside of the platform
Now let’s think a little more broadly… and the image above may have already had you starting to think in this way. It’s important that solution architects don’t just think within the walls of the low-code platform when attempting to resolve customers business problems with digital solutions we build using the low-code toolset the Power Platform provides… we need to sometimes think a whole lot more broadly that that!
Now sure, lots of say medium t-shirt sized solutions may fit within the scope of only needing to be built using low-code tools that the Power Platform provides, but not all of them.
But let’s look at both of the very ends of the t-shirt sizing spectrum… Let’s take extra small sized solutions first. Now here we’re looking at personal productivity sized solutions or solutions we may use in a team with perhaps up to 5 other colleagues. Pretty much ALL of these are built on SharePoint. Straight away there we’ve created an external dependency which someone else in the organisation most likely managed and we’re no longer acting within the walls of the Power Platform.
Now let’s take an extra large solution. Here we’re looking at solutions which need to have high availability and need to be scalable, and scalable without issue. These are the kind of solutions that may have complex requirements around all sorts of things. Let’s take accessibility for an example. It may be something as simple as us needing to build speech to text and vice versa type functionality into a canvas app we build using Power Apps. Well hey right there straight away we’ll need to rely on an Azure service which solution architects should be aware of and should have a high level understanding of the need for that type of design.
It could on the flip side be something much more complicated where we’re relying on multiple Azure AI services, or storage services and more for various parts of our digital solution. You can start to see why a solution architect needs to have a good high level understanding of something a lot broader than just the Power Platform here. Really solution architects, even if they specialise in the area of the Power Platform, need to have a high level understanding of the entire Microsoft Cloud and it’s different elements. Things like…
- Microsoft 365
- Azure
- Dynamics 365
- Power Platform
- Microsoft Graph
- Copilot and AI Products
- Accessibility Products
- So much more!
The broader knowledge a solution architect can have the better! Though that’s not to say that this can be high level in every area. It can be in some, or lots in fact, but a solution architect should most certainly have a deep understanding of Power Platform and various other parts of the Microsoft Cloud to be able to deliver highly successful solutions ranging from XS sized solutions up to XL.
What’s coming up?
So friends, in the next post we’ll look at another considerations solution architects should be thinking about when designing solutions being environments that are being built and worked within. Now I’m not just talking about Power Platform environments here but all sorts like tenant level specification, data location and more! We’ll deep dive more in the next post. Stay tuned friends! 🚀