A few months ago I met an old colleague – let’s call him Ben, and we got talking. He is an experienced Microsoft developer now working on a greenfield Dynamics 365 project. He’d picked Dynamics up quickly after a few months training and upskilling himself, and had a good grasp of the platforms functionality and extensibility techniques. Our conversation went something like this :
Him : I’m working on a potential 200 seat project for <financial organisation> for a Sales Process. I’m going to automatically create a lead when my custom entity changes status and allocate it to the correct sales manager.
Me : Are the sales guys using Leads at the minute or how are they tracking leads outside of D365 – spreadsheets / access / onenote?
Him : Not sure, but that’s what’s going to happen – the Business Analysts have already modelled it in our new process flow diagrams. Once the lead is qualified, we need a trigger to create a case against the related account so another team can track the lead.
Me : What is the purpose of the case? Are you sure you need to use the case entity here?
Him : It’s mainly just for tracking purposes, but the new process says we might need the ability to merge cases sometime in the future. I’ve nailed the security model for cases and leads based on our to-be business units. Dynamics is great for that.
Me : Ok,it’s good you are thinking about security. Have you considered the licences each of these users might need alongside the security rules?
Him : No, that’s not my department, my manager deals with that, I just have to design and build the solution before year end. Licences are in next year’s budget. The project needs to save the company £200k per year by year two.
Me : Hmm. Let’s discuss this in more detail.
The conversation with Ben got me thinking about my approach to initiating projects and how my approach to development and design has evolved over the years across a variety of software projects. Methodologies included :
- Test Driven Development (TDD) – TDD is where the test for a function is written first, then the function itself. With TDD, developers know they are complete when the function passes the test.
- Behavioural Driven Development (BDD) – This looks at business outcomes and drills into the features that will achieve those outcomes.
- Domain Driven Design (DDD). This is a business focused approach which tries to manage complexity – it involves breaking down and revisiting client requirements, distinguishing between Entities and Values and grouping them into Aggregates using techniques such as Event Storming to formulate detailed requirements.
But what about licencing? Back in the 90’s, the majority of greenfield software development projects typically involved building an application from the ground up. You needed hardware, OS, a web server, some sort of programming framework, throw in a database and you were good to go. SQL licencing could be tricky because of per user / per core licencing gotchas, but broadly speaking, only if the application became massively popular or successful would there be a need for new licences to be purchased in order to scale out infrastructure.
Fast forward to the almost 2020s in the cloud and it’s a bit more complicated from a licencing perspective now. It’s more important than ever for any Solution Architect to have commercial awareness and a grasp of licencing considerations alongside traditional design, development and implementation considerations. Sometimes the cost of licencing will be a major factor in how you design a solution. This is what I call Licence Driven Development (LDD).
What is LDD?
LDD is concerned with how product licencing considerations for pre-packaged business software may influence any customisation, configuration or development tasks in relation providing an overall software solution. LDD should take into account current licencing models and agreements to facilitate designing a solution which meets business requirements, balancing licence costs, implementation costs and user adoption. It should consider scope for future growth but shouldn’t involve over-specifying licences to meet potential unknown future requirements. It sits alongside any existing design and development techniques such as BDD or DDD rather than replacing them.
Three Types of Licence Driven Development Projects in the Power Platform
1. Dynamics 365 First Party Application Development
Let’s look at my friend Ben’s project. Ben has designed a solution which creates a lead. The Dynamics 365 Lead entity was designed for this use case. From talking to Ben, there is also a likelihood that Ben will use Portals, Sales, Customer Service and Field Service in the near future. From a licence perspective, the worst case scenario from a cost perspective is that he will need 200 Customer Engagement Plan licences, currently retailing at £86.70 per month per user. That’s a cool £208,080 per year before any time is spent on implementation costs. Let’s hope the out of the box implementation doesn’t need much customisation!
2. Power Platform Development
A couple of years ago, there was no other option than to pay Dynamics 365 licence costs. If Ben wanted to customise, he would have had to develop on top of Dynamics CRM or Dynamics 365 to build an XRM entity model. Now he has a choice. Instead of using Dynamics 365 functionality, he can build an Dynamics 365 style Power Platform app himself and opt for a cheaper Power Platform P2 licence. Assuming there are 200 PowerPlatform P2 Licence users, this could bring the worst case licence cost down from over £200k to £72k per year. That will surely go some way towards saving that £200k per year.
The beauty of the Power Platform is, that since the October 2018 update, Ben is licenced to create his own ‘Lead’ entity. He doesn’t have to use that clunky one that’s a hangover from the CRM 4 and before days. Additionally, having a blank canvas to build from is often easier than trying to understand the reasons someone defined an entity in a particular way (over 10 years ago). This change is as a result of the following line being included in the Dynamics 365 licencing guide in October 2018 – “Custom entities may be based on entities included in Dynamics 365 or created by a customer or partner to represent business entities/items not present or to replicate those already in included in Dynamics 365.”
Currently priced at £6 and £30.50 for a P1 and P2 licence respectively, the PowerApps licences are a good middle ground licence. Both allow users to access data stored in the Common Data Service but have different interfaces. P1 provides a canvas tablet or mobile interface primarily for convenience of users performing business transactions such as requesting leave or approvals. P2 gives you the same but is closer to a traditional Dynamics 365 licence but minus the access to a set of restricted entities. With this in mind, maybe Ben could have forgone the lead and case entity and specified 100 P1 and 100 P2 licences and developed a PowerApps Canvas and Model Driven solution which could be licenced for under £40k per year.
3. Small <15 Entity App Development
So PowerApps, whether P1 or P2 is certainly cheaper than a full Dynamics 365 licence. But what if you are a small business on a shoe-string budget of £10k for year one? What if you are an SME who wants to prove that Dynamics and the Power Platform will help your business mature? What if a large majority of your users, because of the nature of their role, will only use your application once in a blue moon?
Assuming you have at least one full Customer Engagement licence, it’s entirely possible that there is another way you can build small applications, with what I call a ‘Foot in the door’ licence model. Take a 10 man small business primarily used by a single salesman and buy one full licence at £87.60 and 9 Team Member licences at £6 per month each. This would cost you only £1700 per year in total. From a development perspective, you can build a small application that allows all of those 9 users to use up to 15 editable custom entities.
This licencing switch to limiting team members to a fixed number of entities is a smart move by Microsoft because it has truly opened the Dynamics 365 First Party applications up to organisations with lower budgets. These are customers who may otherwise go with an cheap and nasty point in time solution. Now they can choose a strategic platform with a long-term roadmap. It’s reasonable to assume that a large majority of small customers who start off with Team Member licences will eventually need to upgrade higher licences. By that stage however, the benefits of the system will already be proven and cost should be less of an issue.
What approach should I take?
The answer of course is, it depends. It depends on size of company, scope of project, your maturity in understanding what you get out of the box and what you are comfortable building yourself. You may well decide on a hybrid model encompasing all three of the above, using some full licences for some business units and lightweight ones for others.
Some recommendations when considering Licences
- Understand your licence period and renewal cycle and how long your subscription prices are held for. This may differ for each customer depending on sector. Microsoft release a new licence price list every month.
- Try and fully understand the Dynamics 365 First Party apps and if they provide a value proposition strong enough for your business to justify the extra licence cost.
- Estimate development and configuration effort based on the licences and features available to you. Make sure your development team understands any limitations associated with your licence model.
- RFTLG – Read the Full Licencing Guide. There are two, one for Dynamics and one for Power Platform. Then read it again. You need to understand them both. Keep referring back to them to double check you are all good.
- There is no substitute for experience. If it’s your first time with Dynamics or the Power Platform, seek some consultancy from a partner to help you align business outcomes with a solution architecture which aligns with a product licencing.
- Also consider licence costs for third party plugins as a way to save implementation time or add value. Perhaps spending 20% of your budget on a third party plugin may save you 40% in development costs.
- Go small to start off with and do some Proof of Concepts or ‘Shitty First Drafts’ using a trial or one or two full licences and some team member licences to validate your licence model.
Whatever you do, don’t leave the licencing as an after-thought. Consider it early when deciding on your design approach and tailor your components to fit.