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 being the third post of three.

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

• Design data migration strategy
• Partition features into apps
• Design visualization strategy
• Design for upgradeability
• Create functional design documents

Design data migration strategy

The Solution Architect should lead the data model design and alongside that should consider what data should be migrated into the new system.

Data may need to be migrated into Dynamics 365. This maybe a one off task, as data from older systems being replace may need to be imported at the start of the project. Or the migration could be an ongoing task, maybe because you need to synchronise key data attributes between systems.

Tip:
When considering a potential “ongoing” data migration / integration it may be useful to consider if a virtual entity could be used rather than duplicating the data!

Data quality – if you plan to import data from a legacy system you may need to consider data quality. And if any existing data issues need to be handled. For example are the addresses held in the old system adequate. Or are there missing mandatory fields. Or are phone numbers incorrectly formatted.

Duplicates – duplication of data can be a significant issue with “CRM” systems. Do you have large numbers of duplicate leads or contact records? And if so, should these duplicates to resolved prior to migration.

Data retention – Do you really need to import all of the data from the legacy application? Especially as storage is not free! But there might be requirements to keep certain entities for a given period.

Data Transformation – The data in the legacy system may be held in a different format to that required in the new solution. Therefore the process of migration may not be a simple import. Transformation logic maybe need as part of the import.

Tools – what tools will be used to migrate the data. The Power Platform does include out of the box features to import data. But with large complex migrations you may need to consider using 3^rd party tools such as KingswaySoft of Scribe.

Partition features into apps

A Dynamics 365 or Power Platform solution is typically made up of one or more apps. Each app will deliver a logical group of functionality. (Be that via a Canvas App or a Model Driven App.)

The Architect should look for logical functional groupings to help partition the features into apps. This might be based on job functions or areas of the business such as “Customer Service”, “Sales”, “Marketing” etc.

Out of the Box Dynamics 365 ships as a number of model-drive apps. When appropriate you can leverage those apps as shipped. For example, I have often implemented the Marketing app with little change. In other circumstances the out of the box app groupings may not fit your organization. Then consider creating a custom app which may include attributes of several out of the box apps. You can read about the model-driven app design here.

One advantage of using an out of the box app is users would see all new updates as they become available. But equally the out of the box apps may include features you don’t need! Composing a custom (new) app does give you complete control over the options the users see but you will have to manually add new “things” as they become available.

The Solution Architect may need to know when to start with a model-driven app, when to implement a canvas app or when a portal may be more appropriate. So understanding the differences could be important! To help I have highlight some features of each below;

The decision of which approach to use in your solution may result in a hybrid approach. This isn’t a one size fits all scenario! For example, you may use a model-driven app for your admin functions, a canvas app for the user facing elements and a portal for external access. Therefore one solution may comprise of any combination of app types.

Additionally don’t forget that you can embed Canvas apps into model-driven apps. This might allow the introduction of visuals and connectors into a Model-driven app based solution which might otherwise not be able to leverage these capabilities. But I advise you to remember that “pretty” apps are nice but performant apps receive better user adoption. So carefully considering the best approach for your solution is advised.

When deciding how many apps should be included in your solution or what type of app to use, there are a number of guidelines you may wish to consider. Including;

• Large monolithic apps should be avoided
• Too many small apps are jarring to the user if they have to switch context frequently
• Components can be used by multiple apps, allow composition of apps that target users with specific needs.
• Offer groups of users targeted mobile apps to save time when away from their desk

Design visualization strategy

Creation of visualizations covering user screens, reports and other insights will be an essential task of the solution architect. This process should be on going. Right from pre-sales into project initiation and beyond into the analysis, design and implementation phases.

Often customers will focus on the user experience. Understanding if their users are always, sometimes or never mobile may influence the UI design. (As will other factors!)

Wireframes maybe needed to show main forms, dashboards, mobile experiences and other visualizations such as Power BI.

We may need to look for opportunities to use proactive insights or AI in place of a more reactive use of traditional reports and analytics. (Although our designs will also often include traditional reporting mechanisms!)

There are many points to consider when designing visualizations, including;

• Who will consume the reports? (Are they already Power Platform users?)
• What data is required?
• How fresh does the data have to be?
• What data is required that might be external to our Power Platform / CDS solution?
• Can existing reporting capabilities or “insights apps” be leveraged or is something custom required?
• What actions to we expect users to need to take in response to information in reports?
  • Is the action something we can predict or automate?

Reporting could be grouped into three categories. Operations reports, self-service BI and Enterprise BI. Each of these could include the following …

• Operational reports
  • views,
  • charts
  • dashboards,
  • SSRS reports
  • embedding of Power BI
  • Advanced find,
  • Excel / Word Templates
  • And maybe 3^rd party reporting tools.
• Self-service BI
  • manual exports of data into Excel,
  • Access to Power BI service (with data refreshed from CDS, maybe on a schedule).
• Enterprise BI
  
  • the data export service into Azure SQL,
  • Web APIs for data extraction, transformation and loading . (ETL),
  • Azure Data Lake Storage,
  • AI Builder.

Operational reports are typically easy to use, contain current data and can be accessed by most users with standard technical skills. However they will also commonly represent simple visualisations with only basic filtering and a limited access to historic data.

Self-service reports would typically be created by “power users” with more advanced reporting requirements. Often Power BI maybe leverages to allow them to discover, analyze and visualize data. When considering self-service reporting requirements the Solution Architect may need to ensure the required base transactional and reference data is available. Plus any data security concerns are addressed. (For example, within Power BI CDS user security roles and hierarchy are not used.)

Enterprise BI maybe used to reduce the load on operational data, by shifting any “heavy lifting” into Azure Data Lake. Typically enterprise BI may need access to potentially large volumes of historical data.

The AI Builder can provide pre-built models and intelligence you train. It can provide components which can be included directly in Canvas Apps and Power Automate. Or data can be created for use in Model-driven apps. The low-code AI capabilities include;

• Prediction
  
  • Binary classification – predict and classify field in Dataverse.
• Vision
  
  • Forms processing – extract structed data from digital paper, PDFs and forms.
  • Object detection – detect objects through camera or image control. (may need training!)
• Language
  
  • Text classification – classify, group and categorize any text in CDS

Additionally Microsoft Azure Cognitive services provide a family of AI services and cognitive APIs to help developers build custom intelligence into apps. You can read an overview about Azure Cognitive Services here.

Plus Solution Architects should be aware that Microsoft Azure Machine Learning can allow developers to implement enterprise grade AI scenarios not met by the AI Builder or Cognitive Services. You can read about Azure Machine Learning here.

Design for upgradeability

Maintaining custom code is more expensive that features delivered with 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.

Pushing the Power Platform beyond its “natural” capabilities and using unsupported customization techniques should be avoided. Using any unsupported approaches always increases your “technical debt” and will no doubt result in a system that is harder to upgrade.

Consistency across customizations is important. As this will aid the future maintainability of a solution. Additionally any custom software extensions should also follow common design principles.

Plus, consistency across the user experience should be maintained. Creating a consistent interface that sticks to the same layout and naming conventions will ultimately create an improved user experience and an application users are happier to use.

Also, consider that some attributes within the Power Platform are hard to change later. One example being the publisher prefix which gets applied to all schema names. We have all seen the odd “new_” name creep into out applications, this should be avoided! Consider carefully how to name tables and columns, as changing schema names later is “difficult”.

Create functional design documents

A functional design will describe how the requirements to be addressed by the solution will be delivered. It is often a formal document used to describe the intended capabilities, appearance and user interactions in detail.

Functional designs can take many forms. In fact most organisations I’ve worked with have had their own templates defining what should be included.

The functional design maybe a single document but equally the design could be expressed as numerous user stories.

A single functional requirements document (FRD) often has the advantage that it makes tracking the requirements really easy. If all the requirements are covered by one design document it should be easy to “tick off” that they have all been included.

Multiple user stories however tend to aid planning, as each story can be typically be delivered in one iteration or sprint. User stories however can lack the overall detail needed to help illustrate the bigger picture of what is being delivered.

Whatever template / approach you follow  the purpose of the functional specification is to capture what the software needs to do to support a business user. The functional specification could be considered the point at which the business meets IT! As often we’ll see the business users review the functional design to confirm their requirements have been met and also the developers will use the functional design documents as a key input into their technical design.

As with other aspects of the project life cycle, I would expect the Solution Architect to be closely involved with the creation of and review of the functional design. But that does not suggest that they will create the entire design. (Business analysts and other parties may also contribute to the functional design.)

Functional documents will differ from technical specification / detailed design documents are they are based on the business requirements. They should contain details of end-user expectations and will therefore become a basis for the technical designs which will follow. I personally like to think of it like this …. The business requirements define what end result is needed, the functional design defines what will be delivered, the technical designs will define how it will be achieved.

There are potentially (but not always) multiple documents that could be considered as being part of the functional design. You may hear the acronyms BRD, SRS or FRD used …

• Business requirements document (BRD) – this described the needs we are trying to fulfil by developing this solution.
• System requirements specification (SRS) – describes the functional requirements (and non-functional requirements) plus any use cases (stories) that the solution must fulfil.
• Functional requirements document (FRD) – The FRD would be a detailed definition of everything expressed in the BRD and SRS.