Kies ook bij SaaS eerst voor je eigen software architectuur

Het gebruik van API’s en SaaS oplossingen in de cloud biedt organisaties veel kansen. Maar deze ontwikkeling heeft ook een keerzijde. Veel bedrijven en organisaties verliezen hun software architectuur uit het oog. Zo kan wildgroei van (nood)oplossingen en verbrokkelde data ontstaan. Voorkom dit door het ontwikkelproces om te draaien. Begin weer bij je eigen software architectuur. Dat is beter voor je businesscase, de software die daarbij past en om zelf de baas te blijven over essentiële data. Ook de privacywetgeving (AVG) vereist dit.

Het gevaar van SaaS en de API

Je kunt het zomaar vergeten met al die handige koppelmogelijkheden, API’s (Application Programming Interfaces) voor ontsluiting van data en aantrekkelijke SaaS oplossingen (Software as a Service). Maar het blijft belangrijk dat een organisatie eerst nadenkt over de eigen software architectuur.

Als je dit niet doet, ontstaat door allerlei functionaliteiten met API’s en zeer specifieke (SaaS) oplossingen voor bepaalde bedrijfsprocessen (zoals e-mail marketing, CRM of tracking) al snel een diffuus landschap van aan elkaar gekoppelde software. Dan is van een onderliggende softwarearchitectuur eigenlijk geen sprake meer. Of nog erger: een van de onderdelen wordt dominant en dicteert de ‘architectuur’. De andere componenten moeten zich dan conformeren aan het onbedoeld dominant geworden onderdeel.

Gevangen bedrijfsdata door gedicteerde keuzes

Zo’n gedicteerde ‘keuze’ is vaak helemaal niet handig voor een organisatie. De software die steeds bepalender wordt voor het succes van organisaties, sluit dan al snel niet meer goed aan op je eigen kernactiviteiten. De organisatie wordt afhankelijk van de keuzes die worden gemaakt door de producent van een dominant softwareproduct.

Dat gaat vaak ten koste van de beschikbaarheid en flexibiliteit van bedrijfsdata. Die zit immers gevangen in een datastructuur die handig is voor de applicatie. En dat is slechts zelden een handige structuur voor de hele organisatie. Dit leidt tot fragmentatie, onduidelijkheid en uiteindelijk verlies van (zicht op) essentiële bedrijfsdata. Zo krijg je geen software omgeving die de organisatie en prestaties van medewerkers optimaal faciliteert.

AVG en privacy by design

Naast het belang van de software architectuur als fundament voor je eigen business is ook de privacywetgeving (AVG/GDPR) een reden om hier goed over na te denken. Want de AVG (Algemene Verordening Gegevensbescherming) vereist dat organisaties goed nadenken over vragen als: Waar is onze data opgeslagen? Wie kan daarbij? Wat is de bron van die data?

De invulling van privacy by design en privacy by default is daardoor een actueel thema. Dit achteraf doorvoeren, is veel ingewikkelder en duurder dan er vooraf goed over nadenken. Je kunt het ook niet zomaar ‘op je software plakken’, je moet het in de software architectuur ontwerpen. Sterker: de AVG verwacht van organisaties een integrale aanpak in software architectuur om een duurzame en geborgde oplossing voor de privacy beginselen te realiseren.

Software architectuur voor eigen databron

De cruciale stap bij een architectuur first aanpak is het veiligstellen van de beschikbaarheid en flexibiliteit van uw essentiële bedrijfsdata en bedrijfsprocessen. Met een goede software architectuur creëer je hiervoor een eigen databron. Deze kun je zelf (laten) ontwikkelen, los van externe (SaaS) software. Vervolgens verbind je de externe software hieraan voor publicatie en transacties.

Dan blijf je dus onafhankelijk en kun je gerust van SaaS leverancier wisselen als een alternatieve oplossing beter bij jouw organisatie en werkprocessen past. Zo’n overstap is dan goed mogelijk omdat je kerndata en kernprocessen niet gevangen zitten in een dominante SaaS oplossing. Ze zitten veilig en toegankelijk in je eigen omgeving. Zo blijf je dus zelf de baas over cruciale bedrijfssoftware.

Architectuur first versterkt bovendien je businesscase. Het dwingt je om na te denken over waar de kern van je business zit. Welke onderdelen zijn essentieel voor je organisatie en wat zijn de randzaken?

Voorbeeld met een webshop

Oplossingen voor webshops zijn vaak als SaaS beschikbaar. Ze worden dankbaar gebruikt door startende webshop ondernemingen. De productendatabase is dan vaak het hart van de software omgeving. Alle producten, productinformatie en prijzen zitten ook netjes in de database van de SaaS oplossing.

Dat is superhandig totdat je groeit en iets meer wilt bijhouden dan de SaaS oplossing biedt. Bijvoorbeeld dat je bepaalde producten bij meerdere leveranciers kunt inkopen. Dat kan zeer belangrijk worden voor je business. Dat moet dan extern worden bijgehouden, verwijzend naar de SaaS database als bron. Daar begint het verlies van controle, overzicht en flexibiliteit van de brondata. Dit is hét moment om de aanpak om te draaien: eerst zelf je eigen productendatabase en een kopietje daarvan voor de SaaS webshop.