Licensing remains a topic that no one claims to like yet everyone keeps on talking about. October 2019 saw what was undoubtedly the biggest number of changes to Microsoft Business Applications SKUs (i.e. items that MS sells), with the end of Dynamics 365 Plan licenses and new models for licensing PowerApps & Flow. Not to mention the new structure that ties licenses closely to API call limits. Oh, and we’re still waiting for the new restricted entities definition that should have gone along with October 1st licensing terms.
We’re not even past the month of October and there’s already a new licensing discussion heating up in the MS customer and partner community. The announcement of Self-service purchase capabilities for Power Platform products, made via Microsoft 365 Messaging Center (only visible to admins), seems to have pretty much angered everyone who saw it.
I gotta say, you simply could not find a worse channel to announce something like this, because it’s aimed squarely at getting around a problem that IT administration (and sometimes consultants like me) are a part of. But like we’ve seen so many times before, communication isn’t exactly the strongest part of Microsoft’s software licensing management efforts, so let’s just move on and start analyzing what is happening here, why it is happening and what possible outcomes there might be from it.
Empowering every individual to acquire applications
To get an overview of what exactly is going on, you can read the article from Mary Jo Foley: “Microsoft to enable end users to buy Power Platform licenses without administrative approval”. In short, starting in November 2019 (in the US), any user that has an account in your organization’s Azure AD tenant will be able to go and buy Power BI licenses directly from MS. Later this will expand to PowerApps & Flow, and other regions. Essentially this will be an “insert your credit card here to unlock Power Platform functionality” type of experience.
How is this different from any of the popular SaaS products from other vendors then? It isn’t. That’s the model that every consumer app and most business apps support, since it represents the lowest barrier to entering a commercial relationship. Usually you would start with a free trial period to try out the capabilities of the SaaS product. If it’s a good fit for the problem you’re trying to solve, the next problem you face is the procurement of the app. Buying things for personal use is easy, whereas the bigger the organization you’re working in is, the longer you can expect this purchasing stage to be. During it you’re basically standing behind the store window, staring at the product you know you’d really need, yet the door to the store is being kept shut. Often there’s even no opening hours sign to give you any clue on how long this will take (or if you’ll ever get what you wanted).
In such a scenario, it’s not uncommon for problems to get solved with a credit card and an expense claim. The ease of taking this route is how Shadow IT came to be, and I bet we’re just going to see more & more of this Bring Your Own App (BYOA) activity in organizations as the information workers become more savvy about what’s actually out there in the cloud. If one store is closed, there are tens of other options with 24H service.
But they can’t do this! They’re MICROSOFT!!!
It’s one thing being an enterprise software startup and trying to get onto the radar of potential customers via the Bring Your Own App strategy. When you’re Microsoft, though, the expectation is that things work in a completely different way. Since pretty much every bigger company is a MSFT customer, the licensing game has been a process of long negotiations and complex agreements. This is the procurement norm of how Microsoft software finds its way into the hands of the end users. Well, it sometimes does, and other times it doesn’t, because the needs of individual users may get lost in the big corporate IT machine that’s trying their best to keep things under control, with the growing amount of regulations, systems and requirements.
What’s Microsoft on about here with self-service purchases, specifically with this chosen set of products? Imagine you’re the world’s most valuable company, you happen to be producing software & you’ve recently discovered a huge new market in the Low-code Application Platform space. You’ve built up a strong community of advocates (or addicts even) and your target is to empower the next 10 million application developers to digitally transform their organizations with the help of your global cloud infrastructure and AI driven insights. You’ve got all these key buzzwords lined up, there’s a seemingly endless sea of citizen developer opportunity ahead of you. The only thing standing in the way of your success is this nasty thing that looks like Niagara Falls, sucking in many of the smaller boats that the poor citizens attempt to use to sail to this promised land of Power Platform. That thing has a name and it’s called Enterprise Software Licensing Models. So much for the “no cliffs” experience then – hope you packed a life vest on this journey!
To avoid this vortex that Microsoft themselves have largely caused over the past decades with the swirls of their enterprise software sales strategies, it makes perfect business sense to open up new, alternative routes for those power users who seek to merely use the software tools – instead of catering only to those who are tasked with managing the whole lifecycle of IT tools in the organization.
There’s only so much you can do with the PowerApps and Flow features bundled into Office 365 subscriptions, after which you’ll need a premium plan. Why on earth would Microsoft willingly push the users to look for alternative tools like Zapier or IFTTT to automate processes that connect to data sources that are outside Office 365? Why shouldn’t it be possible to enter the very same credit card details into a form provided by MS, to keep the tools within the same MS cloud that’s already used by the organization? Isn’t this actually a way to reduce the problems resulting from Shadow IT? Keep the rogue users closer to the official IT world and you’ll have a better chance of converting the tools into non-shadow status at some point.
Obviously there are some valid concerns with a model that might encourage users to acquire MS software via an alternative channel than the officially sanctioned one. The self-service shop won’t give the same negotiated prices for licenses as the company wide agreements. Handling the expenses from various different sources will be an overhead. The boundaries between supported and unsupported IT will become blurry. Even with the promised central visibility into who’s bought what licenses in the tenant, initially it will all just look like more work to those persons who have traditionally managed Microsoft licenses in the organization. There’s an FAQ document from MS for this self-service purchase model that attempts to address some of these concerns, but with a change like this there’s bound to be far more Q’s than A’s at this point.
There shouldn’t be a need for the self-service purchase channel to exist, but in reality there is. If you have only spent time working in roles that represent the centrally planned deployment of IT systems, you may not realize the challenges that can stand in the way of you and the software license you would need for getting your job done in a larger organization. Sure, there might be a theoretical process in place for how the needs of business users are identified and then eventually turned into a working piece of software that everyone happily uses. In reality a fair share of the people on the business side who live in the world of needs may not be seeing such processes in action. They may well be unaware of any development initiatives on the IT side, nor have contacts with those professionals that could help them navigate these processes. If IT systems can be complex, then the inner workings of an enterprise organization can represent a whole new dimension of complexity. No one is at fault, yet everyone pays the price.
The very nature of these new breed apps that are intended to solve very specific problems that are very important to a very narrow audience is not a great fit with the traditional procurement model of IT solutions. We’re not talking about systems like CRM that represent a common repository of customer data and a platform to harmonize processes across the organization’s customer facing departments. You wouldn’t initiate a similar project for designing and deploying the solution like you would in the Dynamics 365 land, because even though some of the underlying technology components may be common, the general landscape isn’t. What PowerApps, Flow and Power BI will increasingly be used for is building solutions that will never have a three-letter acronym – at least not an acronym that would be shared across different organizations. It’s the land where there isn’t “an app for that” – until someone possibly coming from the business side builds it. Perhaps armed with a credit card and a self-service purchase of a few PowerApps licenses, to prove everyone that a solution might not even require funding yet another enterprise IT project.
“Could we just ignore this, please?”
The part about the new self-service licensing model that sound most controversial is that Microsoft will not provide a way to switch it off. The possibility for individuals to buy licenses for Power Platform (and possible other products in the future) is going to exist in every tenant. This isn’t any different from how the trials work today, though. Already in the current product documentation, here’s the answer to the question “Can I block users in my organization from signing up for PowerApps?”:
Any individual can try out the features of Microsoft PowerApps for 30 days, and incur no costs as outlined in the How do users sign up for PowerApps section. This option is available to any user in a tenant and cannot be disabled by an admin. After the user’s trial expires the user will lose access to PowerApps capabilities.
If a person signs up for a 30 day trial of Microsoft PowerApps , and you choose to not support them inside of your organization, they can in no way incur costs to your company. When an individual signs up for Microsoft PowerApps, that is a relationship between that individual and Microsoft directly, like any many public cloud services from Microsoft, such as Bing, Wunderlist, OneDrive or Outlook.com, and does not in any way imply that the service is provided by your organization.
Finally, if your company wishes to restrict the use of organizational-only data inside of Microsoft PowerApps, that is possible through Data loss prevention (DLP) policies. For more details, See Data loss prevention (DLP) policies.
I’m not surprised that there isn’t a kill switch for IT admins to stop the users from buying licenses that haven’t been given to them by… IT. Such an option would defeat the whole purpose of the initiative. Having said that, I also wouldn’t be surprised if there’s going to be some back & forth around this topic before a working compromise is found between Microsoft and the IT decision makers in their customer organizations. There will probably be a thousand and one compliance arguments used against this crazy idea of letting users pick their own tools – and some might be actually valid. Yet there is one specific argument that I find very hard to accept: security.
Protecting the data isn’t done via licenses
Judging by the initial reactions from the Dynamics 365 community to this self-service licensing announcement, many people seem to think that enabling the license to a product in the Power Platform family gives you access to corporate data. It doesn’t – or it definitely shouldn’t. I can sort of understand the confusion when you approach this topic from a traditional CRM system deployment perspective, but now’s a good time for everyone to remind themselves about how this new generation of business applications works.
Let’s say a user gains the product license to use PowerApps. What data is unlocked at that very minute? To the best of my knowledge, nothing whatsoever. PowerApps is merely the client (or a tool to build clients) that can connect to hundreds of different data sources. Data is never really managed “in” PowerApps, it is delivered via Connectors. Unless you’ve been shared an app with a connection that has some hard-coded credentials to access the data source, there’s no way to perform any privilege escalation via the act of buying a license for yourself. (Yes, connectors like SQL Server have suffered from the limitation of shared credentials, but the new Azure AD authentication support seems to resolve this.)
PowerApps, Flow and Power BI are clients that work with data from other systems via APIs. The data in that source system must be guarded on the API level, or otherwise it’s game over – no matter which technology the rogue citizen developer is using. Let’s say I’ve got a user account in Dynamics 365 Sales and it gives me access to opportunity data. If I’m allowed to sign into the application via an API through any client of my choice, then there isn’t really anything stopping me from setting up a Zapier automation to tweet the contents of all our sales pipeline out into the world.
Access to low-code tools that help build such clients to connect to data sources isn’t the concern. The world is full of companies that make these tools. There are a million developers out there who can write code to create such a client. This isn’t a new threat brought upon us by Microsoft’s announcement.
So, if you are scared about the assignment of a Power Platform license granting access to data sources like CDS, then it’s best to look into securing your environment in a way that doesn’t accidentally expose critical information. If you have concerns about the various different services and clients through which the data could be accessed, exploring the options that Azure AD Conditional Access offers is a good place to start.
Finding the right governance balance
The vision that Microsoft has with Power Platform is aiming for a world in which the act of creating an app is just an everyday task for information workers – like creating a document is today. This is really how we should also examine it on a conceptual level, to understand the threats and the opportunities. Imagine for a moment that the frightening citizen developer app is a document instead.
You wouldn’t block a user from creating an Office document, would you? Right, so they can open up Excel and create a workbook that contains data in sheets, which looks like tables in an application database. They put it on a shared location, invite other users to access and edit it, much like an app would allow them to. Sure, it’s nowhere near as efficient as working with a real app with a dedicated UI and business logic. It’s a file, which they can move to a different location, attach it into an email, send to external recipients, store on a USB drive, set to be printed on a copy machine… Oh sh**! Someone corrupted the data / someone deleted the file / someone saved it to Dropbox / someone sent it to wrong recipient / someone took it with them to a competitor / someone routed it to the wrong printer / [insert security incident here]!
Bad things don’t happen only because someone was able to create an app. Data isn’t exposed only because it’s accessible via an API that power users can now interact with, thanks to low-code tools. Employees in general are trying to do the right thing. Those who go through the effort of exploring tools that would help them and the organization to get work done more efficiently (and often also more securely than with Excel sheets) are even more likely to have good intentions. They might be experimenting with the tools of a trusted vendor like Microsoft, building small PoC apps with a PowerApps trial license, and then 30 days later be presented with this screen:
This shouldn’t be the moment when they go back to Excels, or start exploring tools from other vendors that would allow them to make a small investment to keep this business process development work going. It’s hard for Microsoft to assist these citizen developers who reach this point about where to go next, so they way I’ve understood it, there’s probably going to be the self-service purchase option offered to them.
What could customers do then? Instead of putting your energy into blocking unauthorized procurement of software tools, what if you would look at the possible ways to decrease the likelihood of your employees taking the credit card route to self-service purchases? Providing guidance on what alternatives there are for app development inside your organization and who are the right parties to get involved with is of course a key step here. How about building a small PowerApp and a bit of Flow automation to offer your employees a more approachable process for taking these business application needs forward than just a cold, faceless [email protected] address to communicate with.
Actually, what I’d love to see in the upcoming self-service purchase experience would be for Microsoft to provide the option for all organizations to provide a customizable help link. If you’re already well into the journey of empowering citizen developers, it might lead the user into an app experience like mentioned above. If you have very good reasons why users should not proceed with their Power Platform experimentation, offer them a thorough explanation of why & what the alternatives are. Any mechanism that drives more dialogue between business users and IT would surely be welcome here, since I don’t believe licensing is an area that can ever be solved merely via technical enforcement of rules.