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.

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“.

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?

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.

And 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“?

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.

Considering 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…

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.

We 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.

Everything 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.

Interesting 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. This 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.

Today, 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.

Would 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

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.

Diving 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

Let´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.