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 everything that might fall under the heading “validate the solution design”.
Note: Microsoft have recently updated some of their terminology. Therefore we should consider the terms like CDS and Dataverse as interchangeable. For the exam I would expect them to begin using the term DataVerse at some point but that change is unlikely to be immediate. Meaning in the short term either term could be used. I created this blog post before the revised terms were announced. I have tried to apply updates but a few “outdated” references may still exist!
The Solution Architect will work with the Quality Assurance (QA) team to ensure testing includes all parts of the architecture. This could include functional testing but may also include other types of testing such as disaster recovery and performance testing.
Proper testing is essential to ensure project success. The Architect is often one of the key people who knows the solution the best and therefore can guide the test team on how to validate it. Testing shouldn’t be considered something that just happens towards the end of a project, testing must be an ongoing effort from the first component built until go live. It is now a one-time big exercise it is an iterative, repetitive task that happens thru out the project life cycle.
Evaluate detail designs and implementation
By the implementation (build) phase the Solution Architect has set the path the implementation team will follow. By this point the Architect will have created a high level solution design document (SDD) and will have reviewed any associated detailed designs. Meaning that during implementation the role of the Architect will shift to be a supporting one for the Project Manager and Delivery Architect. As they will be responsible in ensuring the developers create the solution as defined. This includes facilitating reviews with the team to ensure implementation is meeting the architecture as well as reviews with the customer to ensure the solution is meeting their stated requirements.
During the build problems will happen! Therefore the Solution Architect is also involved in problem solving as they are often one of the few people who understand all the “moving parts” involved in the solution. Some of those “problems” maybe found by the testing team and the multiple types of testing they may complete.
There are many types of testing, I will highlight some of the common types below;
| Test Type | Details |
| Units Tests | Typically the unit tests will be created and run by the application builder or developer. Unit tests confirm the correct operation of each component in isolation.
It will be a common practice for everyone to check their own work before handing off. Manual testing maybe completed for all apps, business rules and plug-ins. (etc.) Some tests can be automated using Power Apps Test Studio and Visual Studio. |
| Functional Tests | Functional testing verifies that the implementation meets the requirements. |
| Acceptance Tests | Acceptance testing is completed by the end users. Although I have often seen test teams support the business in this task. The purpose / outcome of an acceptance test is the formal approval that the solution is fit for purpose. |
| Regression Tests | Tests completed on non-changed functions. Regression tests typically aim to prove that nothing has been “broken by accident”. |
| Integration Tests | Verification that everything works together. Including various internal systems and any integrated 3rd party services.
The Solution Architect maybe called upon to help the test team understand how to test integrated components. External systems will need to be available for testing. Sometimes they may require careful preparation to ensure real data is not impacted. For example, email integration testing must ensure messages aren’t inadvertently sent to real customers! |
| Performance Tests | Confirmation that the system can cope with expected peak loads. (And maybe “slightly” beyond the stated peak loads. Can the system cope with future growth??)
You may need to define performance “hotspots” to test. These maybe areas of the system known to be complex or those where the business has expressed specific performance expectations. Additionally requirements gathering might need to establish what peak volumes look like. Occasionally you may even have contractual obligations to test, it maybe that the contract specifies the system must support “n” users or cope with “y” transactions etc etc. You may need to include the infrastructure as part of performance testing. For example, network traffic at remote offices may need to be measured including network latency and bandwidth. |
| Migration Tests | Practice data migrations to ensure data quality. |
| Disaster Recovery Tests | Having a disaster recovery plan is great but it is useless unless you can test it works. |
| Go Live Tests | It is common to complete multiple “dry runs” of the go live process. This might involve data migrations tests! |
Note:
Performance testing may make use of Azure App Insights
Azure Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management (APM) service for developers and DevOps professionals. Use it to monitor your live applications. It will automatically detect performance anomalies, and includes powerful analytics tools to help you diagnose issues and to understand what users actually do with your app. It’s designed to help you continuously improve performance and usability. You can find out more about Azure App Insights here.
Validate security
Having collected your security requirements, designed a solution and built it …. You will need to test that security is being achieved in the required manner.
In terms of the Power Platform application this can require a significant testing effort. As test scripts will be required that must be repeatedly run against each user persona. (or set of security roles if you like.) This effort should not be under estimated.
We should also consider security beyond the Power Platform. For example, we might be using SharePoint for document management integrated in with our solution. Meaning access to SharePoint may need to be tested independently of our Power Platform solution.
Microsoft Dynamics 365 