Prepare for the Solution blueprint review

  • 10 minutes

Typically, the Solution blueprint review takes approximately two to eight hours to conduct. The time might vary based on the level of detail that is available for review and the breadth of the overall solution. The solution architect will work with the implementation team leadership to plan the workshop based on the specifics of the solution that is being reviewed.

Prior to the Solution Blueprint Review workshop, workshop participants should make sure that they are as familiar as possible with the structure of the workshop and the types of topics and prerequisites that will be covered. The solution architect will provide an agenda with topics and prerequisites ahead of the workshop.

Note

The Solution blueprint review is essentially a discussion; it is not intended to be a questionnaire that can be completed and reviewed in an offline mode. While the prerequisites are defined and provided in advance, it is not possible to encapsulate the breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing project artifacts ahead of time. Helpful project artifacts include:

  • Process catalogs – Lists or hierarchies of processes, sub-processes, and user stories that are in scope for the implementation.
  • Process flow diagrams – Diagrams that can add context to the process catalog and describe the operation of the business. At the Solution blueprint review stage, the high-level, end-to-end processes are most helpful.
  • Application diagrams – Block diagrams showing the various components that make up the solution. These diagrams can also provide context that is related to how capabilities map to application components or how application components will interface with each other.
  • Gap requirements – Known areas of functionality that are not viewed as supported by the standard system.
  • Data flow diagrams – In a solution that includes multiple Dynamics 365 apps, legacy, or external services and components, it is helpful to be able to identify where data originates and how it moves and is consumed in the solution.
  • Data migration strategy – Documents or registers that show the entities to be migrated, the sources they will come from, the volumes, the timing, and the methods for migration. At the solution blueprint stage, it is key to ensure that you have scope (tables and sources).
  • Interface register – Lists of interfaces with non-functional requirements and design patterns that document the scope and approach for implementing those interfaces.
  • Analytical data aggregation design – Diagrams or registers of data sources that will be migrated for aggregated analytics.
  • Environment strategy – Block or flow diagrams that outline the types of environments that will be provisioned and how and when they will be used and how code and configuration will flow through them.
  • System usage profiles – Operational process schedules and peak transactional volumes by workload type.
  • Legal entity structure – Diagrams or registers that show the legal entities that will be modeled in the solution and their relationships to each other.
  • Deployment locations – Diagrams or registers that show the physical locations where the solution will be deployed along with language and localization requirements.
  • Project charter – Document providing the background of the project, objectives, and expected key results, stakeholders, budgets, timelines, and milestones.
  • Project plan/schedule – Document or Gantt charts that depict the overall schedule and dependency of key project phases and their associated activities.
  • Responsibility assignment matrix – Table of tasks and project roles’ relationship to those tasks. These relationships are typically assigned through an RACI classification (responsible, accountable, consulted, informed)
  • Test plan/strategy – Document describing the types of testing that will be done throughout the implementation and how tests will be defined, implemented, and measured.

This list is not exhaustive of project deliverables, but it is a good starting point for the Solution blueprint review. The formats, composition, and names of each deliverable might vary from one project to the next. Format isn’t the most important component; it is the information that is available and agreed on across the team that is essential.

When you are conducting a Solution blueprint review early in the project, many of these documents will not be fully formed, which is acceptable in most cases. It’s more important that scope has been determined and that a conceptual plan is in place to determine how the solution will support that scope. If the plan is unsuccessful, these items should be represented at some level in the statement of work that is provided by the consulting partner who is assisting with the implementation. If the scope and conceptual solution approach are in place, the Solution blueprint review can focus on the conceptual approach, and the follow-up, in-depth workshops can focus on the details at the point when they are available.

It is acceptable if your project is using different ways to manage or track project information other than what was previously listed. Typically, format is not critical, if the information is readily available to project members. If the previously listed information is not documented on your project, or if it is documented in a way that it is not easily accessible, you should prioritize getting the relevant artifacts produced.

We recommend that you use diagrams and visual representations to provide high-level summaries, where possible, in the implementation. These diagrams, charts, and graphs provide a ready means of communication across the team and with executives about plans and designs.

Note

The Solution blueprint review is not intended to be an exhaustive review of detailed requirements or design documents. The implementation team will work with lower levels of detail to derive and present the overall architecture. The assumption is that the implementation team will display key concerns, and architects will inquire into potential problem areas. The solution architect will suggest in-depth workshops to investigate areas that require additional assessment.