Sinds de lancering van tablets, smartphones en de app-cultuur ligt de lat voor user experience hoog, ook voor bedrijfssoftware. Om dit te kunnen realiseren, is er een andere manier nodig om aan softwareontwikkeling te doen. Een manier die toelaat om veel sneller,  flexibeler en aan een lagere kostprijs in te spelen op de stijgende verwachtingen en noden. 

Software Architectuur 2020 (SA2020) is een set principes over software architectuur die een invloed hebben op de manier waarop wij analyseren, ontwerpen, ontwikkelen, infrastructuur opzetten, testen en ondersteunen, enzovoort. 

Met SA2020 willen we klaar staan voor elk digitaal initiatief, zelfs voorbij het nu denkbare. Een korte beschrijving van onze architectuur en enkele principes...

Software Architectuur 2020
 

Basisprincipe: we scheiden de frontend van de backend

Het belangrijkste principe in SA2020 is de volledige scheiding tussen frontend (evolueert elke dag) en backend (redelijk stabiel). 
Waar de backend van een applicatie vroeger gebouwd werd in functie van de frontend, maken we nu een (generieke) backend met business services, engines en referentiesystemen. Deze backend kan alle frontends aan én kunnen we koppelen met andere backend systemen. We gaan ook actief op zoek naar hergebruik voor backend services.

Frontend: ACPaaS UI

We ontwikkelen niet elke app van scratch. Heel wat zaken komen immers telkens terug. Daarom gebruiken we - al lang - toolboxen. Vorig jaar voegden we hieraan ACPaaS UI toe, een frontend bibliotheek waarmee we op een eenvoudige & consistente manier responsive apps & websites voor de groep Antwerpen vormgeven, prototypen en de frontend ervan bouwen. Iedereen die één van deze componenten nodig heeft voor de ontwikkeling van een app of website, kan ze gebruiken. 

ACPaaS UI bevat een aantal functionele componenten zoals een zoekbalk, een winkelmandje, delen via sociale media enzovoort. Deze componenten zijn frontend framework (Angular) gebonden, en dus ook afhankelijk van de versie van het framework. 
Meteen de reden waarom we zoveel mogelijk framework-onafhankelijk ontwikkelden: alle vormgeving en core branding van de groep stad Antwerpen, en de services om de functionele componenten te ondersteunen. 

Backend: shared business services, engines en referentiesystemen

Apps maken gebruik van de business services (bijvoorbeeld het ophalen van een stratenlijst) uit onze backend. Business services bestaan elk op zich uit microservices of kleine herbruikbare softwareblokjes. We kunnen deze atomaire blokjes software  onafhankelijk van elkaar implementeren en ze zijn gemakkelijk vervangbaar. Op hun beurt kunnen ze andere services aanspreken waaronder externe services zoals de UIT API van Vlaanderen.

Een business service is een API die de business logica achter de frontend bevat. Een shared business service is herbruikbaar (bijvoorbeeld binnen de dienst financiën).

Dit laatste maakt het verschil met een ACPaaS engine. Engines zijn per definitie generiek en kunnen door om het even welke afnemer gebruikt worden. 

Tot slot zijn er ook de centrale referentiesystemen of authentieke databronnen (personen, bedrijven, adressen, …) die hergebruikt worden. 

API Management

Tussen front- en backend staat de API Manager, een gateway en marketplace waar een developer API’s opzoekt en een contract  aanvraagt om onze API’s te kunnen gebruiken. Om security redenen bewaren we de sleutels van zo’n contract in een tussenlaag: een lichtgewicht backend (bFF of backend for front) in functie van de frontend. Zo schermen we onze API keys af van de buitenwereld . 

Event Handler: asynchrone communicatie tussen microservices

Een frontend app kan gebruik maken van business services en engines. Asynchrone  communicatie tussen deze microservices verloopt via de Event Handler. Zijn er wijzigingen in een backend, dan krijgen we hiervan een realtime update. De Event Handler is een pub-sub-systeem, waarbij de subscribers of abonnees via de Event Handler op de hoogte worden gebracht van updates in de publisher.

Semantic versioning: afhankelijkheden voorkomen

Om afhankelijkheden bij nieuwe go-lives te voorkomen - je wil niet dat het ene niet meer werkt omdat je voor het andere een nieuwe versie lanceert - voorzien we van eenzelfde component verschillende versies. Via semantic versioning, een standaard manier van versioneren, houden we bij welke types aanpassingen er per versie gebeurden (major, minor, patch) en hoe we ermee omgaan. 

Zo kunnen we een nieuwe versie in productie zetten zonder afhankelijk te zijn van de andere afnemers en zonder deze afnemers te impacteren (backward compatibility). Daarnaast maken we afspraken over de ondersteuning van oude versies (de depreciation policy). De afnemers van een component migreren naar de recentste versie zodat ze kunnen genieten van nieuwe features en/of bugfixen. Doen ze dit niet dan kunnen ze na een afgesproken aantal releases van de component geen beroep meer doen op ondersteuning.

Walk the talk - enkele voorbeelden

Hittealarm

Het EcoHuis toont momenteel op 3 schermen (in het EcoHuis zelf en op de grote LED schermen aan de Turnhoutsebaan en op het Astridplein) de huidige temperatuur en  de voorspelling voor de volgende 5 dagen. Daaraan is een hittealarm gekoppeld - een automatische melding wanneer er kans is op een hittegolf. 
Om meer duiding te geven over de stad als hitte-eiland en tips in het geval van een hittegolf, wil de stad deze gegevens binnenkort ook via A-stad ontsluiten.  Hierbij scheiden we de backend van de frontend.

De frontend (de grafiek-snippet) spreekt API services aan om de temperaturen te verkrijgen.
De bestanden waarin de temperaturen staan, worden opgeladen via de ESB (Enterprise Service Bus) en API’s. Als de temperatuur leverancier verandert, dan moet enkel het stuk voor het binnenhalen van de temperaturen wijzigen. Al de rest kan hetzelfde blijven. Het zal ook mogelijk zijn om andere leveranciers van temperaturen dan de huidige toe te voegen om bv. meerdere locaties te vergelijken.

Orderopvolging

Burgers, bezoekers, bedrijven, studenten en stadsmedewerkers kunnen verschillende producten en diensten online aankopen en afrekenen. De Orderopvolging laat de stadsmedewerkers toe om op een vlotte en intuïtieve manier orders op te zoeken, weer te geven en te delen met collega’s en klanten. 

Orderopvolging werd gerealiseerd met verschillende ACPaaS engines. Het M(edewerkers)-profiel en de User Management engine staan in voor de authenticatie en autorisatie van de gebruikers. Updates en creaties van de orders worden via de Event Handler uitgestuurd. Vervolgens worden ze geïndexeerd in SOLR. 
De synergie van deze verschillende componenten zorgt voor een performante applicatie.

Om beter te voldoen aan de SA2020 standaarden, werd de Order Search in het leven geroepen. Deze component zorgt voor de verwerking van de ontvangen events, de indexatie in en de bevraging van SOLR. Zo heeft de orderopvolging toepassing maar één enkele taak: zorgen voor een aangename gebruikerservaring!