What is the Power Platform?

Nick.Doelman

1,947 Most Valuable Professional

Like ( 0 )

Report

The concept of the Power Platform is just over a year old. However, I find that there are still a lot of clients, consultants and even Microsoft employees that don’t fully grasp just what the Power Platform is and what it can do.

Is the Power Platform just Dynamics 365? Isn’t PowerApps a front end for SharePoint? Why would I use Flow over Workflows?

I recently added a section to some recent presentations on PowerApps to better explain what the Power Platform is. I found that a great way to explain the Power Platform is to go back in time and explain just how the Power Platform came to be. This blog post is an adaptation of that presentation.

I was also inspired by Scott Durow’s video on the Story of the Three Realms

The Amazing, Untold Origin Story of the Power Platform

This Story has a surprise ending

A lot of what I am about to tell you likely did not happen exactly in the way I will tell it. Similar to other biographic works on famous celebrities, the content is adjusted to convey the story best.

The Beginning: Dynamics CRM

Microsoft Business Solutions Customer Relationship Management was released in January 2003. There were other established CRM systems in the market such as Siebel and Goldmine. The first release had a basic sales and service module. You could extend the existing entities by creating your own custom fields and by adding JavaScript code to dropdown boxes.

The real power came when Dynamics CRM v3.0 was released in December 2005. You could add custom entities to further extend your CRM system to track additional information around your sales and service activities.

There was a Sales, Service and Marketing module that had a common user interface that all worked on a web based common business application platform that interacted with a Microsoft SQL Server database. The modules shared common information like accounts and contacts.

The Dynamics CRM System

It was around this time that I was in discussions with some organizations that wanted a “core” CRM system to track their customer and stakeholder information, but not necessarily opportunities or cases. These organizations were using paper-based, MS-Access databases or Excel sheets to track critical business data. Using Dynamics CRM, the stakeholder data could be easily tracked in the account and contact entities. We found that we could extend Dynamics CRM by creating custom entities to business records such as projects, grants, applications and dozens of other critical data types.

The Birth of xRM

xRM

This was the birth of using Dynamics CRM as a line of business development platform, aka “xRM” or “anything relationship management”.

With this “platform” you would have the following features available to you to build a “business app”;

Ability to easily create a relational data entity model or extending the model made available by Microsoft.
Able to build a multi-user, web based system.
Built-in security and authentication mechanisms.
A common, easy to navigate, User Interface.
Easy to configure Automation using Workflow
Reporting
Ability to extend using custom code (call-outs, later plug-ins)

We essentially could build a custom app on top of Dynamics CRM.

The Dynamics CRM Platform with the ability to build “xRM” applications.

Around 2010, Microsoft had a campaign that also embraced this concept and even produced a video to promote “xRM” as a “One Platform, Many Applications, Infinite Possibilities” custom software development system.

xRM

For hundreds of “CRM” projects, this concept caught on and there are folks in the community that have worked on many projects but very few pure “Sales, Service or Marketing” type applications. Millions of custom Excel, Access or even dedicated vertical solutions were replaced with advanced xRM systems.

Unfortunately, Microsoft didn’t continue with this line of promotion. It is unclear whether the people in charge at the time didn’t get it, or if Microsoft wanted to promote their other “platform” for building business applications; SharePoint. Microsoft leaders even shot down requests or questions if they would ever release a version of a “naked CRM”; a version of Dynamics CRM without any of the “modules” like sales or service pre-installed.

Side Plot: A Collection of ERP Applications

Got it, Got it, Need it…

Over the years, like a kid collecting hockey cards, Microsoft seemed to acquire a collection of ERP (Enterprise Resource Planning) applications. An oversimplified explanation is that an ERP system is essentially an accounting system with additional advanced features such as inventory, manufacturing or HR modules. The collection includes; Great Plains, Navision, Axapta and Solomon. In the mid 2000’s, attempts were made to consolidate these applications into a new system that went by a code name of “Project Green“. With a large established install base and a resistance to change, this project never really took off and Microsoft continued to support these ERP applications more or less individually.

ERP and CRM systems are similar but are also very different. Accounting principles generally follow the same rules whether you run a lemonade stand in front in front of your house or a multi-million dollar world-wide enterprise. Debits need to equal credits. While ERP functions could be extended, they don’t tend to be great at building custom line of business applications.

Microsoft needed to evolve its ERP systems to the cloud. From their collection, Navision and Axapta seemed to be best suited to be further enhanced to become cloud-based solutions. However, from a public facing perspective, it could look confusing having a rag-tag collection of different business applications for the cloud (NAV, AX and CRM)

The Birth of Dynamics 365

Dynamics 365

This is where Microsoft Marketing came to the rescue. Instead of re-creating all of these as one core business application (like Project Green), instead they came up with the idea to instead call them all the same thing. Microsoft printed off sheets of stickers, slapped them on the products and called them “Dynamics 365” and tried to pass them off as essentially the same business application product. Dynamics CRM also got grouped into this naming frenzy.

Just slap a “Dynamics 365” Sticker on it and call it a day.

This actually caused a bit of confusion as these products, while sharing he same name, were all actually very different. The Dynamics 365 name actually became the name given to Microsoft’s collection of business applications, so Dynamics CRM became Dynamics 365 for Customer Engagement, AX became Dynamics 365 Finance and Operations and NAV became Dynamics 365 Business Central. These names are a bit of mouthful but essentially describe what each of these types of applications functionally do. From a technical perspective, there were some attempts to link them together using some ad-hoc integration methods, but they still stood as individual applications, more or less bolted together under a common name.

Meanwhile, in some other Lab at Microsoft

Microsoft continued to sell these business applications, in another part of the campus, there were initiatives to build low-code, no-code tools to allow non-developers to build custom applications.

PowerApps (the Original)

PowerApps

Project Siena was a garage type project with the goal of providing an easy to use platform for building web based applications without the need for advanced tools such as Visual Studio. This extended upon previous ideas like MS-Access and InfoPath. Project Siena eventually became “PowerApps” (or what we know today as “Canvas based” PowerApps).

Citizen developers can drag and drop controls and fields onto an application canvas and through data connectors link to various data sources like Excel, SharePoint, SQL and many other data sources. Custom functionality can be added with an Excel-like expression language.

Microsoft Flow

Microsoft Flow was also developed as a next generation workflow tool for SharePoint and Office 365. The idea was to be able for citizen developers to be able to connect to different data sources and automate repetitive tasks, move data and streamline communication.

Power BI

PowerBI

PowerBI started out as Business Intelligence tool add-on for SQL Server called Project Crescent. Over time PowerBI became Microsoft’s main business intelligence tool. PowerBI connects to various data sources (including Dynamics 365) to provide advanced analytics and reports.

Power Tools

The combination of PowerApps, Flow and PowerBI provided a powerful combination of functionality where citizen developers could create some pretty powerful applications. However, what was lacking was an citizen developer friendly data storage feature.

Common Data Model/Common Data Service

SharePoint is a great system for managing unstructured data like documents and adhoc lists. However, falls a bit flat when trying to store related, object-based data. MS-Access is also fairly accessible but is based on older desktop based technology and doesn’t have a strong security model. SQL databases (including AzureSQL) provide the ability to store relational data in a robust secure data platform. The issue is that building a SQL database requires some deep technical skills.

Another common issue when an organization builds a set of databases is that different developers will approach building data objects differently. A database table created to represent a person could be named “person”, “customer” or “member” (among other names). The “person” table could also have various data names and formats to track names, addresses and phone numbers. Anyone who has had to consolidate or migrate a number of legacy MS-Access databases knows the pain of mapping and merging the different data models.

I see you called this “Company”, I prefer “Organizations”

To address this, Microsoft developed an citizen developer friendly data store (based on AzureSQL) that already had a predefined set of common data objects like contacts, accounts, activities, etc. (Hmmm, Where have we seen these before?) The predefined schema became the Common Data Model, and accessing databases based on the CDM became known as the Common Data Service. Citizen developers could utilize the existing data objects, extend these with custom fields and also create custom entities.

While the suite of power tools could still connect to various data sources, there was now also a citizen developer friendly relationship database (CDS).

xRM 2.0?

With this new “platform” you would have the following features available to you to build a custom “business app”;

Ability to easily create a relational data entity model or extending the model made available by Microsoft.
Able to build a multi-user, web based system.
Built-in security and authentication mechanisms.
A common, easy to navigate, User Interface.
Easy to configure Automation using Flow
Reporting
Ability to extend using custom code (Azure Functions)

This all seems vaguely familiar…

Now I wasn’t there… so I can’t say for sure that this is how this happened, but can only imagine some kind of “all hands” meeting where the crew that built out PowerApps, Flow, PowerBI and CDS were presenting their radical new set of tools to allow organizations to build all sorts of amazing business applications when a hand shot up from the back of the room from someone from the Dynamics 365 team.

“That all looks really cool, but you know we have all that already, right? For like, 10 years now?”

“What do you mean?”

“Dynamics 365 has a database with a bunch of common things like accounts and contacts. It also has the ability to extend these entities and create new entities. You can also build applications with views and forms. It has a security model, and a few things that your new platform doesn’t have like a solution management system for development. Your workflow thingy looks cool though, and a lot of customers have been screaming for a UI designer like that PowerApps thing you have for years.”

I can also imagine that some high level execs were wondering how millions of dollars were spent building a platform when they already basically had one.

Steve is shocked that the Dynamics 365 Team basically have already built what he is presenting.

The Power Platform Arrives!

Once again, I can only imagine marketing came to the rescue and proposed the idea of taking the best features of both sets of platforms and gluing them together and calling them one thing.

This time the engineers got involved and they they would really merge them (and not fake it like they did the ERP apps).

Armed with a new set of stickers, the marketing folks slapped “PowerApps” stickers on the Dynamics CRM configuration tools. The method of creating Dynamics xRM extensions became “Model Driven” PowerApps and the original PowerApps became “Canvas PowerApps”.

Solution Explorer Before…

Solution Explorer after… all fixed with a “PowerApps” sticker.

The Dynamics 365 for CE business application layer and the v1.0 Common Data Service were merged into a new version of Common Data Service. Many different apps could be built but all talk to the same CDS database, eliminating the need for complex integration tools (we will discuss ERP apps in a bit).

Flow is slowly evolving to replacing Dynamics CRM workflow engine (in the fullness of time). Flow connectors were built to directly interact with the Common Data Service. Users can now build Flows across many different applications and platforms, including competitive products like Salesforce.

Professional Developers were not left out in the cold. Instead of wasting precious time writing simple form JavaScript events hiding and showing fields, they now are tasked with extending the platform with logic apps, Azure Functions, PowerApp Component Framework (PCF) controls and still need to hack out plug-ins!

The result is NOT a cobbled together bunch of software, but something that is truly greater than the sum of the all the parts.

Dynamics 365 as an Application, NOT a Platform

The team didn’t stop there. Dynamics 365 for Customer Engagement got decoupled from the underling platform. Meaning that the Dynamics 365 for CE as we knew it simply became 1st party Model Driven Power Apps. Microsoft continues to develop a full suite of business applications such as Sales, Service, Marketing, Field Service, Project Service, Talent, Retail and many more coming.

CDS PowerApps – Naked xRM!

For a lot of projects, we might not need a Dynamics 365 application (or at least not right away). We can begin our projects using a CDS database and either a Model Driven or Canvas PowerApp (or both). We finally have the “naked xRM” concept in both technology and licensing (via the P1 and P2 PowerApps licensing). Since the applications are built on a CDS database based on a Common Data Model, it becomes a much easier task to link to other applications or even eventually upgrade to Dynamics 365 apps.

Dynamics ERP Apps… Coming Along

Dynamics 365 F&O and Business Central also continue to be slowly merged into the platform using various connectors and dual write functions. Note there is a lot of legacy there so rebuilding on the Common Data Service isn’t a trivial task. The Power Platform provides some data integration templates and will continue to evolve toward a true common data platform.

We now have the Power!

The combination of all these amazing features is what became and is the “Power Platform“. This has become the “xRM” platform that many of us have been dreaming about for many years, but in some ways so much better than we imagined.

The Power Platform

With new technologies being implemented such as AI, Mixed Reality, Bot Agents and dozens more makes the Power Platform a solid foundation for building advanced enterprise business applications.

The Power Platform has truly become “One platform, Many applications, Infinite possibilities”.