Een dashboard voor onze SaaS-applicatie

Bij het selecteren van een SaaS applicatie moet een dashboard een van de requirements zijn. Het helpt ons om de applicatie te beheren en ondersteunt de governance en compliance van de gehele organisatie.

Hier volgen enkele essentiële requirements die voor iedere SaaS-applicatie onontbeerlijk zijn. Ze moeten al vroeg in de levenscyclus van de software worden opgenomen. Ze hebben te maken met multi-tenancy, beveiliging, integratie en schaalbaarheid. De in dit artikel genoemde requirements horen in een dashboard maar worden vaak vergeten.

Wat is een dashboard?

Je hebt vast eerder van het woord gehoord. Het is een veelgebruikt woord in de wereld van auto’s en vliegtuigen. Dashboards helpen chauffeurs bij het houden van de juiste snelheid en verbruiksstatistieken. Ze hebben toerentaltellers, navigatieschermen, hulpmiddelen om te bellen en natuurlijk allerlei waarschuwingslampjes over de status en de veiligheid van de auto. Het is onnodig om te zeggen dat het dashboard net zo belangrijk is als het stuur, de motor en de remmen van een auto.

Ook in IT omgevingen en voor bedrijfsprocessen is het een veel gebruikte term. Het dashboard kunnen we met een oogopslag aflezen en vaststellen of er problemen zijn of dat alles soepel loopt.

Denk je niet dat we voor onze SaaS applicatie iets nodig hebben dat vergelijkbaar is met een dashboard? We willen onze gebruikers niet opzadelen met dit soort onverwachte gebeurtenissen:

• We hebben geen toegang meer tot de applicatie. Hij is gecrasht!
• De verwerking kost vandaag veel tijd dan anders, er is een performance probleem.
• De applicatie geeft onjuiste uitkomsten, het systeem is gek geworden.
• Het systeem wil niet opstarten, we kunnen geen transacties verwerken!

Om dit soort problemen goed te kunnen managen moet we enkele essentiële, maar vaak over het hoofd geziene services op ons SaaS-platform hebben. Zij komen samen op het dashboard en geven daardoor direct inzicht.

Configureren van de SaaS applicatie

Iedere gebruiker zal de applicatie gebruiken om in zijn unieke behoeften te voorzien. Hoewel de werkzaamheden vergelijkbaar kunnen zijn, kunnen hier en daar kleine aanpassingen nodig zijn. Dit zijn kleine variaties op de business rules. Sommige gebruikers hebben bijvoorbeeld een twee-factor-authenticatie nodig en andere niet. De SaaS-provider moet de mogelijkheid hebben om dit soort tweaks uit te voeren zonder downtime. Bovendien mag het geen onbedoelde invloed hebben op het gebruik van de andere klanten.

Ons dashboard moet dus beschikken over functies waarmee er deze aanpassingen kunnen maken. Zodoende hoeven we geen contact op te nemen met het technische team om de aanpassing voor ons te doen. Hierdoor voorkomen we extra kosten en vertragingen door het implementeren van de wijzigingen. Het is onnodig om op te merken dat deze eigenschap van het dashboard onze klanten gelukkig zal maken. Bij het selecteren van een SaaS oplossing is configureerbaarheid altijd een requirement.

Configureerbaarheid per klant

Het gaat niet alleen om configureerbaarheid van de gebruikerswensen maar ook op het niveau van de leverancier. Hij moet voor verschillende klanten verschillende instellingen kunnen maken.

De impact van een gebrek aan of beperkte configureerbaarheid kan zijn dat de software maar geschikt is voor één klant. Ondersteuning van multi-tenancy vereist configureerbaarheid van het kern. Een aantal dingen die we moeten kunnen configureren zijn:

• UI-personalisatie.
• Invulling van de requirements.
• Aanpassen van business rules.
• Workflows aanpassen.
• Aanpassen van meldingen.
• Instellen van de beveiligingsbehoeften enz.

Gezondheidsmonitoring en probleemrapportage

Veel bedrijfsprocessen zijn van afhankelijk van SaaS oplossingen. Voor veel bedrijven zijn ze cruciaal. Als er iets misgaat, heeft dit direct gevolgen voor de omzet. We krijgen dan te maken met veel boze gebruikers en wie weet met grote verliezen. Daarom is het belangrijk om altijd op de gezondheid van alle services te letten.

We willen niet dat onze gebruikers komen vertellen dat een functie niet werkt zoals verwacht. Of dat het systeem helemaal down is. We zou graag dat het systeem zelf belangrijke signalen geeft als er iets niet klopt.

Als het inloggen normaal gesproken bijvoorbeeld 500 ms duurt, maar de laatste 15 minuten kost het 800 ms, dan moeten de systeembeheerders dit zo snel mogelijk weten. Of, als het systeem meer fouten van een bepaald type meldt sinds de laatste oplevering? Het dashboard moet lampjes hebben om dergelijke fouten te melden en te loggen. Hiervoor moeten we deze functionaliteit in het dashboard opnemen. Het later inpassen, is moeilijker dan je denkt.

Abonnementen en quotabeheer

Een van de belangrijkste eigenschappen van SaaS is het abonnementenmodel. Bij het programmeren van de applicatie ligt het accent echter meestal op de basis functies. De implementatie van een abonnementsvorm wordt vaak uitgesteld tot het laatste moment. Dit maakt het tegen die tijd erg moeilijk om te implementeren. Het is beter om vanaf het begin met de mogelijke abonnementsvormen rekening te houden. Varianten kunnen we later eenvoudig implementeren als de structuur maar klopt.

Een ander aspect dat vaak volledig wordt gemist, is quotabeheer. Een voorbeeld van het toepassen van quota, voor een bepaald abonnement, is hoeveel transacties op een dag zijn toegestaan. Of hoeveel relaties je in het systeem mag opnemen. In dergelijke abonnementsvormen rekenen we af per transactie of relatie, niet per gebruiker. Dit is het zogenaamde pay-per-use model.

Ook voor de leverancier is dit belangrijk omdat iedere transactie geld kost. De winstgevendheid van de leverancier loopt gevaar als hij de kosten per transactie niet in beeld heeft. Dit helpt hem ook bij het plannen van zijn infrastructuurbehoeften. Op basis van quota waar klanten voor hebben gekozen, krijgt hij een ​​idee van hoeveel hardware er nodig is en wanneer.

Het dashboard en auditing

De verantwoordelijkheid voor de data en wat daarmee gebeurt, ligt bij de SaaS-provider. Daarom is het belangrijk om over robuuste auditing te beschikken om alle veranderingen van de gegevens die in het systeem plaatsvinden te volgen. Soms kan het nodig zijn om meldingen in te stellen voor bepaalde soorten gebeurtenissen op basis van vooraf gedefinieerde waarden.

Als er bijvoorbeeld te veel mislukte inlogpogingen zijn, wil de systeembeheerder een waarschuwing ontvangen en ook de mogelijkheid om details in te zien van die mislukte aanmeldingen. Bijvoorbeeld van waar ze zijn ontstaan, hoe laat etc.

Dit is een van de niet-functionele requirements die we vaak uitstellen tot een later moment. Maar de harde waarheid is dat dat moment nooit komt. Naarmate het systeem groeit, nemen de implementatiekosten van audits exponentieel toe. Soms dwingen compliance vereisten SaaS-providers ertoe om auditing meteen op te nemen in de software. In andere gevallen is dat niet zo. Hoe het ook zij, het is essentieel dat vanaf het begin auditing in het systeem in te bouwen.

Feedback uit het dashboard

De SaaS systeembeheerders, en tot op zekere hoogte de functioneel beheerders van iedere klant, hebben een dashboard nodig om configuraties te beheren, de status van het systeem te beoordelen en waarschuwingen te ontvangen in geval van problemen. Als de ontwikkelaars al bij het ontstaan van de software aan zo’n dashboard denken kunnen ze een betere ondersteuning leveren. De data die het dashboard oplevert kunnen we gebruiken om de software te verbeteren.

Discussieer mee op LinkedIn.