Level Of Service (English Version)
Casper
Service Level in Control

In this Blog I want to give my vision on the service of an application or chain during use (application life cycle). What should you pay attention to and what do you need. I notice that in practice the emphasis is often on the wrong. Namely on resolving and not on preventing
or limiting
a disruption.
I will try to explain my vision on the basis of a number of terms; - MTBF (Mean-Time-To-Failures) MTTF (Mean-Time-To-Fail), MTTD (Mean-Time-To-Detect) and MTTR (Mean-Time-To-Repair) -. Terms that all indicate the status of an application or chain.
The phase between disruptions (MTTF) is the most desired application status. Everything works as it should, no cloud in the sky. For me, that is the "OK" status. Then a moment comes, and believe me that really applies to every application or chain, that an undesirable situation - incident - occurs, the non-OK (NOK) status. Then the other processes are discussed; detecting (MTTD) and resolving (MTTR). I believe that the diagnosis is part of finding a solution, hence no separate phase for me.
What I often see now is that the emphasis is often on solving disruptions, Mean-Time-To-Repair (MTTR). We divide that into priorities. Resolving a major disturbance called "Prio-1" must be done as quickly as possible. You can see that a lot of attention is paid to this in contracts. Agreements are made about how quickly something must be resolved, often with fines to enforce the agreement. Of course it is important to arrange for the rapid resolution of disruptions. But even more important is the prevention of disruptions (MTBF). If you emphasize the prevention of disruptions, you start thinking about redundancy of systems or alternative forms of availability of an application or chain (workarround). By thinking about this and implementing appropriate measures, the major disruptions will decrease.
Many "Prio-1" disruptions, even though they are resolved within the Service Levels, do not make anyone happy. Certainly not the technicians, who know that the disruption could have been prevented by thinking more about the Mean-Time-To-Fail (MTTF) phase. I am sure that if an organization focuses on this phase, it allows techies to think and decide with it that in the event of a major disruption, everyone is ready to remedy this. With or without a contract. After all, a saying goes; " ... Prevention is better than cure ...".
Casper.
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