Fler perspektiv på positionering och utifrån branschens bakgrund

Detta är ännu en utveckling av tankar kring var diskussionen kring var IT-branschen står och vad vi tror behövs och utifrån vad vi ser i praktisk erfarenhet och diskussioner på forum, böcker och andra platser. Det är oftast ingen motsättning i dessa diskussioner utan bara en rad möjligheter. Det vi tror är viktigt är dock att tillföra ett perspektiv för att få till ’produkten rätt’ och ’rätt produkt’ och i farten även spara på pengar(skattepengar), resurser och tid för verksamheter.

Koppling till dialog i branschen

Det vi ser är ofta olika beskrivningar och perspektiv på verksamhetsförståelse och vi menar att detta ofta är vad som också brukar kallas ’domänkunskap’ i branschen. Det finns ofta mycket bra beskrivningar och mindsetoch som ofta är precis i linje med det som i IT-branschen kallar ’Domändriven design’ och fokus på ’public value’ vs ’organisation’. Här finns mycket som vi ser går att haka på i det perspektiv som vi vill tillföra. Särskilt intressant inom just informationsförvaltning är ’AbD-scan’(Record keeping by design) och som är väl känd metodik i grunden inom branschen och kan också göras med bra, etablerade, metodiker  t.ex ’Design Sprints’, ’Lean UX’ m.fl. Branschen har en pågående dialog kring vad digitalisering är och vi tror att med praktiska beskrivningar och exempel från verkligheten så kan detta tydliggöras. Inte minst behövs ‘praktisk kunskap’ och viktiga aspekter är även hur man riggar sin organisation och arbetssätt. Detta är exempel på sådant som ofta får för lite utrymme.

Förmågor som vi tror behövs

 V-Modellen som beskrivs här på webplatsen är en fundamental del och som också därför återkommer på flera ställen, men den ensam räcker inte, det är viktigt att vara tydlig kring både denna och andra metodiker som ofta blir en slags ‘Silver bullets’. Det finns inga silver bullets utan det är flera olika förmågor, metodiker, roller som behövs. Och då menar jag hela spannet som täcker in en verksamhets syfte och mål och hur man får system och arbetssätt på alla nivåer, i alla delar och i slutändan hundratusentals enskilda, unika rader programkod och som realiserar hundratals olika funktioner en användare använder och som alla skall fungera samtidigt på avsett sätt, tillgängligt dygnet runt, med varierande belastning och på ett säkert sätt.

På webplatsen kategoriserar vi ett tiotal olika sådana förmågor vi ser behövs. Sveriges IT-arkitekter listar också ett tiotal arkitektroller(’IASA IT-arkitektroller 2020’) för att hantera detta tillsammans med tjänstedesigners, projektledare, testare, kravanalytiker osv. och inte minst alla de som kan verksamheten och måste vara med i behov, krav, utvärderingsarbete. Dessa är de roller som behövs för att lösa t.ex DIRKS, Tom Sahlens metodik, och som jag ser det, även Recordkeeping by design. Sedan tillkommer de roller som bygger, utvecklar och driftar systemen, scrum-masters, utvecklare som i sig har ett tiotal kategorier, test, säkerhet, infrastruktur osv. Dessa två grupperingar brukar kallas ’Verksamheten’ respektive ’IT’ och mellan dessa ’The Gap’. Alltså ’Gapet mellan Verksamheten och IT’. Att dessa två grupperingar kan prata, förstå, arbeta tillsammans är den mest grundläggande förmågan för att utveckla digitala system för verksamheter.

En analogi och varför systemutveckling och arkitektur har svårt att få ingång

Analogt med byggbranschen så kan många tänka sig vara med kring form/design/behov men anlitar alltid en arkitekt. Inte minst också för stadsplanering, hur byggnaden passar in i det stora. Och många kan även ha synpunkt på byggmaterial, tekniker men har alltid en byggmästare som praktiskt leder och utför. Detta är ’over the gap’. Inom digitalisering är vem som gör detta mycket mera flytande. Sedan ’under the gap’ så skulle få lita på sig själva när det kommer till att gjuta bjälklag eller installera el eller lägga ett tak. Här är det mera analogt kring digitalisering där vi gärna lämnar till ’IT’ att bygga/köpa och drifta och vi inser vikten av en projektledare som leder och utför. Vi tror alltså gärna för mycket om oss själva vad gäller att förstå behoven, förstå helheten. Verksamheten måste givetvis vara med men det behövs ’arkitekter’, ’inredningsdesigners’, ’stadsplanerare’ även inom digitalisering, det saknas bara insikten om det. Framför allt missförstås och underskattas behovet av att ’bridge the gap’, att överföra behov till praktiska, tekniska implementationer och omvänt, tekniska begränsningar påverkar vad vi kan bygga, hur behov kan mötas. Verksamheter litar alltså alltför mycket till sin egen förmåga och detta leder till lösningar som inte motsvarar behoven, eller inte passar ihop med andra system eller verksamheten i stort.

Systemiskt behov

De tiotal förmågor vi vill lyfta fram är också systemiska, de påverkar varandra. V-modellen kan hjälpa verksamhet och IT att arbeta ihop och omvänt så behöver V-modellen då vara användbar, förståelig, tydlig. Vi närmar oss då ännu en förmåga kring arbetssätt, hur leveranser sker, med kvalitet, inom tid. Och där någonstans är det ytterligare en förmåga, en av de mest fundamentala förmågorna som är ’förbättringsloopen’, PDCA/OODA den går under många namn. Även denna måste vara praktisk och här finns många olika bra metodiker och verktyg och där man närmar sig nästa förmåga kring organisation.

Organisationens fundamentala betydelse och början på en metodik

Redan på 60-talet identifierades också att ’organisationer bygger system utifrån hur kommunikationsvägarna i organisationen ser ut’. I bred mening alltså även arbetssätt, informationssystem osv. utifrån hur dessa kommunikationsvägar ser ut. En insikt är att en kommunal förvaltning ofta bygger en organisation för vidmakthållande (av det kommunala/offentliga uppdraget). Vad detta innebär är att det kommunala uppdraget till alla delar då upprätthålls ypperligt, men det gör å andra sidan att nytänkande, innovation, förändringar kan motverkas och resultatet blir att system och sätt utanför kärnverksamheten blir fragmenterade, inte passar behov, kostar skattepengar. Erfarenhet från innovativa organisationer pekar på fundamentalt annorlunda organisationer för att råda bot på detta. Detta är också något som börjat uppmärksammas, till exempel i den fortsättning på Devops-rörselsen och som drivs av exempelvis DASA ‘www.devopsagileskills.org/’ och som även finns med i SAFE.

Vad vi vill tillhandahålla på webplatsen är att skapa självinsikt om var man som organisation står kring de förmågor vi listar. Och sedan erbjuda en praktisk väg att stärka och rusta sin organisation, hur man börjar, iterativt provar, vidareutvecklar. Främst genom att hitta och stärka medarbetares kompetens men också vilka roller man behöver komplettera med. En praktisk guide alltså, och som är agnostisk när det kommer till framför allt vem man skall köpa tjänster av, men även vilka verktyg man skall använda. ’Använd det ni har’, är grundtesen. Vi tänker oss också tillhandahålla egna verktyg.

Om branschens bakgrund o vikten av reflektion

Man måste också förstå att systemutveckling i bred mening, alltså även arkitektur, designrörelsen, den agila rörelsen är oerhört lättrörlig eftersom ’materialet’ är så lätt att jobba med, så oerhört skalbart och har typ oändligt många olika former. Utvecklingen går i en rasande fart, exponentiellt och drivs inte främst via akademi utan på bloggar, webinarier, konferenser(un-conferences), i viss mån böcker. Och den bygger alltid på praktisk erfarenhet och vad som fungerar, inom ramen för kvalitet, tid, resurser – det finns ingen annan måttstock. En metodik kan tas fram av ett team någonstans, provas under ett par månader och sedan spridas och förändra branschen inom ett år. Så var det med den agila rörelsen som i början av 2000-talet uppstod b.la som motreaktion på Rational Unified Process (som vi anser är till viss del misstolkad och därför värd att läsa och delvis tillämpa fortfarande. Molntjänster gör det möjligt att drifta med hög säkerhet och skalbarhet. Devops(integrering av utveckling och drift) gör det möjligt att prova ideer mycket snabbt för att praktiskt se vad som funkar, återigen inget annat är något värt än vad som fungerar, kommersiellt, kvalitetsmässigt, säkerhetsmässigt, användarmässigt. I början releasade Facebook mycket ofta, många gånger per dag men har över tid stabiliserat sig kring kanske ett par veckor. Andra bolag har liknande erfarenheter att uppdatera ofta och använda detta samt en stor kundbas för A/B-testning.

Sedan också, reglerade verksamheter som rymd, försvar, medicin har förstått essensen och mycket i linje med ’recordkeeping by design’ hittat sätt att ta fram digitala system, på affärsmässig grund, som är både säkra, funkar, fyller behov. Bygger på ISO9000 i grunden o specialiseras genom b.la ISO 62304(medical tillverkare) och HIPAA(medical kunder).

Allt detta har en grund i att IT, systemutveckling, arkitektur, design är en mycket reflekterande verksamhet, och som tog sin början någonstans på 60-talet. B.la genom boken ’The mythical man-month’ som även myntade ’Silver bullet’ i branschen. Den satte igång en rörelse som lett till omvälvande metodiker som på närmast filosofiskt sätt tagit över föregående.’ Strukturerad programmering’ på typ 80-tal, ’objektorientering’/’Rational Unified’ och ’processorientering’ på 90-tal. ’Tjänsteorientering’/’Agila’ rörelsen och som bygger på ’förmågebaserad analys’ på 00-talet, och sedan 10-talet och framåt har det snarast växt på bredden med varianter inom den agila rörelsen kring extremer som mob-programmering(en som skriver kod och övriga teamet står runt omkring), ledarlösa organisationer som Crisp i Stockholm och mera moderata metodiker som den framväxande designrörelsen (user/participatory-design, Design Sprints, Effektkartläggning) och skalning som ’SAFE’, ’DSDM’. Den exponentiella utvecklingen syns ju givetvis också i produkter och tjänster. Från desktop till molntjänster och stordator-PC-mobiler-Smartwatches och givetvis internet, IoT, AI, Big Data. Bakom allt detta finns också en organisation, i form av enskilda utvecklare som skriver kod, i väl fungerande team, i en organisation som fixar lön och semester och någonstans att sitta och som säljer produkter och tjänster. Det är bara att det är ’en masse’.

Ett rotproblem

Grejen är att samma problem som uppdagades på 60-talet gäller nu. Då var det många färre i branschen, systemen var enklare men resan började. Nu är vi i ett läge där många fler måste vara inblandade i digitalisering och systemutveckling, för allt skall digitaliseras. De kompetenser vi ser behövs har inte tillräckligt mycket folk som kan arbeta. Å andra sidan finns det ursprungliga ’gapet mellan IT och verksamhet’ kvar och detta har inte lösts.

 I grunden handlar detta faktiskt om en återgång från tiden före typ Platon, till det grekerna kallade ’fronesis’ praktisk kunskap. Världens svåraste problem då handlade om hur man lever ett bra liv. Nu har vi problem kring digitalisering, om än inte samma magnitud. Då kom Platon och rörde till saker o ting och inledde blue collar/white collar och i förlängnignen ’the business and IT-gap’ vilket främst den agila och även designrörelsen börjat bryta med. Då var det muntliga berättelser och extremer som dilemman(Scylla/Charybdis) och mycket i samma linje använder branschen detta idag också med hypotesdriven utveckling, A/B-tester, kritik/granskningar. Så inom praktisk kunskap hämtar branschen idag också sin inspiration.

Hur branschen pekar en väg framåt

Så, det har främst med ekonomi, självinsikt, organisation att göra anser vi och där man skall titta nu för att börja åtgärda är i ännu en framväxande rörelse som rör sig exponentiellt, ’Lean Startup’, ’Continous Product Management’, ’Lean UX’-rörelsen och som har många olika sätt redan, olika huvudaktörer. Denna rörelse ser ingen skillnad på över och under ’the gap’. Den rör sig i mycket snabba cykler, låg kostnad, korsfunktionella team(tvärs över men in linje med organisation) och den utgår från lärande milstolpar istället för leverans av funktioner vilket gör att uppgiften definieras utifrån just detta. Funktioner och produkter blir mera av en biprodukt. Där tror jag man skall börja när man närmar sig digitalisering även inom offentlig verksamhet och informationsförvaltning.