Category Archives: Open Source Software

Waar niet over gesproken wordt bij Digital Sovereignty

Leave a reply

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?

Het pad naar Digital Sovereignty

1 Reply

Een van de onderwerpen waarover ik de laatste tijd veel nadenk is “Digital Sovereignty”. Het afgelopen jaar is er veel veranderd in het geopolitieke speelveld, ik denk dan aan de Amerikaanse politiek, de verhouding van het westen met China en de oorlog in Oekraïne. Inmiddels is dit onderwerp bij de IT consultancy bedrijven aan beland, onze klanten vragen hiernaar.

Het onderwerp “Digital Sovereignty” lijkt een veelkoppig monster omdat je er verschillende perspectieven op kan hebben. Je kan het benaderen vanuit een bedrijfsvoering perspectief, namelijk kan ik mijn bedrijf operationeel houden? Je kan ook focus hebben op de data, waar verblijft deze? Of je kijkt naar de geldende wetgeving, is de Amerikaanse Patriot act van kracht, of is de Europese wetgeving leidend? Als laatste is er het technische perspectief, welke technische maatregelen kan of moet ik treffen? Na studie (o.a. het AWS perspectief middels een online cursus), discussie met klanten en collega’s, cloud leveranciers white papers en – niet geheel onbelangrijk – er goed over nadenken, is het volgende mijn kijk op de zaak.

Eerst studeren dan maar

De externe bronnen die ik als eerste heb geraadpleegd zijn bijvoorbeeld Gartner, wat is hun kijk op deze materie. Maar ook AWS, Microsoft en Oracle hebben aanbod op dit onderwerp. Erg nuttig vond ik zelf informatie van de Europese Commissie zelf. Zo kan je online het “Cloud Sovereignty Framework” document vinden met daarin verschillende perspectieven op dit onderwerp. Zo kijkt zij naar de “Sovereignty Objectives”, de “Sovereignty Effective Assurance Levels” en “Assessment of Sovereignty Effectiveness”. Als laatste biedt zij een rekenmodel voor een “Sovereignty Score”. Dit laatste heeft vooral betrekking op aanbestedingen.

Voor mijzelf is het technisch / IT perspectief interessanter. Wat kunnen  / moeten we doen voor onze digitale soevereiniteit? En als je er goed over nadenkt, dan hebben die maatregelen veel weg van de maatregelen die we treffen bij security-onderwerpen. Die moet ik als cloud architect (of security architect) vaak meenemen in ontwerpen en adviezen. Het gaat dan om het mitigeren van (security) risico’s. In dit geval risico’s van geopolitieke aard, maar ook die leiden tot technische maatregelen. Dus is het dan gewoon “Risk management”?

Centraal bij security risico’s is dat je als bedrijf “In control” blijft. In control van wie er toegang hebben tot data, in control van wie er gebruik maken van ons netwerk en zo verder. Waarom wil je als bedrijf “In control” zijn? Dat is om zeker te kunnen stellen dat de bedrijfsvoering doorgang kan vinden. De bedrijfsvoering vraagt (vaak) dat de IT weerstand kan bieden aan verstoringen van welke aard dan ook (“Resilience”). Daarbij wil een bedrijf of organisatie in staat blijven veranderingen in de IT aan te kunnen brengen, bijvoorbeeld als de bedrijfsvoering daarom vraagt, of wanneer wet- en regelgeving verandert.

IT capabilities

Vanuit een IT architectuur bezien gaat het wat mij betreft vooral over “IT Capabilities” – kennis, kunde en verworvenheden. Als de “IT capabilities” toenemen, is men steeds beter in staat verstoringen te weerstaan en keuzes te maken die bij de bedrijfsontwikkeling passen. Op welke zaken heeft dit dan betrekking? Wat mij betreft zie ik (minimaal) de volgende onderwerpen waarbij je “In control” moet blijven:

  • software development
  • security
  • scalability
  • availability
  • licenses
  • hardware
  • (geo) locatie van data en
  • vendoren

Ik zie eigenlijk een soort denkbeeldige ladder waarbij je omhoog klimt en steeds meer “IT capabilities’ verwerft. Helemaal onderaan de ladder is een situatie waarbij er sprake is van “Technical debt”. Er worden verouderde software en platformen gebruikt, men is niet goed in staat aan de eigen software verder te ontwikkelen, er zijn in toenemende mate security risico’s. Er is veel handwerk. En er worden proprietary software en licenties gebruikt – waarvan men moeilijk af raakt. Eigenlijk is men niet in staat enig risico te mitigeren.

Applicatie modernisatie, de eerste stap

Hierna volgt de reis van de applicatie modernisatie. Platformen worden vernieuwd (zowel hardware als software) en met behulp van moderne software development tools kan de ontwikkeling van de eigen software weer gestart worden. Er kunnen nu weer keuzes gemaakt worden, men kan operationele uitdagingen mitigeren, bijvoorbeeld op het gebied van availability, resilience, licenties en security. Men neemt voorzichtige eerste stappen met het automatiseren van IT processen, installaties en configuraties.

Digital Sovereignty “ready”

In het volgende “Plateau” is de mate van automatisering groter zodat dat men in staat is om “Workloads” op verschillende (cloud) platformen te draaien. Er komt grip op de data residency (waar staat mijn data) en zaken als hoge beschikbaarheid (multi site) kunnen gerealiseerd worden. Ook krijgt men meer grip op leveranciers, er kunnen tenslotte keuzes gemaakt worden en veelal gaat men nu Open Source Software (OSS) gebruiken. De risico’s die nu gemitigeerd kunnen worden zijn van tactische aard. Eigenlijk is het bedrijf klaar om “Digital Sovereignty” te bereiken als dat gewenst zou zijn.

Strategische controle

Naar mijn idee is het hoogste “Plateau” een niveau waarin de organisatie grip heeft op alle “IT capabilities” die er zijn. Men kiest voor Open Source Software (en containers bijvoorbeeld) waar men dat wil en waar men vrijwillig kiest voor afhankelijkheden waar mogelijk. Men is daarbij in “Control of data residency”. Eigenlijk heeft men de functionaliteit losgekoppeld van de technische implementatie. Hierdoor ontstaat ruimte om te kunnen manoeuvreren en de risico’s die daarbij dus gemitigeerd kunnen worden zijn van strategische aard.

Voor mij gaat “Digital Sovereignty” dus om het beklimmen van de “Ladder” van “IT capabilities”. Bedrijven en organisaties die hoger op deze “Ladder” staan zullen dus beter in staat zijn de “Digital Sovereignty” te bereiken. Mijn suggestie daarbij is, laten we het een discussie maken over “IT capabilities”.

En hoe nu consultancy versnellen?

Leave a reply

In deze reeks over versnelling en complexiteit heb ik gekeken naar het “waarom” van versnelling & complexiteit en het “hoe” van kunnen versnellen. Wat werkt versnelling tegen (complexiteit) en wanneer is versnellen geen goed idee (persoonlijke aandacht). Verder heb ik belicht waarom proces kwaliteit bestaat (het versnelt ons) en welke rol standaardisatie en cloud hierbij kunnen spelen (dat versneld ons ook, mede door complexiteit te verlagen). Dit keer wil ik graag naar ons als IT professionals kijken. Moeten wij ook versnellen, waarom en hoe doen we dat dan?

Business as usual?

Als ons klanten willen versnellen – en die case is wel gemaakt denk ik – dan is de eerste vraag die IT professionals zich moeten stellen, “Kunnen we onze klanten daarbij helpen”? Mij lijkt dat IT instrumenteel is bij het versnellen van bedrijfs – en productieprocessen. Dus ja, daar kunnen we bij helpen. De producten en diensten die we leveren moeten daarom bovenal in staat zijn om onze klanten te helpen versnellen. Dat is ook vaak zo, denk aan Infrastructure as Code (IAC) waarmee we heel snel netwerken en servers kunnen bouwen. Ook kan je hierbij denken aan geautomatiseerde deployment van changes (CICD). Een klant wil vast geen technologie, dat is namelijk maar een middel, maar die wil iets bereiken, een website draaien bijvoorbeeld. Feitelijk wil men een business vraagstuk oplossen en geen nieuwe introduceren.

Low Code wel zinvol dan?

Naast onze klanten direct versnellen, kunnen we ook de complexiteit verlagen. Zoals ik eerder al betoogde is de gang naar de “Cloud” daar een aardig voorbeeld van. Door standaardisatie zijn we beter instaat te begrijpen wat we doen en kennen we de kwaliteit (en beperkingen) beter. Het is als puzzelen met hapklare brokken. Het gevolg is dat de klant dan kan versnellen.

Ook het gebruik van Low Code kan klanten versnellen, door (wellicht tijdelijk) de focus te leggen op de business en wat minder op technologie. In een later stadium kan dat weer anders worden. Misschien wil een bedrijf na verloop van tijd meer aandacht geven aan de technische implementatie. De juiste keuze helpt je dan te versnellen.

Vertragen levert toch meer uren op?

Als IT consultancy klanten helpt te versnellen, waarom zouden we dan zelf moeten versnellen? Dat lijkt contra intuïtief, want we verdienen ons geld aan uren, dus waarom dan sneller?

Als eerste denk ik dat als we relevant willen blijven en succesvol willen blijven concurreren met onze vakbroeders, we moeten versnellen. Ook lijkt mij dat als we onze klanten willen helpen versnellen – en dezelfde technieken gaan gebruiken – we daardoor zelf ook versnellen. En dat heeft alles te maken met het “Hoe” van het versnellen.

Hoe dan?

Zoals ik eerder betoogde, bestaat een kwaliteitsysteem om de snelheid te verhogen. Willen we IT consultancy versnellen, dan is “One Time Right” wel een goede aanpak. Waarom omarmen we in de IT dan het kwaliteitsdenken niet? Laten we een voorbeeld nemen aan Toyota. Door te standaardiseren kunnen we klanten sneller helpen, met voorspelbare resultaten, tegen voorspelbare kwaliteit en kosten. Naar mijn idee sluit dat aan bij wat klanten nodig hebben en willen.

Waarom heeft Max een pits stop?

Daarom lijkt mij dat we de IT consultancy business kunnen versnellen als we zorgen voor een hogere kwaliteit (certificeringen bijvoorbeeld), professionalisering en verdergaande standaardisatie. Klanten vragen niet meer om een “One off”, maar willen liever “Standaard” tegen een voorspelbare doorlooptijd en prijs. Het her-gebruik van software en standaardisatie middels het gebruik van “Standaard bouwblokken” ligt dan ook voor de hand. Dit is niet nieuw, maar wel heel actueel. Dus waarom heeft Max een pits stop nodig? Om daarna sneller te kunnen gaan!