On every occasion that I have worked for an organisation of any size, I have come across an application service that has been implemented with a rapid application development platform (RAD).

In the most rudimentary situations, it was spreadsheets on steroids (Microsoft Excel). In other contexts, I was more likely to maintain Microsoft Access databases, with forms, reports, and code VBA.

Admittedly, I agree that at times the implementation with these tools flirted more with application coding than RAD.

In each situation, these RAD platforms were formally distributed to users at their workstations. And in each situation, these application services filled a gap.

Microsoft Excel or Access have not disappeared. In recent years, however, aPaaS (application Platform as a Service) platforms have emerged that further simplify the implementation of application services. Because, yes, users still have needs that are not covered by the application services officially supported by the organisation.

But then, how can we do things differently or even better today?

To better understand, let’s start from the genesis of the application service by putting ourselves in the shoes of its designers.

At the beginning of the existence of an application service, its designers look at the landscape, the context, in which the service will be built, from the point of view of:

  • Business: Who it will serve, what capacity supports it, what processes are implemented.
  • Data: What data will be processed, organised, secured and distributed.
  • Application: Which applications interact with the data and implement the business processes.
  • Technology: Which hardware and software technologies will support the entire construction.

Choices will therefore have to be made on each of these points. And we hope that these choices will be made by collective decisions.

Technology

When starting to build the application service, it will therefore be necessary to take a position on the technologies to be used. To facilitate such decisions, the organisation may have standards, guidelines and principles. One such principle might be “Subscribe over Build”. In fact, one will choose to take a service from the market (SaaS) before launching a project. If, however, it is an emerging service, specific to the organisation and which differentiates it, then one will choose to build it from scratch.

But is it really ab nihilo?

When we start talking about IT development, it is customary to neglect the technologies that allow us to quickly generate an application service. There is a tendency to debate whether this or that technology, this or that programming language, etc. is the best way to build an application service. So should I code the application service or build it with a platform that gives me the building blocks without me having to code it myself?

That is why most articles about aPaaS platforms explain the benefits they bring:

  • Distribution of development to all employees,
  • Scalability of service,
  • Organisational and business domain agility,
  • Reduced time to market for the service,
  • Easier integration with other application services,
  • Reduction of quality controls,
  • Increased data security,
  • etc.

These benefits are probably undeniable and obvious. And may even be the reason for the adoption of these platforms. I will not participate in trench warfare that debates the veracity of each of these elements.

In the world of metrics, of the distinction between the qualitative and the quantitative, these platforms bring something they didn’t expect: Shaking up organisations.

Empowering employees…

Wikipedia has made it possible to reduce the hierarchy and give every person the opportunity to contribute to an encyclopaedia without that person having first been inducted as an editor.

An aPaaS (Low-Code or No-Code) platform offers everyone in the organisation the possibility to contribute to, define and develop the organisation’s information system. This person becomes a citizen developer and is therefore part of the developer community.

It is true that enterprise architects often wish to have control over the information system landscape. Assumptions of this type are usually articulated:

  • Business processes must all be aligned across business units,
  • Each application service should have a positive return on investment,
  • There should be only one application service for one business capability,
  • The number of technologies deployed should be reduced,
  • and so on.

These injunctions, which generally lead to the setting up of validation and control committees and the definition of standard architectures, weigh down the organisation and only give the illusion of control by imposing a pervasive bureaucracy.

With aPaaS platforms, even if minimal governance is required, enterprise architects must nevertheless loosen their grip on the information system. After all, they do not own it.

In the framework of aPaaS platforms, together with the services that citizen developers provide, they contribute to the design and development and maintenance of the information system.

In fact, more than the information system they design, create, or maintain, citizen developers redefine the shape and scope of their organisation as they go about their business and process execution.

… Or freeze the organisation

As stated by Melvin Conway, the system designed by an organisation produces a design that is a copy of the communication structure of their organisation.

Organisations, who design systems, are constrained to produce designs which are copies of the communication structures of these organisations.

Melvin E. Conway

With this statement, posed as an adage, one can also imagine that there is a risk that the information system will lead to a stronger crystallisation of the organisation. It doesn’t matter, moreover, what technologies are used to create this information system.

It is easy to imagine a company with a strong hierarchical component; the employees have very specialised tasks and do not understand the whole of what the organisation does. So much so that some tasks may be done twice or very often for nothing. Let’s take an example to illustrate this point.

A paper story

Every month, the specialists print out the test results and send them to another unit in the laboratory. These specialists do not know much about this other unit. The interface, agreed long before these specialists started working here, is to provide the results in paper form: one sheet per result.

The receiving unit has always refused to allow this process to be digitised. For the specialists this is incomprehensible, but the task is not too difficult. However, with one click all the details could be provided in a spreadsheet.

One day, however, the logistics department decided to change the type of paper for economic reasons; the new paper was thinner. The change took time, as the paper stocks are renewed every 6 months.

A few months later, the department receiving the result sheets panicked and immediately sounded the alarm. Their process no longer works!

It is difficult to see at first glance why reducing the thickness of the paper is a problem. Yet the specialist should have been able to discuss with his other colleagues to better understand how the results were processed.

Indeed, only the number of tests was important. And it was by measuring the weight of the pile of sheets that the number of tests was calculated. As the paper was thinner, it was also less heavy. In the end, the calculation of the number of tests was simply wrong. Here, the principle “Contractualise” would have prevented this pitfall.

An aPaaS platform does not, of course, solve this situation - in this case communication difficulties - directly. It may even freeze it and make absurd and unnecessary tasks automatic.

On the other hand, the low cost of the application services and the aPaaS platform on which they are implemented allows them to be added or removed unashamedly.

In our example, instead of printing the result sheets, specialists can easily change the interface of their service so that it returns, via an API or even email for a more rudimentary interface, the number of results to the other unit.

This example seems extreme, but the book “Les Décisions absurdes” by Christian Morel lists much more grotesque situations.

Conclusion

What is different from then?

The application services of these developers are no longer scattered on client workstations. They are made visible on a platform. Data is backed up and secured. Performance problems are managed.

However, if an aPaaS platform provider tells you all the benefits we saw in the “Technology” chapter without explaining the disruption, to a greater or lesser extent, that such a platform brings to the organisation, then you are dealing with a charlatan. You know, the kind of people who used to walk the streets selling you a miracle drug with great eloquence and confidence. Nowadays, it’s more like influencers on Instagram or Tik Tok trying to sell you Web3 or cryptocurrencies.

The aPaaS platforms are the present as well as other building blocks, components, which already constitute our information systems today. It would be difficult to program all software in assembly language or machine code today.

It is therefore important to adopt aPaaS platforms as a building block, but also:

  • use it as a liberating element of the organisation,
  • helping to create the necessary governance of the platform,
  • build a community of citizen developers who share their business issues, not only with each other, but also with coded application developers, architects, UI/UX designers, etc,
  • to include the consumers of the services thus provided in a continuous process.

In the end, the question is not “should we have an aPaaS platform or not”, but rather “how do we adopt an aPaaS platform?