Level Of Service
Casper
Service Level in Control (click here for English version)

In dit Blog wil ik mijn visie geven op de service van een applicatie of keten tijdens het gebruik (applicatie levens cyclus). Waar moet je op letten en wat heb je nodig. Ik merk dat in de praktijk het accent vaak op het verkeerde ligt. Namelijk op het oplossen en niet op het voorkomen
of beperken
van een verstoring.
Aan de hand van een aantal termen zal ik mijn visie proberen uit te leggen; -- MTBF (Mean-Time-Between-Failures) MTTF (Mean-Time-To-Fail), MTTD (Mean-Time-To-Detect) en MTTR (Mean-Time-To-Repair) --. Termen die allemaal de status van een applicatie of keten aanduiden.
De fase tussen de verstoringen (MTTF) is de meest gewenste applicatie status. Alles werkt zoals het moet, geen wolkje aan de hemel. Voor mij is dat de ‘OK’-status. Dan komt er een moment, en geloof me dat geldt echt voor iedere applicatie of keten, dat er een ongewenste situatie -- incident-- optreedt, de niet-OK (NOK) status. Dan komen de andere processen aan bod; het detecteren (MTTD) en oplossen (MTTR). Ik ben van mening dat de diagnose onderdeel is van het vinden van een oplossing, vandaar voor mij geen aparte fase.
Wat ik nu vaak zie is dat het accent vaak ligt op het oplossen van verstoringen, Mean-Time-To-Repair (MTTR). We verdelen dat in prioriteiten. Het verhelpen van een grote verstoring de zogenaamde ‘Prio-1’ moet zo snel mogelijk. Je ziet dan ook dat in contracten hier veel aandacht naar toe gaat. Afspraken worden gemaakt hoe snel iets opgelost moet zijn, vaak met boetes om de afspraak kracht bij te zetten. Tuurlijk is het belangrijk om het snel oplossen van verstoringen in te regelen. Maar nog belangrijker is het voorkomen van verstoringen (MTBF). Als je het accent legt op het voorkomen van verstoringen ga je nadenken over redundantie van systemen of alternatieve vormen van beschikbaarheid van een applicatie of keten (workarround). Door hierover na te denken en passende maatregelen te implementeren zullen de grote verstoringen afnemen.
Van veel ‘Prio-1’ verstoringen, ook al zijn ze binnen de Service Levels opgelost, wordt niemand blij. Zeker de techneuten niet, die weten immers dat de verstoring voorkomen had kunnen worden door meer na te denken over de Mean-Time-To-Fail (MTTF) fase. Ik weet zeker dat als een organisatie de focus legt op deze fase, techneuten er over mee laat denken en beslissen, dat bij een grote verstoring iedereen klaar staat om dit te verhelpen. Met of zonder contract. Een spreekwoord zegt immers; “ ... Voorkomen is beter dan genezen ...”.
Blog

Nu er veel nagedacht wordt over Digitale Transitie rijst de vraag; “ Wat doen we met al die digitale gegevens? ” Waar vroeger de website het eindstation was zijn er anno 2020 betere oplossingen. Waarom je beperken tot een website, of mobiel? “ -- Mobile first -- ” is een veel gehoorde kreet. Ik pleit er voor dat om te bouwen naar “ -- API-first -- ” (API staat voor; Application Programming Interface). Als we de software architectuur verdelen in een voor- en achterkant en we zetten daar een laag tussen die dat allemaal verbindt. We waren immers toch al bezig met het schaalbaar maken van de backend systemen (achterkant) in het kader van de digitale transformatie (Lees ook mijn blog over Digitale Transformatie , https://www.casperotto.nl/digitale_transformatie ). Hoe mooi is het als je een API-laag creëert waarop je alles zou kunnen aansluiten: een website of een mobiele applicatie of een koppeling met een ander platform of ….. wat je maar wil. Je bent flexibel om te doen wat voor jouw bedrijf het beste is. Bijvoorbeeld voor klanten een portaal realiseren waar ze zaken zelf kunnen regelen. Of koppelen met een ander portaal van een partner bedrijf. Ongekende mogelijkheden. Van belang is wel om de digitale transformatie goed door te voeren. Als systemen op een goede manier gekoppeld zijn heb je daar veel profijt van. Belangrijke vraagstukken zul je moeten beantwoorden (onder andere); • Welke delen van de architectuur gedragen real time, welke niet? • Waar leg ik gegevensverzamelingen aan? • Waar moet ik buffers creëren om niet (te) afhankelijk te zijn van andere systemen? • Waar maak ik gebruik van API’s en waar van (micro) services? Belangrijk is om goed het evenwicht in het oog te houden. Net als met alle goede apparaten moeten de componenten in balans zijn. Alleen dan werkt het optimaal samen. Naast het technische is het ook belangrijk dat je een groep met de juiste mensen samen stelt. Met focus op techniek, business en financiën. Multi disciplinair, laat ze samen werken, stel kaders op maar zo min mogelijk doelen. Laat het team dat doen, je kunt de uitkomst toetsen aan de strategie welke je voor ogen hebt. Misschien word je wel verrast met een uitkomst die je niet voor mogelijk had gehouden. Dat geeft je als ondernemer ook een boost, nieuwe terreinen verkennen, nieuwe dingen leren en ontdekken. Iedere disruptieve gebeurtenis, hoe vervelend ook, opent de deur voor nieuwe kansen en oplossingen. Laten we er wat mee doen! Casper. https://www.casperotto.nl/ https://www.casperotto.nl/blog