Our Blog

where we write about the things we love

21

Oct

Understanding licence-driven development in a cloud world

We have recently been involved in Dynamics 365 Customer Engagement implementations where licensing has been key in design decisions and here are some insights for these kind of projects.

Understanding Licence-driven development in a cloud world

Dynamics 365 Customer Engagement is Microsoft’s cloud-based customer relationship management (CRM) platform, which many of our clients have successfully used to drive sales productivity and improve their marketing efforts.

In one case, a client had already purchased licences prior to the analysis phase of the project, and in another, they wanted to minimise their implementation cost by carefully mapping the functionality to licensed use rights.

These examples reinforce the importance of what is known as Licence Driven Development (LDD).

What is Licence Driven Development?

Popular definitions of licence-driven development from the Dynamics community refer to LDD as, “how product licencing considerations for pre-packaged business software may influence any customisation, configuration or development tasks in relation to providing an overall software solution”.

It’s not replacing any other approaches, design techniques and development techniques such as Test-Driven Development (TTD), Behaviour-Driven Development (BDD) or Domain-Driven Development (DDD) but rather working alongside them.

When designing a solution, we should consider the licensing models available to us for reducing ongoing operational cost while delivering the business requirements. We should always keep in mind to an extent the scope of future growth but not overcomplicate things based on the unknowns.

Changing our perspective

Nowadays with product offerings like Dynamics 365 Customer Engagement, the licensing landscape is changing with the move to a more usage-based, à la carte-style framework.

One needs to be aware of the intricacies and co-dependencies between users’ rights and security privileges across cloud-based platforms. It’s more important now than ever before for consultants and solution architects to be conscious of licensing considerations alongside traditional design, development and implementation.

The ongoing cost of licensing can be a major factor in how you design a solution, and the on-going scalability of the solution. It’s important to not paint a customer into a corner that could constrain them from future growth.

When architecting solutions, you need to take a wide-angle view on the use case and types of users and roles they have within the organisation to really begin to understand what entities and data they would need to access. We have the opportunity to leverage new tools and techniques like the Power Platform to achieve the same business outcomes within a different licensing landscape.

What do I need to do?

Whilst designing business applications we should be asking ourselves these questions:

1) Who are the users? Salesperson, customer service representatives, admins, managers. What are their roles and personas within the organisation? What matters most to them? What are the pain points? What needs to change, and how will technology enable the journey to the key business outcomes?

3) When to leverage the Power Platform? Would building an “xRM” using the Common Data Service (CDS) and Power Platform work in this use case? Would building a custom app be more cost effective than first party applications. Is it scalable to future requirements?

2) What kind of application would meet their key business outcomes? What first party business applications (sales, customer service, field service, project service automation) have to offer them? Would these be enough or too complex and expensive for their requirements? Could we leverage alternatives?

4) Why it is important to understand cloud-based architecture? Consumption-based licensing is becoming a reality! What data archiving strategy should you put in place to keep the storage footprint down? How are you going to architect integration to consider API limits and consumption-based resourcing?

Most of the time, any implementation will have a mixture of uses and roles. Taking the above considerations into mind, you may well decide on a hybrid model, where you would use a combination of first-party business application for some users and PowerApps for others, leveraging multiple licensing models across the Power Platform for example: per app-based licensing, user-based licensing or full application licensing.

Recommendations

  • Know what the first-party business applications offer. This will empower you to map requirements to the capabilities that first-party application offer. These applications allow users to manage their processes from beginning to end and have inbuilt reporting capabilities. Each business applications sits within the area of customer engagement or enterprise resource planning and can be used in conjunction with each other or on its own.
  • Recognise the use rights of each license type. This will help you to map user rights to different roles in the organisation. You might have to create security roles that should enforce the use rights a user has due to the licence assigned. As of now, Microsoft does not technically enforce the use rights, but we should be careful in creating Dynamics 365 security roles so that the customer is always compliant. Tip: Rename the security roles and add a suffix that denotes the license type that the security role enforces. This helps admins to choose the correct security role that would enforce the licensed user rights.
  • Adopt and learn what Power Apps and Flow offer.
  • Be market aware i.e. know what third party tools are available so you don’t have to re-invent the wheel.
  • Reach out to experienced partners for better guidance as this is all new and changing and everyone is learning.

Some real-world case in point

In one of our recent implementations, the customer had a userbase that does not manage cases but does respond to enquiries.

Customer did not want to license that user cohort with a case licence as it would have been a significant cost increase. We came up with an enquiry model where a custom activity was created to capture and record the enquiry. If needed the enquiry could be converted to case and assigned to the relevant team who manages cases. In this case not all the users who managed enquiries need a case licence.

In another implementation, we reviewed the way we assign licences to managers. Usually managers in that organisation at higher positions are only interested in a read-only view of the data for reporting purposes. These managers were assigned light-weight team member licences and it helped reduce the ongoing licensing cost.

Talk to us at Intergen to learn more about how you can effectively manage implementation and ongoing licensing costs while accomplishing your business requirements.

Posted by: Monica Chopra, Senior Consultant | 21 October 2019

Tags: Dynamics 365, Dynamics 365 Customer Engagement, LDD, Licence Driven Development


Top Rated Posts

Blog archive

Stay up to date with all insights from the Intergen blog