I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will cover leading the design process.

A Dynamics 365 / Power Platform Solution architect needs to lead successful implementations, meaning the architect is a key member of the project team. They must demonstrate functional and technical knowledge of Power Platform and Dynamics 365 apps. And beyond that they must appreciate other related technologies that form part of the overall architecture.

This section of the exam is pretty large! I therefore plan to split this information into three posts. This post, therefore is just the first part.

When we look at this section of the skills measured for the MB 600 exam, I hope you can see that its coverage is quite wide. I also think it is true to say that there is a lot of implied knowledge in many of these subject areas. In my revision notes I will try to cover as much information as I can. But like so many sections of this exam your real-world experience is all important. So I suggest you do reflect on your current and past projects. Think deeply about how you have been involved in the design process and try to consider how this experience relates to the headings below.

In this post I will try to tackle topics under the following headings;

• Design solution topology
  
• Design customizations for Dynamics 365 apps or AppSource apps
  
• Validate and/or design user experience prototypes
  

Design solution topology

The phrase “topology” suggests defining the shape of either the physical or logical design of the solution. This might mean drawing out a business process or creating a diagram to show how the solution components will interact. Or maybe a diagram to show the logical or physical data structures. These diagrams could be considered as the blueprints for the solution. The blueprints provide a visualization of the organisational processes or system components that make up your application. It will often be true that the Solution Design Document (SDD) will contain several blueprints to map requirements to implementation components.

Visualizations used in the creation of a design may include process models, data models and even wireframes showing the user experience.

A single design framework or blueprint obviously does not exist. But there are several principles (pillars) we can expect to be addressed by a well architected solution, including;

Security

A customer’s data is valuable and must be protected from vulnerabilities. We might need to consider the Dynamics 365 security model here but also other features like Azure Conditional Access and Data Loss Prevention polices. A Solution Architect should think about security throughout the entire life cycle of the application. Security includes perimeter control and security model to protect data.

Empowering end users

A Power Platform solution should empower users to be able to extend the application. This may involve providing user-focused connectors or creating reusable Power App components. Additionally we might create app templates or starter apps. Additionally establishing a centre of excellence using the Microsoft provided starter kit may help encourage user empowerment.

Trust and privacy

Compliance requirements and regulations may differ from industry to industry, project to project or maybe even across geographic locations. (For example the rules for data privacy in Europe may differ from those found in the US.) The Solution Architect must recognise these requirements and incorporate them into their designs. Microsoft publishes a trust center that Solution Architects should be aware of.

Maintainability

Maintaining custom code is more expensive than features delivered with simply low-code configurations to out of the box features. Additionally Dynamics 365 and the Power Platform are updated frequently. Therefore the Solution Architect should design solutions which are as easy to maintain as possible and created in such a way that the regular updates do not break the solution. Additionally the Architect should be responsible for ensuring the correct level of documentation is created so that future maintenance is easier.

Availability and recoverability

When a system fails we need to know it can be recovered! The Architect will need to be aware of any expectations on recovery time required by the customer / stake holders. Integrations across system boundaries should receive special attention. We need to avoid the failure of one system component from causing the entire solution to fail. Additionally the Architect should consider and recommend solutions / tools to allow on-going monitoring to help give warnings of issues and allow early reactions to problems.

Performance and scalability

The Solution Architect needs to be aware of any expectations on resource capacity. The Architect needs to support the operations team identify the capacity / responsiveness that is required to support the components that much up the solution.

Efficiency and operations

A monitoring framework maybe needed to ensure visibility of how the application is using resources. We will want to drive up quality, speed and efficiency. Whilst at the same time driving down costs. When considering cloud solutions in will be of particular importance that the system is efficient. As inefficiency and waste in cloud solutions could result in excessive costs.

Shared responsibility

A cloud architecture introduces a concept of share responsibility. Your cloud provider (e.g. Microsoft) will manager certain aspects of the application leaving “you” with the remaining responsibility. The nature of this shared responsibility will have implications on costs, operational capabilities, security and even the technical capabilities of the application. The “bonus” is by shifting responsibility for some of these features to the cloud provide you enable the customer to focus on other activities more core to their business function.

Design choices

Based on these design pillars the Architect should rightly want to build applications that are as secure, available, efficient and performant as possible. BUT, trade-offs come into play! Building the ultimate system comes with “costs” in terms of cash, delivery time and operational agility. Depending on the customer’s requirements design decisions will be needed to deliver a quality application but also one that meets any goals set regarding these costs.

Design customizations for Dynamics 365 apps or AppSource apps

When we consider the target architecture as a Dynamics 365 and Power Platform Solution Architect we are often referring to the Dynamics 365 apps, Power Platform components and other parts of the Microsoft stack. (As shown in the diagram below.) Meaning that ideally a Solution Architect should be aware of and use the full capabilities across the Microsoft stack.

AppSource can be a useful source for solutions that will fill particular horizonal features within the overall solution. For example, you may be able to leverage 3^rd party solutions for things like document management, CTI etc etc.

The Power Platform components are designed to work well together. Therefore the Solution Architect should leverage the strengths of the platform in the solution design. But also consider the right time to use Microsoft Azure to fill any gaps where the platforms capabilities are exceeded. Pushing the Power Platform beyond its “natural” capabilities and using unsupported customization techniques should be avoided. The Power Platform is made up of the following components;

• Power BI – helps people harness data into actionable insights. Connects to hundreds of data sources. Provides dashboards and tiles used to create visualizations which can be embedded into Power Apps. (Additionally Power Apps can be embedded into Power BI dashboards.
• Power Apps – There are three types of PowerApps.
  • Canvas Apps – allows the creation of an app from a canvas without writing code.
  • Model-driven Apps – component-focused approach to app development. Can be used to create complex apps without code. Much of the layout of a model driven app is determined for you and often has a focus on the entities within the app.
  • Portals – allows the creation of a website that can surface Dataverse (CDS) data. Allowing both internal and external stakeholders to view and update Dataverse (CDS) data.
• Power Automate – allows everyone from end users to experts to create automation flows. (Both UI-based automation and API-based.)
• Data Connectors – data can be brought into an app via a data connector. Many connectors exist to access data in popular data sources. Including SharePoint, SQL Server, Microsoft 365, Salesforce, Twitter and many more. Some connectors only provide tables of data but others expose actions. When standard connectors don’t exist custom connectors can be created.
• AI Builder – an approach to bring AI to every organization. Provides pre-trained and trainable models.
• Common Data Service – lest you store and manage data. Includes the common data model which is a base set of standard entities that cover typical scenarios.
• Power Virtual Agents – an easy to use solution to create virtual agents (bots).
  

When considering reporting / visualizations of data it may be useful to leverage pre-built insights including;

• Dynamics 365 Sales Insights
• Dynamics 365 Customer Insights
• Dynamics 365 Market Insights
• Dynamics 365 Virtual Agents for Customer Service
• Dynamics 365 Customer Service Insights
• Dynamics 365 Fraud Protection

Validate and/or design user experience prototypes

As mentioned elsewhere the Solution Architect is responsible for identifying when a proof of concept (POC) solution may be required to help validate the design. Maybe a POC is required to confirm if a particular technical solution is workable. Or maybe to test if the users prefer a model-driven app or a canvas app etc.

Note: It should be understood that sometimes the architect may build these proof of concept / prototype solutions. But this is not a given. Sometimes the Architect will “simply” identify the need and other developers will create the required components.

Additionally it might be that screen mock-ups will be created to help the customer visualise the expected final solution.

Architects who have traditionally worked with model-driven apps may find they haven’t routinely needed to create mock-up designs for screens, as historically the layout of a model-driven app has been “fairly fixed”. But with the advent of custom components (PCF) and Canvas Apps we now have the capability to create “richer” user experiences. And therefore the need to validate the user experience will have increased.

Tip:
The above may also be true for Portals. When the look and feel that will be experienced by the customer will be paramount.

When an application is being developed iteratively in an agile manner, I have found it useful to complete frequent “show and tell” sessions. I have found it useful to show the customer the user interface and gain feedback as early as possible in each iteration.