Why does low-code need a programming language like Power Fx?

At Ignite 2021 virtual event, Microsoft announced a low-code programming language called Power Fx. “A low-code programming language for everyone”.

Wait a minute: wasn’t Power Platform supposed to offer graphical tools for citizen developers, so that they can just point & click to build the apps they need? Why is Microsoft inventing a new language that requires the app makers to write something that resembles actual software code? Won’t this make things more complex and more difficult to approach?

First of all, this “code” actually already exists in Power Apps. It is exactly the same formulas that the app makers have been using inside their Canvas apps for as long as Power Apps has been a thing (even when it was still spelled “PowerApps” with no space). What Microsoft is now doing is giving this formula language an actual name, Power Fx.

In a way, it’s yet another name change like the ones we’ve seen a lot in the MS Business Apps space. However, as the feature didn’t really have a specific name to begin with, it’s not a rebranding effort this time but rather about establishing a new concept.

All this effort wouldn’t be justified unless Microsoft had bigger plans for Power Fx. They certainly do, and that’s what makes the announcement significant for the low-code story of Power Platform. Being a family of loosely coupled products, the platform in its current state has various different places where “low-code code” is used for expressing formulas and business logic. The first areas that will see new Power Fx based features launched later this year will be Model-driven apps, AI Builder and Power Virtual Agent.

This brings us to an important point: no new functionality was launched at Ignite. Canvas apps are the only place where Power Fx code manifests itself today. As described by Greg Lindhorst, the announcement on March 2nd 2021 is just a statement of direction at this point.

Code isn’t a new feature in low-code

The demos for “build an app in 15 minutes” that Microsoft used to show in their Power Apps keynotes a couple of years back didn’t ever go beyond the graphical UI for app makers. As a result, those users who approach Power Apps from the Office perspective and have only ever focused on the Canvas apps side may not even be aware of the amount of actual code that has been used to extend the more complex implementations of Power Apps.

Dataverse, the underlying data platform that was formerly known as the Common Data Service, offers a rich event framework that can be extended with plug-ins written in C#. Custom functionality on the Model-driven apps UI can be implemented with JavaScript based client-side scripting. External apps can talk with Dataverse via the OData based Web API.

These programmatic methods for building, extending and integrating Power Apps have been more prevalent in scenarios where the end users see the apps as Dynamics 365. After all, they require including a skilled software developer to be included in the delivery team. As a result, the code part of the app creation doesn’t exactly fit into a 15 min demo, rather you’ll need a project that facilitates this development part.

Even when using perfectly supported extension points, the responsibility for ensuring the custom code works throughout the lifecycle of the application is ultimately not on Microsoft but the customer. Hence there needs to be a more formal arrangement on how the customer specific code is developed and maintained, either via a partner or an internal software development team. These are reasons why enterprise IT needs to exist and be closely involved with code-heavy business apps.

Code for citizens: business logic

Alongside these formally managed IT systems, there’s often a wealth of business processes that in practice rely on application logic created by business users. Complex Excel sheets with tens or hundreds of formulas may be used in making decisions that have significant financial impact for the organization. Yet this logic isn’t covered by any of the policies and practices for business applications, as it manifests itself as a document rather than an app.

Low-code tools like the ones included in Microsoft Power Platform offer a path for moving business processes away from ad-hoc messaging and document based data manipulation towards more formal and scalable systems. The need for complex business logic is rarely reduced in this transition, though. Someone still has to define what the calculation rules are, as well as keep them up to date as the business requirements evolve. Increasingly this can be done by the same domain experts that have built the earlier Excel workbooks, as the operations don’t require actual software code.

The examples given in Power Fx documentation demonstrate the difference between writing business logic in formulas vs. using a “real” programming language like JavaScript. Dealing with relational data, asynchronous calls, localization, optimizing what data is retrieved, when it is retrieved… Power Fx takes care of all these concepts and lets the app maker focus on describing what the app should do – not the specific implementation details.

Excel-like formulas can be quite efficient in describing business logic while abstracting away the need to know in detail how the surrounding software works. This is why the founding idea behind Power Apps formulas has always been to make them work and behave as close to Excel formulas as possible.

As the saying goes: less is more. In this context, the less we require app makers to have knowledge on the computer science domain, the more people can bring in their expertise from the business domain and build solutions. According to figures published by MS, there could be almost a hundred times more people who know Excel formulas vs. who know JavaScript.

As Charles Lamanna, Microsoft’s CVP for Low Code Application Platform, keeps telling us, there simply aren’t enough pro-developers out there to meet the surging digital demand for business apps. Therefore it isn’t actually a question between pro-code or low-code for businesses. It’s becoming a choice between a digital solution or no solution.

Business problems will be solved with what’s available. If there’s not enough resources for building apps with JavaScript (either skills or money to hire developers – or simply time), then low-code tools will certainly be evaluated. Forrester analysts already estimate that 75% of all enterprise software will be built with low-code technology in 2021.

Source code for low-code

When low-code moves up the enterprise ladder, from just being simple personal productivity apps for a small team (increasingly running on Dataverse for Teams), it will have to become compatible with existing development and governance practices.

After all, moving away from business logic buried within Excel workbook formulas isn’t going to make the digital business processes any more manageable if apps will be treated as personal documents. Excel formulas inside .xlsx documents and Power Fx formulas within .msapp documents are roughly the same thing – unless you leverage the platform features that the latter ones can work with.

Source code version control is a concept that hasn’t previously been all that applicable to the tools in Power Platform (aside from enterprise systems running Dynamics 365, of course). Microsoft has been working on enabling the source code centric approach for managing low-code solutions across their stack. On the Power BI side, the enhanced dataset metadata feature is turning the Power BI models into common JSON format that could be stored and version controlled in Azure DevOps or Git repos.

Power Apps are following a similar path with Power Fx and the recent announcement for source code file support. The new file format for managing Canvas apps is based on YAML and it aims to make it possible to not just version control it but also edit via non-graphical pro-developer tools like Visual Studio Code.

None of these changes mean that app development or report development on Power Platform is moving into code-first territory. A citizen developer is unlikely to work directly with Visual Studio Code nor configure any DevOps pipelines. They can, however, be part of what’s referred to by Gartner as “fusion teams”.

These cross-functional teams consisting of business and IT professionals are where software development practices like CI/CD may be applied to cover not just custom code but low-code based components. We could therefore think of the source code versioning and manipulation support in tools like Power Apps and Power BI to be an “API” that allows the two parties to collaborate efficiently.

Platform unification for achieving enterprise trust

This brings us to the five focus areas that Charles Lamanna’s team at Microsoft is working on, to take low-code to the next level:

The role that these new code-based features in Power Platform have in achieving the above targets is quite central. While the cool new features for app and automation makers will most likely keep on rolling out throughout 2021, the strong enterprise emphasis is where Microsoft’s biggest investments are likely to be made. This is clearly visible from the Ignite announcements on new IT governance and admin tools.

The governance tools deal mainly with questions like “what do we have in our tenant” and “who can access which endpoints”. They address the immediate needs for enterprise IT to ensure that data and applications used by a growing number of employees across different teams aren’t spinning out of control. You could think of these administration capabilities as the foundation that needs to be in place for Power Platform based tools to gain formal authorization within the organization.

Once you get past the “what tools do we have” phase, it becomes a more relevant discussion to think about how you build and develop them. Languages like Power Fx will make it easier to approach questions on where and how the business logic of your apps is developed and managed. Connecting these Excel type formulas with the existing solution framework of Dataverse will bridge the gaps between realities of Canvas app makers vs. Model-driven app developers.

Eventually the stack of Microsoft cloud technologies that you use for delivering both low- and pro-code solutions to your business users may indeed look like the above vision.

It’s important to keep in mind that this is not about turning low-code into pro-code or vice versa. The intention is not to teach every business user how to write code. The goal is to enable everyone in the organization to become a developer.

2 comments

  1. Mr.M
    2021-03-11 at 01:03

    So is that going to be another extension beside .bat

    Potential new SQL kinda thing.

    1. Jukka Niiranen
      2021-03-11 at 13:40

      I don’t think that Power Fx would turn into a file type of its own, at least not quite yet. The source code for Power Apps Canvas apps is being managed in YAML files within the .msapp package. The format in which the other tools that implement and manage Power Fx formulas could of course be different. When MS eventually publishes true source code of Power Fx itself and there will be the possibility for other parties to also adapt it, things may change on this front, too.

Leave a Comment