I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around discovery, planning and analysis.

There is a section of the MB-200 exam which has a focus on discovery, planning and analysis, the associated skills measure statement is shown below.

Introduction / Overview

I think we can clearly see that with these newer exams Microsoft is trying to measure our real-world skills as well as our technical knowledge. I do like this shift in emphasis as just knowing a bunch of technical facts doesn’t make someone a better functional consultant! This shift in emphasis “feels” more apparent for this section of the exam than any other!

Many of the topics may seem fairly easy for an experienced battle-scarred consultant but newer consultants with less projects under their belt may find this section more of a challenge.

Many of us work for Microsoft Partners, meaning we will be allocated to numerous organisations and participate in many projects. This will result in us being exposed to multiple approaches to running projects. Each approach is typically adapted to meet the scale of the project and size of organisation. Also in my experience, I ‘ve found certain industry sectors may have more or less governance. For example, a customer from the financial sector is likely to be required to comply with a raft of rules that might not be present in “simpler” less regulated environments. This regulation and governance typically results in extra documentation to demonstrate our compliance. (And also additional auditing to check that compliance!)

The overall project management approach could also play a part. For example, with a traditional waterfall project we’d define all the requirements upfront. (Possibly in great detail.) Whilst in an Agile project it could be considered more typical to “allow” the requirements to evolve as the project progresses. But Agile is not an excuse for skipping any documentation or best-practices! Agile would simply mean that requirements would be defined and refined in a more interactive manner, the need to record these requirements and our decisions around their creation would remain.

The commercial basis of the project may also influence the documentation and processes we’ll follow. Say we are working on a fixed price deal …. commonly in this scenario a set of features to be delivered will be agreed between the supplier and the customer then a fixed price agreed. Change in all projects is inevitable but every change in a fixed price deal may have a scope and therefore cost implication. In projects like these maintaining a change log is absolutely essential!

I guess what I am trying to say is that there isn’t a one size fits all when we start to look at how we engage with customers. And therefore the quantity and detail of documentation we might expect can vary drastically. But there will be some common themes and best-practices that we might expect to see in all projects. And even if we don’t always follow these best-practices we should be aware of their existence.

Having said all this, we do still have a few statements that are knowledge based. For example, “select between managed and unmanaged solutions”. In this example we will need to understand the difference between managed and unmanaged solutions and be able to appreciate when each might be used.

In the following sections I will give some narrative on the topics mentioned in the skills measured statement. Then, for some topics I will create additional blog posts to dive deeper.

In the following sections I will attempt to give you an introduction into the concepts connected with each of the following;

• Entity Diagrams
• Mock-ups
• Data Migration / Integration
• Determine OOB Functionality
• Validate Functional Requirements
• POC
• Collaboration Tools
• Perform an Audit
• Change Logs
• Managed and Unmanaged Solutions
• Entity Components

Entity Diagrams

An Entity Relationship Diagram (or ERD) is a chart that illustrates how entities relate to each other. When thinking about databases this will mean the tables within the database. (The term table and entity are pretty much interchangeable!)

Typically a standard set of symbols will be used to represent entities. Connecting lines between the entities will show how they relate to each other. By this I mean a one to one, one to many or many to many relationship. Sometimes we might also see notes to highlight any mandatory relationships.

The concept of an ERD is certainly not a new one. Peter P Chen is recognised as creating ERDs in the 1970s. You can read more about Peter on Wikipedia here. Although you should be aware that Chen’s notation is just one way to draw an ERD.

A properly drawn ERD should clearly explain what entities exist and how they are connected. As Dynamics 365 model-driven applications are data focused understanding the data relationships is often a major step in the overall solution design. Drawing the relationships may help highlight any limitations in the design. Assuming you create an ERD before actually starting to build your entities it may prove extremely valuable in spotting design weaknesses / limitations before you start to develop anything.

Personally I have often found a well-drawn ERD to be one of the most important pieces of technical documentation. Mapping out the data is often the first step I’d take in creating any design.

You can read more detail about Entity Relationship Diagrams here.

Mock-ups

Users often find digesting and correctly interpreting sizable requirements documents a challenge. Mock-ups of screen designs can be a great way to help ease this pain. As seeing what the final application will look like really helps them visualise the end result.

In my experience we have at least three variations on the mock-up theme;

1. Sketch / Rough outline – sometimes rather than having a detailed mock-up a simple drawing giving a “representation” of the screens maybe all that is required. If this is done final decisions on who the forms look and feel maybe needed during the build process.
2. Wireframe – the term wireframe normally suggests some level of automation to show how the flow from screen to screen might operate. Potential users would be able to clink on “links” and see how the transition from screen to screen might “feel”. With Dynamics 365 model-driven apps the navigation around the app is generally pretty standard. Hence, in my opinion, the effort of creating a wireframes maybe unnecessary. Although some exceptions may exist! For example, you might be creating a Dynamics 365 Portal when a Wireframe could prove really useful.
3. Detailed Mock-ups – A detailed mock-up would be an accurate representation of the expected form. It would include no logic and wouldn’t function as a form but would give the users a very clear image of the intended screen design.

Mock-ups can be created using tools such as Visio. (Other tools are available!!) Usefully a quick Google search should help you find a number of Visio stencils that include the common controls we find on Dynamics 365 forms. Using these stencils will really speed the production of any mock-ups.

In simpler projects I have often created “mock-ups” by quickly creating a rough version of the actual screen. (Just with no business rules, JavaScript etc.) I do this as the form designer is really easy to use! Although we potentially start to enter a grey area with this approach …. as when would you consider your form mock-ups to actually be a prototype or proof of concept!

Data Migration / Integration

Data migration and integration are very closely related! However data migration would typically be a one-off or infrequent task. Whilst integration suggests a frequent and ongoing requirement.

When moving from a legacy system into Dynamics 365 we may need to migrate data from the old system. Often, Dynamics 365 will then become the master data source. (Meaning this would be a one-off task.)

Data integration, however, suggests an on-going link between two systems. It maybe that an organization already has a number of “satellite” systems these might feed Dynamics 365 with data. Or maybe you need to export data from Dynamics 365 to populate the existing systems. The frequency and complexity of the required integration may suggest a number of different technical approaches being required. For example, in simple scenarios an infrequent manual export / import of data could suffice. But in more complex scenarios an automated near real-time approach may be required. (Which could suggest some significant development effort!)

Below I will try to highlight some common challenges / concerns with data migration and integration;

Tools – it will be important to select the right tool for the job. With Dynamics 365 online we cannot directly write SQL that will access the data therefore any data operations must happen through the SDK. Several options are available;

• Export / Import Utility – Dynamics 365 has an import feature which can be used to import data from various file formats. (Including CSV, txt and xlsx.) Often a spreadsheet might be used allowing the review of data before import. This approach is easy but is probably best suited to simple or infrequent requirements.
• DIY – your developers can create a custom migration / integration package using the Dynamics 365 SDK.
• 3rd party utilities – there are a number of utilities that allow developers to create the ability to handle large datasets. Kingswaysoft and Scribe are just two examples of these.

Data transitions – when moving data from system A to system B we may need to transform the data. The entities or fields held in the source system may not always neatly map to the target system. To give you just one “simple” example, consider a contact’s name. In Dynamics 365 this is typically held as separate first name and a last name fields. But your source system may contain a single name field. If this was the case you might need to decide how to split your names into the separate first name and last name fields. You will need to complete an analysis of the source ERD and Dynamics 365 ERD to decide what transitions are needed. The level of complexity in the expected transitions may influence your choice of the right tool for the data import!

Archive – during a migration process it maybe a fantastic time to consider archiving (or simply deleting) old redundant data. I have often come across legacy systems “stuffed” with data which will never be used. Data storage is not free! And holding really large volumes of data could also have an adverse impact on performance. Therefore taking decisions around what data not to migrate may be essential. Additionally you should consider how to prevent the new system ending up in the same state! So define data retention policies maybe prudent. (Tip: Dynamics 365 does include a bulk delete feature which could be used to frequently delete records of a certain age. For example, you may decide to delete any unqualified leads older than “n” months.)

Cleanse / deduplication – Duplicates can be a common problem in all databases. Plus data quality can be a challenge. During the migration process it is often common to need to decide how to identify and resolve duplicates. Dynamics 365 does include a merge capability to merge duplicates. But if you are migrating large volumes of data an automated approach may need to be considered and built into your migration solution.

Regulatory concerns – regulations change! I have come across legacy systems that contain data which doesn’t comply with the latest privacy regulations. For example, if you are holding leads / contacts for marketing purposes and you don’t have the required consent levels to engage with these people then maybe a migration project might be a good time to purge this data.

Data Governance – data should be tested! In a one off migration this might include a number of automated and manual checks on data volumes and quality. But with data integration you may need to consider on-going checks to ensure data integrity is maintained. Data governance is potentially a technical challenge and also a significant business challenge! When multiple systems and business functions are involved, who controls the master records or who owns the overall responsibility for the data quality can be complex topics.

Configuration Data – most of the above will have been focused on business critical data such as accounts, contacts or orders. But you may need to also consider configuration data. Most systems will include many sets of reference data. Including things like country codes, currencies, product types and much more. It maybe important to move this data not just from one system to another but from multiple instances. By this I mean moving the configuration items from development, to test or production copies of Dynamics 365. As part of the SDK, Microsoft do provide a configuration migration tools for this purpose. You can read about it here.

Hopefully you can see that data migration and integration can be a complex topic. This link from Microsoft docs might help you gain further insights.

Determine OOB Functionality

Dynamics 365 contains loads of out of the box (OOB) functionality, as a general principle I always encourage customers to use OOB features in preference to custom development. A few reasons are;

1. Speed – using an existing feature means potentially complex development efforts can be avoided. It is almost always quicker to use an OOB feature rather than developing a custom one. (faster also equals cheaper!)
2. Simpler future support – if you use OOB entities then other experienced Dynamics 365 consultants should find it easy to understand how these operate. And will therefore be better placed to offer you support / guidance.
3. Future updates – Dynamics 365 is a cloud based service that receives frequent updates. Say you are developing a ticketing system …. you could create a custom entity called ticket or you could use the case entity. If you decide to use case you will not only benefit from all of the existing features but also any future ones! For example, I saw this happen when Microsoft released the enhanced SLA feature with cases. My customer who was already using cases could immediately start to use this new feature with no development effort. If they’d implemented a custom “ticket” entity this wouldn’t have been possible.

Sometimes you might need to be creative in how the Dynamics 365 entities are used. Say the company you work with has a subscription service and they always talk about people who are “members”. When you hear this don’t assume a members entity would be required! You could simple use the existing contacts entity and maybe have a contact type of member. Or maybe you could even rename the contact entity to be called “Member”. Renaming entities is a common way for you to use OOB features but represent them using the terminology the business is familiar with.

When a new requirement is presented also consider if an existing Dynamics 365 feature or app exists that you could now be used. For example, you may receive a requirement for customers to be able to enter self-service support requests. You could develop a custom approach for them to be able to log and view cases on the customer’s website. Or you could simply deploy a standard Dynamics 365 Portal.

The ongoing challenge for all consultants is being aware of potential features. We should avoid re-inventing the wheel simply because we weren’t aware that the required feature already existed. So keeping our knowledge current is essential. Keeping our knowledge current can be a dauting task but Microsoft do publish a product roadmap that should help us. You can view that here.

Validate Functional Requirements

Establishing, documenting and agreeing functional requirements can be a challenging (and fun) task. On countless occasions I’ve worked with users who don’t really know what they want …. they might simply know that they want a system to improve their processes. Users understand the business need to offer better customer service or reduce costs but they may not have a vision of the functionality required to realise these objectives.

As a functional consultant you’ll need to leverage multiple approaches to help identify and agree the features required to deliver the stated business objective. Often this will include running multiple workshops with potential users.

It may even be that the existing processes aren’t well understood. Meaning we may find a need to document the “as is” in addition to the “to be”.

If you’re working in a Agile environment user stories will often be useful to document and validate functional requirements.

A user story is the smallest unit of work in an agile framework. A user story is an end goal expressed from the software user’s perspective. The purpose of a user story is articulate how a piece of work will deliver value back to the customer. User stories are also the building blocks of larger agile frameworks, like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. Typically each user story will be associated with a number of acceptance criteria. These help the users understand the excepted result of the feature being developed and also importantly act as an invaluable aid for testers to check the developers work. All user stories typically follow a standard format …. “As a [persona], I [want to], [so that].”

Tip:
Don’t discount user stories if you are working on a Waterfall project! A user story is simply a template for defining a requirement and should be a concept that can be applied in any scenario.

One of the challenges we have as functional consultants is ensuring our intended users have understood the feature we are describing. And also that we have correctly interpreted the original requirement. User stories can help but other techniques such as mock-ups or proof of concepts can also help validate our understanding.

POC

Proof of concept (POC) systems are often used to demonstrate that a new feature will work. This might be to prove that a new technical feature is achievable or maybe to test that the business process can actually benefit from the proposed system. I like to think of a POC as a disposable prototype.

A proof of concept system may help validate a ground breaking idea without building the complete solution. Often it is better to build a POC and fail quickly than waste countless development hours on a bad solution.

Often a POC system will be built quickly and might therefore exhibit quality issues. This might be intentionally done to test a theory and succeed or fail as quickly as possible. In this scenario the software developed will often be throwaway. But I have seen POCs developed that will later become part of the production solution. So there isn’t a hard and fast rule here. But generally speaking I would suggest that a POC is not for production use.

If you wish to develop code that will test an idea in a production environment a slightly different concept is often adopted. A Minimum Viable Product (MVP) is a term which originally applied to the “Lean Methodology”. Lean is a way of the optimizing people, resources or effort of an organization. When applied to software development this can involve a concept of developing only the must have requirements for a given solution. By doing this we’d create a working piece of software that might not meet all of the stated needs but as it addresses all of the must haves should therefore be a useable solution. The idea being that you could develop the solution and implement it into a production environment in the shortest possible amount of time. Often an MVP might be considered a version one of a solution. Later versions maybe required to fully realise the intended vision.

Collaboration Tools

On all projects it will be essential for users to collaborate with functional consultants in defining requirements / user stories. Or for developers to work with the stories to develop the actual solution. Testers in turn will need to understand what was required and how they can validate the outputs.

With small local teams collaboration is a simple task. But with large teams working on large projects collaboration won’t “just happen”. Your users, developers and testers may, for example, be located in different countries. With potentially significantly different time zones.

Therefore considering what collaboration tools are available to document user stories, record defects and manage issues should be a high priority. Microsoft provide Team Foundation Server (TFS) which may help. But other tools are available, such as Jira, Confluence and many others.

Plus we can make great use of other Microsoft collaboration products. Such as OneDrive or SharePoint for document sharing. Or Microsoft Teams might be used to create collaborative worksplaces and host meetings.

Perform an Audit

In some organisations I’ve worked at we have referred to the initial system audit as a “Discovery”. The idea is that you may need to document everything about the current architecture. This might include details for the physical architecture and software components. Not forgetting things like the operating system and browser versions.

Having a detailed audit of the existing environment can prove extremely valuable. For example, your proposed design may leverage new features that are only supported for certain browser or operating system versions. If you hit this type of requirement knowing how many outdated desktops exist could be an essential piece of information when planning the effort and costs involved in the upgrade.

You may also wish to record details of the network architecture and any other aspects of the architecture which might impact performance. Information like this might help you make observations / recommendations on expected performance.

Additionally documenting details of all existing software licenses may help you ensure all users have the correct licenses to support any changes you plan to deploy. And if they don’t have the required licenses then any associated costs can be built into the project estimates.

I hope you can see that without an accurate system audit it may prove very difficult to make informed comments on performance, stability and system running costs.

Change Logs

You can read wikipedia’s definition of a change log here.

Maintaining a list of changes maybe essential to retain a list of decisions taken.

Some simple changes may need no authorisation but others may have a significant impact on the projects scope, timescales or cost. When this is the case it is normally important to record the detail of the change, its impact and who requested / approved the change. This can be of particular importance in fixed price contracts when every change could result in an additional cost.

Different organisations may log changes in different ways! Typically a detailed Change Request will initially be created. (Often described as a CR). The project board will typically review CRs and approve or reject them. Any approved CRs will be recorded in the change log.

The level of formality in this process can vary drastically. I have also often been project managers given a certain degree of discretion. They may be allocated a change budget that can be used for small changes. However almost always large changes with commercial impacts will need to have some form of formal authorisation.

You may also hear the phrase Change Advisory Board (or CAB). CAB, is actually a term from ITIL. (ITIL stands for the “Information Technology Infrastructure Library”, a set of best practice standards for delivering IT services.) CAB is part of an ITIL phase known as “Service Transition”. This includes the change management processes required by your IT services team and will have a focus on limiting business risk. They will want to evaluation changes completed in your project prior to allowing deployment into production environments. The CAB will consider if the changes are fit for purpose and of an acceptable level of risk. The CAB risk assessment may involve asking multiple questions about the change. Including, “How are services and service levels impacted?”, “What is the impact on performance?” and “Will the change have any impacts on security or compliance?”.

Managed and Unmanaged Solutions

I will create a separate post specifically covering the technical details of managed and unmanaged solutions!

A solution is a Dynamics 365 construct which allows us to “wrap” all of the technical assets in a Dynamics 365 project into a solution. A solution will include entities, forms, views, dashboards, web resources and much more that make up your final application. A solution can be version controlled and exported / imported. This allows us to migrate changes from our Dynamics 365 development environment into our test or production instances in a controlled manner.

All solutions start off as unmanaged, your development environment will therefore include the unmanaged solution(s) that make up your system. This development solution can then be exported in either a managed or unmanaged state. The solution in a managed state is typically imported into your production and test instances.

This process gives several advantages. As unmanaged solutions can be changed whilst managed solutions can have restrictions which prevent anyone making customizations outside of your controlled development environment. When we delete an unmanaged solution just the solution definition is removed. But when we remove a managed solution the assets held within the solution are also removed. This process gives us the potential to rollback changes!

Solutions can also be used by ISVs (Independent Software Vendors) to ship their packages in a format that is easy to deploy by customers. This would generally be done as a managed solution, as this would restrict the customers from amending the application provided and also make it easy for the customer to remove the solution if no longer needed.

As mentioned above I will expand on the technical details of solutions in a future post …. For now the important takeaway is that we have a mechanism in Dynamics 365 to migrate changes from development environments to production ones in a controlled manner.

Entity Components

The entities which may exist within your solutions will be made up of multiple components.

The components of an entity include;

• Fields – these are the attributes that make up an entity.
• Relationships – the links between this entity and others.
• Business Rules – processes containing conditions and actions that can automate various behaviours on the entity. (Such as hiding / showing fields and much more.)
• Views – lists of data. Each entity can have multiple views of data that may include different columns and filtering for various purposes.
• Forms – each entity can include multiple forms. Forms can have multiple types / purposes, include main forms, quick view forms, quick create forms and cards.
• Dashboards – Some dashboards can be entity specific and would be an entity component.
• Charts – Each entity can have a number of charts that when combined with views will render graphical aggregations of the data.
• Keys – all entities have a primary field and unique ID field. The keys option extends this to define additional / alternate keys. These might include things like an account reference number which uniquely identifies an account. (Possibly provided via an integration with a third party system.)

Many of the other posts I’ve created for this revision guide will have expanded on the entity component concepts mentioned above!

I have covered quite a lot of ground in one post! You may need to research some of the topics above in greater detail but I hope this post has given you some important pointers for your MB-200 revision.