Category Archives: Kravhantering

Transportstyrelsens läcka förklarad

Med tanke på allt som skrivs om Transportstyrelsens läcka (eller kanske snarare ”dammen som brast”) är det många som ställer sig frågan om exakt vad det är fråga om. Jag tycker att tidningarna gör ett ganska bra jobb att förklara, men vill ändå försöka förklara det så att människor som inte själva jobbar med IT, säkerhet och databaser förstår problemet.

Jag har själv jobbat med IT på olika sätt och i olika former sedan 1990-talet (bl a drift, design, projektledning, utveckling, databas, säkerhet, upphandling/kravställning) och vet precis vad detta innebär. Och jag ser igenom de försök att skönmåla som förekommer.

Nu till huvudfrågan: varför får en myndighet eller annan samhällskritisk funktion (vissa drivs i bolagsform) aldrig någonsin göra som Transportstyrelsen? Dvs lägga ut driften av system som verksamheten är beroende av för att fungera inkl. databaser på externa molntjänster/datacentrer i andra länder?

Man skapar externa beroenden. Förlorar man kontakten med sin leverantör stannar verksamheten. För ett privat företag är det inte något stort problem. Det händer ganska sällan, och när det väl händer kan man ställa de kostnader/förluster stoppet innebär mot de besparingar/intäkter man gör. Sådana stopp beror ofta på exceptionella händelser. Krig, t ex. Och ingen förväntar sig väl att det ska gå att shoppa via t ex Webhallen eller Dustin mitt under en pågående invasion? En myndighet behöver däremot ofta fungera just i sådana situationer och får aldrig vara beroende av extern data. Samtidigt kan man faktiskt ställa sig frågan om en myndighet har de behov av skalbarhet som en molntjänst ger. Visserligen kan den externa hemsidan ha sådana behov. Men de interna databaserna? Så länge personalen på myndigheten håller sig på ungefär samma nivå och har ungefär samma arbetsbörda ligger belastningen av systemen på en ganska konstant nivå. Och de toppar som kan uppstå ibland kan man ändå ta höjd för utan att behöva ruinera sig.

Man målar in sig i ett hörn. När man väl har outsourcat driften som Transportstyrelsen gjort har man i regel också gjort dig av med alla möjligheter att själv drifta systemen. Anställda har sagts upp, infrastruktur har avvecklats, servrar har flyttats eller stängts ner. Organisationen har tappat all egen kompetens på området. Och nej, det är inte så lätt att man bara anställer nytt folk och börjar bygga upp den egna IT-verksamheten igen. Problemet är nämligen att det bara till viss del handlar om rent teknisk kompetens. Det viktigaste är verksamhetsförståelse och systemkännedom. Att bygga upp den tar ett tag för alla anställda.

För det andra förlorar man kontrollen över sin egen data. Om datan hamnar hos en osäker leverantör kan den manipuleras och modifieras utan att myndigheten i fråga vet om det. Utryckningsvägar för brandförsvaret kan ändras. Uppgifter om hur stor belastning vissa broar klarar av (läs: stridsvagn eller bara personbilar) kan ändras. En fientligt sinnad spelare kan sabotera samhällsstrukturen genom att manipulera den data som finns. Eller bara hindra myndigheten från att nå sin egen data. En DDOS-attack, för att ta någonting som många känner till? Då kan det bli stopp i myndighetens arbete eftersom systemen helt plötsligt står utan data. Beroende på hur säker anslutningen mellan systemen är vet man inte heller vilka utöver leverantören och den egna verksamheten som kan fånga upp trafiken.

Men det mest allvarliga i att släppa kontrollen över sin data är att man inte vet vem som kan komma åt den. Det har man fortfarande inte förstått på Transportstyrelsen. Katarina Fröberg säger att det inte är någon fara. De som driftar har ju inte tillgång till ”gränssnittet”. I mina ögon är det ett fullständigt genomkorkat uttalande och fel på alla sätt och vis. Det gränssnittet gör är nämligen att det begränsar tillgången till data och information! Har man tillgång till databasen – vilket man som drifttekniker i regel har – betyder det att man har tillgång till all data. Gränssnitt eller ej.

Det är sådant jag jobbar med till vardags. Jag är utvecklare och jobbar även en del med drift av olika databaser. Det innebär att jag kommer åt väldigt mycket information, liksom att jag blivit godkänd och skrivit på sekretessförbindelser för att få hantera sådant. Jag skulle tillbringa flera år bakom galler om jag missbrukade det. Och det innebär även att jag inte kommer att gå in på några detaljer om det jag jobbar med.

Men rent allmänt innebär den typen av behörighet att man inte behöver vare sig applikationer eller gränssnitt för att få ut väldigt mycket data och information.

Tvärtom, gränssnittet är bara i vägen när man väl har tillgång till databasen. Är den, som jag förmodar, välbyggd och genomtänkt kan man få fram mycket mer info genom att skriva egna databasfrågor än vad man skulle få ut via de gränssnitt som finns. Den typiske användaren av de gränssnitt som finns kan förmodligen inte koppla samman olika uppgifter med varandra, men den som har tillgång till själva databasen kan göra det. Beroende på exakt vad som finns i Transportstyrelsens databas(er) och hur långt tillbaks i tiden det finns uppgifter skulle man genom att skriva olika databasfrågor där man samkör (joinar) olika tabeller få fram t ex följande:

  • Hur många hål i tänderna piloterna på F10 i Ängelholm har sammanlagt.
  • Vilka poliser i Luleå som har släktingar som krockat med älgar.
  • Hur många bilar inrikesministerns barns yngsta dagisfrökens äldsta faster äger.

Det här är bara tramsexempel, men om uppgifterna finns i databasen kan man göra sådana sammankopplingar mellan olika delsystem som för de vanliga användarna framstår som separata system utan inbördes koppling. Många system- och databasutvecklare/databasadministratörer jobbar nämligen med just sådant till och från, men kanske med mer relevanta sökningar då.

Nu till den sekundära frågan: när kan man göra som Transportstyrelsen gjort?

Svaret är att i princip vem som helst kan göra det. Bara det inte är fråga om myndigheter eller samhällskritiska funktioner. Ibland inte bara kan man. Ibland ska man, enligt min åsikt. Om man driver ett företag som håller på med e-handel är det hål i huvudet att drifta själva e-handelslösningarna själv. Då vill man ha skalbarhet (IT-lingo för ”använda och betala för den kapacitet som behövs, men ingenting mer”) och flexibilitet. Annars måste man ha en egen serverhall som är dimensionerad för fullt tryck dygnet runt, och tekniker i beredskap som kan hoppa in när det skiter sig.

Kör man däremot t ex Amazon Web Services eller Microsoft Azure behöver man inte tänka på det. Och man behöver inte tänka på toppar heller. Eller på att belastningen är olika under olika delar av dygnet. Det är själva syftet med stora datacenterlösningar. När användarna i Europa/Afrika är aktiva sover de i Nord-/Sydamerika och Asien/Australien och behöver ingen kapacitet. Så man behöver bara dimensionera för att klara belastningen från ett visst antal tidszoner i taget. När användarna i Europa och Afrika sedan kryper till kojs vaknar man på andra sidan Atlanten, och kapaciteten används istället för att serva användarna i Nord-/Sydamerika. När de lägger sig tar användarna i Asien/Australien över, osv. Du förstår nog filosofin? Man delar på kapaciteten, eftersom alla inte behöver den samtidigt. Och skulle alla vara igång samtidigt, t ex när en ny och eftertraktad produkt börjar säljas över nätet, skalar man upp med extra kapacitet i de datacenter det handlar om.

En svensk myndighet har däremot inte det behovet och ska inte tänka så. De jobbar inte dygnet runt på Transportstyrelsen. Skalbarheten är därmed en ren kostnadsfråga. Det handlar alltså inte om att man behöver ta höjd för hög belastning, utan om att man vill slippa betala för IT-miljön under den tid på dygnet den inte används. Men framförallt handlar det om att Transportstyrelsen inte är ett företag utan en myndighet!

Så sluta leka företag om du är en myndighet. Då slipper vi det här i framtiden.

Comeback för Nokia 3310?

”Experterna sågar Nokias nya 3310” skriver Omni. Tydligen vill alla ha smartphones nu för tiden, så enligt experterna finns det ingen anledning till att köpa den här telefonen.

Nu är jag ju inte själv expert, så jag är av en annan åsikt. Jag tror nämligen att den här telefonen kan bli en succé. Eller i alla fall framgångsrik.

Så hur får man en galen idé som denna? Att utveckla en nyversion av en telefon som ursprungligen släpptes för nästan 17 år sedan? På mobiltelefonernas tidsskala är 17 år förhistoriskt. Eller för-förhistoriskt. Någonstans mellan Big Bang och ursoppans uppkomst. Någonstans måste man väl ha tänkt fel? Nej. Jag tror att de tänkt helt rätt.

Att surfa med? Den kommer att suga fett. Appar? Glöm det. Sociala medier? Kanske. Att maila? Jodå. SMS och MMS? Det funkar. Ringa med? Givetvis!

Där har vi det. De har listat ut att det faktiskt finns en målgrupp som vill använda telefonen som telefon. Det är egentligen ingenting nytt. Den målgruppen har funnits länge. Men alla mobiltelefontillverkare ser den som förhållandevis liten. Några procent av den totala kundbasen, kanske? Det skulle väl inte löna sig att fokusera på den?

Jodå. Vad man glömmer bort är att även om det handlar om relativt sett liten målgrupp innebär det väldigt många potentiella kunder. Kunder som du inte behöver konkurrera om.

Det är ganska enkelt. Säljer du det alla andra säljer blir det stor konkurrens. Men hittar du någonting som du är ensam om men som efterfrågas av många är du en vinnare. Det är grundläggande konceptutveckling: hitta en målgrupp med behov och önskemål som ingen annan tillgodoser, och bli den som tillgodoser dem. Tänk utanför ramarna.

Ett exempel för att illustrera detta samt problemet med vad experterna tycker är om du bor i en stad om vill öppna ett matställe. Allt som finns i staden är 20 pizzerior. Experterna (eller i det här fallet banken som du vill låna från) kommer att säga att du ska starta stadens 21:a pizzeria, för alla köper ju pizza här i stan. Den som gjort sin hemläxa inom konceptutveckling förstår däremot att behovet av pizza redan är tillgodosett. Att alla köper pizza beror på att det inte finns något annat att välja på. Tittar man dessutom på prisutvecklingen och ser att pizzorna bara blir billigare och billigare ser man att efterfrågan inte bara är tillgodosedd. Den är t o m mättad. Så man öppnar någonting annat. Kanske ett sushihak eller en vegetarisk restaurang. Man hittar sin nisch, helt enkelt. Och det blir givetvis svårt. Banken kommer inte att bevilja lån, eftersom man vill satsa på någonting som ingen rent historiskt sett är intresserad av. Det säljs ju ingen sushi eller vegetarisk mat så då finns det ju ingen efterfrågan.

Kort sagt, jag tror att experterna har fel. Jag tror på nya Nokia 3310: en telefon som man ringer med? Ja varför inte. Det finns många människor som vill använda sin telefon just som telefon och ingenting annat.

One size fits all?

Jag tänkte spinna vidare lite på det jag skrev om dilemmat som uppstår för en organisation när de ställs inför att antingen utveckla egna system eller köpa in färdiga: ”one size fits nobody”. Passar det färdiga systemet perfekt? Är det för stort? För litet? Eller är passformen inte riktigt rätt?

Det här är inte tänkt som något debattinlägg, utan mer ett sätt att illustrera problematiken med färdiga lösningar kontra egna för att göra den tydligare.

Eget eller färdigt?

Slide1.PNG

Ett eget skräddarsytt system som passar perfekt, eller ett färdigt system? Skissen ovan visar ytterligheterna. (Eller worst case scenario, man köper in någonting som inte används utan bygger ett eget…)

Nyckeln i figurerna nedan är överlappet. Det representerar den färdiga funktionaliten out of the box. Det vi får från leverantören. Det vi köper. Den blåa cirkeln är det system som införs i organisationen – det kan vara färdigt och det kan vara egenutvecklat, eller en kombination. Den orange cirkeln är det vi köper. Cirklarna ihop är totalkostnaden.

Exempel 1: perfect fit

Slide2.PNG

Best case scenario. Systemet passar oss perfekt, och utnyttjas fullt ut. Ingen funktionalitet saknas, men inte heller finns det någon överflödig funktionalitet. Det tänker vi oss när vi hör ”färdig lösning”. Det blir dock svårare ju mer specialiserad verksamheten är. Handlar det om standarduppgifter finns det däremot bra exempel. Office-paketet är ett: få använder det fullt ut, men i stort sett allt som ingår används av någon eller några. Och i princip ingen funktionalitet saknas.

Exempel 2: passar väl sisådär…

Slide3.PNG

Det här händer. Troligtvis har man velat köpa in ett färdigt system för någonting det inte finns färdiga lösningar för, och valt något man tror kan fungera om man bygger om och bygger till. Resultatet blir att man lägger mycket tid och resurser på införandet, men när det är klart återstår väldigt lite av det man köpte. Plus att det kanske inte är optimalt för den egna verksamheten. (Se föregående inlägg.)

Exempel 3: enkelt system som byggts ut

Slide4.PNG

Ett bra alternativ om man har egna utvecklare? Man får någonting att bygga ut. Det blir väl anpassat för den egna verksamheten, men bara en del av systemet supportas troligtvis av leverantören. Vill man skala upp får man själv betala för utvecklingen, och risken finns för att man skapar beroenden i organisationen.

Exempel 4: stort system som används till viss del/skalas ned

Slide5.PNG

Ett vanligt scenario? Ett färdigt system som kan mycket, men som ingen utnyttjar fullt ut? Man får mer än man behöver, men behöver inte utveckla eller anpassa det själv. Och det blir lätt att skala upp och införa nya funktioner i framtiden.

Exempel 5: hyfsad passform

Slide6.PNG

När vi köper in större system från större leverantörer hamnar vi kanske här om vi har ett bra underlag med tydliga krav och verksamheten inte är allt för unik. Med stor sannolikhet finns det inget system som har precis det vi efterfrågar och inte heller innehåller sådant som inte behövs. Men i det stora hela är det en bra avvägning där det inte krävs så mycket extra utvecklingsarbete och man inte heller får sådant som inte används.

Det jag tycker är värt att reflektera över när man köper in färdiga lösningar är det här ”överlappet”. Det visar hur mycket av den färdiga lösning man köper in som sedan införs i verksamheten. Det är det man får för pengarna. Därefter kommer egenutvecklingen. Är den väldigt stor i förhållande till överlappet är det inte ett standardsystem man inför, även om det var ett sådant man ursprungligen köpte in.

Om jag skulle rangordna dessa scenarion från bra till mindre bra skulle jag välja den här ordningen:

  • 1: precis rätt för verksamheten.
  • 5: kan med lite jobb anpassas och skräddarsys.
  • 4: har mer än man behöver, men ger någonting att växa i.
  • 3: ett hembygge med färdig lösning som grund.
  • 2: det bidde en tumme.

Nu vill jag dock poängtera att den här rangordningen är utifrån verksamheten jag själv jobbar i. Den är väldigt teknikberoende, specialiserad och har dessutom egna utvecklare (bl a Yours Truly) och drifttekniker. Men uppställningen kan kanske vara intressant när man tittar på system att köpa in?

Bekvämlighetsorienterar du?

Idag läste jag en väldigt intressant artikel i CIO om huruvida man ska utveckla egna system eller köpa in standardlösningar. Är hembyggena skräddarsydda system, eller uppfinner man bara hjulet på nytt? Vad är core business och vad är stödsystem? Eller gäller det omvända ibland? Att man bekvämlighetsorienterar sin verksamhet genom att köpa in färdiga system?

För min egen del är dessa frågor väldigt aktuella just nu. Dels för att jag har jobbat med utveckling inom IT i olika former sedan 90-talet, dels för att vi nu håller på att genomföra en omorganisation på min arbetsplats och dels för att trenden går mot att man outsourcar och köper in färdiga lösningar i allt större omfattning. Standardlösningar är populära.

Det finns dock ett förbehåll: att fler gör samma sak innebär inte att de gör rätt.

Svårigheten ligger i avgränsningarna, vilket tas upp i IDG-artikeln. Den tar dock bara upp en avgränsning, och det är den mellan stöd- och kärnverksamhet och följaktligen vad som är stöd- respektive kärnsystem. För Posten hör logistik till kärnverksamheten, för IKEA är kärnverksamheten inköp och försäljning, och så vidare. Du förstår nog resonemanget.

Men samtidigt finns det fler frågor som behöver svar.

  • Vad är ett standardsystem?
  • Vad innebär ”färdigt” system?
  • Var går gränsen mellan integration/anpassning och utveckling?

Det är enligt min åsikt de här tre frågorna som gör att många satsningar där man köper in färdiga standardsystem inte alltid blir som man har tänkt. För det finns många exempel på det. Läs gärna artikeln i CS om hur det gick för polisen när de skulle gå från halvfabrikatet Pust Java till ”standardsystemet” Pust Siebel. (Tl;dr: åt helvete.) Så låt oss nu titta på de här tre frågorna.

Vad är ett standardsystem?

Det är en intressant fråga. Ställ den till fem olika personer som jobbar med IT i någon form, och det är mycket möjligt att du får fem olika svar. Men om vi ska enas om en vag definition kan vi väl säga att det är ett system som funnits ett tag och har förhållandevis många användare/kunder, och som går att driftsätta nästan out of the box. Windows-familjen är standardsystem. SQL Server är standard. Office-paketet är standard. De har funnits i många år och är beprövade, och man behöver i princip bara öppna en image eller DVD och köra ”Setup.exe”. I teorin i alla fall. I praktiken är det lite mer jobb.

Vad innebär ”färdigt” system?

Där är dilemmat samma som ovan. Svaret beror på vem du frågar. Det är ett system som redan finns och som någon använder. Ungefär som i fråga om vad ett standardsystem är. Grundfilosofin är i alla fall att man inte ska behöva utveckla någonting eget, utan att någon annan redan har gjort arbetet. Allt man behöver göra själv – eller mera troligt hyra in en eller annan konsult (upphöjt i X) att göra – är att driftsätta, integrera och anpassa för den egna verksamheten.

Var går gränsen mellan integration/anpassning och utveckling?

Återigen en fråga utan ett entydigt svar. Det beror på vem du frågar. Vilket i regel leder till att man frågar den som ger det svar man helst vill ha. För det är nu vi kommer till själva stötestenen och det som gör att jag ofta ifrågasätter filosofin med standardsystem och färdiga lösningar: en del av det arbete som görs för att få snurr på dem är utvecklingsarbete (aka ”systemintegration”). Visst, systemet i sig skulle nog fungera om det inte vore för att verksamheten har andra system som det ska fungera med. Ju större verksamhet, desto mer jobb krävs för att få ihop grejerna. Men i ett vakuum fungerar det så klart.

Det var de tre frågorna, och jag har inte sett något tillfredsställande svar på någon av dem. Men varför? Enligt min åsikt för att det ofta är svårt att dra en klar och tydlig gräns mellan stöd- och kärnverksamhet. Det finns alltid en gråzon och i denna olika system och funktioner. Ju lättare verksamheten i sig är att klassa som en ”standardverksamhet”, desto mindre blir visserligen gråzonen. Coop Forum och ICA Maxi är förmodligen väldigt lika varandra. De har samma kärnverksamhet, de har samma behov och därmed kan de troligtvis använda samma system för stödverksamheten. SAS, Finnair och Lufthansa kan förmodligen också använda sig av ungefär samma system eftersom de gör samma sak: frakta resenärer och bagage till samma plats. (Medan KLMs kärnverksamhet verkar vara att via Schiphol skicka resenärer och bagage vidare till vitt skilda destinationer.) Ju fler aktörer som konkurrerar med varandra, desto troligare är det att det finns färdiga lösningar och standardsystem. Men ICA eller COOP kan inte använda samma stödsystem som SAS eller Lufthansa. Visserligen har de alla ”kunder”, men de har helt olika sorters kundrelationer. Standardisera på det viset, och vi kommer behöva boardingkort till mejeridisken på ICA.

I takt med att en verksamhet blir mer specialiserad växer gråzonen mellan stöd- och kärnverksamhet. I synnerhet om de har system som är integrerade med varandra. 

Det beror på att det helt enkelt inte finns system som sedan tidigare är byggda för den verksamhet de ska användas i. Därför gick det åt fanders med Pust Siebel för polisen. Vad polisen behövde var ett system avsett för polisarbete. Men ledningen valde i sin iver att standardisera att införa ett CRM-system (Customer Relationship Management) och försöka anpassa det för polisarbete. Och de missade det mest avgörande – polisarbete är kärnverksamhet inom polisen. Det var alltså inte fråga om ett stödsystem. Men förmodligen var Siebel om inte det bästa så i alla fall ett av de bästa alternativen bland de färdiga lösningar/standardsystem som fanns. Men för polisens arbete finns det inte några standardsystem, eftersom deras verksamhet är unik. Plus att det förmodligen saknades kompetens för att upphandla ett lämpligt system för verksamheten.

Bekvämlighetsorienterar du din verksamhet?

Att göra som polisen gjorde och införa ett system som inte är avsett för ändamålet och sedan försöka anpassa verksamheten efter systemet är ett bra exempel på det jag kallar bekvämlighetsorientering. Med det menar jag raka motsatsen till kundorientering. Att man utgår inte från kundens och kärnverksamhetens behov, utan från den egna IT-organisationens bekvämlighet. Att man försöker anpassa kärnverksamheten efter processerna, som i sin tur anpassas efter systemen vilka anpassats efter stödfunktionernas önskemål, istället för att anpassa stödfunktionerna efter systemen som anpassats efter processerna vilka i sin tur anpassas efter verksamheten. (Därför köper vi gärna onyttig hämtmat till fredagsmyset, eftersom det är bekvämare än att vi ställer oss och lagar någonting eget som vore nyttigare både för plånboken och kroppen.)

Men missförstå mig nu inte. Jag argumenterar absolut inte för att man ska ägna sig åt onödig utveckling där det redan finns fungerande lösningar. Bara en spritt språngande galen CIO skulle gå med på att låta utveckla ett eget ordbehandlingsprogram för att kärnverksamheten är missnöjda med MS Word. Men när systemen når en grad av storlek och komplexitet som innebär att det bara finns en handfull – eller inga – exempel på andra system och verksamheter av samma slag är det inte längre lika uppenbart. Det beror på din verksamhet. Kan du räkna upp flera konkurrenter som det går bra för finns det troligtvis lösningar du kan köpa in och använda. Men vilken verksamhet i Sverige som inte är polisen har med framgång använt Siebel för polisarbete? Den frågan ställdes nog inte.

Dessutom krävs det vass upphandlingskompetens för att köpa in färdiga lösningar. Du kan inte upphandla det du inte själv kan bygga, för då kan du inte heller kravställa det. Så kompetensen för att bygga eget krävs i vilket fall som helst. Kan du inte kravställa det du ska köpa in får du ditt eget Pust Siebel på halsen.