Steve reads his Blog

Business Models Continued

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&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.  

Shining a Light on Shadow IT

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&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.

Steve Reviews a Solution

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.

Dynamics 365 - ISV Protection?

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.

Power Apps - Licenses vs. Passes

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!    

Power begets Power

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!

Steve has another chat with Guggs

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!  

Steve has another chat with Charles Lamanna

In this episode of "Steve has a Chat", I try and sneak up on Charles Lamanna again, but no dice. Recently promoted to CVP, Citizen Application Platform I wanted to see if I could get Charles to help clear up some of the confusion around licensing and API limits that seem to be the topic of the day. He was more than happy to help me set the record straight. Enjoy!
Full transcript follows:
Charles Lammana: Hey Steve. I bet you're recording this, aren't you?
Steve Mordue: Charles, you know I am. Did I catch you at a time where you could talk for a little bit?
Charles Lammana: Yeah, for sure. I'm about to go to dinner, but I'd talk to you anytime Steve.
Steve Mordue: I appreciate that. So we're recording this on Friday the 13th, that's ominous. And right now there's a lot of questions out there in this space, and I thought, "You know what?" I'm going to grab you and see if we can't answer some of these, for some of these folks. I've been fearlessly FUD fighting for the last week or two. I thought I'd just go grab the horse and get his mouth, so.
Charles Lammana: Sounds good. I can guess what you're fighting, but I'll let you share that first.
Steve Mordue: I will. Before I do that, congratulations on the promotion.
Charles Lammana: Thank you very much.
Steve Mordue: Corporate Vice President of Citizen Application Platform, right?
Charles Lammana: Yeah, that's right. I think I dilute the Microsoft CVP brand a little bit, but-
Steve Mordue: I don't think so. I don't think so. Are you still seeing that girl that you introduced me to a little while back?
Charles Lammana: Yes, yeah. And you know what's funny is, the place I'm going to dinner is actually the same place that we ran into each other-
Steve Mordue: Oh yeah? Well I guess she chose wisely then, in selecting a boyfriend. Should we read anything into the Citizen being part of the title?
Charles Lammana: So Citizen Application Platform's been the name for our team for a while and the main focus there is not like citizens of the United States or any country, but instead that anybody, even if they're not a professional developer, can use the Power Platform to go create applications, create dashboards, create flows and so on. That low code element. So that's the real focus, why we have the Citizen Application Platform.
Steve Mordue: So we're already shortening that to CAP?
Charles Lammana: Yeah.
Steve Mordue: You guys calling it CAP inside too?
Charles Lammana: Yeah, it is a mouthful.
Steve Mordue: It is.
Charles Lammana: And people ask me, do I work with the government or something. But nothing related to the government, just making it so anybody can build apps.
Steve Mordue: So I think that a lot of the questions, of course, are coming around from the Dynamics 365 guys. It's interesting because we used to all be Dynamics 365 guys and now there are Dynamics 365 guys and Power Platform guys. And they overlap some, but there's clearly a path for those like myself and others that have decided, "We're going to go Platform all the way." And a lot of the partners that are still heading down the first party all the way, and some of the confusion that's out there around some of the new licensing things. The two things that keep popping up on me and Mark's live weekly show, have you heard that yet by the way?
Charles Lammana: I haven't, but I'll check it out. If you guys are talking about licensing, I got to hear what you're saying.
Steve Mordue: Oh, we're just saying wrong stuff I'm sure. But licensing and of course the API stuff popped up and I've been responding to both those and I realized that one of the things I was saying might not have been correct on the new per app licensing. Now you know that that $10 per app licensing is blowing up everybody's head, right? Everybody's thinking, "This is crazy. This is going to blow up the market. How can anybody make any money?" But clearly this is a scale play and I was just under the assumption, I guess because of the way I was reading this stuff, that that $10 license was for a single app that you just built on the platform. And Ryan Cunningham confirmed with me the other day that no, you could use this on the Dynamics 365 instance as well if a user's only using a single app that doesn't use any restricted entities.
Steve Mordue: Well there's hardly any restricted entities in the sales app and I thought, "Well, I mean you're just going to have a bunch of people that are going to pull out a couple of things in the sales app they may not be using anyway and start paying 10 bucks instead of 95." Clearly that's not the intent. Was he wrong, am I wrong or is there just this idea that, "You know what? We're going for scale at 10 bucks and everything else, get out of the way"?
Charles Lammana: You're both right, but let me inject an additional piece of information. So even in a Dynamics instance you can use the new per app per user license, that's $10 for power apps, as long as you don't use any of the restricted entities or any of the application IP, like a schedule board or something from field service. The piece of information that's missing is that list of sales restricted entities as part of the new per app per user license, there's a few more entities from sales that will be added to that list.
Steve Mordue: Now it starts making a little more sense. Yeah, because I was thinking whoever owns the sales app must be crapping their pants over there at this stuff. You've got to throw him something to keep his PNL going. Are you at liberty to say what those are yet?
Charles Lammana: Yeah, so I don't have the exact list off the top of my head, but I mean the intent is exactly as you described with the list that we have. And that is to make sure that if you are using the dynamics for sales application IP, which has a whole giant engineering org working on it, then it's only fair to pay Dynamics 365 for sales licenses or we'll go purchase them. So it's not going to be contact, but the ability to create an opportunity or manage opportunities, that probably should be restricted, if that makes sense.
Steve Mordue: Yeah. That's where it starts kicking into the logic and certainly those aren't components of the platform by itself, whereas contact is, and that's where you start bringing in the Microsoft vetted logic around all that stuff. So that makes sense. That makes sense. Plus it's good for me, as you know, from what we're doing, I'm sitting here thinking, "Oh great, everybody's just going to go start paying 10 bucks for the sales app and I don't have a business anymore," so I'm still good.
Steve Mordue: On the API stuff, and I've been kind of comparing this, there's a lot of FUD out there and frankly I've probably created some in the past, I know, I've not always said positive things, but at least I said things that were true. And lately, every time you guys go and announce something, and I'm just picturing you guys sitting back there reading that thing a hundred times thinking, "Okay, this is going to be fine, right? Nobody's going to have a problem with this." And it pushes a publish button and all hell breaks loose. And I feel for you guys, I really do, especially when these folks just attack anything you say and try and turn it into the worst case possible scenario. And the API limits I think is the one that all I'm hearing people say is, "Open a contact record. It does 50 API calls," you know, they're clearly taking that conversation in a direction. And my understanding from you guys is that when you do things like this with these limits, you're looking at a fraction of the market that's outside of it. I mean 95% of the people out there today shouldn't even have to think about this. Is that a fair statement?
Charles Lammana: That's exactly right. And I mean all the limits are a bit ... at this point Dynamics is such a big service with such a big surface area and so many customers, we can do pretty good quantitative analysis of what a typical user or a typical customer does. And we did that and that's where the API limits came from because our main focus, put very simply, we want basically all except the most sophisticated complex implementations to just require user licenses, because it's just such an easier conversation for the customer and Microsoft. I have a thousand sellers, I want a thousand sales apps, that's it, boom, done. You don't want to have to go architect, "How many API calls did they make? How many integrations do I have?" And basically our position is you shouldn't have that conversation if you're just going to do this, the vanilla sales workload or vanilla general power apps, workloads over CDS; you don't need to go even think about API calls.
Charles Lammana: And we do that. We do it because there are customers who do use a lot of API calls and it is important to their implementation and they'd like additional API capacity where there's no way for them to purchase it from Microsoft today. So we have to have a limit and then we have to have a way to purchase incremental API calls in order for that model to work. But again, the idea is we're not selling infrastructure or PaaS, there's no cores, none of that stuff. We just want customers to be able to buy USLs for power apps, for Flow, as well as for Dynamics.
Steve Mordue: Yeah. I think it kind of creates some fairness too because obviously we've had issues in the past with a certain segment of customers that are getting a lot more from the platform than intended and everybody else is using it as intended. So I can imagine if you've got some customer that, because of how they're using the platform or running their business or generating a zillion API calls, well they should be paying more. They're getting more out of it. They're doing more with it than the average customer who isn't. So I think it makes it a little more fair. I've always been annoyed at thinking that my customers or myself am subsidizing other customers overuse, you know?
Charles Lammana: Exactly, yeah. Tragedy of the commons, right? That's what the problem is with the multi-tenant SAS. If people can use way more infrastructure at no incremental costs or has issues, we're just trying to shape that behavior. But I mean I'll own, from a Microsoft point of view, we could have done a lot more to more clearly communicate those changes and make it more obvious and provable that the vast, vast, vast, vast majority of our customers will not be impacted. And we kind of view it, and it's kind of funny, we didn't really expect such a pushback on it, but we viewed it as just like that little asterix that you have with your cell phone or cable provider where when I get my internet from Comcast I don't think about how many gigabytes I used to download, but there is a limit. I mean it's really big and I bet like almost nobody hits it, but there is a limit at some point of internet download I can go do with my internet provider. But they have those same types of protections. But I just don't worry about it because it's not front and center. We should have done more to make it clear that that's the intent of these changes, to be that little asterix that you really don't have to think about unless you're doing something well outside the normal bounds.
Steve Mordue: You know, and we had the same challenge with the storage when we tried to change the storage for the better. And when that first got announced all you heard was, "Storage is going up eight times," and everybody's thinking, "Oh my God." And you guys retrenched a little bit, came back with a little clearer story about how that would work and I'm sure some people are paying a little more, but none of my customers are. So that doesn't seem to have impacted but a fraction of customers also.
Charles Lammana: Yep. Yeah. And a lot of those changes, our whole goal is we want our billing model to also not drive weird behavior or bad behavior that make it hard to implement. And the old storage instance cost model did that. So I mean that's why it was really important to change and some of the new API call models also do that. We just wanted to make it so if you build things the right way, the licensing and billing model will reward you for a more reasonable price.
Steve Mordue: So you say you don't want to reward or create weird behavior, but we just launched a $10 skew that sits on a platform that has access to all of the XRM capabilities. If somebody was motivated enough and had enough budget they could essentially build the entire Dynamic 365. They wouldn't, and as I stand back and kind of look, from my perspective, haven't been probably one of the first people in there when there still was missing parts and seen them come, I've seen the portals come, we've seen the Outlook come, we've seen the accelerators now have CDS only versions, we're just seeing more and more stuff coming to the platform, that that's got an awful lot of appeal to people to ... I won't say do weird behavior, but who think, "I want to get off this $95 skew if I can." I mean what's the thinking inside on that? I mean that's got to be expected?
Charles Lammana: Yeah, I think just our viewpoint would be if we ... I would say we are quite confident on the Microsoft side that the value and the intellectual property and the ongoing services and support and SLAs and integrations that come with the proper Dynamics applications can and will continue to command those prices. And it's not always $95, we also have Sales Pro and Customer Service Pro which are a cheaper price. And even if you use the pro license or the enterprise license, it also entitles you to a multitude of custom applications in that same environment, which the $10 per user license doesn't.
Charles Lammana: So I think we feel pretty good about that value prop, and going back to the ... we don't want to do artificial things with our billing model. We think a platform for one app, $10 per user per month, that can unlock the entire world to build all their apps on that platform and we feel like that's the right price for it, the right level of cost between the customer and Microsoft. And we wouldn't want that statement, which we believe to be true, to go be limited because we also think that we can sell a finished SAS application in the case of sales or service for pro and enterprise at a higher premium.
Charles Lammana: We think both of those things can exist and we will have blends. Like we will have customers who will repurpose their sales license for platform capabilities and we'll have customers who will use our platform license to go and try to create a mini CRM, and we think that's okay. I mean that's just their own calculation based on their value. But we're aiming for the 95 to 99% of the entire world where we think the value prop works pretty well.
Steve Mordue: Yeah, I mean I know that when I look across our customer base there certainly is a significant percentage of those people that are heavily using a lot of those high value features that you talk about. And then there's a segment that just never did, they're just kind of using basic stuff, and those are going to be pretty simple candidates to say, "Hey, you know what? You're not using all this stuff, just drop down." Or try and do a sales job to get them to start using it, because the worst case scenario is they aren't using it and they feel like they're paying too much and then they just churn out. And I'd rather move them down and keep them on something that they want, maybe they grow back up.
Steve Mordue: That's another story that's had a little confusion out there is that migration back and forth story. Now, my understanding today is of course if we start on CDS and the customer says, "Hey, this is pretty good, but I want to get some of those snazzy features in the first party," right now we're looking at a migration project, I think. Is that something that you guys think will be fixed or is it something that is a concern or something to think about, or are we just kind of looking at those as different customer types?
Charles Lammana: No, I'd say we definitely don't want to require a data migration like it does today. We want to get to a proper model where ... because I think of CDS and the platform as almost like Windows OS, right? You buy the Windows OS and then you'd go buy all the apps that you want and install it on the OS. And it's not like if I buy Windows and I install Office, but then I want to install, I don't know, Adobe Acrobat or something, I have to go re-image my Window server, right? So we want to make that be the right layering, and that's really just an architectural legacy reason for being that way today. But longterm, absolutely, you want to allow it. So you start with CDS, you can add sales, you can add service, you can add field service, you could add Talent, you could add Project Online; you can add and mix and match all these different applications on top of that CDS environment.
Charles Lammana: And we have early positive signs where that happens. We can't do it for the core CRM app yet, but low approvals, which is modeled as an XRM app and Project Online from Office 365, that's also an app installed on CDS. Those, we actually have many customers who start with a blank CDS and then end up with both of those applications installed in addition to Talent, which is also an app on top of CDS. All those three apps added incrementally, organically over time on top of CDS. So that works great, we just need to go make it so the core CRM also can do the same thing. And that's just some legacy reasons, which as you know, we've been on a journey the last year and a half to go clean up and we're kind of going piece by piece, like Outlook, then Activities and server-side sync are all just some examples where we're hammering against that, but we think we'll get there, no problem, in the foreseeable future.
Steve Mordue: Yeah, I mean for what we've been trying to do with the RapidStart, the Outlook app was definitely something that we needed. I mean everybody was wanting something like that, so thank you for that. And you knew I was hammering you guys for it too.
Charles Lammana: Yep. You would never let me forget it. I mean I wanted to make sure it was done before we had this phone call happen again, but ...
Steve Mordue: No problem. You guys got it done. Appreciate that.
Charles Lammana: Yeah. Yeah, and I've heard quite a bit about RapidStart, so it's great to see the traction of a third party app bill on top of the platform, it's really exciting for-
Steve Mordue: Oh yeah, yeah, we're excited too. We're developing some now on top of the accelerators, so, and the ... you having much to do with the accelerator groups? Smith and-
Charles Lammana: Yeah, so it's not directly out of my team but we collaborate very, very closely with them. But yeah, I mean accelerators are so key because the world increasingly is going to industry-based motions, like if I'm a financial institution, do I really have to rebuild all the financial services goo that goes on top of a CRM or CDS all the time? They don't want to, so the accelerator just provides a ton of value out of the box.
Steve Mordue: Yeah. So they just, with the banking accelerator, I think it's the first one where they released a CDS only version and then some additional add on versions that might take advantage of some of the first party. And I was talking to James about that and he said there's a plan to kind of go back to the other ones. So as soon as they did that we took a look at that banking core, which is an accelerator, and put our accelerator on top of that accelerator, "That'll be real fast," and looking at trying to leverage those accelerators. I think that's going to be an interesting ... I'll be curious to see what the market does with something like that that's built on an accelerator. It'll be a good test for the market.
Charles Lammana: Jjust on the accelerator bit, for Dynamics 365, our core customer engagement or CRM app, the accelerators have been absolutely key the last six months to drive business.
Steve Mordue: Yeah, I've been hearing that.
Charles Lammana: Financial services places, man, it's been a lifesaver for us because customers just love to see that fast time to value. And then so just we think that accelerators are going to be really important for the platform, for the Dynamics apps and for third party apps and building our ecosystem.
Steve Mordue: You know, talking about data models and industry data models, what's the latest on ODI? Is that progressing as you had hoped? Is it going faster, slower or is it going to happen? What do you think, or is there too many people punching-
Charles Lammana: It's advancing exactly at the paces we would want/expect, and I'll expand on what I mean by that. ODI is one of those super industry changing efforts and motions, and the reason it's industry changing is because we're bringing together so many companies like SAP, Adobe and Microsoft, that historically don't partner together and are built completely different stacks. We're bringing together all three companies to go do something, to create basically open data for our mutual and joint customers and a well-defined schema with a well defined set of entities to deliver a bunch of value to customers. So that's going to be a big deal when it lands. But just-
Steve Mordue: It's a big rock. Yeah, it's a big rock to move.
Charles Lammana: Exactly, three companies and 25 different applications, you mix in Dynamics, you mix in Office, you mix it Azure on the Microsoft side, it takes time. But when it arrives it's going to be a big deal. So ODI is absolutely something to pay attention to and it's something that continues to get significant investment from all three companies. It's taken its time, but I think it's going to be, whenever it arrives, it's going to be a really transformational item for our customers.
Steve Mordue: Are you still driving that?
Charles Lammana: I'm not. Robert Bruckner on our team is driving that. We support it from a platform, of course, just it's a lot of energy to go drive that process, so I'm glad we have Robert shouldering the burden.
Steve Mordue: Yeah. So we've got October release coming right around the corner, and of course the advance news that has come out, all anybody has been focusing on, the FUD rakers, is on licensing and APIs. But if you take that part of the conversation aside, which I feel like we should have done in our conversation so far, I feel like we've accomplished that, to all but the truly ignorant, if we take that part aside, what do you think are some of the most exciting things people should be looking for in this release for Power Platform?
Charles Lammana: I would say there's a few little things which I think are a big deal, and then there's a few big things. The little things are just usability improvements. If anyone's gone on and turned on the October release switch in the admin center, you will notice a significant modernization of the unified interface for model driven applications. There's much better grid density, much better density on forms, way less wasted white space. Better-
Steve Mordue: And how long have we been hearing that, right? People complain about white space. So just glad to see that one finally get behind us.
Charles Lammana: Oh man. And they're all little things, but you know what? We fixed the top 10 most painful user experience items of unified interface for October. And it's hard to do that in a way which doesn't trigger a whole bunch of retraining for our customers, so we had to be really thoughtful and diligent and you may not even realize it if you first turn it on, but just open it up side by side and we're really proud of those. Lots of little changes, lots of little pebbles that together really changed the experience for Dynamics and for model driven applications for power apps. So those are kind of the little ones. I'm very excited about that.
Steve Mordue: Yeah, I was poking around in an October version and yeah, you could definitely feel it. It's not dramatic, it's not like, "Oh my God, where am I at?" You haven't lost anything. But you definitely sense right off the bat the density and then the features that have been added or ... yeah, I think you guys probably did a smooth job of that. So now tell us about the bumpy stuff.
Charles Lammana: Yeah, the big stuff, the bulky stuff would be AI Builder is reaching general availability, as is PowerApps Portals. And we think that basically a modern platform needs to be able to support B2C, so external users to your company as well as anonymous access, and PowerApps Portals delivers that for the standalone PowerApps customers. And then we also believe the future of all applications and all automations and workflows is an intelligent, enriched experience and AI Builder delivers that for us. So you can use binary classification and prediction capabilities inside of AI Builder to make your power apps that are canvas model driven, but are built on top of CDS, make them much smarter. And that is one of my favorite features, it's just so amazing how easily you can enable a machine learning model without any data science or even developer background.
Charles Lammana: And then also we have like things like the Forms Recognizer which actually parses digital paper, PDFs, JPEGs, what have you, extracts that information into a structured form and you can use that in your power app or your flow. And we're seeing unbelievable adoption, almost 50% of all AI Builder customers are using the forms understanding capability. It's so transformative for the back office, and if you haven't checked it out, just use it and then your mind will start racing; "My legal department, my finance department, my HR department, my procurement department, all of them can just work so much more efficiently if you can get forms recognized or working with the flow." So we think Portals and AI Builder are two big, bulky, meaningful changes for Power Platform.
Steve Mordue: And AI Builder goes across, right? I mean you could stand up AI Builder on just bare CDS, you could stand it up on first party, it goes across, right?
Charles Lammana: Yep, absolutely. And I apologize to anyone else from my team that may be listening that I didn't mention your feature that you worked on, but they're all important in the October release. But those are my three most favorite children.
Steve Mordue: I definitely am hearing excitement about AI Builder and Portals is another one that's getting its share of FUD, something I read recently and some guy jumped on social talking about how Salesforce is so much cheaper because of this, that and the other. And unfortunately Dileep Singh happened to see what was going on, he jumped in and said, "Wait just a minute here," and kind of clarified some stuff right out there that reversed that whole story. So I'm looking forward to the day when we don't have a whole bunch of people out there watching your every move looking for the gotchas.
Charles Lammana: Well I would say our goal at Microsoft is broad adoption, which I mean generally reflects in lower prices. I mean that's our goal. Like if you go to Microsoft's mission statement, empower everyone and every organization to do more, you can't do that with outrageous bespoke boutique pricing. So that definitely is not our objective and we certainly will learn and we make mistakes, but our push is we want everybody to be able to use this thing. I want everybody in the world to build apps and create flows and create power BI dashboards.
Steve Mordue: Yeah, we'll leave the hidden costs to Salesforce, they're pretty good at that. So Charles, anything else you want to touch on? I've got, I don't know, millions of people that will be listening to this probably.
Charles Lammana: I mean the biggest thing I would say is, and this is my kind of call to action every time I talk to you, and maybe it's an overwrought point at this point in time, but Power Platform, I mean our push is to go unify the Office and Dynamics communities with a single low code platform for all of Microsoft, and in the process make it so everybody in the world can have access to analyze data, create apps and build automations. So if you haven't checked out Power Platform as just Power Platform and outside of Dynamics or Office, go do it now. I think it's super amazing, in five minutes you can get value and just from the point of view of Microsoft as a company, it's just really critical to where we think the future's going.
Steve Mordue: Yeah, I've had people ask me, "Where's the best place to start with Power Platform?" And I typically suggest Flow because it's about the easiest one to understand, the quickest of value and suddenly just light bulbs start going off. And when people are talking about building, because we are doing a lot of work with customers that are moving up from spreadsheets, that's a huge mountain out there for customers that are doing relatively complex business processes on a bunch of shared spreadsheets and torturing them. And we're generally recommending those customers go straight to a model driven app that has kind of that foundation, because then from there, you know, they can spring off with canvas flow, AI Builder, Power BI, have all those other things. And we're starting to get to a point where I'm getting crisped for that conversation because whenever you announce new things and stuff like that, nobody knows what we're talking about. The partners are behind and customers are behind-er. So, lots of education, a sales process now is an education process and probably will be for a while, because I don't see you guys slowing down.
Charles Lammana: Never. We-
Steve Mordue: Yeah, you're not even going to let us catch our breath before you're going to go do some stuff and keeping the partners hopping.
Charles Lammana: Yeah.
Steve Mordue: Well, Charles, I appreciate you taking some time. I knew I might be able to catch you here in the last hour of your work week and I was glad to do it. We'll be publishing this here, I don't know, probably Monday or something like that, get it out there pretty quick while everybody's got all the questions.
Charles Lammana: Sounds good.
Steve Mordue: So you have a good night, you mentioned something about dinner, so enjoy your dinner.
Charles Lammana: Yeah, as always, great chatting, thanks Steve.
Steve Mordue: Tell your girlfriend I said hi.
Charles Lammana: Will do.
Steve Mordue: All right, bye, guy.
Charles Lammana: Bye for now-

Power Platform - Architecting 101

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.    

Dynamics 365 - Buried Skeletons

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.