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 :

Continue reading “Licence Driven Development (LDD)” →