Model your Dynamics 365 Solution – Overview (Part 1)

by dani.kahilin Diagrams, Solution Envisioningon Posted on

Introduction

Building a dolls house can be done by one person. It involves a simple process, performed with basic tools such as nails, hammer, tape and can be done in a few hours without any external help. Your little daughter might want to give you a hand, but you see my point.

If you want to build a real family house, you might have to consider a different approach. It requires planning, sketches and at least a blueprint of the house so that the owners, the architect and the builders can have the same understanding of what is being built.

The same goes for Dynamics 365 solutions. For a simple solution, you might be able to trial and error until you get it right, but in most cases a well-defined blueprint is essential.
In this article, I’ll focus on visual modelling as an extremely effective tool to get to that point.

Why visual models work

Written documentation is the least effective form of communication to create a shared understanding. Our stakeholders see the solution differently than developers do. Even stakeholders sometimes see the solution differently between one another.

Using visual models when implementing Dynamics 365 helps to create a shared understanding of what are the key features of your solution. They can help you map out the requirements and how they relate to one another.

Using models will:

  • Help you visualize a system and promote a deeper understanding of the requirements.
  • Provide a template that guides you in configuring your Dynamics 365 Solution.
  • Help to understand complex systems part by part, exposing opportunities for simplification and re-use.
  • Document the decisions that you have made.
    Ideally, you want to co-create models with the team and stakeholders. Be sure to keep your modelling as lightweight and collaborative as possible. Do just enough modelling and defer commitment. Down the track, you will know more and will be able to ask better questions, which will allow you to dive deeper into other areas of the model and iterate.

    Models will evolve over time. Some may disappear if they are no longer needed, some may grow and become more detailed, and some new models may appear. Below I’ll share the ones that have continued to work for me in the 12 years I’ve been implementing Dynamics 365 solutions. 

    My go-to Models and when to use them

    Use Case Diagram (UML)

    A Use Case diagram is a graphical representation of the interactions between an actor and a system. A use case is a great technique for quickly identifying, clarifying, and organizing core system requirements.

    I typically create a Use Case Diagram in the following situations:

    • Initial meetings with stakeholders to get a quick understanding of the requirements
    • First workshops to validate requirements (and making sure I didn’t miss anything obvious).

      Conceptual Diagram

      The Conceptual Diagram describes, at a business level, what are the main functionalities of the solution. The colouring helps me group functionalities of the same category.
      The Conceptual Diagram is a constantly evolving diagram, that we tweak along with the build and the lifecycle of the system.

      Conceptual Diagrams help me explain how I understood the solution to others. I use Conceptual Diagram in the following context:

      • As a start of most of my workshops to explain and remind what is the solution about and show, on the diagram, what will be the workshop about. Ex: If my workshop is about the Enquiry Process, I will spend more time showing the part of the system that will be discussed during that workshop.
      • As a tool to get a shared understanding and stimulate the generation of ideas.
      • To describe the solution to my team, as it helps me structure my thoughts and narratives when I explain the system.

      Process Flow Diagram

      A process flow diagram is a simplified representation of a process. It usually doesn’t show exceptions or “problems” that may occur during the process flow.
      There is always a start and an end where actions are being done by the different actors of your solution. 

      When to use a Business Process Flow:

      • After I have drafted a Use Case Diagram, I use the Process Flow diagram to describe the more complex Use Cases. 
      • During workshops or meeting to capture the steps of how a particular action could be done in the solution.

      Entity Relationship Diagram

      An Entity Relationship Diagram (ERD) is a type of diagram that illustrates how Dynamics 365 Entities such as Contacts, Companies or Cases relate to each other within the solution.

      ERD helps to understand how the data is structured and how your Dynamics 365 Entity model will be designed.

      Summary

      The above 4 Models are the ones I used most of the time on my projects as key documents to foster a shared understanding of the requirement and the solution we are building. In the next few articles I will describe in more details the process of building each of those diagrams, and how they relate to one another.