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 connected with “Initiate solution planning”.

Evaluate business requirements

A key first step in evaluating business requirements will be “getting to know your customer”. You should begin by completing research about the customer, this might be via the internet or by interviewing key business stake holders.

The evaluation of business requirements will be ongoing but we often see high activity during the “Initiate & design” phase of the project. Initiation will typically cover all of the tasks involving in starting the project. But you should be aware that when working within an “Agile” project this could mean the initiation of a sprint or iteration.

The solution architect may not be actually responsible for capturing every requirement, they will however often play a leading role in customer workshops to identify key workstreams. It maybe that the Architect actually challenges the customer during these workshops to help drive towards a deeper understanding of the “real need”. The Architect will be responsible for helping to select the correct business processes for the solution. The Architect will then collaborate with the consulting teams (often this will be the business analysts) as they gather the detailed requirements for each of the selected business processes.

The Solution Architect would review the detailed requirements gathered. Their role will be to ensure the requirements are as clear and concise as possible. Additionally, the Architect may need to identify any additional non-functional requirements. (Examples of this might be that the system must be scalable to support “n” users or must give responses in “n” seconds etc.)

Identify solution components

Even during the initial discovery phase or the earliest pre-sales meetings, solution ideas will start to evolve. The Power Platform Solution Architect will need to identify the components required to deliver the solution.

As the project progresses into design the solution architect will take the lead in defining the solution and its required components. In some projects all of this work may be done upfront but it will also be common to complete analysis / design within each sprint or iteration.

The Solution Architect will lead in designing the solution. They will be responsible for communicating this design to the wider project team and also maybe the customer. This will be achieved (in part) via high level design documents, detailed solution designs and even requests for change.

High Level Architecture Design – This will include identifying which components will be delivered using Dynamics 365 Apps, AppSource solutions or when external services might be leveraged. Often this will include creating a high-level architecture diagram to show the “big picture” of interactions with internal and external systems. The architecture diagram and a high-level definition of the solution components is often included in a document called the Solution Design Document (SDD). Whilst the SDD would be drafted during the design phase it should be understood that it is a living document that will be revised thru out the project life cycle.

Detailed Solution Design – When it comes to detailed design the Solution Architect will take a leading role but they do not typically complete all of the detailed design work. The detailed design would include designing the security model, data model plus the overall integration strategy. The detailed design will specify customizations to Dynamics 365 apps and any existing apps. The architect will often leverage a fit/gap analysis to help identify gaps between out of the box Dynamics 365 functionality and the requirements. As the detail designs are created by the project team, the Solution Architect would act as a reviewer to ensure the designs fit with in the desired architecture.

Change management – the Solution Architect is not normally fully “responsible” for change management. But the Solution Architect would be involved in any triaging and evaluation on the impact of intended changes. This will include a technical review of the change and also an assessment on the effort involved Change management is obviously essential in ensuring an on time and on budget outcome. The Solution Architect would help avoid scope creep while at the same time allowing essential changes to be successfully progressed.

When considering the solution components the Solution Architect may have multiple aspects to review and include into design documents. Including;

• Process architecture
• Application architecture
• Data Architecture
• Integration architecture
• Intelligence architecture
• Security architecture
• Continuous update architecture
• Platform architecture

Solution components should always be mapped back to requirements. This helps ensure all requirements are being delivered and also helps demonstrate which components will deliver what benefits. Not all solution components will be new as sometimes you will be amending or re-using existing components. Plus some components will be based on out of the box features, when doing this it might be beneficial to flag which components are custom and which are off the shelf.

When considering replacing an existing app be mindful of the reasons. If tangible business benefits are clear then any replacement is acceptable. But replacing (for example) a non-Microsoft ERP solution with Dynamics 365 Finance just because it makes your solution easier to develop is unlikely to be well received.

Identify and estimate migration effort

Estimating the total effort involved in migrating data from the legacy system into the “new world” is something I have often found under estimated.

The effort involved in cleansing data, transforming it and importing into the new system can be significant. Additionally you’ll need to consider how the quality of the migrated data can be confirmed.

But migration may (and will) cover much more than just data. You may need to migrate user accounts, email accounts, documents and much more. Migration effort can therefore refer to the full deployment.

We have multiple deployment options. With Dynamics 365 we have cloud based deployment options for many modules, when considering these we don’t typically need to invest in additions to the IT network, hardware or software. As no local deployment is required. However, Dynamics 365 Finance and Dynamics 365 Supply Chain Management can be deployed on-premise. And therefore could result in upgrades to the existing IT infrastructure.

The deployment of Dynamics 365 Finance, Dynamics 365 Supply Chain Management and Dynamics 365 Commerce should use Lifecycle Services (LCS) for deployment. LCS is a Microsoft Azure-based collaboration portal that provides an environment and a set of regularly updated services. With checklists and tools, LCS helps you manage the project, including providing prebuilt methodologies to help with implementation.

For other Dynamics 365 apps the primary deployment method will be online. And you will therefore need to use a standard set of environments for development, test and production. The costs for creating these environments and the effort to maintain them will need to be considered. But don’t forget that you can create trial environments which may help get systems up and running quickly. Trials only run for a short period but maybe useful for the creation of proof of concept solutions or demos without any license costs.

Dynamics 365 environments come in different types, including;

• Trial – an environment for short-term needs.(Often 30 days.)
• Sandbox – non-production environments. Typically used for testing or development purposes.
• Production – used for the permanent work of an organization.
• Default – a non-custom production environment. Each tenant will have a default environment that is created automatically.
• Developer – created by users with community plan licenses. They are only for use by the owner, sharing is not possible.

Feedback

The Solution Architect is a key member of the project team, as they collect requirements, create the designs (etc) they may spot issues. Any feedback on the requirements or design can then help shape the final solution.

It is important to speak up early, if a potential risk or issue is identified communicating the bad news early is always better than waiting. For example, news like “that feature is being deprecated” should be shared as soon as possible, therefore giving the maximum amount of time to review and implement alternatives.

The Architect may need to feedback to the customer that a particular requirement has issues. Or maybe to the Project Manager that timelines might be impacted by a change. Or maybe they need to feedback to the project team around a potential quality issue.

Feedback should be a continuous process that happens at all stages in the project. So feedback could happen right from presales. The Architect should however ensure that all feedback is constructive and actionable.

The point of the feedback should be to help improve the project outcomes, feedback is not about moaning that something isn’t going your way! Simply saying something like “that won’t work” is likely to get a negative reaction. The Architect should avoid simply saying “no” and instead offer alternatives or suggest mitigation steps. If there isn’t a clear resolution then maybe the Architect can encourage creating a POC or conducting additional tests to identify a workable solution.

Working as a team is important. The Solution Architect should be aware that they are a key team member who should be seen as a role model and mentor to other team members. Most Architect’s won’t get to pick the members of their teams, meaning it will become important for them to be able to assess the skills of team members. And also identify weaknesses, which they can in turn assist with. Assessing skills might involve asking probing questions or giving small measurable assignments to someone.