Can you future proof your Digital Transformation project?

Based on a recent article by my TDG colleague Chris Huntingford, I started wondering about the over-referenced term of Digital Transformation. Why do we need to hear that term again? Well the reason for it is related to Chris’ article on future-proofing your customisations (and platform) and to the Microsoft Dynamics 365 update cycle.

Think of a typical Dynamics 365 transformation project: they span several years and are vastly complex in nature. So, when you undertake these projects, how do you accommodate the 6-monthly release cycle from Microsoft and the architecting of a future-proof solution? The answer is usually that the solution is architected in a future proof manner but the update cycles are ignored because Microsoft give you a year’s leeway before mandating specific updates.

A multi-year programme of work may be conducted over 3-4 years where the core Dynamics 365 product changes significantly in that time where a situation could be realised where as soon as the customer goes live, they need to immediately start thinking about upgrades and patches rather than bedding down the solution and getting the maximum value out of it.

Is it possible to avoid this? Typically, yes, but it requires a bit of forward thinking on both the Dynamics 365 partner’s and customer’s side. Things like the following should be considered:

  • Realising early time to value by deploying smaller functional pieces rather than entire solutions in one go – no doubt this will get the agile vs waterfall people arguing but simply put, the Microsoft update cycle makes waterfall type projects very difficult to complete effectively.
  • Leveraging accelerators/ISVs and preconfigured solutions wherever possible – most Dynamics partners have several of these that are typically stemmed out of industry best practice. Make sure to evaluate them though and check that they are aligned to the Microsoft roadmap, licensing guide, and future-proofed as Chris suggests.
  • Scope in project time for platform updates and new functionality reviews – this is usually a function for some sort of Design Authority, but too often they get stuck looking at current requests without considering what’s coming in the future. Fundamental platform upgrades should also not come as a surprise and should be catered for well in advance. Microsoft have several early release programs available for this as well as their publicly visible roadmap site.
  • Encourage, enable, and promote consultants and customers to challenge the old ways of thinking in favour of newly available alternatives – this point should ensure that the best possible considerations are achieved and is not meant to be a forum for constant debate with no action. Tough I know, but somewhere a decision needs to be made for better or worse, but at least there will have been some considered conversation around the decision before it is just blindly made because that’s the way things have always been done in the past.

Will the above list provide the illusive silver bullet for ensuring that Digital Transformation projects are always successful and utilising the latest technologies and ways of doing things? The answer I am afraid is no. What it should enable is projects that are more flexible and more capable of realising greater value, earlier, for the customer.

Don’t’ forget that there are also technical aspects around the same topics which are just as important but more relevant for the Dynamics 365 partners and consultants delivering these projects. There is no easy way to go through all of the technical aspects that could and probably would change through the lifetime of a Digital Transformation project, I suggest you have a look at and be aware of the following (if you aren’t already):

  • Flow – this new workflow engine that is sperate from the core Dynamics 365 workflow engine provides a huge amount of power and prebuilt connectors that enable several integrations and extended process to be designed and implemented very rapidly. The per transactions model costing should also ensure that you get maximum value for your spend. Don’t gloss over the fact that PowerApps can use Flow and these PowerApps can be embedded in Power BI dashboards which in turn can be embedded in Dynamics 365 Customer Engagement instance. Why would you care? Well you can create one flow that can be triggered either from Dynamics or from Power BI giving a holistic solution that is easily maintainable and cost effective.
  • The Azure platform all up – this is one of the most crown jewels of the Microsoft empire. Huge amounts of capabilities and all easily available to leverage from your Dynamics 365 Customer Engagement instance. Have a look at these in particularly:
  • Teams – collaboration tools continue to evolve and Microsoft Teams is the latest version that is definitely worth checking out
  • Visual Studio Team Services (VSTS) – one of the core components of most Dynamics 365 projects. Whether it’s a code repository, an Agile backlog facilitator or DevOps facilitator, VSTS is definitely worth investing some time in seeing how you can leverage it.
  • Office 365 E5 – lots of productivity in this one, but check out some of the amazing security stuff that Microsoft also include for you.

Future Proofing your Dynamics 365 implementation and Configuration (Part 1 – The licensing question)

Microsoft Dynamics 365 Customer Engagement is an incredibly versatile platform that can be configured with relative ease. This is both a good and bad thing because often solutions that are implemented descend into configuration anarchy. Yes, it sounds as bad and it is. Imagine a deployment with hundreds of entities, attributes and solutions that are irrelevant or are there for no particular reason. On the other hand, what about loads of old ISV solutions that aren’t being used anymore. As fans of Dynamics 365, I can guarantee that most of us have seen this.

So how does one future proof their implementation? I appreciate the fact that there will be loads of opinions on this matter and there are hundreds of things one could do to manage this process from a business and technical point of view.

One of the big questions during any implementation is whether to utilise what is available out the box or whether to create custom entities and attributes. This is generally based on the scenario and the customer’s requirements. Personally, I prefer to use what is already available as much as possible as there is a load of functionality that you may need to rebuild using workflows and plugins if you go the custom route. IN ADDITION, when Microsoft release updates / upgrades, I know the functionality in my solution will be upgraded correctly and is in line with Microsoft projected functional roadmap. That isn’t to say that Microsoft don’t deprecate functionality. They definitely do!

Now, here is the thing: The licensing model limits us or controls what you can and can’t do as far as the addition of custom entities relevant to the existing functionality. YOU MAY NOT REPLICATE THE FUNCTIONALITY OF STANDARD ENTITIES IN DYNAMICS 365 WITH CUSTOM ENTITIES. If the standard entity is replicated then the user must be licensed appropriately for that standard functionality. This is available in the Licensing and Pricing guide on page 17. THEREFORE, in short… you can create your own “Case” entity, sure… However, you will then need to purchase the Dynamics 365 for Customer Services license for users that will be accessing this entity. This is because it replicates the current and standard case management functionality.

This makes absolute sense. Information on the enterprise-licensing model can be found here in appendix B. This is one of the first documents I generally consult during solution design. Microsoft suggest that configurators utilise what’s available within the standard Dynamics 365 platform so that when core functionality is added to the platform on top of the standard entity set or functional area (marketing, Sales, Service, PSA & Field Service), customers have access to this without having to add additional configuration. As an example, when the entitlements functionality was added to the services module, it linked to the standard case entity and functionality as a standard. Companies that had built their own case functionality had to either move to the standard case management functionality or configure a link to the entitlements.

A second example that I have come across before, which required configuration and was considered future proof was where a customer had several case types, each of which required a large amount of data capture. Instead of adding hundreds of fields to the case form, the case was simply used as the header record and a set of custom entities was created for each of the categories. The core case functionality, such as routing and email-to-case was used and the configuration flexibility of the platform was used to apply a huge level of personalisation from an incident management point of view.

In summary, part of future proofing your configuration is to bear in mind what Microsoft offer as out the box functionality, as well as what the licensing model allows you to do and not to do. Often, this involves an honest and transparent conversation with your customer, which will enable you the ability to educate them in what, is required to implement a robust, performant solution that is as future proof as you can make it. In the next post I will be talking about the Dynamics 365 roadmap and how you can prepare your solution for what’s coming.

D365 Custom Control Framework (CCF)

Microsoft Dynamics 365 Customer Engagement contains some impressive hidden gems in some really cool functionality that really promote a more immersive and interactive user experience. One such gem is the Custom Control Framework or CCF, which enables users the ability to place interactive controls over attributes. This video shows off some of the standard Custom Controls and how to add these to the new Unified User Interface (UUI) forms. It is believed that Microsoft will enable us the ability to create our own custom controls in future releases.

I’d also like to give a shout out to Amandip Dhillon for being a part of the testing of these controls! Awesome job 🙂