MSF: gedeelde data, met behoud van autonomie

Artsen zonder Grenzen (Médecins Sans Frontières, MSF) verleent medische humanitaire hulp in zo'n 75 landen. De missies worden aangestuurd door vijf operationele centra, in Amsterdam, Brussel, Genève, Barcelona-Athene en Parijs. Elk centrum is onafhankelijk: het voert eigen projecten uit, stelt eigen prioriteiten, en heeft eigen ERP- en financiële systemen.

Die onafhankelijkheid is bewust, en ze werkt. Maar het betekent ook dat in één land meerdere MSF-teams naast elkaar kunnen werken, elk aangestuurd door een ander operationeel centrum, elk met eigen systemen, en geen van hen kan zien wat de anderen hebben.

Neem de voorraad. Een team dat malariatests tekortkomt, kon die in het buitenland bestellen en weken wachten, terwijl een ander MSF-team een paar uur verderop meer had dan nodig. Niet omdat niemand wilde delen, maar omdat de twee ERP-systemen niet met elkaar spraken, dus niemand het wist. Hetzelfde gold voor rapportage over de secties heen: handmatig, traag en vaak al verouderd zodra die af was.

Kies hieronder een team en een artikel, en vergelijk wat dat team vroeger kon zien met wat het ziet zodra de systemen verbonden zijn.

Wij verbonden de systemen van alle vijf hoofdkantoren in één intersectioneel datawarehouse op Azure Databricks. Eerst de ERP-systemen, daarna de financiële systemen en meer, elk geladen via kernpijplijnen die wij zelf ontwierpen en programmeerden, opgebouwd in lagen van ruwe data tot tabellen klaar voor gebruik.

Het hele platform werd uitgerold als infrastructure as code: elke werkruimte, elk cluster, elke rechtentoewijzing en pijplijn beschreven in code en elke keer op dezelfde manier uitgerold. Dat maakte het herhaalbaar, controleerbaar en, zoals u zult zien, makkelijk te kopiëren.

Het moeilijke deel was niet de systemen verbinden. Het was ze verbinden zonder de teams autonomie af te nemen. Eén centraal platform, eigendom van één groep, was eenvoudiger te bouwen geweest en onmogelijk te accepteren voor vijf onafhankelijke centra.

Dus bouwden wij een federatie. Een centrale werkruimte bevat de meeste gedeelde data. Elk team kan een sjabloon van ons nemen en binnen minuten een eigen Databricks-werkruimte uitrollen, die het volledig zelf beheert, en die via beheerde toegang verbonden is met de data in de centrale werkruimte. Dat loste ook de dataresidentie op: een werkruimte kan draaien in de regio die de wet voorschrijft, in de VS voor Amerikaanse data en in de EU voor Europese data, en toch met iedereen samenwerken. En het liet ruimte voor de eigen initiatieven en experimenten van elk team.

Rol hieronder een paar werkruimtes uit en zie hoe ze verbonden worden.

Een gedeeld platform is alleen nuttig als mensen kunnen vinden wat erop staat. Met de catalogus en zoekfunctie in Databricks is elke tabel geïndexeerd: iedereen kan zoeken naar de data die nodig is, zien wat erin staat en wie de eigenaar is, en toegang aanvragen.

Lineage deed de rest. Databricks legt vast hoe elke tabel uit de vorige is opgebouwd, dus als een getal niet klopt, ziet u in seconden waar het vandaan komt, en als een bron breekt, welke rapporten erdoor geraakt worden. Klik hieronder op een tabel of rapport.

Een federatie houdt alleen stand met heldere afspraken, dus ontwierpen wij de governancestructuur: wie eigenaar is van welke data, wie er toegang toe heeft, en welke rollen wat beslissen. Maar afspraken op papier bereiken geen logistiek medewerker in een veldproject in een afgelegen regio. Hoe weet iemand daar dat er een dashboard bestaat, wie daarvoor het aanspreekpunt is, en hoe die te bereiken is?

Ons antwoord was een decentraal ambassadeursmodel. In elke regio kozen wij goed verbonden mensen: bekend en vertrouwd bij de collega's die wij wilden bereiken, en voldoende thuis in de technische kant. Iedereen kon ons via hen bereiken, en wij konden via hen berichten naar iedereen sturen, als een web. Dat maakte communicatie veel makkelijker en het beheer veel eenvoudiger. Zet het model hieronder aan.

Elk operationeel centrum had eigen prioriteiten en wensen, en ze moesten allemaal gehoord worden. Wij introduceerden agile werken met een stakeholdermodel dat daarbij past: een roulerende zetel onder de dataleads van de centra. Elke drie maanden nam een andere datalead de zetel in en kon die de visie van het eigen centrum doordrukken, terwijl de anderen wisten dat hun beurt eraan kwam.

Zo bleven vijf onafhankelijke hoofdkantoren op één technische roadmap, zonder dat een van hen die bezat. Loop hieronder door de kwartalen.

De hoofdbouw werd in minder dan twee jaar opgeleverd. Het resultaat is één verenigde dataomgeving voor vijf hoofdkantoren en zo'n 75 landen, die de versnipperde rapportage per land vervangt. Land- en sectieteams behielden hun autonomie; de leiding kreeg voor het eerst een beeld over alle secties heen.

Het veranderde hoe mensen binnen MSF data vinden, bekijken en gebruiken. En het was een project van begin tot eind: architectuur, uitrol als infrastructure as code, data governance, stakeholdermanagement en data engineering, allemaal in één.

• De architectuur van een gefedereerd platform: een centraal intersectioneel datawarehouse op Azure Databricks, met zelfstandig beheerde teamwerkruimtes uitgerold vanuit een sjabloon.
• Uitrol van het hele platform als infrastructure as code, zodat elke werkruimte op dezelfde manier gebouwd wordt en kan draaien in de regio die de dataregels voorschrijven.
• De kernpijplijnen die de ERP- en financiële systemen van alle vijf hoofdkantoren integreren, door ons ontworpen en geprogrammeerd.
• De governancestructuur, eigendom, toegang en rollen, die de federatie op schaal houdbaar maakt, met zoeken en lineage zodat iedereen data kan vinden en fouten kan herleiden.
• Een decentraal ambassadeursmodel dat het datateam verbindt met collega's in het veld, in beide richtingen.
• Agile werken en een stakeholdermodel met een roulerende zetel voor de dataleads, zodat vijf hoofdkantoren op één roadmap blijven.