Your integration strategy is the key architectural component to organizational agility.<\/p>\n<\/blockquote>\n\n\n\n
Det finns hur m\u00e5nga program som helst att k\u00f6pa, i alla m\u00f6jliga storlekar och former, men integration kan du inte g\u00e5 ut och k\u00f6pa<\/a>.<\/p>\n\n\n\n I de allra flesta organisationer finns en stor samling mjukvaror. F\u00f6rhoppningsvis har varje mjukvara ett prim\u00e4rt syfte som knappt \u00f6verlappas av n\u00e5got annat program. Men oundvikligen blir en del av informationen \u00e4nd\u00e5 dubbelt representerad tv\u00e4rg\u00e5ende genom flera system, s\u00e5som anv\u00e4ndare eller artiklar. <\/p>\n\n\n\n Ge upp direkt att f\u00f6rs\u00f6ka underh\u00e5lla skapandet, \u00e4ndringen och borttagandet av denna redundanta data med manuella processer. Information som finns representerad p\u00e5 flera st\u00e4llen (som inte erh\u00e5ller den p\u00e5 automatiskt vis via integration) \u00e4r det som h\u00e5rdast b\u00f6r jagas och utrotas. En normalisering <\/a>p\u00e5 organisationsniv\u00e5.<\/p>\n\n\n\n Det som f\u00f6ljer \u00e4r fr\u00e5gest\u00e4llningar som b\u00f6r st\u00e4llas inf\u00f6r all systemintegration. Bygger du microtj\u00e4nster eller saker i molnet ang\u00e5r detta dig ocks\u00e5 f\u00f6r d\u00e5 har du frivilligt valt att introducera n\u00e4tverkshopp \ud83d\ude42<\/p>\n\n\n\n Vilka abstraktioner arbetar systemen med? \u00c4r det sj\u00e4lvklart att x \u00e4r samma som x i det andra systemet? Finns det begr\u00e4nsningar i hur det ena systemet representerat x som inte finns i det andra systemet?<\/p>\n\n\n\n \u00c4r det m\u00f6jligt att ut\u00f6ka systemens modeller av n\u00e5gon annan \u00e4n systemutvecklaren?<\/p>\n\n\n\n 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<\/p>\nBrandon Byars<\/a><\/cite><\/blockquote>\n\n\n\n Kan systemen \u00e4ndras och uppdateras oberoende av det andra systemet? Med andra ord \u00e4r gr\u00e4nssnittet stabilt och v\u00e4lformat till r\u00e4tt abstraktionsniv\u00e5 utan att systemen har sina fingrar l\u00e5ngt inne i varandra och f\u00f6r evigt kr\u00e4ver en stel synkroniserad dans vid varje f\u00f6r\u00e4ndring?<\/p>\n\n\n\n Kan b\u00e5da systemet initiera \u00f6verf\u00f6ringen till det andra n\u00e4rsomhelst? Eller pollar ett av systemen det andra? Finns det risk att n\u00e5gon h\u00e4ndelse missas mellan pollningarna?<\/p>\n\n\n\n Vilken garanti finns att meddelandet kommer fram? Du k\u00e4nner v\u00e4l till hur sv\u00e5rt det \u00e4r att garantera att ett meddelande kommer fram exakt en g\u00e5ng?<\/p>\n\n\n\n Batchas flera \u00f6verf\u00f6ringar ihop eller sker s\u00e4ndning realtidsliknande?<\/p>\n\n\n\n Har systemen uttalade s\u00e4tt (API) att integrera mot andra mjukvaror? Eller skall \u00e4ndringar detekteras direkt i databasen<\/a>?<\/p>\n\n\n\n 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<\/p>\nLinus Torvalds<\/cite><\/blockquote>\n\n\n\n I fallet n\u00e4r data skall h\u00e5llas synkroniserad, hur vet vi att den \u00e4r det efter en viss tid har f\u00f6rflutit? Skall data g\u00e5 \u00e5t b\u00e5de h\u00e5len eller kan l\u00f6sningen f\u00f6renklas genom att det ena systemet enbart ”speglas” fr\u00e5n det andra?<\/p>\n\n\n\n Kan systemen prata samma ”protokoll” direkt med varandra eller beh\u00f6vs ytterligare n\u00e5gon \u00f6vers\u00e4ttningsmjukvara emellan? (applicera d\u00e5 alla fr\u00e5gest\u00e4llningar i detta inl\u00e4gg p\u00e5 \u00f6verf\u00f6ringen mellan k\u00e4llsystemet och bryggan samt fr\u00e5n bryggan till m\u00e5lsystemet)<\/p>\n\n\n\n Kan mottagande system \u00f6verbelastas av s\u00e4ndaren?<\/p>\n\n\n\n Klarar b\u00e5da systemen att det andra f\u00f6rsvinner en kort eller l\u00e5ng stund? Vad h\u00e4nder med meddelanden som borde skickats under denna tid?<\/p>\n\n\n\n Sparas de och skickas om automatiskt eller manuellt? \u00c4r det ens relevant att skicka om meddelandet eller skall ett nytt skapas?<\/p>\n\n\n\n Hur skall respektive systems \u00f6verf\u00f6ringar \u00f6vervakas? Vad blir konsekvensen av en integration som fallerar?<\/p>\n\n\n\n Ansvarar systemet som blir anropat f\u00f6r att inte l\u00e4mna sig sj\u00e4lv i ett icke-logiskt skick ifall anropet av n\u00e5gon anledning inte exekveras f\u00e4rdigt framg\u00e5ngsrikt?<\/p>\n\n\n\n General purpose languages excel at programming over time<\/p>\n\n\n\n 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.<\/p>\nBrandon Byars<\/a><\/cite><\/blockquote>\n\n\n\n Anv\u00e4nd vanliga programmeringsspr\u00e5k och l\u00e4r dig de vanliga designm\u00f6nstren f\u00f6r integration.<\/p>\n\n\n\n 2003 kom boken Enterprise Integration Patterns<\/em> ut som beskriver alla m\u00f6nster i bilden ovan. Den kan k\u00e4nnas dammig nu men faktum \u00e4r att den tillsammans med lite nya ”Cloud Design Patterns<\/a>” \u00e4r lika aktuell i dagens systemutveckling d\u00e5 det fastslagits att varenda minsta applikation skall vara distribuerade p\u00e5 n\u00e5got s\u00e4tt. Antingen med en frontend i webbl\u00e4saren, mikrotj\u00e4nster, koppling till LLM eller en samling ihopkopplade l\u00f6sningar hos molnleverant\u00f6ren.<\/p>\n\n\n\n You can\u2019t buy integration, but that\u2019s OK; it\u2019s worth the investment to build it yourself. After all, it may be the most strategic software in your portfolio<\/p>\nBrandon Byars<\/a><\/cite><\/blockquote>\n\n\n\n You Can’t Buy Integration<\/a><\/p>\n\n\n\nDatamodellen<\/h2>\n\n\n\n
\n
\u00d6verf\u00f6ringss\u00e4tt<\/h2>\n\n\n\n
\n
At-most-once delivery<\/strong>. This means that a message will never be delivered more than once but messages might be lost.\nAt-least-once delivery<\/strong>. This means that we'll never lose a message but a message might end up being delivered to a consumer more than once.\nExactly-once delivery<\/strong>. The holy grail<\/strong><\/mark> of messaging. All messages will be delivered exactly one time.<\/code><\/pre>\nhttps:\/\/jack-vanlightly.com\/blog\/2017\/12\/15\/rabbitmq-vs-kafka-part-4-message-delivery-semantics-and-guarantees<\/a><\/cite><\/blockquote>\n\n\n\n\n
Kommunikationss\u00e4tt<\/h2>\n\n\n\n
Driften<\/h2>\n\n\n\n
Implementationen<\/h2>\n\n\n\n
\n
![\"\"](\"http:\/\/localhost:8081\/wp-content\/uploads\/2023\/10\/firefox_09Lm5tylZl.png\")
<\/a><\/figure>\n\n\n\n\n
Mera l\u00e4sning<\/h2>\n\n\n\n