Sommarlovsteatern!

Sommarlovsteatern på P1 rockar i vanlig ordning. Nu senast har de kört en väldigt spännande och bra fantasypjäs som heter "Skämmerskans dotter". Som "skämmerska" har man gåvan/förbannelsen att i folks ögon se precis allt det som de skäms över. Lysande upplägg.

Men ack! Så har man missat några avsnitt. Som tur är finns pjäsen på webben. Men hur lösa det på landet, där inget bredband finns? Få över pjäsen på CD kanske?

Lite windowstips för den händige:

Tanka ner strömmande RealMedia

Högerklicka på länkarna, t ex första avsnittet "http://www.sr.se/p1/lovteatern/sounds/2006/sommar/1.skammerskans_dotter/1.ram" och spara filen (inte köra eller lyssna eller någonting sådant).

Öppna den här ".ram"-filen i en texteditor. Vad ser man? Aha, en URL!

rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/1.rm

URL:en pekar på själva ljudfilen.

Nu behövs ett nedladdningsprogram som begriper sig på "rtsp"-protokollet (se i början på URL:en). Jag använder FlashGet.

Bara att mata in alla pjäsens URL:er:

rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/1.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/2.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/3.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/4.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/5.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/6.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/7.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/8.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/9.rm
rtsp://lyssna.sr.se/barn/lovteatern/2006/sommar/1.skammerskans_dotter/10.rm

Ut i solen och dricka kaffe, komma in igen: klart!

Nu kan man lyssna i RealMedia åtminstone. Men få över till CD då? Eller till mp3-spelaren?

Konvertera RealMedia till t ex mp3

Nästa steg är lite lurigare. Det finns nämligen zillioner betalprogram som konverterar rm till mp3. Svårt att hitta gratisprogrammen då!

Jag använder Free RM to MP3 Converter från jodix.com.

Efter ett par minuter har jag rm-filerna konverterade till mp3.

Sedan in i CD-brännaren med mp3-orna, bränn en CD, lyssna.

Jag älskar radioteatern!

(och ja, jag betalar min TV-licens, och nej, jag kopierar inte och sprider P1:s upphovsrättsskyddade material till andra. Vad jag gör är en konvertering till ett format som jag kan lyssna på, absolut fair use ur alla synvinklar).

Snabb: Länka xsl-stilmall till xml-dokument

Så här kan det se ut:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet href="test.xsl" type="text/xsl"?>
<mitt>
    <fina>XML-dokument</fina>
</mitt>

En ny kärlek - eXist

Har ni sett den? Har ni provat den? Jag talar om min nya kärlek: XML-databasen eXist!

Vad det är? Joo...

Det är en server, skriven i Java.

Servern innehåller ett enda tomt XML-dokument. Men du kan ta alla dina XML-dokument och stoppa in i det där dokumentet. Och söka fram dem. Och göra omvandlingar med XSLT. Och allt annat XML-igt man gör nu för tiden.

Plus att du har användare och tillgänglighetskontroll (förstås). Jag kan ge dig rätt att läsa vissa delar av det stora XML-dokumentet, och ge dig rätt att skriva vissa delar, och jag kan förbjuda dig tillgång till andra delar.

Världen har väntat på en riktig XML-databas. Åååh vad många tillämpningar man velat skriva under åren, tillämpningar som hade behövt eXist. Tillämpningar som tvingats använda relationsdatabaser eller filsystem.

Alltså, förstå mig rätt. Jag ogillar XML-hajp. Jag gillar filsystem. Jag gillar relationsdatabaser. Men för vissa tillämpningar gör sig XML alldeles ypperligt.

Tack alla utvecklare bakom eXist. Jag känner att ni har gjort mitt liv lite enklare från och med nu.

Förresten, jag söker jobb!

Projektet som jag jobbar i går in i en ny fas efter semestrarna. Det har varit roligt och lärorikt, och jag har fått arbeta med väldigt intelligenta människor. Faktiskt både bland kolleger och beställare.

Men det är dags att söka sig något nytt. Jag saknar samarbetet (projektet är på väg mot förvaltning och det kommer att bli väldigt mycket ensamarbete), och jag saknar den affärsmässiga pulsen och tänket (det är ett universitetsprojekt).

Så om du känner någon som har behov av en väldigt erfaren och påhittig och kunnig systemutvecklare (med kraftig slagsida åt RUP och Java och serverprogrammering och webbtekniker) så hör av dig!

Mitt något censurerade CV kan du se här.

Mitt ocensurerade CV med alla kontaktmöjligheter kan du få se om du lämnar ett meddelande med svarsadress i kommentarsfältet nedan.

Stödtrupper och spjutspets

Ännu ett bevis för att mina predikningar om att skilja mellan stödtrupper (system som stöder din verksamhet och som dina konkurrenter har) och spjutspetsar (system som ger just din verksamhet en konkurrensfördel) inte är ett påhitt från mig lämnas oss av cio.idg.se.

Men du behöver inte lägga 50 spänn på en gräll PDF-artikel. Själva språket i blurben borde få dig att tveka. Hör bara: "ett nytt sätt att se på IT". Nytt? Tvärtom!

Det är ett gammalt och beprövat sätt. Och självklart (om man bara ser till att behandla IT som vilken annan investering som helst). Det sorgliga är att blurben har rätt på ett sätt: för många människor i ledande IT-ställning är sådana här självklarheter lika med nyheter. Men det beror mer på att dessa sitter och bestämmer över saker de inte begriper.

Undrar vad som hade hänt om samma tillsättningsprincip hade tillämpats på andra områden:

Ekonomichef! Använd dubbel bokföring med både debet och kredit. Det nya sättet att styra ekonomin!

Klinikchef! Nu behöver du inte hitta en ihålig ek på en kyrkogård att dra barnen igenom. Läs om det nya sättet att bota kikhosta på!

Politiker! Nu behöver du inte... vänta. Kanske ett dåligt exempel...

En klockren liknelse

En kommentar på Slashdot, rörande Microsofts förhållande till fri mjukvara och Gnu Public Licens (GPL):

The GPL is like a nude beach. 
It's an agreement that you are no 
going to wear any clothes on this beach.

Microsoft wants to hang out on that beach 
but not remove thier clothing.

I can't blame them; 
but the sunbathers all know that 
Microsoft is just there to ogle.

Såååå klockrent!

Installera PHP5 för Apache på din windowsburk (XP)

1. Gå till http://www.php.net/downloads.php. Klicka på PHP 5.1.4 zip package. Nu får du välja varifrån du ska tanka hem. T ex från se.php.net.

2. Skapa en mapp i C: som heter "PHP". Packa upp zip-filen i den mappen. Mappen C:\PHP ska alltså inte innehålla en mapp som heter "php" eller "php-5.1.4-Win32" eller någonting sådant, utan mappen C:\PHP ska innehålla mapparna dev, ext, extras, och PEAR, samt en massa andra filer.

3. Nu blir det lite hårigare. Gå till din Apachekatalogen C:\Program Files\Apache Software Foundation\Apache2.2\. Du ska nu ändra i en konfigurationsfil. Gå till katalogen conf och öppna filen httpd.conf i någon texteditor.

4. Sök fram en rad där det står "#LoadModule ssl_module modules/mod_ssl.so På raden under skriver du

   LoadModule php5_module "c:/php/php5apache2_2.dll"
   

5. Sök fram en rad där det står "AddType application/x-gzip .gz .tgz". På raden under skriver du

   AddType application/x-httpd-php .php
   

6. Sök fram en rad som börjar med "DocumentRoot ". På raden under skriver du:

   PHPIniDir "C:/php"
   

7. Sök fram en rad som börjar med "DirectoryIndex index.html". Efter "index.html" skriver du "index.php".

Nu behöver du göra en liten grej i ditt PHP-bibliotek. Gå till C:\PHP. Har du filen "php.ini"? Om inte, namna om "php.ini-dist" till "php.ini". Har du filen "php5apache2_2.dll"? Om inte, öppna filen http://snaps.php.net/win32/php5.2-win32-latest.zip och kopiera den därifrån till C:\PHP.

Spara httpd.conf och klicka på den lilla Apacheikonen bredvid klockan (en liten röd fjäder på en vit boll med en grön pil). Välj "Restart".

Kopiera nedanstående text i en fil du kallar test.php och lägger i htdocs:

<? echo "Hejsan, världen!"; ?>

Nu kan du testa http://localhost/test.php. Om du ser "Hejsan, världen!" men inte "echo", så fungerar det.

Installera Apache 2.2.2 på din windowsburk (XP)

Så här gör du för att installera Apache på din windowsburk (XP):

1. Ladda ner Apache, t ex från http://apache.archive.sunet.se/dist/httpd/binaries/win32/. Klicka på "apache_2.2.2-win32-x86-no_ssl.msi".

2. Dubbelklicka på den nyligen nedladdade MSI-filen.

3. I dialogen som kommer: klicka på "Next" hela tiden, eller "I accept". Detta ger dig en standardinstallation.

4. Har du en brandvägg på datorn kommer den kanske fråga dig om du vill att Apache ska vara åtkomlig på nätet. Det vill du förmodligen.

5. Avsluta installationsdialogen med att klicka på "Finish".

6. Nu har du förmodligen Apache installerat. Kör din webbläsare till adressen http://localhost. Får du upp ordet "It works!", så har du Apache

Om du gjort en standardinstallation så finns själva Apache-programmet på C:\Program Files\Apache Software Foundation\Apache2.2.

Dina hemsidesdokument finns i katalogen "htdocs" (C:\Program Files\Apache Software Foundation\Apache2.2\htdocs).

En smart grej är att göra en mjuklänk från din hemkatalog ("Mina Dokument" eller "My Documents" eller något).

Välj Start - My Documents / Mina Dokument. Högerklicka och välj "New - Shortcut / Nytt - Genväg". Du får fram en dialog där du ska skriva in sökvägen C:\Program Files\Apache Software Foundation\Apache2.2\htdocs, eller bläddra fram den.

Du får nu en genväg till dina hemsidesdokument. Genvägen ser ut som en mapp. Spara hemsidesdokumenten där.

Ja du...

Det finns postadresser och det finns postadresser:

www.k12.nf.ca

Ett fint kedjebrev till

Fick ett fint kedjebrev. Eller... javisst, det innehöll en del skrocksmörja om hemskheter som kan drabba en, och sådant är bara smörja.

Men resten av brevet var fint, och därför vill jag skicka det vidare till er:

1. Ge folk mer än vad de förväntar sig, och gör det med glädje.
2. Gift dig med någon du gillar att prata med. När ni blir äldre, blir den gåvan lika viktig som någon annan.
3. Tro inte allt du hör, bränn inte allt du har, och sov inte så mycket du vill.
4. Säger du "jag älskar dig", så mena det.
5. Säger du "förlåt, jag är ledsen", så se den andre i ögonen.
6. Var förlovad minst sex månader innan giftermålet.
7. Tro på kärlek vid första ögonkastet.
8. Skratta inte åt andras drömmar. Folk som inte har drömmar, har inte mycket.
9. Älska djupt och passionerat. Du kan bli sårad, men det är det enda sättet att leva ett fullt liv.
10. Strid rent när du strider. Inga smädelser.
11. Döm inte folk efter deras släktingar.
12. Prata långsamt, tänk snabbt.
13. Om någon frågar dig något du inte vill svara på, kom med en leende motfråga: "Varför vill du veta det?".
14. Kom ihåg att stor kärlek och stora framsteg kräver stora risker.
15. Säg "prosit" när någon nyser.
16. När du går miste om något, gå inte miste om lärdomen.
17. Kom ihåg: Respektera dig själv, respektera andra, och ta ansvar för dina handlingar.
18. Låt inte en liten dispyt stjälpa en stor vänskap.
19. När du gjort fel, åtgärda det omedelbart.
20. Le när du lyfter luren. Det kommer att höras på din röst.
21. Ta dig tid att vara ensam med dig själv.

Fina, enkla, och sanna insikter, som alltför ofta glöms bort. Sprid dem!

Tack, SuS, för dem!

The Pirate Bay

Sådär, nu stängdes The Pirate Bay, och servrarna togs i beslag. För brott mot upphovsrättslagen. Utan att ha brutit mot upphovsrättslagen. Däremot tillhandahållit en kontaktförmedling mellan människor som vill byta filer. Och bland dessa människor (belägna någon helt annanstans än på det aktuella webbhotellet, och vars datorer inte tagits i beslag, märk väl) finns det förmodligen en och annan upphovsrättsbrottsling.

Nå, jag tycker att brott mot upphovsrättslagen ska bestraffas. Men agerandet igår är skandalöst. Ett par frågor:

• Är det kontaktförmedlingens fel om två människor som fått kontakt via kontaktförmedlingen börjar bete sig brottsligt?

  The Pirate Bay är en kontaktförmedling. Själva har de efter vad jag förstår inget upphovsrättsskyddat material på sina servrar.

  Men jag undrar verkligen varför inte polisen griper brottslingarna? Vi som producerar upphovsrättsskyddat material har enligt lagen rättigheter förbundna med detta. Jag önskar verkligen se att brottslingar åker dit.

  Istället lägger polisen resurser på att gripa helt andra personer. Hmm. Om knarklangare dyker upp i närheten av mina barns skola vill jag verkligen att polisen ska gripa dessa. Jag skulle bli vansinnig om polisen istället resonerade så här:

  Hmm, låt se... knarklangare står på gatan... gatan använder asfalt... Jag vet! Vi åker till Gatubolaget och beslagtar alla asfaltskokare! Case closed!

Genier i arbete...

• Att sprida upphovsrättsskyddat material är inte brottsligt. I så fall gör varje producent av upphovsrättsskyddat material sig till stora brottslingar dagligen. Att sprida upphovsrättsskyddat material utan upphovsrättsinnehavarens tillstånd är brottsligt.

• Hur stor "collateral damage" (där tredje part drabbas) är ett samhälle villigt att acceptera? Om polisen har husrannsakningsorder på en lägenhet i ett flerfamiljshus, ger det dem rätt att raida alla lägenheter?

  Svaret på min fråga är i någon mening "ja", polisen har långtgående befogenheter. I teorin skulle de kunna söka igenom alla bilar i ett P-hus om någon av bilarna misstänks innehålla en bomb. Men denna rätt (och skyldighet) har vi medborgare gett polisen, för att vi litar på att de kan hantera den rätten ansvarsfullt. Igår togs ett stort antal andra sajter ner. Däribland sådana som sysslar med politisk opinionsbildning.

  I vanliga fall är polisen duktig på att skydda tredje part. I vanliga fall är polisen försiktig när det är grundlagsskyddade rättigheter som står på spel. Men nu verkar det juridiska förnuftet ha glömts bort på vägen.

  Om ett internationellt brottssyndikat hyrde in sig på ett hotell, och polisen avsåg att gripa lite folk, hur brukar polisen göra:

  • Samarbeta med hotellägaren, bedriva spaning, och sedan slå till utan att tredje part drabbas? Eller...
  • Raida hela hotellet och skrämma bort alla gästerna?

  Igår gjorde de det sistnämnda.

Grip skurkarna och sluta trakassera oskyldiga!

Sveriges förenade systemarkitekter

Ovanstående googling gav i sökande stund svaret "...matchade inte något dokument" (fast från och med i natt kommer väl detta inlägg upp kan jag tro :-/)

Men hursomhelst: det känns som om det börjar bli dags. Konkretisera yrkesrollen. Formulera branschetiken. Synliggöra nyttan. Få en stiff förkortning efter sitt namn: Ola Berg, Systemarkitekt SFSA

Håller ni med?

Definiera "fungerar"

I en av de intressanta bloggarna på CIO.com, kom en kommentar upp. Inlägget handlade om när man kan säga att data mining (hitta tendenser utifrån en massa data) fungerar. Kontexten är amerikansk terroristbekämpning (vad annars?) men är tillämpbart överallt.

Ett tekniskt svar på frågan om det fungerade var: "Genom data mining har vi fått ner antalet misstänkta fall från 1 på tio miljoner till 1 på tio tusen." Kochs mer kontextuella invändning: "Men fortfarande gäller samma fråga: 'hur hantera en stor mängd falska positiver?'"

Och det är ju helt sant. Skillnaden med data mining är förvisso en tusenfaldigt större träffsäkerhet. Men det grundläggande problemet har man ju inte löst: hur skilja agnarna från vetet? eller snarare: hur undvika att skada allt detta vete i jakten på ett litet skräpagn? Vad man gör med data mining är att man minskar sökrymden för andra, mer träffsäkra men kostsammare metoder. Man underlättar för det andra steget. Men behovet av detta andra steg kvarstår: då man ska göra något intelligent med det man faktiskt funnit.

En insiktsfull läsare kommenterar:

[snip] ...any data mining solution succeeds or fails based on a) how the business logic is set up in the first place, and b) how "error conditions" are handled.

Man kan stryka "data mining" från ovanstående, uttalandet blir lika sant oavsett system och metod. Allt står och faller med att verksamhetslogiken i sig är bra, och logikens användbarhet beror till största delen på avvikelsehanteringen.

Aldrig blir det så tydligt som när man är i kravfångnings- eller verksamhetsmodelleringsläge och tar fram användningsfall. Ett enkelt jobb kan det tyckas, så länge som man bara beskriver huvudflödet i ett användningsfall. När man däremot kommer till avvikelserna, det är då det börjar bli lurigt. Det är då det går upp för verksamheten exakt på hur många sätt det kan skita sig. Och att verksamheten ofta inte tänkt igenom hur man hanterar dessa avvikelser.

Det är inte ovanligt att avvikelsebeskrivningarna upptar tio gånger så stor plats som huvudflödet. Och då kan man också räkna ut att det är i avvikelserna som ett system eller en process visar sin differentierande sida. Det är genom att jobba med dem som man kan skapa konkurrensfördelen.

Det går bara att baka kakor på ett begränsat antal sätt (för att återvända till bageriet i mitt bludder om mjukvaruekonomi tidigare). Men det går att hantera brända kakor, trasiga förpackningar, skiftande mjölkvalitet osv. osv. på hundratals olika sätt.

Så tänk till i det andra steget. Tänk över avvikelserna. Och tro aldrig att en teknisk lösning, hur bra den än är, gör att du slipper tänka över dina processer!

Krav != lösning

I avdelningen "Märkliga förväntningar" har turen nu kommit till

Jag ställer kraven, du programmerar lösningen.

Jovisst, det är sant att kraven ska komma från verksamheten. Det är verksamheten som ger intäkten och systemen ska stödja verksamheten.

Och jovisst, det är en utvecklingsavdelning som ska leverera lösningen. Det är deras jobb.

Men däremellan är det inte lika enkelt.

För det första: vad är skillnaden mellan krav och utveckling? Egentligen?

I den stund en tanke väckts på en förändring någonstans, så är utvecklingen igång. Så verksamheten utanför utvecklingsavdelningen är i någon mån utvecklare.

Och även om lösningen ska fungera i verksamheten, så ska den ju först och främst fungera. Vilket betyder att den inte enbart är underkastad verksamhetskrav, utan en hel dröse andra krav som har med IT-systemets egenskap av att vara IT-system att göra. Så utvecklarsidan är på samma sätt i någon mån kravställare.

Och då inträder den intressanta situationen att dessa krav gärna är i konflikt, att vi har en zon där muren mellan kravställare och utvecklare inte kan upprätthållas. Och konflikter måste som bekant lösas. Hur?

IT ska inte styra verksamheten. Verksamhetskraven har alltid prioritet över IT-sidans invändningar.

Ett klassiskt sätt att skjuta sig i foten, som mest avslöjar att man inte riktigt förstår sig på IT-sidans invändningar. Och därmed inte sin egen verksamhet heller. Från den stund man blandat in IT i verksamheten, är IT en del av verksamheten.

IT är verktyg, på samma sätt som telefonsamtal, grafiska manualer, säljkampanjer, fabriksgolv, logistikkedjor, you name it. Verktyg har egenskaper. Försöker man sig på att styra verktygsanvändning utan att förstå sig på hur dessa egenskaper påverkar siffrorna i årsredovisningen, går det vanligtvis åt pepparen. Säljkampanj utan kunskap om kundpsykologi, logistikplanering utan geografikunskaper, beslut om IT-stöd utan kunskap om informationshantering och tekniska begränsningar... Hejdå, vinst!

Så hur bör man göra då?

Jo:

1. Ta fram verksamhetskraven. Med prislapp (vad tjänar vi på att få kravet uppfyllt).
2. Låt en människa som är kunnig i både IT- och verksamhetskrav hjälpa dig att skärpa och tvätta kraven, så att både människa och maskin kan bli nöjda med den.
3. Låt en duktig människa ta fram en design som löser problemen. Förvänta dig inte att designen ska implementeras på en gång, det är alltid bättre att ta det i etapper (iterationer). Ofta leder etapp 1 till att de ursprungliga kraven förbättras. Det är därför som RUP och andra iterativa utvecklingsmodeller fungerar så bra.
4. Sätt dig in i vad designen innebär för din verksamhet. Det är designen du kommer att leva med under systemets livslängd (och ofta längre än så, vanligen behåller man en design i flera system).
5. Fatta beslut kring designen. Sådär. Nu har du och din verksamhet försvurit er åt designen. De lösningar som framgent kommer att förverkligas, kommer att ske inom designen.

För varje verksamhetskrav finns det hundra designer som kan lösa kravet. Varje design har egenskaper som kommer att påverka din verksamhet på det ena eller andra sättet.

Därför är det så viktigt att du skiljer mellan krav (som är din verksamhets problemformulering), och den lösning som du vill införa.

Så när någon säger:

Jag ställer kraven, du programmerar lösningen.

...så säger denne egentligen:

Jag ger dig bara en liten del av kraven, och jag bryr mig inte om vilken design du kommer upp med, och jag struntar fullständigt i hur din lösning kommer att påverka verksamheten i framtiden.

Och det tycker jag är ett märkligt sätt att förhålla sig till sin egen verksamhet.

Grunkvärde i praktiken

Här finns ett exempel på grunkvärde i praktiken. Det är ett whitepaper som förklarar dåliga saker att göra om man har en applikationsserver. Nästan längst ner i dokumentet finns precis det slags IT-matematik som är så enkel och så viktig, men som så sällan görs (är det för enkelt?).

Räkneexemplet denna gång gäller vad nedtid kostar (=vad systemet är värt). Formeln i ett av fallen (en webbshop) lyder:

Antal transaktioner per timme x snittvärdet av varje transaktion).

I ett annat fall är det en affär som både har webbshop och vanlig butik. Systemets andel i processen är 50% (är systemet nere sker bara hälften av transaktionerna):

Antal transaktioner per timme x snittvärdet av varje transaktion x systemets andel

Folket på IBM använder dessa enkla formler för att visa hur dyrt det kan vara att fuska med kvaliteten. I pappret listas de elva vanligaste sätten att fuska med kvaliteten som de stött på när de besökt kunder som haft problem.

Samtliga fusk härrör från tagna affärsbeslut. Inget kan härröras till dåligt handhavande från den tekniska personalens sida. Inget beror på dålig programmering. Även de få fall i pappret där rena applikationsfel är källan till problemet, är det inget fusk från utvecklarnas sida. Allt ligger i investeringsbeslut rörande process, metodik, hårdvaruinköp, resurser avsatta till dokumentation. Investeraren bär ansvaret för investeringens ekonomi, ingen annan.

Slacka begåvat

Tom Demarco (mannen som skrev "Peopleware", boken om människorna i systemutvecklingen) har även skrivit: "Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency".

En bra bok som handlar om skillnaden mellan "busywork" och "business", och om hur letandet efter TotalEffektivitet(tm) inte är så effektivt alla gånger.

Egentligen är det inte så konstigt. Vill man vinna effektivitet genom att minska sina marginaler, sina buffertzoner, så blir resultatet välfungerande när det fungerar, men oerhört skört.

Man kan likna det vid bilkörning. Kör man fort, så minskar marginalerna. Tricket (som ju varje bilförare vet) är att dra på när man är på en gles motorväg i bra väder, men sakta ner när man kör i en korsning.

Ibland är verksamheten motorväg (målet är klart, alla rusar åt samma håll, det finns utrymme). Då ska vi dra på. Ibland är det korsningar (många andra trafikanter att hålla reda på, målet eller vägen dit är inte glasklar). Då ska vi hålla igen.

Dagens lästips

Mer klokskap. Denna gång är det Thomas Murphy som ger goda råd.

I korthet:

• Koordinera utvecklingen med resten av verksamheten. Det är ett ledningsjobb att stå för den koordinationen. I det ledningsjobbet ingår att lyssna på de olika intressenternas krav och samordna dem.
• Driften är en användare av systemet. Glöm inte bort driftens krav.
• Håll ordning på grunkportföljen. Bokför applikationerna enskilt så att ni ser när det är dags att byta ut dem.
• Tillämpa en arkitektur för företaget, och se till att driftsatta applikationer följer den. Det är svindyrt med applikationer som inte följer arkitekturen.

http://www.ftponline.com/special/lifecycle/murphy/

IT är inte svårt

Klockrent från cio.com:

Here are smart people being paid major salaries making important business decisions. And they are flying blind when it comes to IT. Executives have figured out finance, marketing, mergers, manufacturing and so on. Time to add IT. It’s not that hard.

Exakt. Precis. Word. Just det.

Det är ju inte så svårt!

http://blogs.cio.com/whats-the-matter-with-business-executives

5 miljonerkronorsfrågan

Låt oss låtsas att du har en IT-avdelning. Den kostar 10 miljoner om året. Men trots att den inte får direkt fler system att ta hand om, så levererar den sämre och sämre resultat, för lika mycket pengar.

Nu säger de som arbetar där att de går på knäna. Du tror dem inte riktigt, så du ber att få se vad de lägger sin tid på och ser att de förmodligen har rätt, de har alldeles förfärligt mycket att göra.

Nu räknar de ut att de skulle behöva öka sin budget med 5 miljoner kronor, till 15 miljoner om året. Ska du acceptera? Och hur blev allt så dyrt, plötsligt?

Vi kan beskriva situationen med följande diagram:

Detta är den förväntade nyttan av IT-avdelningens arbete. Vid nollpunkten, längst till vänster, ligger den i paritet med sin driftskostnad på 10 miljoner.

Men det här är den verkliga situationen. Kostnaden är densamma, men nyttan går ner över tid. Kraftigt ned till och med, om det får fortsätta:

Det som händer här är vad som skämtsamt brukar kallas för "bitröta", eller software rot

Bitrötan är på skoj (databitar ruttnar i allmänhet inte), men allt runtomkring systemet rör på sig. Hårdvara blir sämre, ny hårdvara kräver nya operativsystem som kanske har en lite annorlunda hantering av saker och ting, osv osv.

Men i allmänhet beror det på att själva verksamheten ställer något annorlunda krav nu än tidigare på samma system. Datamängder ökar, nya slags transaktioner ska in osv osv.

Även om man underhåller sina system och programmerar in ny funktionalitet, så kan en ursprunglig design eller arkitektur bara tänjas till en viss gräns. Till slut tar kostnaden för all handpåläggning osv ut sin rätt.

Denna ökade arbetsvolym är det gröna fältet nedan:

Det gäller alltså att vara förutseende, och inte anta att ett driftsatt system kräver lika mycket underhåll dag 1 som dag 700. Redan från början ska man planera in tid för en ordentlig översyn och omarbetning av systemet. Givet en "normal" förändringstakt i omgivningen, så är två år en bra tumregel. Men bara som tumregel, verligheten kan se annorlunda ut i dina omgivningar. Allt beror på hurpass robust designen var från början (hur väl man lyckades förutse vad som komma skulle), och hurpass oförändrad din verksamhet är.

Poängen är att alla ska vara medvetna om detta, redan från början. Och två år är ingen dum avskrivningstid. Skulle ditt system ha klarat sig väl på den tiden, så har du en stor fördel under omarbetningen, i det att du kommer att kunna återanvända såpass mycket. Att göra fel åt andra hållet däremot (förutsätta stabilitet över en femårsperiod, men tvingas till förändringar tidigare), är inte ekonomiskt.

Det handlar ju om att stipulera den tid som du ska räkna hem systemet på. Frågan är om man vågar lita på en tidsperiod som är längre än två år. Det är ju mycket som kan hända.

Nå, ska du stillatigande acceptera en ökning av driftsbudgeten med 5 miljoner? Kanske, men förmodligen inte. Inte innan du vet vad du får för pengarna.

Allt vad IT-avdelningen tar sig för är inte lika effektivt. Alla delsystem är inte lika illa däran. Vad du bör göra är att lämna den klumpvisa "IT-drift"-posten åt sitt öde. Den säger ingenting om hur väl spenderade enkronorna är. Istället ska du ta reda på vad det är för system (och tjänster) som du har i verksamheten, och ställa deras kostnader emot intäkterna, vart och ett för sig.

Förmodligen kommer du att behöva rucka på dina prioriteringar på köpet. Du kommer att se vad du betalar för. Du kommer att kunna rätta munnen (IT-behovet) efter matsäcken (IT-tjänsterna) på ett mycket bättre sätt. Och du kommer att frigöra resurser som kan ta itu med den långsiktiga förbättringen av din plattform.

Det är det som är business alignment. Din verksamhet ser över sitt IT-behov, och ändrar sina krav så att det verkliga IT-behovet blir uppfyllt.

Kanske kommer du att finna att 15 miljoner inte är en orealistisk IT-budget. Men du kommer att ha koll, inte bara på vart de nya fem miljoner kronorna går, utan vart alla femton miljoner går. Du skaffar dig koll, och det är bra att ha. Kanske har dina konkurrenter redan koll.

Men om man vill förnya då?

Jag var lite elak här. Det handlade om Bob Suh från Accenture som i Computer Sweden sade att väldigt många företag dröjer för länge med att uppdatera sina system.

Jag gav honom rätt, men hade inte mycket att ge dem som faktiskt redan satt sig själva i klistret, annat än dessa ord:

Verksamheten måste för det första fatta att det man betalar för nu är priset för gamla synder. Man valde en väg för två år sedan (eller tidigare) som kändes enkel, men som blundade för avskrivningstiden för systemet.

Så visst OK. Vi blundade för det. Vi får ta konsekvenserna. Men vad i hela friden gör vi nu, då?

Så som ett svar på den frågan följer här min punktlista för hur ni ska bära er åt:

• Planera för en uppdateringscykel. Alltså en sådan ni redan borde ha planerat för. Lägg den gärna en liten liten bit in i framtiden, så att ni har tid att skaffa er utrymme för den. Om det är något som måste patchas eller joxas ihop precis nu, så gör för allt i världen det först, men börja sedan uppdateringscykeln.
• Börja en första kravfångningsrunda, a la RUP. Dvs identifiera de drabbade, deras problem, samt problemens kostnad. Det är nu ni inser hur bra det var att ni redan har bokfört per system: nedtid, handpåläggningstid osv så att ni har god koll på kostnaderna. För det gör ni väl, bokför?
• Genomför rotorsaksanalys (ställ frågan varför till problemen lika många gånger som en femåring frågar "varför"), så att ni får grepp på de riktiga problemen. Kolla kostnaden för dem. Problemens kostnad är taket på lösningens budget.
• Prioritera. Här kan jag inte hjälpa er, men ni borde ha ett gott underlag vid det här laget.
• Skissa på en arkitektur som löser problemen. Fokusera på de viktigaste problemen. Se om inte den arkitekturen kan implementeras stegvis.
• Skapa rum för att utveckla lösningar (i både process och system) för det första steget. Kanske inser ni nu att ni först och främst måste ta hand om något gammalt skrot som hindrar er oproportionerligt mycket; och därigenom vinna handlingsutrymme. Se vad som kan göras med egen personal, och vad som kan göras med inhyrd.
• Gör en projektplan för steg 1 och sälj in den stenhårt till hela organisationen. Ge den ett namn, och kommunicera precis vad som ska ske i steg 1. Blanda inte in de övriga stegen. Folk blir förvirrade om de måste hålla isär era löften för steg 1, och era drömmars mål (efter steg 2, 3, 4, 5 osv). De tror bara att ni lovar att alla problem ska lösas i steg 1.
• Börja utvecklings och införandeprocess för steg 1, i enlighet med en god, iterativ, affärsdriven utvecklings-/införandemetod *host*R*host*UP t ex.
• Leverera iterationerna och gör alla hysteriskt glada över förbättringarna.