“Now everyone can quickly build and share low-code apps with Microsoft Power Apps” – this is the slogan you see when you open https://powerapps.microsoft.com/en-us/
This is how Microsoft sees Power Apps, and, in the bigger schema, this is what Power Platform is all about – democratizing development by providing the tools everyone can use. With Power Automate, we can connect to almost everything almost everywhere, and, then, we can perform actions on those connections without writing a single line of code. With Power Apps, we can use the same connectors, but, this time, we can create UI experiences without writing any pro code.
Naturally, when looking at it that way, the next logical step would be to encourage business users to start writing applications for themselves since, of course, they are the ones who know how businesses operate, and, from that standpoint, they have obvious advantage over developers who might be able to use pro-code, but who would not be able to foresee all the peculiar scenarios their applications may have to cover because of how businesses are supposed to operate.
Traditionally, application development would be organized around a project team, and that team would be expected to follow some kind of delivery methodology – it could be agile/scrum with all the user stories, it could be waterfall with all the business requirements, or, possibly, it could be something else. However, all of those would, normally, assume that business requirements would be captured, this way or another, before development starts. This would be to ensure that all those peculiarities of the business process were clearly explained to the developers, and, therefore, to eventually develop applications that provide expected functionality.
With the introduction of low-code, which has brought application development within the reach of the actual business people, where is this all going to go? Is it, really, that everybody in any organization will start building low-code apps or is there more to it?
Personally, I believe there are at least a few things to keep in mind:
- Business users are not going to become low-code developers just because they can
- For any organization to stay manageable, there should be some consistency in the data it’s collecting from various sources and in the processes it’s following
- There are certain rules an organization may need to follow, and those rules may have to be enforced (think of various data protection laws, for instance)
I will talk about this more below, but, just by looking at the list above, you can probably see what I’m going to arrive at, and, basically, it’s that an organization may have to meet certain conditions to really start benefiting from the democratized application development.
Why so?
First of all, if you think of the business folks, they have their immediate operational responsibilities, and, often, their performance might be measured by certain metrics. Those have nothing to do with application development – this holds true for the sales agents, this holds true for the CEO-s, and this holds true for the business owners.
Of course some of them might be interested to jump into the application development since this would be something they always wanted to try, but there we are talking about people trying another hobby. For those turning to the low-code tools to improve their personal efficiency, there will always be a very interesting dilemma (I find it surprising “improving personal efficiency” is often touted as a benefit, since it’s sort of ignoring the obvious): you can become more efficient, but, once your secret is revealed to your peers, they will all reach the same level of efficiency, and you will all be equal, again. What’s the point? It seems obvious, so why would anybody other than those who have been given some incentives push for the personal efficiency? Of course business owners would be naturally incentivized to improve personal efficiency of their employees/contractors. People on commission might also see benefits in becoming more efficient, even if that end up being only a temporary boost in payments.
However, for most of the business folks, unless, again, they were always dreaming of doing this, the idea of becoming a low-code developer might seem far from what they would really want to be doing on their spare time.
And there is no judgement there – after all, not that many pro-developers would want to become sales agents, right?
Although, there could be an alternative (or complimentary) approach where organizations will start encouraging employees to spend time on citizen development somehow. Possibly, they will, but, this way or another, for the business users to start using low-code development tools, they must be willing to do so. In other words, everyone probably can start developing apps now, but not everyone will.
But that would still be only the first step. Imagine everybody jumping into it and starting to develop all sorts of low-code applications. For everyone involved, it might turn into a really interesting experience, but, in the end, if some of those applications start storing their data in Excel, other are going to start using personal one-drive, and yet others would opt for and Azure SQL database, this will become a nightmare for the organization. Since, after all, you need to ensure the data produced by all those apps is available and manageable somehow. Otherwise, what’s the point in having that data?
But, even when you have manageable data, you can’t really allow one sales person to start following a process that’s completely different from what another sales person would be doing. Mind you, there might be advantages in doing exactly that, since, after all, this way the organization might be able to invent and/or identify better processes.
And, then, the second pre-condition for “everyone starting to do low-code development” would be to either have standardized business processes in the organization (so, any improvement that someone comes up with would be useful for others), or to implement some sort of “incubator” program where the organization would be able to identify the improvements made by individual citizen developers and adjust remaining business processes accordingly. Which, in the end, will lead to standardizing the processes across the organization.
Again, those scenarios are not, necessarily, mutually exclusive. There could be well-defined data and processes in the organization, but there could still be room for significant process adjustments (not just for minor process improvements/“automation”).
Let’s say there are people in the organization who can see how turning to low-code development might be useful to them, and let’s say there is some structure to the organizational data / processes those folks can rely on.
There can still be internal / external regulations and rules that the organization has to follow, and that may have to be accounted for while doing any sort of development (be it low-code or pro-code). Externally, those rules may come from various source, and of course, various data protection laws would be one such example. Internally, there might be a need to ensure integration of certain data with specific systems – for example, when taking a payment through a low-code app somehow, and assuming finance users are relying on SAP to see all financial data, some kind of integration may have to be implemented to ensure all payment data ends up in the SAP.
How would you enforce that on the organizational level? Since it is very unlikely every low-code developer would just start following those rules. The only way I see that happening is by somehow implementing an application development methodology that would be followed by everyone in the organization, and, then, you would need someone (possibly a team) to oversee proper implementation of that methodology on each “project”.
This could all be represented by a funnel like this:
In the end, low-code development has a lot of potential, and it’s true that “everybody can start building applications”. Whether they will, and whether they even should, depends on a number of things, though, in the end, it all comes down to whether the organization is seeing this as an opportunity to improve, whether it has create the environment that encourages application development by “everyone”, and whether it has the mechanisms to ensure that development is done consistently across the board.
This is not to say it’s not possible, and, where possible, it might be really beneficial, but, in many cases, getting there is not a small feat.