Al zolang er ‘ict’ is, is er de behoefte om dit te besturen, te beheer(s)en en vooral beschikbaar te houden. Om de gebruiker 100 procent beschikbaarheid te laten beleven, is het voor de ict-manager noodzakelijk precies te weten wat er in het steeds complexer wordende ict-landschap gebeurt. Daarom wil hij inzicht hebben in de keten van gebruiker, bedrijfsproces, applicatie, data en onderliggende infrastructuur. De oplossing: voorspellend monitoren van de héle keten.
Ict-ketens hebben tot doel om bedrijfsprocessen zoals ordering, fulfillment en billing te ondersteunen. Deze complexe processen maken gebruik van diverse ict-componenten. Het uitvallen van één van deze componenten kán grote impact hebben op de bedrijfscontinuïteit.
Een verstoring kan echter ook helemaal geen gevolgen hebben. Wat is de impact van het uitvallen van een enkele firewall op de gehele dienstverlening? Of zou men graag van te voren al willen weten dat er verslechtering van de performance aankomt?
De praktijk: reactief
Om beter inzicht in de impact van verstoringen te hebben, is het belangrijk om een goede basis neer te zetten met componentmonitoring (gericht op afzonderlijke ict-componenten zoals servers, routers, databases en storage).
Dit stelt men in staat om te zien dat er wat defect is, maar geeft nog geen inzicht op de impact op de klantbeleving van de ict. Daarom kun je alleen reageren als er daadwerkelijk een verstoring optreedt in de bedrijfsprocessen en geeft het alleen inzicht in de beschikbaarheid van afzonderlijke elementen.
De wens: proactief
Van veel meer toegevoegde waarde zou het zijn als deze losse elementen logisch verbonden worden aan de bedrijfsprocessen. Dit kan met business service monitoring dat inzicht geeft in de impact van een event of incident op een bedrijfsproces.
Daarmee kan de business proactief geïnformeerd worden over events die tot performanceproblemen kunnen leiden en de business kunnen verstoren. Met dit inzicht kunnen ook incidenten worden voorkomen, wat weer leidt tot stabielere performance.
Gebruikersmonitoring
Gebruikersmonitoring geeft inzicht in wat gebruikers daadwerkelijk ervaren, naast het inzicht in het algehele bedrijfsproces door business service monitoring. Business service monitoring is in essentie een passieve vorm van monitoren. Er wordt bijvoorbeeld alleen gemeten of er data dan voorbij komt dan wel of er activiteit is of niet. Door dit te combineren met actieve monitoring geeft het ook inzicht in wat de eindgebruiker daadwerkelijk ervaart.
Wanneer zich een incident voordoet, is de oorzaak eenvoudiger te achterhalen als de resultaten van gebruikersmonitoring op het moment van het event worden vergeleken met de resultaten van de element- en business service monitoring op het moment van het event. Een logische mapping tussen gebruikerstransacties en de daarvoor benodigde elementen is hiervoor randvoorwaardelijk.
Capacity management door ‘prediction of events’
Nóg proactiever kan men acteren als de historische data van events wordt bijgehouden. Er kan dan worden voorspeld of er een incident aankomt. Als uit analyses bijvoorbeeld blijkt dat wanneer het facturatieproces altijd een incident ervaart wanneer het cpu-gebruik boven de 70 procent komt, dan kan de ict-afdeling al ingrijpen wanneer de cpu-load op 65 procent komt.
Dit kan door dynamische cpu-capaciteit op te schakelen of aan de applicatiekant enkele handelingen op ‘on hold’ te zetten, al dan niet geautomatiseerd met een script. Voorspellend monitoren vraagt vooral om trendanalyse van historische data, niet om extra monitoring. Het vraagt om een proactieve houding van de ict-afdeling; ‘meten is weten’ moet ‘weten is actie’ worden.
David van Straalen, performance consultant bij KPN
“Wanneer zich een incident voordoet, is de oorzaak eenvoudiger te achterhalen als de resultaten van gebruikersmonitoring op het moment van het event worden vergeleken met de resultaten van de element- en business service monitoring op het moment van het event. Een logische mapping tussen gebruikerstransacties en de daarvoor benodigde elementen is hiervoor randvoorwaardelijk.”
Wat moet ik me daarbij voorstellen ? Iets van : “Heee, toen die printer het begaf gingen ineens mensen bellen, dat ze nie meer konden printen”. Hmm, zou er een verband zijn ?
Mooie presentaties met business lingo gaan erin als koek bij het management. Maar wie heeft er wel eens een uptodate CMDB gezien bij een beetje groot bedrijf ?
En gelijk hebben ze, mooie plaatjes maar wat een rotwerk om dat allemaal bij te houden 🙂 In de Cloud ermee en vette SLA erop.
Meer grip op de keten is nu precies de controlekramp waar we niet naar toe moeten.
In de hier geschetste 4-lagen architectuur in de vorm van een “keten van gebruiker, bedrijfsproces, applicatie, data” zie ik vooral een proces-georiënteerde aanpak en niet een service-georiënteerde aanpak.
Zo bestaat het fundament van een SOA niet uit data of infrastructuur, maar uit bedrijfsobjecten, om de eenvoudige reden dat SOA een vervolg is op het object-georiënteerde denken (OO). Voortbouwend op dit solide fundament kunnen dan achtereenvolgens de bedrijfsfunctionaliteit en de bedrijfsflow worden onderscheiden, tenslotte uitkomend in de bovenste laag, namelijk de gebruikersinterface (ook wel voorkant of selfservice genaamd).
Kortom, de 4 lagen van een Process Oriënted Architecture, soms ook wel Data of Information Oriënted Architecture (IOA) genoemd, worden in dit opiniestuk geschetst, namelijk:
data, applicatie, bedrijfsproces, gebruiker;
de 4 lagen van een Service Oriented Architecture zijn in mijn optiek echter:
objecten, functionaliteit, flow, selfservice
Wordt het na productoriëntatie en procesoriëntatie niet eens tijd voor service-oriëntatie?
@Jack,
Het artikel gaat over bedrijfscontinuiteit, incidenten voorkomen en monitoring en beschrijft 5 lagen. Jij hebt het over orientatie van aanpak en vergeet de Infrastructuurlaag. Je kunt orienteren wat je wil maar, toch gok ik dat jij ook gaat bellen als je niet kan printen.
Felix,
De vermelde 5 lagen zijn een verwarring van views; infrastructuur hoort bij een Technology View, de andere 4 lagen bij een Functional View (en nog wat verder ingedikt bij een Business View).
Zie desgewenst mijn reactie op
https://www.computable.nl/artikel/opinie/systeembeheer/4082721/1277800/architectuur-en-service-management-superduo.html
voor een verdere toelichting.
Jack, Je kunt orienteren, optiek hebben, denken en viewen.
De gebruiker belt echter dattie niet kan printen. Ten behoeve van een business proces, werkt die in een applicatie, die data afdrukt middels een infrastructuur. En dat lukt nie. In dat kader nix mis met het plaatje in het artikel.
Het is daarbij niet de vraag of “het niet eens tijd wordt voor service-orientatie”. Het is is tijd om de toner te vervangen, pappier bij te vullen en wellicht de printer te monitoren met iets als SNMP ofzo.
Bedankt voor jullie reacties op het artikel. Een service oriëntatie is zeker relevant. Een logische vraag die je jezelf moet stellen nadat je inzicht hebt verkregen in de keten prestatie, Hoe ga je de klant beleving (service) verbeteren met deze inzichten.
In een volgend artikel wil ik hier ook verder op in gaan. Hoe kan je je service verbeteren als je vanuit je monitoring ziet dat de toner leeg is. Liever nog, zien we dat hij op 10% zit en dat ik de toner al kan vervangen voordat er signalen komen dat er helemaal niet meer geprint kan worden (voorkomen van incidenten).
Denk aan de voordelen die je kan behalen als je middels monitoring (en het acteren daarop!) in staat bent om service monteurs 100% IT beschikbaarheid te bieden. Hoe veel sneller ze daarmee problemen kunnen oplossen zonder te wachten op IT (waaruit zij de incidenten, adres gegevens etc) moeten ophalen. Elke minuut wachten op IT is een minuut waarin zij niet jou telefoon aansluiting kunnen repareren.
@Felix,
Je hebt er blijkbaar behoefte aan de beleving van de klant te reduceren tot een goed functionerende infrastructuur, maar dan heb ik nog wel een heel concreet voorbeeld waaruit blijkt dat tevredenheid van klanten nog wel wat meer omvat.
Zo bestelde ik enkele weken geleden in een webshop enkele artikelen met 50% korting. Onder de verschillende betaalwijzen kon onder andere gekozen worden voor “vooraf betalen”, waarbij een bevestigingsmail wordt toegestuurd met rekeningnummer, of “direct” door middel van Ideal.
Ik koos voor een betaling met Ideal; het uitstapje naar mijn eigen bank werd keurig afgesloten met de melding: “De betaling is geslaagd”. Hierna kwam ik echter niet terug in de winkelmand van de webshop; wel op een lege internet-pagina met adres: https://ppipe.net/connectors/asyncresponse.
Op dat moment ontstond bij mij het vervelende gevoel wel betaald te hebben voor een bestelling die nog niet was doorgegeven aan de webshop. Dus besloot ik op een tweede tabblad in de browser opnieuw naar de webshop te gaan, waar mijn winkelmand nog intact was. Om de bestelling alsnog door te geven koos ik nu voor betaalwijze “vooraf betalen”, en kreeg vervolgens de eerder genoemde bevestigingsmail met de bestelde artikelen toegestuurd.
Om een lang verhaal kort te maken: de bestelling is geannuleerd en ik kreeg het betaalde bedrag ongeveer 20 dagen later teruggestort op mijn rekening.
Uit deze gang van zaken is een tweetal conclusies te trekken:
1. de applicatie van deze webshop is niet in staat automatisch koppelingen te leggen tussen betalingen met Ideal en bestellingen met betaalwijze “vooraf betalen”, zodat deze bestellingen niet geautomatiseerd kunnen worden afgehandeld. Dit wordt nog in de hand gewerkt doordat voor de verschillende betaalwijzen verschillende rekeningnummers worden gebruikt.
2. bovendien zijn helpdeskmedewerkers niet in staat door handmatig ingrijpen deze koppeling alsnog te leggen en daarnaast in te grijpen in de workflow, zodat het automatisch annuleren van de bestelling kon worden voorkomen.
Zie hier de gevaren van het blijven denken in (ketens van) bedrijfsprocessen. Door de opkomst van selfservice kunnen zeer snel en via verschillende kanalen wijzigingen in de klantsituatie ontstaan. Dit willen afhandelen door middel van bedrijfsprocessen leidt tot een toename van de complexiteit en een afname van de flexibiliteit en bovendien tot een haperende dienstverlening wat uiteraard fnuikend is voor de klanttevredenheid.
Nogmaals, klantbeleving heeft ook te maken met beschikbaarheid en een vlotte response, maar uiteindelijk wil je gewoon de diensten waarom je hebt gevraagd.
Ja, Jack, jij hebt blijkbaar behoefte aan het promoten van Service Orientatie Architectuur, SOA.
In jouw klantbeleving voorbeeld kan de klant wel betalen, maar krijgt die het product niet toegezonden. Die fout kon blijkbaar niet worden hersteld worden door de helpdesk. Het zou op te lossen zijn met SOA. Henri hoor ik in de verte ook al enthousiast knorren 😉
Die asyncresponse duidt op SOA en dat is nu precies waar het mis ging. De Payment Service Provider kan wel registreren dat de betaling gelukt is, maar dat niet terugmelden aan de webshopserver, die de request doet aan de PSP. Das gewoon een bug, ik vermoed aan de webshop kant.
Het zou mooi zijn als de softwarebug werd verholpen, of dat de helpdesk de koppeling (tussen voorgaande betaling en bestelde product) alsnog konden maken. Maar dat vergt respectievelijk aanpassing in software, dan wel extra helpdeskrichtlijnen.
Het model van de auteur, David, beschrijft echter uitsluitend afhankelijkheden en geen nieuwe vervangende architectuur. Dat kost ook nogal wat, he. Aan zijn antwoord leid ik ook een beetje af dat hij het niet over het architectuurdeel van de SOA heeft, maar alleen over de Service Orientatie. Das volgens mij ook het logisch gevolg van IT-ers die Service Oriented Architectuur voorstellen als Service Orientatie aan de Business. Die wil namelijk geen architectuur maar dat IT-ers zich op de dienstverlening aan de klant richten. Heb ik meer over gelezen hier bij Computable.
Zo maakt SOA misschien wel meer kapot dan je lief is.
Nou ja, iedereen reageert is zo positief. Laat ik vaststellen dat we het ermee eens zijn dat de klant de beleving moet hebben dat die krijgt waar die om gevraagd heeft.