5. Till synes elegant integration
På många företag bestämmer man sig för att lösa sina integrationsproblem med en elegant integrationsplattform, eller en ”tjänstebuss” eller någon annan typ av mellanprogram och med hantering av metadata.

Efter ett tag visar sig ofta två saker. För det första att den nya lösningen innebär att det blir enklare för utvecklare att lösa enkla problem. För det andra att den nya lösningen inte är någon lösning alls på de svåra problemen. Det här innebär att utvecklarna helt enkelt bygger om den gamla härvan av integrationslösningar, men gömmer dem inuti en ny plattform så att andra inte kan se dem.

En till synes elegant integrationslösning är lika sårbar och svår att underhålla som en härva av gränssnitt med enskilda integrationer mellan sig. Som vanligt innebär det att it-resurser dras från värdeskapande aktiviteter.

6. Fullösningar
En konsult kanske gjorde ett slarvjobb eller så fick du en för snäv deadline själv. En gedigen insats i ett projekt kanske hade sabbat kalkylen för det. Slutresultatet blir hur som helst att en massa applikationer hålls samman med provisoriska lösningar.

Om du har tur så är det ingen som upptäcker det innan du byter jobb eller går i pension. Men situationen innebär förstås att applikationer blir sårbara och att underhållskostnaderna ökar med varje ny, egentligen onödig, fullösning. Lägg till det mer nertid, högre utbildningskostnader och ökad komplexitet för varje nytt projekt.

7. Föråldrad teknik
Det är verksamhetskritiskt! Det uppfyller affärskraven perfekt! Vad menar du med att vi behöver lägga pengar på underhåll?

Så här kan det låta när du berättar att du byggt något i en version av Visual Basic som Microsoft slutade ge support för mer än tio år sedan, som bara kan läsa data från Sql Server-versioner som är minst sju år gamla och som bara fungerar på Windowsversioner som inte har drivrutiner för skrivarna ni har på företaget.

Läs också: Därför är edge computing nästa stora hajp

Ju fler föråldrade tekniklösningar man har, desto svårare blir underhållsarbetet och arbetet med att skapa integrationslösningar. Följden blir, återigen, högre underhållskostnader och mindre flexibilitet vad gäller att ge stöd för ändrade affärskrav.

8. En massa rapporter
Du ser varningstecknen för dålig arkitektur. Så du ser till att organisera en arbetsgrupp. Du hyr in en expert, eller två. Deras produktivitet är enorm.

I alla fall mätt i mängden rapporter de producerar. Och visst kan de ändra hur ni jobbar med it, i alla fall om alla läser deras rapporter och följer deras instruktioner. Men deras påverkan på hur er it-arkitektur ser ut är noll, eftersom alla ignorerar dem. Följderna av deras arbete är bortslösade pengar, papper och toner. Och en ökad cynism på företaget.

Sida 2 / 2

Innehållsförteckning