Tag: capacity

Why Power Platform licensing is complex, part 4: the role of CDS
Three months ago I set myself a goal to publish a 4-part series on the many mysteries around Power Platform licensing models. I’ve been known to write blog posts that are a bit on the long side and sometimes it surprises myself when after announcing the new article on LinkedIn I see a “20 minute read” info tag added alongside what I though was just a quick exploration into a topic. So, learning to better pace myself is a skill worth practicing, and dividing my writings into more digestable portions is one such exercise.

To recap, the original outline of this series was to cover these sources of licensing complexity:
- Protection of intellectual property as well as development budgets across Microsoft product portfolio (part 1, done✔)
- The old world of apps as data silos & the concept of multiplexing (part 2, done✔)
- Light use scenarios for information workers vs. “Real Business Applications” (part 3, done✔)
- The role of CDS as the platform, not just a data source/target (part 4, you are here 📍)
The Common Data Service is more than a data service

For the majority of users and developers out there who work with Microsoft technologies on a daily basis, CDS is not yet a “common” part of the toolkit. It’s not a visually sexy thing like Power Apps pixel-perfect UI’s, nor an superglue that connects different cloud services like Power Automate. There’s nowhere near as much flare in the data part as with Power BI. It’s not (in itself) an intelligent thinking AI machine with fancy algorithms either. For many it simply looks like a boring database that sits somewhere in the MS Cloud.

These people got it all wrong, of course, but it’s hardly their fault. After all, “CDS” sounds a bit like “SQL” and the term often isn’t used in any other context than when you’re planning the data storage part of your solution architecture. What CDS really should have been called is “Power Platform”, because essentially it is the single place that represents all the platform elements that makers, developers and admins can take advantage of when building on Microsoft’s low-code application platform.

The above image is the best illustration of the many dimensions of Common Data Service that I have yet come across in Microsoft’s slide decks. “Yeah, that’s pretty much all the important stuff you get with CDS”, I was thinking for a long time. Until someone pointed out to me that this picture is actually missing one obvious thing: solutions! That’s perhaps the single most important thing that CDS from its XRM origins is bringing to the table. Without solutions, what Microsoft would otherwise have is just a collection of independent cloud services that each have a completely separate way to manage their configuration, with no way to package these components into one logical container covering the functionality of an app, nor any valid ALM story for enterprise scenarios. In short, Power Platform would not be a platform without the solution model that’s powered by CDS.

The fact that we can so easily miss a critical part of the Common Data Sevice while talking about it just goes to show how much of a foundational part CDS is in the business applications offering. It’s not just one icon in the cloud architecture pictures. In fact, we also should keep in mind how many different Azure services CDS runs on, to deliver its feature set to users, makers and developers:

Yes, there is of course a whole bunch of deep tech stack found behind each and every icon in that picture too – say CosmosDB, for example. It is “big”, in the same way that CDS is “big”. What I think makes the Common Data Service special in this discussion is how it can abstract all that techy stuff from Azure and allow citizen developers (like myself) to control it indirectly, either via our own configuration or through the predefined patterns built by MS.

Essentially CDS is a value-added layer that brings much of the cool new cloud technology into my business apps while I’m sleeping. What I mean by this is that the architecture evolves to cover new requirements and open up new possibilities, all the while the original business logic and data of the app is preserved. If I create a custom entity, like I did for the first time in 2007, it will keep gaining new superpowers every year as application platform beneath it matures and evolves. All I have to do is keep paying for the service.

How do you price such a thing then?

The answer: in all the wrong ways. At least that’s what it often looks like at that moment when the cost factor is brought into the discussion in Power Apps business scenario planning.

The more central CDS becomes in the app story of MS Cloud, the more dissatisfaction there seems to be on the impact that its premium licensing model has on business decisions. There have been many debates on Twitter during the past few months, with valid arguments and counterarguments presented between the participants that range from customers to Microsoft 365 pros to Dynamics 365 pros to MSFT employees. Threads like this highlight an important aspect:

If you were to invent a brand new service out of the blue, had zero customers and then started to plan the pricing model for it, life would be easy. If, on the other hand, you take an online service that has been offered to customers for over a decade now, then try and mold that into whole new use cases, you’re inevitably going to cause some anger among the existing customer base.

In the above example, Neil’s point about the CDS storage cost increase in the new pricing model that moved from a flat GB rate to database/log/file storage type separation is entirely true: some part of the bill will go up 8x and that quite frankly sucks. Imagine if that would happen to the price of gasoline and your fuel costs would suddenly be 8 times higher. But hold on: the price of diesel went down considerably at the same time, and filling the tank with natural gas like LNG is now practically FREE!!! “Well whoop-de-doo, I’ll just switch my old gasoline Volkswagen to use LNG the next time I need to stop at the station.” Yeah, real life comes with a bit more friction to change the system that powers your vehicle, or your business processes.

Going back to my CDS custom entity example, though, if we think about the types of cars that Volkswagen sold back in 2007 vs. in 2020, of course there are slight differences in what the product is. The transition to electric cars is a very apt metaphor when thinking about the difference between XRM and CDS. Even though the Volkswagen engineers were able to create an electic version of the popular VW Golf model and sell the e-Golf alongside its combustion engine powered cousins since 2014 already, that particular path wasn’t going to get them far enough. In order to remain a competitive vehicle manufacturer in the global game, Volkswagen has had to design a pure electric compact car in the form of ID.3, and struggle with the many issues that come with brand new technology (also on the software side).

Similarly, it wasn’t ever really enough for Microsoft to just take XRM to the cloud and host it there (which they did a decade ago already). A lot of R&D budget has surely been spent in building the new foundation of Power Platform. At the same time, some existing features that the loyal fans of the classic VW Golf would have enjoyed could not be brought over to the ID.3, because there just isn’t a logical place for the combustion history to co-exist with the electric future all within the same frame. Witness the same pain with CDS, Power Apps and Power Automate never quite reaching full parity with what was available in the world that came before them.

Aside from just going electric, there’s one even bigger existential question the car makers are facing: do people even want to purchase cars in 2020 or would they prefer to just pay for the transportation services that they need at any given time? A bit like the dilemma of the light use scenarios, whereby it would make more business sense to lower the barrier of entry by not requiring the purchase of a full user license for the complete platform but rather selling tickets to enter the app when the need arises. This growth in revenue wouldn’t necessarily come from the existing customer base that pays more – it could be a whole new revenue stream made possible by the way the technology as well as the world out there has evolved.

Think about a simple, timely example: customer self-service terminals. In the aftermath of COVID-19, our day-to-day interactions with humans directly are being greatly reduced due to regulations on keeping a safe distance when roaming out there in the physical world. Instead of talking to clerks and cashiers, we are now acquiring the same information and completing the same transactions by using touch screens that allow the customer to do the data entry and retrieval themselves. Now, Power Apps Canvas apps would of course be the perfect fit for quickly creating touch friendly tablet UIs for various self-service scenarios. There’s only one blocker: Canvas apps don’t have a licensing model for kiosk scenarios where the person interacting with the app isn’t equipped with a user license for Power Apps. Doh!

It’s hard to imagine Microsoft not wanting to expand the footprint of Power Platform to more and more scenarios that aren’t tied to named users with dedicated licenses. Yes, Portals can already do that, Power Virtual Agents can of course serve anonymous customers, Power BI can even be embedded inside third party applications. It’s that direct interaction with the CDS entities through a user identity mapped into security roles that isn’t quite as flexible yet in the current world… because like I’ve been telling you all along, Power Platform licensing is complex for the customers, the partners and surely Microsoft themselves as well.

Life finds a way, licensing may follow

The good news is that CDS as a technology is doing better than ever, thanks to the critical role it is playing in so many different Microsoft products these days. It’s further expanding inside the Dynamics 365 portfolio via Dual-write. Data platform is embracing it via the native sync to Azure Data Lake. It’s the ALM backbone for all Power products (aside from Power BI – and of course PowerPoint!). Project got rebuilt on top of CDS to replace the earlier SharePoint based architecture. It’s perfectly feasible to imagine more and more MS apps and products gravitating towards this growing platform and starting to orbit around the central body that is CDS.

That still leaves open the question of the customer specifc business apps that are getting built every day as Power Apps Canvas apps. In order to ensure the citizen developers don’t just default to using SharePoint Lists (soon to be called Microsoft Lists) as their data storage solution, MS needs to find ways to lower the barriers to go with CDS instead. There’s the technical barrier from the long legacy of CRM requirements, then we have this licensing complexity. Even though the recent launch of Per App passes as a concept has in some high value scenarios made the business case calcuations easier, the vast majority of true citizen developer apps won’t ever even reach that stage where official calculations for a specific app’s ROI would be analyzed in detail. For this long tail of app development, there should just be ample CDS capacity available to be used for the purposes that the business experts themselves have identified as worthy to spend their time on (which often may cost a lot more than the actual software licenses).

Capacity based licensing of course wouldn’t make the tools free either, it just changes the way the final bill is calculated. The example of CDS storage pricing change is a reflection of exactly what happens when trying to find non-user based billing metrics that would reflect the rate at which the platform is used. Looking at the Power Platform price points, Microsoft may well feel that it’s perfectly OK to sell the CDS database capacity at $40/GB/month when their traditional CRM rival Salesforce has set their list price per GB to be a whopping $250 (which I don’t think they publicly advertise anywhere, so your real mileage may vary). Both figures have nothing to do with how much it actually costs to store data in the cloud, they are purely intended for building a pricing curve where the growth in platform usage (and hopefully business value) results in growth of revenue to the service provider.

The more we have capacity based pricing of Power Platform features, the bigger the issue of capacity limits and their enforcement will become in solution architecture design. API calls are much more difficult to estimate than user counts, so there is bound to be some increasing complexity ahead for scenarios where CDS and other Power Platform tools are used in a “pay per request” model. MS will likely continue to bundle quotas of API and storage capacity into their own software products that use CDS and where the revenue is attained via other means, in an effort to simplify the experience for that one product. The challenge that remains is the more holistic usage of an application platform, where not only do you buy the Apps but use features powered by CDS in your own unique ways.

Other parts in this article series can be found here:
Read more about Microsoft Business Applications licensing
Check out my earlier blog posts in the licensing category.
July 16, 2020
Dynamics 365 & Power Platform licensing FAQ, February 2020

Here’s a collection of recent questions from the Dynamics 365 and Power Apps use community on licensing topics. The answers are my own interpretations, based on what I’ve seen from MS or other community members. It’s a point-in-time blog post that may well be outdated tomorrow already. Please do also leave a comment if you see errors in the answers I’ve written.

As always with enterprise software licensing, ultimately the answers need to come from materials published by the software vendor, i.e. Microsoft. At the end of the day the customer is always responsible for being compliant with their own legal agreements that may have specific terms included.

Team Members

Q1: What’s changing in the 2020 Release Wave 1 for users equipped with Dynamics 365 Team Member license?

The release plan contains several items that talk about licensing enforcement. So, the actual rights for Team Member licenses are not changing, but there will be technical limitations on what the users are actually allowed to do. I’ve blogged about the underlying mechanism for linking service plans to application types, which will first be used for Team Members and down the line probably also for other licensing types.

2020 Release Wave 1 will introduce three new App Modules with pre-configured experiences for Team Members: Sales Team Member, Customer Service Team Member and Project Resource Hub. See my review of the early access version of these New Team Member Apps for Dynamics 365 for more details.

Q2: When will the technical enforcement be enabled in our Dynamics 365 environment?

For new customers, Microsoft intends to switch on the restrictions in April 2020. For existing customers with Team Member users, the change won’t happen overnight. Expect to see further communication from MS on this if your organization is affected by the changes.

Update: On Feb 24th Microsoft published the following “Dynamics 365 – Team Member License Enforcement Notification” in the Microsoft 365 Message Center (MC204622) visible to administrators:

To facilitate a smooth transition to the new Team Member app experiences, all existing customer organization instances, which will be impacted by this change, will be granted an additional grace period until June 30, 2020.

Update 2: due to COVID-19, Microsoft has postponed several deadlines for updates and deprecations. The latest guidance for Team Member licensing enforcement is now:

To facilitate a smooth transition, all customer organization instances that are created before April 1, 2020 have been granted an additional grace period until January 31, 2021.

Q3: The entities we use with Team Member license in our environment are not included in the standard apps, can we add them?

Yes. Customizing the aforementioned App Modules is allowed, as long as you follow the instructions given by Microsoft:

“Team Member apps can be tailored to more closely fit your organization’s industry, nomenclature, and unique business processes, just like other model-driven apps built on Common Data Service. However, these customizations will need to conform to the Dynamics 365 Team Members use rights detailed in the licensing guide. While customizing the app, you can add 15 additional entities. These additional entities can be any Common Data Service core entities, or you can create custom entities.”

Q4: The new Team Member apps ship with dedicated security roles. Does it mean we’re only able to assign these to the TM users and nothing else?

There is currently no restriction on what roles you can assign to users with a Team Member license. The way I see it, the OoB security roles are primarily used for granting access to the App Modules and stripping down features within the app that are not within the original design scope.

Q5: If we need users to access more than 15 entities, what are our options?

The App Modules for Team Members will technically enforce a limit on how many entities can be added. Now, keep in mind that the App Module itself doesn’t restrict what’s actually visible in the UI when looking at an entity form. For example, an account form can have many related entities shown that are not part of the App Module specification. If you don’t directly need to navigate to the entity but rather use them to describe properties of the main entity (say, account plans related to an account), then there might not even be a problem here.

If you need to browse through lists of tens of different entities, then you’re really pushing the boundaries of what Team Member licenses are intended for. Anyway, you could consider alternative access mechanisms alongside the Unified Interface App Module to cover these scenarios. Reporting tools could be a better way to present large quantities of data that are going to be read-only for the users. By purchasing a Power BI license for users that are equipped with Team Member licenses already, you would have full access to read the business data in CDS via reports and dashboards – as well as use Power BI for any other analytics needs within the organization.

Q6: Our users are accessing data mainly via the Dynamics 365 App for Outlook, is this going to be available to Team Members?

Yes. The Licensing Guide specifically lists this as the first use right for Team Members in Appendix A: “Access Anywhere: Web App, Mobile App, Tablet App, via Outlook.”

Q7: Can we also leverage Canvas apps with the Team Member license?

Yes and no. You can use embedded Canvas apps within a Model-driven app entity form, since these are just customizations within the app itself. However, you can’t access standalone Canvas apps with just a Team Member license.

Q8: What about if we have Office 365 license that gives access to Power Apps AND a Team Member license, could we then build a Canvas app that reads Dynamics 365 data?

Probably not, as this would require access to Premium Connectors. The CDS Current Environment Connector is the only non-deprecated way to access Dynamics 365 data (in the “product formerly known as Customer Engagement”, not talking about Operations or Business Central here), so this will likely be the technical blocker that stops you from building the custom app.

Power Apps

Q9: If we were to move our licenses from Team Members to Power Apps per App plan, what will the main differences be in the user experience?

Power Apps licenses are meant for custom apps, meaning there will not be a preconfigured App Module from Microsoft. That’s no big deal, since creating new Model-driven App Modules is very simple. You can choose the entities you need in the app, design a sitemap to provide the navigation experience for accessing these, give your app a name, hit “publish” and have a custom App Module available to the users. There aren’t any fundamental differences between what a Sales Team Member app and “Our Customer Management app” look like to the users, as they’ll all be Model-driven apps presented via Unified Interface.

Q10: Are there still restricted entities in Dynamics 365 that you can’t access with Power Apps licenses?

Yes, there are, but no one knows exactly which entities. We are still waiting for Microsoft to update the list of Restricted entities requiring Dynamics 365 licenses, to align with what was supposed to be the October 2019 licensing model update. Eventually there will be new information published, but the current situation is quite challenging for both customers and ISVs to navigate past the Power Apps potholes.

Compared to Team Member rights, a Power Apps premium license grants you access to create-read-update-delete (CRUD) entities like accounts, leads and opportunities that are read-only for Team Members. Also there are no 15 entity max limits in the Power Apps world, so your custom app can have a CDS data model that’s very complex. When you’re working with entities you create yourself, there are no restrictions at all. When you touch something built by MS for their first party apps, there’s a chance that limitations will apply at some point.

Q11: If we would like to allow also external users to access Power Apps in our tenant, can we do that without buying a Power Apps Per App Plan or Per User Plan for everyone?

With Canvas apps, there is the option for “bring your own license” (BYOL) available, which I’ve covered in this blog post. For Model-driven apps, this isn’t possible today. Power Apps Portals is always an option if you’re willing to re-build your app as a portal UI. (See also the Capacity topics below.)

Q12: We’ve bought Power Apps per App Plan licenses for our users, now how do we assign these to the custom Model-driven app we’ve built?

This is currently a tricky process, since Microsoft is still working on the proper mechanism to associate app passes with Model-driven apps. Follow these steps published on Magnetism Solutions blog and you should be able to pull it off. The Canvas app side is much easier and better documented by Microsoft.

Q13: It seems that we can’t assign the app passes to both our production and test environments. Is this a bug or a feature?

It’s a feature. While Dynamics 365 licenses like Team Member grant access to any number of environments in your tenant, the Per App Plan is actually a “Per App Within an Environment Plan”.

Q14: From a licensing perspective, what are the differences between a Dynamics 365 environment and a pure CDS environment without Dynamics 365 Apps?

Power Apps users can access any environment, if they have the Per User Plan or a Per App Plan app passes assigned in that environment. Dynamics 365 users are only allowed to use environments that have one or more Dynamics 365 Apps installed. So, if you build a small expense tracking app in a pure CDS environment, a user with $10 or $40 Power Apps licenses can use it, but a user with a $95 Dynamics 365 Enterprise App license can’t.

Q15: If we start with a pure CDS environment to build a custom data model for our custom apps and later want to add a Dynamics 365 first party App from Microsoft, how does that work?

Today you can’t deploy Dynamics 365 Apps into a pure CDS environment, so the only way would be a data migration project from your CDS environment to a new Dynamics 365 environment. It’s a technical limitation that MS surely wants to remove at some point, but right now you can’t step up from custom app to first party app via a license purchase alone.

Capacity

Q16: We want to build solutions that go beyond the personal productivity apps that the Default Environment is really only good for. What do we need for adding more environments, to leverage CDS and do proper ALM?

Creating a new environment requires database storage capacity, since every blank environment consumes 1 GB before you even store any data there. This is the only cost associated with environment creation, you don’t need any instance licenses for sandboxes anymore like Dynamics 365 used to require earlier.

If you purchase even a single Dynamics 365 license or a Power Apps Per User Plan license, you’ll get the 10 GB default capacity for database storage. If you only purchase Power Apps Per App Plans, it’s 1 GB. Each additional user accrues 250 MB more, if you buy Dynamics 365 Enterprise Apps or Power Apps Per User Plans. With Power Apps Per App Plan or Power Automate Per User Plan the users only accrue 50 MB. With Dynamics 365 Team Member or Professional App licenses, there’s no accrual per user.

The default environment already burns 1 GB of your database capacity, so creating new environments may not possible without buying a capacity add-on license – unless you’ve bought one license that increases your default capacity to 1o GB (hint: always buy one).

Q17: We have integrated other systems with Dynamics 365 / CDS and are now worried about the cost of API calls. How much will we have to pay for these?

If the integration is accessing CDS as a non-licensed application user, the number of API calls that you have available for free is determined based on the types of licenses in your tenant. With at least one Dynamics 365 Enterprise App user, you get in total 100k requests per 24h, every day of the month. With Professional licenses this falls to 50k and with Power Apps / Automate it’s 25k. Anything beyond that requires buying dedicated capacity add-on licenses.

Now, even though you can buy the license already, you can’t assign it yet. Since there also isn’t any API usage telemetry available to customers yet, we’re not in a situation right now where the system usage would be technically limited based on overage.

Q18: Power Apps Portals, is the login capacity license starter level of 100 logins / $200 per day or per month?

That’s 100 logins per month. A login session lasts 24 hours, after which a new login is consumed from the licensed capacity. If a user logs in every first day of the month, that’s a $2 per month cost. If they log in every working day of the month, the cost would be around $20 per month for Portal access, which is twice the price of a Power Apps Per App Plan. For higher volumes of Portal usage, there are discount tiers available to bring down the costs. Note that you need to purchase a sufficient amount of capacity in advance, based on how many logins you expect to have in any given month, because unused capacity does not roll over to the next month.

There’s more!
I’ve written several blog posts about the licensing topic, which you can browse through right here. If you want to keep up with the latest news around Power Platform, please feel free to subscribe to the Thinking Forward blog updates.

February 22, 2020
Licensing by consumption: pricing model of Power Platform online services

On the topic of Dynamics 365 and PowerApps licensing changes coming in October 2019, I earlier wrote about the biggest change in how Microsoft is separating the first party applications and the underlying platform in the new Per App pricing model. There’s another aspect in the coming licensing updates that has also caused a lot of concern among partners and customers: the API call limits. While the existence of limits on how much load one can place on the online service are not an entirely new construct, it’s the first time that the amount of API calls available is directly tied to the type of licenses bought.

In their August 29 blog post, Microsoft stated the following:

“A single, integrated approach for daily capacity limits will be implemented to help maintain a consistent quality of service for customers with PowerApps and Flow plans. These capacity limits should not impact standard or reasonable usage of PowerApps or Flow. Organizations that require additional capacity for heavy usage scenarios will be able to purchase add-on capacity and assign it to specific users or processes.”
Updates to Microsoft 365, Dynamics 365, PowerApps and Flow Licensing

The finer details of the new model are outlined in the PowerApps and Microsoft Flow licensing FAQs for October 2019 as well as the Requests limits and allocations pages over on docs.microsoft.com. You should keep an eye on these documentation pages, since further information will be made available, based on the incoming questions from customers. There have already been a lot of blog posts around this topic and I’m not expecting the debate to die out anytime soon. Rather than speculating about what the exact policies will be, I will instead try to set this new consumption based licensing into context with what’s happening in the Microsoft Cloud.

Users aren’t the only thing that matters

USL, user subscription license, has been the dominant model for pricing applications from Microsoft in the online services era. Of course they’ve been a key component ever since the personal computing revolution started with PCs running DOS, then Windows and many productivity applications like those found in the Office suite. The networked computing era extended the pricing models to server software that wasn’t always purely a per-user play, as the complexity and robustness of your back-end services determined how expensive that side was. In the initial wave of SaaS business applications, we saw a return to the simplicity of just paying a fixed fee like $50 per user and getting all of that server stuff covered for you. Oh bliss! Isn’t this exactly the way the cloud should be sold?

Those first SaaS services also were in themselves quite simple. A replica of the server software you could have either in your own closet or the data center run by companies like Amazon and MS. You just offloaded the complexity involved in managing hardware redundancy, backups, storage etc. and instead payed for all that in the USL. This is all fine and dandy as long as the value from the applications can be closely linked to the number of licensed users accessing it. Using CRM as a simple tool to improve sales person productivity might map into this type of cost-value structure. But how about when you take a step further on the digital transformation path and start to actually replace those tasks carried out by human employees with something that is almost fully automated? Hmm, perhaps the PC business model isn’t optimal for a future that looks like this.

Let’s look at some of the new services in the Dynamics 365 cloud. The commercial launch of Dynamics 365 for Marketing in Spring 2018 was a bit of a shock for anyone who always though these applications are licensed per user. Instead, Microsoft chose the model that HubSpot any many other vendors in the marketing automation space apply, by setting the pricing per contact. Yes, initially they were way off with this thinking by applying the pricing logic to the entire contents of the CRM database, but based on market feedback the model was adjusted to now count only for marketing contacts actually used by the specific application (i.e. where business value should be generated). Also, you actually don’t need any Dynamics 365 user license for those marketing people who build the customer journeys and analyze the results, since free user licenses are available to unlock the door into the system. Licensing is done on the environment level, after all.

Dynamics 365 Customer Insights is a CDP (Customer Data Platform, for those not keeping up with the latest acronyms) that allows customers to bring in customer related data from various different sources and unify them into a “customer 360” profile that links all those activity entries into a single view of the customer. You can then leverage big data processing features of a CDP to generate target segments like customers most likely to churn, select them to be a target group in Dynamics 365 for Marketing customer journeys and preserve your revenue streams by holding on to these customers identified by the intelligent machine in the cloud. How is this service priced? Per number of profiles: starting at 100k profiles for $1.5k, so 1.5 cents USD per profile. Any user in the tenant can be simply authorized to access the application, since the dedicated UI doesn’t have any dependency to the USL construct found on the Model-driven application side.

Forms Pro is a professional version of the personal/team productivity app found in the Office 365 suite, storing its data into CDS entities for process automation and data analysis. Do you need a USL for the Pro features? Nope. The pricing is based on the number of responses to surveys, at $100 per 2k, making it $0.05 per response. If you want to listen to your customers and improve business outcomes as a result of that, it’s not about how many people you have looking at the data but rather how smart and how automated your feedback management processes are.

AI Builder will go GA in October 2019. Guess how that’s going to be priced? That’s right: not per user. You buy a capacity license at $500/month for 1M “service credits”. When it comes to machine learning models as a service, with no pre-packaged Dynamics 365 app on top of them, there isn’t even any concept like contact or survey response that would tie the pricing to the physical world. You literally extract value directly from the data you put in there, with the help of apps and automation that builds on top of and integrates with your unique business processes.

The consumption pricing model is already here. Future products in the Business Applications portfolio are more likely to gravitate towards that, rather than finding a user to attach a price tag on.

Sandcastles in the sky and how to draw the lines

In the cloud era, Microsoft can see everything. No, they don’t have employees looking at any customer’s private data or anything like that. What I mean is they have telemetry data on everything that happens on the service, because they are hosting all the moving parts involved. This gives them the opportunity to be very data driven in analyzing how products are adopted, what people actually do with them. It is essentially their own implementation of the digital feedback loop that you see James Phillips preaching to Microsoft’s customers and partners in every keynote he does. There’s the “transform products” part that is all about aligning product features to meet customer needs, but you can be sure MSFT also want to “optimize operations” when it comes to the logistics of delivering the cloud services and how to price them appropriately.

Dynamics 365 is claimed to be the biggest service running on Azure today. Now, even though at Microsoft they both fall under the Cloud & AI that Scott Guthrie runs, there’s not a single bucket where all the costs would be thrown. The more Business Applications products are built that consume data storage and compute capacity, the higher the bill from Azure will be. The term COGS (cost of goods sold) is being used frequently when talking about the resources needed to keep cloud services up and running on these platforms like Azure. Power Platform is a platform on top of another, and while it often uses higher levels of abstraction that its raw Azure counterpart, API calls from the citizen developer PowerApps do turn into API calls against Azure services. Whatever product is generating this consumption must also front the bill.

The vast majority of Dynamics 365 business today is still done based on user licenses, regardless of what our AI & big data driven future may look like. These are sold as SaaS apps you can just sign up and start using, rather than a complex solution that needs a technical architect to build the blueprint for. As such, the message Microsoft wants to get out there (but isn’t always so good in phrasing) is that the app user license should cover all normal usage for real human beings interacting with Dynamics 365 CE. Yes, anytime a user opens a contact form on a Model-driven app there are around 10 API calls made, which count against the quota for that particular user account. All CRUD operations theoretically count, but for an end user you shouldn’t need to count them. This is not the intention of MS.

What is the idea behind setting the API call limits then? Well, the situation is this: the platform has evolved from the early days of being a simple CRM database for sales user productivity improvement into something that can connect OoB to a vast number of external (non-CDS) data sources and run complex automation on this data without anyone sitting in front of their PC and opening those contact record forms. When sold as Power Platform, there will be a massive amount of this non-CRM style consumption of computing resources running on the platform (unless MS completely fails with capturing this new business potential). Building all of this abstraction on top of the underlying Azure services and then giving it a way with essentially a per-identity flat monthly fee just wouldn’t be a sensible business model.
(more…)

September 12, 2019