Constructieprincipes voor de informaticus: (10) Applicatiefunctie en dataopslag scheiden

Om het principe te verduidelijken gebruik ik de metafoor van goederenvervoer. De goederen zijn de data. Dat is uiteindelijk wat waarde heeft voor de eindgebruiker. De verschillende transportsystemen zijn de verwerkingsfuncties of applicatiefuncties. Als de goederen hard gekoppeld zouden zijn aan het transportsysteem (bijvoorbeeld containervervoer) dan zou het vanaf de productie in de fabriek tot aan de eindgebruiker goed “gevangen” zitten in die container. Op zichzelf is dat geen belemmering voor het vervoer maar het levert beperkingen op. De goederen kunnen dan niet door een ander transportsysteem (door de lucht of in een kleiner voertuig) worden vervoerd. Er zouden overal containerwagens rijden en schepen varen en herdistributie vanuit de containerverpakking naar een ander transportmiddel is onmogelijk. Dat is inflexibel vanuit het gezichtspunt van de goederen en de eindgebruiker.

Met andere woorden: als de data niet gescheiden van de applicatiefunctie kan worden verwerkt dan zit deze “gevangen” in die applicatiefunctie. De gebruiker kan alleen via die applicatiefunctie de data benaderen.

In het goederenvervoer is de mogelijkheid gecreëerd om goederen via verschillende transportsystemen te leveren, passend bij het gebruik. Het goed kan door verschillende systemen “benaderd” worden om de gewenste functie ermee uit te voeren. Moet het snel dan kan het via luchtvracht. In een stad via de bakfiets van Coolblue.

Als we applicatiefunctie en dataopslag scheiden kan de data door meer dan die ene applicatiefunctie worden verwerkt. Dat levert allerlei voordelen op.

Tussen de applicatie en de data zit een “API” (een Application Programming Interface). Een API is de moderne ontkoppelcomponent in de informatica waarmee de data wordt losgekoppeld van de applicatie. Door de API te standaardiseren kunnen verschillende applicaties op dezelfde wijze een dataopslag benaderen. Maar let op; dit standaardiseren is geen sinecure. De structuur van de dataopslag en betekenis van de data moet wel passen bij de API standaard. Databeheer moet ervoor zorgen dat de kwaliteit van de data passend is en dat duidelijk is welke dataopslag voor welk gegeven de bron is.

Bovendien moet de toegang tot de data (die bij een ongescheiden opslag via de applicatiefunctie verloopt) worden geregeld op de opslag zelf. Dat betekent dat de API via een beveiligingsmechanisme toegelaten moet worden, eventueel zodanig dat de eindgebruiker die via de API data benadert, kan worden geauthentiseerd en geautoriseerd tot die data.

Het is dus zeker niet eenvoudiger te realiseren dan een ongescheiden applicatie. Maar je krijgt er wat voor terug op gebied van leveranciersonafhankelijkheid en onderhoudbaarheid.

Eén van de voordelen van niet “gevangen” zitten in de applicatiefunctie is dat de gebruiker vendor lock in kan voorkomen. Door eisen te stellen aan de dataopslag kun je deze ook buiten de applicatie van de leverancier gebruiken. Dat was in het verleden vaak de reden dat dit principe door leveranciers niet werd toegepast. Nog steeds is dataportabiliteit door leveranciers beperkt en is het lastig om een applicatie te vernieuwen zonder grote datamigratietrajecten omdat de dataopslag alleen werkt voor die ene applicatie.

Dit principe draagt ook bij aan de in 2016 geformuleerde FAIR principes (findability, accessibility, interoperability, and reusability) voor wetenschappelijke datasets. Met name toegankelijkheid en hergebruik zijn gebaat bij een los van de applicatie benaderbare dataset.

De scheiding komt de onderhoudbaarheid (wijzigbaarheid) van zowel applicatielaag als dataopslag ten goede. Lastig te bouwen nieuwe functionaliteit in de bestaande registratieve applicatie kan als aparte applicatie worden toegevoegd op dezelfde dataopslag. Het Mendix platform is daar groot mee geworden.

Omgekeerd kun je een verouderde database vervangen door andere technologie (zelfs een cloud database) terwijl je de applicatie zelf ongemoeid kan laten. Alleen de API moet koppelen op de nieuwe locatie van de database.

Dit principe is één van de centrale uitgangspunten binnen Common Ground. Door de data te scheiden kunnen gegevens worden gedeeld tussen verschillende applicaties zonder dat deze meerdere keren moeten worden opgeslagen. Het doel is hier om alle applicaties de data te laten halen bij dezelfde bron. De eerder genoemde inspanning om de kwaliteit en betekenis van de data dan wel te waarborgen is de keerzijde van het voordeel.

Een andere toepassing zien we binnen Whatsapp waarbij de ontvangen media op de telefoon ook worden opgeslagen in de mediaopslag zodat ze apart te benaderen zijn vanuit andere apps. Omdat de context de telefoon is van een persoon is de beveiliging voor die aparte mediaopslag al geregeld.

Maar er zijn nog steeds voorbeelden van het niet toepassen. Bijvoorbeeld bij email. Probeer maar eens een .pst bestand van Microsoft Outlook (waarin al je email zit) te benaderen los van Outlook. Of een email zodanig op te slaan als los bestand zodat je hem in een ander programma als email met bijlagen kunt bewerken en doorsturen. Er zijn vast handige conversieprogramma’s op internet te vinden maar gemakkelijk is het niet. En dat komt omdat er geen standaard API is gedefinieerd voor emailberichten.

Een ander voorbeeld zie je bij de vele tekenprogramma’s. Die hebben ieder hun eigen opslagformaat waardoor een tekening alleen in die tooling kan worden bewerkt.

Als Informaticus moet je dit principe zorgvuldig afwegen. Het is niet altijd nodig, er moet een rechtvaardiging zijn voor de extra moeite die je moet steken in het ontwikkelen of toepassen van een API tussen applicatielaag en datalaag. Maar meestal is die rechtvaardiging snel gevonden.

1. Betekenisloze identiteitsaanduiding, lees hier.
2. Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen, lees hier.
3. Consistentie van taal, lees hier.
4. Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie, lees hier.
5. Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen, lees hier.
6. Autorisatie loskoppelen van identificatie/authenticatie, lees hier.
7. Enkelvoudige vastlegging van stamdata, lees hier.
8. Data en metadata scheiden in opslag en verwerking, lees hier.
9. Standaardpatronen toepassen zonder afwijkingen, lees hier.
10. Applicatiefunctie en dataopslag scheiden, lees hier.
11. Apparaat onafhankelijk ontwikkelen, lees hier.