Power Platform is a First Class Citizen in the Cloud Transformation + App Modernization journey
Note: Beginning in January 2020 I am sharing a new presentation at business applications conferences and other events around the world. This post both shares a title with and is a distillation of pieces of that presentation in a form that can be shared more virtually. I welcome your ideas and thoughts!
Power Platform has become a "first class citizen" in the cloud transformation and app modernization journey for large organizations. Indeed, the platform exists alongside Azure and Office 365 as one of Microsoft's "three clouds". Perhaps counterintuitively, I'm increasingly seeing this trend at forward-thinking organizations in some of the most complex or regulated sectors. They are realizing that Power Platform is an enterprise-grade platform for enterprise-grade workloads.
These organizations are embracing an approach to cloud transformation and app modernization build on the understanding that:
Some business challenges can be solved with custom software development… But there’s only so much of that in which you can invest.
Some business challenges can be solved with Commercial-off-the-Shelf SaaS solutions… But there isn’t always an app for that.
Everything else is missed opportunity to transform and modernize in the cloud… No-Code / Low-Code Cloud transformation is the answer.
Let's consider some recent research from Forrester, Dresner, and Gartner:
Backlog: 65% of organizations say they have one for app development
Paper: 37% of organizations say they're still using it to manage critical functions
Digital Transformation: 69% of organizations say this is why they're embracing low-code
App Development: 65% of it will be happening on no-code / low-code platform by 2024
That’s what low-code cloud transformation and app modernization is really about: Harnessing the “65% Opportunity” with Power Platform as a first-class citizen for business applications amongst Microsoft’s “Three Clouds”.
Power Platform is a first class citizen amongst Microsoft’s “three clouds” in serious cloud transformation + app modernization.
So what's driving this? And — perhaps more importantly — how do we do this at scale? How do we migrate one, two, or ten thousand workloads to Power Platform? I see three factors driving this change.
The technology itself is incredibly compelling. Common Data Service (CDS) out of the box offers up capability that we used to build from scratch, and is — in my view — worth the cost of licensing on its own. Custom connectors where we'd previously have had to build APIs, the ability to rapidly build model-driven apps right out of our data model, powerful dataset integration capabilities and self service reporting and analytics inside of Power BI, robotic process automation (RPA). The list goes on.
Power Platform allows us to reduce time to market and be incredibly agile. Low-code does not equal low-complexity. To the contrary: Low-code allows us to save time building the truly complex, which of course reduces the time to market taking a workload from concept to production. Further, by disaggregating the data layer (CDS) from the transaction layer (Power Apps, Power BI, etc.) we are able to iterate workloads or build entirely new experiences atop our existing data models.
This thing is built for scale. I increasingly hear big Power Platform customers talking about modernizing 1,000 or more business activities each year. That kind of scale doesn't happen by hiring more developers; you'd never be able to keep up. It only happens when citizen developers and experienced software engineers alike are able to build together on a platform that scales from localized productivity to enterprise line of business workload. The licensing model reflects this reality: When I see organizations struggling to swallow the license cost for deploying a single app, I suggest that perhaps they consider what a bargain they'll find it when they've deployed 1,000.
What's an "app" to you? I often use the word "workload" where others might say "app". There's purpose to this. Most large organizations rely on a host of line of business applications, ERP, CRM, and thousands of "quasi apps" — Excel spreadsheets, Access databases, SharePoint "apps", and third-party tools — built over years. Often, though, there isn't an exact one-to-one match between one of these legacy apps and the "modernized" thing it will become on Power Platform. Perhaps we've crammed a number of functions into a single Access database, but now with Power Platform we can move the data into CDS and create multiple fit-for-purpose apps atop that data. Perhaps we're using charts inside of Excel that we can break up into separate Power Apps and visual components in Power BI. The point is that we need to be thinking of holistic, business-driven use cases — "workloads" — not necessarily a one-to-one migration of apps.
Notional Breakdown of 1,000 Candidate Workloads
So let's break down some numbers. For sake of easy math, let's assume we're looking at 1,000 legacy applications in your organization. Most of the large organizations with which I work actually have far more, but… easy math. Based on experience, we can conservatively assume that at least 20% of those apps are actually obsolete. These are the functions that exist, but which nobody has used in ages. Again, most organizations with which I work find that this number is higher, but I want to be conservative. Of the 80% remaining, we’ll apply Gartner's research and say that 65% of those may migrate to Power Platform. That leaves us with some quick back-of-the-napkin math that suggests 52% of all the workloads in your organization are destined for modernization on Power Platform (1,000 * 80% * 65% = 520 = 52%).
That means we're talking about adopting a platform here, not simply choosing a technology to meet a narrow set of requirements.
The Power Platform Adoption Framework points us in the right direction from here. This framework has become the global standard for adopting Power Platform at scale in enterprise-grade organizations.
Quick Start
Power Platform Adoption Framework is how we adopt this technology at at scale.
Begin with a "Quick Start" of about 1-2 months. It's important to time-box this so that you don't fall into the trap of repeatedly adding additional time in order to create one more feature, one more feature… one more sprint turns into one more month, again and again. We're trying to get to value quickly. In Quick Start, we're focused on prototyping the first workload, beginning to build our community of citizen developers via “ABC” in a Day training (that’s App in a Day, Flow in a Day, Dashboard in a Day), building a partnership between IT and business via stakeholder working groups, and planning for the next six to twelve months in the adoption.
Three Tracks
The framework suggests that we adopt Power Platform along three simultaneous work streams that we call “tracks”.
Track 1: Build. Design, build, launch new apps, visualizations, bots, and automation. Steer the more complex workloads to developers at a Microsoft partner, or to your internal IT development teams. Steer the less complex towards your citizen developers.
Track 2: Roadmap. Analyze candidate workloads, create a roadmap for adoption. When we’re talking about road mapping at this scale discussed above, think in terms of high priority workloads being migrated centrally by the folks who own the overall platform adoption, medium priority workloads being the responsibility of the owning business units, and low priority workloads being — in effect — the obsolete workloads we’re not going to touch.
Track 3: Enterprise Management. Deployment, management, governance at enterprise level. Getting this right is the most important thing you will do in adopting Power Platform. Here we’re building the model for how the platform will operate in your organization. If you fail here, you will fail everywhere else.
Where to turn…
In the coming weeks I'll be sharing new best practices that are coming to the Power Platform Adoption Framework, including a model for architecting Power Platform environments at scale across large organizations, and emerging best practices as to how citizen developers fit within this ecosystem. I'll update this post as those new pieces become available on GitHub.
Until then…
Power Platform Adoption Framework lives on Github, where we take submissions of ideas and feedback, and keep the latest working version in the Wiki. There’s a lot there for you to take in on this topic, so I’ll not restate the entire business here.
