Het grootste obstakel voor een geoliede samenwerking tussen business en it is dat ze simpelweg niet dezelfde taal spreken. De traditionele watervalmethode voor applicatie-ontwikkeling benadrukt de verschillen eerder dan dat het ze oplost. De domeinexpert beschrijft wat het bedrijf nodig heeft bij het vaststellen van de vereisten.
De developers horen alle informatie door een filter van softwaretalen en it-architectuur te halen, omdat ze altijd al naar de volgende stap kijken, en krijgen dus maar een deel van wat de domeinexpert beschrijft binnen. Vervolgens is er radiostilte totdat de oplossing maanden of zelf jaren later wordt opgeleverd. Dit mist natuurlijk elk doel.
Het is misschien een open deur, maar veel software-ontwikkelaars hebben geen master bedrijfseconomie gevolgd. En de meeste bedrijfsconsultants weten maar weinig van coderen. Ze hebben een verschillende taal geleerd en gebruiken de woorden die ze nodig hebben om uit te blinken in hun vakgebied. Interessante kanttekening: een van de oprichters van Mendix, Roald Kuit, een genie op softwaregebied is weer terug de schoolbanken ingegaan om een MBA te behalen en zo het probleem van beide kanten aan te kunnen pakken.
Modelgestuurde ontwikkeling (modeldriven development, mdd) overbrugt deze ‘taalkloof’. Het model geeft iedereen een gemeenschappelijke taal. Door te werken met visuele bouwstenen kan de domeinexpert de developer precies laten zien wat het probleem of de zakelijke behoefte is op een manier dat de developer het begrijpt. De developer kan op zijn beurt de domeinexpert laten zien wat de mogelijkheden zijn en een nieuwe manier aandragen om het probleem op te lossen. Ze pingpongen over de beste aanpak en zijn het met elkaar eens voordat ze verder gaan met een volgende stap in het proces.
Het resultaat: veel minder fouten door miscommunicatie, het proces verloopt sneller en het eindproduct sluit aan bij de behoeften. De oplossing levert het gewenste bedrijfsresultaat, kortom: iedereen wint.
Wat maakt een model?
Modelgestuurde ontwikkeling biedt gebruikers een grafische of visuele interface. Het verschil wordt echter gemaakt met wat er zich onder deze interface bevindt. Het is overigens mogelijk om een visuele interface te hebben zonder low-code, maar low-code zonder interface bestaat niet.
Low-code maakt het model los van de code. In plaats van complexe talen met ingewikkelde syntaxis is er sprake van bouwstenen of ‘vooraf ontwikkelde applicatiecomponenten’. Elk met een domein-specifieke taal, die zorg dragen voor alle technische aspecten van een applicatie – de logica, het datamodel, de gebruikersinterface, beveiliging, integraties, et cetera. Deze componenten of ‘stukjes functionaliteit’ worden geabstraheerd en visueel aan de gebruikers gepresenteerd.
Deze bouwstenen zijn de gemeenschappelijke taal die iedereen in het team kan begrijpen: van domeinexpert tot hardcore-ontwikkelaar. Sterker nog, wanneer ze samen aan een oplossing werken, kunnen ze letterlijk zien waar ze het over hebben, de componenten rang- en herschikken, en – dankzij een extra dosis wonderdrank – de applicatie snel uitproberen.
De wonderdrank is automatisering, een ander fundamenteel onderdeel van modelgestuurde ontwikkeling. De processen onder die bovenste laag van visuele ontwikkeling met drag & drop zijn geautomatiseerd, denk hier aan alle configuratie, testing en question and answer (qa) en integraties. Dit ontlast de professionele ontwikkelaar van een aantal saaie taken en is de primaire reden waarom low-code zo’n boost voor de productiviteit in het development-proces is.
Zonder code!
Een vraag die zich waarschijnlijk opdringt is: hoe kun je een applicatie hebben zonder code? Sommige low-code platformen zijn afhankelijk van code. Vaak van veel code, honderd procent code. Daarmee komen alle traditionele valkuilen, matige kwaliteit en operationele valkuilen van typische code-full applicaties.
In echte modelgestuurde low-code applicaties is het model zelf uitvoerbaar in runtime. Er is dus geen code nodig. Zonder code te hoeven schrijven of aan te hoeven passen bij problemen, is het ontwikkelproces exponentieel sneller en is de kwaliteit van de voltooide applicatie hoger. Mocht een bepaalde functie nog niet beschikbaar zijn in de vooraf gebouwde componenten, dan kan een professionele developer code schrijven om zijn eigen component te bouwen die vervolgens onderdeel wordt van het model. Ook kan deze via de community beschikbaar worden gesteld aan andere ontwikkelaars.
Verwezenlijking van bizdevops
Modelgestuurde low-code brengt het idee van bizdevops tot leven. Domeinexperts worden een integraal onderdeel van het ontwikkelproces door de intuïtieve, eenvoudig te begrijpen hulpmiddelen voor visuele modellering. Domeinexperts kunnen zelfs eigenhandig applicaties bouwen.
De developers krijgen een grote boost op het gebied van snelheid en productiviteit dankzij het visuele model. Bovendien worden ze door slimme automatisering verlost van de alledaagse repetitieve taken, die de productiviteit en de moraal niet ten goede komen. Ook wordt er geen tijd verspild aan het maken van een keuze voor de taal, datastructuren, logic flows of architectuur – het model maakt de juiste keuzes voor hen. Vanuit een ops-perspectief is alles simpelweg beter en eenvoudiger dankzij de geautomatiseerde processen, kwaliteitscontroles en de ingebouwde deploy-knop.
Uitdaging
Technologische ontwikkelingen volgen elkaar vliegensvlug op. Er zijn continue nieuwe mogelijkheden, denk bijvoorbeeld aan iot, ai, ar, blockchain, edge en ambient computing. De uitdaging voor software is adoptie en integratie met deze nieuwe technologieën. Omdat het open en eindeloos uit te breiden is, is een low-code platform ideaal voor innovatie. Low-code wordt namelijk niet alleen gebruikt voor het ontwikkelen van individuele apps. Het core model is zo abstract dat in theorie alles gemodelleerd kan worden. Modelgestuurde low-code is hulpmiddel bij het ontwikkelen, aanpassen en verbeteren van volledige it-landschappen. Door voor een model te kiezen en niet langer low-level code te gebruiken, kan iedereen in het team – zowel domeinexperts als techneuten – zich concentreren op belangrijke oplossingen en concepten.
Automatisering verlicht de last van alledaagse en repetitieve taken en vermindert menselijke fouten, hierdoor verbetert de kwaliteit en is er sprake van een hogere productiviteit. Een open platform zorgt voor connectiviteit met alles en overal: van legacy-systemen tot nieuwe technologieën. Het resultaat is krachtigere applicaties, die sneller gebouwd kunnen worden in vergelijking met traditionele code-platformen.
“In echte modelgestuurde low-code applicaties is het model zelf uitvoerbaar in runtime. Er is dus geen code nodig”
Stel je eens voor als je geen code draait in een serverless environment. Nu nog iets om het management weg te rationaliseren ..
de nieuwe code van de keizer 🙂
Business en IT moeten de zelfde taal spreken, en vervolgens komt er een ongelofelijke bak gewauwel over low-code en modelgestuurd ontwikkelen. Wanneer leren IT-ers nu eens dat de taal van de business financieel is, vastgelegd in een business case. Hoe draagt een stuk automatisering gericht op informatieverwerking (want dat is meestal wat we doen) bij aan de top line of de bottom line van het bedrijf? Daar heb je geen master bedrijfseconomie voor nodig, gewoon een beetje interesse in hoe een bedrijf z’n geld verdient, welke processen daarbij een rol spelen en hoe het applicatie-landschap daar een rol in speelt.
Veel organisaties zijn internationaal en multicultureel. Hoe zit het met de “taal”? In hoeverre zijn medewerkers cultureel competent en kunnen ze intercultureel communiceren en begrijpen ze het high context Engels van veel (bijvoorbeeld Indiase) medewerkers?
@Bert van Hijfte | 25 mei 2020 13:56
Het lijkt mij meer evident dat medewerkers moeite doen om de taal & cultuur van de organisatie te doorgronden.
Wat is code? Veel software-ontwikkelaars zullen denken aan een programma geschreven in Java, C#, Python, Javascript, Haskell, XSLT. … Maar dit zijn allemaal abstracties van de onderliggende code (JVM bytecode, assember, bits). In die zin is een model ook code; het codificeert processen, gegevens en relaties binnen een organisatie. Het model bevindt zich op een hoger abstractieniveau dan de meeste programmeertaalcode, maar moet even goed interpreteerbaar en ondubbelzinnig zijn. En als het model executeerbaar is, is er op een of andere manier een vertaling van model naar code in een programmeertaal.
Er zijn naar mijn idee twee trends zichtbaar: Aan de ene kant is er een toename van ‘accidental complexity’, wat leidt tot programmacode die niet inherent is aan de functionaliteit. Software ontwikkelaars zijn steeds meer tijd kwijt aan het configureren van tools, CICD pipelines en dergelijke, terwijl die ooit bedoeld waren om tijd te besparen.
Aan de andere kant is er een beweging naar meer abstractie van de onderliggende hardware en software, waarvan “low-code” een voorbeeld is. In dit verband is het interessant om een verwijzing te maken naar declaratief programmeren en de https://declarative.amsterdam/ conferentie. (Het artikel had al een redelijk advertorial gehalte, dus dit mag dan ook wel.)
Poeh.
De titel sprak mij aan maar de uitwerken en de ‘voorbeelden’ hangen in dezelfde sfeer als altijd (applicaties bouwen). Business en IT ‘moeten’ inderdaad dezelfde taal spreken. Dit betekent (lijkt mij) dat je uitgaat van WAT de business communiceert, waarover praten zij (NLP). Letterlijk de taal in de vorm van woorden, beelden, vormen in een bepaalde context. Met twee woorden spreken zegt veel over content – context : datamodel – waarden. Financiën bv heeft net als HR en Juridisch zaken of Sales en Marketing {zelfstandige naamwoorden} de context c.q. betekenis bedrijfsfunctie, daaronder ‘hangen’ bedrijfsproducten (en -diensten). Bv weke producten en diensten biedt Financiën? We kennen (allemaal) woorden als administratie, bank, belasting e.d. Belastingen bv kent vier ‘kapstokken’. In de taal van de organisatie zijn dat omzet-, loon-, dividend- en vennootschapsbelasting. Hiermee spreken van de taal van de organisatie die een op een en dus eenduidig in de systemen (moeten) terugkomen. Aangestuurd door de boaordroom waarbij de verantwoordelijk CFO over (in dit voorbeeld van belastingen) vier dashboards heeft.
Daarnaast spreken we (over andere {architectuur} modellen) vanuit de business zoals de bedrijfsprocessen en de taken waar een functionaris “Jan de Belastingman” (in de organisatie) verantwoordelijk voor is. Hij volgt (en controleert {proces werkwoorden!} in dit geval 100%) de processen die gevolgd en uitgevoerd moeten worden.
Deze modellen; Bedrijfsfunctiemodel, bedrijfsproductenmodel, bedrijfsprocesmodel en bedrijfsinformatiemodel zijn letterlijk de (taal) bronnen en dus de voeding (Governance) voor de drop down en pick listen in de systemen. In dat geval spreek je (pas echt) over de taal van de business die je terugziet in applicaties en die ondersteunend zijn aan de werkende mens in zijn functie (verantwoordelijkheden en bevoegdheden) Welke laatste ook weer heel simpel de (HRM en AD) lijstjes met namen zijn die gebruikt worden als bron c.q. basis van alle gegevens (data) in ALLE applicaties.
Met andere woorden als we over taal spreken stel ik voor wel duidelijk de context erbij te benoemen en ……… altijd te redeneren vanuit de business en dus de communicatie tussen zelfstandig werkende mensen (hun klanten) en v.v. hun systemen.