Bygger vi IT-lösningar som om det vore 1930? Del 2

– Av Anders Kingstedt, VD, Mjukvarukraft

För ett tag sedan skrev jag ett inlägg där jag jämförde IT-branschen med byggbranschen (tidigare inlägg, här). Jag påstod, lite provokativt kanske, att vi fortfarande jobbar som man gjorde på 30-talet. Och hur vi skulle jobba om våra IT-projekt fungerade som det bygge som jag ser växa fram utanför mitt kontorsfönster i Hammarby Sjöstad. I det här inlägget ska jag ge några tips och rekommendationer på ett bättre och moderna sätt att skapa IT-lösningar, utifrån Mjukvarukrafts och mina egna erfarenheter.

I slutkant på mitt förra inlägg problematiserade jag kring några vanliga bekymmer, t ex:

  • Oklar eller obefintlig ritning (läs: ingen verksamhets-, IT- och lösningsarkitektur)
  • Proprietära lösningar (läs: lågt eller obefintligt utnyttjande av färdiga element, komponenter och tjänster)
  • Ensidig fokus på kod

Listan över vanliga utmaningar kan självfallet göras längre. Bristande förankring, dålig kommunikation, oklara ansvar, inga eller dåligt definierade krav, övertro på verktyg, underanvändning av verktyg, bristande effektmålsbeskrivning och nyttodefinition och annat tillhör vanliga projekt-bekymmer.

Kanske är det att göra det lätt för sig att påstå att lösningen på utmaningarna är att helt enkelt adressera problemen genom att t ex undvika att starta projekt utan tydliga mål, krav, en väl definierad arkitektur, informationsmodell och en genomtänkt och förankrad förvaltningsplan. Utmaningen blir ju inte heller mindre av att IT idag är en komplicerad och ofta komplex fråga; många olika system, tekniker, nya och gamla applikationer och kanske olika versioner av programvara samsas i samma IT-miljö. Och ska underhållas. Lägg där till en ökad andel Molntjänster. I större organisationer växer problemet med att slutanvändare handlar upp IT-stöd på egen hand, ofta som Molntjänster. Detta försvårar ytterligare möjligheten att genomföra större förändrings- och migreringsprojekt. De många gånger stora resurser som lagts ner i ”legacy” försvårar självfallet också övergången till modernare lösningar; kalkylen för att ekonomiskt försvara investeringar i nya lösningar är helt enkelt inte försvarbar.

Inget desto mindre. Med små steg och ett metodiskt och uthålligt arbete går det naturligtvis att få till förbättringar. Här följer några tips.

  • När vi pratar med varandra löser vi problem: människan har en fantastisk förmåga att lösa problem bara genom att träffas och kommunicera! Det självklara kan ibland utgöra den bästa lösningen; i större projekt uppnås framgång inte sällan genom bra och täta dialog mellan projektmedlemmar, men också givetvis alla aktuella intressenter. Prata med varandra. Det är sällan svårare än så.
  • Standarder och färdiga komponenter är bra grejer! Jag har haft förmånen att få jobba med standard-utveckling på global nivå (inom ISO och ITU-T) samt på nationell nivå. De standarder jag arbetat med har i huvudsak rört Molntjänst-standarder. ISO/IEC 17788:2014 definierar terminologi för och ger en översikt över Molnbaserade datortjänster (finns att köpa på SIS, här). ”Cloud Computing”, som vi i Sverige oftast refererar till som ”Molntjänster” (eller bara ”Molnet”). Många standarder kan också hjälpa din organisation att möta kraven på dataskydd av individers data enligt EU:s nya Dataskyddsförordning (GDPR). Här följer några exempel på standarder som kan underlätta ”DSF-följsamhet”:
    • ISO 29100 (”Privacy Principles”)
    • ISO 29184 (”Guidelines for online privacy notices and consent” – planeras att bli publicerad som internationell standard oktober 2019)
    • ISO 29134 (”Privacy impact and methodology”)
    • DIN 66398 (Tysk standard för borttag av data som är på väg att bli ISO-standard)
    • ISO 19944 (”Data flow, data taxonomies and data use”)
    • ISO 20889 (beskriver anonymisering av data)
    • ISO 27552 (standard som beskriver hantering av integritet)
  • Utöver ovan standarder för DSF finns det också en mängd färdiga s k ”building blocks” och resurser på EU-nivå som kan användas för att snabbt etablera tjänster, t ex inom e-Handel. För mer information, se gärna EU:s program, CEF Building Blocks.
  • Lägg lite krut på kravarbetet: jag upplever starkt att många organisationer underskattar behovet av ett gediget kravarbete, en bra lösningsarkitektur och inte minst en uppsättnings acceptanskriterier som man kan komma tillbaka till för att verifiera att aktuell lösning möter de ursprungliga kraven. Genom att lägga tid och energi på krav, användningsfall (eller ”User Stories”), arkitektur och acceptenskriterier underlättas arbetet i konstruktionsfasen och inte minst för löpande kvalitetsarbete avsevärt. ”- Men behövs detta om man jobbar agilt?”. Självklart menar jag. Agil utveckling står inte på något sätt mot ”ordning och reda”. Tvärt om. Agila metoder fungerar, enligt min erfarenhet, ännu bättre med ett bra underlag som startpunkt.

Så. ”Visionen” jag skissade på i mitt förra projekt är alltså inte någon utopi. Tvärtom. Mycket av det som inryms i nedan listan (tagen från föregående inlägg) kan nog betraktas som självklarheter:

  • En detaljerad arkitektur och konstruktionsplan har tagits fram innan konstruktionen har påbörjats.
  • All planering har gjorts på förhand.
  • Alla resurser i projektet har tydliga och välbeskrivna roller, ansvar och uppgifter.
  • Den lösning som ska tas fram baseras på färdiga komponenter (”byggstenar”) som har tillverkats externt av underkontrakterade leverantörer.
  • Projektet regleras av och utgår från tillämpbara standarder (ISO/CEN/SIS/ITU-T osv.) och kundens policies.
  • Leveranserna regleras där möjligt baserat på avtal (t ex SLA).
  • Kvalitetssäkring görs löpande.
  • Dokumentation inklusive eventuell avvikelserapportering görs löpande.
  • Förseningar tillåts inte eftersom det skulle innebära störningar i produktions-processerna.
  • Alla intressenter – kund – leverantör – underleverantörer m.m. – har ständig och tät dialog för att säkerställa att projektet framskrider efter initiala och successivt avstämda mål.

Men. ”Det lätta sagda är det svåra gjorda” (med ursäkter till Esaias Tegnér). Det gäller att få rutiner på plats. Och det gäller att formalisera det självklara. Och att uppmuntra dialog, ständig kunskapsuppbyggnad, ständiga förbättringar (heja Kaizen!) och anamma att ”ordning och reda” kan kombineras med agila arbetssätt.

IT 2.0 (3.0? 4.0?) – det är dags nu.