Jukka Niiranen

Tag: Dual-write

  • Why Power Platform licensing is complex, part 2: multiplexing

    Why Power Platform licensing is complex, part 2: multiplexing

    In my previous post in this series on Power Platform’s sources of licensing complexity I explored the internal product structure at Microsoft and why changes in this commercial packaging of different technnologies may lead to confusing messages. Now it’s time to move further into the actual usage of these products and discuss how the depth of integration that you – the customer – build between the systems can affect the licensing requirements.

    Multiplexing is a term that isn’t necessarily familiar to anyone who hasn’t worked with either selling or buying enterprise software. This is the core definition that Microsoft is using in all of its documentation:

    “Multiplexing refers to the use of hardware or software that a customer uses to pool connections, reroute information, or reduce the number of devices or users that directly access or use the [X] service. Multiplexing does NOT reduce the number of subscription licenses of any type required to access the [X] service. Any user or device that accesses the [X] service – whether directly or indirectly – must be properly licensed.”

    There’s has never been that much information made publicly available by Microsoft on how the multiplexing topic – probably because it’s a hairy beast that no one would want to let out of the closet. But the beast is there nonetheless, an if you’re not careful in how you design the technical solution architecture and the software products included in it, that beast may jump at you when you’re not ready and mess up all your plans.

    The price of data entry

    Let’s look at a simple example first, one that is a very common requirement from customers. Imagine there are employees out there in the field that work with customers and may hear about their future plans or identify current needs for which the organization could offer services or products to. They’re not in a sales role themselves but would love to pass on the info to the actual salespersons who manage these customer accounts. The lead entity in Dynamics 365 would be the obvious place to record such information, but this would require the employee in question to have the necessary license for creating new records into it. So, even if these field employees would be equipped with a Team Member licenses or even the Field Serivce Enterprise app, this is not an operation that they’re allowed to perform, according to the Dynamics 365 licensing guide.

    “But wait, we don’t need to actually have the users themselves interact with the lead record in the Dynamics 365 application in order to achieve this!” you might think, if you’d be viewing it purely as a functional requirement. Yes, technically we could create a custom entity like “Incoming Sales Information” and store its records into CDS, then run a workflow or Power Automate to copy that data into the lead entity’s corresponding fields automatically. Commercially speaking this would not reduce the need for licensing the users who are initiating the process. You’ve just designed a software solution that does the multiplexing, but the end result is still exactly the same, thus the actual problem remains. First of all, you are automating the data entry into CDS, and second, you are indirectly using an entity that is not covered by all Dynamics 365 license types (funnily enough, it IS covered by Power Apps, but that’s another story).

    The important thing to remember about multiplexing is that it essentially only concerns the internal users of an organization (this includes employees, contractors, vendors, agents). You can have a “Contact Us” web form on a public site with the same fields as you have on your Dynamics 365 lead entity, then have that form call a webhook and use Power Automate to write the submitted form’s data as a new lead record. Everyone else in the world can use that, but if any of your internal users would go onto this public web form and use it for data entry into Dynamics 365, they would have to have a user license that grants them sufficient privileges. (How would you in practice stop employees from using a web form that requires no user identification? Good question.)

    Multiplexing within Dynamics 365

    As Microsoft is making their Dynamics 365 apps more & more tightly integrated, we’re encountering scenarios where the traditional boundaries between the CRM product and the ERP product get very much blurred. The GA launch of the Dual-write feature means that Microsoft now provides an out-of-the-box way for entities common to both sides to have near real-time two-way synchronization. For example, you might modify the field of an account record in CRM (or “model-driven apps in Dynamics 365”) and this will right away be reflected on the customer record in ERP (“Dynamics 365 for Finance & Operations apps”). From an end user perspective, there is only a single system to work with. Awesome!

    How does this align with Dynamics 365 product licensing then? As of today, I haven’t seen Microsoft make any announcements on the multiplexing definition being relaxed as a result of their Dual-write feature. So, if a user creates or edits any record in one of the entities on the CRM side that gets almost instantaneously replicated over on the ERP side, they are using two systems at once and should be licensed for them both. All of a sudden, that $95 Sales Enterprise app license isn’t enough and you’d need something bigger. With Dynamics 365 Finance or SCM App starting at $180 as the base licenses, then adding a bit more of attach licenses to cover the Sales App, you’d be looking at a doubling in costs for the users who are stil working in the one and the same user interface but leveraging functionality that now connects seamlessly with another Dynamics 365 system behind the scenes.

    Setting the licensing dilemma aside for a moment, there are scenarios with very clear benefits from having the CRM and ERP side work together hand in hand, where the cost from the current way of working may well be higher. For example, being able to transiently call the product data and pricing engine of the ERP system to produce the details needed for quoting a customer on the CRM side can potentially remove a lot of context switching from the end users as well as reduce the amount of custom code you need to build and maintain. In the far end of the spectrum, brand new product offerings like Project Operations can emerge from this unified platform that can now replace the prior mix of apps like PSA, Finance and MS Project. They don’t actually need to suffer from the multiplexing “tax”, since all Microsoft needs to do is design a targeted commercial model for offering this functionality.

    Power Multiplexing

    The concept of charging for access to data that has originated from of flowing to another system has been invented at a time when software was deployed to dedicated servers and data had clear boundaries of the system in which it resided. Back when the old Dynamics CRM era rules on multiplexing were defined, I bet most of the Microsoft people working with the product surely couldn’t have imagined that the data used in managing the business processes for sales, marketing or service might one day also be stored elsewhere than the application’s own SQL database. We are living in very different times today.

    With Power Platform the whole purpose of these new cloud native tools is to combine data sources and manipulate their contents by sometimes bypassing the original application altogether – at least on an UI level, when talking to an API via Connectors. It’s effectively a whole platform designed to multiplex all the things!

    In today’s world many of us no longer perceive the value of a software application to be delivered only via the user direclty interacting with the user inteface. Especially in the context of business processes, we’re more concerned with the outcomes from the digital orchestration of data, business logic, and users – both the internal ones and the actual end customer. Despite of this, on commercial level we still need to pay attention to the number of individual systems involved in a process that’s triggered by the user. In a recent interview, Charles Lamanna from Microsoft stated that you should be able to instinctively know when you’re crossing the line to multiplexing.

    “At its core, if you’re using or doing something to circumvent a user license and you’ll know you’re doing it because it will feel unnatural because the system’s not built to behave that way, that’s multiplexing and not allowed. Everything else, the intent is to have it be allowed.”

    The question of whether data is replicated between systems in real-time or in scheduled batches used to be a reasonable criteria for evaluating whether something was multiplexing or not. Today when any citizen developer can build a Flow that pushes data across systems almost immediately, or construct a custom app that pulls & pushes data via Connectors and presents it in potentially a much better UI than the originating enterprise systems, the lines have blurred down to a level where they become almost useless in trying to navigate the licensing maze. The systems are built one way but the business users are now armed with low-code tools that they’re going to use to try and get the systems to work their way. Governance of remaining compliant in this new world is certainly going to become more and more challenging for organizations as a result.

    The business of software

    We can’t escape the fact that while the code based PaaS of Azure is mainly charged by API and resource consumption, the low-code application platform (aPaaS) of Microsof Power Platform is founded on the per-user licensing model. The pricing dynamics of a platform are such that the more workloads you can move away from individual applications (be it legacy on-prem systems or SaaS point solutions) onto a common app platform with a Per User licensing model, the more cost savings you can achieve. However, if you were to try and automate the processes up to a level where the number of licensed employees needed in total is reducing as a result, then that’s actually not a favourable result to the platform provider financially. Hence the strong stance on requiring every user involved in the business process someway to have a license.

    It’s not only Microsoft that has this complexity built into its product licensing. SAP is known for chasing the Indirect Access of data that has touched their system. Oracle talks about Named User Plus. It is one of the core principles through which enterprise software vendors have traditionally defined the rules under which their IPR can be made to be a part of the digital processes of an organization. What this means is that any modern platform which strives to connect these type of systems as data sources or targets in the new application UIs or automations built as low-code solutions is subject to the same licensing impact. Creating new avenues to use the data and business logic of these third party systems may well incur new costs as a result of extended usage.

    It’s tempting to argue that systems like CRM and ERP should not be able to place down a commercial lock on access to core information like the organization’s customers or the pricing of the products they sell. We should still keep in mind that often there would be no such single source of valid records that reflect the business reality in a digital form, had there not been the design and implementation of an enterprise system that can govern all the various processes around it. The API to any system may look deceptively simple, precisely because it abstracts the complexity behind it. Managing that data and process complexity is one of the key reasons why these systems exist, and why companies are usually willing to pay their licensing fees in exchange for the value they get. Unfortunately this tends to push down the complexity to those scenarios where power users and citizen developers might want to build new, creative solutions to that tap into the data managed in these systems.

    Other parts in this article series can be found here:

    Read more about Microsoft Business Applications licensing

    There are plenty of articles in my blog for you to browse in this category: Licensing.

  • United at last: Dynamics 365 Dual-write goes GA

    United at last: Dynamics 365 Dual-write goes GA

    On March 27 2020, Microsoft announced that the Dual-write feature is generally available. After being in preview for over a year, the functionality itself isn’t necessarily a surprise to anyone who’s actively following what’s taking place in the Dynamics 365 product portfolio. The GA does however mark a milestone where it makes sense to reflect on what the broader impact of Dual-write is to business applications built on top of Microsoft Power Platform.

    The very short answer to “what is Dual-write” would be that it’s a built-in feature for making business data available across Dynamics CRM & ERP products without any additional integration tools. It may come as a surprise to people outside the MS ecosystem that even though the Dynamics 365 brand was announced already in the summer of 2016, the practical work of bringing the different apps from this product suite together has not yet changed that much from the early days of custom integration projects. Putting things into context, the effort to unify the 1 CRM & N ERP products in Microsoft’s portfolio originally targeted its first deliverables in 2004 (as “Project Green”). This proved to be impossible (or rather not feasible from a business perspective) in the on-premises era, but now when the Dynamics products are services hosted in the global MS cloud, the unification has actually been doable.

    Dual-write isn’t your everyday CRM-ERP integration, though. It is a near real-time synchronization of data between the Finance and Operations database and the Common Data Service that powers the low-code application and automation development story of Power Platform. Looking at the even broader data story that Microsoft is building around it’s business apps, BI and AI capabilities, we can also see that Dual-write is just one of the mechanisms that will move business data around:

    Taken from the Ignite 2019 session “Common Data Service with Dynamics 365 Finance and Operations”, this slide highlights the role of Azure Data Lake Gen2 in the analytical features that will be offered both as preconfigured features from Microsoft as well as customer specific implementations, to derive new insights from the business data. When it comes to the more operational side of doing business in the digital world, having the SCM and Finance app data available in CDS is what opens up plenty of new interesting scenarios. What if anyone could easily build Power Apps that work directly with the enterprise master data from ERP like customers, products and pricing information? If CDS indeed could lower this data integration barrier and bring task based experiences with pixel-perfect Canvas apps into the hands of frontline workers, that could surely be a transformative service worthy of its name. Not just a single database like XRM was but a connecting layer across many Microsoft cloud technologies.

    In order to bring the ERP data into CDS, Microsoft needed to design harmonized data models that align with what used to be the independent products of Dynamics CRM and Dynamics AX originally and define how the schema of each system maps to the other. As an example, the CRM product data model has understandably been considerably more limited than that of an actual ERP application. Now with Dual-write, these two must come together in a unified product experience:

    No two businesses operate exactly alike when it comes to data and processes, so the logic of Dual-write has been built to allow no-code configuration to adjust the details of specific implementations. However, this new depth of application integration within the Dynamics 365 portfolio now means that you should have very good reasons if you decide to deviate from the standard model. Let’s look at Microsoft’s guidance for the above mentioned product data model as an example:

    The dual-write entity maps for products have been designed to flow data one-way only, in near-real time from Finance and Operations apps to Common Data Service. However, the product infrastructure has been made open to make it bi-directional if required. Although you can customize it, it’s at your own risk, as Microsoft does not recommend this approach.

    Anyone who’s worked with Dynamics CRM / Dynamics 365 Customer Engagement implementations in the past has surely come across the need to extend or modify the overly simplistic product and pricing data model that hasn’t been flexible enough to accomodate many real life sales scenarios. Jumping from such a customized environment in production use into Dual-write may not be all that easy, nor will the new data model defined by Microsoft just magically solve everyone’s problems. Dynamics 365 consultants working on data integration between systems aren’t likely going to be out of jobs just yet.

    Whether you’ll be jumping into deploying Dual-write or not, everyone needs to educate themselves on the implications of this new piece in the Dynamics 365 puzzle. From the DW documentation, have a look at the chapter “What does dual-write mean for users and architects of CRM products?” to understand why. There will be several new concepts introduced over on the CDS side like “company” and “party” that will affect all apps built on top of it – such as Dynamics 365 Sales, Marketing or Customer Service. Foundational elements like how customers of the organization or the internal units within that organization are defined have different data models in CDS vs. FinOps, so it’s important that everyone working on either side will use the new common documentation for Dual-write as the starting point to try and understand eachother’s perspectives on the world.

    There are also other dimensions affecting future solution architecture listed out in the documentation. According to MS, initially Dual-write will be shipped as separate solutions (notice that DW is solution-aware right from GA, highlighting the role of CDS as the cross-product ALM foundation in Power Platform). “In future releases, those solutions will become part of Common Data Service”, which I presume translates to every Dynamics 365 customer getting the core components, regardless of whether they already have Finance and Operations apps deployed in their tenant or not. Data types in CDS are also about to get extended to accomodate the enterprise ERP needs arising from this out-of-the-box FinOps integration.

    Of course not everyone is using the ERP solution based on AX, Finance & Operations, Unified Operations, Finance/SCM or whatever name Microsoft comes up next for it. A large share of the customer base will be a better fit for Dynamics 365 Business Central, which isn’t at least publicly yet targeted with Dual-write. Is there going to be an impact to SMB implementations where CDS is part of the solution architecture in some way and is this going to be positive or negative? According to the documentation, “in future releases, concepts in model-driven apps in Dynamics 365 (for example, customer, contact, quotation, and order) will be scaled to mid-market and upper-mid-market customers.” If Microsoft is really aiming to have a Common Data Model that should serve not just all Dynamics 365 products but also software providers from outside the immediate MS ecosystem, there are bound to be trade-offs between the complexity of the required schema for enterprise ERP and the ease of use for how citizen developers can tap into the Common Data Service for building simple business apps.

    Finally, there’s the ever interesting licensing aspect, of course. From the Ignite 2019 presentation, we can find the following statement on Dual-write licensing implications:

    When Microsoft customers (ISV, Partners, End Users, etc.) possess a valid Dynamics 365 for Finance and Operations license, they are entitled to replicate data between the Common Data Service and Dynamics 365 for Finance and Operations.  This entitlement does not include capacity consumed by the replicated data; if necessary, this is purchased separately.  This entitlement does not include use rights for the Dynamics 365 for Customer Engagement applications, including Sales, Service, Marketing, etc; if necessary, this is purchased separately.

    I’m expecting that the upcoming versions of the Dynamics 365 Licensing Guide would include documentation about the licensing scenarios for Dual-write, as at the time of writing there isn’t any public guidance available yet to address the concerns of multiplexing that inherently arise from the real-time synchronization of ERP data into CDS.

    As we know, having Power Apps licenses allows you to read all of CDS data. If you read through the GA announcement of Dual-write and its documentation, you’ll notice that MS is following its own guidance and not mentioning Customer Engagement even once, since CE now refers to on-premises software only. The new term, “Model-driven apps in Dynamics 365”, is a representation of Microsoft app teams themselves ship as the Sales app, Customer Service app and so on. When it comes to the customer specific business apps tailored to their needs, meaning Power Apps, these can be Model-driven or Canvas, ranging from simple “one click” mobile experiences to advanced information worker UI’s for desktop environments. They are all backed by the Common Data Service and running on the Microsoft Power Platform. How will these custom apps be treated in the licensing documentation that traditionally assumes customers would just be using the Dynamics 365 Apps as-is rather than adapting them to their unique needs and real life processes? This remains to be seen.

    Now that we are gradually getting over the age old divide between CRM and ERP, I hope the next area of unification would be a common licensing story that doesn’t draw artificial lines between Dynamics 365 and Power Apps. Splitting these into different licensing guides and different pricing publication formats isn’t all that helpful for the customers nor the partner ecosystem. A Common Data Service based on a Common Data Model should preferably be backed by a Common Licensing Model, don’t you think?