Data replicatie is het begin data sovereignty.

Geef een reactie

Er is de laatste maanden voldoende geschreven over Digital Sovereignty. Dit wordt natuurlijk beïnvloed door geopolitieke ontwikkelingen. Bedrijven en organisaties denken opnieuw na over de keuzes die ze kunnen maken en de afhankelijkheden die zij hebben. Tenzij je bereid bent zelf computers te bouwen en zelf software te ontwikkelen – en oh ja, zelf stroom op te wekken, ben je altijd wel van iets of iemand afhankelijk. Deze afhankelijkheid is niet per se een probleem, zolang je vrij bent om de afhankelijkheden te kiezen en de zelfstandigheid van de organisatie, en ze de uitvoering van het werk, de productie of de services niet in de weg staan, zit je goed. Keuzes zouden de toekomstige opties niet moeten beperken. Dus ga nooit een eenrichtingsverkeer straat is qua IT.

Bij de meeste bedrijven en organisaties betreft Digital Sovereignty eigenlijk hoofdzakelijk Data Sovereignty. Het “In control” blijven van data betekent vaak bepalen wie toegang heeft tot data, waar de data opgeslagen is (geografisch) en dat het niet gestolen-of encrypted kan worden (ransomeware). Ook compliancy speelt hierbij een rol. GDPR / AVG vereisen dat je garanties kan geven over het niveau van beveiliging en bescherming van data. Hoe doe je dat wanneer jouw data onder buitenlandse wetgeving valt?

Voor Data Sovereignty is het dus erg belangrijk dat je data technisch kan manipuleren (managen) en dan vooral kan repliceren. Dit is zeker geen nieuw onderwerp, in ons IT vakgebied doen we dit al jaren. Omdat het wederom zo’n actueel onderwerp is, wordt in dit artikel gekeken naar de verschillende soorten data replicatie die er zijn – dit alles tegen het licht van Data Sovereignty.

Verschillende soorten replicatie

Om maar meteen met de deur in huis te vallen, er zijn 3 fundamentele vormen van data replicatie. Zo kunnen disk-blokken gerepliceerd worden (block based replication, bijvoorbeeld bij Reduntant Arrarys of Inexspensive Disks – RAID), kunnen er records gerepliceerd worden (bij databases) of volledige files gerepliceerd worden (denk aan bijvoorbeeld AWS S3 buckets, Google’s Cloud Storage of Microsoft Azure Blob storage). Allen hebben hun sterke en zwakke kanten en daarmee specifieke toepassingsgebieden. In “Cloud Speak” hebben we het dan over “Patterns and Anti-Patterns“. Hierbij zijn de “Patterns” de juist toegepaste replicatie types en de “Anti-Pattrens” onjuist toegepaste replicatie types in een specifiek geval.

Block based storage

Block based storage komen we vaak tegen in de wereld van Storage Area Networks (SAN’s). Dit zorgt ervoor dat data op meerder disks komt te staan en het falen van een disk niet leidt to data verlies. Het is een heel efficiente vorm van data replicatie omdat alleen gewijzigde blokken gerepliceerd worden. Dit in tegenstelling tot het repliceren van het complete bestand. Niet alleen bij SAN’s komen we dit tegen. Zo is er ook open source software om block based replicatie te doen (eventueel over een netwerk), zoals o.a. DRBD.

Block based replication wordt meestal toegepast met als doel redundantie (van disks bijvoorbeeld) te realiseren. Wanneer het geen replicatie is tussen lokale disks, maar er naar een andere disk op een andere locatie gerepliceerd wordt, gaat het niet alleen om disk redundantie, maar ook om de beschikbaarheid van de data. De (fysieke) locatie van de data is dan als Single Point of Failure (SPoF) uitgesloten. Maar ook zo’n oplossing kent zijn grenzen. Wanneer data aan een zijde gedelete wordt, wordt dat gebeurt dat ook aan de andere kant. Daar beschermt het dus niet tegen. Het is geen disaster recovery (DR). Een off site backup is dat bijvoorbeeld wel.

Record gebaseerde replicatie

Record gebaseerde replicatie wordt toegepast bij databases. Databases kennen lees-acties en schrijf-acties van bijvoorbeeld records . Bij replicatie worden alleen schrijf-acties gerepliceerd, de lees-acties veranderen immers niets, De schrijf-acties worden aan de andere zijde opnieuw gedaan zodat beide databases weer gelijk zijn. Vaak is de gerepliceerde database een “Alleen lezen” database (ook wel “Slave” genoemd). De gerepliceerde (slave) database kan bijvoorbeeld prima gebruikt worden om backups van te maken. Er is dan geen performance impact op de “primaire” of “Master” database.

Replicatie wordt hier dus ook gebruikt om de beschikbaarheid te vergroten (en is er geen sprake van DR). De backup die van de “Slave” database gemaakt wordt is wel een DR maatregel. De gerepliceerde schrijf-acties Kunnen in een re-do log file geplaatst worden (Oracle technologie). Deze re-do log files worden dan vaak ook in de backup meegenomen. Met de combinatie van backup van de database en de re-do log files kan een “Point-in-Time restore” worden uitgevoerd.

Databases hebben legio mogelijkheden om te repliceren. Bijvoorbeeld MySQL / MariaDB bieden uitgebreide mogelijkheden hiertoe. In het bovenstaande voorbeeld werd de database replica niet gebruikt voor productie. Het wordt gebruikt om een backup van te maken en het heeft ook geen eindgebruikers. Maar voor lees-acties kunnen beide databases (“Master” en “Slave”) gebruikt worden, zolang wijzigingen alleen naar de “Master” geschreven worden. In het algemeen heeft een database 10 keer zoveel lees-acties als schrijf-acties. Een “Master” met 9 “Slaves” kan dus een manier zijn om de totale performance van het gehele systeem te verhogen. Maar hoewel de performance dan hoger is, is de “Master” nog steeds een Single Point of Failure (SPoF). Een van de “Slave” database kan “Master gemaakt worden, maar dat vraagt tijd en dat levert dus Down time op voor schrijf-acties.

“Master”-“Master” setup

ACID

Een term die bij databases gebruik wordt is ACID (Atomicity, Consistency, Isolation & Durability). Dit zijn kenmerken van een database waarmee de juistheid en compleetheid van data gegarandeerd wordt. Het 'Atomicity" kenmerk stelt dat database bewerkingen ondeelbaar zijn en dus juist of helemaal niet doorgevoerd en opgeslagen worden. Het voorkomt dat bewerkingen half doorgevoerd worden en dat er data mist of corrupt raakt.

Een andere mogelijkheid is een “Master-Master” setup te bouwen. Hierbij kunnen beide “Master” databases schrijf-acties ontvangen en repliceren deze naar de andere “Master”. Er moet voorkomen worden dat records met hetzelfde record nummer geschreven worden. Daarom wordt gekozen de ene “Master” de “Even” inserts te laten doen en de andere “Master” de “On-even” inserts. Beide databases zijn met lokale performance te gebruiken – ook wanneer ze ver uit elkaar staan. Deze systematiek kan naar believen verder uitgebreid worden, bijvoorbeeld met een 3 “Master” setup (zie de figuur). De beschikbaarheid van de data gaat hiermee omhoog evenals de performance. Maar een “Drop Tabel” (verwijder tabel) wordt naar alle “Masters” gerepliceerd en dus is het geen DR.

Nog een laatste opmerking over de multi "Master" setup. Wanneer de databases ver van elkaar verwijderd zijn, is er sprake van een hogere lantency bij de replicatie. Beide databases kunnen lokaal met uitstekende performance gebruikt worden. Het is een goede setup voor active-active (of ook wel Multi Region) designs. replicatie kan hierbij "Achterlopen" (denk dan aan de RPO, zie sectie over RPO en RTO).

File based replicatie

In cloud omgevingen is het (op simpele wijze) repliceren van files een basis voorziening. Dit bestond al voor de cloud (Ceph bijvoorbeeld), maar de cloud heeft het wel populair gemaakt. Tegenwoordig weet iedereen wat een AWS S3 bucket is. Met file gebaseerde replicatie worden files op meerdere storage systemen (en vaak ook locaties) opgeslagen. Zodra een file verandert, wordt een volledig nieuwe versie van de file (of object) gemaakt, dit wordt ook wel “Copy-on-Write” genoemd. Het gevolg hiervan is dat als een file (of object) verandert, alle kopieën gelijk gemaakt moeten worden. Dit kost hierdoor tijd en daarmee spreek men wel over “Eventually Consistent” storage. De file (het object) kan van iedere locatie gelezen worden (nadat het consistent is geworden). Dit levert een hoge performance op. Versiebeheer is ook (relatief) eenvoudig, na een “Copy-on-Write” wordt de oude versie niet verwijderd.

Nadeel van het “Copy-on-Write” principe is dat wanneer slechts 1 bit van een file veranderd wordt, het gehele file opnieuw geschreven moet worden. Het opslaan van een database file op een object store (zoals S3) is dan ook niet efficiënt. Iedere record change leidt tot een nieuwe kopie van het complete database bestand. De performance hiervan is dan ook slecht, het is een zogenaamd “Anti-Pattern“. Gesteld kan worden dat object storage (file based replicatie) dus zowel de performance ten goede komt (in de juiste situaties, de “Patterns”) net als de beschikbaarheid (availbility). Het kan ook DR bieden, mits versiebeheer ingeschakeld is. Een laatste voordeel van een dergelijk storage techniek is dat het vrijwel onbeperkte schaalbaar is qua opslag capaciteit. Het is buitengewoon krachtig in z’n eenvoud.

Maar kan een object storage file systeem gekoppeld (gemount) worden?

Block gebaseerde file systemen kunnen gekoppeld (gemount) worden "In" of "Aan" een computer. Het wordt daarmee gezien als lokale storage ook al is het dat niet. Dit is niet gebruikelijk met object storage. Het heeft een Application Programming Interface (API) die gebruikt kan worden. Lees, schrijf, create en delete acties kunnen middels deze API uitgevoerd worden. Toch is het - als je dat echt wil - wel mogelijk een object store te koppelen (mounten). De performance van een dergelijk oplossing is laag vooral vanwege het "Copy-on-Write" principe. De object store gedraagt zich fundamenteel anders dan lokale storage en dat heeft niet veel toepassingen (Patterns).

RTO en RPO

Bij het design van een omgeving wordt vast gesteld welke RTO en RPO behaald moeten worden. De Recovery Point Objective (RPO) is het maximale data verlies dat een omgeving mag hebben. Recovery Time Objective (RTO) is feitelijk de maximale down time, maar je kan het ook zien als de beschikbaarheid van de omgeving. Deze waarden worden vaak tijdens een Business Impact Analyse (BIA) vast gesteld.

De RTO wordt bereikt door alle maatregelen die getroffen zijn om de beschikbaarheid te kunnen garanderen of te herstellen. De RPO wordt vooral bepaald door de latency van de data replicatie en de backup / restore (DR). Maar wanneer er een netwerk storing optreedt voordat data volledig gerepliceerd is, hoeveel data is dan verloren gegaan? Welke hoeveelheid dataverlies is eigenlijk acceptabel? RPO is dus een complex onderwerp, want hoe weet je welke data nog wel gerepliceerd is tijdens een storing en welke niet? Hoe bepaal je welke van de twee zijdes de correcte data bevat als ze niet meer in sync zijn? Dit wordt ook wel de data “GAP” genoemd. Hiermee raken we aan het onderwerp van synchrone en a-synchrone data replicatie. Meer hierover in de sectie “Timing”.

Welke data is nu correct nadat we een replicatie storing hebben gehad? Met een database kan de "Time Stamp" gebruik worden. Het laatste correct weggeschreven record is de laatste data die goed is, alles daarna is fout. Voorwaarde hiervoor is dat beiden kanten de correcte tijd hebben. Bij Block gebaseerde replicatie wordt iets gebruikt dat "Fencing" genoemd wordt. "Fencing" wordt gebruikt om te bepalen welke (storage) zijde de waarheid bevat.

En backup dan?

Je kan je – terecht – afvragen of backup / restore een data replicatie techniek is. Dat is vast een discussie waard. In de meeste gevallen wordt een backup / restore echter niet gezien als een replicatie techniek. Een backup / restore gaat eerder over retentie en recovery. Het maakt een “point-in-Time” kopie van data (inclusief fouten). Data replicatie is eerder een techniek die gebruikt wordt om “Business Continuity” te garanderen. Verwarrend is dat object storage ook gebruikt kan worden voor de opslag van backups. Het is hoog beschikbaar en ondersteund versiebeheer. Deze discussie is lastig te beslechten. Cruciaal is dan ook het antwoord te vinden op de vraag, “Wat moet er bereikt worden”?

En Off site backups dan?

Object store biedt goede opties voor het opslaan van backups. Want niet alleen ondersteund het versiebeheer, het geeft ook de mogelijkheid om van andere regio's gebruik te maken. Hiermee komen we dicht bij het idee van off site backups.

Granulariteit

De 3 replicatie technologieën hebben allen hun voor- en nadelen, hun “Patterns & anti-Patterns”. Een groot verschil tussen deze technieken is wel de granulatriteit. De kleinste replicatie eenheid is block based replicatie. Het gaat dan bijvoorbeeld om blokken van 4 kilobytes. Records zijn meestal veel groter en files zijn vaak nog vele malen groter.

In overzicht:

TypeData eenheidUse casePerformance
Block4 KB – 64 KB blocksSAN’s, virtuele servers, RAIDHoogste (lage over head)
RecordIndividuele database rijenSQL / NonSQL databasesHoge performance (selectief)
FileGehele files / objectenCloud opslag (S3 bijvoorbeeld), backupsverieert, (Copy-on-Write)

Toplogie

Het artikel raakte eerder al aan “One-way” replicatie en “Two-way” replicatie. Dit wordt ook wel de topologie van de replicatie genoemd.

Deduplicatie

Wanneer de opslag van files geanalyseerd wordt dan valt op dat vaak dezelfde bestanden / files vaker opgeslagen worden. Dat is jammer, want met replicatie worden toch al meerdere kopieën bewaard. Kopieën van kopieën is onnodig en kostbaar. Sommige opslagsystemen halen deze dubbelingen eruit zonder dat je dat als eindgebruiker merkt. Dit wordt deducplicatie genoemd. Deduplicatie bespaard opslag capaciteit en dus kosten.

Compressie

Als toevoeging op deduplicatie kunnen data en files ook gecomprimeerd worden. Hierbij maken we bestanden / files kleiner door middel van compressie en besparen zo op opslag capaciteit. Het grootse voordeel wordt behaald wanneer zowel deduplicatie als compressie gecombineerd worden. Beiden vragen echter ook rekenkracht (overhead) en voegen dus (al is het theoretisch) latency toe.

Encryptie

Een onderwerp dat regelmatig langs komt is encryptie. De meeste cloud provider / hypescalers bieden dit “Out of the Box” aan. Dit kan toegepast worden op lokale (block) gebaseerde opslag, op databases en op object gebaseerde opslag. Het is een goed idee om encryptie toe te passen, het is makkelijk en kost vrijwel niets. Het beschermt je echter niet tegen de cloud provide / hyperscaler zelf. Zij kunnen gewoon bij de encryptie sleutels. Moet dat voorkomen worden, dan zal een bedrijf of organisatie zelf haar encryptie sleutels moeten beheren. Dat is te doen, maar integreert niet zo fijn in de cloud omgeving. Bijvoorbeeld met een Hardware Security Module (HSM). Dit beschermt dan wel tegen de cloud provider / hypescaler en tegen informatie verzoeken van overheden en geheime diensten. Het is dus belangrijk in de discussie rond Data Sovereignty. Deze encryptie van opgeslagen data wordt ook wel encryptie van “Data at Rest” genoemd. Naast encryptie van “Data at Rest” kennen we encryptie van “Data in Transfer“, het netwerkverkeer. Beiden zijn encryptie, beiden beschermen tegen andere risico’s.

Caching

Een onderwerp dat hier genoemd wordt worden is caching. Caching - in het algemeen - is de benadering waarbij veel gevraagde data op snelle disk (SSD), memory of geografisch dichtbij wordt geplaatst. Hierdoor kan deze data heel snel aangeleverd worden. Ook operating systemen zoals Linux, OSX en Windows kennen zoiets. Databases kennen ook cache. Hiermee kunnen veel opgevraagde records snel verstuurd worden. Bijvoorbeeld handig voor sessie informatie die veelvuldig gevraagd wordt. Cache is een data replicatie onderwerp om dat het enerzijds replicatie kan versnellen en anderzijds replicatie kan verstoren. Hier wijden we niet verder uit over dit onderwerp, maar je gaat dan bijvoorbeeld in op onderwerpen als "Cache hits", "Cache misses" en "Flushing Cache".

Timing

Een ander interessant aspect van data replicatie moet nog in meer dertail besproken worden. De tijdsvertraging (latency). Dit is van belang bij replicatie. Dit kwam eerder aan bod bij de RTO en RPO. De fysieke afstand tussen de storage die we repliceren bepaalt welke tijd er nodig is om die data te repliceren. Pas wanneer data aan beide kanten compleet is weggeschreven is de data veilig. Wanneer de afstand groot is begint dit een rol te spelen. Bij synchrone replicatie wordt pas een bevestiging gegeven als beide zijden geschreven hebben. Vanwege de afstand moet een eindgebruiker dan langer wachten. Bij echt grote afstanden kan dit vervolgens een probleem worden. Er kan dan beter gekozen worden voor asynchrone replicatie. Hierbij kan de eindgebruiker verder wanneer de data lokaal is weggeschreven. Daarna wordt de data nog gerepliceerd. Dit is goed nieuws voor de performance, maar minder goed voor data veiligheid. Want het kan dus voorkomen dat de data nog niet volledig is gerepliceerd en er zich een verstoring voordoet. De storage is dan niet meer hetzelfde. Welke zijde heeft nu gelijk als er bidirectonele replicatie toegepast werd? Hier zijn natuurlijk wel oplossingen voor, maar die vallen buiten de scope van dit artikel.

Data Soverignty

En waarom was dit allemaal zo belangrijk voor Data Sovereignty? In het licht van de Data Sovereignty zouden bedrijven en organisaties kunnen overwegen data op meerder plekken op te slaan. Bijvoorbeeld om zeker te zijn van de (geo)locatie van de data (Data Residiency). Ook bieden verschillende technieken de mogelijkheid tot DR van data. Dit is iets dat Data Sovereignty zeker raakt. De beschreven technieken zijn dus van belang om dergelijke doelstellingen te verwezenlijken. En omdat geen enkele techniek alle problemen oplost en situaties van elkaar verschillen, zijn alle technieken zinvol om kennis van te hebben en ze “Meester” te zijn. Misschien dat zelf een combinatie van technieken gebruik kan / moet worden.

Hoewel het geen replicatie technologie betreft, moet open source software (OSS) hier toch genoemd worden. Omdat Data Sovereignty gaat om in “Control” te komen van data, heeft de software die gebruikt wordt daar een grote impact op. De beste manier om controle te behouden (of opnieuw te verkrijgen) is controle te behouden over de software die gebruikt wordt. OSS is dan de beste keuze die gemaakt kan worden. Interessant detail is overigens dat alle cloud provider / hyperscalers gebruik maken van OSS. Soms gaan ze zo ver om OSS een nieuwe naam te geven en het als een eigen product in de markt te zetten. Dat is overigens legaal. Zelfs al wordt de hernoemde versie gebruikt, men kan altijd terug naar de OSS variant en daarmee blijft data toegankelijk.

Nog een voordeel van het gebruik van OSS is dat het de beste garantie is om open standaarden te gebruiken. OSS kan niet anders dan open standaarden gebruiken en dat garandeert de toegankelijkheid tot de data.

Samenvattend kan gesteld worden dat het begrip van “Patterns and Anti-Patterns” en het beheersen van de technologeen van data replicatie hoogstwaarschijnlijk noodzakelijk zijn om Data Sovereignty te bereiken. Data Sovereignty is het mitigeren van geopolitieke risico’s in data opslag. Deze technieken gaan je daarbij helpen.

Waar niet over gesproken wordt bij Digital Sovereignty

Geef een reactie

Als je een beetje de onderwerpen in de media volgt, dan zal je gezien hebben dat de discussie rond Digital Sovereignty redelijk “Losgaat”. Ook op LikedIn is Digital Sovereignty een onderwerp dat veelvuldig voorbijkomt. Veel van mijn vakbroeders zijn hiermee bezig – logish – want klanten zijn ermee bezig. Daar vinden deze discussies plaats en als gevolg daarvan worden we als IT consultancy bedrijf daarin betrokken. Veel consultancy bedrijven hebben ook al een Digital Sovereignty aanbod, net zoals mijn huidige werkgever. Maar ik vraag me serieus af, wie gaat er ook echt wat doen? Welk bedrijf gaat daadwerkelijk een punt zetten achter de afhankelijkheid van Amerikaanse tech? Maar nog belangrijker, welk aspect wordt vermeden?

Oke, waar hebben we het over?

Eerder schreef ik al een blog tekst over Digital Sovereignty. Hierin onderzocht ik wat goede definities zijn om te hanteren. De Europese Commissie heeft daar een prima startpunt voor. Dit “Cloud Sovereignty Framework” is zeer bruikbaar. De Europese comissie toont hier leiderschap naar mijn idee. De kern is dat Digital Sovereignty veel meer is dan alleen Data Sovereignty. Zoals Gartner aangeeft is er sprake van

  • Technologische Sovereignty,
  • Data Sovereignty,
  • Operationele Sovereignty

In de meeste organisaties wordt overigens alleen gesproken over Data Sovereignty. Dat bleek tijdens twee rondetafelgesprekken die ik mocht leiden. Daarmee wordt voorbij gegaan aan het moeilijkste deel, namelijk de afhankelijkheid van US tech, zowel hardware als software. Het onderwerp Data Sovereignty rechtvaardigt een eigen blog tekst denk ik.

Wat me overigens ook verbaast is dat dit blijkbaar gezien wordt als drie ongerelateerde onderwerpen. Volgens mij kan je geen Data Sovereignty behalen als je technologisch afhankelijk bent. Even zo goed is Operation Sovereignty een illusie als je Data Sovereignty niet op orde hebt. Ik vermoed steeds meer dat alles draait om de Technological Sovereignty, de afhankelijkheid van US tech. En ja, dat gaat zowel over hardware als software.

Wat leerde ik tijdens de rondetafelgesprekken?

Een telecom provider uit een noordelijk land gaf aan dat ze bij een invasie ook hun data terug uit een cloud willen kunnen krijgen. Dit aspect had ik eerder niet overwogen. De vraag die onmiddellijk bij mij op kwam was, en dan heb je je data terug hoe weet je dan dat het uit de cloud is verwijderd? Kan je dat eigenlijk wel bepalen?

Risc mitigation

Vanuit een architectuur standpunt bekeken gaat deze gehele discussie over risico mitigatie. Dat deden we altijd al, maar er is een geopolitiek risico bij gekomen. Namelijk, de afhankelijkheid van Amerikaanse tech. Nederland is volledig afhankelijk van Microsoft Office bijvoorbeeld. Ik kan geen opdracht doen zonder hiermee in aanraking te komen. Probeer het als professional maar eens te vermijden, succes. Overigens de alternatieven zijn ook allemaal uit de US afkomstig. Zelf gebruik ik Apple hardware, Google, Microsoft en AWS. Deze risico spreiding heeft dan ook een zwak punt, het is allemaal US tech.

Uitzondering hierop is mijn oude Macbook met Ubuntu. Welliswaar is de hardware op Amerikaanse tech gebaseerd, maar de software niet. Ook mijn Proton-account is redelijk vrij van Amerikaanse tech. Maar van mijn werkgever mag ik het allemaal niet gebruiken. Het is niet veilig en niet managed. Dit in tegenstelling tot mijn Windows laptop die volledig dichtgetimmerd is. Deze is wel als veilig beschouwd, ookal zijn de keys van Bitlocker inmiddels aan de FBI overhandigd.

Maar zoals gezegd, risicomitigatie dus. Vanuit architectuurstandpunt bezien vraag ik me dan af, welk geopolitiek risico wil je precies mitigeren? We zijn altijd wel ergens afhankelijk, maar ben je vrij om de afhakelijkheid te kiezen? Of accepteer je een afhankelijkheid omdat je niet door de pijn wil om daarvan af te raken? Ik heb het wel eens vergeleken met drugs, je moet cold turkey gaan om ervan af te komen. Maar dan heb je wel je vrijheid herwonnen.

Hardware en software afhankelijkheden

Mij lijkt het erg lastig om alternatieven voor US based hardware te vinden. Ze zijn er wel, o.a. mijn werkgever komt met eigen computer chips. De afhankelijkheid van US based hardware heeft daarnaast overigens ook een pikant detail. De machines om die chips te fabriceren komt uit Nederland. Anyways, ik zie dit toch niet zo snel veranderen.

Op het software vlak is meer eer te behalen. Er zijn veel Open Source alternatieven te vinden voor US based software. Ik ga geen lijst van alternatieven maken, die is er al. De alternatieven zijn misschien niet zo mooi en vereisen gewenning. Functioneel is het wel. Je blijft hiermee baas over de functionaliteit en de beschikbaarheid daarvan. Operational Sovereignty dus. En met Open Source software komen ook open standaarden. Deze open standaarden maken dat je baas blijft over eigen data. Een belangrijk deel van Data Sovereignty dus. Naar mijn idee kan je met Open Source software twee vliegen in een klap slaan.

Wel is er voldoende kennis en ervaring nodig om Open Source software succesvol te implementeren. Je wordt niet bij de hand genomen, er moet veel zelf uitgezocht worden. Het raakt hiermee aan de capabilities van de IT organisatie. Ik schreef er eerder over, maar ook dit onderwerp verdient een eigen blog tekst.

En hier hebben we het dus niet over

Opnieuw zien we dus nut van Open Source software. En daar wordt niet, of nauwelijks over gesproken. Opnieuw wel bij de Europese Commissie. Zij wil de commerciele Open Source software stimuleren. Verschillende organisaties werken aan alternatieven voor hun US based software. Frankrijk kiest bijvoorbeeld voor een alternatief voor Zoom. En opnieuw gaat het dus niet om kosten. Bedrijven zijn prima bereid te betalen voor software. Het gaat om de vrijheid om zelf keuzes te kunnen maken.

Voor mij is het een “Trip down memory lane”. Ik was destijds betrokken bij het Antonius Open project. Hier probeerde het St. Antonius ziekenhuis in Utrecht / Nieuwegein Open Source software te introduceren in haar IT landschap. We hebben veel weerstand ondervonden, maar technisch kon het allemaal wel. Inmiddels zijn we jaren verder en misschien is onze motivatie nu sterker?

De business logica van een IT afdeling

Geef een reactie

Al jaren doe ik werk voor IT afdelingen van bedrijven, in voorkomende gevallen zelfs IT organisaties genoemd. Soms als interne collega maar meestal als externe consultant. Als mij jaren geleden gevraagd was wat IT afdelingen doen, dan had ik waarschijnlijk gezegd “Die doen IT”. Inmiddels weet ik beter, ik heb eens goed nagedacht over deze overduidelijk simpele vraag en het resultaat wil ik graag met jullie delen. Het beantwoorden van een overduidelijk simpele vraag geeft soms toch bijzondere inzichten.

Het resultaat was voor mij erg verhelderend. Ik begrijp nu de vier hoofdtaken van IT afdelingen; “Maintenance” – het beschikbaar houden van bestaande functies, “Projects” – het verwerven van nieuwe functies, “What’s on the Radar” – welke ontwikkelingen worden belangrijk en “Decommisioning” – het afvoeren van verouderde technologie, systemen en applicaties. Dit is dan ook wat alle IT afdelingen gemeenschappelijk hebben. In zekere zin lijken ze dus op elkaar, in ieder geval qua generieke uitdaging. Maar hoe omschrijf je dan het nut van IT afdelingen voor de organisatie?

Acceleration

Ja, wat doet een IT afdeling voor het bedrijf waar zij deel van uit maakt? En dan met name vanuit een business perspectief gezien? Aanvankelijk was mijn eerste serieuze suggestie, “De IT afdeling ondersteunt de business”. Vluchtig bekeken lijkt dat zinvol, maar “Ondersteunen” is wel passief. Mijn tweede gedachte was daarom ook “De IT afdeling versnelt de business”. Dat was veel beter, want het geeft aan waar het nut van de afdeling zit.

Ik heb eerder geschreven over versnelling, dus deze gedachte is geen grote verrassing. Maar overweeg het omgekeerde, stel dat de IT afdeling de business vertraagt, zou de organisatie er dan wel geld aan willen uitgeven? Zeg nu zelf, dat doet geen enkele organisatie. Dan gaat het dus om versnelling. En dan met versnellen bedoel ik dan dingen sneller doen, ze beter doen, tegen lagere kosten, minder complexiteit en met minder fouten. Dat is toch wel wat organisaties van IT verwachten? Gecombineerd met de vier generieke taken van de IT afdeling, ontstaat er het volgende beeld.

Maintenance

Het overgrote deel van de inspanning van een IT afdeling betreft “Maintenance”. Het beschikbaar houden van bestaande functionaliteiten. Er wordt geen nieuwe functionaliteit geïntroduceerd, maar men behoudt wat er is. Vergelijk het met onderhoud aan een auto. Je verwacht dat na het onderhoud alles weer optimaal functioneert, maar niet dat er ineens een autoradio is toegevoegd. Deze “Maintenance” functie van de IT afdeling doet ze liefst zo efficiënt en kosteneffectief mogelijk. Er wordt tenslotte niets nieuws gemaakt. Je zou dit kunnen vergelijken met het behouden van een bepaald niveau, een plafond zo je wil. Het “Plafond” is het maximaal haalbare, je kan het alleen slechter doen. Daarom is de kern bij “Maintenance”, “Efficiëntie”.

Projects

Een andere belangrijke taak van een IT afdeling is in mijn ogen “Projects”. Nieuwe functionaliteit wordt namelijk in projecten gerealiseerd. Dus waar het bij “Maintenance” gaat om het bereiken van het “Plafond” (en het dus om “Efficiëntie” draait), gaat het hier om het verhogen van het “Plafond” en de kern is dan “Effectiviteit”. Waarom? Nou, natuurlijk willen we projecten graag op tijd en binnen budget afgerond hebben, maar als ze geen waarde toevoegen (ze de organisatie niet versnellen), dan is het alsnog verspilde moeite. Bijvoorbeeld, een project dat later dan afgesproken wordt opgeleverd en misschien duurder was dan gebudgetteerd, maar wel de organisatie versneld, heeft toch waarde. “Effectiviteit” is daarom belangrijker dan “Efficientie”. In het voorbeeld van de auto zou je bijvoorbeeld kunnen denken aan het monteren van een trekhaak. Dat heeft niets met onderhoud te maken maar realiseert een nieuwe functie – het kunnen trekken van een aanhanger.

On the Radar

De derde functie van een IT afdeling is wat ik “What’s on the Horizon” of “What’s on the Radar” noem. Dat zijn onderwerpen waar de IT afdeling in de toekomst mogelijk iets mee moet. Dat kunnen nieuwe technologieën zijn, bedrijfsveranderingen zoals overnames of veranderende wet- en regelgeving. Deze taak kent twee uitdagingen. De eerste is, kunnen we succesvol vaststellen of een onderwerp belangrijk wordt voor de organisatie? We kunnen bijvoorbeeld denken dat een onderwerp belangrijk gaat worden, maar achteraf gezien is dat niet het geval (type 1 error), of we denken dat een onderwerp niet belangrijk is, maar achteraf gezien is dat toch wel zo (type 2 error). Als we deze twee soorten fouten hebben kunnen voorkomen, dan hebben we nog een volgende “Hobbel” te nemen.

Deze “Hobbel” is wat de Eisenhouwer Matrix genoemd wordt. Deze matrix kent twee dimensies, “Belangrijk” versus “Urgentie”. Dit leidt dan tot 4 combinaties. Is een onderwerp eenmaal relevant bevonden (dus geen type 1 of een type 2 error), is de vraag of we die op de roadmap kunnen krijgen? Meestal krijgen onderwerpen die urgentie hebben voorrang, ongeacht of ze belangrijk zijn. Onderwerpen die geen urgentie hebben, maar wel belangrijk zijn worden uitgesteld. In het voorbeeld van de auto zien we bijvoorbeeld aankomen dat elektrisch rijden de toekomst is. We willen ons daarop voorbereiden. Zo kunnen we dan besluiten alvast laadpalen te plaatsten nog voordat iedereen elektrisch rijdt. Dat is belangrijk. Wachten we tot de elektrische auto’s rond rijden, dan zijn we te laat met het plaatsen van de laadpalen.

Deze “On the Radar” functie van de IT afdeling is erg lastig uit te voeren vanwege de genoemde uitdagingen. De kern is “Relevantie”. Het correct bepalen van relevante onderwerpen is de sleutel tot succes.

Decommisioning

De laatste functie bij een IT afdeling is “Decommisioning” van oude technologie en applicaties. Waarom is dit een belangrijke functie? Oude technologie en applicaties vragen veel onderhoudswerk en vragen dus een onevenredig groot deel van het budget. Bovendien heeft oude / verouderde technologie vaak security issues die veel werk vragen en afbreukrisico kennen. Het is daarom verstandig oude technologie af te voeren zodra dat kan. Niet te vroeg, want dat schaad de organisatie, maar zeker ook niet te laat. Kortom, de kern van deze functie is dan ook “tijdigheid”. In het voorbeeld van de auto kunnen we denken aan het afvoeren (verkopen) van een brandstof auto omdat elektrisch rijden de toekomst heeft.

Als je dit leest vraag je je waarschijnlijk af hoe deze vier functies zich tot elkaar verhouden voor wat betreft het percentage inspanning. Dat vroeg ik me ook af. Grok heeft me hier even geholpen, 

- onderhoud 55% tot 70%, 
- projecten 15% tot 25%, 
- on the Radar 10% tot 20% en het 
- afvoeren van oude technologie 3% tot 10%

Hier zie je overigens gelijk nog een reden waarom het bij "Maintenance" om "Efficientie" gaat. Het is verreweg de functie die de meeste inspanning vergt. Een  efficientieslag hier levert het meeste op.

In de praktijk zal “Decommisioning” een project zijn, of onderdeel zijn van een groter project. Als een applicatie bijvoorbeeld vervangen wordt, is het logisch het afvoeren van de oude applicatie daar als laatste stap aan toe te voegen.

“Maintenance” legt “Projects” beperkingen op

Nu de basisfuncties van de IT afdeling geïdentificeerd zijn, kunnen we het model “Testen”. Kunnen we er wat mee? Geeft het ons inzicht? Het eerste dat opvalt is dat de resultaten van de projecten eindigen bij “Maintenance”. Dus, hoe sneller / succesvoller we projectresultaten opleveren, hoe meer onderhoudswerk er te doen is. Dus gaat er meer budget naar “Maintenance”. En als gevolg hiervan kunnen we dan weer minder projecten doen. Er is dus een negatieve feedback loop tussen “Maintenance” en “Projects”. Dat is een interessant inzicht.

De vier hoofdtaken kennen een soort "Flow". Items "On the Radar" worden een keer een project. Het resultaat daarvan komt bij "Maintenance" terecht en na verloop van jaren worden die opgeruimd ("Decommissioning"). Feitelijk is dit een "Product Life Cycle".

Budget invloeden

Veel IT afdelingen hebben tegenwoordig te maken met budgetbeperkingen. Soms worden budgetten “Bevroren” of zelfs kleiner. Het is dan de vraag hoe kan er dan ruimte gemaakt worden voor projecten – want het versnellen van de business blijft nodig. Ik zie hier een paar mogelijkheden.


De eerste optie is het budget toch opgehoogd te krijgen. Soms lukt dat, als de business case goed is of wanneer het zakelijk belang dermate groot is dat het verantwoord is.

Een alternatief is bijvoorbeeld projecten te schrappen of later uit te voeren. Dit is een relatief makkelijk oplossing waarvoor vaak gekozen wordt. Het probleem hiermee is, we versnellen de organisatie niet. Dat gaat maar een tijdje goed. Maar zodra we een concurrentie achterstand gaan ervaren, zijn we te laat. Het is dan ook een tijdelijke oplossing. Er is nog een factor die dit onderstreept. Beheercontracten zijn altijd langerlopende contracten. Deze zijn lastig of niet voortijdige te beëindigen. Dat is waarom als eerste op projecten bezuinigd wordt.


Een andere en logische optie is “Maintenance” efficiënter uit te voeren. Dit maakt budget vrij voor projecten. Dit is daarom de onderbouwing waarom de “Efficiëncy” de kern is van “Maintenance”. IT-onderwerpen die betrekking hebben op efficiëntieverbeteringen, betreffen daarom altijd de onderhoudsfunctie van de IT afdeling.


Als laatste mogelijkheid zie ik het afvoeren van oude technologie, applicaties en technische schuld (“Decommisioning”). Dit verlaagd de onderhoudsinspanning en dus het beslag op het budget.

DevOps?

Veel bedrijven werken vandaag volgens de DevOps aanpak waarbij het team zowel verantwoordelijk is voor software development als het beheer ervan. Dit wordt ook wel aangeduid als "You build it, you run it". Is dit dan strijdig met wat hierboven beschreven is? Nee, het zijn twee taken die bij hetzelde team belegd zijn. Het development werk is feitelijk een doorlopend project, of meerdere kleine projecten (we noemen dit vaak "Sprints"). Voor het beheerwerk ("Maintenance") geldt ook hier dat het zo efficient mogelijk gedaan moet worden. Beheerwerk gaat letterlijk ten kosten van development uren. Een groot voordeel van DevOps is dat dezelfde mensen de beheer consquenties voelen van hun development werk. DevOps vergroot dan ook de kans op slim software ontwikkelen met een minimale beheer impact. En dat is wenselijk.

En security dan?

Kan dit model ons helpen inzicht te krijgen in het onderwerp security? De meeste security onderwerpen hebben betrekking op “Maintenance”. Want zowel de inspanning om de security op peil te houden, maar ook veel van de werkzaamheden als gevolg van security incidenten doen een beroep op (het budget van) “Maintenance”. Security is daarom voornamelijk een “Maintenance” aangelegenheid. Er is wel een uitzondering. Want wat zou security in projecten kunnen zijn? Dan heb je het over “Secure by design”. En dat is slim omdat het security level, na oplevering (en dus tijdens “Maintenance”) makkelijker op peil te houden is. Minder werk en dus minder kosten. Het heeft daarom zeker nut security als specifiek onderwerp in een project mee te nemen. Hetzelfde geldt voor “Decommisioning”. Waarom ontwerpen we systemen in de projectfase niet zo dat zij met minimale inspanning afgevoerd kunnen worden. Een soort exit strategie van de applicatie.

Technical Debt

Ik heb vaak bij klanten gezien dat verouderde applicaties en technologie problemen gaven. Er moest extra veel tijd in “maintenance” gestoken worden en soms kon de applicatie zelfs niet meer goed onderhouden worden. Dat kwam bijvoorbeeld doordat upgrades onmogelijk geworden waren. Dat laatste is een bron van security problemen. Kortom, technische schuld geeft ellende, vertraagt en doet een te groot beslag op het budget. De vraag is dan natuurlijk, hoe voorkom ik dat ik vandaag de technische schuld van morgen creëer? En net als bij security ligt het antwoord bij de projecten die je doet. Kan je projecten (en technisch ontwerpen) zo maken dat je toekomstige technische schuld – by design – beperkt? Ik denk het wel. Bijvoorbeeld door alle handmatige werkzaamheden te voorkomen en door de onderhoudbaarheid van applicaties als ontwerpcriterium mee te nemen.

Een goede “Design” vraag is dan ook, kan mijn applicatie onderhouden worden als ik die straks opgelever? En wat hebben mijn collega’s dan nodig om dat efficiënt te kunnen doen? En dat betekent vandaag nadenken over de onderhouds uitdagingen van morgen. Ik kan je verzekeren dat die te maken hebben met efficiëntie.

De overduidelijk simpele vraag

Als je nog steeds leest dan hoop ik dat het beantwoorden van deze overduidelijk simpele vraag ook voor jou verhelderend is. Voor mij is de (business) werking van een IT afdeling nu veel logischer. Ik begrijp nu hoe en waarom groepen van werkzaamheden zijn zoals die zijn en hoe ze elkaar beïnvloeden. Dat we een “Product Life Cycle” achtige “Flow” zien in de taken. Met een paar voorbeelden heb ik geprobeerd het model te “Toetsen” zo je wil. Door te zien of het ons inzicht verschaft en dat doet het naar mijn idee. Er zijn vast meer voorbeelden te bedenken. Het model staat, doe er je voordeel mee.