Om integration av stora IT-miljöer

Denna text var del av en av de utkast jag arbetade med för rapporten till Statskontoret, men som jag efter ett tag valde att kasta. Jag gillade det här sättet att se på integration – att det är något som pågår på alla nivåer.

IT-miljön hos ett typiskt större företag eller statlig myndighet är brokig. Den består av flera olika system, utvecklade mer eller mindre oberoende av varandra, baserade på olika plattformar och teknologier. Efter blandning av egenutveckling och inhyrda konsulter består IT-miljön av system som är skapelser ur skilda kulturer. De avspeglar andra sammanhang än dem de nu fungerar i, då verksamheten antingen är en annan eller inte förstods när de utvecklades. Som följd av att systemen vuxit individuellt överlappar de varandra i funktionalitet. Enskilda arbetsuppgifter kräver stöd av flera system, inte sällan med någon form av manuell överföring emellan. Verksamhetens information har spridit sig från system till system, i fragmenterade kopior, nu inkonsistenta efter att inte ha hållits ajour.

Systemen vidareutvecklas, integreras mot varandra, ineffektivt och kostsamt eftersom det sker isolerat, inom olika delar av organisationen. I allt större utsträckning behöver systemen integreras också mot system i andra organisationer. I båda fallen handlar det om främmande system, som kräver samordning för att uppnå interoperabilitet. I båda fallen krävs en samstämmig uppfattning hos de inblandade parterna om syftet med integrationen samt förutsättningarna för den. Dålig kännedom om verksamhetens totala IT-miljö är orsaken till dess brokighet och IT-systemens inkonsistenta och överlappande funktion och information. Segregation, inte integration.

Integration innebär att man låter ett system få tillgång till information och funktionalitet i ett annat, att det förra utnyttjar tjänster tillhandahållna av det senare. Det som motiverar utnyttjande av ett annat systems tjänster är förstås att det är mer ekonomiskt än att utveckla samma tjänster på nytt, samt att det minskar IT-miljöns brokighet, dess heterogenitet. Inte minst är det viktigt att tjänsterna tillhandahålls av det system där funktionaliteten och informationen hör hemma, där det är mest logiskt att förlägga den. Logisk partitionering av funktionalitet är någonting som sker inte bara på systemnivån utan på varje nivå därunder ’ inom varje system i form av dess subsystem; varje subsystem bryts sedan ned i dess övergripande komponenter och så vidare. Integration är alltså ett sätt att hantera komplexitet. Inom en organisation följer denna komplexitet av att dess IT-system växt till att omfatta hela organisationens verksamhet och därmed dess samarbeten med andra organisationer.

Ånda sedan IT-historiens början har komplexitetsproblem avlöst komplexitetsproblem. Varje uppfunnen teknik eller metod för att lösa sådana problem har möjliggjort åter nya nivåer av komplexitet, med därpå följande problem.

När datorerna var nya programmerades de på låg nivå. Källkod bestod av primitiva instruktioner. Snart blev programmen för långa och svåröverskådliga, varför de behövde uttryckas på ett mer läsbart sätt. Högnivåprogramspråk skapades vars varje instruktion översattes automatiskt till en sekvens lågnivåinstruktioner. Dessa språk tillät mer strukturerad programmering än tidigare, men blev liksom de maskinnära språken så småningom otillräckliga. Senare när procedurer introducerades i högnivåspråken kunde program organiseras i form av procedurer. De uppgifter som ett program skulle utföra bröts ned i deluppgifter, vilka i sin tur bröts ned ytterligare. Varje deluppgift motsvarade en procedur som anropade andra procedurer motsvarande de deluppgifter den brutits ned i. När programmen blev större och mer komplexa behövdes stöd för att organisera procedurerna, varpå högnivåspråken försågs med möjligheten att definiera moduler. Programspråkens utveckling handlar till stor del om att bättre organisera komplexitet och skapa begriplig källkod.

Parallellt med programspråkens utveckling har olika metoder för analys och design utvecklats, metoder för att analysera dels de behov ett datorprogram ska tillgodose, dels det sammanhang i vilket programmet ska användas, i syfte att ge underlag till utformningen av programmets design. De senaste femton åren har handlat mer om sådana metoder än om hur programspråken ska bli bättre på att organisera komplexitet, även om programspråken fortfarande utvecklas. Med allt större utvecklingsprojekt, allt mer omfattande system, blev behovet större att organisera komplexiteten på en nivå ovanför programspråken. Med flera utvecklare uppdelade i olika team behövdes en övergripande logisk struktur för dessa att hålla sig inom. Systemen delades liksom tidigare upp, men skalan var större; olika team ansvarade för delsystem, olika utvecklare för delar av dessa. Den övergripande strukturen förmedlades till dem via olika typer av diagram och specifikationer, för vilka formatet angavs av den tillämpade metoden.

De senaste åren har komplexitetsproblemen till stor del kretsat kring integration av system inom och mellan organisationer. Existerande system inom en organisation integreras mot varandra, nya system integreras mot existerande. Målet med denna integration är effektivisering. En IT-miljö där var sak har sin plats, där information och funktion inte är redundant, där samma plattformar och teknologier används och så vidare ’ kort sagt en integrerad homogen IT-miljö ’ har större förutsättningar att kunna effektivt anpassas efter förändringar inom verksamheten, efter nya behov. Sådan integration kräver övergripande samordning. Det krävs en uppfattning om vilka system som finns samt vilka tjänster de potentiellt skulle kunna erbjuda till andra system. Då detta vanligen redan beskrivits i form av diagram och specifikationer inom respektive tidigare projekt har metoder skapats för att sammanställa dessa beskrivningar i syfte att göra dem tillgängliga centralt. Annan existerande dokumentation som kan vara värdefull för framtida projekt tillfogas lämpligen denna centrala IT-verksamhetsbeskrivning, såsom begreppsmodeller av verksamheten, processbeskrivningar, med mera.

Teknikerna för att bättre strukturera och öka läsbarheten hos källkod, de olika typerna av diagram för att åskådliggöra struktur och flöden inom system, de olika metoderna för att organisera sådana diagram och övrig dokumentation om IT-verksamheter ’ dessa har gemensamt att de är hjälpmedel för att underlätta integration, för att hantera ett eller flera systems komplexitet genom partitionering på olika nivåer, genom logisk uppdelning i komponenter, vilka i flera led utnyttjar funktionalitet och information hos komponenter på underliggande nivåer. Integration är inte enbart en fråga om att ansluta ett existerande system till ett annat, för att möjliggöra tjänsteutbyte. Ett tjänsteutbyte är baserat på antagandet att den utnyttjade tjänsten logiskt sett hör mer hemma i systemet som levererar den. Integration handlar om att kombinera flera system, vart och ett en logisk helhet avseende dess funktionalitet, till ett sammanhängande större system. När ett sådant är välintegrerat är det organiserat efter funktionen hos respektive delsystem. Det är överskådligt och begripligt.