In een strategisch analyseverslag uit 2001 maakte Gartner de beroemde voorspelling dat “de transitie naar ERP II” eraan zou komen. Er staat (vertaald): “Er komt een zakelijke revolutie aan waarin grote ondernemingen zichzelf transformeren van traditionele verticaal geïntegreerde organisaties naar ‘hercombineerbare bedrijfsonderdelen’ die zich strategisch baseren op de uitvoering van kerncompetenties”.
Klinkt dat bekend?
Concurrentievoordelen
Het verslag zet de voorspelling voort met de woorden: “In de meeste sectoren zullen ondernemingen die een virtueler, combineerbaar businessmodel gebruiken een substantieel voordeel hebben tegenover degenen die dat niet doen.” Het blijft nog steeds een goed verslag. “Alle inspanningen van c-commerce (collaborative commerce) zullen vertrouwen op robuuste, geïntegreerde applicatiesuites die de onderneming centraal stellen en gebaseerd zijn op open architectuur en in staat zijn om informatie real-time uit te wisselen”.
Dit enkele verslag is alom erkend als één van de drijfveren voor bedrijven om een dienstgeoriënteerde architectuur na te sterven en meer te focussen op de waardeketen en samenwerking. Het 3-laagse architectuurmodel werd de logische uitkomst: houdt de ERP-registry gescheiden van het samenwerkingsproces en de user interfaces voor de verschillende kanalen. Je zult de zuilen op moeten splitsen om succesvol te kunnen zijn in de digitale eeuw, herinner je dat nog? Toen klonk het allemaal logisch en dat doet het nog steeds.
Of toch niet?
Domeingestuurd ontwerp
Nu blijkt het dat als je een grote marktreus in drie lagen opdeelt, dat je het risico loopt dat de onderdelen die je krijgt nog steeds te groot zijn om te managen. Zakelijke veranderingen hebben meestal invloed op meer dan een laag, wat dus om zorgvuldige coördinatie vraagt en vaak aanzienlijk veel tijd. Pogingen om dit aan te pakken door er eenvoudigweg meer mensen op te zetten zijn grotendeels mislukt. Meer teams vraagt om nog meer coördinatie en meer ceremonies, wat op zijn beurt het vermogen om te veranderen en innoveren aantast en snelheid kost.
Dat is waarom domeingestuurd ontwerp redding komt bieden. In plaats van het opsplitsen van grote ondernemingen in technische lagen, splitsen we het op in tientallen functionele domeinen, die afgestemd worden met zakelijke capaciteiten en allemaal bediend worden door een eigen team. Dat team is van voor tot achter verantwoordelijk voor zijn domein. Om wendbaar te worden zullen deze teams grotendeels onafhankelijk moeten werken en ieder zijn eigen microservice op moeten bouwen. Idealiter zou een verandering in het ene domein totaal geen invloed moeten hebben op een ander domein. Dan komt het erop neer dat microservices in feite mini-zuilen zijn.
De nadelen ondervangen
We weten allemaal dat zuilen nadelen hebben. De wereld is gewoon niet op zo’n manier vormgegeven dat je ieder individu zomaar in één zuil kunt proppen. En iedereen die in meer dan één zuil werkt, weet dat er een wirwar van inconsistenties kan bestaan. Dit is onafhankelijk hoe die persoon betrokken is, als klant, werknemer, manager of leverancier. Logica achter de interactie met gebruikers, naamgeving, inconsistente gegevens, verschil in uitkomsten van berekeningen, inconsistente logistiek, financiële en wettelijke verschillen, het kan allemaal zo snel een verwarrende of zelfs frustrerende ervaring worden. Dus hoe kan het hebben van meer zuilen nu een voordeel zijn?
De oplossing ligt in de technologie. Denk eens aan je telefoon. Je hebt er tientallen, zo niet honderden apps op geïnstalleerd. Ja, er zijn verschillen in hoe ze werken, maar niets dat onmogelijk te managen is. En ja, er zijn verschillende weer apps die verschillende weersvoorspellingen geven, maar dat is niet per se problematisch. Het zou zelfs wel eens goed kunnen zijn. Er kunnen zelfs, en dat komt regelmatig voor, verschillende realiteiten zijn de we opzettelijk niet weg willen harmoniseren.
Massaal gedistribueerd ontwerp
De reden waarom dit allemaal werkt, zonder uiterst chaotisch te worden, is omdat het raamwerk en middleware door alle apps gedeeld worden. Slecht enkele app stores bieden miljoenen apps aan. Er is één enkel notificatiesysteem. Er is één klok met een gesynchroniseerde tijd voor de hele wereld. Er is één instellingen app. Je kunt meestal maar één account gebruiken. Eén kalender. Een gezamenlijk authenticatiemechanisme. En zelfs betalingen worden nu samengevoegd.
Met bedrijfssystemen zou het vergelijkbaar kunnen werken. Grote systemen kunnen verdeeld worden in meerdere apps. Iedere app zou meer dan één implementatie kunnen hebben. Specifieke complexe onderdelen, zoals nationale standaarden en wetgeving kan in een specifieke client geïmplementeerd worden, waardoor de complexiteit van het implementeren van alle lokale vereisten in een enkele wereldwijde app er opzettelijk uit weg ontworpen wordt. Natuurlijk zijn er binnen een bedrijf strikte eisen aan gegevensconsistentie. Je kunt niet toestaan dat een betaalde bestelling uiteindelijk niet geleverd wordt. Of dat een annulering geen restitutie ontvangt. Dus, als er verschillende microservices in het spel zijn, en tal van apps die ze gebruiken, (in andere woorden: een massaal gedistribueerd systeem), is de integratie van diensten belangrijker dan ooit tevoren.
We kunnen van het succes van de smartphone leren dat er meer haken en ogen aan een geïntegreerde ervaring zitten dan alleen de integratie van gegevens. Feitelijk zul je harmonie en consistentie door je hele ecosysteem bewust moeten ontwerpen. Dat is niet alleen aan de gebruikerskant, maar geldt net zo goed voor back-end. Je hebt een universele ruggengraat nodig voor events, object opslag, zichtbaarheid, service mesh, en log analytics om er een paar te noemen. Dat is wat op dit moment de ‘outer architecture’ genoemd wordt.
Outer Architecture
De outer architecture die je hebt zal tig technieken moeten kunnen ondersteunen. Gegevensintegratie, bestandsintegratie, berichtgestuurde integratie, streamingintegratie en eventgestuurde integratie zijn de belangrijkste daarvan. In de wereld van de microservice heeft Kafka veel momentum. Kafka is een betrouwbare, eventgestuurde gegevensstroom met integriteit en schaal. Natuurlijk publiceer je al jouw API’s in een enkele API Store. Manage je jouw API-beleid met een enkele beleidsmanager. Heb je slechts één Identity Provider voor alle soorten identiteiten. De lijst gaat maar door.
Denk eens terug aan het app-ecosysteem op je mobiele apparaat. Er zijn talloze verhalen over ontwikkelaars die hun idee binnen een paar dagen of weken omgezet hebben in een succesvolle app. Ga eerst viraal, voeg later pas functies toe. Dit is de ongelofelijke kracht van deze ecosystemen. Hoe rijker het ontwikkelingsraamwerk en de infrastructuur van de app worden, des te makkelijker de ontwikkeling wordt. Op vergelijkbare wijze zijn jouw digitale platformdiensten een vitaal deel van jouw digitale ecosysteem geworden. Maar iemand moet al die kant-en-klare functies nog wel kant-en-klaar maken. Wie is er klaar voor om de rol van Apple of Google aan te nemen in zijn eigen ecosysteem?
Go Connext
Connext is onze Digitale Integratiehub die we aanbieden als een virtueel privéplatform. Het is eigenlijk een goed geïntegreerde samenstelling voor de outer architecture van jouw microservices en tegelijkertijd de middleware laag voor je interne systemen en clouddiensten. Daarom is het de alles-in-één oplossing voor hybride integratiesystemen. Jij kunt jouw integraties net zo gemakkelijk ontwikkelen als dat je een mobiele app ontwikkeld. Zo creëer je een rijke ervaring die aan de hoogste kwaliteitsstandaarden voldoet, ongeacht of het eventgestuurde microservices zijn of low-code orchestration services. Aan al jouw eisen wordt voldaan.
Nog niet overtuigd? Download deze casusstudie om te lezen hoe de Universiteit Utrecht Connext gebruikt. Of bel ons om een demonstratie in te plannen. Zien is geloven.
Gepubliceerd op 3 november 2020
