Hoe interessant veel producten of diensten ook zijn, vaak zijn de ‘makers’ minstens zo interessant. Denk aan Elon Musk, Steve Jobs en – in iets mindere mate – Emile Ratelband. Hoe zit dat dan met onze eigen Bart en Jelle? Beschikken zij bijvoorbeeld net als genoemde iconen over voldoende daadkracht en besluitvaardigheid? Voor een antwoord op die vraag legden we de oprichters van Ambrero een reeks pittige dilemma’s voor.

‘Waar zouden ze zijn zonder de trein?’

De oprichting van Ambrero in januari 2005 kwam, voor diegenen die dat nog niet weten, min of meer toevallig tot stand. Bart Matthaei (34) kwam namelijk in 2004 tijdens zijn dagelijkse treinreis van Heerhugowaard naar Amsterdam in gesprek met een oude schoolvriendin. Die dame bleek bevriend met Jelle van den Berg die toen Interaction Design studeerde aan de HKU in Utrecht. Tijdens de levendige gesprekken die volgden, bleken er ondanks de vele verschillen tussen beiden qua achtergrond en persoonlijkheid ook voldoende overlap te zijn voor een goede klik. Ook al omdat ze op dezelfde school hadden gezeten en Bart nog les had gehad van Jelles vader.

Jeuk

Bart had toen al een paar jaar werkervaring als software-ontwikkelaar en systeem- en netwerkbeheerder bij webhosting partij Cyso. In die tijd ontwikkelde Bart ook een portaal waarmee klanten zelf konden kiezen uit een reeks diensten. Een paar jaar later begon het idee te jeuken om dit soort zaken voor meer klanten te doen en desnoods voor eigen rekening. Na de treinontmoeting en de vele gesprekken daarna trok hij met Jelle de stoute schoenen aan en was Ambrero een feit. Met VSM, een flitspaalfabrikant en enkele medische klinieken als eerste klanten kon het avontuur beginnen. Dat gebeurde aanvankelijk op een kamer bij Jelle thuis en daarna op zolder van de nieuwe woning van Bart in Alkmaar.

Dilemma’s

Het werkzame leven van Jelle (38) was tot dat moment blijven steken op ‘anemonen breken’ bij een bollenboer. Inmiddels gaat hij door het leven als UX Architect en directeur HR. Bart is op zijn beurt Consultant en directeur Finance en Commercie. Spijt van hun beslissing hebben ze geen moment gehad en eigen baas of loondienst is dan ook nooit meer een dilemma geweest. En waarom zou je ook met een goedlopend bedrijf en twintig man personeel? Nee, de dilemma’s komen uit heel andere hoek. Hier komen ze:

Nog meer weten? Bijvoorbeeld het antwoord op jouw eigen dilemma: Excelleren of consolideren? Je kunt Bart en Jelle bereiken op kopkoffie@ambrero.nl.

De afgelopen vijf maanden heb ik bij Ambrero mijn afstudeeropdracht mogen uitvoeren. Het doel was ‘’Het ontwerpen en implementeren van een proof of concept voor een schaalbare architectuur voor een groot sensornetwerk’’. De opdracht besloeg de onderwerpen: Internet of Things (IoT) en Big data. Tijdens mijn afstudeeropdracht heb ik veel geleerd en met deze blog wil ik deze kennis en een aantal tips delen.

De opdracht; proof of concept

Mijn opdracht: het maken van een proof of concept, het ontwerpen van een schaalbare dataverwerking voor een sensornetwerk.

Het sensornetwerk bestaat uit luchtkwaliteit-sensoren voor consumenten die data versturen via LoRaWAN. Het geeft consumenten inzicht in de luchtkwaliteit van hun eigen omgeving. Daarnaast dragen ze bij aan analyses over een specifieke regio.

De bedoeling is dat deze dataverwerking op drukke momenten opschaalt om de datastroom aan te kunnen. En dat het op rustige momenten weer terug schaalt zodat het efficiënt gebruik maakt van resources. Er zijn twee belangrijke eisen gesteld:

• dataverwerking van minimaal 10.000 berichten per seconde
• dataopslag van minimaal een jaar

Is mijn data eigenlijk Big data?

Veel data betekent automatisch Big Data. Deze aanname wordt vaak gemaakt waardoor er onnodig tijd wordt besteed aan speciale databases en frameworks. Terwijl deze niet altijd beter, soms zelfs slechter, presteren dan conventionele oplossingen.

Ik bepaal of mijn data Big data is aan de hand van de drie V’s van Big data; velocity, variety en volume. In de afbeelding hieronder zijn deze te zien en het toont de relaties tussen de drie V’s. Alles in de binnenste ring is geen Big data. Wanneer er één of twee V’s buiten de binnenste ring vallen kun je overwegen om onderzoek te doen naar speciale databases en frameworks. Vallen alle drie V’s erbuiten dan heb je te maken met Big data!

In mijn onderzoek is de velocity van de data; hoe vaak data wordt gebruikt tussen batch en interval. De variety is simpel, namelijk kleine berichtjes van 40kB. Het volume is echter erg groot, namelijk 10.000 berichten per seconde maal één jaar. Dat zijn ruim 300 miljard berichten met een grote van meer dat 13 terabyte. Er is dus een speciale oplossing nodig om efficiënt met de data om te gaan.

Het zoeken van de juiste componenten

Het is nog een hele zoektocht om de juiste analyse frameworks en databases te vinden voor deze applicatie. Het Big-Data landschap is namelijk enorm. Er zit altijd wel iets tussen wat goed werkt maar het vereist enig uitzoekwerk!

Uiteindelijk is mijn keuze gevallen op Apache Cassandra voor de database en Apache Flink voor het maken van analyses. Deze keuze heb ik op de volgende manier gemaakt:

In het geval van het analyse framework zocht ik een framework met batch en stream analyse mogelijkheden.

Het is handig om voor iets te kiezen wat recent is en veel gebruikt wordt, de kans dat er genoeg informatie en ondersteuning beschikbaar is is dan groot. Maar ga ook niet gelijk voor de eerste de beste big-data database die bekend klinkt. Doe je onderzoek grondig.

Kijk welke databases/frameworks voldoen aan je eisen

• Geen één gevonden? Zoek dan verder naar wat minder bekende oplossingen of kijk welke het dichtst in de buurt van je gestelde eisen komt.
• Zijn het er meerdere kijk dan welke het best binnen de applicatie past.

Vaak weet je pas echt of een framework goed binnen de applicatie past nadat je er een tijdje mee gewerkt hebt. Zorg er dus voor dat er genoeg ruimte is om te wisselen van framework.

Het creeëren van snelheid

Om de applicatie schaalbaar te maken is deze verdeeld in losse componenten. Ontstaat er bij een component een knelpunt dan wordt deze meerdere keren gestart om zo het knelpunt te verhelpen. Binnen de dataverwerking wordt RabbitMQ gebruikt als messagbroker tussen de verschillende componenten. Zo is er geen harde koppeling tussen en kunnen ze onafhankelijk van elkaar schalen. Daarnaast bevatten slimme frameworks zoals Apache Flink interne schaling waardoor ze erg snel zijn.

Optimaliseren door isoleren

Maar hoe achterhaal je de oorzaak van een traag component? In een ideaal scenario schaalt een component lineair, verdubbelt het aantal instanties dan zal de snelheid ook verdubbelen. In veel gevallen zal de hardware van het systeem waarop de applicatie draait ervoor zorgen dat een lineare schaling net niet haalbaar is. Wanneer het veel afwijkt, wijst dit op een limitatie buiten het component.

Het vinden van deze limitaties, binnen het component en/of erbuiten is een kwestie van isoleren. Ik blijf doorgaan met het isoleren van delen van het component met externe connecties totdat de schaling nagenoeg linear was. Hierdoor vond ik de bottleneck.

Uiteindelijk moest ik de volgende optimalisaties uitvoeren voor Apache Cassandra en de PostgreSQL database:

Om efficiënt gebruik te maken van de database connectie is het handig om berichten niet één voor één weg te schrijven maar ze op te sparen en periodiek weg te schrijven.

Bij speciale databases raad ik aan om eerst op te zoeken hoe zo’n database optimaal kan functioneren. In het geval van Apache Cassandra is concurency vereist om hoge snelheden te halen.

Het resultaat; 10.000 berichten per seconde

Inmiddels staat er een schaalbare applicatie die op een snelle en efficiënte manier data analyseert en verwerkt. Door het gebruik van slimme frameworks, efficiënte databases en schalende componenten kan deze dataverwerking nu 10.000 berichten per seconde verwerken. Daarnaast biedt het de gebruiker inzicht in de luchtkwaliteit en het aantal metingen per vierkante kilometer.

Een bijkomend positief resultaat… ik heb een 9 behaald met mijn afstudeeropdracht!

Tips

• Veel data betekent niet direct Big data!
• Kies bij voorkeur voor bekende Big data frameworks/databases voor de beste ondersteuning maar onderzoek de keuze hierin.
• Speciale frameworks/databases vereisen vaak een andere manier van werken, onderzoek dit.
• Verdeel je applicatie in componenten en zorg ervoor dat componenten onafhankelijk van elkaar kunnen schalen voor efficiënte schaling.
• Door te isoleren kom je erachter wat de bottlenecks van je applicatie zijn.
• Blijf optimaliseren totdat een component nagenoeg linear schaalt.

Arnout Schekkerman
Eindejaarsstudent Technische Informatica – Hogeschool van Amsterdam

Onder druk van overheid en verzekeraars worden zorgverleners gedwongen om voor minder geld dezelfde, hoge kwaliteit te bieden. Tegelijkertijd zorgt ook de vergrijzing voor een toenemende werkdruk. Ziekenhuizen, zelfstandig behandelcentra en andere instellingen moeten zo steeds efficiënter werken om hun inkomsten en uitgaven in evenwicht te kunnen houden en wachtlijsten te voorkomen.

De valkuil van efficiëntie

Door deze permanente druk dreigen we in de zorg steeds vaker de menselijkheid uit het oog te verliezen. Een ontwikkeling die we niet graag zien. Want als organisaties vooral gaan kijken naar korte termijnoplossingen om hun cijfers, declaraties en output op orde te brengen, neemt het werkplezier van artsen en verplegers vaak navenant af. We zien nu al dat ziekenhuispersoneel vaak buitensporig veel tijd kwijt is aan administratieve randzaken. Wat leidt tot artsen die een ‘afwezige’ indruk maken. En dat is niet het beste uitgangspunt voor een goede arts-patiëntrelatie…

Zorg voor innovatie

Bij Ambrero draaien we daarom de zaken graag om. Wij geloven namelijk in software die juist de mens als uitgangspunt neemt. Software moet zorgverleners vooral de vrijheid geven om zich met hun vak bezig te houden. Met onze opdrachtgevers gaan wij daarom op zoek naar hun ultieme, geoliede zorgproces. We ondersteunen hun proces met gebruiksvriendelijke software. Software op maat waarmee artsen en verplegers eenvoudiger, veiliger en met aanzienlijk meer plezier hun vak kunnen uitoefenen.

Hoe? Nou:

• door de beslisbomen en protocollen als leidraad te nemen in plaats van declaraties.
• door alle labuitslagen, röntgenfoto’s, scans met één druk op de knop op het scherm te laten verschijnen.
• door intuïtieve touchscreens op de operatiekamers te plaatsen waarmee de behandeling eenvoudig is te registreren.
• door extra veiligheid in te bouwen met ‘stops’ zodat er geen handelingen per ongeluk kunnen worden vergeten.
• door de maatsoftware te laten praten met de overige software van het ziekenhuis.
• patiënten zelf een rol te geven bij het compleet maken van hun dossier via online vragenformulieren over hun ziektebeeld.
• door consults en nazorg op afstand mogelijk te maken via webcams.
• door revalidatie vanuit huis mogelijk te maken met spelconsoles.
• door vervolgafspraken niet in dezelfde ruimte te laten plaatsvinden als het slechtnieuwsgesprek heeft plaatsgevonden.
• door monitoring op afstand mogelijk te maken met apparaten die de juiste waardes doorgeven.

Meer tijd voor de patiënt

Kortom, door de ultieme software voor u te ontwikkelen die uw ideale zorgproces perfect ondersteunt en het aantal administratieve handelingen vermindert zodat uw zorgverleners het hoofd en handen vrij hebben om de patiënt uitgebreid te spreken, te onderzoeken en het behandelplan door te spreken. Software die de menselijkheid terugbrengt. Voor zorgverlener en patiënt.

En dat is eigenlijk geen toekomstmuziek. Dat hebben we bij CASA klinieken al in de praktijk gebracht. Bekijk deze video maar eens: