JDriven klant sessies

Ieder jaar kijken we samen met al onze collega's naar de mooie projecten die we voor onze klanten uitvoeren en welke uitdagingen we daar mogen oplossen. Dit jaar was de vorm een beetje anders maar de beleving en interactie was er niet minder om. In een mooie sessie hebben we de volgende 6 projecten besproken:

Sessie 1

Chiel & Tammo vertelden over hun project voor een grote klant in de financiële sector. Ze zijn daar bezig met machine learning om data van klanten te verrijken en te categoriseren met afgeleide informatie middels patroonherkenning in transacties. Om de kwaliteit van de categorisering te verbeteren is het belangrijk om de feedback van klanten op de getrainde modellen te verwerken zonder dat de data te herleiden is naar individuele transacties.

Technisch zijn er twee pipelines voor data ingestie: een voor transactie patronen, en een voor feedback van eindgebruikers.

Hierbij gebruikte technologieën: Kubernetes, Kafka, AWS S3, Cassandra, Scala, Akka Streams, Zio, Airflow, AWS Sakemakers, Apache Spark en Tensorflow.

Sessie 2

Voor een klant in de energiesector is Lana onlangs begonnen aan een nieuw product wat gebruik maakt van een aantal SAP producten: UI5, Cloud Foundry, ECC en GateWay. Om deze technologieën te verbinden wordt er gewerkt met Java en Spring Boot.

Zoals we wel vaker zien wanneer het SAP product portfolio wordt gebruikt, worstelt haar team met het gebruiken van development best practices, zoals CI/CD en technologie die niet van SAP komt.

Een nadelig aspect van SAP Cloud Foundry is dat het alleen ondersteuning voor publieke API's biedt, er is geen ondersteuning voor lokale development. Tevens is de SAP documentatie uitvoerig doch gefragmenteerd en soms incompleet.

Dit alles heeft het team doen besluiten te kiezen voor GitHub Actions voor CI en een Java-based modulaire monoliet om communicatie via publieke API's te voorkomen. Hierbij heeft het team besloten geen gebruik te maken van Akka.

Sessie 3

Kees werkt op de research afdeling van een klant in de chemie sector. Kees werkt hier samen met de researchers en een JCore collega om de kwaliteit van hun onderzoekstool te verbeteren.

Hierbij heeft Kees de volgende uitdagingen:

• De klant is zelf technisch ingesteld en stelt vaak oplossingsgerichte vragen. Hierin zitten vaak aannames over het voortbestaan van reeds bestaande oplossingen verpakt. Met als gevolg dat de klant en consultant voorbij te gaan aan goed begrip van een onderliggend probleem dat opgelost moet worden (Start with Why).
• Data modellen en API's die de data ontsluiten worden vaak naar diverse behoeftes toe geschreven. De behoefte aan data wijzigt echter vaak, waardoor er regelmatig wijzigingen nodig zijn in de API's. Hierdoor is een duidelijkere separation of concerns nodig.

Sessie 4

Hubert vertelde over de tech stack die gebruikt wordt voor een klant binnen de lease sector waar hij als developer bij betrokken is.

Het domein waarin hij werkt is user account management en de basis van de implementatie is KeyCloak. Opvallend detail is dat er met Domain Driven Design wordt gewerkt en men op CQRS zonder Event Sourcing is uitgekomen. Er is bovendien geen framework (zoals Axon) ingezet om CQRS te implementeren. Ook wordt binnen het project gewerkt met JEE MicroProfile. In het verleden hebben JDriven collega's gemerkt dat MicroProfile vaak nog niet 'af' voelt, maar bij deze klant draait het inmiddels stabiel.

Sessie 5

Voor een samenwerkingsverband van klanten in de logistieke sector is Joost aangehaakt als CICD architect en belast met het faciliteren van een DevOps transitie op het gebied van proces, organisatie en techniek. Een flinke klus waar hij veel energie van krijgt.

De opdracht bevat een flink aantal uitdagingen:

• De bestaande applicatie is vitaal, draait al sinds 2003, draait op 50 verschillende omgevingen en is sterk gekoppeld aan de behoefte van meerdere stakeholders. Deze applicatie moet gemodulariseerd worden t.b.v. wendbaarheid en onderhoudbaarheid.
• Er is een technische migratie gaande van Java SWT, WebLogic en Oracle DB naar Java/Spring/Angular en Postgres.
• De klant doorgaat tevens een DevOps transitie, wat e.e.a. betekent voor hoe teams en organisatie omgaan met verantwoordelijkheden en informatiestromen.
• Er is behoefte aan een sterkere feedback loop tussen teams en architecten.

Joost presenteerde een aantal opvallende besluiten om dit aan te vliegen:

• Architectuurvisie wordt herhaaldelijk bijgesteld en is samen te vatten in een vijf minuten durende video. Er wordt veel aandacht gegeven aan het feit dat complexiteit binnen de monoliet verhuist naar integratie tussen systemen. Dit is een bekende uitdaging in de wereld van microservices.
• Deployments zijn losgekoppeld van feature releases, om te voorkomen dat een omgeving met zoveel stakeholders leidt tot het ophopen van features voordat een release klaar is om te mogen deployen. Er zijn bovendien geen losse eigenaren meer van individuele omgevingen; iedere acceptatie en productie omgeving wordt gelijk getrokken voor alle stakeholders.
• Het shift left paradigma wordt toegepast op testen.
• Prioriteit voor herbouw en ontkoppeling gaat naar onderdelen die weinig koppelingen hebben.

Sessie 6

Justus werkt voor een klant in de energiesector, en ook hij heeft veel te stellen gehad met het werken met het SAP product portfolio. Hierbij merken we het nut van klantensessies zoals deze: hier ontdekken we ook verschillende lessons learned.

De problematisch gefragmenteerde en soms onvolledige documentatie van SAP producten passeerde al eerder de revue deze avond. Opvallende andere zaken die bij het oppakken van deze opdracht het hoofd moesten worden geboden:

• Het SAP Cloud Application Programming Model (CAP) blijkt nog work in progress, waarbij er bijv. pas sinds kort ondersteuning is voor het werken met JARs ipv WARs en voor local development. Het team heeft besloten een SAP specialist aan te trekken gezien de uitdagingen en hoge learning curve.
• SAP Core Data Services (CDS) is gebaseerd op Apache OLingo en helpt met het mogelijk maken van mock services voor local development.
• Het team werkt met SAP Busines Application Studio (BAS), wat gebaseerd is op Microsoft Visual Code. Veelgehoord probleem met BAS is dat het regelmatig connectie verliest, waardoor werk verloren gaat. Dit vormt een bron van frustratie.
• Het team heeft besloten om voor alle integratie uitdagingen waar integraties met SAP producten niet werken, een eigen custom REST API te bouwen.
• Waar het team niet gebonden is aan SAP, draait de software op OpenShift.

Kortom: voldoende aspecten om als team samen over na te denken en van elkaar te leren. Ik denk dat iedereen veel nieuwe kennis en inzichten opgedaan heeft.

Jasper