Er forretningsbrukere klare og i stand til å bygge sofistikerte applikasjoner ved hjelp av plattformer med lav kode og uten kode? Det er mye håp og hype knyttet til programvarebevegelsen med lav kode og uten kode, men det betyr ikke at utviklere vil legge på IDE-ene sine når som helst snart. Vi er ikke i nærheten av det punktet hvor forretningsbrukere faktisk kan bygge og distribuere relativt sofistikerte applikasjoner uten hjelp fra deres avdelinger for informasjonsteknologi.
Foto: Joe McKendrick
“Generelt sett er de fleste av de innbyggerutviklede applikasjonene vi ser i dag, fokusert på en prosess uten begrensninger,” sier David Beaudreau, VP for US Cloud Practice i Sogeti, en del av Capgemini. “Det er noen få tilfeller der borgerutviklere lager multifunksjonelle prosess- og arbeidsflytapplikasjoner, så vel som kompliserte business intelligence-dashboards, men dette er stort sett unntaket.”
Ikke alle i bransjen er enige om at sofistikerte applikasjoner er utenfor grenser for utviklere med lave og ikke-koder. Linda Ding, seniordirektør for vertikal markedsføringsstrategi i Laserfiche, sier hun har sett kunder “bygge veldig sofistikerte applikasjoner i løpet av Covid-19-pandemien.” En kombinasjon av knappe IT-ressurser og etterspørsel etter umiddelbare løsninger førte til etterspørsel etter en rekke applikasjoner, sier hun, inkludert “skjemaer og prosesser for å be om hotspots for studenter som trenger dem for fjernlæring, distribusjon av økonomisk støtte og formidling av lønnsslipp.” Dette er eksempler på applikasjoner som “alle krever relativt sofistikerte arbeidsflyter, logikk og integrasjoner, muliggjort gjennom verktøy uten koder uten kode i forretningsbrukernes hender.”
På en eller annen måte vil det alltid være en aktiv rolle for IT-avdelinger når det gjelder styring og støtte for en applikasjon. En forretningsbrukeres rolle er “bygg ja, distribuer nei,” sier Chris Ellis, teknisk direktør i Nintex. “Sofistikerte applikasjoner har sofistikerte problemer. Oftere enn ikke kan en applikasjon som er lett å bygge, bli hodepine lenger nede.”
Ellis oppfordrer til en “vetting-and-verification process or approval-of-solution-builds to deploy via IT” -tilnærming. “Organisasjonenes forretningsbrukere burde absolutt være en del av identifiseringen av forbedringer og en del av løsningen, men det er kortsiktig å se dem som de eneste forvalterne som driver et transformasjonskift med lav kode.”
Beaudreau føler at applikasjoner bygges utenfor IT-domenet, har en tendens til å være enklere, mer perifere. “Vi ser først og fremst bedrifter bygge enkeltfokuserte prosess- og arbeidsflytapplikasjoner som støtter manuelle prosesser som ofte faller utenfor IT-området på grunn av budsjettbegrensninger og/eller opplevd avkastning,” sier han. “IT-ekspertise er fremdeles viktig når det gjelder nye pakkede plattformer, høyt integrerte miljøer, eller når man ønsker å muliggjøre ny teknologi i organisasjonen. Det er fortsatt fortsatt nødvendig å implementere støttefunksjoner som integrasjon og moderne dataplattformer for å støtte innbyggerutviklere og deres opprettelse aktiviteter. ”
Samtidig åpner stadig mer sofistikerte utviklingsmetoder med lav kode/ingen kode nye veier for innovasjon. “Vi ser dette med borgerutviklere når vi veileder dem gjennom oppslukende hendelser som hackathons,” forteller Beaudreau. “Ettersom de forstår plattformer med lav kode, er de i stand til å tilpasse muligheten til vanlige problemer i det daglige arbeidslivet. Med førstepersonsperspektivet ser de ofte mer innovative og noen ganger forenklede løsninger enn hva som kan komme fra en IT perspektiv.”
Nylige hendelser har også presset konvolutten for innovasjon. Covid-krisen “akselererte adopsjonen av verktøy med lite kode og ikke-kode på grunn av situasjonens haster og direness – utfordringer utviklet seg daglig, til og med hver time, og organisasjoner måtte styrke forretningseksperter utenfor IT for å skape applikasjoner som skulle dekke drifts- og kundebehov, sier Ding. “Tradisjonelle måter å utvikle applikasjoner på kan ta flere måneder – for testing, feilsøking og distribusjon i et bedriftsmiljø. For å øke hastigheten på dagens virksomhet, endre kundeforventninger og uforutsigbarhet i markeder, er ikke tidslinjen lenger.”
Bedriftsbrukere – forretningsanalytikere og administratorer utenfor IT-avdelingen – “er godt kjent med sine egne prosesser og de som påvirker kundene deres,” legger hun til. “Når de får en plattform eller verktøyene de trenger for å løse problemene, er de i stand til å lage svært sofistikerte applikasjoner som ikke bare er back-end arbeidsflyter, men kundevendte løsninger som er veldig innovative.”
< p>Med tilnærminger med lav kode og uten kode, “er det mange muligheter for å forbedre klientopplevelsen som ikke ville eksistert hvis bedrifter bare stolte på IT for å utvikle applikasjoner,” sier Ding. “Lav-kode og ingen-kode gir problemløsningsverktøyene i hendene på forretningsbrukere, som kan takle kundeutfordringer, få rask leveringstid for distribusjon og gi enorm verdi for kundene.”
Lavkode- og ikke-kodetilnærminger gagner ikke bare ikke-tekniske forretningsbrukere. Profesjonelle utviklere vedtar også løsninger med lav kode/ingen kode av forskjellige årsaker. “Vi har sett en betydelig interesse for lavkodet/ingenkodetrening ettersom utviklere nå innser at disse plattformene ikke tilsvarer funksjonell begrensning,” sier Beaudreau. “Plattformene lar utvikleren fokusere på forretningsfunksjonell design i stedet for ikke-funksjonelle krav som plattformene ofte administrerer.”
Dette baner vei for virkelig å gjøre mer med mindre i dagens utviklingsbutikker. “Hvis du kan skalere arbeidsbelastningen din effektivt som en profesjonell utvikler for å levere full samsvar – enten det er med en løsning med lav kode/ingen kode, full tilpassing eller noe i mellom – bør et vellykket kunderesultat være nummer én prioritet, sier Ellis. “Å bruke den minste motstandsveien for å komme dit er å jobbe smartere og ikke vanskeligere. Bare fordi du kan utvikle noe, betyr ikke det.”
En robust kultur med lav kode eller uten kode med stadig mer sofistikerte applikasjoner gir nye sett med utfordringer. For det første er “styresett, eller mangel på det, assosiert med utbredelse noe alle som har vokst opp rundt SharePoint bør være kjent med,” sier Ellis. “Å la forretningsenheter bygge og distribuere det de vil, uten tilknytning, kan raskt bli andres administrative og lisensielle hodepine.”
En mindre åpenbar risiko, tilføyer Beaudreau, “er veksten i nødvendig applikasjonsstøtte som kan oppstå når borgerutviklere akselererer deres bruk av plattformene. Dette kan muligens overgå organisasjonens IT-støttekapasitet.” Duplisering er en annen risiko med lav-kode/ingen-kode. “Det er sannsynligvis fellestrekk i en virksomhet, og det bør gjøres en innsats for å unngå å doble den samme løsningen, bare i forskjellige forretningsenheter,” advarer Ellis.
Beslektede emner:
Cloud Big Data Analytics Innovation Tech and Work Collaboration Developer 