Skip to content

ontwikkelingen

skin27 edited this page Apr 9, 2021 · 25 revisions

Van modulaire software naar het modulaire bedrijf

Net als een huis bestaat uit individuele bakstenen, bestaan programma’s uit stukjes code. Deze code wordt meestal gebundeld in modules. Programmeurs zijn het dan ook gewend om modulair te werken. Maar al die ‘bakstenen’ moeten wel bij elkaar gehouden worden. Zonder cement zou een huis immers onbewoonbaar zijn. Programmeurs spreken over het compileren van code. Wanneer een programma eenmaal gecompileerd is, is het cement hard. Gelukkig is gecompileerde software vaak flexibeler dan gehard cement. Denk bijvoorbeeld aan muziek. Wanneer je een opname opslaat in een digitaal bestand, kan het eindeloos gekopieerd worden. Probeer dat maar eens met een huis!

De limieten van code

Digitaal kopiëren is makkelijk. Meestal willen we echter geen exacte kopie, maar bepaalde elementen in een applicatie veranderen. Dat gaat normaliter als volgt: de gebruiker vermeldt de nieuwe vereisten bij de programmeur als concrete issues. Vervolgens gaat de programmeur aan de slag om het programma aan te passen, de code wederom te compileren en te delen met de gebruiker.

De programmeur kan de gebruiker meer invloed geven door opties of configuratiebestanden in te bouwen. Dit maakt de software flexibeler. Toch is deze aanpak nog steeds niet flexibel genoeg om adequaat te kunnen reageren op de snel veranderende omstandigheden in de markt. Bedrijven beschikken dus niet over dezelfde modulariteit als software programmeurs. Er blijft een gat tussen IT en de business.

Low-code als oplossing?

Low-code is een van de manieren om deze gapende afstand toch te overbruggen. In plaats van een programmeertaal gebruikt low-code visuele bouwblokken en modelleringstools om bepaalde functionaliteiten te creëren. Nadeel is dat het niet gemakkelijk is om een low-code platform te bouwen. Voor elk onderdeel van een programma – zoals de gebruikersinterface, datamodellen of business logic – zijn andere vormen van visualisatie nodig.

Op dit vlak is code toch universeler, aangezien alles wordt gepresenteerd als tekst. Er wordt al jaren getracht om low-code-platforms te creëren, maar dit leidde vooralsnog tot inflexibele en non-portable programma’s. Recent hebben Mendix, Outsystems, Betty Blocks en Progress Kinvey wél vooruitgang weten te boeken met low-code. Het is natuurlijk nog steeds niet zo open en uitgebreid als de meeste programmeertalen, maar er kunnen volwaardige applicaties mee worden gebouwd. De functionaliteiten van low-code-platforms groeien. Dat is ook wel nodig om flexibele programma’s te maken.

De keerzijde is dat low-code-programma’s steeds lastiger worden om te bouwen. Er verschijnen steeds vaker low-code-platformspecialisten om alles in goede banen te leiden. Dat ondermijnt de vrijheid en toegankelijkheid van low-code. Low-code is onderdeel van de oplossing, doordat het programmeren dichter bij de bedrijfspraktijk brengt. Maar het is niet de oplossing voor het centrale probleem van applicatiebouw: programma’s zijn alleen modulair tijdens het bouwproces en niet wanneer ze in gebruik zijn.

Runtime delivery

Het boek startte met het feit dat mensen een stuk flexibeler zijn dan systemen. Denk maar aan de volgende type video's:

IMAGE ALT TEXT

Er staan geen verkeersborden of verkeerslichten, iedereen rijdt gewoon langs elkaar heen. En dit gaat meestal op magische wijze goed. Nou ja, bijna dan. Er bestaan evenveel filmpjes op YouTube waarbij het dan ook net fout gaat. Het punt is natuurlijk dat we stiekem toch ook op magische wijze data tussen applicaties willen laten stromen.

In het dierenrijk zijn ze wat dit betreft al verder. Bijen vliegen in zwermen door elkaar heen zonder elkaar ooit te raken. Met behulp van bionics proberen ingenieurs nu drones precies zo te laten vliegen en zelfs samen te laten werken. In de logistieke sector zijn er experimenten die voertuigen, zoals auto's en vrachtwagen, met elkaar laten communiceren, waardoor het video van een Indiaas kruispunt ook in andere landen een alledaags verschijnsel zou kunnen worden. En dan zonder ongelukken natuurlijk.

Eigenlijk wil je een directe en intuitieve manier om met de digitale wereld om te gaan. Een veel directere aanpak die ik runtime delivery noem. Bij runtime delivery heeft een bedrijf directe online toegang tot de bouwblokken voor programma’s. Het is met andere woorden geen low-code-platform om nieuwe applicaties in het leven te roepen, maar een ‘high-code’-dienst om een bedrijf mee op te bouwen. De individuele bouwblokken vervullen slechts één enkele taak (separation of concerns) binnen een specifiek domein, compleet onafhankelijk van andere bouwblokken. Deze verschillende bouwblokken doen hun werk binnen de cloud. Dat zorgt voor een gestroomlijnde dienstverlening, die overal toegankelijk is. Dankzij runtime-delivery-bouwblokken kunnen bedrijfsontwikkelaars die nu nog afhankelijk zijn van Excel of low-code-platforms functionaliteiten toevoegen op bedrijfsniveau.

Runtime delivery klinkt wellicht als een mooie toekomstdroom, maar het is nu al realiteit. Een goed voorbeeld van is een business rules engine (BRE) die totaal onafhankelijk van andere software functioneert. De BRE maakt gebruik van ‘Als … dan … anders’-constructies. Zo simpel dat een bedrijf ze gemakkelijk zelf aan kan passen.

Integrated data

Hoe zit dit nu met data integratie? Ook hier zijn trends en experimenten die applicaties sneller en makkelijker met elkaar kan integreren. Naast low-code voor integratie zijn dit bijvoorbeeld containers, (hybdrid) cloud, streaming en datahubs.

Containers als legoblokken

Een analogie die al langer in software wordt gebruikt is lego. Het laat je met eenvoudige bouwstenen complexe constructies bouwen. Uiteraard beginnend met instructies, maar ten slotte kunnen creatieve gebruikers allerlei constructies zelf bedenken en bouwen. Het mooie van lego is dat in tegenstelling tot bakstenen, de legostenen weer uit elkaar kan halen en telkens iets nieuws van kan bouwen.

Aan lego blokken zit ook een andere kant. Immers een beperkte set bouwblokken en materialen kan ook beperkend zijn en het is soms lastig te vertalen naar de praktijk. In software wil je bouwblokken die een zekere flexibiliteit bieden en naadloos op elkaar aansluiten.

Een andere analogie die tegenwoordig veel wordt gebruikt zijn containers. Containers ontkoppelen bijvoorbeeld de goederen van het transportmiddel en standaardiseren het formaat. Een container of deze nu op een containerschip, een vrachtwagen of een trein, ze hebben allemaal dezelfde afmetingen. Van de buitenkant weten we niet wat er in zit. In data integratie hebben data formaten al enigszins deze functie. Maar het gangbare voorbeeld binnen software is tegenwoordig natuurlijk Docker containers. Docker is een lichtgewicht laag (die in seconden is op te starten), waar in je software componenten plaatst. Het grote voordeel is dat dezelfde Docker container overal werkt, in plaats van 'het werkt op mijn computer'. Doordat Docker containers makkelijk zijn aan te maken en te starten, is het niet ongebruikelijk dat er honderden containers in een cluster draaien en met elkaar samenwerken.

Het is ook geen wonder dat in analogie met de eerdere analogie van een zwerm bijen een Docker cluster wordt vermarkt onder de term Docker Swarm. Docker is in elk geval een goede basisbouwblok voor integratie. Een integratie module werkt dan als microservice. Je kan containers hebben die de technische integratie (gateway/brokers) rol vervullen en modules die de functionele integratie rol vervullen (DataFlow/ESB/API). Het idee is dat deze modules in het cluster, zoals Docker Swarm of nog populairder Kubernetes worden opgenomen.

Het verschil van deze bouwblokken is dat deze zich op een hoger niveau bevinden dan code. Vanuit code bouw je applicaties. Nadat deze applicaties in containers zitten, bouw je vanuit containers ketens. Deze ketens bestaan aan de ene kant uit applicatie containers en de andere kant containers met een integratie componenten. Het is een combinatie van de drie analogiën:

  1. Lego als bouwblok
  2. Containers als standaard manier van verpakken en verplaatsen van software
  3. Een zwerm voor het dynamisch clusteren van containers/toevoegen bouwenblokken

Serverless

Elke container is dus een eigen service. Door middel service discovery worden nieuwe containers automatisch opgenomen in een cluster. Vanuit de keten gedacht is deze serverless. Dat wil zeggen dat hardware resources automatisch worden toegedeeld. Zodra er meer data door een keten stroomt kan het automatisch opschalen. Het kan nog een stap verder gaan door ook op software niveau automatisch integratie modules/schakels er tussen en bij te plaatsen.

Hybrid cloud

Hybrid cloud is een applicatielandschap die van een mix van omgevingen gebruik maakt om applicaties te hosten. Bijvoorbeeld on premisse, private cloud and public cloud (AWS/Azure). Dit biedt meer opties waar applicatie en business functionaliteit wordt uitgevoerd, maar brengt voor data integratie wel uitdagingen met zich mee. Ten eerste afhankelijkheid tussen netwerken en meer security barrières. Een feit is dat hybrid cloud gangbaar is geworden en data integratie hier mee om moet kunnen gaan.

In de vorige paragraaf werd idee om integratie componenten onderdeel te laten zijn van een container cluster, maar hoe zit dan met een hybrid cloud? Een hybrid cloud wil zeggen dat er een combinatie is van on premisse, private cloud en één of meer public clouds (Azure, AWS). Cloud Native Application Bundle (CNAB) zijn een nieuw initiatief van onder andere Microsoft, VMWare, Docker en IBM die zorgt dat containers in elke type cluster kunnen draaien. Een Docker container op zich werkt overal, maar dit geldt niet altijd in verbinding met een cluster (Azure, Amazon, OpenShift). CNAB maakt dit mogelijk.

Zodra de cloud provider de servers automatisch in het cluster voor je schaalt, wordt er gesproken van serverless. Soms gaat dit met behulp van functies die je kan aanroepen (OpenWhisk, Azure function en AWS Lambda). Ook deze functies zijn bouwblokken. Het is ook mogelijk om zelf serverless functies/workloads te maken met behulp van KNative.

Streaming en Reactive

We kennen streaming voornamelijk van streaming media en diensten als Netflix. Hier hoef je niet eerst de media te downloaden voor het te consumeren. Bij integratie gaat het om een stroom van data die al geconsumeerd (en gebruikt wordt) voordat het geheel binnen is. Deels kan dit al worden bereikt door data in kleine gedeeltes op te delen en op basis van events te triggeren.

Low-Code en iPaas

Low-code ontwikkelomgevingen proberen bij de creatie van een applicatie, de code zoveel mogelijk te minimaliseren. Vaak ligt de nadruk bij modeleren en het maken van grafische user interfaces. Zulke omgevingen zijn ook wel bekend onder de naam Rapid Application Development of Model-Driven development. Idee is natuurlijk dat je sneller, dichter bij de business en meer gestandaardiseerd applicaties kan creëren. Bedrijven als Outsystems en Mendix hebben goede resultaten geboekt om hiermee mobiele/webapplicaties te bouwen. Low-code omgevingen zijn vaak te beperkt om integratie modules of data interfaces mee te bouwen. Daarnaast levert de platform een specifieke applicatie op.

iPaas (Integration Platform as a service) concentreren zich juist op integratie functionaliteit die op een low-code wijze gebouwd worden in de browser. Een voorbeeld is Dell Boomi. Deze low-code en as-a-service concepten om op een meer high-level manier van integreren worden belangrijker.

Het probleem is dat een platformen vaak een gesloten ecosysteem is. Niet vanuit de bouwblokken van een bedrijf, maar vanuit het platform wordt er geredeneerd. De business en platform zijn echter nooit gelijk, daarom zou je kleine onafhankelijke en open modules willen inzetten die een specifieke functionaliteit bevatten.

In runtime delivery gaat het erom de concepten van low-code en as-a-service in zo'n specifieke module te plaatsen die draait in een container. Voorbeelden van low-code integratie modules zijn Assimbly Gateway, RabbitMQ en Apache NiFi. Dit zijn voorbeelden van kant-en-klare bouwblokken waarmee samen één geheel kan worden gebouwd. Als één bouwblok niet meer voldoet of er betere bouwblok is dan hoef je alleen dit bouwblok te vervangen.

Quic

Het internet is oorspronkelijk ontwikkelt bij de Amerikaanse defensie. Doel was een robuust decentraal netwerk te bouwen die nog steeds werkt, als een deel uitvalt bijvoorbeeld door een aanval of door een aanslag. Deze is oorspronkelijk opgebouwd op basis van het TCP protocol. Dit protocol breekt data op in kleine pakketten die door meerdere netwerklagen gaan en zet deze bij de client weer in elkaar. Deze data pakketten kunnen dynamisch meerdere routes afleggen tot het op plaats van bestemming komt.

Bovenop het TCP is later HTTP protocol gebruikt om websites te draaien. Inmiddels is dit zo gegroeid dat het tegen de beperkingen aan loopt. Er is daarom behoefte aan veiliger en robuuster internet. Deze zijn initiatieven op het TCP protocol te vervangen door het QUIC protocol en HTTP door HTTP/3. Nu is dat een boek op zich, wat overigens al geschreven is en hier te lezen is. Wel is de verwachting dat toekomstige integratie modules, zoals brokers, van Quic gebruik gaan maken.

Daarnaast is het de vraag of het idee van robuuste datapakketten die via verschillende routes op plaats van bestemming komen, ook in de applicatie laag kan worden verwezenlijkt. Dus als één integratiemodule niet kan worden bereikt dat deze door een andere module kan worden verwerkt.

Standaardisatie en data knooppunten

Een andere beweging is verdere mate van standaardisatie van data formaten. Denk hierbij aan HL7, GS1, Arts en dergelijke. Hier zijn het voornamelijk standaardisatie organisaties die uitwisseling willen vergemakkelijken. In de praktijk zijn er vaak zoveel mogelijkheden, zodat een standaard die door een sector gedragen wordt nog lijvig is en daar ook lastig te implementeren. Binnen standaardisatie van formaten is er ook niet veel standaardisatie tussen formaten of enigheid of de bouwblokken. Wel zie je dat bedrijven en instellingen hier op inspreken en als knooppunten fungeren. Denken aan wigo4it en stichting inlichtingen bureau voor gemeentes of verwerkers van EDI berichten. De Nederlandse overheid heef inmiddels een forum opgericht om dit te promoten.

Een volgende stap zou zijn een gestandaardiseerde unit voor data uitwisseling. Een voorbeeld is RDF die als metamodel kan dien voor allerlei. Het voordeel is dan dat als je basis van bijvoorbeeld HL7 in de zorg kent ook de basis van GS1 kent. Naast de inhoudelijke standaardisatie is er ook standaardisatie van identiteit, autorisatie en authenticatie. Een voorbeeld is het afsprakenstelsel iShare.

DataBRAINthecloud

Keten van gestandaardiseerde eenheden voor het delen van data

Als je denkt, denk je gewoon. Een gedachte is onmiddellijk. Je denkt niet: "welk deel van mijn hersenen gebruik ik?", "wat is het pad dat mijn gedachten hebben afgelegd?" en "welke zenuwcellen zijn erbij betrokken?". Stel je voor dat voordat denkt, je eerst zou specificeren welke hersencellen deel uitmaken van één gedachte. Dit zou betekenen:

  1. Een gedachte zou veel tijd kosten om te specificeren.
  2. We hebben minder tijd om na te denken.
  3. Het denken zou moeilijk zijn om te veranderen.

Dit is natuurlijk heel onnatuurlijk, maar dit is precies het geval voor bedrijfsprocessen. Bedrijfsprocessen zijn erg statisch. Managers, bedrijfsanalisten, architecten, procesontwerpers en integratie specialisten proberen de stukken te maken om processen te bouwen. Vervolgens verbinden ontwikkelaars, systeemingenieurs, integratiespecialisten en beheerders deze tot één bedrijfsproces.

Het duurt dus erg lang voordat een bedrijfsproces operationeel is. Zodra het operationeel is, gebruikt het ook nog eens ontzettend veel energie. Momenteel gebruiken datacenters samen circa 100 miljard Kwh aan stroom. Dit groeit circa 4% per jaar, zodat in 2025 circa 1/5 van de totale energie consumptie wereldwijd door computers wordt gebruikt. De hersenen gebruiken gemiddeld 20 watt, waarmee ze zeer complexe taken kunnen uitvoeren. Het is interessant in dit opzicht te onderzoeken hoe het brein informatie verwerkt.

Het brein is niet één ding, maar opgebouwd uit verschillende gespecialiseerde delen, zoals de hersenstam, hypothalamus, amygdala en de hersenschors (cortex). De oudere delen kunnen snel intuïtieve reacties geven, terwijl de hersenschors meer cognitieve taken op zich neemt. De afzonderlijke delen zijn samen weer opgebouwd uit circa 100 miljoen hersencellen (neuronen). Elke hersencel is verbonden met verschillende andere hersencellen. Informatie wordt verwerkt doordat hersenscellen enerzijds iets doen en tegelijkertijd andere hersencellen aan sturen.

Hoe doet het brein dat? Ten eerste gebruikt het miljarden generieke cellen die met elkaar zijn verbonden via dendrieten en synapsen. Ten tweede zijn er hersengebieden die gespecialiseerd zijn in het verwerken van bepaalde soorten informatie. Ten derde worden door bepaalde gedachtes, bepaalde routes in het brein versterkt. Zou dit ook voor organisaties mogelijk zijn? Kan een bedrijf spontaan denken?

Lagen

Toekomstige technologieën zoals quantum computers, blockchain en AI maken deze informatieverwerking waarschijnlijk tot realiteit. Maar hoe ver komen we al met de huidige technologieën? Het is goed om het internet als uitgangspunt te nemen. Het internet is ontworpen als een fout bestendig netwerkprotocol. TCP/IP gebruikt hiervoor verschillende lagen:

  1. De koppelingslaag (de fysieke netwerkapparatuur die wordt gebruikt voor het onderling verbinden van knooppunten en servers)
  2. De internetlaag (verbindt hosts met elkaar op verschillende netwerken)
  3. De transportlaag (zorgt voor alle host-naar-host communicatie)
  4. De applicatielaag (om communicatie tussen applicaties op een netwerk te verzekeren)

Gegevens worden onderverdeeld in kleine pakketten die op plaats van bestemming weer worden samengevoegd. Het internet is niet op de hoogte van wat de gegevens betekenen. Dus zelfs wanneer je internet gebruikt om gegevens te delen, moet je zorgen met behulp van integratie dat het ene systeem begrijpt het andere begrijpt.

Hoe kan dit op het niveau van informatie werken? Allereerst moet de gedachte aan het bedrijf worden uitgedrukt en dit moet worden geïnterpreteerd in een gestandaardiseerd bedrijfsproces om de toepassing of zelfs organisaties te doorkruisen. Hiervoor hebben we niet alleen lagen nodig, maar ook een keten.

Als het internet het levensader van de digitale wereld vormt, hoe ziet dan het 'digitale brein' eruit die data verwerkt? Naar deze analogie kunnen we hersenscellen het beste vergelijken met nodes. Een node is een schakel in de keten. Een plek waar data wordt bewerkt en doorgestuurd. Het doorsturen kan naar één of meerdere andere nodes zijn.

Er is al lang een beweging om ketens op te delen in kleinere schakels. Denk aan low-code technieken, integratiemodules, containers, microservices, API's enzovoorts. Daarnaast is er beweging om basis technologieën, protocollen, data en business afspraken publiekelijk toegankelijk te maken. Dit enerzijds door software open source te maken en anderzijds te standaardiseren. Om bedrijfsprocessen als een gedachte te laten verlopen, dienen al deze ontwikkelingen tegelijk te worden ingezet.

Een voorbeeld keten

The Backery Group is inmiddels uitgegroeid tot een bekende keten waar ook andere bakkerijen van gebruik kunnen maken. Het levert aan groothandels en andere derde partijen. Stel een groothandel wil alle informatie van het gebakassortiment. Hoe ziet dan de informatieketen eruit zonder dat er een apart bedrijfsproces of data interface ontwikkelt voor hoeft te worden?

Als start node kunnen we de applicatie waar deze informatie wordt vastgelegd. Dit kan de Master Data Management applicatie zijn van The Bakkery Group. Het gehele assortiment, artikelnummers, ingrediënten en informatie over verpakkingen wordt hier in vastgelegd. Het beste is dat het artikel volgens de internationale standaard GS1 wordt vastgelegd. Per artikel wordt in standaard dataformaat, zoals JSON of XML, door gegeven aan een andere node. Een node kan een middleware component zijn, zoals in hoofdstuk 3 aangegeven.

Net als het internet voor netwerken, zou het voor informatie uit verschillende niveau's zijn opgebouwd:

  1. Hostniveau: dit is het niveau waarop een organisatie haar functies heeft geclusterd. Deze functies kunnen geclusterd worden in Kubernetes of in de cloud (Bijvoorbeeld Azure, Amazon AWS, Google Cloud).
  2. Containerniveau: de gestandaardiseerde eenheid voor software die kan worden geïmplementeerd en in een cluster kan worden uitgevoerd
  3. Toepassingsniveau: de eenheid die een bepaald type functie vervult
  4. Informatieniveau: een metadata-model dat vertelt welke soort functie en informatie wordt gedeeld.

Niet alleen The Bakery Group, maar ook andere bedrijven hebben één of meerdere nodes draaien. Hoe meer data, hoe meer nodes er automatisch gestart worden. Het aantal nodes is dus gerelateerd aan het dataverbruik. Al deze nodes draaien in containers die onderdeel zijn van een cluster. De transport node bevat bijvoorbeeld een AMQP broker die berichten filtert en doorstuurt naar andere nodes. De berichten komen op de broker via een generieke authenticatie en autorisatielaag (bijvoorbeeld iShare). De data stroom zou van de ene naar de andere node versleutelt tot het op een node komt van bestemming. Daar wordt ontsleutelt en komt het bij het doel aan. De doel kan of het standaard bericht direct verwerken of er iets een node voor functionele integratie en/of node voor technische integratie. Ten slotte wordt er bevestiging bericht terug gestuurd. Deze metacommunicatie wordt in lange termijn geheugen opgeslagen om aan te tonen dat berichten zijn afgeleverd.

De nodes (hersenscellen) worden dus niet geprogrammeerd, maar zijn software bouwblokken met een specifieke functie. Elk deel van de keten is een container. Delen van de keten worden vervolgens automatisch opgestart in de clusters van elk bedrijf. Applicatie containers zijn modules die net als een neuron informatie consumeert, verwerkt en produceert. Andere modules zijn gespecialiseerd in de overdracht. Denk aan technische en functionele integratie modules. Een keten van informatie is gecreëerd.

De ideale taart

Ideaal gezien zijn er geen barrières voor mensen en informatie. Het ideaal plaatje bestaat natuurlijk niet, omdat elke situatie anders en de realiteit weerbarstig is. Toch kan een betere integratie verwezenlijkt worden door de juiste mix van bovengenoemde nieuwe ontwikkelingen. Telkens als er nieuwe bouwblok bij komt voor verdere integratie, is er weer een stap gezet. Een stap in het verbinden van data. Een stap in het verbinden van mensen. Kortom: Tijd voor een taart!