Integration och KISS-principen

För tre år sedan var jag med och upphandlade en integrationsplattform baserad på avancerade kö-mekanismer och datatransformeringsverktyg. Det blev dyrt, och krävde en rejäl utvecklingsinsats för att få fart på några integrationstjänster för att hantera ett orderflöde. Vi pratar om investeringar i 10 miljonersklassen här för licenser och inhyrda expertkonsulter, och flera hundratusen kr per år i supportkostnad till leverantören. Den delen av verksamheten som nyttjade integrationerna blev inom kort såld till ett betydligt mindre företag som inte hade råd att betala de dyra licenspengarna för att behålla integrationsplattformen. Istället satte sig en av deras utvecklare och skrev om hela integrationlösningen från scratch, baserat på standardfunktioner i .NET. Det tog tre månader och sedan kunde de stänga ner den tidigare lösningen.

Parallellt med detta var jag med om att bygga nästa integrationslösning baserat på den dyra integrationsplattformen. Det var jobbigt och tog lång tid, ungefär ett år. Under tiden började jag tveka på om vi verkligen var på rätt spår. Kanske det fanns en enklare lösning även för oss? Det kändes som att allt var så tillkrånglat i den här dyra fina integrationplattformen. Det var svårt att förstå hur lösningarna fungerade, svårt att debugga, svårt att versionshantera, svårt att deploya, svårt att utveckla tillsammans i team. Plattformen var dessutom inte särskilt stabil, så det var med viss nervositet som man gick på semester.

Vi tog till slut ett beslut som innebar att även vi byggde om alltihopa i ren .NET. Det tog åtta veckor, och efter det har lösningen bara snurrat. Nu tar vi nästa steg och bygger en ny integrationslösning direkt i denna .NET-arkitektur, och det ser lovande ut! Vi tror att vi ska vara klara på 6 veckor. Lösningarna är tillräckligt enkla för  att vi ska kunna förvalta dem med egen personal, och vi är inte längre beroende av någon leverantör. Avtalen med leverantören av den tidigare integrationplattformen är nu uppsagda.

Vad är då sensmoralen i denna historia? Jo: Keep It Simple and Stupid. Även kallat KISS-principen.

Har ni liknande erfarenheter av dyra, komplexa infrastrukturplattformar? Kommentera gärna!

Varför vill man ha ID som betyder något?

Jag har under de senaste veckorna brottats med exakt samma frågeställning på tre olika ställen i vår verksamhet: "Vi vill att ID för X ska vara formaterat så här: Y" där X kan vara ett anställningsnummer, ett användarnamn, ett artikelnummer, etc. Y är något mönster som innefattar information om hierarkin som objektet ingår i eller kanske en förkortning av innehållet i andra fält.

Anställningsnummer

Här vill man helst ha olika intervaller för att särskilja anställda mellan olika bolag i vår koncern. T ex 3000-3999 för bolag x och 4000-4999 för bolag y.

Användarnamn

Här vill man oftast ha någon slags förkortning av personens för- och efternamn, t ex två bokstäver från förnamnet och tre från efternamnet, eller förnamnets första bokstav och hela efternamnet.

Artikelnummer

Artiklarna ingår i artikelgrupper som ingår i produktgrupper, så då vill man ha artikelnummer på formen xxx-yyy-zzz.

Det finns ju många nackdelar den här typen av formatterade koder. T ex så begränsar man sig i hur många anställda man kan ha, eller det blir krockar i användarnamnen som gör att man måste gå ifrån mönstret, eller att man inte kan flytta på en artikel till en annan artikelgrupp. Istället skulle man ju vilja ha rena löpnummer som ID, som kan automatgenereras av systemen, och att man som användare inte behöver se ID utan bara jobba med objektens namn och andra attribut.

Så vi på IT frågar varför. Verksamheten svarar "vi vill kunna se på ID vad det är för något". Varför det, frågar vi. Verksamheten svarar "för att vi har inte tid att kolla i någon separat tabell för att se vad ID betyder". Varför måste ni kolla det då? "Jo för att vi inte kan se det i GUIt".

Aha! Det är en användbarhetsfråga! Varför inte lägga lite energi på att förbättra våra gränssnitt så att man ser den relevanta informationen direkt?

Märkligt att samma diskussion dyker upp överallt. Kan det vara så att vi människor har en tendens att försöka se mönster i allt, även när det inte finns något? Jag upplever till exempel att jag funderar över mönster som jag tycker mig se i de koder som genereras när jag loggar in på min internetbank. Men det borde ju inte finnas något mönster eftersom då skulle inloggningen ha allvarliga säkerhetsbrister. Det verkar alltså vara våra hjärnor som lägger energi på att skapa mönster och tolkningar, och när vi exponeras för siffror som inte betyder något, så försöker vi ändå att skapa en betydelse...

Känner ni igen er i detta resonemang? Kommentera gärna!