Prepare for the workshop
Typically, the Solution performance workshop takes approximately 2-4 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 performance workshop, participants should be 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
Essentially, the Solution performance workshop is a discussion; it’s 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’s 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:
- Solution blueprint review – As a prerequisite to the solution performance workshop, a Solution blueprint review workshop should have been completed already. The information that is captured for areas such as project plan, solution architecture diagram, business processes, integration strategy, environment strategy, number of users, data migration strategy, and other solution information can lead directly into this workshop.
- Project plan/schedule – Document or Gantt charts depicting the overall schedule and dependency of key project phases and their associated activities.
- System usage profiles – Operational process schedules and peak transactional volumes by workload type.
- Environment strategy – Block or flow diagrams that outline the types of environments that will be deployed, how and when they will be used, and how code and configuration will flow through them.
- Deployment locations – Diagrams or registers that show the physical locations where the solution will be deployed along with language and localization requirements.
- Interface register – Lists of interfaces with non-functional requirements and design patterns that document the scope and approach to implementing those interfaces.
- 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 that they will come from, the volumes, the timing, and the methods for migration. At the solution blueprint stage, ensuring that you have scope (entities and sources) is key.
- Performance test strategy – Any pre-existing documentation around performance testing strategy that describes areas such as performance objectives, KPIs, testing tools, environment to be used, and other factors that are consistent with performance testing.
This list is not exhaustive of project deliverables, but it is a good starting point for the solution performance review. The formats, composition, and names of each deliverable might vary from one project to the next. Format isn’t the most important element; rather, it’s the information that is available and agreed on across the team.
When you are conducting a solution performance review early in the project, many of these documents will not be fully formed, which is acceptable in most cases. Most important is that scope has been determined and that a conceptual plan is in place for how the solution will support that scope. If the scope and conceptual solution approach are in place, the solution performance review can focus on the conceptual approach, and then the follow-up, in-depth workshops can focus on the details at the point when they are available.
It’s acceptable if the project uses different ways to manage or track project information other than what is shown in the preceding list. Typically, the format isn’t critical if the information is readily available to project members. If the information from the preceding list isn’t documented on the project, or if it’s documented in a way that isn’t easily accessible, you should prioritize getting the relevant artifacts produced.
Tip
We recommend that you use diagrams and visual representations to provide high-level summaries in the implementation, wherever possible. These diagrams, charts, and graphs provide a ready means of communication across the team and with executives about plans and designs.