Eines de desenvolupament: LOW-CODE i NO-CODE

Elaboració pròpia: la font és de pagament i no es reprodueix

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. Eines de desenvolupament: LOWCODE i NOCODE.

1. Definicions

Les dues són eines de desenvolupament visual: es construeix l'aplicació component a component sobre un llenç, i la plataforma en genera l'execució, les dades i el desplegament. El que les separa és una sola cosa —si es pot escriure codi o no—, i d'aquí surt tota la resta: qui les pot fer servir, fins on arriben i quan es queden curtes.

Tots dos comparteixen: desenvolupament visual (arrossegar i deixar anar), components predefinits, connectors a fonts de dades, plantilles, desplegament automatitzat i cicle de vida gestionat per la plataforma.

Concepte relacionat: el citizen developer és la persona d'una àrea de negoci, sense perfil tècnic, que construeix aplicacions amb aquestes eines dins d'un marc de govern establert per TI (Tecnologies de la Informació). El que el distingeix de qui munta una fulla de càlcul pel seu compte no és l'eina: és que treballa dins d'aquest marc; quan hi treballa fora, el resultat és shadow IT (§5).

2. Quan usar cadascun

El cas natural del no-code és el tràmit intern simple: agilitzar la creació d'un formulari de sol·licitud de material d'oficina, amb la seva aprovació i el seu seguiment, dins d'un projecte corporatiu. S'hi decanta perquè:

• el procés és simple i basat en formulari i aprovació;
• no requereix lògica complexa ni integracions profundes;
• el pot construir i mantenir la mateixa àrea usuària, sense consumir capacitat de l'equip de desenvolupament;
• el temps de lliurament és de dies, no de mesos.

Casos d'ús habituals a una administració: sol·licituds i autoritzacions internes, inventaris i registres d'actius, reserves de sales i vehicles, recollida de dades de camp amb el mòbil (inspeccions, incidències a la via pública), enquestes i formularis de participació, quadres de seguiment d'un servei, i el seguiment intern de peticions que encara viu en una fulla de càlcul compartida. Una aplicació sectorial de tramitació —per exemple la gestió de llicències municipals— hi encaixa si el procediment no és reglat; si ho és, entra en joc el §7.

En canvi, es descarta el no-code quan hi ha requisits de rendiment exigents, lògica de negoci complexa, integracions no cobertes pels connectors, alta criticitat o volums grans.

Regla pràctica de decisió:

3. Plataformes

Power Platform és la més present a les administracions que ja tenen Microsoft 365 (→ tema 51): Power Apps (aplicacions), Power Automate (fluxos), Power Pages (portals), Dataverse (dades) i connectors a centenars de serveis.

Algunes d'aquestes plataformes tenen una modalitat específica per generar aplicacions mòbils natives o multiplataforma (Power Apps, OutSystems, Mendix, Appian); el detall del desenvolupament mòbil es tracta a desenvolupament d'aplicacions mòbils. I encara que el RPA comparteix l'enfocament visual amb poc codi, no construeix aplicació nova: automatitza un procés existent imitant una persona sobre la interfície; es tracta a automatització, orquestració i RPA. La distinció paral·lela amb el BPM és la mateixa vista des de l'altre costat: el BPM modela i orquestra el procés de punta a punta, mentre que el low-code construeix la interfície i l'aplicació que hi participen.

4. Integració amb sistemes existents: connectors i API

El que fa possible que una app low-code/no-code no visqui aïllada és que la plataforma exposa i consumeix serveis en comptes d'obligar a reescriure el que ja hi ha:

• Connectors predefinits: components ja fets per parlar amb un sistema concret (SharePoint, SQL (Structured Query Language) Server, SAP, Salesforce, un servei de correu) sense programar el protocol des de zero; és el cas normal per a integracions habituals. Les plataformes els solen classificar en estàndard i prèmium, i la diferència és de llicència, no de capacitat: els prèmium, els locals i els personalitzats exigeixen un pla de pagament, i per això el catàleg de connectors disponible depèn del que s'hagi contractat.
• Connectors personalitzats: quan no existeix el connector, se'n fa un embolcall d'una API pròpia —s'hi descriu la interfície i les operacions— i a partir d'aquí es fa servir com qualsevol altre. És la via per integrar l'aplicació sectorial de casa que cap fabricant no coneix.
• API (Application Programming Interface, interfície de programació d'aplicacions) REST d'entrada: la plataforma exposa els propis processos i dades com a servei perquè un altre sistema hi pugui trucar.
• API REST de sortida: quan no hi ha connector fet ni se'n vol fer un, un connector genèric HTTP (HyperText Transfer Protocol, protocol de transferència d'hipertext) sobre l'estil REST (REpresentational State Transfer, transferència d'estat representacional) permet trucar qualsevol API que el sistema existent ja publiqui.
• Webhooks: el sistema existent notifica un esdeveniment a la plataforma en temps real, sense que aquesta l'hagi d'anar consultant per sondeig (polling).
• Passarel·la de dades locals (on-premises data gateway): un servei que s'instal·la dins de la xarxa de l'organisme i que fa de pont entre la plataforma al núvol i les fonts internes (una base de dades, un servidor de fitxers). La connexió la inicia la passarel·la cap enfora, així que el sistema intern no s'ha de publicar a internet ni obrir cap port entrant. És la resposta al cas més freqüent a l'administració: l'aplicació és al núvol i les dades no en poden sortir.

Per què això importa especialment a una administració: el sistema ja existent —el padró, el gestor d'expedients, l'ERP (Enterprise Resource Planning, planificació de recursos empresarials) municipal— gairebé mai es pot tocar per adaptar-lo a l'eina nova. La característica d'aquestes plataformes que facilita la integració amb altres sistemes és, doncs, que disposen de connectors i interfícies d'aplicació (API) predefinits; no que calgui codificació manual avançada, ni que la integració sigui impossible, ni que s'hagi d'adaptar el programari existent a la plataforma nova.

El diagrama diu el que el tribunal explota: els tres camins directes exigeixen que el sistema existent sigui accessible, i el quart —la passarel·la— és el que serveix quan no ho és, que a l'administració és el cas normal.

5. Beneficis i riscos

Beneficis: rapidesa de lliurament, reducció del retard acumulat de peticions petites, acostament del negoci a la solució, prototipatge ràpid, menor cost per a aplicacions simples, i estandardització visual i d'accessibilitat si la plataforma ho aporta.

Riscos i límits:

1. Bloqueig de proveïdor (vendor lock-in): el més greu. L'aplicació no és portable: viu dins de la plataforma i sovint no hi ha manera d'exportar-la a codi. La decisió d'assumir aquest risc, o de pagar per evitar-lo, es pren al cas de negoci → tema 3.
2. Shadow IT (Information Technology): aplicacions crítiques construïdes fora del control de TI, sense còpies de seguretat, sense documentació i amb un únic responsable que un dia se'n va.
3. Seguretat i protecció de dades: connectors que treuen dades fora del perímetre, permisos mal configurats, tractaments sense base de licitud ni registre d'activitats.
4. Escalabilitat i rendiment limitats per la plataforma.
5. Cost per usuari i per llicència, que creix amb l'adopció i pot superar el d'un desenvolupament propi. El salt de preu sol arribar quan cal un connector prèmium o la passarel·la (§4).
6. Deute tècnic: no desapareix perquè no hi hagi codi; canvia de forma, i és més difícil de veure. La lògica viu dins d'un llenç visual que no es pot llegir en una revisió de codi ni cercar amb una eina de text; no hi ha proves automàtiques ni control de versions comparables als del desenvolupament tradicional; les mateixes regles es dupliquen d'una aplicació a una altra en comptes de compartir-se; i el coneixement de com funciona se'l queda qui la va fer. El resultat típic és un parc d'aplicacions òrfenes: funcionen, ningú sap com, i cap no es pot refactoritzar.
7. Deute d'integració: cada aplicació nova crea dependències no documentades cap a sistemes que no saben que algú els està consumint.
8. Manteniment i cicle de vida: canvis de versió de la plataforma —que decideix el fabricant, no l'organisme— que trenquen aplicacions ja en producció.

6. Governança

Perquè el low-code/no-code sumi i no fragmenti, cal un marc explícit:

• Catàleg d'entorns: separació de desenvolupament, proves i producció i, en el cas de Power Platform, entorns amb polítiques diferenciades.
• Polítiques de prevenció de pèrdua de dades (DLP, Data Loss Prevention) que restringeixin quins connectors es poden combinar (per exemple, prohibir combinar un connector corporatiu amb un de xarxes socials).
• Classificació d'aplicacions per criticitat: les crítiques passen a ser mantingudes per TI.
• Registre d'aplicacions ciutadanes amb propietari, dades tractades i base de licitud, integrat amb el registre d'activitats de tractament (RGPD, art. 30).
• Formació i comunitat de citizen developers, amb plantilles i components corporatius reutilitzables.
• Revisió de seguretat i d'accessibilitat abans del pas a producció.
• Estratègia de sortida: què es fa si es deixa la plataforma.
• Contractació: exigir reversibilitat, exportació de dades i de definicions, i condicions de sortida (LCSP i Mesura de digitalització oberta).

7. Al sector públic

• Encaix normatiu: qualsevol aplicació que tracti dades personals necessita base de licitud, registre i, si escau, AIPD (Avaluació d'Impacte de Protecció de Dades, RGPD, art. 35); si dicta actes, és actuació administrativa automatitzada (Llei 40/2015, art. 41) amb tot el que comporta —òrgan competent, control de qualitat, auditoria del codi font i òrgan responsable a efectes d'impugnació. Una plataforma que no permeti auditar la lògica és problemàtica en aquest supòsit.
• Accessibilitat: el resultat ha de complir el RD (Reial Decret) 1112/2018 i WCAG (Web Content Accessibility Guidelines) 2.1 AA; no totes les plantilles de les plataformes hi compleixen per defecte.
• Sobirania digital i programari lliure: la Mesura de digitalització oberta estableix la preferència pel programari lliure i els estàndards oberts. Una plataforma propietària de low-code hi entra en tensió: convé valorar les alternatives de codi obert (Budibase, Appsmith, ToolJet, n8n) i, en tot cas, assegurar la portabilitat de les dades.
• Reutilització (Llei 40/2015, art. 158): consultar el directori d'aplicacions abans de construir.
• Ús raonable: el low-code és excel·lent per als tràmits interns i els processos de suport; el nucli de tramitació administrativa, amb els seus requisits d'expedient electrònic, signatura, notificació i arxiu, sol requerir la plataforma corporativa (a Barcelona, el GPA, Gestió de Procediments Administratius) → tema 4.

Claus d'examen

• La integració amb sistemes existents la faciliten els connectors i l'API predefinits, no la codificació manual ni adaptar el sistema existent (TS-TIC 2025 específic, p. 44).
• Diferència real low-code/no-code: no-code no permet gens de codi; low-code sí que pot requerir-ne en casos avançats. No és una qüestió de perfil d'usuari exclusiu ni de límit a pàgines web senzilles (TS-TIC 2025 pràctica, s3 p. 3).
• Tràmit intern senzill sense escriure cap línia de codi = plataforma No-Code, no un framework tradicional (Spring Boot), ni un sistema de gestió de la qualitat del programari (SQMS, Software Quality Management System, tal com ho escriu l'examen), ni un repositori Git: dues d'aquestes tres ni tan sols construeixen aplicacions (TS-TIC 2025 pràctica, s3 p. 4).

Per recordar

• Low-code = perfils tècnics, amb possibilitat d'escriure codi; no-code = usuaris de negoci, exclusivament visual.
• Per a tràmits interns simples (formulari + aprovació) la resposta és no-code / low-code, no desenvolupament tradicional.
• El risc principal és el bloqueig de proveïdor: l'aplicació no és portable.
• El segon risc és el shadow IT: aplicacions crítiques fora del control de TI.
• La governança exigeix entorns separats, polítiques DLP de connectors, registre d'aplicacions, revisió de seguretat i accessibilitat, i estratègia de sortida.
• Si l'aplicació dicta actes administratius, és actuació automatitzada: cal poder auditar-ne la lògica i el codi font.
• Power Platform és la suite més present a les administracions amb Microsoft 365; alternatives lliures: Budibase, Appsmith, ToolJet, n8n.
• La integració amb sistemes existents es fa amb connectors predefinits i API REST (entrada i sortida) i webhooks; és el que permet integrar-se sense tocar el sistema existent, que a l'administració gairebé mai es pot adaptar.
• Quan el sistema intern no és accessible des d'internet, el mecanisme és la passarel·la de dades locals: la instal·la l'organisme i inicia ella la connexió cap enfora, sense obrir cap port entrant.
• El deute tècnic no desapareix per no haver-hi codi: la lògica viu en un llenç visual que no es revisa ni es busca com el codi, i acaba en un parc d'aplicacions òrfenes.
• RPA no és low-code: el RPA automatitza un procés que ja existeix imitant un usuari; el low-code construeix aplicació nova.