Alla digitaliseringsresor bygger på ospännande integration av samtliga mjukvaror. Det är här komplexiteten underskattas.
Your integration strategy is the key architectural component to organizational agility.
Det finns hur många program som helst att köpa, i alla möjliga storlekar och former, men integration kan du inte gå ut och köpa.
I de allra flesta organisationer finns en stor samling mjukvaror. Förhoppningsvis har varje mjukvara ett primärt syfte som knappt överlappas av något annat program. Men oundvikligen blir en del av informationen ändå dubbelt representerad tvärgående genom flera system, såsom användare eller artiklar.
Ge upp direkt att försöka underhålla skapandet, ändringen och borttagandet av denna redundanta data med manuella processer. Information som finns representerad på flera ställen (som inte erhåller den på automatiskt vis via integration) är det som hårdast bör jagas och utrotas. En normalisering på organisationsnivå.
Det som följer är frågeställningar som bör ställas inför all systemintegration. Bygger du microtjänster eller saker i molnet angår detta dig också för då har du frivilligt valt att introducera nätverkshopp 🙂
Datamodellen
Vilka abstraktioner arbetar systemen med? Är det självklart att x är samma som x i det andra systemet? Finns det begränsningar i hur det ena systemet representerat x som inte finns i det andra systemet?
Är det möjligt att utöka systemens modeller av någon annan än systemutvecklaren?
We need to invert the mindset, from thinking of how to solve integration problems with our tools to instead thinking of how to build the right interfaces to maximize agility
Brandon Byars
Kan systemen ändras och uppdateras oberoende av det andra systemet? Med andra ord är gränssnittet stabilt och välformat till rätt abstraktionsnivå utan att systemen har sina fingrar långt inne i varandra och för evigt kräver en stel synkroniserad dans vid varje förändring?
Överföringssätt
Kan båda systemet initiera överföringen till det andra närsomhelst? Eller pollar ett av systemen det andra? Finns det risk att någon händelse missas mellan pollningarna?
Vilken garanti finns att meddelandet kommer fram? Du känner väl till hur svårt det är att garantera att ett meddelande kommer fram exakt en gång?
https://jack-vanlightly.com/blog/2017/12/15/rabbitmq-vs-kafka-part-4-message-delivery-semantics-and-guaranteesAt-most-once delivery. This means that a message will never be delivered more than once but messages might be lost. At-least-once delivery. This means that we'll never lose a message but a message might end up being delivered to a consumer more than once. Exactly-once delivery. The holy grail of messaging. All messages will be delivered exactly one time.
Batchas flera överföringar ihop eller sker sändning realtidsliknande?
Har systemen uttalade sätt (API) att integrera mot andra mjukvaror? Eller skall ändringar detekteras direkt i databasen?
An ugly system is one in which there are special interfaces for everything you want to do. Unix is the opposite. It gives you the building blocks that are sufficient for doing everything. That’s what having a clean design is all about
Linus Torvalds
I fallet när data skall hållas synkroniserad, hur vet vi att den är det efter en viss tid har förflutit? Skall data gå åt både hålen eller kan lösningen förenklas genom att det ena systemet enbart ”speglas” från det andra?
Kommunikationssätt
Kan systemen prata samma ”protokoll” direkt med varandra eller behövs ytterligare någon översättningsmjukvara emellan? (applicera då alla frågeställningar i detta inlägg på överföringen mellan källsystemet och bryggan samt från bryggan till målsystemet)
Kan mottagande system överbelastas av sändaren?
Driften
Klarar båda systemen att det andra försvinner en kort eller lång stund? Vad händer med meddelanden som borde skickats under denna tid?
Sparas de och skickas om automatiskt eller manuellt? Är det ens relevant att skicka om meddelandet eller skall ett nytt skapas?
Hur skall respektive systems överföringar övervakas? Vad blir konsekvensen av en integration som fallerar?
Ansvarar systemet som blir anropat för att inte lämna sig själv i ett icke-logiskt skick ifall anropet av någon anledning inte exekveras färdigt framgångsrikt?
Implementationen
General purpose languages excel at programming over time
The ecosystems with general purpose programming languages evolve at a rapid clip. Advances in testing tools, IDEs, observability tools, and better abstractions benefit from the sheer scale of the community such languages operate in. Low-code platforms have much smaller ecosystems, limiting the ability to advance at the same pace.
Brandon Byars
Använd vanliga programmeringsspråk och lär dig de vanliga designmönstren för integration.
2003 kom boken Enterprise Integration Patterns ut som beskriver alla mönster i bilden ovan. Den kan kännas dammig nu men faktum är att den tillsammans med lite nya ”Cloud Design Patterns” är lika aktuell i dagens systemutveckling då det fastslagits att varenda minsta applikation skall vara distribuerade på något sätt. Antingen med en frontend i webbläsaren, mikrotjänster, koppling till LLM eller en samling ihopkopplade lösningar hos molnleverantören.
You can’t buy integration, but that’s OK; it’s worth the investment to build it yourself. After all, it may be the most strategic software in your portfolio
Brandon Byars