Building or Configuring: Where Does the Work Actually Go?
By Colin Yates, Director, WorkMobile
Low-code has changed application development enormously, but I sometimes think the name gives people the wrong impression. It can sound as though much of the work involved in creating an application has disappeared when, in reality, a lot of it has simply changed.
I spent many years working as a software developer, and one of the things you learn fairly quickly is that writing code is only one part of creating software. Before anything useful reaches a user, decisions have to be made about how the application should work, what information it needs, how people move through it and what should happen when something changes. The tools used to create the application may make those decisions easier to implement, but somebody still has to make them.
That is why I find the distinction between building and configuring more useful than the distinction between code and low-code. The real question is not simply how much programming is involved. It is how much of the application itself the organisation needs to create.
Low-code still means building an application
Power Apps is a good example of how much application development has changed. A capable Power Platform developer can create a useful business application without writing thousands of lines of conventional code. Visual tools, formulas, connectors and reusable Microsoft services make a great deal possible without starting from scratch in the traditional sense.
There is still an application to design, though.
Suppose a department needs a new internal process. Someone has to decide what type of application it should be and where the data will sit. The information needs a sensible structure. Screens and navigation need to make sense to the people using them. Rules have to determine what users can enter and what happens when particular conditions are met. Permissions need to reflect who should see or change different information.
If the application needs notifications, document production or connections to other systems, those become part of the design as well. Where it will be used without a reliable connection, offline behaviour has to be considered. Once the application is assembled, it needs to be tested with the people and devices that will actually use it before moving into the live environment.
None of those things are problems with Power Apps. They are simply part of creating an application. Low-code has made many of them quicker and more accessible, but it has not removed the need to think about how the pieces fit together.
For something relatively straightforward, one experienced Power Platform developer may be able to handle most of that work. As an application becomes more involved, other knowledge often comes into play. The person building it may need to understand data relationships, security roles, connectors and how changes move between development and live environments. Operational people may also need to explain the process, while IT or data specialists become involved where the application touches other parts of the organisation.
From a development perspective, none of this is particularly surprising. The organisation is creating its own application, so it needs to make the decisions that come with doing that.
Configuring starts further along the road
A configurable operational platform begins at a different point.
WorkMobile is one example. It is designed specifically for field and operational workflows, so the mobile application and the main operational components already exist. User access, offline data capture, synchronisation, job distribution, evidence handling and report generation are part of the platform rather than something that has to be recreated for each new workflow.
That does not mean there is nothing to design. In fact, there can still be a fair amount of work involved. Someone needs to understand the process properly and decide what information should be collected, which questions should be mandatory, who should receive the work and what should happen when it comes back. User groups, job types, approval stages and the finished reports still need to reflect the way the organisation operates.
The difference is where that effort is being applied.
Take something as simple as photographs. The operational discussion might be about which photographs are required, at what point they should be taken and whether somebody can complete the job without them. Those can be quite important decisions.
What the organisation is not also deciding is how to create the camera function, where the image should be stored or how it should be associated with the correct record.
The same principle applies to job allocation. There may be plenty to agree about who should receive a job, what information they should be given and how its status should be represented. The underlying mechanism for getting the job onto the mobile application, however, is already part of the product.
Reporting follows much the same pattern. The business still needs to decide what the completed document should contain, what it should look like and who needs to receive it. It does not first have to create the mechanism that turns the completed operational record into that output.
Configuring does not mean avoiding the difficult questions
I think this is an important distinction because the word “configuration” can sometimes make a project sound almost trivial. It isn't.
The organisation still has to understand how its own process works. In my experience, that is often where some of the most valuable discussion takes place. What information do we genuinely need? Which evidence is important? Who should be able to see the completed record? What should happen when something fails or needs further review?
Those questions do not disappear simply because the underlying software already exists. If anything, removing some of the application-level decisions can make it easier to spend more time on them.
At WorkMobile, the organisation brings the operational knowledge. It understands the work, the people carrying it out and what a useful completed record should contain. The platform provides more of the technical framework within which those decisions can be put into practice.
That changes the type of knowledge needed to make an amendment as well. If somebody wants a new question on a form or a change to an approval stage, they are working mainly with the operational logic of the process rather than designing new data structures or application components around it.
This is not the same as saying configuration offers the same freedom as application development. It doesn't. A development platform gives much greater control over the interface, logic, architecture and connections surrounding an application. Where the requirement genuinely depends on that level of control, there may be good reasons for taking on the additional development work.
The distinction is simply that a configured workflow begins with more of the application already decided.
So where does the work actually go?
When I look at the two approaches, I don't think of one as involving work and the other as avoiding it. Both require thought, and both depend on somebody understanding the business problem properly.
The difference is what people are spending their time deciding.
When building an application, part of the effort goes into the application itself: its data, screens, logic, permissions, connections and behaviour. With a configurable operational platform, more of those underlying components already exist, so more of the effort can go into the process being supported.
That is why I prefer to think of low-code and configuration as two different starting points rather than two different levels of difficulty. Power Apps reduces the amount of conventional coding required to develop an application. A purpose-built operational platform can go a stage further for the processes it was designed to support, because the underlying operational application does not need to be developed again for every new workflow.
Neither route removes the need to understand the requirement. They simply put the work in different places.
This article is part of a series exploring the themes in WorkMobile's white paper, Power Apps Can Build Almost Anything. But Should It?
