Power Platform vs. classical programming

Advantages and limitations of low-code

The development of individual software for mapping business processes has undergone a remarkable transformation in recent years – particularly in the Microsoft 365 environment around SharePoint. The question increasingly arises as to which development platform offers the greatest added value for companies.

Up to now, classic software development approaches have been used, such as solutions based on SPFx web parts in combination with Azure Functions. However, with the introduction and continuous development of the Microsoft Power Platform, a powerful low-code alternative is available that is becoming increasingly important.

In this blog post, we shed light on whether low-code applications – for example with Power Apps and Power Automate – are worthwhile compared to classic development approaches. How do the two approaches differ in terms of development effort, expandability, operation and maintenance (especially when it comes to troubleshooting and bug fixing) as well as cost structure? We will give you a well-founded overview and support you in choosing the right architecture for your next project.

Low-code vs. classic development: a comparison of typical architectures

A frequently used traditional software architecture consists of a combination of client-side SharePoint Web Parts with SPFx and React for the front end and Azure Functions in C# as the back end. Microsoft Teams Apps can also be used as an alternative to SharePoint Web Parts.

In comparison, we look at Microsoft’s low-code development platform, which uses Power Apps (Canvas Apps) as the front end and Power Automate (Cloud Flows) as the back end. Both approaches have their merits, and in this article we look at the advantages and disadvantages of each.

Low-code refers to a development approach that either does not require traditional programming languages or only requires a minimal amount of code. There are various platforms on the market for this approach – for example from Microsoft, Salesforce or AWS.

The major strengths of low-code lie in accelerated development and potential cost savings.

The following table is based on experience from customer projects and compares the two approaches using specific criteria.

	Power Platform	SPFx and Azure Functions
Development effort	Low	Medium to high
Expandability	Depending on premium licenses	Flexible
Complexity of the application	Simple use cases	Simple and complex use cases
Operation, maintenance and bug fixes	Partly cumbersome	Follows standards
License and platform costs	Low (except when premium licenses are required)	Low (various app plans available)

The citizen developer approach: potential and challenges

Even if at first glance the Power Platform appears to be the ideal solution for implementing enterprise applications, you should be aware of the advantages and disadvantages of low-code solutions when deciding on the architecture in order to be able to develop a successful application in the long term.

The initial development effort is usually significantly lower than with a traditional code solution. The citizen developer approach in particular, in which specialist employees from the specialist departments are involved in the development process, is often emphasized. However, this usually only happens in connection with the automation of personal workflows.

Why the Citizen Developer approach often fails

• Too little time in addition to their own day-to-day business
• Often little technical understanding
• Little or no knowledge of standards / best practices
• Complex use cases
• No experience in bug fixes and operations

On the one hand, most employees from the specialist departments do not have the time to deal intensively with a development platform. The complexity of the use cases often exceeds the skills of citizen developers. Most specialist employees also lack the necessary experience in software development and best practices. When it comes to operation and troubleshooting, many reach their limits.

It can be a challenge for IT to take over operations. In addition, most companies define numerous requirements for business-critical applications that are difficult to implement without project management and professional software developers. Therefore, companies should carefully assess whether an application is suitable for the citizen developer approach or whether a professional development team should take over the project.

Center of Excellence: Support for Citizen Developers

A Center of Excellence (CoE) is a team or organizational unit that focuses on the distribution and development of specialist knowledge and best practices for specific topics. This includes offering training courses, providing knowledge resources and supporting citizen developers in the specialist departments. The establishment of a Center of Excellence for the Power Platform is a good way of countering the risks through the Citizen Developer approach. If employees in the specialist departments get stuck, they can get technical support. In addition to supporting the specialist departments, the employees at the Center of Excellence focus on developing best practices and establishing uniform standards to ensure quality.

Limits of the low-code approach through premium licenses

In the course of an application life cycle, extensions are often made – sometimes even during the initial development phase. Almost anything can be implemented on the Power Platform. The possibilities are almost limitless. However, users require premium licenses for most functions, which are not included in the normal subscriptions (e.g. Microsoft 365 E3 / E5) and must be purchased additionally per user. Many companies do not want to pay the ongoing costs and therefore limit themselves to the standard functionalities of the Power Platform. If you use Dynamics 365 in your company, the situation is different. The premium functionalities are included in most Dynamics licenses. The integration of Dynamics 365 and the Power Platform is excellent and represents great added value for companies with Dynamics 365.

Often companies without Dynamics 365 licenses make compromises to avoid the additional ongoing costs of Power Platform Premium licenses. Some requirements are put on hold and never implemented. If it becomes apparent during application enhancements that new functionalities are only possible with premium functionalities, there are really only three options:

• Waiver of the new functionalities
• Payment of the running costs for premium licenses
• New development on a different architecture

At this point, weighing up the options is a question of costs and benefits for the company. For this reason, we recommend choosing an architecture whose expandability is independent of the license model and offers flexible options for applications whose functional scope and possible future expansion requirements are not yet clear at the outset.

Data storage: Where is the data stored?

This list hasn’t yet addressed the important question of where application data is stored on the Power Platform. The Power Platform provides several options through its connectors. Many users choose SharePoint, as it’s a standard connector commonly used in applications. However, users often encounter issues when running certain queries on larger datasets (2,000 items or more). If filtering or sorting is involved, the results of complex queries can be incomplete.

Microsoft actively promotes Dataverse – the Power Platform’s own data platform – both in Learn articles and within the user interface. However, using Dataverse immediately places you in the premium licensing tier. Additionally, the available database capacity is very limited and can only be increased for an extra fee.The license model has changed again and again in recent years. Not always to the benefit of customers. However, there are also connectors to classic databases, such as SQL databases. At the beginning of the Power Apps era, the SQL connector was included as standard. In the meantime, the SQL connector can only be used by users with premium licenses.

Depending on the business case, the connection of a Power Automate Flow or Power App with a database should be critically scrutinized:

• Is a technical account or the app user used for registration?
• How are the authorizations for read or write access ensured?

The implementation of authorizations is part of the business logic and is usually mapped in the backend. This ensures that the database is in a consistent state in terms of content. Power Apps in combination with Power Automate quickly reach their limits. This is illustrated by a look at the common architecture of a Power Platform solution consisting of a canvas app and several Power Automate flows:

Direct data access and authorizations with SharePoint as data storage

As a rule, developers integrate data directly into Power Apps as a data source. The app sends queries and save operations straight to the database. This means that record-level authorizations must be implemented directly in the database. In SharePoint, for example, row-level permissions are only feasible for a limited number of records and quickly reach their limits when dealing with large datasets. Field-level authorizations are not possible at all.

Developers implement business logic – such as sending emails, reminders, and approval workflows – in the backend. Some flows are triggered directly from the Power App, while others run automatically, for example, when a new item is saved in SharePoint.

Using the example of SharePoint lists as data storage, this would mean that users need direct access to the data in SharePoint in order to be able to use the data in Power Apps or Power Automate. If the users call up the SharePoint website, they can also view, edit and delete the data here according to their authorizations. This allows users to bypass any implemented business logic from the Power App or the associated flows. SharePoint offers options for hiding lists from users, but experienced users can still access the data.

Error handling in Power Platform vs. classic development

If you want to implement error handling in Power Apps or Power Automate that covers common standard errors, the complexity quickly increases considerably. A flow originally comprising 10 steps can easily become 30 steps or more. Error handling blocks are often repeated several times within a flow and are difficult to outsource.

The attempt to outsource recurring error handling elements to parent and child flows often leads to problems in practice. This differs significantly from classic code projects, in which functions can be called multiple times and flexibly at different points.

The options for implementing error logging in classic development projects are diverse and usually only require a small amount of additional work. In contrast, the effort required to implement meaningful and traceable logging in Power Automate Flows is significantly higher.

Advantages of an SPFx web part with Azure Functions backend

In addition to the flexibility in terms of expandability, a major advantage is that complex business cases in particular can be implemented with a detailed authorization concept at the level of individual data records. The SPFx web part in the frontend functions exclusively as a display element, while the entire business logic is mapped in the backend.

This clear separation of frontend and backend significantly improves the maintainability and scalability of the application. Both areas can be developed and optimized independently of each other. Communication takes place via standardized interfaces, which promotes the reusability of the individual components.

This architecture also contributes to greater security: Sensitive data is processed in the backend and transmitted via a protected API only to authenticated and authorized users according to their roles in the application.

The diagram shows the classic architecture consisting of a front end for display and a back end with business logic and database access:

Users logged into Microsoft 365 call up the page with the SPFx web part. The frontend sends a request including the user context to the backend and receives the role of the current user and the initial data to be displayed in response. The backend uses the stored business logic to check which data the user has access to in their respective role.

All data access takes place exclusively in the backend – in the case of SharePoint via an Entra App registration. This means that users do not have direct access to the database. The authorizations therefore do not have to be implemented at database level, but flexibly in the backend in accordance with the business logic. Both read and write access to individual fields, based on the role or status of a process, can thus be easily implemented.

Access to other data from Microsoft 365, such as SharePoint sites, Teams or calendar entries, can also be set up via the Entra app registration. This enables flexible expandability and seamless integration of the application into everyday working life.

Outlook: Which solution suits which use case?

The Power Platform is a valuable resource for companies that want to implement simple solutions quickly. However, for long-term stable applications, the effort required for operation, maintenance and extensions should not be underestimated.

For more complex requirements, especially if premium functionalities are required, a flexible architecture such as SPFx in combination with Azure Functions is recommended. It enables a clear separation of frontend and backend as well as a robust authorization concept – ideal for the secure handling of sensitive data.outlook: Which solution suits which use case?

Summary

• Comparison of low-code and classic software development: Both approaches have their advantages and disadvantages.
• Risks of the Citizen Developer approach: Employees in the specialist departments often have insufficient resources and technical understanding.
• Cost efficiency vs. long-term expenses: Short-term benefits can be overshadowed by later operating costs.
• Recommended action: Setting up a Center of Excellence helps employees in specialist departments to develop their own applications and automations in their day-to-day work.
• Architecture consulting: The challenge lies in choosing the right platform for the right use cases and identifying risks and KO criteria at an early stage.

Are you faced with the decision between low-code and classic development? Our experts will help you find the right architecture for your individual requirements. Contact us for a no-obligation consultation and benefit from our experience in developing customized solutions!