In Microsoft’s continuing quest to make Business Solutions easier, “Configuration over Code” is where they are making the most investment. “Coding” requires skills that most customers, and frankly most partners, do not have, which leads to additional costs for the customer. How is Microsoft doing on lowering this barrier?
In the recent past, in order to get a Dynamics Business Solution to truly “fit” a customer’s unique requirements, configuration would only get you part of the way. By configuration, I mean adjusting the settings and options within the application that would be available to a System Administrator, a role that a Partner, as well as the Customer, may have. You could do a lot with configuration, but in the end it was glorified tweaking. At some point, many specific requirements, would require an effort beyond configuration. This additional effort was probably required in “most” deployments, and almost always required additional expenditures with a partner/developer. I have yet to find the customer who was happy to invest these additional funds, and Microsoft has been eyeing this tension as well. With Dynamics 365, Microsoft has made great progress towards, if not codeless, at least code less, and I expect that trend to continue.
Code is code, it is written by a coder, it can be good or bad, and still function. Introducing externally written code into Dynamics has been a very common way to extend its capabilities for a very long time. The problem with code is that it is not Customer “accessible”; not that they can’t get to it, but they can’t understand it if they do. For many years, I think even Microsoft was resigned to the fact that code would simply be required with a complex application like Dynamics. The best they could hope for was that decent coders would be involved. I consider a “Developer” to be a different animal. While they may also know a bit about coding, their real strength is extending the application with the tools provided, more like a “Super Configurator”. Things like adding custom entities, building complex workflows. etc. But even these super-configuration tasks were beyond most customer’s capabilities, leading to additional costs.
The R&D Team behind Dynamics 365 at Microsoft, has been very busy writing lots of new code, the goal of which is to reduce the need for additional code after product delivery. The first attack at minimizing external code is giving Super Configurators more tools. You might look at the new ability to create a slider control as fairly simple to add in the new configuration. This would have required external code before, and no doubt Microsoft wrote a whole bunch of code to eliminate the need for this external slider code.
One of the huge benefits to Microsoft of this shift to the cloud is that they can now see what is happening in the Customer environments. Telemetry is a big thing and getting bigger. I don’t know they they can do this today, but if not already, they soon will be able to see, and catalog, what solutions and web resources are being added, and for what purpose. This would allow them to identify common feature gaps, that maybe should be added to the core. We saw this recently with the new Editable Grids capability, much to the chagrin of a few ISVs.
AppSource is the new preferred method for adding first and third-party capabilities to Dynamics 365. AppSource apps typically contain a lot of externally written code. There is a lot of telemetry behind AppSource. AppSource will be a huge repository of “Feature Gap” fillers, that could eventually find their way into the core, and not just through acquisition. I am not suggesting that Microsoft is a Witch and AppSource is an Apple, but Customers will always trump Partners, as well they should. Prior to the Cloud and AppSource, Microsoft had zero visibility into their customers’ deployments. The Wild West is being tamed.
This is the holy grail Microsoft is striving for; if Microsoft can reduce the cost for the customer to reach success, you can bet your ass they are going to do it. Cloud may have lit the fuse on lowering customer costs, but competitive forces are keeping that fuse burning and extending it. Let’s take a look at some of the options that a typical customer has today, I’ll use an SMB Construction Company as an example.
The typical SMB Construction company will make use of plenty of out-of-the-box features. Leads, Opportunities, Contacts and Accounts for example. This is fine for Lead to Opportunity management, but that customer would like to do more, for example they may also want to track their projects in Dynamics 365. To do this, they have several options depending on their needs:
We are working with a large government agency that I cannot name. They came to us after pursing their traditional route to solving a software issue with a custom coded approach. The traditional approach was coming in at 7 figures and that went right up, and right back down, the flagpole without approval. Still having a dire need, they investigated alternatives and that led them to us. Instead of writing code from scratch, I suggested that we leverage the existing millions of lines of code that Microsoft has already written behind Dynamics 365. The project, instead of coding, became a “super configuration” project, and the cost fell to the low 6 figures. This entire agency has now adopted the approach of using COTS (Commercial Off The Shelf) software, with configuration only. I wish I could name them because your jaw would drop.
To my coder friends out there: Coding has entered the Grace Period.
The post Dynamics 365 – Bending it to Your Will first appeared on Steve Mordue MVP.
Original Post https://stevemordue.com/dynamics-365-bending-will/?utm_source=rss&utm_medium=rss&utm_campaign=dynamics-365-bending-will