Low Code: facilitant la transformació digital

Els conceptes Low Code i No Code i les solucions que els suporten tornen a estar de moda. Els reptes que el procés de transformació digital està plantejant a les organitzacions en termes de velocitat de resposta, reducció de cost i adaptabilitat fan que totes les bondats que ofereixen aquestes plataformes siguin molt atractives i necessàries, sempre que abordem adequadament la seva implantació.

En aquest article revisarem les experiències del passat, quines lliçons vam obtenir i com aplicar-les per a fer que la nostra Low Code Application Platform una història d'èxit.

En aquest article parlarem de:

1. ¿Què és Low Code?
   1. El Low Code no és nou…
   2. … però ara ha trobat el seu lloc al món
2. Avantatges i riscos de la filosofia Low Code
3. Com afrontar la incorporació del Low Code
   1. Introduir la filosofia Low Code en una organització
   2. Molt bé, i ara com abordo un desenvolupament al meu LCAP?
4. Claus per a l’èxit: El nostre enfocament
   1. Low Code com estratègia
   2. Expectatives realistes del client
   3. Low Code no és Low Architecture
5. Conclusions

La filosofia Low Code i el seu extrem No Code sorgeixen de traslladar els principis de fabricació industrial  a l'última gran artesania que és de desenvolupament d'aplicacions.

En aquesta línia, les solucions que suporten aquesta filosofia busquen dotar a l'usuari de:

• Blocs de construccions (OoTB) estàndard que s'adaptin a les necessitats concretes de cada usuari via parametrització i combinació, fàcilment replicables i mantenibles.
• Eines de construcció fàcils de fer servir, molt visuals, que no requereixen d’especialització en IT, i que fins i tot no necessiten coneixements previs de programació (No Code).
• Eines per a l'explotació i monitoratge de les aplicacions construïdes: Gestió global dels diferents entorns (1-clic staging) ,Objectes OoTB per al monitoratge del consum de recursos, ús de fluxos, etc.
• Eines per a l'extensió del OoTB i la integració amb la resta de la plataforma via exposició/consum de serveis. En aquest àrea es concentren els requeriments d'especialització en IT.

Així doncs, la filosofia Low Code podem veure-la com la via per a evolucionar la indústria del desenvolupament IT cap a la maduresa productiva que podem trobar en els sectors d'automoció, naval…

La cerca de l'automatització i reutilització a nivell industrial en IT no és una cosa nova: les plataformes RAD de finals dels 80, els llenguatges i plataformes 4GL dels 90, les plataformes tipus lotus Notis o els CRM de principis d'aquest segle en són exemples clars. Totes aquestes solucions prometien:

• Reducció dràstica del temps de desenvolupament amb un estalvi d'ordres de magnitud respecte al desenvolupament a mesura.
• Disminució de la inversió en IT tant com a conseqüència per la reducció dels temps de desenvolupament, com per evitar la implicació de perfils especialitzats i cars, a més d'una reducció dels costos d'operació i manteniment
• Qualsevol pot construir aplicacions, sense necessitat de coneixements de programació. L'usuari final és el que coneix el negoci i el plasma directament sobre l'aplicació sense intermediaris.

Però la realitat és tossuda, i van aparèixer greus problemes:

• L'ecosistema d'aplicacions sofria d'un fort acoblament a la plataforma, a més d'uns costos alts d'integració per on s'escapolien totes les reduccions de costos promeses.
• L'efecte BlackBox generava la pèrdua de la traçabilitat de les solucions així com introduïa problemes de seguretat
• No es contemplava cap mena de filosofia de lock in, així que canviar-les implicava costosos projectes de migració.
• La falta de personalització i el concepte de tot és possible provocava l'explosió de “Wild Custom Code” que normalment contenia tota la lògica de negoci, sense documentar i amb greus problemes de compatibilitat amb l'evolució de la plataforma que feia que tot el sistema es quedés ancorat en una versió concreta aviat obsoleta.

Així doncs, es van generar greus dubtes sobre una bona idea. En els departaments IT es va posar en dubte la viabilitat de la seva utilització en aplicacions de missió crítica i va generar desconfiança en els CIOs pels perills d’apalancament tecnològic i financer. Els problemes d'integració i males pràctiques de desenvolupament comprometien quan no anul·laven els estalvis en inversió.

Així doncs, les solucions Low Code / No Code van iniciar la seva travessia del desert…

En l'última dècada, amb l'explosió de la transformació digital, la situació del mercat ha canviat dràsticament. Els cicles de vida de les aplicacions s'han escurçat significativament amb el que els temps per a obtenir un ROI acceptable són molt menors. Apareixen grans oportunitats i necessitats de negoci a les quals cal donar una resposta ràpida però efímera basada en aplicacions oportunistes difícilment abordables des d'un enfocament tradicional. Les unitats de negoci estan íntimament implicades en tota la fase de concepció i desenvolupament, estenent-se la pràctica de la utilització de prototips que provin la bondat de les idees en situacions reals per a la seva ràpida evolució o rebutjat.

D'altra banda, les plataformes Low Code han sortit de la seva travessia enfortides amb un canvi d'enfocament, que en funció del fabricador, cerca resoldre els problemes de les seves antecessores: disminució del perill d'acoblament, obertura a la comunitat, èmfasi en el no Lock-in, evolució de les capacitats d'integració, etc.

Així doncs, l'opció Low Code / No Code torna a estar damunt de la taula amb força, però per a no tornar a caure en els mateixos errors cal abordar-les amb un enfocament diferent.

Tal com hem vist en l'anterior capítol, les solucions basades en la filosofia Low Code tenen grans avantatges, de les quals destaquem:

• Significativa reducció dels temps de desenvolupament i posada en producció, arribant fins i tot a estalvis d'ordres de magnitud.
• Major implicació de l'usuari en tot el procés de definició i construcció, aconseguint afinar i ajustar millor el resultat a les necessitats del negoci.
• La definició visual dels fluxos en la pròpia plataforma permet l’“autodocumentació”, evitant els costosos i moltes vegades heroics processos d'enginyeria inversa per a saber què fa un mòdul, llibreria o aplicació.
• Reducció dels costos de desenvolupament en requerir-se equips més petits.

Una resposta ràpida, enfocada en les necessitats de negoci on des del minut u tots els actors de l'organització estiguin implicats, és possible i facilitada per les solucions Low Code, sempre que controlem els riscos que les van fer sotsobrar en el passat, destacant:

• La facilitat d'ús i extensibilitat proporciona la falsa sensació de “navalla suïssa”: L'orientació de “solució per a tot” dona lloc a un excés de personalització, un mal disseny i un trencament d'esquemes que suposa la conjunció del pitjor dels dos mons: Un codi difícilment mantenible, mal documentat i on s'ha traslladat la lògica de negoci que fa que ens apalanquem no ja una plataforma concreta, sinó en una versió obsoleta d'aquesta.
• La confusió entre disminució dràstica en els requeriments de desenvolupament amb pontejar la supervisió de IT genera el desenvolupament d’integracions sense control i sense govern, que no sols comprometen l'estabilitat de tota l'arquitectura, sinó la seva evolució futura. Apareix el temut lock-in.

La maximització dels primers i minimització dels segons passa per un procés controlat d'introducció global de la filosofia Low Code en l'organització així com d'una metodologia eficaç i eficient en el desenvolupament de projectes sobre la plataforma implantada.

L'adopció de la filosofia Low Code implica un canvi de la manera de pensar les possibles solucions IT als problemes de negoci. Estem davant un projecte estratègic en el qual el seu èxit depèn, en bona part, d'un correcte procés d'implantació que estructurarem en quatre fases:

• Fase 1: Estudi arquitectònic / Negoci
• Fase 2: Sol·licitar informació a diferents fabricants (*RFI)
• Fase 3: Prova de concepte  (POC)
• Fase 4: Pla de desplegament

FASE 1: ESTUDI ARQUITECTÒNIC / NEGOCI

En aquest primer estadi farem una anàlisi des de diferents perspectives de com dur a terme la implantació de la futura LCAP i si realment és útil a la nostra organització

• Vector OPS: Els responsables d'arquitectura identificaran les necessitats d'adaptació en la plataforma actual per a poder encaixar la nova LCAP. Així mateix, definirem els requeriments tecnològics de desplegament, operació i integració a satisfer per la LCAP.
• Vector IT: Els responsables de IT identificaran les necessitats de desenvolupament i manteniment que es generen amb la implantació de la LCAP en la seva globalitat: cost de llicències, desenvolupaments d'interfícies, processos d'enginyeria inversa, migracions, etc.
• Vector Negoci: Conjuntament amb IT, identifiquem aquelles àrees de negoci que per les seves necessitats o implicacions són candidates perquè la nova LCAP. Una actualització global dels processos de back office suportats per una tecnologia obsoleta i amortitzada són el tipus de situacions en què l'opció Low Code pot ser més que encertada.

La primera i fonamental decisió que hem de prendre és go/no go en funció a la relació cost/benefici definida en el treball dels tres vectors. En cas de seguir endavant, amb aquest estudi tenim el context on la nostra nova LCAP serà útil i identificats els requeriments tecnològics de la LCAP i del nostre ecosistema actual.

FASE 2: SOL·LICITAR INFORMACIÓ A DIFERENTS FABRICANTS (RFI)

Encara que es tracti d'una fase opcional, si que és recomanable bé directament, bé a través de proveïdors de confiança, demanar a diferents fabricants preseleccionats en la fase 1 informació addicional sobre els principals requeriments arquitecturals, de desenvolupament i de negoci que complementin la recollida de requeriments realitzada a l'estudi.

Com a resultat d'aquesta RFI recomanem seleccionar dues o tres candidatures per a la fase 3.

FASE 3: PROVA DE CONCEPTE (POC)

Un axioma en IT que tots coneixem bé és que “el paper ho aguanta tot”. La Fase 3 és, doncs, fonamental per a comprovar que tot el que s’ha analitzat en les dues fases anteriors s'ajusti amb la realitat, sabent que “la veritat sofreix quan s’examina”.

Per a ser realment útil, aquesta POC deu:

• Basar-se en cas d'ús realista, si pot ser un procés real de negoci dels seleccionats per a ser suportats per la LCAP
• Amb un nombre raonable d'interaccions amb la resta de components de l'arquitectura de l'organització (CRM, ERP, bus d'esdeveniments, etc.)
• Limitada en el temps per a comprovar realment les bondats de la LCAP i disposar d'informació en un termini adequat
• Limitada en cost, perquè no deixa de ser una prova i no una implantació real, a la qual ens intentarem acostar en la mesura del possible

Les diferents plataformes preseleccionades les estudiarem en diverses dimensions, avaluant diversos aspectes de la LCAP:

• Desenvolupament: Analitzarem el cost, temps i equip necessari respecte a un desenvolupament a mida, perfils implicats, requeriments i facilitats per a la migració, bondat de les eines de suport al desenvolupament, o l'adaptació a diferents metodologies (Waterfall, Agile)
• Arquitectural: Seguint els requeriments identificats en fases anteriors, estudiarem aspectes com la integrabilitat, proves d'estrès, entorns de desplegament (cloud, on premise, hybrid), lock in i acoblament, i els aspectes de DevOps definits.
• Fabricant: Avaluarem aspectes com la política de llicenciament, el suport tècnic prestat o la política de versionat (majors releases, minor releases, patches, política d'actualització, etc).
• Funcional: Revisarem característiques com la cobertura de l’OoB respecte a les necessitats de negoci, l'adaptabilitat i extensibilitat de la plataforma o la capacitat de personalització.

Com a resultat d'aquesta prova tindrem seleccionat el fabricant que proveirà la nostra nova LCAP concorde als nostres requisits i necessitats.

FASE 4: PLA DE DESPLEGAMENT

En aquesta fase definirem com implantarem la nostra nova LCAP. Per a assegurar el seu èxit, en la seva construcció ha d'estar implicada tota l'organització des del primer moment, liderats per IT.

Aquest pla ha d'incloure, com a mínim, els següents elements:
Roadmap de migració de l'àrea de negoci seleccionada, amb un especial èmfasi en la gestió de les expectatives del client, per la qual cosa l’involucrarem en tot el procés.

• Roadmap de totes les adaptacions, evolucions i canvis que dins de l'arquitectura per a encaixar la nova LCAP
• Guia de governança de la LCAP, on es defineixi clarament com utilitzarem la LCAP per a la implementació de les noves solucions. En aquest context apareix dins de l'organització una nova figura, l'Arquitecte de Solucions LC. Entre les seves responsabilitats trobem:
  • Vetllar pel compliment dels criteris  de bona governança.
  • Seleccionar i validar que les aplicacions realment són candidates a ser suportades per la LCAP.
• Anàlisi de cost/benefici que permeti fer realitat aquest projecte.

Els projectes candidats a desenvolupar sobre nostra nova LCAP solen tenir una o diverses de les següents característiques:

• Alta indefinició dels requeriments
• Curt temps de sortida al mercat
• Alta implicació d'usuari
• Necessitats de negoci canviants

La metodologia Agile és la que millor va per a encarar aquests projectes. La naturalesa iterativa d'aquests, la integració d'usuari i la gestió exigent de les seves expectatives fan que aplicar una estratègia waterfall sigui el preludi d'un fracàs.

D'altra banda, l'equip que implementarà la nova solució varia no tant en composició a un desenvolupament a mida, sinó al seu nivell de participació. En concret:

• La implicació de UX/UI és fonamental, i és convenient tenir-ho present durant tot el projecte. Assegurar els criteris d'usabilitat, la definició de l’user journey i comptar dins de l'equip amb persones que parlin el mateix idioma que els usuaris assegura l'èxit del projecte.
• La figura del Business Analyst és clau en la implementació. És l'encarregat del correcte mapatge de les User Stories dins de OoTB, així com de detectar les necessitats de “custom development”, alineat amb les directrius marcades en la guia de governança.
• La figura de l'Arquitecte és complementària a la del Business Analyst i igualment clau, perquè és el que revisarà i definirà totes les necessitats de connectivitat i extensibilitat que la nova aplicació exigeix de la LCAP
• Els equips de desenvolupament són més reduïts, sent les seves tasques fonamentals:
  • Implementació del custom code definit
  • Implementació o adaptació de les API i connectors necessaris per a consumir recursos de l'ecosistema.

Des d’Opentrends estem convençuts que l'èxit de la incorporació de la filosofia Low Code descrita anteriorment està suportat en tres grans pilars o paradigmes:

• Low Code és una decisió estratègica
• Gestió de les expectatives del client i unitats de negoci
• Low Code no és Low Architecture

L'èxit de l'adopció d'una Low Code Application Platform (LCAP) requereix que sigui considerada una decisió estratègica dins de la companyia. Considerar la implantació d'una LCAP com una tàctica per a resoldre un problema o urgència aïllada o una simple reducció de cost és una condemna al fracàs.

La implantació d'una LCAP s'ha d'abordar d'una forma global ja que:

• Les LCAP tenen uns costos de sortida importants en forma de llicències, corba d'aprenentatge, formació i comunicació interna que requereixen de temps per a obtenir el ROI desitjat. És fonamental definir l'àrea objectiu de negoci on aplicar-la atenent volum i nombre d'aplicacions, recursos implicats...
• Implica un canvi en la manera d'afrontar com donar el suport tecnològic necessari als requeriments del mercat. El balanç d'implicació dels diferents actors es desplaça des de desenvolupament a negoci i arquitectura.
• Requereixen mobilitzar recursos en els àmbits de IT i àrees de negoci.
• Requereixen crear noves figures i pràctiques dins dels departaments de IT i negoci
• La formació de tots els actors implicats en el coneixement de les capacitats de la plataforma és fonamental per a aprofitar tota la seva potència, maximitzar beneficis i minimitzar riscos.

Tota l'organització està implicada del canvi i ha de ser partícip d'ell. Aprofitar la rapidesa de resposta a les necessitats de negoci i la reducció significativa de costos que brinden les LCAP passa per involucrar i il·lusionar d'una forma realista a tots els futurs usuaris pel que no pot ser vist com una decisió merament tàctica de IT.

Un dels missatges més potents i més repetits quan parlem sobre  “què és Low Code” és que aquestes plataformes ens permeten construir aplicacions sense tenir coneixements de programació (No Code) o molt bàsics (Low Code). La conseqüència directa és generar en els usuaris la síndrome del “bàlsam de fierabràs”: les LCAP són la panacea que permet solucionar tots els problemes per mi mateix, sense comptar amb cap mena de supervisió per part de IT. No tenir en compte aquest fenomen i mitigar-lo des d'un bon començament és tenir el fracàs servit.

Gestionar les expectatives del client final sobre què pot fer realment a la plataforma, que és molt, és vital. Són fonamentals les accions de comunicació interna que conscienciïn l'usuari de negoci de que té una eina molt flexible, que realment té requeriments de desenvolupament molt menors i li permeten abordar amb eficiència i eficàcia les necessitats que es presenten a tota velocitat, sempre que siguem molt estrictes en l'observança d'uns criteris de bona governança i en els criteris de selecció de quines solucions són candidates a ser suportades sobre la LCAP. En la resolució de totes aquestes necessitats la participació de IT és crítica per a l'èxit.

Un error clàssic és considerar la Low Code Application Platform com un ens autònom, una caixa negra aïllada de la resta de solucions que componen l'ecosistema IT de l'organització. El nostre enfocament considera la LCAP com un element més dins de la infraestructura IT, que ha de seguir els paradigmes arquitectònics definits i ha de respondre als següents criteris:

• Acoblament feble: La LCAP no pot convertir-se en un punt d’apalancament tecnològic que generi una pèrdua d'agilitat en la resposta a requeriments, així com condicionar l'evolució d'aquesta.
• Lock - in: La LCAP ha d'incorporar mecanismes i/o estratègies que permetin no sols prescindir d'ella en un futur, sinó incorporar un suport eficaç i eficient a la gestió d'incidències de la plataforma o de la política d'actualitzacions.
• Integració: La LCAP ha de ser capaç de consumir i exposar serveis a la resta dels components de l'arquitectura seguint els estàndards definits (API REST / SOAP, webhook...)
• Personalització: La imatge de marca que transmetem al mercat és avui dia crucial per a qualsevol organització. La LCAP ha de donar respostes a totes les exigències en UX/UI contemplades en seccions anteriors: Pixel Perfect, reutilització de patrons, generació de nous patrons de disseny, etc.
• DevOps (CI/CD): La LCAP ha de complir els requeriments d'operacions sota l'estratègia CI/CD com a integració amb eines com Jenkins, compatibilitat amb el desplegament en contenidors, suportar estratègies Cloud, On premise i Híbrides, monitoratge de l'ús i de consum de recursos.
• Seguretat: La LCAP ha d'integrar-se amb sistemes SSO, d'autenticació i autenticació, així com proveir mecanismes de gestió de Rols.
• Traçabilitat: La LCAP ha de proporcionar mecanismes que minimitzin l'efecte Black Box. Ha de permetre recollir i explotar informació sobre l'ús dels fluxos creats, objectes, recursos consumits, etc.

L'èxit d'una iniciativa Low Code només és possible amb un bon pilotatge des de IT i el seu encaix suau dins de l'arquitectura tecnològica.

La filosofia Low Code ha arribat a la maduresa. És una bona estratègia per a abordar les necessitats actuals i futures del mercat, facilita la transmissió de coneixement i la democratització de la generació de solucions dins de l'organització, acostant els departaments de IT i negoci, que deixen de ser uns desconeguts.

No repetir els errors del passat passa per abordar la LCAP com una estratègia global i no com a resposta a un problema aïllat. La gestió de les expectatives de l'usuari, la implicació de IT en la seva correcta governança per a no desbordar els seus límits asseguren poder aprofitar tota la potència d'unes solucions que permeten a les organitzacions afrontar reptes de la canviant realitat de l'huracà de la transformació digital.

Definitivament, la filosofia Low Code ha tornat per a quedar-se.