Vi oplever ofte, at vores multi-tenant SaaS tjenester bliver sammenlignet med forældede systemer og pakket ind i begrebet SaaS. Forældet software kan nemt pakkes ind i ny indpakning, så det ser lækkert ud. Software på abonnement er også muligt, selv om det er baseret på gammelt software.
Forældet eller gammelt software går ofte under begrebet Legacy software og er typisk kendetegnet ved at være baseret på forældet teknologi, der stadig indfrier mange af de behov, som det oprindeligt var designet til. Selve brugergrænsefladen kan derfor godt syne moderne og nutidig. Men legacy software er svært at opdatere og vedligeholde, og systemerne er svære at integrere med andre systemer.
Selvom ansvaret er placeret hos producenten, bliver det over tid kundens hovedpine, når udfordringerne skubbes og teknisk gæld opbygges. Det kan enten have økonomiske eller sikkerhedsmæssige konsekvenser.
Problemet er kundens!
Efterhånden bliver der længere og længere mellem opdateringerne, og leverandøren takker enten nej til nye tiltag, tilbyder specialudvikling, eller udvikling af en app som alternativ. Efterhånden er kunden flettet ind i forældet software og en klynge af specialudviklet software. Jo mere specialudvikling, desto mere komplekst og dyrt bliver det at opdatere og vedligeholde tjenesterne. Det ved enhver udvikler, når de skal fejlsøge. Lapper de spanden et sted, springer den læk et andet sted.
Selv om kunden kontraktmæssigt har garderet sig med opdateringer og vedligehold i aftalen, er der stadig grundlag for bekymring. Den største hovedpine opstår, når forældet software alligevel ikke bliver opdateret og vedligeholdt, så bliver det sårbart for hackerangreb, herunder især ransomware, der er i stand til at ligge hele organisationer ned. Ledelse og ansatte i IT-afdelingerne, der har prøvet det, ser det som deres karrieres største udfordring.
Hos Bleau er vi vidner til meget Legacy software indenfor vores branchevertikaler. Nogle tjenester mere forretningskritiske end andre. F.eks. kan det virke harmløst at få udviklet en app til servicering af beboere, eller bibeholde et forældet intranet i kommunen, da det jo stadig virker. Men når f.eks. en app er afhængig af et Legacy system, bliver den heller ikke vedligeholdt og kan derfor fungere som en trojansk hest ind til samme Legacy system og måske videre til øvrige fagsystemer. Chancen for at skabe en kædereaktion med nedbrud og manglende overholdelse af GDPR-regler, bliver derfor unødvendig stor.
Mange offentlige kunder er bekymret for Schrems II, med at udlevere persondata uden for EU. Der bør dog også være søvnløse nætter hos ledelsen over brugen af utallige applikationer, som enten er udviklet på open source-software i ukendt land, eller som hostes hos f.eks. Amazon, Google, Facebook uden sikkerhedsforanstaltninger for misbrug og GDPR.
Sådan undgår I valget af et legacy system
Hvis I vil undgå gammel eller forældet legacy software, skal I i stedet vælge et SaaS-system. Læs med og bliv klogere på, hvordan I sikrer jer det.
Vælg ægte SaaS
- Først og fremmest vælg et ægte SaaS system, der kendetegnes ved, at der er mange kunder som benytter samme standard funktionalitet, og som dermed bidrager til løbende vedligehold og øgede sikkerhedsforanstaltninger. For SaaS leverandøren handler det om, at jo højere kvalitet og oplevelse af value for money, desto større sandsynlighed for øget kundetilgang. Et ægte SaaS system bliver kun forældet, hvis der er for få kunder, som benytter tjenesten.
- SaaS systemer er også veldokumenterede som forretningsgrundlag. Single-tenant og specialudviklede systemer er sjældent veldokumenterede, da konfigurationen i overvejende grad er målrettet den enkelte kunde.
Vælg ægte SaaS
- Først og fremmest vælg et ægte SaaS system, der kendetegnes ved, at der er mange kunder som benytter samme standard funktionalitet, og som dermed bidrager til løbende vedligehold og øgede sikkerhedsforanstaltninger. For SaaS leverandøren handler det om, at jo højere kvalitet og oplevelse af value for money, desto større sandsynlighed for øget kundetilgang. Et ægte SaaS system bliver kun forældet, hvis der er for få kunder, som benytter tjenesten.
- SaaS systemer er også veldokumenterede som forretningsgrundlag. Single-tenant og specialudviklede systemer er sjældent veldokumenterede, da konfigurationen i overvejende grad er målrettet den enkelte kunde.
Stil krav til Multi-tenant
- Spørg efter Multi-tenant vs. Single-tenant applikationer. Med Multi-tentant er alle kunder på samme platform, og dermed altid opdateret og vedligeholdt på samme niveau. Ved Single-tenant er der ofte risiko for flere versioner af softwaren, der bliver vedligeholdt forskelligt.
- Flere versioner af samme software kræver ekstra vedligehold, og der opstår hurtigt et A-B-hold mellem de kunder, som er på nyeste version, og de kunder som opbygger teknisk gæld ved ikke at være opdateret.
- Spørg til hvor ofte der er releases på opdateringer. Multi-tenant opdateres med høj frekvens, ofte ugentlige releases og ofte automatisk. Med versionstyret software er det ofte i fastlagte intervaller (månedligt/kvartalsvis/halvårligt), hvor det kræver, at kunderne bliver inddraget.
Stil krav til Multi-tenant
- Spørg efter Multi-tenant vs. Single-tenant applikationer. Med Multi-tentant er alle kunder på samme platform, og dermed altid opdateret og vedligeholdt på samme niveau. Ved Single-tenant er der ofte risiko for flere versioner af softwaren, der bliver vedligeholdt forskelligt.
- Flere versioner af samme software kræver ekstra vedligehold, og der opstår hurtigt et A-B-hold mellem de kunder, som er på nyeste version, og de kunder som opbygger teknisk gæld ved ikke at være opdateret.
- Spørg til hvor ofte der er releases på opdateringer. Multi-tenant opdateres med høj frekvens, ofte ugentlige releases og ofte automatisk. Med versionstyret software er det ofte i fastlagte intervaller (månedligt/kvartalsvis/halvårligt), hvor det kræver, at kunderne bliver inddraget.
Gå med cloud
- Cloud vs On-Premise installation. Tillader leverandøren installation lokalt i kundens eget server miljø, også selv om det er kundens Cloud installation, er der tale om On-Premise og dermed vedligehold af flere versioner. Har I selv andre Legacy systemer, der skal tale sammen med den nye tjeneste, så vælg en Hybrid installation, hvor data alene udveksles mellem SaaS Cloud og jeres On-Premise miljø via API.
- I stedet for at efterspørge On-Premise løsninger pga. Schrems II, bør I i stedet sikre, at leverandørens Cloud Miljø er krypteret og data alene bliver opbevaret i EU.
Gå med cloud
- Cloud vs On-Premise installation. Tillader leverandøren installation lokalt i kundens eget server miljø, også selv om det er kundens Cloud installation, er der tale om On-Premise og dermed vedligehold af flere versioner. Har I selv andre Legacy systemer, der skal tale sammen med den nye tjeneste, så vælg en Hybrid installation, hvor data alene udveksles mellem SaaS Cloud og jeres On-Premise miljø via API.
- I stedet for at efterspørge On-Premise løsninger pga. Schrems II, bør I i stedet sikre, at leverandørens Cloud Miljø er krypteret og data alene bliver opbevaret i EU.
Vælg en moderne systemarkitektur
- Moderne software er udviklet således, at brugergrænsefladen kan tilpasses individuelt uden om kernefunktionalitet. Undersøg hvor fleksibelt brugergrænsefladen er, uden det kræver specialudvikling.
- Mikro services er mindre selvstændige software komponenter, med egen logik og processer. Tjek at det er muligt at anvende mikro services, som kan udskiftes og opgraderes uafhængigt af kerne-funktionalitet.
- Mikro services bliver forbundet gennem et API, så forhør jeres leverandør, om de har et åbent standard API - og igen under hvilken rutine det bliver vedligeholdt. Jo flere specialudviklede API’er, desto større sandsynlighed for manglende vedligehold.
Vælg en moderne systemarkitektur
- Moderne software er udviklet således, at brugergrænsefladen kan tilpasses individuelt uden om kernefunktionalitet. Undersøg hvor fleksibelt brugergrænsefladen er, uden det kræver specialudvikling.
- Mikro services er mindre selvstændige software komponenter, med egen logik og processer. Tjek at det er muligt at anvende mikro services, som kan udskiftes og opgraderes uafhængigt af kerne-funktionalitet.
- Mikro services bliver forbundet gennem et API, så forhør jeres leverandør, om de har et åbent standard API - og igen under hvilken rutine det bliver vedligeholdt. Jo flere specialudviklede API’er, desto større sandsynlighed for manglende vedligehold.
Prioriter et udviklingsfællesskab
Afslutningsvis, men ikke desto mindre vigtigt, sikre jer at leverandøren af SaaS har et velfungerende udviklingsfællesskab, hvor I som kunde bliver lyttet til og kan bidrage til den videre udvikling af jeres tjeneste.
Prioriter et udviklingsfællesskab
Afslutningsvis, men ikke desto mindre vigtigt, sikre jer at leverandøren af SaaS har et velfungerende udviklingsfællesskab, hvor I som kunde bliver lyttet til og kan bidrage til den videre udvikling af jeres tjeneste.
