Power Platform | Power Apps or Dynamics 365 or both?

I recently came across a couple of conversation around the same topic – Will a Power Apps license be enough to run Dynamics 365? Not sure why this became a big topic in the last weeks, maybe due to cost considerations, maybe some solution architects brought up that idea on Twitter? Anyhow, I thought the answer should be easy – just take a look into the license guide and every customer should know when to go with Power Apps or Dynamics 365 licenses.

But truth is, neither latest Power Apps licensing guide, nor Dynamics 365 licensing guide is providing a simple answer to this question. Furthermore, there´re some myths outside that customers must struggle with the answer. Want to know some of them?

I started reaching out to my good old friend Chris Huntingford asking if he came across this as well. To my surprise we´ve been addressing the same topics side by side without knowing. But without further details, let´s hop into content we aggregated, starting with a simple definition first. Above visual shows two houses and my challenger question would be: Where´s the difference?

People would start taking a deeper look into both images, trying to find a window with a wrong shade, a false angle, or any other difference. [Believe it or not, both are the same]

Next, we would outline that both houses share the same base – rock-solid, which is Azure as Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) level. On top of this the Software as a Service (SaaS) layer is what we would typically see and where you would categorize both Power Apps and Dynamics 365 with. But more recently, we´ve seen a category aPaaS (Application Platform as a Service) in between that better describes the Power Apps offering. Another good old (MVP) friend of mine Jukka was already talking about this here. Anyway, back to the roots, Chris and I thought: Very high-level and very technical, isn´t it? So we asked if there´s an even better way to help distinguish between Power Apps and Dynamics 365?

Of course the answer to this is looking into more details. Whereas Power Apps main purpose is to either built from scratch or start with a template, Dynamics 365 1st party applications simply would be installed, configured and then would be ready to use.

Those feature-rich applications contain pre-built business logic which makes those apps a perfect fit for specific business processes. Furthermore, those IP is currently protected using restricted entities. [In other words: Specific entities would force to have a Dynamics 365 license instead of a Power Apps license only]

Though above linked article is listed as out-of-date and you should visit the Power Apps licensing guide instead to find answers on licensing requirements by entities, you will figure out that it references back on the restricted entities article. Puzzled? Yes, we all agree that it needs a better way to address the protection of Dynamics 365 licensing. But the real issue is the myths on features, that some advisors would classify as forcing a Dynamics 365 license, which in fact are not or no longer.

So features like the App for Outlook, Server-side Sync and Exchange Integration, SharePoint Integration, Document Templates, Microsoft Teams Integration or even Plug-Ins are also included with a standalone Power Apps license. In fact, Power Apps Product Group just posted a reminder on their blog site here.

Why – you would think – should I have a Dynamics 365 license then?

Chris and I put together a real-life example. The true Power-House is to allow the license mix between front-end and back-end usage on typical solutions, such as:

  • Facilities Management
  • Fleet Management
  • Inspections
  • Logistics or Supply Chain Management

Those solutions typically can be split into front-end users that would have lightweight access points on some parts of the solution, such as uploading a photo, adding notes, adding details and back-end users that takes care of business processes, such as case-routing, knowledge-base article creation, work-order creation or resource scheduling.

What all of those solutions have in common is a mixture of 60:40, 70:30, 80:20 or even 90:10 ratio of users assigned to either front-end or backend-roles. Well, instead of building the application needed for backend users, you will figure out that Dynamics 365 1st party apps are already a good fit. They can be easily deployed and used, but for rolling those out across organization it might become an issue.

And here´s the beauty of the license mix. Building task-based front-end apps with a subset of features, but perfectly matching the needs of front-end users. Let´s look into one of the above examples in more detail.

Here you can see a Facilities Management solution that consists of two major solutions. One is containing custom entities that would be needed for both front- and back-end users, but also contains canvas apps and/or model-driven apps for front-end users + any business processes or flows needed for them.

A second one contains additions to entities that would be shipped with Dynamics 365 1st party applications, such as FM-specific fields added to the case or work-order entity. It also contains all kind of back-end typical business process flows, case creation rules, etc.

By layering both solutions, the overall resulting solution is one Facilities Management solution that can be used by both front- and back-end users in a license mix, without violating any given license restrictions, such as CRUD (Create, Read, Update, Delete) permissions.

Therefore, distinguish between Power Apps and Dynamics 365 in many situations is not what the solution architect should recommend. It should be pretty common instead, to have a license mix, use solution layers that merge into single or at least linked solutions with a harmonized Common Data Model inside the Common Data Service.

That´s all for now, until next time

Power Platform | A good data strategy without isolation

Maybe due to the nature of Power Platform, maybe due to easy to use connectors, such as SharePoint, SQL & Co., the moment app makers think about their application use case, they are asked to become a good data strategist.

In many customer workshops (think App-in-a-Day), app makers are overwhelmed by the various responsibilities that they weren´t thinking of, when considering building an app. To allow an easier entry level and lower the barrier, let me share with you some of the key principles, I start teaching about. First data requirements, meaning:

  • Do you need structured or unstructured data, or better a combination of these two?
  • Would you be able to achieve your goal with internal data only, or do you need to supplement your company data with external data (for example supplier information, weather data, etc.)?
  • What about quick access to the data you need?
    • If not, what data collection method will you use?

While starting with the Power Platform and in special with Power Apps following KISS, the more use-cases and apps you´re designing and building, the more you will came across above.

Once you´re into data requirements your next bus stop is around data governance. Your key considerations should include:

  • Who will be or is responsible for ensuring the data is accurate, complete and up-to-date?
  • How to ensure data is stored securely?
  • Accessing someone else´s data, could you lose access to it? What about a plan-B in this case?
  • How to ensure an ethical use of data?
  • What permissions would you need to gather and use data?
  • How to minimize data where possible and meet compliancy with GDPR?

Following these two key principles in your app ideation, design and creation process, you would think about: Does low-code / no-code or in particular Power Platform could help you with this? This is the time, I am introducing a third principle, which is regarding the technology implications. Here´s where in many cases I do see questions upcoming regarding the Common Data Service compared to other data sources. Couldn´t it easily become an isolation of data or a siloed approach?

3-ways importing data into Common Data ServiceTo proof this is wrong, let´s take a closer look into the Common Data Service and it´s importing and exporting options. First by diving deeper into the ways of getting data into the Common Data Service.

There´re three main options, that you could follow:

  1. Using Data Flows and Power Query
  2. Using Azure Data Factory or
  3. Using either Azure Logic Apps or Power Automate

to import data into the Common Data Service. The beauty around all of them is the easy to learn, easy to setup and easy to maintain approach, that is shared across all three options. So, if you´re a data analyst being familiar with Power Query, you high-likely would shape or transform data, map it to Common Data Model entity definitions using the Data flow editor and import data easily on a scheduled or manual basis.

Being an Azure developer familiar with Azure Data Factory, you might be in favor of using pipelines, data sets and data flow concepts to connect SaaS, Cloud- or on-premises data and import data into the Common Data Service.

Last but not least, being a system integrator you might consider using Azure Logic Apps or Power Automate and one of its hundreds of connectors to get data imported into the Common Data Service, or if not yet existing use the Custom Connectors Framework that can connect to Open API (Swagger) to work with Services, Functions, and Code running in IaaS & Azure Kubernetes Services (AKS).

No matter of the toolset you´re using to import the data needed into Common Data Service, you should always remember the easy to publish data to Azure Data Lake from CDS. A simple to configure extension already GA´d, often not yet known.

Multiple ways exporting data from Common Data ServiceOnce configured, you would already have your first export option activated, but from an app maker perspective, you might want to know about additional services. And the beauty here is again on multiple options, such as the already mentioned

  • Data Flows + Power Query
  • Azure Data Factory
  • Logic Apps or Power Automate

but also an additional Data Export Service that allows exporting you Common Data Service data.
You might now ask yourself: What kind of toolset to be in favor of? The answer would be, it depends. Technology implications, such as

  • collecting, storing and organizing data,
  • processing (analyzing) data to extract the insights
  • Additional technology, such as AI Builder, Machine Learning and Algorithm being used to gather insights or
  • How to communicate the insights from data and think about the its visualization?

should be your tour-guide here. And finally take a look at your Skills and Capacity and your Implementation and Change principles.

Hopefully, after reading this you´re now equipped to think of a good data strategy without isolation, and you agree that using Common Data Service is not following a siloed or isolated way of data processing. Instead the various low-code or pro-code options allow for matching your skills and capacity or implementation and change principles.

Like to discuss, leave a comment on Twitter or here on this blog.

Until then…

Power Platform | Talking about the underdog

Today, I´d like to follow up on a story from one of my ideation workshops, where I was with a customer and the room was full of pro-developers that came in with their questions around Microsoft´s Power Platform and align Microsoft´s roadmap with their vision around integrating low-code development to achieve a tandem strategy for app development.

Common Data Service - What´s in that "box"?As I was starting to talk about the underdog they might have heard or read about, but not yet fully „adopted“, I highlighted a couple of features they would get out of the box from the Common Data Service, such as security, authentication or even relational database and audit log retention services.
Not surprisingly them coming from the Azure side and being familiar with Azure services, what caught their attention first though, was Azure Data Lake, Azure Dev Ops and Azure Synapse Analytics.

I kept introducing the Common Data Service, offering them way more services than just a simple relational database (which is what many are thinking of first, when Common Data Service is mentioned). After a short while thinking of all kind of services, it wasn´t a surprise them asking around the technical architecture of this „box“.

Common Data Service - Technical Architecture (simplified)

So we started talking about the facts, the Common Data Service running on Azure and extending with Azure services. We also discussed that just recently additionally to API first exposure, a TDS endpoint has been added as experimental preview which provides pro developers even more flexibility in their future app projects.

That way we could also address typical questions, such as why shouldn´t they use an Azure SQL Database or a Cosmos DB instead. Cause many people still don´t know that the underdog is using those services already out of box and provides low-coders to benefit from all without the need to configure them. Instead an easy to use and easy to maintain UI can be used, when interacting with the Common Data Service from an app makers perspective.

But all this wasn´t enough in terms of getting the underdog to be fully adopted as a new beloved child. Which immediately reminded me of a couple of social media discussions on Twitter, where a couple of my MVP friends and #PowerAddicts were discussing the pro´s and cons of using the Common Data Service. To many, still seen as a premium service and therefore a „to be avoided path“. I am sure my good friend Chris Huntingford (@TATTOOEDCRMGUY) won´t stop promoting the Common Data Service in favor of SharePoint.

Nevertheless, lucky me we were in an ideation workshop which brought up the opportunity to think of it differently – and those who know me or have seen my previous articles know that I am in favor of think differently. We therefore defined together a simple use-case scenario that is pretty much standard and might be well known by yours:

How about an existing app being in the need of enabling a user to search for a product and additionally show some details on the product journey?

Using Azure Services to achieve goal When designing this scenario from a pro-dev perspective it is pretty simple task to think about structuring the data for the app and bring in additional services that would allow a simplified approach to achieve these goals.

Nevertheless, same as in real-life, a late-incoming breaking requirement for this app disrupted creation process (think of following an agile sprint design and -development process). But as I had Azure familiar developers around me, it was easy to define the Azure services needed to fulfill this additional requirement. If you might have recognized, all kind of Azure puzzle pieces are coming together – so the question was, are there any alternatives? Remember us being in an ideation workshop.

Using Low-code and CDS to achieve same goalsAnd yes, the alternative is to think of the app scenario like every (other) developer – thinking low-code. Cause with all the Azure services added for the app scenario there´re 10 services, where I need to understand

  • their APIs
  • their pricing models
  • how they scale
  • how they handle security
  • how they work together
  • how to operate them and additionally,

I have to think of an end to end telemetry and error handling that spans all those services. Therefore, I outlined the low-code approach [in the visual to the right], where instead we would use our underdog – the Common Data Service that allows us to easy design, build and maintain an app that also could be combined to other systems, services and SaaS platforms easily.

Guess how the ideation workshop ended? We talked about the tandem strategy in app development to combine pro-dev and low-code services and leverage the benefits from both worlds. The underdog became a first-class citizen of app development strategy and finally everyone understood, that it is way more, then a simple low-code relational database or just a premium service to be avoided.

For those, now asking if pricing was an issue. No, cause pricing or licensing shouldn´t be the only tour guide on your digital transformation (as I keep repetitive saying). Instead, getting to know options, evaluate and distinguish features or services should be on your top to-do list.

If you´re interested to know more, please make use of Microsoft´s Business Application Summit or Build sessions that are available on demand and there´re great sessions from real-life experiences.

#NeverStopLearning – until then

Power Platform | When a single app thinking isn´t enough

Today, I´d like to reflect on licensing- , well actual pricing discussions again. Those, here and there to be found on social media regarding the Power Platform. In many cases those discussions kick-off by someone complaining around the fact of being forced to re-engineer a solution, based on the fact of data sources being used for the app scenario forcing a high cost.

The pattern in many cases follows this: „I am frustrated of the Power Platform licensing, due to forcing us to a pricing that in no circumstances can be accepted for using Common Data Service as app data source“. I am not going to add additional attributes used to show the level of frustration.

When reading this, I am always reminded of my day-to-day life, where in press or news we´re discussing the price of food. Is it okay in times of Corona to raise the price of fruits and vegetables? Do we need to raise the price of meat, to allow for better working conditions and avoid current ongoing practices to produce meat as low as possible – as the argument is called out as „the market would demand it“?

Case-by-case vs. Enterprise roll-out decision

Well, I don´t want to further discuss this topic here, but explicitly outline, that pricing might not be the point to discuss. Instead, we should think of a value in total discussion.

In other words, a single app might not be sufficient to explain the overall value, your company would receive when making a buy-in to Power Platform. Why is this?

In my value talks, I am referring to a price-point discussion being like finding a needle in a haystack – Let´s say an actual app scenario would safe a front-line worker 15 mins each day for a specific process; year 2020 will be calculated as 254 working days; a possible saving of 3.810 mins or 63.5 hours or ~2.65 days would be possible. Let´s assume, we´re calculating this with 125 USD/day salary, our saving per front-line worker could be worth ~331 USD/yr.

If we compare this to current known list pricing of 10 USD per App or 40 USD per User pricing per month for Power Apps (and yes, this is what happens though there´re multiple more license options), we could do the math and compare our ~331 USD/yr with an investment of 120 USD/yr or 480 USD/yr. In other words, selecting the per App licensing model, a single scenario like this could save us money; choosing per User licensing model instead, our investment will be higher than our possible revenue.

This is why I´m calling this „finding a needle in a haystack“. If you can´t find this single app scenario, you probably have a tight discussion ongoing around pricing. Same tough discussion you would have, if you would compare this to meat-, vegetables, or milk pricing and not turning this into a value discussion as well.

In my value talks, I am therefore trying to shape the scope and turn discussion to something that is often-times overlooked in for instance Power Apps licensing. What is it, you ask? If you check out current Power Apps pricing page for per App it says: „Run applications around a single business scenario for an individual user“ and if we deep dive in the matrix the single business scenario is outlined as 2 apps and 1 portal.
Regarding per User licensing the page talks about: „Run unlimited applications for multiple business scenarios.

What do both of them have in common? They are talking about more than a single app. Therefore a value talk should start by discovering a broader app requirement. What would be, if we can take into account >1 app scenario?

Let´s assume additional to above app scenario, we could identify another scenario where a Power Automate flow in context would be involved. By automating the task via the flow, instead of letting the first-line worker do the task manually, we´re saving this worker another 5 mins each day. Our calculation would be 5 * 254 = 1.270 mins/yr or ~21.17 hours or 0.88 days. Again with a 125 USD/day salary, our saving per front-line worker could be worth additional ~110 USD/yr.

As you can see, we´re getting closer and closer to our 480 USD/yr investment of a per User license. Of course this is very simplified calculation and there´re many more aspects of cost-savings that needs to be taking into account. But same as you shouldn´t think of from an investment point the license cost being the single point of truth. What about the development & maintenance costs of an app? If you´re interested in understanding industry standard economic impact calculation, I recommend you taking a look into the Total Economic Impact™ of Power Apps study by Forrester.

My point is, Power Platform licensing for all its modules (Power BI, Power Apps, Power Automate, Power Virtual Agents or the add-ons) is based on the fact of making a buy-in to a low-code platform for digital transformation. For IT departments or pro-developers, it is about buy-in to a tandem development strategy to both provide low-code platform services to citizen developers as well as accepting low-code being an alternative to their traditional development tools.

A single app might not be worth driving a discussion of a low-code platform being used for digital transformation. But neither should selecting a data source or re-engineering an app scenario to fit a specific licensing option be your tour-guidance when thinking of the Power Platform as a digital transformation toolset for your company.

If you´re interested in getting behind the scene´s on this, please check out my 4-part series around why I do think a paradigm shift is needed.

  1. Episode I
  2. Episode II
  3. Episode III
  4. Episode IV

Agree, Disagree, additional thoughts? Let me know your thoughts via comments or via Twitter.

Until then…

Power Platform | Top Strategic Technology Trend 2020 | Hyperautomation

It was with great interest, when Gartner in late October, 2019 introduced one of the Top 10 strategic technology trends being Hyperautomation. Of course one of the first asks was, how Power Automate would find into this sooner than later becoming a buzz word. Through that time, the AI Builder team introduced more preview models being available for Power Automate shortly after becoming generally available on Oct. 1st, 2019. That was the fist time a significant part of Hyperautomation became available to Power Automate users Artificial Intelligence (AI) and Machine Learning (ML).

Today, Microsoft announced the acquisition of Softomotive to expand the low-code robotic process automation (RPA) capabilities of Power Automate and immediately let customers benefit from low-code desktop automation solution with WinAutomation.

Multiple automation tools vs. orchestrated platformConsidering that customers typically started their automation journey with a single tool for task automation, but shortly afterwards already figured out them to deal with multiple automation tools to address typical needs of automation – it is with no surprise that maintaining and combining these automation tools becomes a challenge.

You might think of this not being a huge issue, as each product is addressing a specific need and there wouldn´t be a demand of combining them. In fact, interoperability is not only a thing between Microservices. Maintaining each single toolset individually, requiring employees to specialize and build knowledge around these solutions, becomes a huge cost factor for companies regarding their overall digital transformation toolset.

Running ideation workshops with customers and openly discuss the all over challenge of shrinking IT budgets vs. allowing more agile, more flexible adoption to rapidly digital transform, it should be almost a no-brainer to take into account orchestrated platforms as the first foundation of establishing a company wide ecosystem. Customers no longer searching for instant savings only, instead looking for revenue shifts and new business empowerment. Consider this Hyperautomation market growth rapidly, it is with no surprise that vendors being specialized on a single automation segment today, sooner than later will either transform to cover multiple segments of automation or could end up being candidates for an acquisition.

Let´s review this together around August – October timeframe where typically we will see new analysts reports being published. Democratization of Automation just started…

Until next time

 

Power Platform IT budget | A paradigm shift needed to be compliant with SaaS? (4/4)

The previous 3 episodes set up the scene we´re into today, in episode I, the intention was to highlight current ongoing discussions with IT departments around their readiness on a new norm created by the growing number of developers which are also known for as „citizen developers“. In episode II, the focus was on various power platform features that can be licensed individually or in a mix + the intro of a first problem statement to setup an operating model designed to avoid unaccountable licensing spent. As a follow-up, in episode III, we added a second problem statement to highlight the balancing mix of emerging, current and legacy technology support and find a way that fits all requirements and offers enough room for growing or creating new business.

Today, let me introduce you to a recent game I came back to during pandemic times. The Tower of Hanoi. Does anyone know this from their childhood as well?

After a customer workshop, I was „brought back to reality“ (I guess many of you know the WFH challenge) – someone asking me around this game. What it is? How to play it? If there are rules to apply?
To my surprise, I was perfectly reminded of how to think about problem solving and discover a solution. Kind of a flash back, as a couple of weeks before, I was installing the Tower of Hanoi game based on Power Apps. For those not being familiar to this game a quick wrap up of rules to play this game:

a) A larger disk never can´t be positioned on top of a smaller disk

b) you do have 3 bases and the overall goal is to move the Tower from the source base to a target base you define first. You´re only allowed to move one disk at a time.

You might now be puzzled on how this can be related to the previous 3 episodes and our 2 problem statements. Let me help you understanding the bigger picture here.

First, the disks can be seen as the several modules (products) that can be found in a SaaS offering, like Power Platform. Orange for instance being the Office 365 or newly Microsoft 365 seeded services, purple being Power Apps, blue being Power Automate, I think you get it now…
The bases being the individual departments reporting their individual demand; the rules highlighting the difficulty (problem statements) and why in some situation (moves) it will fail.

Still puzzled? Need an example? No worries, let´s play this virtually…

Power Platform Tower of Hanoi Step 1 Obviously the first move in this game is a simple one. Let´s say a department comes up with a need for using Power Virtual Agents, which is what the green disk should be for. As a reminder, my basements are seen as departments. From a pool of licenses (let´s say my license catalog), I could serve this department demand, pricing and activating this service. And for the sake of simplicity, let´s say the budget for this was pre-planned.

Power Platform Tower of Hanoi Step 2We continue to play this game with a 2nd department, raising demand for AI Builder capabilities, which the red disk is for. As budget again was pre-planned, this service could be offered, maintained, operated and also supported by IT.

Power Platform Tower of Hanoi Step 3Everything works fine, until we hit the day X within our budget year. Our first department returns to us with an additional demand. They figured out that with the help of Power Automate, they could refine their Power Virtual Agents service and automate some tasks, but as the department played with this in a trial, several users in this department discovered that there´s demand for automation outside of Power Virtual Agents as well. Think of it as why the blue disc is now even bigger than the green disc. Unfortunately, we violated rule a) of the Tower of Hanoi game. Does this remind you of something?
In my case, yes. I feel reminded of my customer talks and them struggling with exactly this situation happening during a financial budget year. The department wasn´t able to address their demand beforehand and now struggles to have budget for the additional requirements. The question would be, what would change, if instead of the bases seen as department, IT would start to think of „in categories“. So each base becomes a summary of categories?
And just to outline: Categories are org-wide, can be assigned to multiple departments and new requirements can kick-off new categories. Let´s turn back to the Tower of Hanoi.

Power Platform Tower of Hanoi Step 4Interesting enough, all of sudden there´s a new path to comply rules for our next move. The Power Virtual Agents and AI Builder „stack“ unites into a category and we do win a new category, free for another move. Power Platform Tower of Hanoi Step 5This additional move allows us to add our incoming request by our department which is around the Power Automate service. This „service category“ could be extended by additional services as well as used by additional departments. Same as we can continue to play the Tower of Hanoi with additional moves by shifting & extending categories, I do feel reminded of a typical Power Platform digital transformation story.
No customer starts with a „big bang“. Everyone starts small, growth over the time, raises new businesses and gets more and more familiar with all the capabilities and benefits of the Power Platform as a digital transformation platform for their company.

Does it mean, we all should now start playing Tower of Hanoi in our IT meetings? Of course not! My only intention was you to pause, think and come up with a solution. Same as you would do it when playing the game.

Am I saying that this is the overall solution to our problem statement in total? Certainly not, but isn´t it interesting to see some similarities between a game with simple rules and a current business problem? Maybe a paradigm shift is what is needed to stay aPaaS, SaaS, IaaS compliant and the way those services are offered or licensed.

There´s a solution to everything. Hopefully, you do feel engaged now to discuss Power Platform licensing and always feel reminded to keep out-of-box thinking. And remember, pause, think and re-start to find your solution.

Until next time, keep safe and healthy.

Power Platform IT budget | A paradigm shift needed to be compliant with SaaS? (3/4)

In our last article we kicked-off conversation with an intro of a problem statement. Today, let me go further and add another axis to this graph.

Traditionally, many IT executives were familiar to work with vendors and sourcing products. They made build-or-buy decisions on business software and infrastructure (hardware for in-house data centers). They sourced development skills, procured middleware, operating systems and database licenses.

Before everyone talked cloud, microservices and connected data, IT executives had high levels of control over their domains:

  • Architecture & engineering teams lay out the roadmap end ensure purpose fit and meeting particular risk and security requirements
  • Provisioning and deployment teams buying IT infrastructure and ensure configuring
  • Data center facilities group managed and controlled IT facilities and ensured infrastructure setup
  • Support and operations teams monitored to ensure safe operation
  • Software development worked to understand the business need and to both enhance old and create new business value by delivering application functionality.

Problem Statement #2 - the formulaToday, as IT executives look to provide value from their IT portfolios, they are balancing a mix of emerging, current, and legacy technologies. The role of IT often shifts from one in which it would buy and integrate products and components, to one where they buy and govern enabling services.

Many companies applied DevOps strategies, bringing the development and operations teams closer together to ensure faster time to market, lowering operating costs and availability.

The visual above explains a simplified formula in terms of internally invoicing DevOps, and outlines that due to different service levels and individual support tiers, a fee for a single service (product) varies by department.

Office 365 License AssignmentWould a flat fee help? [A question, I´ve seen and listened to many times as Power Apps & Co. licensing is compared vs. Office 365 licensing] Well, let´s take a look into the Office 365 license and again simplify on it regarding that a company would have purchased an E3 or E5 license at a specific price point. As this license contains multiple services (products) the IT would be under control of enabling or disabling services with the toggles [see in the visual to the right] inside the Microsoft 365 Admin Center.

To a certain point, I do compare this „flat fee“ license with the offering the Dynamics 365 team previously based on, which was a Customer Engagement Plan. In this case, a customer was paying for a CE plan, even while it was only using the sales-, marketing- or customer service part of it. The result: A lot of customers complaint about paying for something that is not being used.

Regarding Office 365, I guess it would be the same, if the majority of services would be turned off, though the company [e.g. user] would pay for it.

We all know the results on the Dynamics 365 side of the house – the CE plan licensing was given up in favor of a more flexible app-based licensing model.

Compared with Power Platform licensing, you do find a kind of an app-based licensing in here as well [in fact we´re talking about certain services, add-ons or combos].

So in terms of above conversation around flat fees my challenger question would be – Why should a flat-fee licensing help with Power Platform adoption?

Take a look at above formula again and drill into the components of it to better understand where the issue around this problem statement or even previous statement from last article is, before discussing further a possible solution approach.

Looking forward to it? Please let me know by either sending me comments or leave a reply on Twitter, where this discussion is running as well.

Until then – stay safe.

Power Platform IT budget | A paradigm shift needed to be compliant with SaaS? (2/4)

Today, I am going to enhance the change of IT departments ongoing with a topic that I came across quite often. In many of my customer talks, in every other hackathon where everyone feels enthusiastic around the capabilities and someone stands up and ask the tough question of „How much will all of this cost us?“

Power Platform components

Power Platform components

It obviously is a topic I´ve seen many people struggle with in my career as there´re many facettes to it. Some complain about complexity, some about the fact of thinks should be way easier, like a flat fee – of course I am talking about the licensing of the Power Platform and therefore budgeting.

 

As you can see in the visual to the right, we do have many components that all make the Power Platform. Power Apps, Power Automate, Power Virtual Agent and Power BI to name the most obvious and then the various add-ons like RPA with UI Flows or AI Builder as a capacity add-on.

But let´s not forget the Office 365 seeded licensing as many customers do mention these as a perfect example of a flat fee and they wished it would be as easy as this to license the Power Platform.

Let´s run through some facts: First and foremost, Office 365 licenses doesn´t come for free, so talking about „free“ services vs. premium services is worth calling this fake news. Yes, those Office 365 licenses do come with some Power Apps and Power Automate as well as Power BI licensing which are referred to as „seeded licensing“.
Neither free vs. premium is helpful when thinking about and debating the real issue, which I call out as demand forecast, shrinking or to be optimized IT budgets and an operating model designed to avoid unaccountable licensing spent during a fiscal (budgeting) year.

Problem Statement #1 IT vs. BusinessDiving into this, what I´ve observed in many customer talks and social media discussions is our issue is multiple folded. One layer is around IT- and business folks being in the need of budget planning accordingly, meaning IT to meat the goal of shrinking and optimizing IT budget year over year and business being in the need of forecasting and reporting their demand. This is where time is needed as many use-cases cannot be foreseen, forecasted or planned for. The more business is able to articulate their actual forecast, the more accurate the IT budget forecast could look like, but instead of planning for agility and flexibility during the year, this budget gets optimized. The result, inaccurate forecast and demand planning leads to difficulties in agility during a financial year. Some companies overcome this issue by shifting budgets around – some fail.

Could better education lead to a better forecast in terms of business being able to articulate their demand?
We currently do see an answer to this in terms of the current ongoing pandemic. The amount of respirators and surgery masks needed doesn´t match the current planning – though scientists early in 2015 already published their studies to being in need for a certain amount of those in an ongoing pandemic. But in all honesty, who wants to plan for something that might happen, could occur in a maybe and oh… those costs, sorry that´s simply a no go. The consequences, I don´t need to mention them as we´ve all seen them.
So does better education and forecast lead to better budgeting? Certainly not. It can make a difference, but didn´t I mention an even more complex level of this ongoing layer?

Watch out for the next article covering more details and another add to this problem statement to discuss a possible solution afterwards.

See ya next time. Stay healthy.

Power Platform IT budget | A paradigm shift needed to be compliant with SaaS? (1/4)

Today, I want to re-start Power Platform talks with a topic discussed controversy, complex and sometimes with emotions. Can you guess? Licensing. I´ve calmed down this blog service for quite a while to focus on other important topics and tasks, though I never stopped sharing my experiences via Twitter with you.

I didn´t expect licensing to be the topic to restart with, but a recent game – I will come back to this later – reminded me of a simple rule of thumb.

Sometimes we struggle identify a solution to a problem statement. This is where we should pause, step-back, think and finally find an approach or solution to this

Power Platform New Developers create a new NormLet´s start with an intro to this topic by outlining the current ongoing change that creates a new norm. Low-code application platform development or LCAP added a new category of developers – Gartner & Co. calls them Citizen developers.

I am not going to discuss this terminology further with you, but with this number of developers growing there´s a move or journey ongoing for IT departments. They need to adjust their operating model and turn successful into the SaaS business not even due to Covid-19 impact on economics and business in general.

In my career, I feel like I´ve had tons of customer talks around ongoing changes, how to address them and plan for future success. But recent Twitter discussions around the Power Platform licensing again reminded me of above rule of thumb a dozen times.

There´re tons of myths around the Power Platform capabilities, hidden gems, asks, answers and of course this never stopping topic of fitting licensing. Some of them I am always happy to address in my Governance and Security at scale customer talks or Hackathons. Others seems to have calmed down, but then all of a sudden raises like a Tsunami a colleague of mine recently called this out.

Need an example? What about the discussion of splitting Power Platform and specifically Power Apps licensing into „free“ vs. premium services, ending up in bad project / decision guidance in terms of re-engineering architecture on data sources to avoid premium licensing? Well, which free-model everyone is talking about? [me thinking] The Power Apps Community plan – which comes as a free service to learn and teach yourself the Power Apps & Power Automate capabilities? Office 365 seeded licensing to be called free is same a myth as well as wrong information for those currently making a decision or being in an upcoming decision process.

Interestingly enough those discussions are ongoing with a lot of passion shown by parties coming from both the SharePoint folks fighting SharePoint Services and then those Dynamics folks fighting their CDS well known and of course Database enthusiasts kick-in with SQL or AzureSQL services. Isn´t it funny that Power Apps and Power Automate allow to connect to all of these easily? There´re good reasons for any of those data sources, so your data source shouldn´t be your driver of avoiding licensing.

Obviously it shouldn´t. It should be a natural part of your backend architecture. So in my next articles I am going to introduce you my story I came across and hopefully you feel inspired to discuss and think with me.

Time to „Hit Refresh“ – welcome 2018

After 20+ years being in business, it is time for me to „Hit Refresh“ – Inspired by so many lovely friends, companions and nice anecdotes from Satya Nadella’s book with the same title – looking forward to 2018 and all the things that are going to come.

Happy New Year everyone – enjoy an incredible one and hope to see and meet ya soon.

Thanks to my family for being such supportive in times like these.