Finding The Limits of Low-Code

Here’s why customers should pay for more for customizations!

How to Write a Modern RFP for CRM Implementation

How to ”Do More With Less” with Microsoft

The Myth of the ”Full Stack Developer”

Update on ”Service as a Subscription” Model

When Microsoft introduced the Power Platform as a "Citizen-Friendly" set of tools for non-technical business users to create apps to solve business challenges, it seemed a worthy endeavor. Well, enough time has passed to assess the outcome. Those who jumped in with both feet now have a mountain of shitty little apps. Those who watched from the sidelines decided, "We don't need that!" So is that the end of the tale? Let's see.  The First Mistake To enable broad and rapid adoption of the Power Platform, Microsoft decided to add a "seeded" Power Apps capability to all Microsoft 365 licenses. Thus instantly putting a version of this technology into millions of "citizens" hands. While IT could turn this "off", it was "on" by default. Microsoft knew that no IT Admin would ever enable it if it were the other way around. This led to many citizens seizing the opportunity to replace their shitty little Excel spreadsheets with a slightly less shitty app. Excel was the original Citizen tool, and many organizations have a ton of Excel spreadsheets floating around, which are now slowly but surely being replaced with shitty Power Apps built by people who not only don't know what they are doing but don't know that there is anything beyond those seeded capabilities. The Second Mistake Once IT figured out what was happening, many flipped the switch stopping this unchecked motion. In response to alleviate their concerns, Microsoft launched the "Center of Excellence" CoE. A tool that could wrangle this proliferation of shitty apps to be under IT's control again. CoE was a solution to a Microsoft-created problem. Now IT could see all of the shitty apps that had been built, including apps that never got used, multiple apps trying to solve the same problems, apps connecting to external sources, apps exposing internal confidential sources, and users having access to apps they shouldn't. There are few things more fun than watching the faces of fear of IT when a CoE lights up. Going back to the Fork I have written before about the poor citizen, oblivious to anything beyond the seeded capabilities, building some contorted solution only to months later learn there were better options. They unknowingly took a fork, unaware there was more than one fork to take. Their anger towards Microsoft is deserved. But they are not the only ones to take the wrong fork; Microsoft also did. Microsoft determined at the beginning that Joe NoNothing building his own app to solve his own problem was the best path. With rare exceptions, disaster ensued, or a least a lot of wasted time. Recognizing the obvious, that no organization wants a thousand shitty little apps, Microsoft took a pivot with an emphasis on a new idea, "Fusion Teams". Pair Joe NoNothing with Sally KnowsAlot and Bob ProDev... this is a "Fusion Team". Now instead of a shitty little app that does not do very much, you can expect a nice little app that does not do very much. Again, even the Fusion Team has taken the wrong fork. What Other Fork is There? There is another fork, but you can't see it from the seeded Power Apps. Had Microsoft called the seeded Power Apps something like Power Apps Lite, you might have been given a clue, but inexplicably, they chose not to. So you are left thinking that you have seen Power Apps and are justifiably unimpressed. But there is another "Power Apps" in the Power Platform. One that is much more capable and runs on top of a relational database called Dataverse instead of a SharePoint list or Excel spreadsheet. Why did you not know about this? Why would you? In the time you have been struggling to create a Canvas app, you could have built an entire, bulletproof solution to your problem. A solution that could be easily extended also to solve related problems. What's the Catch? Ok, you got me; the catch is that the "real" Power Platform is not included with your Microsoft 365 license. It will add either $5 or $20 to your monthly cost per app user. Still pretty cheap to actually "solve" a problem rather than just canvas over it with shit. The Fork Microsoft Should Have Created I am sure some inside of Microsoft would agree that mistakes were made.  Had they forgone the Citizen path and instead emphasized the Rapid Development low-code Power Platform as a way to solve mission-critical business challenges at a much lower cost than ever before in history, we would all be in a different place today.  Fusion Teams was the one bright spot in this series of missteps. What about Citizens? Don't Citizens already have a job? Why are they wasting time pretending to be app developers? As an organization, your cost to have complex mission-critical applications built by professionals is a fraction of what it was only a few years ago. Seriously, drop a zero off of the end of what you previously paid! Do you really need to reduce those cost savings even further by having Sally build some shitty app on her own? Some of you reading this are already sitting on a pile of shitty apps and can see that the "savings" were never real. So What is the Power Platform... Really? I'm glad you finally asked! The Power Platform is a suite of capabilities, including Apps, Automation, ChatBots, Webpages, and AI. Individually, each component is pretty cool, but when combined, there are few business challenges that cannot be solved. Forget about your shitty little "Time Off" app. I am talking about enterprise-grade; run your entire organization level stuff. That $5-$20 is starting to sound pretty cheap now, isn't it? Why hasn't anybody told you about this? It's because of that $5-$20 thing. Microsoft and most partners would actually prefer that you buy their first-party business applications for a buttload more money. If word got out that instead of customizing Dynamics 365 Sales @ $95+/user, you could spend the same amount customizing on the Power Platform and end up with the same thing at a fraction of the cost... well, that would not be good for those who sell the $95+ apps. Prove It! Ok, here are some examples of some of our clients. An NFT company that sold $90 million worth of NFT tokens on its first day manages the entire process on the Power Platform with integration directly to the blockchain. A Solar contractor runs their entire end-to-end business, from web prospects to permitting to construction and long-term maintenance agreements on the Power Platform. An Insurance Brokerage generates and tracks thousands of quotes daily on the Power Platform. A Mega-Church manages hundreds of monthly events, including event creation, promotion, and kiosk-based check-in for thousands of constituents on the Power Platform. An Opportunistic Investment firm created an in-house deep financial research solution on the Power Platform. A Petroleum Distributor and Convenience store operator with thousands of locations runs their organization on the Power Platform.  Still think the Power Platform is about shitty little apps built by Joe NoNothing?

When Microsoft introduced the Power Platform as a "Citizen-Friendly" set of tools for non-technical business users to create apps to solve business challenges, it seemed a worthy endeavor. Well, enough time has passed to assess the outcome. Those who jumped in with both feet now have a mountain of shitty little apps. Those who watched from the sidelines decided, "We don't need that!" So is that the end of the tale? Let's see. The First Mistake To enable broad and rapid adoption of the Power Platform, Microsoft decided to add a "seeded" Power Apps capability to all Microsoft 365 licenses. Thus instantly putting a version of this technology into millions of "citizens" hands. While IT could turn this "off", it was "on" by default. Microsoft knew that no IT Admin would ever enable it if it were the other way around. This led to many citizens seizing the opportunity to replace their shitty little Excel spreadsheets with a slightly less shitty app. Excel was the original Citizen tool, and many organizations have a ton of Excel spreadsheets floating around, which are now slowly but surely being replaced with shitty Power Apps built by people who not only don't know what they are doing but don't know that there is anything beyond those seeded capabilities. The Second Mistake Once IT figured out what was happening, many flipped the switch stopping this unchecked motion. In response to alleviate their concerns, Microsoft launched the "Center of Excellence" CoE. A tool that could wrangle this proliferation of shitty apps to be under IT's control again. CoE was a solution to a Microsoft-created problem. Now IT could see all of the shitty apps that had been built, including apps that never got used, multiple apps trying to solve the same problems, apps connecting to external sources, apps exposing internal confidential sources, and users having access to apps they shouldn't. There are few things more fun than watching the faces of fear of IT when a CoE lights up. Going back to the Fork I have written before about the poor citizen, oblivious to anything beyond the seeded capabilities, building some contorted solution only to months later learn there were better options. They unknowingly took a fork, unaware there was more than one fork to take. Their anger towards Microsoft is deserved. But they are not the only ones to take the wrong fork; Microsoft also did. Microsoft determined at the beginning that Joe NoNothing building his own app to solve his own problem was the best path. With rare exceptions, disaster ensued, or a least a lot of wasted time. Recognizing the obvious, that no organization wants a thousand shitty little apps, Microsoft took a pivot with an emphasis on a new idea, "Fusion Teams". Pair Joe NoNothing with Sally KnowsAlot and Bob ProDev... this is a "Fusion Team". Now instead of a shitty little app that does not do very much, you can expect a nice little app that does not do very much. Again, even the Fusion Team has taken the wrong fork. What Other Fork is There? There is another fork, but you can't see it from the seeded Power Apps. Had Microsoft called the seeded Power Apps something like Power Apps Lite, you might have been given a clue, but inexplicably, they chose not to. So you are left thinking that you have seen Power Apps and are justifiably unimpressed. But there is another "Power Apps" in the Power Platform. One that is much more capable and runs on top of a relational database called Dataverse instead of a SharePoint list or Excel spreadsheet. Why did you not know about this? Why would you? In the time you have been struggling to create a Canvas app, you could have built an entire, bulletproof solution to your problem. A solution that could be easily extended also to solve related problems. What's the Catch? Ok, you got me; the catch is that the "real" Power Platform is not included with your Microsoft 365 license. It will add either $5 or $20 to your monthly cost per app user. Still pretty cheap to actually "solve" a problem rather than just canvas over it with shit. The Fork Microsoft Should Have Created I am sure some inside of Microsoft would agree that mistakes were made.  Had they forgone the Citizen path and instead emphasized the Rapid Development low-code Power Platform as a way to solve mission-critical business challenges at a much lower cost than ever before in history, we would all be in a different place today.  Fusion Teams was the one bright spot in this series of missteps. What about Citizens? Don't Citizens already have a job? Why are they wasting time pretending to be app developers? As an organization, your cost to have complex mission-critical applications built by professionals is a fraction of what it was only a few years ago. Seriously, drop a zero off of the end of what you previously paid! Do you really need to reduce those cost savings even further by having Sally build some shitty app on her own? Some of you reading this are already sitting on a pile of shitty apps and can see that the "savings" were never real. So What is the Power Platform... Really? I'm glad you finally asked! The Power Platform is a suite of capabilities, including Apps, Automation, ChatBots, Webpages, and AI. Individually, each component is pretty cool, but when combined, there are few business challenges that cannot be solved. Forget about your shitty little "Time Off" app. I am talking about enterprise-grade; run your entire organization level stuff. That $5-$20 is starting to sound pretty cheap now, isn't it? Why hasn't anybody told you about this? It's because of that $5-$20 thing. Microsoft and most partners would actually prefer that you buy their first-party business applications for a buttload more money. If word got out that instead of customizing Dynamics 365 Sales @ $95+/user, you could spend the same amount customizing on the Power Platform and end up with the same thing at a fraction of the cost... well, that would not be good for those who sell the $95+ apps. Prove It! Ok, here are some examples of some of our clients. <ul><li>An NFT company that sold $90 million worth of NFT tokens on its first day manages the entire process on the Power Platform with integration directly to the blockchain.</li> <li>A Solar contractor runs their entire end-to-end business, from web prospects to permitting to construction and long-term maintenance agreements on the Power Platform.</li> <li>An Insurance Brokerage generates and tracks thousands of quotes daily on the Power Platform.</li> <li>A Mega-Church manages hundreds of monthly events, including event creation, promotion, and kiosk-based check-in for thousands of constituents on the Power Platform.</li> <li>An Opportunistic Investment firm created an in-house deep financial research solution on the Power Platform.</li> <li>A Petroleum Distributor and Convenience store operator with thousands of locations runs their organization on the Power Platform.</li> </ul> Still think the Power Platform is about shitty little apps built by Joe NoNothing?

A Mountain of Shitty Little Apps

Microsoft is Infected with AI as Copilots Consume all of the Oxygen

Steve has a  4th chat with charles

Steve has a Chat with Vahe Torossian

Welcome to the ”Steve reads his posts podcast”. For those of you who are too busy, or too lazy, to actually read my posts, I have taken on the huge effort of reading them to you. Enjoy.

Steve talks with leaders from industry and adds his his experience to provide a real perspective on what’s upcoming in the industry. I never miss an episode.

Thoughtful and Honest

Steve reads his Blog

Charles Lamanna

Steve has another chat with Charles Lamanna

I know... this is out of left field right? Me doing a review of a Power Platform solution. But I know the team behind it, and I thought hmm... maybe this could be an angle for some new blog content. So, what the hell! BTW, I am not being compensated for this, nor did they offer... cheap bastards. What's wrong with sales today? Sales has always been a black box. Great sellers have their secrets, but would rather not share them. Bad sellers just show up and check boxes until somebody finally notices they did not sell anything and fires them. Most sellers fall somewhere in-between. Obviously, we would like to elevate their skills to the level of the Great sellers; maybe send them to training, etc. But most of the great sellers I know, never went through any training, they were simply born with a gift. Everybody seems to think they are lucky... but they make their own luck; it's part of their gift. In your sales team, hopefully you have some Great sellers, hopefully you keep your roster lean on bad sellers, which means the bulk of your team are "average". Over time, some of those average sellers will blossom, but most will not, and those are the largest part of your sales force. You will never turn them into Great sellers, so you need to figure how to get the most you can out of them, the way they are. Average Sellers Average sellers know they are average. They can see the Great sellers and wish they had their gifts... and job security. They know they are better than the bad sellers, who may be able to hide in plain sight from management for a while, but all the other sellers know exactly who the bad ones are. Eventually all bad sellers get the boot. Once than happens, the lowest ranking average seller is now at the bottom... and possibly slipping. Average sellers are under the most pressure. And pressure usually leads to bad sales motions. Bad Motions What is the worst bad sales motion out of all of them? Desperation. This has killed more deals, and turned more average sellers into bad ones than anything else. Desperation to close a deal, make quota, stay off the bottom... and all right now! There is no time to waste. "Gimme a hot lead and I'm gonna call them right now and make them buy!" They jump on the phone, pressure the customer and hear something like, "I don't know if I want your product/service or not, but I know I don't want it right now",  "Ok, fuck that guy, I never look back, gimme another one."  Wait, did he just say "I never look back"? CRM as a "Look Back" Machine CRM was born out of the realization that most deals don't close on the first phone call. There are very few businesses left that can survive on the "One Call Close" strategy. Society is much more skeptical today, than in those good old days. So this means you are going to have to make contact more than once to close any deals, and for some things it may require many touches, over an extended period of time. This is what CRM originally tried to solve for, a place to store and track all of this information until we could finally close or lose a deal. Of course it is all well and good to have a repository of your customer history to draw upon, providing you actually go back and draw upon it, instead of focusing all of your energy on new ones. The Watering Can Most sellers suffer from the watering can dilemma. They are watering all of their seeds, consistently and evenly, until one sprouts... then they dump the entire remainder of the can of water on that one. While they are desperately trying to get this hopeful sprout to bloom, all the other seeds wither and die. Water in this analogy is of course, the seller's time. The key is to create more of that, but time is finite... or is it? Is Time Finite? Yes, of course it is, that's a stupid question to even ask. So instead, let's talk about cloning yourself because that is possible right? Well, sorta. In our business we call the closest thing to cloning, "Automation". How does Automation clone a seller? By automatically performing routine sales tasks in the background, on behalf of the seller. How many more hours can this add to the Seller's day, I guess it depends on how much of their work can be automated. Automation Automation is not a new term in our industry. Microsoft has made huge strides in the automation space, as have others. To be sure, the toolbox is there, but the machines are not, they need to be assembled. Microsoft has given us a lot capabilities to automate routine tasks, and for sure, if you spent enough effort you could automate some of your Sellers' time. It would certainly be handy if there was a solution out there that was designed to do exactly that. The Solution Okay, I know this was going to be a review of a solution, and one that I think can tackle many of the items I discussed here, but to be honest, I don't have time to get to it in this post. This is not an intentional "Cliffhanger", I just got some other shit to do right now. I come back to this shortly.

I know... this is out of left field right? Me doing a review of a Power Platform solution. But I know the team behind it, and I thought hmm... maybe this could be an angle for some new blog content. So, what the hell! BTW, I am not being compensated for this, nor did they offer... cheap bastards. What's wrong with sales today? Sales has always been a black box. Great sellers have their secrets, but would rather not share them. Bad sellers just show up and check boxes until somebody finally notices they did not sell anything and fires them. Most sellers fall somewhere in-between. Obviously, we would like to elevate their skills to the level of the Great sellers; maybe send them to training, etc. But most of the great sellers I know, never went through any training, they were simply born with a gift. Everybody seems to think they are lucky... but they make their own luck; it's part of their gift. In your sales team, hopefully you have some Great sellers, hopefully you keep your roster lean on bad sellers, which means the bulk of your team are "average". Over time, some of those average sellers will blossom, but most will not, and those are the largest part of your sales force. You will never turn them into Great sellers, so you need to figure how to get the most you can out of them, the way they are. Average Sellers Average sellers know they are average. They can see the Great sellers and wish they had their gifts... and job security. They know they are better than the bad sellers, who may be able to hide in plain sight from management for a while, but all the other sellers know exactly who the bad ones are. Eventually all bad sellers get the boot. Once than happens, the lowest ranking average seller is now at the bottom... and possibly slipping. Average sellers are under the most pressure. And pressure usually leads to bad sales motions. Bad Motions What is the worst bad sales motion out of all of them? Desperation. This has killed more deals, and turned more average sellers into bad ones than anything else. Desperation to close a deal, make quota, stay off the bottom... and all right now! There is no time to waste. "Gimme a hot lead and I'm gonna call them right now and make them buy!" They jump on the phone, pressure the customer and hear something like, "I don't know if I want your product/service or not, but I know I don't want it right now",  "Ok, fuck that guy, I never look back, gimme another one."  Wait, did he just say "I never look back"? CRM as a "Look Back" Machine CRM was born out of the realization that most deals don't close on the first phone call. There are very few businesses left that can survive on the "One Call Close" strategy. Society is much more skeptical today, than in those good old days. So this means you are going to have to make contact more than once to close any deals, and for some things it may require many touches, over an extended period of time. This is what CRM originally tried to solve for, a place to store and track all of this information until we could finally close or lose a deal. Of course it is all well and good to have a repository of your customer history to draw upon, providing you actually go back and draw upon it, instead of focusing all of your energy on new ones. The Watering Can Most sellers suffer from the watering can dilemma. They are watering all of their seeds, consistently and evenly, until one sprouts... then they dump the entire remainder of the can of water on that one. While they are desperately trying to get this hopeful sprout to bloom, all the other seeds wither and die. Water in this analogy is of course, the seller's time. The key is to create more of that, but time is finite... or is it? Is Time Finite? Yes, of course it is, that's a stupid question to even ask. So instead, let's talk about cloning yourself because that is possible right? Well, sorta. In our business we call the closest thing to cloning, "Automation". How does Automation clone a seller? By automatically performing routine sales tasks in the background, on behalf of the seller. How many more hours can this add to the Seller's day, I guess it depends on how much of their work can be automated. Automation Automation is not a new term in our industry. Microsoft has made huge strides in the automation space, as have others. To be sure, the toolbox is there, but the machines are not, they need to be assembled. Microsoft has given us a lot capabilities to automate routine tasks, and for sure, if you spent enough effort you could automate some of your Sellers' time. It would certainly be handy if there was a solution out there that was designed to do exactly that. The Solution Okay, I know this was going to be a review of a solution, and one that I think can tackle many of the items I discussed here, but to be honest, I don't have time to get to it in this post. This is not an intentional "Cliffhanger", I just got some other shit to do right now. I come back to this shortly.

Steve Reviews a Solution

It seems clear to me from listening to people on social media, comments on my posts, and generally having an ear to the ground, that too many people, including many who should not be, are still confused about PowerApps... and wouldn't they be? A Quick Quiz. What is a PowerApp?  A Mobile Application you built on top of SharePoint  A Mobile Application you built on top of the common data service  A Mobile Application you built on top of Dynamics 365  A Custom Application you built in Dynamics 365  A Custom Application you built on the Common Data Service  A Custom Application you embedded into a Dynamics 365 Form  Something Else If you answered "all of the above", you get a gold star, but you're no closer to clarity. PowerApps Camps There are three primary camps for PowerApps as I see it. There are campers that come from the productivity side of the lake, where Office 365 and SharePoint live. We also have campers from the Dynamics 365 side of the lake, busily extending the Dynamics 365 applications with their own canvas and model-driven apps. Lastly, we have the Platform side of this apparently three-sided lake, using both canvas and model-driven paths to build apps from scratch on CDS. While these campers can hear the sounds of other campers across the lake, they seem to have little understanding of what the other campers are doing over there, even though they are each called "Camp PowerApp". I want to go a little deeper into the two of these camps that are part of Business Applications that I am familiar with. Someone else can speak to those productivity campers. A Custom Application I think the biggest confusion, for those of us in one or both of the Business Applications camps, are the distinction between items 4 and 5 from the quiz. "Building custom applications in Dynamics 365" vs. "Building custom applications directly on the Common Data Service". But Steve, aren't those both on CDS? Yes they are, but they got there via two distinct pathways, from opposite sides of the lake. They are not the same thing and different rules and licenses apply to each. Dynamics 365 Campers Let's face it, Model-Driven PowerApps are just XrM renamed. Everything you ever did with XrM in the past is now called PowerApps. Along the way a few more things happened, like the separation of the first-party apps from each other, and the introduction of the ability to make new role specific "PowerApps" by mashing up parts of the other first-party apps into your own concoction. Dynamics 365 brings all of the power and advanced capabilities you could want, including A.I., MR, and all the other acronyms. This is the deep end of the pool! The separation of the Apps from the underlying platform was of less importance to this camp, but actually spawned a whole new camp. Platform Campers These campers could care less about Dynamics 365. They are building their own custom apps directly on the same platform that sits under Dynamics 365. Are they masochists or anarchists? I guess a little of both. The "Platform" is actually the old XrM framework sitting on top of a database that is now called the Common Data Service (CDS). It is but a hollow shell of Dynamics 365, containing very little in the way of usable items, yet everything that is required to build as powerful an application as Dynamics 365. This is the deep end of the pool. Deep Ends If you were reading/listening closely, you heard me refer to both of these camps as the "Deep ends of the Pool". Extending the complex out-of-the-box functionality in the first-party apps requires significant skill and knowledge. But building functional, powerful and comprehensive applications on the platform also requires significant skill and knowledge. The shallow water in the middle is where "Citizen Developers" swim, creating their cute little widgets. Fuzzy Rules When it comes to the rules, there is clear separation, but for many it still seems fuzzy. Some common examples: "You can't use a Restricted Entity in a PowerApp!" This is incorrect, a clearer way to phrase this would be "If you are building a PowerApp on top of Dynamics 365, and you include in your PowerApp a restricted entity (for example the Incident entity), the user of your PowerApp will require a license that includes that entity (i.e Dynamics 365 for Customer Service)." This does not mean that you cannot build the app! Also, Restricted Entities have nothing to do with Platform Campers. There are no restricted entities in CDS without Dynamics 365. Similarly, with Team Member and it's restrictions. Team Member licenses are a type of Dynamics 365 license. Again, Team Member has nothing to do with the Platform Campers, only the Dynamics 365 campers need to be concerned with Team Member. "You cannot replicate the functionality of the first-party apps in PowerApps." This was previously true, and relevant only to the Platform Campers, but is no longer the case. For Microsoft to succeed with their Platform aspirations, it was clear they needed to eliminate any artificial restrictions, and they did. Fuzzy Licensing The recent announcement about the Platform License changes that I discussed in  my last post, referenced  this blog post by Charles Lamanna. Note that this post, and these licenses refer to "standalone" (aka Platform), and have nothing to do with Dynamics 365. This post and these licenses are for the Platform Campers only. You cannot use a Per App License with Dynamics 365, Dynamics 365 has it's own licenses. Similarly, the retirement of the bundled Plan licenses for Dynamics 365 has nothing to do with Platform Campers. A Fuzzy Line The line between these two camps is very clear, yet at the same time, not very obvious. There is way too much "assuming" and lazy interpreting going on, leading to way too much misinformation, leading to way too much confusion. One way to help would be, if you don't know that what you are saying is correct... don't spit it out to the world as a fact. There is an old saying, "Better to be silent and thought a fool, than to speak up and remove all doubt".

It seems clear to me from listening to people on social media, comments on my posts, and generally having an ear to the ground, that too many people, including many who should not be, are still confused about PowerApps... and wouldn't they be? A Quick Quiz. What is a PowerApp? <ol><li> A Mobile Application you built on top of SharePoint</li> <li> A Mobile Application you built on top of the common data service</li> <li> A Mobile Application you built on top of Dynamics 365</li> <li> A Custom Application you built in Dynamics 365</li> <li> A Custom Application you built on the Common Data Service</li> <li> A Custom Application you embedded into a Dynamics 365 Form</li> <li> Something Else</li> </ol>If you answered "all of the above", you get a gold star, but you're no closer to clarity. PowerApps Camps There are three primary camps for PowerApps as I see it. There are campers that come from the productivity side of the lake, where Office 365 and SharePoint live. We also have campers from the Dynamics 365 side of the lake, busily extending the Dynamics 365 applications with their own canvas and model-driven apps. Lastly, we have the Platform side of this apparently three-sided lake, using both canvas and model-driven paths to build apps from scratch on CDS. While these campers can hear the sounds of other campers across the lake, they seem to have little understanding of what the other campers are doing over there, even though they are each called "Camp PowerApp". I want to go a little deeper into the two of these camps that are part of Business Applications that I am familiar with. Someone else can speak to those productivity campers. A Custom Application I think the biggest confusion, for those of us in one or both of the Business Applications camps, are the distinction between items 4 and 5 from the quiz. "Building custom applications in Dynamics 365" vs. "Building custom applications directly on the Common Data Service". But Steve, aren't those both on CDS? Yes they are, but they got there via two distinct pathways, from opposite sides of the lake. They are not the same thing and different rules and licenses apply to each. Dynamics 365 Campers Let's face it, Model-Driven PowerApps are just XrM renamed. Everything you ever did with XrM in the past is now called PowerApps. Along the way a few more things happened, like the separation of the first-party apps from each other, and the introduction of the ability to make new role specific "PowerApps" by mashing up parts of the other first-party apps into your own concoction. Dynamics 365 brings all of the power and advanced capabilities you could want, including A.I., MR, and all the other acronyms. This is the deep end of the pool! The separation of the Apps from the underlying platform was of less importance to this camp, but actually spawned a whole new camp. Platform Campers These campers could care less about Dynamics 365. They are building their own custom apps directly on the same platform that sits under Dynamics 365. Are they masochists or anarchists? I guess a little of both. The "Platform" is actually the old XrM framework sitting on top of a database that is now called the Common Data Service (CDS). It is but a hollow shell of Dynamics 365, containing very little in the way of usable items, yet everything that is required to build as powerful an application as Dynamics 365. This is the deep end of the pool. Deep Ends If you were reading/listening closely, you heard me refer to both of these camps as the "Deep ends of the Pool". Extending the complex out-of-the-box functionality in the first-party apps requires significant skill and knowledge. But building functional, powerful and comprehensive applications on the platform also requires significant skill and knowledge. The shallow water in the middle is where "Citizen Developers" swim, creating their cute little widgets. Fuzzy Rules When it comes to the rules, there is clear separation, but for many it still seems fuzzy. Some common examples: "You can't use a Restricted Entity in a PowerApp!" This is incorrect, a clearer way to phrase this would be "If you are building a PowerApp on top of Dynamics 365, and you include in your PowerApp a restricted entity (for example the Incident entity), the user of your PowerApp will require a license that includes that entity (i.e Dynamics 365 for Customer Service)." This does not mean that you cannot build the app! Also, Restricted Entities have nothing to do with Platform Campers. There are no restricted entities in CDS without Dynamics 365. Similarly, with Team Member and it's restrictions. Team Member licenses are a type of Dynamics 365 license. Again, Team Member has nothing to do with the Platform Campers, only the Dynamics 365 campers need to be concerned with Team Member. "You cannot replicate the functionality of the first-party apps in PowerApps." This was previously true, and relevant only to the Platform Campers, but is no longer the case. For Microsoft to succeed with their Platform aspirations, it was clear they needed to eliminate any artificial restrictions, and they did. Fuzzy Licensing The recent announcement about the Platform License changes that I discussed in <a href="https://stevemordue.com/reduce-your-dynamics-365-license-costs-by-92-percent/" rel="nofollow" target="_blank"> my last post</a>, referenced <a href="https://powerapps.microsoft.com/en-us/blog/new-licensing-options-for-powerapps-and-flow/" rel="nofollow" target="_blank"> this blog post</a> by Charles Lamanna. Note that this post, and these licenses refer to "standalone" (aka Platform), and have nothing to do with Dynamics 365. This post and these licenses are for the Platform Campers only. You cannot use a Per App License with Dynamics 365, Dynamics 365 has it's own licenses. Similarly, the retirement of the bundled Plan licenses for Dynamics 365 has nothing to do with Platform Campers. A Fuzzy Line The line between these two camps is very clear, yet at the same time, not very obvious. There is way too much "assuming" and lazy interpreting going on, leading to way too much misinformation, leading to way too much confusion. One way to help would be, if you don't know that what you are saying is correct... don't spit it out to the world as a fact. There is an old saying, "Better to be silent and thought a fool, than to speak up and remove all doubt".

PowerApps vs. PowerApps

In this episode of "Steve has a Chat", I catch up again with Steven Guggenheimer "Guggs" to get the latest on the ISV Connect program. I also had a few surprises for him.  Enjoy! BTW, don't forget, Mark Smith (@nz365guy) and I do PowerUpLive every Wednesay at 4PM EST, click here to be alerted, and  here's a link to the replays!

In this episode of "Steve has a Chat", I catch up again with Steven Guggenheimer "Guggs" to get the latest on the ISV Connect program. I also had a few surprises for him.  Enjoy! BTW, don't forget, Mark Smith (@nz365guy) and I do PowerUpLive every Wednesay at 4PM EST, <a href="https://www.youtube.com/watch?v=g_BOpfgFzxY" rel="nofollow" target="_blank">click here</a> to be alerted, and <a href="https://www.youtube.com/playlist?list=PLzf0yupPbVkoTxWhWJ7QraqVV4oBkgeX-" rel="nofollow" target="_blank"> here's a link</a> to the replays!

Steve has another chat with Guggs

I hinted in my  last post about possibly being able to reduce your Dynamics 365 license costs by up to 92%. I may have been a little too coy, so I titled this post more overtly. Was I just bullshitting you? Well... not all of you. It Depends Follow me here as there are a lot of "ifs", but many organizations will meet them. IF, you are paying $115/user/month for the Dynamics 365 Customer Engagement Plan Licenses. IF, you are only using the basic out-of-the-box features. IF, the advanced capabilities you are using were all custom built. IF, any third-party solutions are compatible, or you can do without them. IF, your users primarily work in a single application, ie. "Sales" or "Service" but not both. IF, you are not using things like "Relationship Insights," or any of the A.I., or other advanced features.  Depending on your answers to the above "Ifs", you may well be able to move to the upcoming  PowerApps Per App Plan model for $10/user/month. My math says that from $115, down to $10, is a 92% savings. Is this even realistic? How is this possible? The same way it would be possible for certain people to get by fine with Notepad instead of Word... unused features. As a partner who has been involved with hundreds of deployments, I can safely say that the number of customers who use every feature of the first-party apps they are paying for is... zero. I feel quite confident that number does not change for customers using even half of the available features. Of course no two customers are alike, and the mix of features they actually do use varies significantly, but they are all paying for all of the features. Obviously my 92% scenario assumes you are currently paying the highest price ($115), and that you could ultimately be satisfied with a single PowerApp at $10. Not everyone will, and many are also paying less than $115. Free Money? Not exactly. It is not quite as easy as buying a $10 license and cancelling the others. Even if you meet the parameters I outlined, or are willing to give up a few things to do so, there is still some refactoring and a migration to be done. This too will vary significantly from customer to customer. If you are able to save some money, or a lot of money, you will have to spend some money to get there, so the ROI may be deferred. For example, let's say you fit the profile perfectly. You have 150 users and are paying (let's be more conservative here), $95/user/month for the Enterprise Sales App. Assuming your actual needs could be met with a custom built PowerApp, you could potentially save $12,750/month. Of course you need to have the PowerApp built which will cost you something (you may want to explore our  RapidStartCRM accelerators in AppSource, and RapidLABS services for a fast and low-cost way to do this). I don't want this to sound like a slam dunk, for some customers the cost to do something like this may actually exceed all of the development costs they have invested so far. There are a lot of factors in this equation. Power "less" By now you may be thinking, this sounds great... for an organization with simple needs. What you will forgo in this Per App Plan are the "pre-built" capabilities of the First-Party applications. But... they are PowerApps too. With enough development funds and time, you could practically replicate them entirely, but that would be silly. Instead, you would just build exactly what you need, no more and no less. We have a customer with thousands of users, where everything but Account and Contact was custom built (Account and Contact already exist in PowerApps). In their case, the customization solution (which includes a single app) could be installed directly on a CDS instance with no changes at all, then just migrate their data, and they would be in the exact same place. There are some massive deployments out there, that with little effort could go this route. In fact, for many of my customers, the Per App Plan offers more than what they are even utilizing today. An "App" in the Per App Plan can include a Web App (aka Model-Drive App) like most customers are already using today, but that "App" can also include a Mobile App (aka Canvas App), which less of them are using, and a Web Portal which very few of them are using. The Outlook App is also available and works the same way. Is Microsoft Okay with this? I would guess that depends on how many of their existing customers, walk through this door that Microsoft created to gain new customers. In my example above, trading $14,250/month for $1,500/month may be an unintended consequence of Microsoft's new model. Make no mistake, this will not be a viable option for everybody. Again, the first-party apps bring a plethora of advanced capabilities that many customers depend on, that would not be practical to rebuild. But it will be interesting to see just how many, are using enough of the out-of-the-box advanced features. The difference in cost sets a pretty high bar for Microsoft's first-party apps. Microsoft will need about 10 net new PowerApps Per App users to make up for each D365 Plan user who makes this switch, but clearly their expectation is that the PowerApps Per App Plan model will blow up to a point where they don't really care. And why wouldn't it? This is more potential business application "power" for $10 than any other company even comes close to, and at $10 moves it into the category of: "Affordable to Anyone". Is Dynamics 365 Dead? Once again, Mark Smith's (@nz365guy) looming prediction that "Dynamics 365 is Dead", shows more life. While there will continue to be a place for Dynamics 365 Customer Engagement Apps for the foreseeable future, it's no longer the "take it or leave it" product it once was. PowerApps has created a highly viable alternative for many customers... new or existing. If you're interested in exploring this, Forceworks is offering a free Assessment, to help you see if you can take advantage.

I hinted in my <a href="https://stevemordue.com/updating-to-unified-interface-powerapp-it/" rel="nofollow" target="_blank"> last post</a> about possibly being able to reduce your Dynamics 365 license costs by up to 92%. I may have been a little too coy, so I titled this post more overtly. Was I just bullshitting you? Well... not all of you. It Depends Follow me here as there are a lot of "ifs", but many organizations will meet them. <ul><li>IF, you are paying $115/user/month for the Dynamics 365 Customer Engagement Plan Licenses.</li> <li>IF, you are only using the basic out-of-the-box features.</li> <li>IF, the advanced capabilities you are using were all custom built.</li> <li>IF, any third-party solutions are compatible, or you can do without them.</li> <li>IF, your users primarily work in a single application, ie. "Sales" or "Service" but not both.</li> <li>IF, you are not using things like "Relationship Insights," or any of the A.I., or other advanced features.</li> </ul> Depending on your answers to the above "Ifs", you may well be able to move to the upcoming <a href="https://powerapps.microsoft.com/en-us/blog/new-licensing-options-for-powerapps-and-flow/" rel="nofollow" target="_blank"> PowerApps Per App Plan</a> model for $10/user/month. My math says that from $115, down to $10, is a 92% savings. Is this even realistic? How is this possible? The same way it would be possible for certain people to get by fine with Notepad instead of Word... unused features. As a partner who has been involved with hundreds of deployments, I can safely say that the number of customers who use every feature of the first-party apps they are paying for is... zero. I feel quite confident that number does not change for customers using even half of the available features. Of course no two customers are alike, and the mix of features they actually do use varies significantly, but they are all paying for all of the features. Obviously my 92% scenario assumes you are currently paying the highest price ($115), and that you could ultimately be satisfied with a single PowerApp at $10. Not everyone will, and many are also paying less than $115. Free Money? Not exactly. It is not quite as easy as buying a $10 license and cancelling the others. Even if you meet the parameters I outlined, or are willing to give up a few things to do so, there is still some refactoring and a migration to be done. This too will vary significantly from customer to customer. If you are able to save some money, or a lot of money, you will have to spend some money to get there, so the ROI may be deferred. For example, let's say you fit the profile perfectly. You have 150 users and are paying (let's be more conservative here), $95/user/month for the Enterprise Sales App. Assuming your actual needs could be met with a custom built PowerApp, you could potentially save $12,750/month. Of course you need to have the PowerApp built which will cost you something (you may want to explore our <a href="https://appsource.microsoft.com/en-us/marketplace/apps?search=rapidstartcrm" rel="nofollow" target="_blank"> RapidStartCRM</a> accelerators in AppSource, and <a href="https://account.forceworks.com/product/rapidlabs-development/" rel="nofollow" target="_blank">RapidLABS</a> services for a fast and low-cost way to do this). I don't want this to sound like a slam dunk, for some customers the cost to do something like this may actually exceed all of the development costs they have invested so far. There are a lot of factors in this equation. Power "less" By now you may be thinking, this sounds great... for an organization with simple needs. What you will forgo in this Per App Plan are the "pre-built" capabilities of the First-Party applications. But... they are PowerApps too. With enough development funds and time, you could practically replicate them entirely, but that would be silly. Instead, you would just build exactly what you need, no more and no less. We have a customer with thousands of users, where everything but Account and Contact was custom built (Account and Contact already exist in PowerApps). In their case, the customization solution (which includes a single app) could be installed directly on a CDS instance with no changes at all, then just migrate their data, and they would be in the exact same place. There are some massive deployments out there, that with little effort could go this route. In fact, for many of my customers, the Per App Plan offers more than what they are even utilizing today. An "App" in the Per App Plan can include a Web App (aka Model-Drive App) like most customers are already using today, but that "App" can also include a Mobile App (aka Canvas App), which less of them are using, and a Web Portal which very few of them are using. The Outlook App is also available and works the same way. Is Microsoft Okay with this? I would guess that depends on how many of their existing customers, walk through this door that Microsoft created to gain new customers. In my example above, trading $14,250/month for $1,500/month may be an unintended consequence of Microsoft's new model. Make no mistake, this will not be a viable option for everybody. Again, the first-party apps bring a plethora of advanced capabilities that many customers depend on, that would not be practical to rebuild. But it will be interesting to see just how many, are using enough of the out-of-the-box advanced features. The difference in cost sets a pretty high bar for Microsoft's first-party apps. Microsoft will need about 10 net new PowerApps Per App users to make up for each D365 Plan user who makes this switch, but clearly their expectation is that the PowerApps Per App Plan model will blow up to a point where they don't really care. And why wouldn't it? This is more potential business application "power" for $10 than any other company even comes close to, and at $10 moves it into the category of: "Affordable to Anyone". Is Dynamics 365 Dead? Once again, Mark Smith's (<a href="https://twitter.com/nz365guy" rel="nofollow" target="_blank">@nz365guy</a>) looming prediction that "Dynamics 365 is Dead", shows more life. While there will continue to be a place for Dynamics 365 Customer Engagement Apps for the foreseeable future, it's no longer the "take it or leave it" product it once was. PowerApps has created a highly viable alternative for many customers... new or existing. If you're interested in exploring this, Forceworks is offering a <a href="https://forceworks.com/d365pa-assessment/" rel="nofollow" target="_blank">free Assessment</a>, to help you see if you can take advantage.

Reduce your Dynamics 365 License costs by 92%?

Mona Baset

Typically I am catching Microsoft leaders on my "Steve has a Chat" podcast, this time I thought I would try and pounce on an Enterprise Customer to get some candid feedback on PowerApps. Mona Baset, AVP of Information and Analytics Services for Atrium Health was game for a chat. Atrium Health is comprised of 40 hospitals and 900 locations in the Carolinas and Georgia. Some of the things Mona and I discussed, included the place for PowerApps in a large organization that is committed to Salesforce.com. It was quite interesting to hear how PowerApps is viewed from the customer side of the table. BTW, don't forget to tune into #PowerUpLive every Wednesday at 11AM EST, where Mark Smith (@nz365guy) and I discuss the latest news around all of Microsoft  Business Applications, subscribe here: https://www.youtube.com/nz365guy.

Typically I am catching Microsoft leaders on my "Steve has a Chat" podcast, this time I thought I would try and pounce on an Enterprise Customer to get some candid feedback on PowerApps. <a href="https://www.linkedin.com/in/monabaset/" rel="nofollow" target="_blank">Mona Baset</a>, AVP of Information and Analytics Services for <a href="https://atriumhealth.org/" rel="nofollow" target="_blank">Atrium Health</a> was game for a chat. Atrium Health is comprised of 40 hospitals and 900 locations in the Carolinas and Georgia. Some of the things Mona and I discussed, included the place for PowerApps in a large organization that is committed to <a href="http://Salesforce.com" rel="nofollow" target="_blank">Salesforce.com</a>. It was quite interesting to hear how PowerApps is viewed from the customer side of the table. BTW, don't forget to tune into #PowerUpLive every Wednesday at 11AM EST, where Mark Smith (<a href="https://twitter.com/nz365guy" rel="nofollow" target="_blank">@nz365guy</a>) and I discuss the latest news around all of Microsoft  Business Applications, subscribe here: <a href="https://www.youtube.com/nz365guy" rel="nofollow" target="_blank">https://www.youtube.com/nz365guy</a>.

Steve has a Chat with Mona Baset

The Dynamics 365 Web Client is going to be deprecated soon. If you have not transitioned to the Unified Interface, time is running out to be in control of that process for yourself. Maybe there is a reason to look at this "chore" as an "opportunity". Unified Interface The Unified Interface is awesome, a vast improvement over the previous Web Client. Yet a significant number of organizations are still using the Web Client. Microsoft needs you to get off your ass and move. In fact they recently created an Online Community dedicated to this single purpose. In my informal survey of customers who are still on the Web Client I am aware of the following three reasons: Obliviousness, Fear or Money. Obliviousness There are a reasonable number of customers who deployed Dynamics 365 without a partner. Many of them bought the licenses and then went underground on their own, disconnected from whatever may be happening on the surface. Many other customers were deployed by a non-Dynamics partner who likewise is not up-to-speed with changes in the product. There are also customers, as well as partners, who engaged offshore resources or freelancers, most of which are also out-of-the-loop of current information. So in addition to many other things this large customer group is unaware of, the looming deprecation of the Web Client they use every day, is yet another. Fear This group of customers is aware of changes coming to the platform, but lives in fear that their deployment, which they liken to a Rube Goldberg machine, will break if they dare touch it. This group will always wait until the very last minute, which is ironically the scariest and riskiest thing they could possibly do. Their fear is often a result of a lack of confidence in either their own, or their partner's knowledge and understanding of the platform. In other words, they're ignorant. Money Is there a free service that will update you to the Unified Interface? Not that I am aware of. Is it a simple project? That depends, for some users it could be, but for most it will require more effort. Is it frustrating that you subscribed to this product, paid some partner to help you initially configure and customize it for your needs, have been happily using it for a long time, and now out-of-the-blue you have no choice but to spend some money to keep using it? Yes, I would assume that is frustrating. More so if you have no budget for things like this. Opportunity Does this upcoming unavoidable "Effort/Expense" present a possible silver-lining opportunity for customers? Maybe. As a Partner, I often look at changes like this as a good reason to look at what a customer is doing today, vs. what they were doing when we first put this thing together. Hindsight is always 20:20. If we have to crack this thing open anyway, let's go ahead and address some of those issues we discovered after launch, that we never got around to taking care of. At least if the customer has to spend some money for a required change, they can get a little upside out of it. But is there even more upside potential today? PowerApps What if I told you, that while you were at it, you could potentially reduce your license costs by 92%! Is this even possible? You will have to wait for my next post to find out.

The Dynamics 365 Web Client is going to be deprecated soon. If you have not transitioned to the Unified Interface, time is running out to be in control of that process for yourself. Maybe there is a reason to look at this "chore" as an "opportunity". Unified Interface The Unified Interface is awesome, a vast improvement over the previous Web Client. Yet a significant number of organizations are still using the Web Client. Microsoft needs you to get off your ass and move. In fact they recently created an <a href="https://community.dynamics.com/365/unified-interface/" rel="nofollow" target="_blank">Online Community</a> dedicated to this single purpose. In my informal survey of customers who are still on the Web Client I am aware of the following three reasons: Obliviousness, Fear or Money. Obliviousness There are a reasonable number of customers who deployed Dynamics 365 without a partner. Many of them bought the licenses and then went underground on their own, disconnected from whatever may be happening on the surface. Many other customers were deployed by a non-Dynamics partner who likewise is not up-to-speed with changes in the product. There are also customers, as well as partners, who engaged offshore resources or freelancers, most of which are also out-of-the-loop of current information. So in addition to many other things this large customer group is unaware of, the looming deprecation of the Web Client they use every day, is yet another. Fear This group of customers is aware of changes coming to the platform, but lives in fear that their deployment, which they liken to a Rube Goldberg machine, will break if they dare touch it. This group will always wait until the very last minute, which is ironically the scariest and riskiest thing they could possibly do. Their fear is often a result of a lack of confidence in either their own, or their partner's knowledge and understanding of the platform. In other words, they're ignorant. Money Is there a free service that will update you to the Unified Interface? Not that I am aware of. Is it a simple project? That depends, for some users it could be, but for most it will require more effort. Is it frustrating that you subscribed to this product, paid some partner to help you initially configure and customize it for your needs, have been happily using it for a long time, and now out-of-the-blue you have no choice but to spend some money to keep using it? Yes, I would assume that is frustrating. More so if you have no budget for things like this. Opportunity Does this upcoming unavoidable "Effort/Expense" present a possible silver-lining opportunity for customers? Maybe. As a Partner, I often look at changes like this as a good reason to look at what a customer is doing today, vs. what they were doing when we first put this thing together. Hindsight is always 20:20. If we have to crack this thing open anyway, let's go ahead and address some of those issues we discovered after launch, that we never got around to taking care of. At least if the customer has to spend some money for a required change, they can get a little upside out of it. But is there even more upside potential today? PowerApps What if I told you, that while you were at it, you could potentially reduce your license costs by 92%! Is this even possible? You will have to wait for my next post to find out.

Updating to Unified Interface? PowerApp it!

Recently, our contact on a large multi-year customization effort for a customer left. The new person who came in seemed to be of a mind to change things up. What was a highly effective and collaborative effort, suddenly became a battle over every hour billed. I'm on the verge of kicking them to the curb, but...  Screwed by Nature There is an interesting anomaly in our business, that can ultimately lead to disaster; the seeds are planted as soon as you hire a Microsoft Partner. I don't think customers think about the end at the beginning. Why would they? They have no idea just how bound to that partner they will become over time. Houses of Cards You will ultimately be working with a person who is architecting your solution to meet your described requirements. Assuming they know what they are doing, they still have multiple ways to go about it. "Best Practices" is a bullshit term, don't get lured by it. While there are many ways to architect something wrong, there are also many ways to architect it right. It will boil down to that person's opinions based on their knowledge and past experiences. But even the most knowledgeable and experienced people will architect things differently from each other. They are all right! It's not intentional. Eventually, all complex deployments become houses of cards. It's just how it is. Removing any card. without knowing what it may be holding up, can crash everything down. This is why most partners being brought in to replace another, suggest starting many things over from scratch. It would just take too much time in forensics to figure out what the prior partner had done and why, ("What does this card do?"). This is regardless of whether it was done well or poorly. I'm sure some partner will jump on the comments and say they are smart enough to figure out anything. These are the ones that usually come back later and say "Upon further review, the last partner did not know what they were doing, and we need to start over"... convenient. Transition to Internal Team The big customization effort is complete! Let's have our own people take over from here. This is a natural and logical desire. But you better plan on keeping your partner around, and happy, because there will be issues and fires. There always are. They tend to pop up before you can even get clear of your partner. The bigger the deployment, the more dependent you are on the partner who built it, they are only ones who know where the skeletons are buried. The only bigger risk is having one of your employees build it. Citizens There is a lot of conversation today about "Citizen Developers". They will also build houses of cards, but will likely do it poorly, without the deep knowledge and experience, and then suddenly they leave your company. Admittedly, when we are called into these scenarios, starting over is often the only option. Updates All platforms go through continuous updates, Microsoft Business Applications included. These can not only bring new features, but occasionally can deprecate features you are using. As a customer with your own business concerns, you will likely not be up-to-speed on these, and will instead discover them one day when things stop working. That would be a fire, and you better have a brigade at the ready. Better yet, if you have maintained a good relationship with your partner, they will give you a heads up, and be there to make sure things continue to go smoothly. Universal This is not a Microsoft Business Applications phenomena, this is the same for all platforms that allow for broad customization. The same was true when we were Salesforce.com partners. It's also not new. The same was true for that Access Database solution Joe built for you ten years ago, and then he was hit by a bus and died. Damn Joe! Summary Eventually your partner will have you by your underwear band. Whether they give you a wedgie will have a lot to do with who they are, and how your have engaged with them. The cost of changing them will be very high, and last a very long time. Choose wisely.

Recently, our contact on a large multi-year customization effort for a customer left. The new person who came in seemed to be of a mind to change things up. What was a highly effective and collaborative effort, suddenly became a battle over every hour billed. I'm on the verge of kicking them to the curb, but... Screwed by Nature There is an interesting anomaly in our business, that can ultimately lead to disaster; the seeds are planted as soon as you hire a Microsoft Partner. I don't think customers think about the end at the beginning. Why would they? They have no idea just how bound to that partner they will become over time. Houses of Cards You will ultimately be working with a person who is architecting your solution to meet your described requirements. Assuming they know what they are doing, they still have multiple ways to go about it. "Best Practices" is a bullshit term, don't get lured by it. While there are many ways to architect something wrong, there are also many ways to architect it right. It will boil down to that person's opinions based on their knowledge and past experiences. But even the most knowledgeable and experienced people will architect things differently from each other. They are all right! It's not intentional. Eventually, all complex deployments become houses of cards. It's just how it is. Removing any card. without knowing what it may be holding up, can crash everything down. This is why most partners being brought in to replace another, suggest starting many things over from scratch. It would just take too much time in forensics to figure out what the prior partner had done and why, ("What does this card do?"). This is regardless of whether it was done well or poorly. I'm sure some partner will jump on the comments and say they are smart enough to figure out anything. These are the ones that usually come back later and say "Upon further review, the last partner did not know what they were doing, and we need to start over"... convenient. Transition to Internal Team The big customization effort is complete! Let's have our own people take over from here. This is a natural and logical desire. But you better plan on keeping your partner around, and happy, because there will be issues and fires. There always are. They tend to pop up before you can even get clear of your partner. The bigger the deployment, the more dependent you are on the partner who built it, they are only ones who know where the skeletons are buried. The only bigger risk is having one of your employees build it. Citizens There is a lot of conversation today about "Citizen Developers". They will also build houses of cards, but will likely do it poorly, without the deep knowledge and experience, and then suddenly they leave your company. Admittedly, when we are called into these scenarios, starting over is often the only option. Updates All platforms go through continuous updates, Microsoft Business Applications included. These can not only bring new features, but occasionally can deprecate features you are using. As a customer with your own business concerns, you will likely not be up-to-speed on these, and will instead discover them one day when things stop working. That would be a fire, and you better have a brigade at the ready. Better yet, if you have maintained a good relationship with your partner, they will give you a heads up, and be there to make sure things continue to go smoothly. Universal This is not a Microsoft Business Applications phenomena, this is the same for all platforms that allow for broad customization. The same was true when we were <a href="http://Salesforce.com" rel="nofollow" target="_blank">Salesforce.com</a> partners. It's also not new. The same was true for that Access Database solution Joe built for you ten years ago, and then he was hit by a bus and died. Damn Joe! Summary Eventually your partner will have you by your underwear band. Whether they give you a wedgie will have a lot to do with who they are, and how your have engaged with them. The cost of changing them will be very high, and last a very long time. Choose wisely.

Dynamics 365 - Buried Skeletons

Okay, I know it has been a while since I wrote a post. It's been a very busy time, and since Mark Smith and I started do a weekly live show, I felt the base was sort of covered. But people have pointed out that my retweeter has run out of fresh content, so I am compelled to write this.  Whirlwind Continues So I had a last minute change of plans, and headed over to Ignite for the first few days. Wow! It was the Power Platform show. If you have not been looking at the Power Platform yet, that train has left the station. Now you will have to run to catch up, but you better do just that. BAG is pouring the lion's share of their investment into all things "Power". There is no "catching your breath", more things announced at Ignite, while we are still digesting the last things. The least interesting announcement was the official name change of Microsoft Flow to Power Automate... or as I like to call it, "Powerate" or "Pautomate", we'll see which one I can make stick... just to annoy Alysa. For now, let's look at a couple of the real things that James announced in  his post. Power Virtual Agents Finally we have accessible bots. Accessible because they are code-less. Yes, get used to hearing that term. Up until now, we have had the bot framework, but that was over the heads of too many. The new Power Virtual Agents provides an easy interface for creating simple to complex bots without a single line of code. It is in preview, so you can play with it today. Get ready for bots to take over the world now that anybody can build them. Hmm, maybe this is not a good thing... Robotic Process Automation (RPA) This one will be interesting, and probably mostly Enterprise focused. Basically not everything out there has an API. Yes, believe it or not, there are many legacy applications in the wild that the only way to interact with them is via the UI. Mostly desktop, but even some web-based applications have no API. So there is this potential siloed data store, and we can't have that in the CDS age. Microsoft has introduced UI Flows, their name for their RPA solution built on Selenium. Seems like it should have been called "Power UI Flows", but it will probably change a few times anyway. It is interesting to see how far Microsoft has come, now building on top of open-source software, that was once called a "Cancer" by former CEO Steve Ballmer. Teams Integration Clearly, Microsoft wants to "own" your desktop real estate. You can't "own" it with a Power App alone, but you could own it with Teams... if it allowed you to do everything you needed from within it. So the Teams integration continues to see love from Microsoft. I have been on several enterprise calls lately where Microsoft was demoing Power Apps. I was caught off-guard when they launched Teams, and worked with the Power App entirely from there. As Power Platform SIs and ISVs we need to be taking note of this shift. I think it may quickly become "the way" people engage with our apps. AI Builder Her's another one that probably should have been called "Power AI", and may have some name changes also. Here we go again, code-less AI, utilizing pre-built templates that Microsoft has created. I have had a few discussions on my "Steve has a Chat" series with Microsoft leaders about the challenge of getting AI off the ground. Everybody wants it, but it was a lot of work to deploy. Well, heavy-duty AI is still going to be a lot of work to deploy, but you can have some simple, yet high value, AI in an hour now, with these templates. It's all about creating the addiction. Ignite Pivot I sat in on a couple of sessions by Microsoft people. Sessions that I had seen previously at UG Summit. It is interesting how they slant the narrative for a different audience. At UG Summit, which is primarily end-users, it was all about "You don't need a developer to do any of this", at Ignite which has a huge developer crowd, the same slide was presented as "The Citizen can't do shit without developers". I'll keep watching this dance play out, but I'm sure I'm not the only one comparing notes. Enterprise Control Lately, there seems to have been some angst created in Enterprise IT departments with how Microsoft is pushing Power Platform directly to the end-users closest to the business. There were a lot of sessions and focus on this at Ignite. Clearly, Microsoft knows that if they gave IT a switch to turn things on, they would never do it. So let's pivot the conversation, and they had several large IT organizations up talking about how their businesses have changed for the better by fostering this motion, instead of fighting it. In one session I saw, Ryan Cunningham had the best possible answer to the question of new "Shadow IT": a single slide showing the Office 365 Login screen. Controlled by Azure Active Directory, "Shadows" are not really possible. Mic drop! Adding a space One minor item, that got almost lost in the buzz, was the space added to the name "PowerApps", it is now officially "Power Apps". It may seem insignificant, but it is another "alignment" for the future of "Power". I have it on good authority that we will see more "Power things" in the future. I can't wait!

Okay, I know it has been a while since I wrote a post. It's been a very busy time, and since <a href="https://twitter.com/nz365guy" rel="nofollow" target="_blank">Mark Smith</a> and I started do a <a href="https://bit.ly/powerupplayback" rel="nofollow" target="_blank">weekly live show</a>, I felt the base was sort of covered. But people have pointed out that my retweeter has run out of fresh content, so I am compelled to write this. Whirlwind Continues So I had a last minute change of plans, and headed over to Ignite for the first few days. Wow! It was the Power Platform show. If you have not been looking at the Power Platform yet, that train has left the station. Now you will have to run to catch up, but you better do just that. BAG is pouring the lion's share of their investment into all things "Power". There is no "catching your breath", more things announced at Ignite, while we are still digesting the last things. The least interesting announcement was the official name change of Microsoft Flow to Power Automate... or as I like to call it, "Powerate" or "Pautomate", we'll see which one I can make stick... just to annoy Alysa. For now, let's look at a couple of the real things that James announced in <a href="https://cloudblogs.microsoft.com/dynamics365/bdm/2019/11/04/announcing-rpa-enhanced-security-no-code-virtual-agents-and-more-for-microsoft-power-platform/" rel="nofollow" target="_blank"> his post</a>. Power Virtual Agents Finally we have accessible bots. Accessible because they are code-less. Yes, get used to hearing that term. Up until now, we have had the bot framework, but that was over the heads of too many. The new <a href="https://powervirtualagents.microsoft.com/en-us/" rel="nofollow" target="_blank">Power Virtual Agents</a> provides an easy interface for creating simple to complex bots without a single line of code. It is in preview, so you can play with it today. Get ready for bots to take over the world now that anybody can build them. Hmm, maybe this is not a good thing... Robotic Process Automation (RPA) This one will be interesting, and probably mostly Enterprise focused. Basically not everything out there has an API. Yes, believe it or not, there are many legacy applications in the wild that the only way to interact with them is via the UI. Mostly desktop, but even some web-based applications have no API. So there is this potential siloed data store, and we can't have that in the CDS age. Microsoft has introduced <a href="https://flow.microsoft.com/en-us/ui-flows/" rel="nofollow" target="_blank">UI Flows</a>, their name for their RPA solution built on <a href="https://www.seleniumhq.org/" rel="nofollow" target="_blank">Selenium</a>. Seems like it should have been called "Power UI Flows", but it will probably change a few times anyway. It is interesting to see how far Microsoft has come, now building on top of open-source software, that was once called a "<a href="https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/" rel="nofollow" target="_blank">Cancer</a>" by former CEO Steve Ballmer. Teams Integration Clearly, Microsoft wants to "own" your desktop real estate. You can't "own" it with a Power App alone, but you could own it with Teams... if it allowed you to do everything you needed from within it. So the Teams integration continues to see love from Microsoft. I have been on several enterprise calls lately where Microsoft was demoing Power Apps. I was caught off-guard when they launched Teams, and worked with the Power App entirely from there. As Power Platform SIs and ISVs we need to be taking note of this shift. I think it may quickly become "the way" people engage with our apps. AI Builder Her's another one that probably should have been called "Power AI", and may have some name changes also. Here we go again, code-less AI, utilizing pre-built templates that Microsoft has created. I have had a few discussions on my "<a href="https://stevemordue.com/category/stevehasachat/" rel="nofollow" target="_blank">Steve has a Chat</a>" series with Microsoft leaders about the challenge of getting AI off the ground. Everybody wants it, but it was a lot of work to deploy. Well, heavy-duty AI is still going to be a lot of work to deploy, but you can have some simple, yet high value, AI in an hour now, with these templates. It's all about creating the addiction. Ignite Pivot I sat in on a couple of sessions by Microsoft people. Sessions that I had seen previously at UG Summit. It is interesting how they slant the narrative for a different audience. At UG Summit, which is primarily end-users, it was all about "You don't need a developer to do any of this", at Ignite which has a huge developer crowd, the same slide was presented as "The Citizen can't do shit without developers". I'll keep watching this dance play out, but I'm sure I'm not the only one comparing notes. Enterprise Control Lately, there seems to have been some angst created in Enterprise IT departments with how Microsoft is pushing Power Platform directly to the end-users closest to the business. There were a lot of sessions and focus on this at Ignite. Clearly, Microsoft knows that if they gave IT a switch to turn things on, they would never do it. So let's pivot the conversation, and they had several large IT organizations up talking about how their businesses have changed for the better by fostering this motion, instead of fighting it. In one session I saw, Ryan Cunningham had the best possible answer to the question of new "Shadow IT": a single slide showing the Office 365 Login screen. Controlled by Azure Active Directory, "Shadows" are not really possible. Mic drop! Adding a space One minor item, that got almost lost in the buzz, was the space added to the name "PowerApps", it is now officially "Power Apps". It may seem insignificant, but it is another "alignment" for the future of "Power". I have it on good authority that we will see more "Power things" in the future. I can't wait!

Power begets Power

Fresh from a week of "drinking from the firehose" at the Microsoft MVP Summit, several things became quite apparent to me. MVPs like to drink, and the Common Data Service, is anything but "Common".  It will continue... indefinitely It seems that whenever Microsoft announces a "new" way to do something, they are hesitant to say the the "old" way will be eliminated. "We have no plans to deprecate the old way in the foreseeable future". In reality, they can't wait to pull the plug on a whole slew of inefficient, or misaligned things; but they can't grab their customers' legs and swing them back and forth like rag-dolls either. Or can they? One Version? It's no secret that Microsoft is the final stages of snapping all online customers onto a single version of the product. With rare exception, most of us are already there, whether you knew that or not. This is the best place for Microsoft to have us, and for 99.9% of us, it is the best place for us to be. Why is that not as scary as it sounds to people who are slow movers? Because the old things, that have been replaced by new things, are still there. When will they be removed? ITFOT It can't remember exactly how long ago it was, that I heard Ryan Cunningham say in response to a question from an audience, that something will happen "In the Fullness of Time". I can distinctly remember trying to deconstruct that phrase; was it a month, year, decade? It was such a brilliant response, I adopted it for use with my wife and kids. When my wife asked when we could get a puppy, I replied "In the Fullness of Time", with a wry smile. Turns out, it equals exactly three days. Chunks of Fullness One of the awesome things about being an MVP, that I share with my fellow MVPs, is the ability to see into the future... in chunks. The fuzziest chunk is the 2-5 years out chunk. As MVPs, there is an expectation that we are all smart enough to "get it", so of course we all nod knowingly as we are being exposed to the distant future state. In reality, our brains are all scrambling between excited and terrified as we try to wrap our heads around things we never thought about. I'm pretty sure the team knows this, as there seems to be the occasional unnecessarily long pause for effect. I did take a look around the room for a two-way mirror that the team might be cracking up behind, but did not see one. It is reassuring as a partner, to know that the team is thinking that far out, but in today's world... 2 years is a long damn time. The Aw-Yay Chunks The upcoming release vs. the one after that. Let's face it, at any point of time, there is an upcoming release. As soon as it lands, the next release is now the "upcoming" release.. every six months. As a partner, your highest focus is always on the upcoming release. As a partner you are, or should be, in a continuous state of preparation. If you are not, you will be replaced by one who is... it seems Darwin was correct. As we are being presented with things that will be in the upcoming release, vs. what got pushed to the next one, it is an odd mix of "Awws" and "Yays". Since the release notes are now released 90 days before the release, there is a 3 month window for surprises. The best surprise is that stretch goal, that was not listed in the notes, that suddenly appears. Of course there is also that occasional listed item that lands, but not exactly as we had hoped. Yet, all clearly within the doctrine of ITFOT. Preparation Test The most critical chunk, is actually the present, which, not that long ago was a future chunk also. But now that chunk has landed. If it was a new "way", then it landed next to the historical "way" chunk... if it was a new "thing", it landed by itself. Even though we may have known it was coming, and had time to test, play and prepare for it, often we are still caught unaware... like we forgot. It's like sobering up real fast, when the blue lights flash behind you, when your customer asks, "Hey, what's this new button do?". No More Rag Dolls I wrote a ISV focused post a while back on Ryan's Five Things. This was based on a response from the Business Applications Chief Traffic cop, Ryan Jones when asked about what ISVs should focus on. Turns out it was from his own playbook for how Microsoft is running the Platform today. Ryan and his team may be the most important cog in the entire Business Applications team. Their job is not coming up with the newest whiz-bang feature, rather their job is making sure it will work efficiently, and reliably for end customers once it launches. I get the feeling that Ryan says "No"... a lot. This was not the case in the not too distant past. Less than two years ago I wrote about what seemed like a strategy of  punching customers in the face... a strategy Ryan has clearly obliterated. Common Data Service Okay, so I know I veered off of the topic quite a bit, and I don't want to be accused of link-baiting. So this Common Data Service thing... yeah, it's pretty big. I will unpack it in a future post, but now I need to prepare for another week of firehose drinking at the Partner Advisory Council meetings... then can I go home?

Fresh from a week of "drinking from the firehose" at the Microsoft MVP Summit, several things became quite apparent to me. MVPs like to drink, and the Common Data Service, is anything but "Common". It will continue... indefinitely It seems that whenever Microsoft announces a "new" way to do something, they are hesitant to say the the "old" way will be eliminated. "We have no plans to deprecate the old way in the foreseeable future". In reality, they can't wait to pull the plug on a whole slew of inefficient, or misaligned things; but they can't grab their customers' legs and swing them back and forth like rag-dolls either. Or can they? One Version? It's no secret that Microsoft is the final stages of snapping all online customers onto a single version of the product. With rare exception, most of us are already there, whether you knew that or not. This is the best place for Microsoft to have us, and for 99.9% of us, it is the best place for us to be. Why is that not as scary as it sounds to people who are slow movers? Because the old things, that have been replaced by new things, are still there. When will they be removed? ITFOT It can't remember exactly how long ago it was, that I heard Ryan Cunningham say in response to a question from an audience, that something will happen "In the Fullness of Time". I can distinctly remember trying to deconstruct that phrase; was it a month, year, decade? It was such a brilliant response, I adopted it for use with my wife and kids. When my wife asked when we could get a puppy, I replied "In the Fullness of Time", with a wry smile. Turns out, it equals exactly three days. Chunks of Fullness One of the awesome things about being an MVP, that I share with my fellow MVPs, is the ability to see into the future... in chunks. The fuzziest chunk is the 2-5 years out chunk. As MVPs, there is an expectation that we are all smart enough to "get it", so of course we all nod knowingly as we are being exposed to the distant future state. In reality, our brains are all scrambling between excited and terrified as we try to wrap our heads around things we never thought about. I'm pretty sure the team knows this, as there seems to be the occasional unnecessarily long pause for effect. I did take a look around the room for a two-way mirror that the team might be cracking up behind, but did not see one. It is reassuring as a partner, to know that the team is thinking that far out, but in today's world... 2 years is a long damn time. The Aw-Yay Chunks The upcoming release vs. the one after that. Let's face it, at any point of time, there is an upcoming release. As soon as it lands, the next release is now the "upcoming" release.. every six months. As a partner, your highest focus is always on the upcoming release. As a partner you are, or should be, in a continuous state of preparation. If you are not, you will be replaced by one who is... it seems Darwin was correct. As we are being presented with things that will be in the upcoming release, vs. what got pushed to the next one, it is an odd mix of "Awws" and "Yays". Since the release notes are now released 90 days before the release, there is a 3 month window for surprises. The best surprise is that stretch goal, that was not listed in the notes, that suddenly appears. Of course there is also that occasional listed item that lands, but not exactly as we had hoped. Yet, all clearly within the doctrine of ITFOT. Preparation Test The most critical chunk, is actually the present, which, not that long ago was a future chunk also. But now that chunk has landed. If it was a new "way", then it landed next to the historical "way" chunk... if it was a new "thing", it landed by itself. Even though we may have known it was coming, and had time to test, play and prepare for it, often we are still caught unaware... like we forgot. It's like sobering up real fast, when the blue lights flash behind you, when your customer asks, "Hey, what's this new button do?". No More Rag Dolls I wrote a ISV focused post a while back on <a href="http://stevemordue.com/power-platform-ryans-five-things/" rel="nofollow" target="_blank">Ryan's Five Things</a>. This was based on a response from the Business Applications Chief Traffic cop, Ryan Jones when asked about what ISVs should focus on. Turns out it was from his own playbook for how Microsoft is running the Platform today. Ryan and his team may be the most important cog in the entire Business Applications team. Their job is not coming up with the newest whiz-bang feature, rather their job is making sure it will work efficiently, and reliably for end customers once it launches. I get the feeling that Ryan says "No"... a lot. This was not the case in the not too distant past. Less than two years ago I wrote about what seemed like a strategy of <a href="http://stevemordue.com/dynamics-365-how-hard-can-you-punch-a-customer-and-keep-them/" rel="nofollow" target="_blank"> punching customers in the face</a>... a strategy Ryan has clearly obliterated. Common Data Service Okay, so I know I veered off of the topic quite a bit, and I don't want to be accused of link-baiting. So this Common Data Service thing... yeah, it's pretty big. I will unpack it in a future post, but now I need to prepare for another week of firehose drinking at the Partner Advisory Council meetings... then can I go home?

Power Platform - The Uncommon Data Service

The Power Platform is on fire! Lot's of partners, developers and citizens are all creating all kinds of things at a rapid pace, it all seems so easy. Unfortunately many of them will get down the road and realize they should have taken a fork a few miles back. Let's see if we can map out the right path from the jump.  Whatcha gonna do? Before thinking about where to start, you should have clear idea of where you want to end up. Depending on the problem you are trying to solve, some choices will become obvious. If you are just looking to be notified when a new file is uploaded to a SharePoint folder? Microsoft Flow is probably all you need. Not much "Architecting" required. For this post, I want to talk about bigger things you may want to do, like building a robust sales application for your team for example, or any other function for that matter. Sure, for my Sales example, the Dynamics 365 Enterprise Sales application is one option to consider, but again, here I will go for the Platform approach. Foundation Canvas apps are great for point solutions, Power BI doesn't do anything without data and Microsoft Flow is great for connecting existing things, but for most customers we recommend starting with a model-driven app on CDS. It's not the app that is the foundation, it's the Common Data Service (CDS). CDS is the heart of all things to come, and allows for everything you start to do now, to have a full future later. The App The model-driven app you will be provided with by default is fairly scant. It does include Accounts and Contacts as a common starting point for most business applications, although for a B2C scenario you may not even need Accounts. It is a nice "rolodex" at this point, but way more powerful in it's potential. From here you can "model" your data and processes that are required to solve your initial needs. To shorten this process significantly you may want to look at our  RapidStart Accelerator Applications on AppSource. Regardless of your starting point, you will likely need some further development by yourself or a Microsoft Partner who specializes in Business Applications. The good news is, the effort required is significantly less than it has ever been before. Apps As you work on your model-driven CDS environment, you may see a need for more than one use case. Maybe your sales department needs something, but you also want something for the warehouse, or whatever. By the way I am just using "Sales" as an easy-to-grasp concept, but the app(s) could be for any business need. You have a decision to make with potential monetary consequences. Do you build two separate apps, or one and control access with security roles? Microsoft is launching a per/app/user license that is only $10, and it would be awesome to utilize just that. If your users are pretty segregated, and few or none of them  would have need to access both apps, you are fine. But if many of them need to access both, it will cost $10 X 2 apps. If many have to access 3 apps, it would be $30 for them. This maxes out at $40 for that 4th app as you would buy the unlimited app licenses at that point for $40/user. Still a bargain compared to past costs and other platforms. Architecting for License Cost As I said you could consider building a single app for all the different users needs and controlling who sees what, with security roles. It is more complex way to approach it, and could get unwieldy if you have many unrelated use cases, so you would have to weigh the costs of doing it that way vs. effort to make it that way. Again, this would only apply to users who wear multiple hats. Next Steps Let's say you now have a nice model-driven business application. Notice I did not say "basic", that's because it can actually be as complex and advanced as you need it to be over time. Are you done? Not even close. Now is when some of those other tools come into play on top of the foundation you have built. You have several options to go to next, one that is already covered in your $10 is a Canvas App, but this canvas app will take advantage of the CDS database you already built your model-driven app on, so all of that data is available. Also, Microsoft Flow, Power BI and Portals can be bolted on as well. So let's take a look at what these can add to your ultimate application to change the world, or at least your organization's world. Canvas Apps Canvas Apps are Task-Specific. The name Canvas comes from the design surface that you build them on, it looks a lot like PowerPoint. It is primarily a mobile application for those types of tasks that would be logically done on a mobile device. For example, adding a barcode scanner and tracking inventory in a warehouse, or a Check-in/Check-out app for corporate laptops. If this does not relate to your CDS environment, you would probably just make that Canvas App freestanding, but I'm keeping in the lanes of business applications here. Remember that the Model-Driven app you already built has full mobile capabilities also, so you will want to explore that before you complicate things with yet another app to maintain, but for the right scenarios, Canvas is awesome. Microsoft Flow Let's say your organization has some other app they are using for other things. Let's also say that it could be advantageous to have your new app talk to that app. Maybe it would be nice to pass some data back and forth when certain things happen. Microsoft Flow is your bridge to over 250 other apps and growing. Microsoft Flow sits between your new model-driven app and any of those 250+, and can pass things back and forth based on triggers or conditions. It sounds more complicated than it is. Trust me, it's not. Not long ago, to accomplish this would have required a significant development project, all gone now. Power BI Power BI is Microsoft's industry leading Business Intelligence tool. Of course you have charts and dashboards in your model-driven app, but if you really need to go deep, or mash several sources up, Power BI is the tool for that. Of course it's primary source in your case is... you guessed it... your CDS. You can create advanced visualizations in Power BI to share with anyone, and you can even embed them into your existing app's dashboard. Is it easy? Well, it's not as easy as Flow, but you don't have to be a rocket scientist either. Another option to consider is a new offering called AI Builder. This is more of a "citizen" level tool-set that is actually quite easy to use. Not as powerful as Power BI, but it can handle a lot of AI needs. Again, sitting on your CDS. Portals Things are going quite well, and you realize there would be some efficiencies gained from having customers, vendors or partners do somethings themselves. You don't really a want to give them access to your application, but some highly filtered level of access would be real handy. This is one example where Portals come into play. A web based representation of your business application, tailored for your audience, so they can interact with you touch-free. The scenarios are limitless, but take for example a case management solution. A place where your customers could create and review cases you are working on with them in your business application. A way they can be engaged with what is going on 24/7, without having to call you for an update. All running on top of the same CDS you started with. Accelerators Let's say you are in one of the industries that Microsoft has built accelerators for, and there are several and more to come. But, for example, let's say you are in the Banking business. Your path just got shorter. Microsoft offers pre-built data models at no cost to help you get to where you need to easier. Our RapidStartCRM for Banking Accelerator is actually built on top of Microsoft's Banking Accelerator giving you...umm... double acceleration! Between these two, you may already be done before you started! Summary There are other ways to approach it, but this I my recommended path that eliminates any backing up and restarting later. Regardless of where you want to get to, Microsoft has made it exponentially easier today. Start with a model-driven app on CDS, and the sky is the limit. If you want to explore how you can move a spreadsheet based process for example, onto a platform, listen to my recent podcast with a large customer who just did exactly that.

The Power Platform is on fire! Lot's of partners, developers and citizens are all creating all kinds of things at a rapid pace, it all seems so easy. Unfortunately many of them will get down the road and realize they should have taken a fork a few miles back. Let's see if we can map out the right path from the jump. Whatcha gonna do? Before thinking about where to start, you should have clear idea of where you want to end up. Depending on the problem you are trying to solve, some choices will become obvious. If you are just looking to be notified when a new file is uploaded to a SharePoint folder? Microsoft Flow is probably all you need. Not much "Architecting" required. For this post, I want to talk about bigger things you may want to do, like building a robust sales application for your team for example, or any other function for that matter. Sure, for my Sales example, the Dynamics 365 Enterprise Sales application is one option to consider, but again, here I will go for the Platform approach. Foundation Canvas apps are great for point solutions, Power BI doesn't do anything without data and Microsoft Flow is great for connecting existing things, but for most customers we recommend starting with a model-driven app on CDS. It's not the app that is the foundation, it's the Common Data Service (CDS). CDS is the heart of all things to come, and allows for everything you start to do now, to have a full future later. The App The model-driven app you will be provided with by default is fairly scant. It does include Accounts and Contacts as a common starting point for most business applications, although for a B2C scenario you may not even need Accounts. It is a nice "rolodex" at this point, but way more powerful in it's potential. From here you can "model" your data and processes that are required to solve your initial needs. To shorten this process significantly you may want to look at our <a href="https://appsource.microsoft.com/en-us/marketplace/apps?search=rapidstart&amp;product=dynamics-365" rel="nofollow" target="_blank"> RapidStart Accelerator Applications</a> on AppSource. Regardless of your starting point, you will likely need some further development by yourself or a Microsoft Partner who specializes in Business Applications. The good news is, the effort required is significantly less than it has ever been before. Apps As you work on your model-driven CDS environment, you may see a need for more than one use case. Maybe your sales department needs something, but you also want something for the warehouse, or whatever. By the way I am just using "Sales" as an easy-to-grasp concept, but the app(s) could be for any business need. You have a decision to make with potential monetary consequences. Do you build two separate apps, or one and control access with security roles? Microsoft is launching a per/app/user license that is only $10, and it would be awesome to utilize just that. If your users are pretty segregated, and few or none of them  would have need to access both apps, you are fine. But if many of them need to access both, it will cost $10 X 2 apps. If many have to access 3 apps, it would be $30 for them. This maxes out at $40 for that 4th app as you would buy the unlimited app licenses at that point for $40/user. Still a bargain compared to past costs and other platforms. Architecting for License Cost As I said you could consider building a single app for all the different users needs and controlling who sees what, with security roles. It is more complex way to approach it, and could get unwieldy if you have many unrelated use cases, so you would have to weigh the costs of doing it that way vs. effort to make it that way. Again, this would only apply to users who wear multiple hats. Next Steps Let's say you now have a nice model-driven business application. Notice I did not say "basic", that's because it can actually be as complex and advanced as you need it to be over time. Are you done? Not even close. Now is when some of those other tools come into play on top of the foundation you have built. You have several options to go to next, one that is already covered in your $10 is a Canvas App, but this canvas app will take advantage of the CDS database you already built your model-driven app on, so all of that data is available. Also, Microsoft Flow, Power BI and Portals can be bolted on as well. So let's take a look at what these can add to your ultimate application to change the world, or at least your organization's world. Canvas Apps Canvas Apps are Task-Specific. The name Canvas comes from the design surface that you build them on, it looks a lot like PowerPoint. It is primarily a mobile application for those types of tasks that would be logically done on a mobile device. For example, adding a barcode scanner and tracking inventory in a warehouse, or a Check-in/Check-out app for corporate laptops. If this does not relate to your CDS environment, you would probably just make that Canvas App freestanding, but I'm keeping in the lanes of business applications here. Remember that the Model-Driven app you already built has full mobile capabilities also, so you will want to explore that before you complicate things with yet another app to maintain, but for the right scenarios, Canvas is awesome. Microsoft Flow Let's say your organization has some other app they are using for other things. Let's also say that it could be advantageous to have your new app talk to that app. Maybe it would be nice to pass some data back and forth when certain things happen. Microsoft Flow is your bridge to over 250 other apps and growing. Microsoft Flow sits between your new model-driven app and any of those 250+, and can pass things back and forth based on triggers or conditions. It sounds more complicated than it is. Trust me, it's not. Not long ago, to accomplish this would have required a significant development project, all gone now. Power BI Power BI is Microsoft's industry leading Business Intelligence tool. Of course you have charts and dashboards in your model-driven app, but if you really need to go deep, or mash several sources up, Power BI is the tool for that. Of course it's primary source in your case is... you guessed it... your CDS. You can create advanced visualizations in Power BI to share with anyone, and you can even embed them into your existing app's dashboard. Is it easy? Well, it's not as easy as Flow, but you don't have to be a rocket scientist either. Another option to consider is a new offering called AI Builder. This is more of a "citizen" level tool-set that is actually quite easy to use. Not as powerful as Power BI, but it can handle a lot of AI needs. Again, sitting on your CDS. Portals Things are going quite well, and you realize there would be some efficiencies gained from having customers, vendors or partners do somethings themselves. You don't really a want to give them access to your application, but some highly filtered level of access would be real handy. This is one example where Portals come into play. A web based representation of your business application, tailored for your audience, so they can interact with you touch-free. The scenarios are limitless, but take for example a case management solution. A place where your customers could create and review cases you are working on with them in your business application. A way they can be engaged with what is going on 24/7, without having to call you for an update. All running on top of the same CDS you started with. Accelerators Let's say you are in one of the industries that Microsoft has built accelerators for, and there are several and more to come. But, for example, let's say you are in the Banking business. Your path just got shorter. Microsoft offers pre-built data models at no cost to help you get to where you need to easier. Our RapidStartCRM for Banking Accelerator is actually built on top of Microsoft's Banking Accelerator giving you...umm... double acceleration! Between these two, you may already be done before you started! Summary There are other ways to approach it, but this I my recommended path that eliminates any backing up and restarting later. Regardless of where you want to get to, Microsoft has made it exponentially easier today. Start with a model-driven app on CDS, and the sky is the limit. If you want to explore how you can move a spreadsheet based process for example, onto a platform, listen to my <a href="https://stevemordue.com/steve-has-a-chat-with-mona-baset/" rel="nofollow" target="_blank">recent podcast</a> with a large customer who just did exactly that.

Power Platform - Architecting 101

Many of you have probably heard me talk about the new Power Apps Per App Plans. At $10ea, I know a lot of people are inquiring about it from my  Save 90% post a while back. It's real, but it's different. Until Jukka writes the definitive post on this, I will give you my thoughts.  Licensing One thing that most everyone can agree on, is that licensing for the Power Platform is complicated. It was complicated enough when it was just user-based licensing to determine what license a user needed, for whatever it was they needed to do. Now we have "Capacity-based" licensing. The simpler examples are things like storage, where when you run out, you add some storage "capacity". But capacity-based licensing is spreading it's wings. Would you like fries with that? Addons are a model you will continue hearing more about from Microsoft Business Applications Group. In a way, it is moving from pure user-based licensing to more of a consumption model... sorta. We currently have five items so far that are offered as "Capacity Addons" for the Power Platform: AI Builder Credits Portal Logins Portal Page Views Flow per Business Processes App Passes These $10 "licenses" I have been talking about, are the "App Passes". Taking a Pass App Passes are not the same as User Licenses. First, they are assigned to an App; or more specifically to an Azure AD Group, more on this later. This makes sense as they are designed for accessing a particular App as opposed to just anything. Using App Passes is a three-step process: 1) Purchase, 2) Allocate, and 3) Consume. This sounds easier than it is, depending on what you want to do. Purchase To purchase App Passes Microsoft refers you to the licensing guide. According the guide, you can purchase these passes through all of the normal channels, so the same place you buy your licenses today should have them. While Microsoft refers to the Per App plan as a means for users to "Get Started" . I am sure many users will never go beyond them. I'll discuss what you can do with these passes in a moment. Allocate This can get a little tricky. Once you have passes available and allocated to your environment, you can allocate them to users by simply sharing a "Canvas" App with other users. While Canvas apps certainly have their place, the real goal is to use these passes with a model-driven app, in my opinion. So how do you do that? First, you have to create an AAD group, then you would assign the "PowerApps Per App Baseline access" to the group, you can get that  here. After that, add your users to the group. Are we done? Not yet. The next step is to generate a Canvas app from the CDS environment that you plan to use the passes with. You can use the automated app generator for this, as I don't think you will use this canvas app for anything later,  here's how. Now assign the security role to the group who will use the Model-Driven app. Then share the Canvas app with the group, and finally share the Model-driven app with the same group and assign the security role for that. Wow! They are not making this $10 pass easy to use. Stay tuned for Jukka's much more detailed step-by-step that I will suggest that he write. Consume You will need to indicate for which apps you want to allow Per App Passes to be assignable.  Here's how to do that. Is it worth the effort? This will depend on how you plan to use apps in general. Instead of "Per App", you could opt for "Per User" License. Per User Licenses are assigned in the traditional way, and have the advantage of being able to use any Power Apps that are created, instead of being tied to a single one. However, that will cost you $30 more per user ($40 total). An "App" in the Per App plan can include a Single Model-Driven application, plus a single Canvas App, plus a single Portal. (You can use as many embedded Canvas Apps as you want in your Model driven app.) Power Automate is also available within the context of the App. So you can build a pretty robust business application within this framework, particularly of you spend some time up front on architecture. Once you have done the work up front on the AAD group etc, adding passes and users should be a pretty simple process, so it's more of a one-time effort. Saving $30/user/month may not be that significant if you only have a small number of users, but it could quickly add up for larger teams. BTW, Microsoft has told me that they plan on making this process easier for Model-Driven Apps. Details to come. Architecting for Per App Passes While Microsoft advocates the Per App plan as a way to "Get Started" with Power Apps, we have seen some customers solve some pretty advanced business problems with a single Model-Driven app. Add the ability use a Canvas app and a Portal to that, and you can build a complete business solution for a small to midsized business, or a department in a large enterprise. I wrote a post a while back on Architecting for Power Apps here. Let me know how this "Per App" approach works out for you!

Many of you have probably heard me talk about the new Power Apps Per App Plans. At $10ea, I know a lot of people are inquiring about it from my <a href="https://stevemordue.com/reduce-your-dynamics-365-license-costs-by-92-percent/" rel="nofollow" target="_blank"> Save 90%</a> post a while back. It's real, but it's different. Until <a href="https://survivingcrm.com/" rel="nofollow" target="_blank">Jukka</a> writes the definitive post on this, I will give you my thoughts. Licensing One thing that most everyone can agree on, is that licensing for the Power Platform is complicated. It was complicated enough when it was just user-based licensing to determine what license a user needed, for whatever it was they needed to do. Now we have "Capacity-based" licensing. The simpler examples are things like storage, where when you run out, you add some storage "capacity". But capacity-based licensing is spreading it's wings. Would you like fries with that? Addons are a model you will continue hearing more about from Microsoft Business Applications Group. In a way, it is moving from pure user-based licensing to more of a consumption model... sorta. We currently have five items so far that are offered as "Capacity Addons" for the Power Platform: <ol><li>AI Builder Credits</li> <li>Portal Logins</li> <li>Portal Page Views</li> <li>Flow per Business Processes</li> <li>App Passes</li> </ol>These $10 "licenses" I have been talking about, are the "App Passes". Taking a Pass App Passes are not the same as User Licenses. First, they are assigned to an App; or more specifically to an Azure AD Group, more on this later. This makes sense as they are designed for accessing a particular App as opposed to just anything. Using App Passes is a three-step process: 1) Purchase, 2) Allocate, and 3) Consume. This sounds easier than it is, depending on what you want to do. Purchase To purchase App Passes Microsoft refers you to the <a href="https://go.microsoft.com/fwlink/?linkid=2085130" rel="nofollow" target="_blank">licensing guide</a>. According the guide, you can purchase these passes through all of the normal channels, so the same place you buy your licenses today should have them. While Microsoft refers to the Per App plan as a means for users to "Get Started" . I am sure many users will never go beyond them. I'll discuss what you can do with these passes in a moment. Allocate This can get a little tricky. Once you have passes available and allocated to your environment, you can allocate them to users by simply sharing a "Canvas" App with other users. While Canvas apps certainly have their place, the real goal is to use these passes with a model-driven app, in my opinion. So how do you do that? First, you have to create an AAD group, then you would assign the "PowerApps Per App Baseline access" to the group, you can get that <a href="https://signup.microsoft.com/signup?sku=bf666882-9c9b-4b2e-aa2f-4789b0a52ba2" rel="nofollow" target="_blank"> here</a>. After that, add your users to the group. Are we done? Not yet. The next step is to generate a Canvas app from the CDS environment that you plan to use the passes with. You can use the automated app generator for this, as I don't think you will use this canvas app for anything later, <a href="https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/data-platform-create-app" rel="nofollow" target="_blank"> here's how</a>. Now assign the security role to the group who will use the Model-Driven app. Then share the Canvas app with the group, and finally share the Model-driven app with the same group and assign the security role for that. Wow! They are not making this $10 pass easy to use. Stay tuned for Jukka's much more detailed step-by-step that I will suggest that he write. Consume You will need to indicate for which apps you want to allow Per App Passes to be assignable. <a href="https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/limits-and-config#powerapps-per-app-plan" rel="nofollow" target="_blank"> Here's how to do that</a>. Is it worth the effort? This will depend on how you plan to use apps in general. Instead of "Per App", you could opt for "Per User" License. Per User Licenses are assigned in the traditional way, and have the advantage of being able to use any Power Apps that are created, instead of being tied to a single one. However, that will cost you $30 more per user ($40 total). An "App" in the Per App plan can include a Single Model-Driven application, plus a single Canvas App, plus a single Portal. (You can use as many embedded Canvas Apps as you want in your Model driven app.) Power Automate is also available within the context of the App. So you can build a pretty robust business application within this framework, particularly of you spend some time up front on architecture. Once you have done the work up front on the AAD group etc, adding passes and users should be a pretty simple process, so it's more of a one-time effort. Saving $30/user/month may not be that significant if you only have a small number of users, but it could quickly add up for larger teams. BTW, Microsoft has told me that they plan on making this process easier for Model-Driven Apps. Details to come. Architecting for Per App Passes While Microsoft advocates the Per App plan as a way to "Get Started" with Power Apps, we have seen some customers solve some pretty advanced business problems with a single Model-Driven app. Add the ability use a Canvas app and a Portal to that, and you can build a complete business solution for a small to midsized business, or a department in a large enterprise. I wrote a post a while back on Architecting for Power Apps <a href="https://stevemordue.com/power-platform-architecting-101/" rel="nofollow" target="_blank">here</a>. Let me know how this "Per App" approach works out for you!

Power Apps - Licenses vs. Passes

As an ISV, with solutions for both Dynamics 365 and Power Apps, I was encouraged about the attention that Business Applications ISVs are getting recently. Unfortunately, I.P. protection is not one of the items coming anytime soon. Managed Solution Myth Many ISVs believe that their managed solutions are safe. Having taken great pains to ensure that their managed solution never gets in the wrong hands, by requiring that their own teams install it for example. Thanks to some utilities in free open source solutions like XrmToolBox for example, managed solutions are not even close to safe. Using a tool in the XrmToolBox called "Manage Solution" for example, I can login to any instance I have access to, and view a list of both managed and unmanaged solutions. The good news is I can only download to disk a copy of unmanaged solutions. However I can copy a managed solution into an unmanaged one, and then of course download a copy. So getting an unmanaged copy, of your managed solution that is installed on an instance I have access to, would take me about 30 seconds. I can now install your unmanaged solution on another instance, and poof, I have absconded with your I.P.. I can even take Microsoft's own Managed Solutions. Plugins Many ISVs feel that Plugins are safe. Well, using the "Assembly Recovery Tool" (also in XrmToolBox), I can download any dlls, managed or unmanaged. Pop open a freely available decompiler, and poof, I now have your Plugin I.P. Power App Components Forget about it, these run client side and I can scrape your I.P. right from my browser. Reverse Engineering Using a few freely available tools, an unscrupulous party can rip off and reverse engineer anything we have today. It happens. Sometimes it is a creepy, but savvy customer who just wants to get out of paying us for our solutions. Tinker here, tweak there and boom, they have it for free. Worse yet is unscrupulous parties that will take your I.P., re-brand it as their own, and resell it. At least I have been told by Microsoft that if we see that in AppSource, they will remove it. What Helps? Shifting necessary code off of your solution to your Azure is one scenario. At least on "your" Azure you can turn it off or on. If your solution has to reach outside, to get some bit of code or information to make it run, you at least have created a minor barrier. Code obfuscation is another technique that can help, but that is also not 100%. What Works? The only defense you have, in my opinion, is marketing. You have to build a brand and a reputation, that sane people will value over some low-cost knockoff. This is easier sad than done. It has taken us almost five years to establish a brand (RapidStartCRM) and a reputation, and still I hear people confusing us with knockoffs with similar names. There is of course, nothing illegal about liking someone's idea, and creating your own variation of it. But it still sucks to the one who did it first. What is not worth the effort? Let's face it. Most I.P could be reverse engineered even if I could not get your code. Just using it and understanding what it does is enough for a smart person to go create their own version. While their at it, they may as well go ahead and improve on your idea. In our solutions we have forgone the potentially very expensive, and not very effective anyway, I.P. protection efforts. We are able to track usage, and let customers know when they are out of compliance. This works with the 95% of customers who are honest. To me it was not worth the investment to attempt to thwart the %5. In retail, they call it "shrinkage". Obviously if you have extremely valuable, or highly proprietary I.P. you may look at it differently. Windows I have used this analogy for many things about Microsoft, and ISV solutions are no different. When you think you have identified an idea, a window opens. Shortly after you go through it, others will follow. In a relatively short amount of time, that same window starts to close. Either too many people went through it and there are no margins left, or Microsoft patched the hole you found and your solution is no longer needed. Today, windows close as fast as they open. If you are going to be in the ISV game, you need to move very fast with ideas, and always been thinking about what you will do next.

As an ISV, with solutions for both Dynamics 365 and Power Apps, I was encouraged about the attention that Business Applications ISVs are getting recently. Unfortunately, I.P. protection is not one of the items coming anytime soon. Managed Solution Myth Many ISVs believe that their managed solutions are safe. Having taken great pains to ensure that their managed solution never gets in the wrong hands, by requiring that their own teams install it for example. Thanks to some utilities in free open source solutions like <a href="https://www.xrmtoolbox.com/" rel="nofollow" target="_blank">XrmToolBox</a> for example, managed solutions are not even close to safe. Using a tool in the XrmToolBox called "Manage Solution" for example, I can login to any instance I have access to, and view a list of both managed and unmanaged solutions. The good news is I can only download to disk a copy of unmanaged solutions. However I can copy a managed solution into an unmanaged one, and then of course download a copy. So getting an unmanaged copy, of your managed solution that is installed on an instance I have access to, would take me about 30 seconds. I can now install your unmanaged solution on another instance, and poof, I have absconded with your I.P.. I can even take Microsoft's own Managed Solutions. Plugins Many ISVs feel that Plugins are safe. Well, using the "Assembly Recovery Tool" (also in XrmToolBox), I can download any dlls, managed or unmanaged. Pop open a freely available decompiler, and poof, I now have your Plugin I.P. Power App Components Forget about it, these run client side and I can scrape your I.P. right from my browser. Reverse Engineering Using a few freely available tools, an unscrupulous party can rip off and reverse engineer anything we have today. It happens. Sometimes it is a creepy, but savvy customer who just wants to get out of paying us for our solutions. Tinker here, tweak there and boom, they have it for free. Worse yet is unscrupulous parties that will take your I.P., re-brand it as their own, and resell it. At least I have been told by Microsoft that if we see that in AppSource, they will remove it. What Helps? Shifting necessary code off of your solution to your Azure is one scenario. At least on "your" Azure you can turn it off or on. If your solution has to reach outside, to get some bit of code or information to make it run, you at least have created a minor barrier. Code obfuscation is another technique that can help, but that is also not 100%. What Works? The only defense you have, in my opinion, is marketing. You have to build a brand and a reputation, that sane people will value over some low-cost knockoff. This is easier sad than done. It has taken us almost five years to establish a brand (RapidStartCRM) and a reputation, and still I hear people confusing us with knockoffs with similar names. There is of course, nothing illegal about liking someone's idea, and creating your own variation of it. But it still sucks to the one who did it first. What is not worth the effort? Let's face it. Most I.P could be reverse engineered even if I could not get your code. Just using it and understanding what it does is enough for a smart person to go create their own version. While their at it, they may as well go ahead and improve on your idea. In our solutions we have forgone the potentially very expensive, and not very effective anyway, I.P. protection efforts. We are able to track usage, and let customers know when they are out of compliance. This works with the 95% of customers who are honest. To me it was not worth the investment to attempt to thwart the %5. In retail, they call it "shrinkage". Obviously if you have extremely valuable, or highly proprietary I.P. you may look at it differently. Windows I have used this analogy for many things about Microsoft, and ISV solutions are no different. When you think you have identified an idea, a window opens. Shortly after you go through it, others will follow. In a relatively short amount of time, that same window starts to close. Either too many people went through it and there are no margins left, or Microsoft patched the hole you found and your solution is no longer needed. Today, windows close as fast as they open. If you are going to be in the ISV game, you need to move very fast with ideas, and always been thinking about what you will do next.

Dynamics 365 - ISV Protection?

I know had previously written about Partner business models, but I can't find that post. I recall discussing our "Blocks of Hours" model, and how it was working well for both us and our customers. But I was seeing some cracks in it, and decided to create yet another business model, that we are starting to use now, that shows even better potential.  What is a Business Model? At some point in talking with a customer about how awesome you and your team are, and hearing about what they are hoping to accomplish, they will ask "So how do we engage with you?" They will have to ask, because we all have our own ways of working with customers. I have tried them all, and don't like most of them. Each one that is in common use today has it's "fatal flaw", maybe for you, maybe for the customer, or sometimes both. Let's review a couple for fun. Fixed Scope-Fixed Price Most customers think that this is the model they want. How can they get budget approval without a fixed cost? This is particularly acute with Government or Large Enterprise customers. You could answer with a range... it could be as low as $x, or as high as 2 x $x. Which number do they go to management and ask for? In our business, the fixed-scope will not survive the first kick-off phone call anyway. Since the time you developed the requirements, Microsoft launched three more applicable features. Fixed Scope-Fixed Price is the most antagonistic model there ever was. It literally turns the engagement into a battleground from the jump. It does not work for either side, so we'll toss that one in the toilet. Value Based Pricing The idea here is to abstract away the actual effort required, and price things according to what their value is to the customer. This one is completely partner-centric, basically charging normal costs for normal things, but hammering the customer for the shit they really want. This model assumes that customers are morons... this one ends badly. Time and Materials This one seems pretty safe for the partner, although upside is limited. No scope, no price, we just put our heads down and start working. At some point we look up to a customer who is saying "What the fuck have you been doing?", "Oh, you know, just bopping along." No structure, goals, plan, or timeframe. This one usually comes to an abrupt end, with no finished work. A Little Better Model Several years ago we went to a "Blocks of Time" model. Customers could purchase blocks of time in increments of 10, 20, 40 or 80 hours. These were pre-paid, so it eliminated any chasing money on our part. It was a blended rate that covered anything they wanted to do, and unused time expired after six months. It was similar to a regular T&amp;M model, but was promoted as more of a modified Agile approach. What I did not like about it was the lack of accountability, on both sides. 40 hours is basically one week of one person, but with six months to use the time, nobody was in any particular hurry. It would not be unusual for a customer to go quiet for weeks, and then come back all fired up to resume. In the meantime, we re-assigned people, forgot where we were on their project, and it was just not as efficient as it could be. The upside was the most the customer could buy was 80 hours at a time, which meant we both had the opportunity to end the engagement whenever a block was consumed. It was a pretty good model, but I saw room to improve it. PowerSprints I liked the idea of "blocks", but it was lacking the urgency and accountability on both sides to actually get shit built... quickly. Time is the killer... endless projects that meander around are not good for anybody. I originally started thinking about time-boxing the blocks, getting away from the six months and tightening that up... a lot. I ended up with this idea that I'm call "PowerSprints" (Neil Benson is shaking his head at this moment). Basically, a PowerSprint is one week of effort by a team. I have small, medium and large PowerSprints, while each is one week in duration, their size will determine the velocity as they have progressively larger teams. An engagement starts with a required PowerSprint Zero (5 Man-days). I stopped providing free consulting, under the guise of "Pre-Sales", years ago. We use this week to perform any analysis, setup environments, pre-requisites, etc, and conclude with an initial backlog for the first PowerSprint. We will also create a high level schedule of time and sprint sizes, which can vary from week to week depending on what needs to be done. This schedule will be a range of "Best Case" with up to a 100% contingency, in case all hell breaks loose. We will mutually agree with the client on which week a PowerSprint will begin. They need to be ready for continuous communication and daily deliverables, and we need to be ready to execute. The PowerSprint begins on a Monday morning, and is continuous effort and deliverables until Friday afternoon... and it's done. What got done? As much of the prioritized backlog as possible based on the team size. This is what you call "Not Fucking around". A small project may only require one Small PowerSprint... but it's done in one week. A large project may require several successive sprints, and potentially some off weeks to all catch our breath. What do I like about this model? Well, as long as everybody is on-board, focused and ready... this is a "Shit gets done fast" model. What are the possible drawbacks? There are a couple of risks. On our side we have to have a team in place, focused and ready. A Team typically consists of a B/A who can also do configuration, an Architect, an Account Manager, a Developer and a Q/A person. The make-up of the team is flexible depending on the sprint backlog, as long as it adds up to the same man-days. For the customer, the risk is that they think they are ready to hold up their end, and then are unable to for some reason. Once a PowerSprint starts, it does not wait for anybody, and ends on Friday, ready or not that PowerSprint was consumed. If the customer is unable to engage, they will get our interpretation of the backlog. So we are starting to use this model, and having good results, I would love to hear others' opinions.

I know had previously written about Partner business models, but I can't find that post. I recall discussing our "Blocks of Hours" model, and how it was working well for both us and our customers. But I was seeing some cracks in it, and decided to create yet another business model, that we are starting to use now, that shows even better potential. What is a Business Model? At some point in talking with a customer about how awesome you and your team are, and hearing about what they are hoping to accomplish, they will ask "So how do we engage with you?" They will have to ask, because we all have our own ways of working with customers. I have tried them all, and don't like most of them. Each one that is in common use today has it's "fatal flaw", maybe for you, maybe for the customer, or sometimes both. Let's review a couple for fun. Fixed Scope-Fixed Price Most customers think that this is the model they want. How can they get budget approval without a fixed cost? This is particularly acute with Government or Large Enterprise customers. You could answer with a range... it could be as low as $x, or as high as 2 x $x. Which number do they go to management and ask for? In our business, the fixed-scope will not survive the first kick-off phone call anyway. Since the time you developed the requirements, Microsoft launched three more applicable features. Fixed Scope-Fixed Price is the most antagonistic model there ever was. It literally turns the engagement into a battleground from the jump. It does not work for either side, so we'll toss that one in the toilet. Value Based Pricing The idea here is to abstract away the actual effort required, and price things according to what their value is to the customer. This one is completely partner-centric, basically charging normal costs for normal things, but hammering the customer for the shit they really want. This model assumes that customers are morons... this one ends badly. Time and Materials This one seems pretty safe for the partner, although upside is limited. No scope, no price, we just put our heads down and start working. At some point we look up to a customer who is saying "What the fuck have you been doing?", "Oh, you know, just bopping along." No structure, goals, plan, or timeframe. This one usually comes to an abrupt end, with no finished work. A Little Better Model Several years ago we went to a "Blocks of Time" model. Customers could purchase blocks of time in increments of 10, 20, 40 or 80 hours. These were pre-paid, so it eliminated any chasing money on our part. It was a blended rate that covered anything they wanted to do, and unused time expired after six months. It was similar to a regular T&amp;M model, but was promoted as more of a modified Agile approach. What I did not like about it was the lack of accountability, on both sides. 40 hours is basically one week of one person, but with six months to use the time, nobody was in any particular hurry. It would not be unusual for a customer to go quiet for weeks, and then come back all fired up to resume. In the meantime, we re-assigned people, forgot where we were on their project, and it was just not as efficient as it could be. The upside was the most the customer could buy was 80 hours at a time, which meant we both had the opportunity to end the engagement whenever a block was consumed. It was a pretty good model, but I saw room to improve it. PowerSprints I liked the idea of "blocks", but it was lacking the urgency and accountability on both sides to actually get shit built... quickly. Time is the killer... endless projects that meander around are not good for anybody. I originally started thinking about time-boxing the blocks, getting away from the six months and tightening that up... a lot. I ended up with this idea that I'm call "PowerSprints" (Neil Benson is shaking his head at this moment). Basically, a PowerSprint is one week of effort by a team. I have small, medium and large PowerSprints, while each is one week in duration, their size will determine the velocity as they have progressively larger teams. An engagement starts with a required PowerSprint Zero (5 Man-days). I stopped providing free consulting, under the guise of "Pre-Sales", years ago. We use this week to perform any analysis, setup environments, pre-requisites, etc, and conclude with an initial backlog for the first PowerSprint. We will also create a high level schedule of time and sprint sizes, which can vary from week to week depending on what needs to be done. This schedule will be a range of "Best Case" with up to a 100% contingency, in case all hell breaks loose. We will mutually agree with the client on which week a PowerSprint will begin. They need to be ready for continuous communication and daily deliverables, and we need to be ready to execute. The PowerSprint begins on a Monday morning, and is continuous effort and deliverables until Friday afternoon... and it's done. What got done? As much of the prioritized backlog as possible based on the team size. This is what you call "Not Fucking around". A small project may only require one Small PowerSprint... but it's done in one week. A large project may require several successive sprints, and potentially some off weeks to all catch our breath. What do I like about this model? Well, as long as everybody is on-board, focused and ready... this is a "Shit gets done fast" model. What are the possible drawbacks? There are a couple of risks. On our side we have to have a team in place, focused and ready. A Team typically consists of a B/A who can also do configuration, an Architect, an Account Manager, a Developer and a Q/A person. The make-up of the team is flexible depending on the sprint backlog, as long as it adds up to the same man-days. For the customer, the risk is that they think they are ready to hold up their end, and then are unable to for some reason. Once a PowerSprint starts, it does not wait for anybody, and ends on Friday, ready or not that PowerSprint was consumed. If the customer is unable to engage, they will get our interpretation of the backlog. So we are starting to use this model, and having good results, I would love to hear others' opinions.

Business Models Continued

The IT organization, inside of most enterprise customers, is primarily focused on Security, Governance and Compliance these days. One of the biggest tools in their arsenal is the word "No".  That approach, to requests from various departments for solutions to help them accomplish their goals, planted the seeds for Shadow IT, and that Genie is not going back in the bottle.  Shadow IT In every organization, that is of a size to have an actual IT Department, Shadow IT exists. If you work or run one of these departments, and think there is no Shadow IT in your organization... you are wrong. There are tens of thousands of pay-by-credit-card online services available, to solve just about the same number of problems that people in your organization are struggling with. When you said "No" to Sally, and her 5-person department, for some kind of a solution they could use to track their projects, Sally signed up for "Billy-Bobs Project Whiz", a SaaS service, that she put on her credit card and adds to her expense reimbursement request. Studies A Plenty Clearly the "Democratization of IT" is bringing it's challenges to IT. There have been many studies over the years about the potential impact of Shadow IT, I pulled a few interesting tidbits from this Forbes one from late last year, where they surveyed 350 Enterprise Execs. "60% of organizations don't include Shadow IT in their threat assessments." I'll call this the "putting your head in the sand" approach. Yet "46% say Shadow IT makes it impossible to protect their data." So we are aware... we just choose to ignore it. When asked who should be responsible for a security issue from unsanctioned apps, 87% said the users themselves! So Sally unknowingly connects "Billy Bob's Project Whiz" to sensitive data, that is then exposed and brings the whole company to a stop... but it's Sally who is responsible? 68% said it was the IT Department's responsibly for software that they are not even aware of, not causing a problem! Another 64% said it was Billy Bob's responsibility! Less than half of the Execs believed they were even aware of the extent of Shadow IT. My guess is, that the ones who claimed they were aware, don't know the depth of it. There are more scary facts in that study, as well as the many other studies out there. Battle Tactics Up until now, the typical tactics used by IT to curtail Shadow IT have been lockdown measures, including elaborate data access policies, Zero-Trust policies, encryption, etc. Basically removing access to the most valuable resources from the people who need access. How are Line-of-business owners supposed to advance their organizational goals, without access to the very data they need to accomplish that? Obviously you can't just open up your data stores to every "Billy Bob" SaaS service... but your users need it. Embrace It? If it's going to happen anyway, is it better to just embrace it, and attempt to govern this Shadow activity? This would require a significant change in IT's thinking. "Hey Sally, I know I said 'no' to your request last year, but I assume you have solved your issue another way, can I take a peek at that please?" Certainly you could review "Billy Bob's" app, and maybe realize that Sally, not being a knowledgeable person, could have checked a box to encrypt all data, or similar things. Maybe you could even get satisfied that "Billy Bob's" App does not present a threat. What's next? Find every app like that in use your organization? How could you even do that? And checking them all would become a year-long project. For the ones that don't pass your review, how would you stop them from using it anyway... I mean they already went around you. Asking "Nicely"? That's not a trait of IT. What are these Apps? Most of the Shadow IT Apps in your organization will be some kind of point solutions to solve specific business challenges for your users. Many of these "Apps" will be brought in by the department to replace spreadsheet based systems that are just not cutting it for them anymore. Maybe you could track your users' Excel usage... if it suddenly goes down, you may have a new Shadow App in your org. Here's the problem, if you keep saying "No" to requests for help, they are going to solve their problem another way. But if you start saying "Yes", you now have a full-time job of vetting and monitoring all these "Billy Bob" apps. Microsoft's Power Platform Ok, I am aware that as a Microsoft Partner, I have my bias, but that does not mean that they haven't created a path for you to solve this problem. The Power Platform, which includes Power Apps, Power Automate, Power BI and Power Virtual Agents, was purposely designed to be used by your line-of-business users to build applications, using no/low code, to solve many of the problems they are going outside for. But are you just trading one problem for another? Again, saying "No" means Power Platform is just one more place your users can go with a credit card and sign up for on their own. Or you could bring it into your organization yourself and give them access to it. Why? Well now it is running in your environments that you control, and access to all of it is via Active Directory. The ultimate in security is their login page to your Microsoft account. So does the Power Platform solve your Shadow IT problem? Hell no. Internal Shadows Microsoft made a recent decision to turn on the ability for your users to create their own apps "by default". I guess they thought you would get in the way. Yes, if you have Office 365, your users can start building apps, and many may have already. Sure, you have a master kill switch, but that would just drive them back outside. Based on Microsoft information, users are building thousands of apps right now on the Power Platform... because they can. Using connectors, these users can be sending your data outside of your organization right now. So the Power Platform alone does not solve your problem, it could even be making it worse! How can you figure out the extent? I guess you could hit the kill switch and see how many screams you hear. Is there a better way? Center of Excellence (CoE) Fully cognizant of the potential of the Power Platform to transform an organization, but at the same time drive IT nuts, Microsoft developed an alternative to the kill switch they desperately hope you won't push. Since pushing it will drive your users back into the shadows, maybe a CoE is worth a look. Microsoft developed a CoE "starter kit". From the document: "The Center of Excellence (CoE) starter kit is a collection of components and tools that are designed to help get started with developing a strategy for adopting and supporting the Power Platform, with a focus on Power Apps and Power Automate." So this toolkit can help solve some of the biggest challenges, visibility for one. Basically you would create your own Power App, install their components on it, connect to their APIs and voilà, you now have visibility of all of the apps in your organization, as well as who is building them. A light on the shadows. What's in the box? Okay, there is no box actually, but some of the things that are part of the CoE toolkit are: Environment and Environment Security management, Data Loss Prevention (DLP) policy management, as well as Data integration and Gateway management. Compare that to the control you have over Shadow IT today. Is the toolkit a magic bullet to cure all ills? No, it is a part of a more comprehensive plan. Again from the document: "The kit does not represent the entire Center of Excellence, because managing a CoE requires more than the tools alone; the Center of Excellence also requires people, communication, defined requirements and processes. The tools provided here are just a means to get to the end goal, but the Center of Excellence itself must be thoughtfully designed by each organization based on their needs and preferences." So there is more to do. Why bother? Bringing Shadow IT into the light alone is a huge benefit for IT, but actually embracing the Power Platform and fostering and nurturing it's "governed and controlled" use, has had significant proven benefits for Enterprise organizations.  Here I will provide a few highlights and links to case studies. A small team at G&amp;J Pepsi with no previous app-development experience created auditing apps that saved the company $500,000. Link The Miami HEAT used data insights to grow fan engagement and increase season-ticket sales by 30 percent. Link Virgin Atlantic creates custom-built mobile apps to continually improve the start-to-finish travel experiences of 5 million passengers a year. Link One Autoglass employee created 40 apps that boosted the productivity of 3,000 field technicians and brought $40,000 savings. Link France’s national railway improved maintenance procedures and incident reporting by enabling employees to create more than 150 apps. Link  There are a ton of other stories about how IT, partnered with their users, has become the hero in their organizations. What's Next? Well, the first thing you should know, is that the CoE tools that are "provided" by Microsoft, are not "supported" by Microsoft. They have enough on their plate. So it is pretty much a DIY project. My company Forceworks, is offering a free CoE Briefing to learn more, you can sign up for that at forceworks.com/coe.

The IT organization, inside of most enterprise customers, is primarily focused on Security, Governance and Compliance these days. One of the biggest tools in their arsenal is the word "No".  That approach, to requests from various departments for solutions to help them accomplish their goals, planted the seeds for Shadow IT, and that Genie is not going back in the bottle. Shadow IT In every organization, that is of a size to have an actual IT Department, Shadow IT exists. If you work or run one of these departments, and think there is no Shadow IT in your organization... you are wrong. There are tens of thousands of pay-by-credit-card online services available, to solve just about the same number of problems that people in your organization are struggling with. When you said "No" to Sally, and her 5-person department, for some kind of a solution they could use to track their projects, Sally signed up for "Billy-Bobs Project Whiz", a SaaS service, that she put on her credit card and adds to her expense reimbursement request. Studies A Plenty Clearly the "Democratization of IT" is bringing it's challenges to IT. There have been many studies over the years about the potential impact of Shadow IT, I pulled a few interesting tidbits from <a href="https://stevemordue.com/wp-content/uploads/Shadow-IT-Study.pdf" rel="nofollow" target="_blank">this Forbes one</a> from late last year, where they surveyed 350 Enterprise Execs. "60% of organizations don't include Shadow IT in their threat assessments." I'll call this the "putting your head in the sand" approach. Yet "46% say Shadow IT makes it impossible to protect their data." So we are aware... we just choose to ignore it. When asked who should be responsible for a security issue from unsanctioned apps, 87% said the users themselves! So Sally unknowingly connects "Billy Bob's Project Whiz" to sensitive data, that is then exposed and brings the whole company to a stop... but it's Sally who is responsible? 68% said it was the IT Department's responsibly for software that they are not even aware of, not causing a problem! Another 64% said it was Billy Bob's responsibility! Less than half of the Execs believed they were even aware of the extent of Shadow IT. My guess is, that the ones who claimed they were aware, don't know the depth of it. There are more scary facts in that study, as well as the many other studies out there. Battle Tactics Up until now, the typical tactics used by IT to curtail Shadow IT have been lockdown measures, including elaborate data access policies, Zero-Trust policies, encryption, etc. Basically removing access to the most valuable resources from the people who need access. How are Line-of-business owners supposed to advance their organizational goals, without access to the very data they need to accomplish that? Obviously you can't just open up your data stores to every "Billy Bob" SaaS service... but your users need it. Embrace It? If it's going to happen anyway, is it better to just embrace it, and attempt to govern this Shadow activity? This would require a significant change in IT's thinking. "Hey Sally, I know I said 'no' to your request last year, but I assume you have solved your issue another way, can I take a peek at that please?" Certainly you could review "Billy Bob's" app, and maybe realize that Sally, not being a knowledgeable person, could have checked a box to encrypt all data, or similar things. Maybe you could even get satisfied that "Billy Bob's" App does not present a threat. What's next? Find every app like that in use your organization? How could you even do that? And checking them all would become a year-long project. For the ones that don't pass your review, how would you stop them from using it anyway... I mean they already went around you. Asking "Nicely"? That's not a trait of IT. What are these Apps? Most of the Shadow IT Apps in your organization will be some kind of point solutions to solve specific business challenges for your users. Many of these "Apps" will be brought in by the department to replace spreadsheet based systems that are just not cutting it for them anymore. Maybe you could track your users' Excel usage... if it suddenly goes down, you may have a new Shadow App in your org. Here's the problem, if you keep saying "No" to requests for help, they are going to solve their problem another way. But if you start saying "Yes", you now have a full-time job of vetting and monitoring all these "Billy Bob" apps. Microsoft's Power Platform Ok, I am aware that as a Microsoft Partner, I have my bias, but that does not mean that they haven't created a path for you to solve this problem. The Power Platform, which includes Power Apps, Power Automate, Power BI and Power Virtual Agents, was purposely designed to be used by your line-of-business users to build applications, using no/low code, to solve many of the problems they are going outside for. But are you just trading one problem for another? Again, saying "No" means Power Platform is just one more place your users can go with a credit card and sign up for on their own. Or you could bring it into your organization yourself and give them access to it. Why? Well now it is running in your environments that you control, and access to all of it is via Active Directory. The ultimate in security is their login page to your Microsoft account. So does the Power Platform solve your Shadow IT problem? Hell no. Internal Shadows Microsoft made a recent decision to turn on the ability for your users to create their own apps "by default". I guess they thought you would get in the way. Yes, if you have Office 365, your users can start building apps, and many may have already. Sure, you have a master kill switch, but that would just drive them back outside. Based on Microsoft information, users are building thousands of apps right now on the Power Platform... because they can. Using connectors, these users can be sending your data outside of your organization right now. So the Power Platform alone does not solve your problem, it could even be making it worse! How can you figure out the extent? I guess you could hit the kill switch and see how many screams you hear. Is there a better way? Center of Excellence (CoE) Fully cognizant of the potential of the Power Platform to transform an organization, but at the same time drive IT nuts, Microsoft developed an alternative to the kill switch they desperately hope you won't push. Since pushing it will drive your users back into the shadows, maybe a CoE is worth a look. Microsoft developed a <a href="https://docs.microsoft.com/en-us/power-platform/guidance/coe/starter-kit" rel="nofollow" target="_blank">CoE "starter kit"</a>. From the document: "The Center of Excellence (CoE) starter kit is a collection of components and tools that are designed to help get started with developing a strategy for adopting and supporting the Power Platform, with a focus on Power Apps and Power Automate." So this toolkit can help solve some of the biggest challenges, visibility for one. Basically you would create your own Power App, install their components on it, connect to their APIs and voilà, you now have visibility of all of the apps in your organization, as well as who is building them. A light on the shadows. What's in the box? Okay, there is no box actually, but some of the things that are part of the CoE toolkit are: Environment and Environment Security management, Data Loss Prevention (DLP) policy management, as well as Data integration and Gateway management. Compare that to the control you have over Shadow IT today. Is the toolkit a magic bullet to cure all ills? No, it is a part of a more comprehensive plan. Again from the document: "The kit does not represent the entire Center of Excellence, because managing a CoE requires more than the tools alone; the Center of Excellence also requires people, communication, defined requirements and processes. The tools provided here are just a means to get to the end goal, but the Center of Excellence itself must be thoughtfully designed by each organization based on their needs and preferences." So there is more to do. Why bother? Bringing Shadow IT into the light alone is a huge benefit for IT, but actually embracing the Power Platform and fostering and nurturing it's "governed and controlled" use, has had significant proven benefits for Enterprise organizations.  Here I will provide a few highlights and links to case studies. <ul><li>A small team at G&amp;J Pepsi with no previous app-development experience created auditing apps that saved the company $500,000. <a href="https://customers.microsoft.com/en-us/story/gj-pepsi-consumer-goods-powerapps" rel="nofollow" target="_blank">Link</a></li> <li>The Miami HEAT used data insights to grow fan engagement and increase season-ticket sales by 30 percent. <a href="https://customers.microsoft.com/en-us/story/761660-miami-heat-media-and-entertainment-dynamics-365" rel="nofollow" target="_blank">Link</a></li> <li>Virgin Atlantic creates custom-built mobile apps to continually improve the start-to-finish travel experiences of 5 million passengers a year. <a href="https://customers.microsoft.com/en-US/story/virgin-atlantic-travel-and-transportation-power-apps" rel="nofollow" target="_blank">Link</a></li> <li>One Autoglass employee created 40 apps that boosted the productivity of 3,000 field technicians and brought $40,000 savings. <a href="https://customers.microsoft.com/en-us/story/belron-autoglass-consumer-goods-powerapps" rel="nofollow" target="_blank">Link</a></li> <li>France’s national railway improved maintenance procedures and incident reporting by enabling employees to create more than 150 apps. <a href="https://customers.microsoft.com/en-us/story/sncf-travel-transportation-power-apps" rel="nofollow" target="_blank">Link</a></li> </ul> There are a ton of other stories about how IT, partnered with their users, has become the hero in their organizations. What's Next? Well, the first thing you should know, is that the CoE tools that are "provided" by Microsoft, are not "supported" by Microsoft. They have enough on their plate. So it is pretty much a DIY project. My company Forceworks, is offering a free CoE Briefing to learn more, you can sign up for that at <a href="https://forceworks.com/coe/" rel="nofollow" target="_blank">forceworks.com/coe</a>.

Shining a Light on Shadow IT

Steve has a third chat with Guggs

As I think back to past customers of Dynamics 365, not all of them were successful. The challenges that brought them to Dynamics 365 were real enough, but at the time we only had one solution to try and solve them with. I would love to snap my fingers and take Power Apps back in time. Sledgehammers Dynamics 365, borne out of it's predecessor, Dynamics CRM Online, is a software marvel. I'm talking specifically in this post about the "CRM" side of Dynamics 365. For a midsized to large business, D365 has all of the tools you would need to transform your entire operation. XrM was a blessing and a curse. In layperson's terms, XrM was the capability to customize almost any of the significant out-of-the-box capabilities to meet organization specific needs in a highly targeted and relevant way. XrM was also the path utilized to "Extend" D365 to solve other problems not contemplated by the out-of-the-box capabilities. It is a powerful combination that can be brought to bear on almost any business problem. The Curse Over the years, many Dynamics 365 partners became very proficient with XrM. As a result, D365 became a solution to "anything", not just Sales or Service related issues. When your only tool is a hammer, every problem looks like a nail. A customer has a business issue, not related to any of the out-of-the-box capabilities, no problem, we can solve it with XrM! And so it begins, provision an instance, hide most of the out-of-the-box capabilities, and start building custom capabilities. Or, maybe to save some time, we'll re-purpose some of the OOB capabilities, and contort them to fit the requirements, sorta. It's one thing to modify the Opportunity capabilities to better fit a customer's specific Opportunity requirements, even if modified heavily, it's another thing to re-purpose the Opportunity process to solve for Asset Tracking. As a result there are a lot of "bastard" deployments in the wild. Commitment Many well-intentioned partners, offered D365, planning on extensive use of XrM, as a solution to many customers' non-sales or service related problems. Could it solve those problems? Yes! But never as easily, or quickly or cost efficiently as anticipated. Trying to build a custom solution within D365 to a unique problem, is like doing laps in a crowded pool. Your route from start to finish will end up being far from a straight line. For some customers the cure was worse than the problem. All partners have experienced the customer who eventually pulled the plug on the effort. Wouldn't it be nice if there was a way to get the XrM capabilities in an empty pool? Power Apps Over the past couple of years Microsoft has been rolling out Power Apps, now part of the Power Platform. You may have seen it pop up in your Office 365 environments, you may have even played with it. That is really one face of Power Apps. Microsoft, in their infinite wisdom decided to use the same "Power Apps" name for another, completely different, solution. I personally put this at the top of my Dumb Decisions list... but that's another story. The Power Apps you might have seen or used in Office 365 are what are called "Canvas" Power Apps. If you look at a SharePoint list online, for example, you may have seen the Create Power App button, which if clicked, will automatically create a "Canvas" Power App from your list. As a result, a significant number of customers feel they are familiar with Power Apps, I know because I talk to them all the time, but they are only familiar with half of Power Apps, oblivious to the other face of Power Apps. Model-Driven What a shitty product name, or rather qualifier of a product name. Even when I try and explain it to customers, they are confused, because of what they think they already know. Microsoft really botched this one. I know that the plan was that these two completely different things would eventually converge, but giving them both the same name in the meantime was a huge mistake. Customers are thoroughly confused. It's not like Microsoft is afraid to change names, they do it unnecessarily all the time. As I am writing this, they are announcing a name change for "Office 365", a well-known and understood product, to "Microsoft 365", a name that was already in use for something completely different. For a really smart company, they can be quite stupid sometimes. XrM in an Empty Pool Model-Driven Power Apps are the XrM capabilities, in an empty pool. What I would give to go back in time to those customers who pulled the plug on D365. This was the product they actually needed at the time. But... it did not exist, so there's that... maybe I would have just suggested they wait a couple of years. What we have available today is an empty pool, with a low-to-pro code development platform sitting on top of it. We no longer have to waste time and money emptying the pool, or dodging big floats. Time to Value has been slashed. Development costs have been slashed. Time to ROI has been slashed. There's just a hell of a lot of slashing going on. A Big Ask If you are one of those customers, who went down the D365 path and wasted a lot of time and effort, only end up with nothing, I am aware that suggesting you to take a look at something else is a big ask. But, if you still have the problem, Microsoft may have caught up with your needs with Power Apps. Umm.. the other Power Apps.

As I think back to past customers of Dynamics 365, not all of them were successful. The challenges that brought them to Dynamics 365 were real enough, but at the time we only had one solution to try and solve them with. I would love to snap my fingers and take Power Apps back in time. Sledgehammers Dynamics 365, borne out of it's predecessor, Dynamics CRM Online, is a software marvel. I'm talking specifically in this post about the "CRM" side of Dynamics 365. For a midsized to large business, D365 has all of the tools you would need to transform your entire operation. XrM was a blessing and a curse. In layperson's terms, XrM was the capability to customize almost any of the significant out-of-the-box capabilities to meet organization specific needs in a highly targeted and relevant way. XrM was also the path utilized to "Extend" D365 to solve other problems not contemplated by the out-of-the-box capabilities. It is a powerful combination that can be brought to bear on almost any business problem. The Curse Over the years, many Dynamics 365 partners became very proficient with XrM. As a result, D365 became a solution to "anything", not just Sales or Service related issues. When your only tool is a hammer, every problem looks like a nail. A customer has a business issue, not related to any of the out-of-the-box capabilities, no problem, we can solve it with XrM! And so it begins, provision an instance, hide most of the out-of-the-box capabilities, and start building custom capabilities. Or, maybe to save some time, we'll re-purpose some of the OOB capabilities, and contort them to fit the requirements, sorta. It's one thing to modify the Opportunity capabilities to better fit a customer's specific Opportunity requirements, even if modified heavily, it's another thing to re-purpose the Opportunity process to solve for Asset Tracking. As a result there are a lot of "bastard" deployments in the wild. Commitment Many well-intentioned partners, offered D365, planning on extensive use of XrM, as a solution to many customers' non-sales or service related problems. Could it solve those problems? Yes! But never as easily, or quickly or cost efficiently as anticipated. Trying to build a custom solution within D365 to a unique problem, is like doing laps in a crowded pool. Your route from start to finish will end up being far from a straight line. For some customers the cure was worse than the problem. All partners have experienced the customer who eventually pulled the plug on the effort. Wouldn't it be nice if there was a way to get the XrM capabilities in an empty pool? Power Apps Over the past couple of years Microsoft has been rolling out Power Apps, now part of the Power Platform. You may have seen it pop up in your Office 365 environments, you may have even played with it. That is really one face of Power Apps. Microsoft, in their infinite wisdom decided to use the same "Power Apps" name for another, completely different, solution. I personally put this at the top of my Dumb Decisions list... but that's another story. The Power Apps you might have seen or used in Office 365 are what are called "Canvas" Power Apps. If you look at a SharePoint list online, for example, you may have seen the Create Power App button, which if clicked, will automatically create a "Canvas" Power App from your list. As a result, a significant number of customers feel they are familiar with Power Apps, I know because I talk to them all the time, but they are only familiar with half of Power Apps, oblivious to the other face of Power Apps. Model-Driven What a shitty product name, or rather qualifier of a product name. Even when I try and explain it to customers, they are confused, because of what they think they already know. Microsoft really botched this one. I know that the plan was that these two completely different things would eventually converge, but giving them both the same name in the meantime was a huge mistake. Customers are thoroughly confused. It's not like Microsoft is afraid to change names, they do it unnecessarily all the time. As I am writing this, they are announcing a name change for "Office 365", a well-known and understood product, to "Microsoft 365", a name that was already in use for something completely different. For a really smart company, they can be quite stupid sometimes. XrM in an Empty Pool Model-Driven Power Apps are the XrM capabilities, in an empty pool. What I would give to go back in time to those customers who pulled the plug on D365. This was the product they actually needed at the time. But... it did not exist, so there's that... maybe I would have just suggested they wait a couple of years. What we have available today is an empty pool, with a low-to-pro code development platform sitting on top of it. We no longer have to waste time and money emptying the pool, or dodging big floats. Time to Value has been slashed. Development costs have been slashed. Time to ROI has been slashed. There's just a hell of a lot of slashing going on. A Big Ask If you are one of those customers, who went down the D365 path and wasted a lot of time and effort, only end up with nothing, I am aware that suggesting you to take a look at something else is a big ask. But, if you still have the problem, Microsoft may have caught up with your needs with Power Apps. Umm.. the other Power Apps.

Tried Dynamics 365? Take another look at Power Apps.

Steve has a third chat with Charles Lamanna

The best podcast episodes about true crime. For any thrill seeking podcast listeners who just can't get enough of the captivating stories of murderers and criminals. This topic has all the best episodes from many different true crime podcasts.  Add episodes you're interested into your queue below!

Best True Crime Podcasts

The best philosophy podcast episodes. Asking questions about how to live a better life, what it means to be and do good, to the idea of God. This topic includes episodes that bring about important questions that everyone should be asking themselves. Add episodes you're interested into your queue below!