Microsoft dropped a big bomb this week with their Dataflex announcement. I don’t think I’ve ever had as many notifications on my social media apps as there were after I posted my two Dataflex articles on this blog and our company blog.
Knowing that it wouldn’t be a simple topic for outsiders to grasp, with the many different dimensions that Microsoft’s various product teams would use in their own messaging, I wanted to make sure there was at least one article out there that would explain what Dataflex means for Teams, Power Apps and Dynamics 365 in the big picture of business applications. It was great to see that this explanation I came up with was also adopted elsewhere in the mainstream tech media:
Here are some of the topics that the community has raised up since the July 21st announcement, based on the still fairly limited amount of public information that is out there on the coming Dataflex and the rebranded Dataflex Pro (formerly CDS).
Yeah, about that name…
For the small minority of techies who have actually heard of the Common Data Service (or XRM), the need for inventing a new name for their beloved service that remains the same (i.e. Dataflex Pro) wasn’t very obvious. For the larger crowd that works with Office tools and Microsoft Teams, Dataflex is a brand new thing, which understandably has made MS think whether a brand new brand would also be useful at this point.
Unfortunately the name “Dataflex” isn’t so unique that there wouldn’t be some clashing with non-MS products out there. In this case, there has been an existing trademark within pretty much the same application development domains since the year 1981 already.
What do you think about the following post from the owners of the #Dataflex trademark? https://t.co/WAPd9UA6Ut some people say the new #CDS name is ”Microsoft Dataflex” if I started using ”Microsoft nz365guy” I am sure I would get a letter from a lawyer. What do you think?
21 days after launching their Dataflex product name, Microsoft had to cancel their original plans due to litigation from the lawful owner of the Dataflex trademark (Data Access Worldwide). Read this blog post for more details: There never was a “Microsoft Dataflex”.
Why not call it “Power Dataflex” or “Power [anything]” then? Wouldn’t that have been better in line with the whole Power Platform story, as well as reduce the chances of a legal dispute? Probably so, but it’s important to understand that this Power thing actually isn’t the only purpose that Microsoft has in mind for the platform:
#MicrosoftDataflex it is – that is key because it applies to all of the Microsoft Cloud (that’s why no Power Dataflex :)).
The entry level offering of Dataflex for all Teams users is an important milestone for XRM/CDS/MDF (not sure I want to adopt “MDF” as the acronym just yet, actually). Don’t be surprised if the same technology will pop up in more & more places within the MS Cloud in the coming months and years.
Licensing details: TBC = “To Be Confusing”
The specifics of what is and isn’t included with Dataflex didn’t get released yet, as this new service is still pending for the public preview to start sometime in August. At the announcement day it has clearly been more important for MS to higlighlight what you can do with the non-Pro Dataflex vs. what you can’t. Even after the eventual GA, we can expect to see Microsoft use just the term “Dataflex” when referring to Pro capabilities like API access and custom code. When raising this issue of one additional source of Power Platform licensing complexity, Charles Lamanna confirmed that this is indeed intentional:
PowerApps with no spaces is just bad… I am hanging my head right now. Definitely unintentional 🙂
On Dataflex – Dataflex Pro is a licensing option (like Power BI Pro) and not actually a different thing.
This comparison to Power BI actually makes a lot of sense. In fact, much of what has happened with the platform side of MS Business Applications has been taken from the Power BI playbook used in conquering the Nr. 1 spot in business intelligence products within a relatively short period of time. So, here’s how the product levels are positioned over there:
Power BI: free for anyone to use, also for publish to web
Power BI Pro: user specific license required for sharing reports across the organization (non-public)
Power BI Premium: capacity based offering that allows enterprise customers to remove the per-user element from the licensing equation
What Dataflex and Dataflex Pro are going to offer is quite similar to this structure. No, I don’t quite expect the completely free edition of Teams to offer Dataflex features anytime soon, but the bundling into Office 365 & Microsoft 365 effectively makes it free for a huge pool of organizations to start using. When you then need to build some apps that go beyond the scenarios of team specific use cases and want to enforce some organization wide policies on it, Dataflex Pro may quickly become a requirement.
What may initially sound like not a very profitable business model (give stuff away for free) can result in a lot of positive effects on the company wide revenue streams of Microsoft if played right. After all, we’ve already seen the plumbing from under the Dynamics products to being reused as a platform for DIY apps (Power Apps), so this strategy of exposing as many users to Dataflex as possible is a clear continuation of that path.
It's the same question as "why buy Dynamics 365 Enterprise apps when I can build my own on Power Apps". Ultimately it's the scale of Teams that will bring in revenue, even if MS is (again) cannibalizing their previous offering to some extent with #MicrosoftDataflex non-Pro.
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) July 23, 2020
Following the Power BI model, the next logical step after Dataflex and Dataflex Pro would now be to offer a Dataflex Premium service for enterprise customers who are more willing to pay for the capacity rather than for each and every seat. Whether MS ever launch this or not, the question of capacity consumption in terms of storage and API calls is bound to become a big source of confusion with the “free” vs. paid plans for Power Apps. Luckily the team behind Power Platform Center of Excellence Starter Kit is already working on making some of these governance tools compatible with the non-premium resources:
We're still working on the final details, but the plan is for at least the Admin (Core) components to work in Teams with Dataflex & no need for a premium license. With the idea being you have a Teams for your Power Platform admins where they can chat, share files and use the kit
The debate on why you should not use SharePoint lists as your app’s data source vs. why they area a perectly valid option has been going on for probably longer than Power Apps has existed. The inclusion of Dataflex into the core services of O365/M365 subscriptions has now prompted people to claim that app development inside SharePoint should be avoided altogether.
There are plenty of greant points in the blog post by Andrew Welch on the impact that Dataflex will have on the app strategy for organizations. Certainly the old reality of avoiding CDS due to licensing costs will need to be replaced with a more modern view into the low-code application development landscape in Microsoft 365. SharePoint will remain as the service most well known in the Modern Workplace technology category for sure, but questioning whether it’s the right tool for managing structured data should now become a mandatory step in all app plannign discussions.
One thing that’s clearly stealing the thunder from the Dataflex announcement and making the M365 folks even more confused is the GA announcement of Microsoft Lists that took place at the very same time. Yeah, this is just classic MSFT – having multiple products with overlapping feature sets and competing marketing messages.
Teams: your business app platform?
No matter how cool the apps that we build for customers (and ourselves) may be, it’s important to keep in mind that the majority of the average information worker’s time is spent inside applications that are exactly the same for everyone – like Microsoft Teams. This recent news about Slack first claiming Teams is not even a competitor to them, then moving to filing a lawsuit against Microsoft for bundling Teams with O365/M365 subscriptions, tells a lot about the game being played:
After claiming Microsoft wasn't a competitor, Slack is now filing a competition complaint against Microsoft in the EU, claiming it is illegally tying Teams to Office 365: https://t.co/tRdoqCj6yz
It’s a fight for the future of work, which will largerly be remote work. The digital transformation of business processes will require many, many apps that are tailored for a specific task inside a particular organization. Nevertheless, it’s the umbrella above them, meaning the platform for teamwork, that will drive a lot of the technology choices and licensing dollars into the online meeting and remote work ecosystem that provides the different business apps the common context.
If there would indeed be a significant uptake on the modern task based “mini” apps that do one thing well and we’d see organizations abandond their earlier enterprise system monoliths, then the question is where would all these apps logically land in? I haven’t really seen the enterprise app store concept being heavily utilized out there in the real world yet. Nor has there been much hope for Windows to enjoy a similar success with users installing apps from Microsoft Store, like they do all the time with iOS and Android.
It’s been already a decade since the app store concept was first launched for Microsoft Business Applications. AppSource is a great channel for distributing Dynamics 365 and Power Apps solutions in theory, but in practice it’s a lousy marketplace for most ISVs to do business in:
The #MSBizApps store that's been in the making since 2010 and still hasn't been able to deliver results: Microsoft AppSource. If even @stevemordue can't get customers via this channel, it's hard to imagine any other #MSpartner can make a buck from it either. https://t.co/13QzpELulM
— Jukka Niiranen mstdn.social/@jukkan (@jukkan) June 13, 2020
I’m not yet going to claim “this time it’s different” on the Teams app store and the Dataflex powered apps that can soon be published there by both 3rd party vendors and internal citizen developers. The idea however does sound like something that might scale better. Instead of deploying add-ons or templates into the single system of record like CRM, the new Teams based deployment model could allow a smaller group of users to install apps into an environment with a lot more narrow impact on organization-wide processes and data models. This could well be a more logical approach for Power Apps based solutions to find their way into more and more tenants.
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:
At the start of this year, we made the decision to go all-in on Microsoft Power Platform and founded a company that focuses on helping organizations on their journey to take ownership of this low-code business application platform. You could therefore say that it’s pretty darn important for us that there is compelling roadmap for the products that represent the technical foundation of our services.
Luckily Microsoft doesn’t show any signs of slowing down the investments into Power Apps, Power Automate, Power BI, Power Virtual Agents and all the underlying elements of the platform. Our MVP team at Forward Forever already did a “Top 3 x 3” highlights article on what each of us found to be the most exciting feature announcements in the 2020 Release Wave 2 release plans that Microsoft published yesterday. I wanted to expand a bit on that top list and reflect on how I see Power Platform evolving based on this new roadmap information.
But first: what happened to Wave 1?
Ah, true. We’re actually only halfway through the April-September period that 2020 Release Wave 1 represents. This means that many of the features I highlighted in my earlier first impressions posts have not yet shipped. Just because there’s a virtual launch event every six months doesn’t mean that it would be the exact time when a big box full of new software is made available. There are no version numbers in the cloud, it’s a continuous release train that runs on its endless route.
It’s important to keep in mind that these are release plans, not release notes. The thing with plans is that they tend to change, and such is also the fate of some items in 2020 Wave 1 that I picked as the higlights in my post back in January. If we look at the change history page in the release plan, for Power Apps alone we see that 15 items had their release schedule changed and 7 were removed from Wave 1. And remember we’re only a bit over 50% through the April-September period, so more changes are bound to still occur.
Changes do happen for the better, too. 8 new features have been added for Power Apps already after the initial release plan. In total there are one hunderd new features added to 2020 Release Wave 1 after January 27th. Wow! I can’t recall how many items in total there were originally, but this really highlights two things:
The Release Plan is not a static document, rather it’s an evolving backlog of planned features.
Microsoft has been very actively maintaining the online version of the Release Plan over on docs.microsoft.com.
This is what the product roadmaps for clour services are like today. You can’t simply have a look every 6 months and then forget about them, rather you should always refer to the latest information online. Also, you can be 100% sure that there will be a lot more coming for Power Platform between October 2020 and March 2021 than this first Release Plan version reveals. Just look at Wave 1: we would not have seen from the plan that MS would acquire an RPA vendor like Softomotive, or that they would announce T-SQL support for CDS during MS Build. Get ready to be taken by surprise during Wave 2 as well!
Wave 2 features to keep an eye on
Portals Web API with CRUD support was big news in Wave 1, but the GA date for the feature isn’t until February 2021. It’s all part of the story where Portals is being made more compatible with the two other app types in the family. Wave 2 now promises a preview of PCF control support for Portals in December 2020, which should certainly be a nicely wrapped Xmas present for pro devs if that schedule will hold.
If Portals is getting closer to the mainstream Power Apps types, then the unification of Canvas and Model-driven apps into “Run One UI” is also moving along. By the time the custom pages feature hits public preview in December 2020 it will have been 18 months since we saw the roadmap, but I’m not actually that surprised it’s taking a while for making these 2 very different client technologies work in harmony. It’ll surely be worth the wait from an UX perspective, as the Canvas app embed story has been somewhat limited in its impact so far.
Once Canvas apps can be natively placed on pages that appear inside the app navigation, they’ll be ever more likely to become an integral part of more complex enterprise applications. This means that also Canvas development practices need to become more mature, which is exactly what the reusable components for business logic are aiming for. PCF components for Canvas apps are also critical to allow the pro dev audience to contribute into low-code app development projects. Code components have already been in preview for a while and GA is expected in March 2021, so obviously injecting custom code into what was originally designed as a “PowerPoint + Excel” experience for citizen developers is a big investment that takes time to polish.
Power Automate has grown into an all-encompassing process automation service that covers both API and non-API (meaning RPA) scenarios. I have to say that for me personally it’s one of the scariest parts of this “low-code” platform due to how much secret formula knowledge one must posses to achieve something where XRM workflows offered a full GUI experience. I’m glad to see that MS is investing not only in the UI flows territory from their Softomotive acquisition but also in making Power Automate work more seamlessly with Power Apps. Simplifying things even further, the coming “diet designer” and templates desined for Microsoft Teams users is an example of how broadly the PaaS foundation of Azure Logic Apps is being productized via its Power Automate UI experiences across the whole MS stack.
From the Data Platform side, we will finally be seeing the ability to use Power BI on system dashboards for Model-driven apps. It’s one of those things that the vast majority of customers probably would have assumed to be possible for ages already. Getting proper support for parameters like environment variables has been a prerequisite to make these components play well together in the Power Platform ALM story. Now, this still doesn’t mean PBI would replace the built-in visualizations from CRM 2011 era, rather we see that MS is actually only working on catching up with the year 2011 when it comes to Unified Interface charts customization (i.e. supporting ASP.Net chart XML based features with the new Highcharts).
Come to think of it, there isn’t a single mention of the TDS endpoint / T-SQL support in either 2020 Wave 1 or 2020 Wave 2 release plans. It’s a good reminder to everyone that despite of the huge volume of information in the release plans, they don’t reveal the complete story of what’s happening with Business Applications beyond the immediately visible end user and app maker features. You’ll still need to do a bit of 1+1 yourself to figure out how things like DirectQuery support enabled by the TDS endpoint might have a dependency on unlocking more modern visualizations on top of CDS data in Power Apps.
While creating charts on a sales pipeline etc. could be seen as just doing old stuff with new tech, what’s really net new in terms of data analysis capabilties is all the goodies coming into CDS integration with Azure Data Lake. Time series data: get the full historical values of business record in a format that you can actually report on (i.e. not audit logs). Soft delete support: instead of keeping all historical data in that fairly expensive CDS database storage, delete the transactional record but still keep the data in the analytical system. Support for entities with attachments: if you’d like to get some value out of the annotation data clogging up your CRM system, push it into the Data Lake where AI can crunch it and generate new insights from it. All in all, this built-in continuous replication of data from the Power Apps / Dynamics 365 app database into Azure Data Lake seems to be truly delivering on the vision of The Real Common Data Service that goes far beyond the boundaries XRM used to have.
If getting data out of CDS is evolving, so are the mechanisms for getting data in. Power Platform dataflows have a lot of potential for sure, yet just like with Power Automate, it’s been difficult for these new generic cloud services to complete with the built-in XRM tools when it comes to feature completeness for CRM customers to achieve their common business goals (use a GUI to automate a process, run a Wizard to import relational data). Power Automate already has the path to “upgrade” the business logic into Azure Logic Apps and now also Power Platform dataflows can grow up to Azure Data Factory, once the March 2021 preview arrives. In the big picture, this ability to start from citizen developer tools and then transition to pro dev methods and systems is a very powerful value proposition from Microsoft to all their customer organizations who are looking to empower their subject matter experts to take steps forward in the day-to-day digital transformation. App creation & automation is where this Maker revolution has started, and I bet we’ll see more and more data driven features in the next phase of Power Platform evolution.
Finally, as the number of apps grows and they become an irreplaceable part of critical business processes, there’s a growing demand for tools to ensure the digital machine is well oiled. As we know, data is the new oil and in this context that means organizations need broader access to telemetry data on how their business apps are working. The 2020 Wave 2 feature that promises to deliver CDS errors, performance data, and diagnostics data in customer’s own Azure Application Insights should do exactly this, by complemeting the built-in metrics available in PPAC with a way for customers to build their own alert systems for both proactive and reactive maintenance. Yet another “grow up to Azure” path that illustrates how closely the low-code application platform-as-a-service will be intertwined with Microsoft’s PaaS offering.
Application Lifecycle Management, ALM, is a topic rarely covered in the mainstream pitch for how low-code/no-code solutions are transforming app development practices. This is understandable, since the initial time-to-value, from an identified business need to a working application (or at least a functioning prototype of one) is where the major difference to the traditional software development initiatives are easiest to demonstrate. It’s the “five minutes to WOW” effect that gets most of the attention.
Relying on configuration and formulas over custom code does promise also a lower maintenance overhead for the post go-live phase where the apps are used and evolved gradually to remain in line with the business requirements. There is less to worry about the potential impact of changes in each of the underlying components that keep the app running when you’re subscribing to a service like Power Platform that aims to abstract away many of the moving pieces in Azure and other related cloud services.
You shouldn’t assume life to be completely worry free, though. If you don’t plan ahead on what type of work is needed after the creation of your low-code app, then a nasty surprise may lie ahead for someone, somewhere, at the most inconvenient time. In the worst case your organization has become reliant on an app that no one owns & no one knows how it works, only to realize that your processes have already stopped due to errors caused by a change either inside or outside the system. Updates to the cloud components or changes in APIs used via Connectors, for example. A slower yet equally frustrating problem can arise from identifying a future change you’d really need to implement for the app in question, yet you don’t have the means to make that happen in practice.
The rise of low-code application development and the forecasted arrival of 500 million new apps in the next 5 years is making IT organizations very aware of the need for setting up governance models to address this new reality. Having baseline knowledge of what apps are created, by whom, for which audience, for what purpose, through what technologies, on what data sources etc. is often the discussion that needs to be done first to analyze the current situation. A great tool for facilitating this is the Power Platform Center of Excellence (CoE) Starter Kit, which gives you an overview of the big picture for Power Apps and Flows in your tenant. To go deeper and actually manage the lifecycle of an individual (potentially business critical) application, we need to start discussing ALM.
What is this ALM thing anyway?
Microsoft has published fresh new documentation on ALM with Power Platform that could be viewed as a similar Starter Kit for this topic as the aforementioned CoE. It briefly covers the high level summary of what ALM means:
ALM is the lifecycle management of applications, which includes governance, development, and maintenance. Moreover, it includes these disciplines: requirements management, software architecture, development, testing, maintenance, change management, continuous integration, project management, deployment, and release management.
A very broad concept then. What I like most about this intro chapter is the definition of the goal of ALM: “driving efficiency through predictable and repeatable software delivery”. That’s the essence right there. Anything that reduces the differences between how individual app makers / developers perform common tasks within the whole lifecycle of a specific business application will improve the state of your ALM practices. Those with a software development background may immediately venture into thinking about various DevOps methods and tools at this point, whereas I’m always most concerned about how the business can get a grip of what exactly is happening to their applications over time. Who built what, based on which specification, when was it deployed & where to, how were the changes documented, what impact did it have on others systems, how were users educated on the new features, and so on.
Microsoft’s ALM guidance is mostly revolving around the technical level specific to Power Platform, meaning how solutions and environments should be used. If you haven’t heard it before, then the solution framework that was born in 2010 for the XRM era has been actively expanded to cover more & more areas that are not a part of the Dynamics 365 Customer Engagement on-premises server. Canvas apps, Flows, AI Builder models, Power Virtual Agent chatbos, Export to Data Lake configs, pretty much everything in the Power Platform is now manifested as solution component. More is on the way, based on how Matt Barbour has stated things like Power BI and integration services being “on the radar” for the Power Platform solution system.
The expanding technical capabilities and scope of components shipped via solutions is of course great news. However, as we are now talking about the platform for every developer, not just pro devs, my number one question about Power Platform ALM is not “will it scale up to new products and features” but rather “will it scale down to new types of apps that don’t follow the lifecycle of a CRM system?” So, there’s two dimensions I feel will be critical for the ALM story to succeed: 1) unifying the mechanisms to manage configuration & code across the different app teams within MS Business Applications Group, and 2) democratizing healthy ALM practices by making them accessible to citizen developers. The first one is well underway with the solutionization of everything, but how about the second one?
Managing your “source low-code”
The fundamental challenge with why ALM tools aren’t already a part of every Power Apps maker’s or Dynamics 365 customizer’s core workflow is that they don’t exist within the context where these people do their work. This audience doesn’t need Visual Studio for anything, nor would there be anything familiar with the terminology used by version control systems like Git. This is alien technology from Planet Developer, which the no-code app makers would have to learn specifically for the purpose of managing how their configuration deliverables are moved from one environment to another. Compare that to the “export solution as .zip” / “import solution .zip” actions availble in the Power Apps Maker GUI that gets the job done for them. Many of these app makers surely understand the value that a formal deployment process and solution versioning could offer, but the barrier has been much too high for them to make that leap.
There have been tools for pro-code developers working with XRM solutions for many years already, some provided by MS and many built by the community. Today there are official Microsoft Power Platform Build Tools available for Azure DevOps, which offer readymade tasks like solution export, import, unpack, pack, publish, with more features to come. Rather than tweaking PowerShell scripts, it would seem like there’s a way to visually configure the cloud to do some ALM magic for our low-code apps. Sure, this is not within Power Apps directly, but could this be considered just another admin portal that the citizen developers might learn to navigate?
Setting up an Azure DevOps pipeline that pulls solutions from your dev environment, commits them into a repository for version control and then deploys that same solution to test or prod still isn’t exactly a next-next-next process. However, following a Power Platform specific tutorial, even a non-developer like me can get this up & running in a few hours. MVP Nick Doelman has written exactly what I needed, so if you’re interested in building your very first ALM pipeline, I recommend you to try this out:
Combining this with a recent update to the Power Apps Build Tools that also introduced support for MFA protected environments (meaning you can log in with an Application User identity), I was able to get our company’s “CRM” solution’s customization changes from from Dev to GitHub and Dev to Prod. Here’s what it looks like now when adding a new field on the accout entity:
“Woo-hoo, we now have proper ALM in place!” Well, not quite. All that we really achieved with this was the possiblity of doing it “right”, meaning there are DevOps pipelines that could be used for handling configuration changes automatically instead of manually by individual low-code developers. Until I actually go and remove all Power Platform service admin roles from my colleagues, anyone of them could still go and mess up the production customizations directly. So, proper ALM is only partially about the tooling and automation – you still need to the exact same thing as without DevOps, meaning defining the processes and agreeing on the practices for how the business applications are managed.
Regardless of this, it does makes perfect sense for low-code app development projects to evaluate if they would get benefits from leveraging automation tools like Azure DevOps. You’ll need to have the solution configuration stored somewhere anyway, so why not put it in a version control system that’s designed for “real code” and gain access to things like viewing the changes of individual solution components – rather than just dumping the files on OneDrive/SharePoint. Who knows, taking that step might even unlock further opportunities to automate and harmonize your application management processes.
We should keep in mind that automation is a double-edged sword. In theory it can save you a lot of time, yet in practice it may often turn into an additional time sink of its own. The legendary webcomic XKCD beautifully illustrated this dilemma of Automation, which I think is especially true here in the ALM discussion. The tasks that you’re trying to automate need to happen on a frequent enough basis for a long enough time before you could achieve a positive ROI from investing in setting up your pipelines. A single citizen developer building a one-off app may not yet meet that threshold, so preferably in your automation scenario there should be a team of developers who will do several planned releases for the app in question.
ALM for a team of low-code developers
Microsoft likes to promote the stories of Power Apps Champions who have managed to make digital transformation a reality for their organizations by building low-code apps that would have earlier required a team of software developers. This marketing approach higlights the role of an individual hero, but from an ALM perspective the dependency to any individual person’s heroic actions and secret knowledge is rather a problem that should be solved. Once that initial app idea and first PoC starts turning into something business critical, you should have a team in place that can ensure its continuity.
This team may not resemble your typical software development team. Yes, it’s quite likely that there will also be people with programming skills either working in the team or closely with it, but the primary competence on the technology side for this team is in assembling the features and components of the chose application platform into solutions that solve a wide variety of business problems. They are less likely to be all working with the single code base of a large application, doing pull requests, commits and all that Git jazz, simply because a fair share of Power Apps aren’t going to be built that way at all.
If you look at Power Apps Canvas apps today, they are essentially a document made of JSON that cannot be simultaneously worked on by multiple developers. This is very different from a traditional app project on the Model-driven side (let’s say in a CRM context) where one person could be building the customer data management features while another team member is working on products and order management. All with their own dedicated entities, having so little overlap that simultaneous work within the same dev environment is often doable. Even though Components promise to offer a more modular way to build capabilities for the Canvas world (and Model, too), I suspect that the client side experience of a single app will typically remain a “one maker show” in the near future.
Sharing elements and patterns across different apps built and managed by the team is, on the other hand, in a much greater role in the low-code approach. Here components, template apps and other reusable pieces of configuration can be of high value. Power Apps began its journey as a citizen-first app creation experience yet is gradually accumulating more of these features that mean every app doesn’t have to be a unique project. We’re getting more & more possibilities to see beyond the Maker GUI, like “peek code” in a Flow or use Monitor to debug Canvas app formulas. However, based on what Microsoft representatives have publicly said, it doesn’t sound likely that these low-code tools would evolve into allowing app makers to directly manipulate the configuration files in VS Code, for example. There are community tools like CanvasAppPackager from MVP Daryl LaBar that will help app developers understand complex Canvas apps, but these are NOT meant for building or modifying apps.
Even in Model-driven apps the list of supported modifications for customizations.xml is fairly limited. So, keep this in mind when thinking if the pro-dev tools and ALM practices that are based on direct source code manupulation are going to be a fit for the low-code app developer team or not. Your Power Platform experts need to be primarily fluent with the admin tools from MS and the community (always start from XrmToolBox), plus they’ll need excellent skills for using collaborative tools like Teams within your org to share their lessons learned. Once you’ve got this side is covered, then you can move onto Azure DevOps and the likes.
Environment management is another big topic for low-code apps on Power Platform. Having a separate CDS environment for every developer working on their corner of an application is Microsoft’s recommended approach to keep changes isolated. As your number of “ALM enabled” apps in the tenant will grow, the total number of environments will grow even faster. Assuming a theoretical 5 GB size for the CDS database of an environment, the $200/month storage cost itself wouldn’t actually be that significant if it saves a few hours of work from those developers. What you don’t want to happen, though, is having dormant dev environments consuming CDS capacity for many months with no actual deliverables from them – especially when your CDS quota is defined on a tenant level with no control available for reserving it to specific apps/environments.
There are remedies to this problem. The “governance way” is managing the environment creation/deletion though a process that provides transparency to environment usage and enables allocating costs accordingly, for example via custom apps built on top of the CoE Starter Kit. The “ALM way” is provisioning on-demand environments from the source code in your repo via DevOps automation, then scrapping them after the active development work stops. While I sort of fancy this idea of “everything as code” where all of the infrastructure and configuration is managed via the same pipeline, I can’t help thinking that the most difficult thing about environments for business app development isn’t necessarily the configuration or the code. It’s the valid test data needed for making the app come alive. Yes, of course you could also script the perfect test data set to be generated alongside the environments, but again, we’re taking the level of effort needed in achieving deployment automation onto a very non-citizen developer level and approaching the XKCD scenario.
Managed Solutions: what do you REALLY want to manage?
Whenever Microsoft talks about ALM, usually you’re going to hear their statement on “use only managed solutions in production” sooner later than later. It’s not surprising that also the latest guidance, such as the MBAS 2o20 sesssion on Advanced Application Lifecycle Management capabilities lists this high up on the ALM Health Check list:
In the user community around XRM there’s been an endless debate around whether unmanaged or managed solutions are really the way to go, and we’re not going to find the ultimate answer to it here in my blog. Personally, I’ve always had a hard time understanding the exact benefit that a customer organization would get from self-imposing the limitations of managed solutions onto themselves. It just sounds to me like installing a different lock with a dedicated key onto the window blinds in every room of your house. Expensive, overly complex, and very likely to leave you in the dark when someone forgets which key was used for which lock. It can also give you a false sense of security, as the main door to your house is still left completely unlocked, because Microsoft doesn’t yet offer a way to protect your production environments from the deployment of unmanaged customizations by anyone with sysadmin rights.
In the context of low-code specifically, if you don’t have a seriously mature ALM process in place, I’d say you’re fairly likely to hurt yourself when playing with the sharp objects that are managed solutions. This is why during my 10 years of working with Dynamics CRM, XRM and now Power Apps, I haven’t yet deployed a single managed solution inside a customer specific project. On the other hand, I have worked with removing managed solutions created by the customers’ previous partners, after the ALM process has broken down for one reason or another (“not existing” being one of them), then replacing them with an unmanaged layer of customizations that has been a better fit for their overall CRM landscape. Yes, those other partners probably defaulted to following MS instructions on using managed solutions in every production environment – this guidance remained the same since CRM 2011 days, after all.
Please do note that I’m not saying managed solutions wouldn’t serve a purpose. When you are building an actual app product that is meant to be deployed across multiple environments for different customers, managed solutions are of course the way to go. They offer the container for keeping your stuff separate from the stuff delivered by other app vendors, when deployed into the single CRM system that’s used widely across the enterprise by different user groups for different processes. Any proper commercial product development initiative should also be able to absorb the ALM overhead from environments, automation etc. and turn that into increased revenue from being able to ship software releases faster and more reliably as time goes by, thanks to the upfront investment made. It all makes sense here, but this is a very different landscape than how I perceive the typical use cases for low-code apps within organizations to evolve as Power Platform becomes more widely adopted.
Remember: you’re no longer building “one place for all customer data”, rather you’re often creating several targeted apps for very specific purposes and audiences. Most of these app experiences will likely be fully developed by either savvy citizen developers, an in-house team of Power Apps champions, or an external consultant brought in to get that job done. The app lifecycle can be very short, even targeted to be used in one-off events (or under temporary disruptions such as COVID-19 social distancing), whereby some apps may actually be “disposable by design”. These are pretty much the opposite of monolithic CRM systems where a wealth of different ISV solutions need to peacefully co-exist throughout the years. So, whichever solution strategy you choose for your Power Platform environments, make sure it solves a real problem that your low-code app developers and admins are facing, rather than directly adapting practices that have been designed for the ALM needs of pro-developer teams working full-time on shipping a sizeable amount of custom code alongside the low-code application platform configuration information.
A different approach to ALM: Power BI deployment pipelines
The broad umbrella of Microsoft Power Platform covers also technology that isn’t (currently) built on the solution framework: Power BI. Since it is in practical terms more part of MS Data Platform, the mechanisms used on the BI side are understandably quite different than those originating from the citizen-dev PowerApps (back when it was still spelled together) or CRM systems. What makes this an interesting area to observe is that from what I’ve understood, the traditional development of reporting solutions hasn’t exactly followed the typical software development path either. Checking in reports to source control systems may not be the natural workflow of a Power BI content author or data analyst, so the barrier for adopting advanced ALM practices is likely to be pretty high for this audience, too.
Power BI deployment pipelines is a feature that has recently been launched in preview. Labelled as an ALM solution, as also Power BI now packages report content into “apps”, this functionality is actually baked right in to the native user interface of the PBI service:
Reading the introductory text gives us an idea of how this feature is positioned:
Deployment pipelines help enterprise BI teams build an efficient and reusable process by maintaining development, test, and production environments. BI creators can incrementally transition new or updated content between environments, reconfiguring them with the appropriate data connections and permissions. Pipelines are very easy to use and take only few minutes to setup. No previous expertise or coding skills required.
Wouldn’t it be nice if we could take the term “BI” from that paragraph, replace it with “App” and have a similar story to tell for low-code business app developers? A targeted experience that would be readily available for each & every customer environment right out of the box would certainly be the most effective way to democratize healthy ALM practices.
You’ll need Power BI Premium capacity for using deployment pipelines, so the reporting ALM story is aimed towards the enterprise audience. If there ever was a native deployment pipeline functionality for Power Apps, I’m sure the usage would require consuming some type of paid for capacity from the Power Platform product subscriptions. I believe this would still be a lot easier approach for selling the idea of why customers need to invest in having proper ALM infrastructure and capabilities in place, since it wouldn’t be just an extra layer of billable hours added on top of app development project budgets but rather something much more tangible.
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:
It’s hard to avoid this question whenever people discuss the business scenarios for Microsoft Power Platform. The tools and experiences for creating apps are getting more & more streamlined, yet it feels like the complexity of rules on what licenses are needed for each specific scenario just keeps growing. With great powers for designing creative new solutions comes also great responsibility for understanding the commercial factors of implementing them. This means that the solution architecture needs to take the licensing aspects into consideration, even if many technical people aren’t very comfortable with the topic.
The main factors I consider to be sources of complexity in the licensing discussion around Power Platform, Dynamics 365 and Office 365 are these:
Protection of intellectual property as well as development budgets across Microsoft product portfolio
The old world of apps as data silos & the concept of multiplexing
Light use scenarios for information workers vs. “Real Business Applications”
The role of CDS (now: Dataverse) as the platform, not just a data source/target
I’ll cover each of these dimensions in a separate blog post, to avoid building up too many stress factors into a single post and scaring away people. None of these obstacles are insurmountable, instead I believe raising awareness of them will make it easier for everyone to answer the question of “why” and move on to the “how” part of planning the actual solutions and business cases for leveraging the full potential that lies within the Power Platform.
Let’s begin from the complexity source nr. 1: Microsoft’s product portfolio structure.
Protecting the products & investments
XRM, the predecessor of CDS and partially also Power Apps, was never sold as a platform. The business model was built around selling a suite of CRM applications, which you could then customize and extend to cover business processes not originally within the scope of the product shipped by Microsoft. This meant that a lot of money was left on the table because customers that weren’t looking for a new CRM system didn’t really have much reason to consider XRM as a platform their other business apps needs. From the perspective of Dynamics CRM as a product, there wasn’t much threat of competing apps within the MS ecosystem, but unfortunately it also meant that investments into the core platform weren’t likely to grow very fast if the Dynamics offering was to remain outside the mainstream product portfolio of Microsoft.
Now that Power Apps is offered specifically as a platform where your citizen developers, pro developers and ISVs alike can all come and build their apps, the upside to everyone is that the common infrastructure for data and application management is evolving crazy fast. The new problem that arises from this is the battle of the internal buckets where money should be flowing in. Unless all customers unanimously purchase both the platform (Power Apps premium licenses) and the first party applications (Dynamics 365 Enterprise Apps), someone could easily consider their bucket to have a leak caused by these new buckets. Cannibalization of revenue is a rational fear to have when there is overlap between product offerings within the organization.
The way how Power Platform has been positioned as the extensibility layer for both Office 365 and Dynamics 365 is undoubtedly one of its key strenghts from the business perspective on Microsoft level. PP is everywhere because so many customers already have it, underneath their existing information worker tools and CRM systems, whereas low-code competitors like OutSystems or Appian will need to find a way to get their foot in the door somehow. However, this mechanism of having “seeded” Power Apps and Power Automate features inside other products just delays the commercial discussion to a later point in time. “Why do we need to buy these new premium plans if we already have the Office/Dynamics features?”
Before Power Apps merged with XRM, what we know call “Canvas apps” were introduced to the markets as a technology that could easily work with the ubiquitous Office 365 services as data sources. The same with Microsoft Flow. I believe this really was more of a marketing positioning strategy rather than a deep architectural commitment from MS, since many experiences weren’t really that seamless once you got down to working with SharePoint, for example. Still, this approach made it possible for the community of citizen developers to start gathering around Power Apps, when power users all over the world discovered how they could go beyond Office 365 standard capabilities with these no-code tools – while still remaining within the existing corporate licensing of Office tools offered by IT.
Had Power Apps and Power Automate (Flow) remained there as just tools in the Office waffle that come with the subscription, we would have likely seen only a tiny fraction of the features that now are rolling out into Power Platform. After all, if you’re not paying any additional licensing fees for the products, then are they really products in themselves at all? “Freebies” like Sway or Bookings that we’ve seen appear in the cloud service nowadays known as Microsoft 365 are examples of what you could expect from technology that isn’t large enough to warrant a SKU of its own in the MS product portfolio. Not a very lucrative position for any ambitious app team in the long run.
There’s this dilemma that if you raise the barrier of entry too high for a product, the adoption curve is going to take a hit and you’ll miss out on the viral effect of “free” software. At the same time, if you can’t directly tie the usage rate into a visible stream of new money, it’s difficult to collect funding for product development investments beyond the initial hype and excitement of launching something new & cool. In the enterprise software business you can’t even monetize the users by exploiting their data and eyeballs for selling ads, because privacy and confidentiality tend to be bigger factors here than in the consumer market (where unfortunately everything is moving to “pay with your data” business model). Just look at the example of Google, who did build up their own App Maker product into the G Suite, then saw too low usage numbers for it and ended up killing the service and customer apps built on top of it. Now they’ve acquired the low-code application development platform provider AppSheet and are trying to gain a foothold in this growing market.
While this explains why Microsoft couldn’t just keep the doors open for ever more advanced Power Apps development on top of exisiting Office 365 subscriptions, there’s also the other direction to consider. At some point these apps become so advanced that they’ll start to challenge the Dynamics 365 applications formerly called “CRM” or “Customer Engagement”. These commercial apps from MS are nowadays just called “model-driven apps in Dynamics 365”, which further underlines the role of Power Apps Model-driven Apps as the infrastructure that makes these apps tick. They are preconfigured instances of applications on top of CDS, but they are not the same as the platform itself. Therefore, starting from October 2019, buying a Dynamics 365 Enterprise App no longer gives you an Access All Areas pass to using apps in just any vanilla CDS environment that hosts a custom app for process X. You’ll need to be wearing the lanyard that specifically says “Power Apps” if there’s not Dynamics 365 applications installed in the environment you want to enter.
In short, buying the Dynamics 365 product doesn’t give you the Power Apps product, just a “seeded plan” to work within the boundaries defined by the application context. The same holds true the other way around: buying a Power Apps Per User license doesn’t grant you the rights to use everything that’s running on the platform within the tenant. Similar to how ISVs (independent software vendors) would charge you a fee to use their application features via their own licensing mechanism, Microsoft is setting up mechansims that will control who can access which App Module.
Regardless of how that might sound like initially, I believe it could actually be a good thing in the long run. The reason being that the way how Microsoft has previously attempted to limit access to the schema and data of CDS by drawing lines on restricted entities available only to Dynamics 365 license holders (aside from data read operations) isn’t really going to be a sustainable model. In his third chat with MVP Steve Mordue, the Corporate Vice President of what MS internally refers to “Citizen Application Platform”, Charles Lamanna, has stated that an alternative licensing model is being prepared right now:
“So there is something in the works that we’re working towards and I would say at a high level, restricted entities as a concept are largely antithetical to our common data service, common data model and vision. And they were just like the least bad option to go make sure that we appropriately can license Dynamics apps. So we are working feverously on many proposals to get out of that restricted entity business, but still have a model which more appropriately captures and protects the value of the Dynamics apps without introducing restricted entities.”
I’ll dive deeper into the whole Common Data Model (CDM) discussion in the next part of this blog series. In general, what I believe to have been a big barrier for the licensing options available to MS work with is the amount of effort needed in making the application/platform separation initiative a technical reality. It has surely been also holding back many teams in terms of how a specific Dynamics 365 App like Sales can deliver features that differentiate it from the sea of business applications that are to be built on Power Platform, by citizens, by customer development teams, by ISVs. A level playing field is needed for the future solution ecosystem to bloom, yet in the short term it requires work behind the scenes that doesn’t surface as application features directly.
The fact that such investments and also compromises have been made during the past couple of years is a clear signal of how Microsoft believes the demand for its different services will evolve & how they will be competitive because of their dedicated low-code application platform product offering. Customers will continue collaborate via Office 365 productivity tools, likewise they’ll keep on adopting readymade business applications from the Dynamics 365 family of Apps for scenarios like omnichannel customer service. There in between lies the opportunity for 450 million new low-code apps to be built within the next 5 years, as Charles Lamanna states in the recent CNBC article “Next frontier in Microsoft, Google, Amazon cloud battle is over a world without code”.
It is not a market that the Office products could easily rise to cover, nor is this bottom-up innovation a natural fit for the Dynamics way of delivering top-down enterprise systems. A dedicated product offering is needed here, which is why the Power Platform exists. Since Microsoft has chosen not to follow the “buy” path of Salesforce, Google and other competitors, but has rather adopted a “build” strategy to create their low-code application development platform from in-house technology, many of the elements in this platform have already been used somewhere else, and as a result also commercially licensed for scenarios that predate this new low-code era. This is the reason we’ve seen so frequent changes in the licensing model across Power Apps and Dynamics 365. It is a source of licensing complexity that is difficult to avoid when the different apps don’t live in their dedicated silos but rather share so much of the common platform capabilities.
Microsoft talks a lot about having three clouds: Office 365, Dynamics 365 and Azure. Where Power Platform fits in is right smack in the middle, and with plenty of overlap in relation to the existing clouds. It’s a new “aPaaS” layer added between the SaaS apps of Office & Dynamics and PaaS/IaaS offered by Azure. As a result, the relative position of existing products needed to shift a bit, which created a before/after dimension into both how Microsoft envisions each cloud to be used and as well as how they commercially offer the services to be licensed.
Other parts in this article series can be found here:
Our company, Forward Forever, is 1 month old today!🥳 It’s truly been exciting times starting a company that goes all-in on Microsoft Power Platform. And that’s even without considering all the surprise elements that COVID-19 is bringing into the equation right now…
The start of April also happens to be the official launch moment for Microsoft Business Applications 2020 Release Wave 1. Since MS will host their own Virtual Launch Event on April 2nd, we though this is a good moment to also set up the first ever FF webinar. So, without further introducions, here it is:
Please join me, MVP Timo Pertilä, Jouko Nyholm and Lasse Teeriaho in our 2020 Wave 1 Release Highlights webinar on Monday, April 6th, 11:00 AM (Central European Time). We’ll be talking about the coolest Power Apps, Power Automate, Power BI and Dynamics 365 features in this April-September release wave, as well as analyzing the many demos that MS will undoubtedly show in their own event.
Just fill this Forms Pro form, which will create a record in our CDS, then trigger Power Automate to send you an ICS calendar invite file hosted on my OneDrive. The link for the Teams Live Event will go live on Monday, if everything works according to plan. Yes, obviously we need to be dogfooding these tools in everything we do😊
Register for our webinar!
First 50 people get in for free, the rest will have to… Oh, alright then – you’re all welcome to join our event, no strings attached.
NOTE: This post was originally published in March 2020, the last revision of pricing information is from November 2022.
As of today, there isn’t a single place from where to check the actual prices of the different license types covered by the Microsoft Power Platform suite of products – like there is for Dynamics 365, for example. The information of prices vs. what paying that price actually entitles you to is distributed across several information sources and formats – starting from the individual product pages, to the learn.microsoft.com documentation pages, to the PDF licensing guides.
To stop myself from having to always use a search engine to discover these pricing details, I decided to compile a list of links to the places where each individual Power Platform product team has made their pricing information public, as well as write out the current subscription prices in US Dollars and Euros. I’ve also included a few relevant licensing model elements that describe what the particular subscription entitles you to do (capacity, features and so on).
Most of Power Platform product licensing is done via the prepaid subscription model familiar from Microsoft 365 (Office 365). More recently the pay-as-you-go (“PAYG”) option has been introduced for some of the services, allowing payment via an Azure subscription (read more about the November 2021 announcement here). It’s important to note that in general prepaid subscription prices are cheaper than pay-as-you-go. The PAYG option is primarily aimed as an option for customers to use, before they know the true consumption level and are ready to commit to a prepaid subscription. Where applicable, I’ve included the PAYG prices here for comparison.
Your actual licensing costs will of course depend on the types of agreements your organization has with Microsoft. So, consider the prices on this page as mainly a starting point for understanding the relative costs of different Power Platform services.
Allows you to access one Power Apps app (canvas, model-driven, portal/website).
The same app in different Power Platform environments (dev/test/prod) requires a per app license for each environment.
Pay-as-you-go option: $10/monthly active user/app/month
Power Apps per user plan: $20 (€16.90)
Allows you to access an unlimited number of Power Apps (canvas, model-driven, portal/website) in your tenant.
Can also be used for accessing canvas apps shared to guests in another tenant (not applicable to other app types).
Power Apps pricing change on October 2021
Before Oct 1st 2021, the Power Apps per app list price was $10 and Power Apps per user $40. See this blog post for more details on the price reduction as well as changes in the per app license entitlements. Note that your license agreement may still apply to the old terms, based on the contract duration.
AI Builder capacity add-on: $500 (€421,70) per unit per month
Each unit contains 1 million service credits on the tenant level
Allows the organization to use any of the AI model types included in AI Builder
AI models consume service credits when they are trained, used in an app or flow, or scheduled to periodically run. The amount of capacity consumed varies based the AI model, as well as the size and complexity of the data set. See AI Builder calculator to estimate the capacity requirement and cost of your model.
Add-on requires at least one paid Power Apps, Power Automate or Dynamics 365 license
For the built-in Business Card scanning feature in Dynamics 365 Sales, there is free capacity included in Sales Enterprise App licenses: 10 scans per user per month, pooled at tenant level. Sales Insights has a capacity limit for business card scanning of 200/user/month. If additional Business card scanning capacity is required, Sales Enterprise customers may purchase additional Sales Insights licenses. (Taken from Dynamics 365 Licensing Guide PDF document.)
Power Virtual Agent: $1,000 (€843.20) per 2,000 sessions per month
Allows the organization to have an unlimited number of bots
In addition to the tenant license, internal users will need to be assigned a user license. The tenant license costs money, but the user licenses that are purchased via the same mechanism are apparently free.
“A session is an interaction between the customer and the bot, and represents one unit of consumption. The session begins when an authored topic is triggered. These sessions are referred to as ‘billed sessions’ in the product. Sessions are deducted for both testing and production usage.”
This Monday we publicly launched our new company: Forward Forever.
There are many reasons for why we as a team of experienced professionals in Microsoft technologies wanted to build a company of our own, which I’ll talk about later once we are actually fully operational and have shown how we operate. Right now, though, I wanted to explain why we’ve decided to go all in with Microsoft Power Platform. It boils down to the interplay of three elements: data, apps, processes.
Data
James Phillips, President of Business Applications at Microsoft, said in a recent interview (behind a paywall):
“These applications, Dynamics 365 and the Power Platform that sits beneath are designed to be data first, designed to allow you to collect data from across the organization, from all of your various systems and to analyze that, to deeply understand it and to predict. And that’s what’s leading to I think the success that we’re seeing in the market.”
The idea of data-first design as opposed to app-first is very much in line with what we’ve seen happening in the Dynamics 365 product portfolio during the past 1-2 years. Microsoft has placed big emphasis on making the traditional systems of record more intelligent by building various Insights products to broaden the Business Applications stack as well as bringing Insights into the familiar sales, service and marketing apps. Since there is no AI without data, building the connectivity from Dynamics 365 and Power Platform into as many existing business data sources as possible is where the Business Apps are heavily relying on the R&D of MS Data Platform to outrun the competition.
Even before James, the leadership team at Microsoft revealed their true ambitions of grabbing a much bigger share of the pie than what CRM & ERP as an app-first market could offer them. Already back in 2016 when I was visiting Redmond, the leaders of the product engineering for Dynamics CRM at the time were describing the two sides of the complete end-to-end offering as Transactional Stack (XRM) and Analytical Stack, giving us the following guidance:
“Analytical Stack will be 10 times more powerful than the Transactional Stack. This is where you need to be. Transactional apps will be commoditized, monetization will happen on Analytical apps.”
That moment really stuck with me. While I knew that such forward looking statement probably wouldn’t have a visible impact on Dynamics partner business within the next year or two, it was obvious that these targets Microsoft had on turning things around with their intense focus on data would eventually shake things up. The products would evolve into something different and so would the competence demands for anyone working with them.
Apps
There is a lot of power on the commoditization side of the stack, too. If we look at things only from the traditional business applications perspective, how Dynamics 365 capabilities are typically used by organizations who manage their sales, service, marketing processes, it might at times seem like we’re just in a race to the bottom. Packaged offerings replacing project work, ready-made integrations replacing customer specific code, online learning resources replacing in-person training. This is simply what naturally should happen, when technology and past experience allow us to move from solving unique problems to solving common problems in the most efficient and scalable way.
Let’s look at another perspective, though: 500 million apps in the next 5 years. This is the statement Satya Nadella made about the exploding demand for new apps within organizations who are aiming to digitally transform their businesses. You don’t get to 500M with the normal software project methods and tools, which is why the no-code/low-code movement has such momentum behind it today. Because this is exactly the way. Turning the app users into potential app makers is the ultimate method of commoditizing business applications.
So, this is the second major shift that will shake up the Microsoft partner business. What may well happen is that the existing partner channel for CRM and ERP based solutions that has formed around the Dynamics products over the years will not be the ones who can eventually cannibalize their own offering and grab this new space in the market. At the same time, it’s also difficult for me to see the Modern Workplace partners from the Office ecosystem all stepping up into a new area of higher business value consulting. It’s not exactly a walk in the park. Helping customers to define how a particular business process with all its actors, inputs and outputs should actually work in the digital domain, inside the frame of existing lines of business and different industries, isn’t necessarily the natural path for Microsoft 365 specialists to follow.
Processes
Regardless of all this new AI potential found in huge data sets and the possibilities of new app creation via citizen friendly tools, in the minds of the decision makers in customer organizations it still tends to boil down to the question of money: how to make more of it & how to spend less of it. The faster we can draw a line between these technological innovations and the financial results, the faster it starts to pay off and the more future investments will be made here. This is why the role of Dynamics 365 is still of highest strategic importance for Microsoft to turn the aforementioned vision into reality. In the above mentioned interview, James Philips described this alignment of products vs. platform:
Our customers are telling us that, if we can give them an application to start with versus a collection of tools to go build solutions, they would strongly prefer that.
James has communicated already at MS Ingite 2019 that they’ve recently tripled the size of their Dynamics 365 sales organization by adding 1000 new people in past 3 months (referred to as “D1000”). With the growing stack of first-party apps in the portfolio, it’s only natural that MS needs to assume a more active role in bringing these solutions in front of customers. The very nature of many of these data-first apps is incompatible with the kind of partner channel that Microsoft built back in the MBS era. For the system of record type of core business infrastructure you’ll still want a reliable service provide to steer the slow moving cargo ships. For these new speed boats that require quick maneuvering skills, a very different kind of crew is needed.
The old model for Dynamics partners to sell a bit of everything that the product can do to anyone who happens to ask for it is becoming obsolete – or has already become, depending on how much competition there is in the local market you happen to be operating in. The new role of the Dynamics partner would appear to be in offering very specialized expertise on the delivery of application A, preferably focused on target industries X, Y and Z. Microsoft will have done the solution selling part for the latest cloud apps already before you step through the customer’s door. If you can’t fit your offering into this new role that’s being presented, then… Well, it isn’t really Microsoft’s problem but rather your very own problem as a partner.
It’s time to go forward
Based on this perception that I have about the business applications landscape around us, what kind of a partner would Microsoft customers then actually need in order to achieve business success with this technology? My first answer is: they will need many, I’m sure. The platform and the apps on top of it have grown well beyond the boundaries of what the initial deployment of a single CRM system may have been ~10 years ago. It’s time for the customer to own their digital business platform and then choose the suitable products and service providers for their different development initiatives that utilize this common stack. This needs to be an ongoing process, not a one & done deal for X years with a single company that got the best scores from your RFP Excel sheet a long while ago.
The second answer is more to do with the skill set that the experts in the partner’s team should have. As I described in the Process part, each app in the Dynamics 365 suite will require deeper and deeper expertise. What about the horizontal aspect – the platform that connects all the apps? I would say that the partner you’re working with should posses the following traits:
Understand the Data Platform underneath the Power Platform.
Be citizen-ready in their business app development practices.
Know the past, present and future direction of Dynamics 365 products.
At least that’s what we as Team Forward Forever are striving to achieve. We’ve decided that the competence we will build and the solutions we will offer are going to be 100% focused on Power Platform:
This is the foundation that Forward Forever is built on. Our team consists of professionals with several years of experience on delivering customer solutions with Power BI, Power Apps and Dynamics 365. What we’re NOT planning is sticking to doing what we already know, though. The fact that we all see the clear need to evolve our skills towards the demands that the unstoppable onslaught of Power Platform will gradually force upon every partner out there is precisely why we are joining forces. This is how individuals like us can move forward as a team:
Timo Pertilä, a fellow Microsoft Business Applications MVP has a loooong history in Office 365 world and has jumped head-first into Power Apps and Power Automate in his 100+ blog posts over the past 2 years.
Jouko Nyholm is a leading expert in the local MS Data Platform scene, with background as a full stack developer who later decided to fully embraced Power BI well before it exploded into the dominant BI tool that it is in the market today.
Lasse Teeriaho is an entrepreneur with a solid Dynamics 365 CE background from both partner and customer roles, with hands-on experience on cutting edge MS technologies in machine learning, AI and bots.
Honestly, I couldn’t hope for a better crew to sail with on this journey of helping our customers navigate the Power Platform seas. To quote the lyrics of a song by the late & great Andrew Weatherall:
One of the reasons why I changed my blog from “Surviving CRM” to “Thinking Forward” was to give me more space to cover topics that don’t necessarily fit under the umbrella of Dynamics 365. Yes, Power Platform is naturally one of the big drivers for this broadening of the scope, but I see a whole range of technologies in the Microsoft Cloud that are becoming more & more relevant for anyone who’s designing and delivering business solutions to customers. Broad awareness of the stack combined with deep expertise in specific fields is what I believe is needed to survive and thrive in my line of work. You could call this the path of the specialized generalist, or “T-shaped people who run the world”.
How does one go about building up this awareness of Microsoft Cloud technologies? All the required information is of course out there in the great wide Internet, but the big questions are A) what would be the most relevant topics right now for me to search guidance on, and B) how could I make this new knowledge stick? In order to create a memory footprint that will still remain after I’ve moved on from one browser tab to the next, sometimes it helps when you can associate things with something tangible from the physical world. People, places, events, moments.
The big event of the year for the Microsoft minded crowd of IT professionals in Finland is TechDays, which is on March 5-6 this year. I’ve got fond memories of the first time I attended this conference in 2011, when Dynamics CRM 2011 & CRM Online had just been launched and there was a dedicated track for this exciting new version & cloud service (which I naturally covered in my Finnish CRM blog at the time). Now, I have to admit that level of exposure to MS BizApps didn’t exactly become the norm for the event, because for a long time the MBS unit and its Dynamics products remained on the fringe of the mainstream Microsoft product portfolio.
Today things are different. No, you still wouldn’t find a CRM session from the TechDays 2020 agenda, but you wouldn’t find one in Microsoft’s list of products sold, either. What you will find instead is Power Platform being promoted as the common customization layer for both Office and Dynamics products. You’ll encounter a growing number of Azure services being turned into Insights products in the Dynamics 365 portfolio. You’ll see Microsoft promoting a platform for every developer, from professionals to citizens. You’ll hear Satya being bullish in MSFT earnings calls about their Customer Data Platform, powered by Dynamics 365 + Data Platform.
That’s how the story has evolved and this is the new reality in which the customer solutions must be designed: making use of all we have, not just what we’re familiar with. So, let’s look at the TechDays 2020 Finland session list with this in mind. Here are my top 3 sessions picked from the domains that I consider highly relevant for business applications professionals that want to understand the bigger picture of MS Cloud: Power Platform, Data Platform, Azure, Microsoft 365. I will also try to do a post event summary of the sessions I managed to attend and share the key takeways.
Power Platform
“Power Apps – Miten pääsen alkuun ja vielä pidemmälle?” by MVP Timo Pertilä. “Encrypted in Finnish” yet consisting 100% of demos, this session is going to help you kickstart your Power Apps (Canvas) app building journey for sure.
“How to build RPA solutions with UI Flows” by Timo once again. Robotic Process Automation is one of the hottest areas in business software and MS has only very recently entered the game with Power Automate’s new UI Flows that are aiming for GA in June. How far are they already? We’re about to find out!
“Developing enterprise-ready solutions with Power Platform and SharePoint” by Mikko Koskinen. Even if there is native support for CDS in Power Platform, the Connectors to SharePoint are bound to be the most common data source/target for apps today. Understanding how to leverage these in scenarios that go beyond citizen developed apps is therefore quite important.
“Building an Empire – Implementing Power BI Step by Step” by MVP Alexander Arvidsson. I’ll be the first to admit that of all the key pillars in Power Platform, Power BI is where I have the least hands-on experience so far. Therefore the promise of crafting the PBI solution from the absolute beginning and working our way towards Power BI dataflows sounds like just the thing for me!
“Introduction to Azure Databricks” by MVP Oskari Heikkinen. Going big in the data field requires courage to explore technologies like the Apache Spark based Databricks and understand how they relate to MS developed services in Azure.
Azure
“Selecting the right Azure products for your Azure PaaS project” by MVP Sakari Nahi. Just because I know how to sprinkle some #azure hashtags on my social media posts, that doesn’t mean I would have the capacity to keep an eye on all the products that are being launched there. I’m convinced that Sakke from Zure can give a Power Platform “aPaaS” guy like me a nice crash course on what the “PaaS with no training wheels” consists of.
“Need to know Azure services as a Microsoft 365 developer” by MVP Laura Kokkarinen. I bet there are similar mental barriers in reaching into raw Azure, no matter if you’re extending Dynamics 365 or Office 365 based solutions. It’ always interesting to hear how the professionals from the cloud next door are tapping into “The World’s Computer” when delivering customer specific solutions.
“Lisenssit löytyy, #mitäsitten – ota Teams hallitusti haltuun!” by MVPs Karoliina Kettukari & Vesa Nopanen. User adoption has always been a hot topic / grave concern in CRM projects. Even though Microsoft Teams is now the fastest growing product in the software giant’s 45 year history, that hardly means users will just discover all the benefits on their own and live happily ever after. Tips for how to gracefully pull off the launch new technology affecting such a large crowd of information workers are always useful, even when developing and rolling out more targeted business apps.
“Getting Started with Developing Apps for Microsoft Teams” by MVP Christina Wheeler. Speaking of business apps, it’s pretty clear that Microsoft is envisioning Teams to become the hub for teamwork, not just via common productivity tools but also unique applications made available through its UI. Understanding the options available and contrasting them with what Power Platform can offer is going to be key in building a solid app strategy for customer organizations.
“Customizing Microsoft Teams Provisioning and Governance” by MVP Olli Jääskeläinen. Collaboration practices should be backed up by a smart system that can bring some structure into the otherwise so unstructured world of conversations and documents. Learning how to more tightly connect Microsoft Teams provisioning with the processes and data structures managed in systems of record like CRM is what I’m eager to see.
