Fundament - en smart mojäng

Processorer

2010-11-22T13:15:00.002+01:00

En central funktion i Fundament är möjligheten att länka samman flera resurser, så att resurs A ingår i resurs B, som tas om hand av resurs C. En sådan länkning kallas för en kedja:

/path/to/resourceA/path/to/resourceB/path/to/resourceC

Ovanstående länkning kan bara fungera om resurserna A och B faktiskt har förmågan att hantera andra resurser. Att resurserna A och B är processorer. Vissa filtyper har processorer knutna till sig. Till exempel kan varje XSLT-fil generera en XSLT-processor:

/path/to/file.xsl/!proc/

Subresursen /!proc är namnet på själva processorn, både för XSL-processorer och andra. På så sätt kan man uttrycka att en viss XML-fil ska processas av en viss XSL-fil:

/path/to/file.xsl/!proc/path/to/file.xml

Informationsmodellen

2010-11-08T21:44:00.008+01:00

Fundament är en kollektion av resurser, ordnade i ett träd, precis som i ett filsystem. Resurserna kan vara filer, eller databastabeller, eller enskilda värden, eller vad som helst:

http://viggo.nu/examples/
http://viggo.nu/examples/some.txt
http://viggo.nu/examples/some.txt/!lines/
http://viggo.nu/examples/some.txt/!lines/23
http://viggo.nu/db/Persons/
http://viggo.nu/db/Persons/Ola
http://viggo.nu/db/Persons/Ola/!attrs/
http://viggo.nu/db/Persons/Ola/!attrs/shoeSize

Men antingen resursen är en mapp eller fil eller ett enskilt värde, så är resursen i Fundaments ögon ett exempel på basinformationsmodellen. Enligt basinformationsmodellen är varje resurs i stort sett en databasrad: en lista med attributvärden.

Vilka attribut som en resurs har är beroende av resursens typ. För en tabellrad i en databas är attributen förstås detsamma som tabellens kolumner. För en fil är det filattributen.

Precis som en databastabell definierar resurstypen en sekvens med attribut som utgör resursens primärnyckel. För en fil är det attributet name. För en tabellrad är det tabellens primärnyckel, antingen den är singulär (t ex Person.id) eller sammansatt (t ex kombinationen Dog.name och Dog.ownerId).

Dessutom kan resursen ha barn, om resurstypen är en sk kollektion. En mapp i ett filsystem är en kollektion, medan en vanlig fil inte är det. En tabell i en databas är en kollektion, medan en rad i tabellen inte är det.

Kollektioner:

http://viggo.nu/examples/
http://viggo.nu/db/Persons/

Inte kollektioner:

http://viggo.nu/examples/some.txt
http://viggo.nu/examples/some.txt/!lines/23
http://viggo.nu/examples/db/Persons/Ola
http://viggo.nu/examples/db/Persons/Ola/!attrs/shoeSize

Splitters är kollektioner, det är ett sätt att aktivt omvandla singulära element till sök- och traverserbara kollektioner:

http://viggo.nu/examples/some.txt/!lines/
http://viggo.nu/db/Persons/Ola/!attrs/

Vid traversering genom trädet krävs det att varje föräldrakollektion kan leverera ett barn givet ett id-uttryck. Varje mapp- och filnamn i kedjan är ett id-uttryck.

http://viggo.nu/examples/
http://viggo.nu/examples/aFolder/
http://viggo.nu/examples/aFolder/aFile.txt

Id-uttrycket är helt enkelt primärnyckeln (i fallet filer och mappar: värdet av attributet name). När det rör sig om sammansatta nycklar blir id-uttrycket detsamma som de två nyckelvärdena med ett komma emellan:

http://viggo.nu/examples/db/Dogs/Ola,Fido
http://viggo.nu/examples/db/Dogs/Ola,Laban
http://viggo.nu/examples/db/Dogs/Arne,Fido

Förutom attribut (där vissa ingår i primärnyckeln), och eventuella barn, har varje resurs en binär representation, dvs en serie bytes (enligt en viss MIME-typ) som returneras när man surfar till resursen.

Vad denna binära representation består av bestäms av resurstypen. För en fil är det naturligtvis filinnehållet. För en mapp är det innehållet i indexfilen precis som på en vanlig webbserver.

Innehållet är i alla hänseenden ett automatiskt attribut, alltså ett resursattribut som du inte utan vidare kan sätta direkt, utan som bestäms av värdet av andra attribut.

Innehållsattributet har ett särskilt namn: !content.

Adresserbarhet

2010-11-08T17:28:00.003+01:00

En av de saker som internet har lärt oss är finessen med att allt data är adresserbart. Det är URL:en (Uniform Resource Locator) som är själva grejen. På webben, i sitt originalutförande, är varje dokument adresserbart:

http://example.com/some/file.txt
http://foo.bar/baz/garply.gif

REST-api:er försöker göra varje dataelement till en adresserbar resurs:

http://data.com/Persons/Ola
http://shop.com/Articles/135

I Fundament är varje dokument, varje dataelement, och varje del av ett dokument adresserbara. Dokumentdelarna görs adresserbara genom att man låter olika splitters dela upp dokumentet. En splitter är t ex !lines som kan dela upp textrepresentationen av en resurs i dess rader, där varje rad blir adresserbar med dess radnummer:

http://viggo.nu/example/some.txt/!lines/32

En annan splitter är !attrs som gör attributen för varje resurs adresserbara individuellt. Notera att de två förstnämnda exemplen pekar på samma datamängd:

http://viggo.nu/example/some.data
http://viggo.nu/example/some.data/!attrs/content
http://viggo.nu/example/db/Persons/Ola/!attrs/shoeSize
http://viggo.nu/example/some.txt/!attrs/lastModified

En väldigt dynamisk splitter är !split som splittar på ett regex:

http://viggo.nu/example/some.txt/!split/%25;/

Notera att varje splitter är en kollektion. Det gör att det går att söka i kollektionen, loopa igenom den, osv. Men allt sådant tar vi en annan gång.

Tillbaks i världen

2010-11-07T21:10:00.002+01:00

Tjo. Det har gått tre år sedan jag skrev här sist, och mycket har hänt. Den gamla BOX-servern har utvecklats till att bli Fundament, en vänlig webbserver där folk som utformar gränssnitt till webbapplikationer lätt kan knyta samman funktionerna som finns förprogrammerade i servern. Samma serverprogramvara till många olika applikationer alltså.

REST-inlägg på firmabloggen

2007-04-10T11:28:00.000+02:00

Kolla... http://jsolutions.se/?p=111

LOST - Lowly Old School Transfers

2007-04-09T10:29:00.001+02:00

A simplified, old-fart-stupid-web-0.9-compliant-dumbed-down-rest-file-transfer-protocol

I publish this in English since my frustration is to be heard all over the world.

After having developed at least three clean, nice, and neat RESTful file and application servers in PHP (for plain vanilla Apache installations), when deploying it at my web hotels' (servers outside my control), I discovered a lot of problems:

First: the authorization headers. Stupid safe-mode schmafe-schmode that restricts my scripts from reading those headers.

Then: the firewall only let GET and POST through!

Gnash gnash!

RESTfulness is beautiful, but since the world doesn't understand the economic value of protocol beauty, we have to go ugly.

My former take on the problem, the BOX server, was competent but a bit too complex.

Need to restate the problem: never mind the full functionality, here's the BAG (Bare-bones All Good) server, implementing Lowly Old School Transfers.

Workings

The URL space of LOSTful servers only references one type of resource: the folder. LOSTfulness is about storing and getting chunks of octets in folders. Folders are named using a path. Octet chunks are named using a file name.

Only two HTTP verbs are used, the plain old comrades GET and POST.

The folder itself understands more verbs.

GET

LOSTfulness in its most primitive form only recognize GET to the folders.

GET /foo/bar?name=my_file.txt

...returns the octet chunk that has its name property called "my_file.txt".

This ensures the RESTfulness of LOST: GET is still a safe operation.

POST

POSTs are not safe (they change stuff on the server), but should be idempotent (POSTing the same message twice should not mean something else than POSTing it once or trice).

For putting octet chunks at the server, we use the file-upload mechanism (POSTing "multipart/form-data").

For other verbs, we have to resort to command message postings.

Delete: cmd=del&name=my_file.txt

Removes the my_file.txt at the folder.

Security: user=foo&pass=qwerty

Basic authentication is used.

For legacy support, POSTing or GETting user/pass pairs will result in a session id header.

The security domain is a folder and all its subfolders.

Tailer i ny version!

2007-04-04T08:29:00.001+02:00

Nu kan man dra och släppa filer på antingen adressfältet eller det stora fältet.

Vidare finns där en knapp för att bläddra i filsystemet. Pause/Play-knapp med symboler för att pausa det aktiva bevakandet av filer.

Återstår: Copy (från cut-copy-paste) samt möjlighet att öppna flera fönster. Det sistnämnda är kanske inte så viktigt, det är ju bara att öppna fler Tailers.

http://fundament.se/tailer.jnlp

(http://fundament.se/tailer.jnlp, http://fundament.se/scrap.jnlp, http://fundament.se/sock.jnlp)

Liten idé

2007-03-27T15:14:00.000+02:00

Idé som jag kanske kommer att implementera någon dag, eller också inte:

För att lösa brandväggsproblemet med instant messaging brukar man ibland låta meddelandena läggas på en server som man sedan pollar. Detsamma gäller P2P-applikationer.

Nå, inte ska väl en så enkel operation behöva olika implementationer? Visst är det där bara en instans av fall där en REST-filserver skulle göra susen. Tjipp-tjopp-skriv till URL. Tjipp-tjopp-hämta data vid URL.

HTTP for the win.

Vi har spelat in musik

2007-03-25T14:02:00.000+02:00

Jag och min vän Paul har, som vissa av er vet, en liten duo där vi spelar lite musik och sjunger ihop. Nu har vi gett oss till att spela in lite (tack vår musikaliska klippa P för all hjälp och begåvat dobro-spel):

Lyssna på! No Admittance har Paul skrivit, Hurt har jag skrivit, och One by One har vi skrivit tillsammans.

Update

Kanske ska byta namn på bandet. "EK" är tydligen även mexikansk dödsmetall (tack Tomas för påpekandet): EK.

Underbart

2007-03-21T12:19:00.000+01:00

http://www.flickr.com/photos/joshclark/383000936/

Fundament Tailer ute!

2007-03-15T00:55:00.000+01:00

Det tog en kväll att svänga ihop en första Tailer-implementation.

http://fundament.se/tailer.jnlp

Peka ut den fil du vill "taila" (skriv sökvägen i fältet). Pausa om du tycker att den behöver lugna sig.

Ska försöka få till ett multifönster också där man kan taila flera filer samtidigt, och som kommer ihåg vilka filer man tailade... En "Bläddra"-knapp bredvid fältet, bokmärken, refresh-knapp, symboler för "Paused" och "Running"... listan kan göras lång.

Men först måste jag försöka få ut RedNote.

EDIT: En vän saknade även möjligheten att dra och släppa filer på textarean/adressfältet. En god idé.

Mina två populäraste inlägg

2007-03-14T12:45:00.001+01:00

Det mest efterfrågade på denna blogg, om man ser till statistiken, är mina två hurmangör-dokument om Apache 2.2 på Windows, samt PHP till densamma.

Nu fick jag reda på igår att det är lite svårt att söka fram dessa två, alltså repriserar jag deras URL:er här.

Varsågoda, Installera Apache 2.2 och PHP 5 på Windows:

PDF Scrap, trädräddaren i nöden.

2007-03-14T12:04:00.000+01:00

Heh... Jag ska hålla en kurs i IBMs Message Broker. Kursen är skriven av IBM själva och innehåller en lärarhandledning på ...780 sidor !!!!

Mitt inre öga ser hur skogen mals ner och massafabrikerna tjänar multum.

Nå, mitt yttre öga är ganska gott och klarar att läsa liten text. Därför utökade jag Scrap PDF igårkväll med "Arrange 2x2".

Se till att din infil är stående A4, genom att skala till det (drag och släpp den på "Scale to A4").
Drag och släpp din fil på "Arrange 2x2". Sidorna arrangeras 4 och 4 på stora ark.
Skala ner till stående A4 igen (drag och släpp).

Sådär, nu är sidorna förminskade fyra gånger och monterade fyra och fyra på A4 ark. Sparar skog, sparar bläck.

http://fundament.se/scrap.jnlp

jsolutions.se

2007-03-13T22:49:00.000+01:00

Har dessutom en text på G om REST. Fast den får komma upp på firmabloggen istället.

2007-03-13T22:38:00.000+01:00

Lite nya ideer och progressrapporter...

För det första saknar jag tail så att jag kan dö. Tail tillhör definitivt ett av de fundamentala verktygen, och sålunda bör fundament ha en implementation. Jag funderar på att göra den url-baserad dock, det är ju ändå 2000-tal. Men det kan bli lite lurigt, eftersom tail bygger på att läsa filer bakifrån, medan url:er handlar om att suga i sig resurser framifrån.

Jag drömmer fortfarande om det goda databasverktyget. En vacker dag kommer det, jag lovar.

Min gamla ide om en texteditor som minns allting tidsmässigt börjar så smått bli färdig. Den heter RedNote och funkar som ett superviktigt anteckningsblock.

Kommer förmodligen efter Tailer. Och Zap. Zap är en komprimerare/dekomprimerare. Drag och släpp mappar på komprimeringsikonerna, och det blir en komprimerad fil. Drag och släpp en komprimerad fil, och den kommer att bli en avkomprimerad mapp. Alltid mapp. Man ska aldrig behöva tveka om filerna packas upp hej vilt, eller om de packas upp i en snygg mapp.

Födda: Fundament Scrap

2007-03-13T22:24:00.000+01:00

Nuså. Undertecknad proudly presents PDF-mojängen från garaget: Fundament Scrap. Gör så här:

Se till att du har Java 6 installerat på din burk.
Klicka på länken http://fundament.se/scrap.jnlp
Drag och släpp dina PDF:er på någon av ikonerna. En ny PDF skapas i samma mapp som den gamla.

Jag gjorde den här för att jag gillar hemgjorda häften. Gör så här:

se till att originalet är en PDF med jämnt antal A4-sidor (vid behov: skala till A4).
Skapa häfte (Create PDF Folder).
Skala till liggande A4 (A4 Landscape).

Nu har du fått en PDF som är sådan att om du skriver ut den dubbelsidigt, så är det bara att vika och häfta i ryggen (som en serietidning). Och jo: du måste lita på mig. Jag tänker inte skaffa ett certifikat, för allvarligt talat, om jag skaffar ett certifikat, hurpass mycket säkrare blir du då egentligen?

Aforism

2007-03-03T10:17:00.000+01:00

Himlen och helvetet är samma plats för systemutvecklare, en plats där man i evighet tvingas använda de system man själv utvecklat.

Och Ziggy fanns där sedan gammalt

2007-01-28T18:40:00.000+01:00

Ziggy Stardust

Nu även bouldevard of broken dreams

2007-01-28T16:44:00.000+01:00

Även Boulevard of Broken Dreams (Green day) finns i XML-format.

Virtuella kontanter

2007-01-27T19:56:00.000+01:00

En idé till: virtuella kontanter.

Tanken är inte ny, men har aldrig riktigt lyft. Här är mitt förslag:

Var och en kan ge ut sin egen valuta. Det som krävs är en hemlis. Genom att ange min egen hemlis, så kan jag ge ut min egen valuta.

Låt oss säga att jag skapar en egen peng: 100 Flunk. Pengen har ett sedelnummer som är skapat av min hemlis.

Nu ger jag pengen till min vän. För att pengen ska få sitt värde även för vännen, så måste vännen växla in pengen till en ny peng på 100 Flunk. Då invalideras min gamla peng, så att jag inte kan använda den flera gånger.

Men överraska mig då!

2007-01-19T23:38:00.000+01:00

Marknadsfolk. Lyssna nu riktigt riktigt grisnoga:

Hemligheten är inte att ge folk vad de vill ha. Hemligheten är att ge dem vad de till sin överraskning upptäcker att de vill ha!

Jag är professionell datanörd. Jag surfar på många nördsidor. Därför är jag tydligen dömd att nås av nördreklam. Prenumeration på internetworld, osv osv.

Dessa reklamskript som försöker ge oss annonser som liknar de siter vi redan besöker, de missar en viktig sak: folk vill bredda sig!

Alltså: tror ni inte att jag inte redan har läst senaste internet world? Finns det i era hjärnor att jag surfar för att försöka hitta sånt jag inte redan känner till?

Internet är till för att bredda vyerna, inte för att snäva till dem ytterligare.

Dumskallar.

Två ideer till

2007-01-12T20:17:00.000+01:00

För det första: en liten krypterad fil, för folks alla lösenord och hemlisar. Man kan välja att ha den på fundament-servern, eller i hemkatalogen, eller på den lilla USB-pinnen.

För det andra: en liten synkkatalog på den lokala datorn och servern. Enkel upp/nedladdning, som väljer den senaste versionen av alla filer, som ser till att inget körs över.

En bra bok

2007-01-12T14:05:00.000+01:00

En bra bok: läs.

Skapa PDF från blogginlägg

2007-01-07T22:10:00.000+01:00

Jag har ju slutat bry mig om att vara förtegen med alla mina idéer. Istället gäller mitt nyårslöfte: kommunicera dem!

Min senaste idé jag jobbar med är en PDF-generator från blogginlägg. Jupps. Givet ett blogginlägg (eller vilken RSS/Atom-post som helst), så skapas en PDF.

Kan vara käckt. Vissa människor är ju så hopplöst utskriftsdokumentiga. Lättdistribuerat bland kostymnissarna.

Salut!

Songs.xsl, för gitarrnörden

2007-01-07T14:33:00.000+01:00

Idag har jag suttit och tagit ut One med U2 på gitarren.

Resultatet kan beskådas här: www.fundament.se/songs/one.xml

Lägg märke till att låten är en XML-fil. Självklart är det XSL som står för presentationen! XSL-filen finns här: http://www.fundament.se/songs/songs.xsl

Leve XML! Leve U2! Leve nörderiet!

BOX server är ute

2006-11-22T14:51:00.000+01:00

Nu är BOX Server i drift på http://www.fundament.se/box.php.

Ta gärna en titt. Logga in med användarnamn: test, lösenord: test, och lägg upp lite filer och så.

BOX Server är alltså just nu en hanterare för "box"-objekt. Ett "box"-objekt är en filkatalog som lagras på en webbserver, men där filerna inte kan kommas åt om man inte är inloggad som rätt person.

Uppdatering

2006-11-15T12:46:00.000+01:00

Sådärja! Nu har jag börjat installera mig på nya jobbet.

Jag har alltså krupit in under konsultkepsen ännu en gång, nu som konsult på IBS Konsult, närmare bestämt på den del av IBS Konsult som går under namnet JavaSolutions.

Och vad gör då vi?

Jo, till att börja med så är ju IBS en tillverkare och leverantör av affärssystem. Konsultbenet opererar dock oberoende av affärssystemet (även om vi naturligtvis kan det) med att leverera expertis till våra kunder, såsom:

Objektorienterad analys, design, och implementation.
Teknisk projektledning och arkitektroller.
Javalösningar. Vi har kompetens och erfarenhet inom allt ifrån små inbyggda system till stora verksamhetsinformationssystem (Enterprise Information).
AS400. Jäpp, plattformen lever och frodas. En väldigt bra plattform för många tillämpningar.
Och självklart är vi duktiga på att integrera Java och AS400. Har du en gammal viktig grönskärmsapplikation i din verksamhet, samtidigt som du vill gradera upp din miljö (tjänsteorienterat, distribuerade objekt, mm)?
Utbildning. Eftersom IBS Konsult är ett företag som VetHurManGör, så är det bara naturligt att vi utbildar en massa.

Så det gör jag just nu. Kodar java. Objektorienterar. Utbildar i UML, RUP och agila metoder. Utforskar AS400/Java-integration.

Och har precis hur kul som helst!

Snälla tomten

2006-10-19T13:18:00.000+02:00

Snälla tomten! Jag önskar mig Ken Schwaber's bok Agile Project Management with Scrum.

2006-10-10T11:48:00.000+02:00

Dags för lite kryptografi i Java igen. Det går så långt mellan varven nu att jag glömmer bort hur man gör :-/

Den här gången är det 3DES som ska implementeras.

Först skapar jag nyckeln (från 24 slumpmässiga bytes, från random.org), och de två chifferobjekten.

//the key, from 24 random bytes ("_keyData")
_key = SecretKeyFactory
   .getInstance("TripleDES")
   .generateSecret( new DESedeKeySpec( _keyData));
            
//the cipher objects for encryption and decryption
_encryptor = Cipher.getInstance( "TripleDES");
_encryptor.init( Cipher.ENCRYPT_MODE, _key);
_decryptor = Cipher.getInstance( "TripleDES");
_decryptor.init( Cipher.DECRYPT_MODE, _key);

Att kryptera och dekryptera är sedan lätt:

//encrypt a byte[]
byte[] encryptedData = _encryptor.doFinal( cleartextData);

//decrypt a byte[]
byte[] decryptedData = _decryptor.doFinal( encryptedData);

//cleartextData and encryptedData is now the same!

Det luriga ligger som vanligt i att försöka få tag i och installera en provider. Jag använder helst den helfria BouncyCastle här.

Men i detta fallet använder jag den medföljande implementationen av 3DES.

Algoritmnamnen ja... usch vad många gånger det har blivit fel. När man skrivit "3DES" istället för "TripleDES" till exempel.

OpenID

2006-10-09T22:37:00.000+02:00

Du vet Microsoft Passport? Skaffa ett konto hos Pyttemjuk, så funkar det på många sajter. OpenID är samma tänk, single sign-on osv, fast utan beroende av en enda drakonisk leverantör.

Jag har skaffat ett OpenID, på en webbplats som heter myopenid.com. Om OpenID-konsortiet försvinner, så gör det inget, mitt ID finns kvar. Om myopenid.com försvinner, så gör det inget, jag kan behålla mitt ID, fast får gå till en annan leverantör.

Ingen utom jag kontrollerar mitt OpenID! Det är det viktiga.

Hälsningar ola.berg.myopenid.com .

En som vet vad han talar om

2006-10-09T12:14:00.000+02:00

Jag misstänker att Mark Baker är en man som vet vad han talar om: nämligen webben som plattform. Läs och ta del!

FreeRIP

2006-09-12T12:33:00.000+02:00

För att rippa musik på CD-skivor till MP3 så använder jag numera FreeRip. Ett bra program.

www.mgshareware.com/frmmain.shtml

HTML som datatransfer

2006-08-28T18:11:00.000+02:00

Ljuvligt med semester. Bad tre gånger om dagen. Ingen skojprogrammering nästan. Förrän på slutet, då det blev regnigt. Och då hittade jag på följande: Dataöar i HTML. Alltså inte i XML i största allmänhet, utan i HTML.

Detta är en av tillämpningarna av mikroformat. Små, enkla dataformat som inte försöker sig på att vara mer än vad de är. microformats.org

Snabb: Länka XML Schema till XML-dokument

2006-07-04T11:58:00.000+02:00

Om man vill påstå eller garantera att ett visst XML-dokument följer ordningen i ett visst XML-schema, så kan man göra följande:

<?xml version="1.0" ?>
<mitt 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http//min.server.se/mitt.xsd" >
  <fina>dokument</fina>
</mitt>

Sommarlovsteatern!

2006-06-30T10:48:00.000+02:00

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

2006-06-29T23:12:00.000+02:00

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

2006-06-22T08:08:00.000+02:00

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!

2006-06-14T23:56:00.000+02:00

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

2006-06-14T17:07:00.000+02:00

Ä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

2006-06-13T21:53:00.000+02:00

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)

2006-06-09T11:47:00.000+02:00

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.
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.
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.
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"
```
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
```
Sök fram en rad som börjar med "DocumentRoot ". På raden under skriver du:
```
PHPIniDir "C:/php"
```
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)

2006-06-09T10:26:00.000+02:00

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

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".
Dubbelklicka på den nyligen nedladdade MSI-filen.
I dialogen som kommer: klicka på "Next" hela tiden, eller "I accept". Detta ger dig en standardinstallation.
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.
Avsluta installationsdialogen med att klicka på "Finish".

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...

2006-06-04T16:42:00.000+02:00

Det finns postadresser och det finns postadresser:

www.k12.nf.ca

Ett fint kedjebrev till

2006-06-02T23:49:00.000+02:00

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:

Ge folk mer än vad de förväntar sig, och gör det med glädje.
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.
Tro inte allt du hör, bränn inte allt du har, och sov inte så mycket du vill.
Säger du "jag älskar dig", så mena det.
Säger du "förlåt, jag är ledsen", så se den andre i ögonen.
Var förlovad minst sex månader innan giftermålet.
Tro på kärlek vid första ögonkastet.
Skratta inte åt andras drömmar. Folk som inte har drömmar, har inte mycket.
Älska djupt och passionerat. Du kan bli sårad, men det är det enda sättet att leva ett fullt liv.
Strid rent när du strider. Inga smädelser.
Döm inte folk efter deras släktingar.
Prata långsamt, tänk snabbt.
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?".
Kom ihåg att stor kärlek och stora framsteg kräver stora risker.
Säg "prosit" när någon nyser.
När du går miste om något, gå inte miste om lärdomen.
Kom ihåg: Respektera dig själv, respektera andra, och ta ansvar för dina handlingar.
Låt inte en liten dispyt stjälpa en stor vänskap.
När du gjort fel, åtgärda det omedelbart.
Le när du lyfter luren. Det kommer att höras på din röst.
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

2006-06-01T09:20:00.000+02:00

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

2006-05-31T11:38:00.000+02:00

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"

2006-05-31T10:36:00.000+02:00

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

2006-05-26T12:01:00.000+02:00

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:

Ta fram verksamhetskraven. Med prislapp (vad tjänar vi på att få kravet uppfyllt).
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.
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.
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).
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

2006-05-24T14:52:00.000+02:00

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

2006-05-18T09:48:00.000+02:00

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

2006-05-17T09:03:00.000+02:00

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

2006-05-16T09:11:00.000+02:00

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

2006-05-15T22:09:00.000+02:00

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å?

2006-05-15T16:48:00.000+02:00

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.

O why, o CIO, o why?

2006-05-15T10:56:00.000+02:00

Jag ägnade en del av söndagseftermiddagen för att fundera över varför jag irriterar mig så mycket på http://cio.idg.se.

Jag tror jag har det nu: jag irriterar mig eftersom jag förväntar mig att det ska finnas en svenskspråkig tidning som behandlar:

IT-styrning
Metodutveckling och verksamhetsutveckling
IT-ekonomi (olika aspekter)
System- och verksamhetsarkitektur
...och liknande jox.

Det närmaste som råkade komma upp i min väg var http://cio.idg.se, och den motsvarade inte mina förväntningar (vilket naturligtvis inte är IDG:s fel).

Det andra skälet är att jag ogillar den är att den har en kraftig slagsida åt tekniska lösningar på verksamhetsproblem. Till skillnad från den engelskspråkliga varianten som ju mer fokuserar på verksamhetsproblem och deras lösning (inklusive metod- och organisationsfrågor).

Därigenom uppfyller den svenskspråkliga utgåvan inte sitt motto: "Länken mellan IT och affärer", utan känns mer som ett reklamblad från den lokala handlaren (just nu specialpris på morötter!).

Den trivialiserar hela frågan, helt enkelt. Och det är inte bra.

Placerad på kartan

2006-05-14T13:58:00.000+02:00

Jag har ävensom placerat in denna blogg på http://bloggkartan.se/registrera/7129/goeteborg/

Dynamiska gränssnitt i browsern

2006-05-14T11:39:00.000+02:00

Nuförti'n ska webbapplikationer kodas med Asynkron Xml å Avancerad Javascript (sk AJAX). För att sprida användingen av denna webbteknik har eliten av världens reklambyråer tävlat om att ta fram kampanjmaterial.

Helt oväntat vanns tävlingen av en fotograf i Skövde:

http://www.svenskadansband.se/img223.search.htm

"IT ska inte styra över affären"

2006-05-14T00:22:00.000+02:00

Se där ett mantra som hörs titt som tätt. Men vad menas?

Ofta verkar det som om det är en obehagskänsla man vill besvärja. Ett obehag över det faktum att IT faktiskt styr över den egna verksamheten.

Mantrat är för övrigt alldeles sant. IT ska inte styra. IT vill inte styra. IT har i sig själv ingen riktning (annat än att ett visst slags IT-lösningar är enklare att genomföra än andra, vilket leder till en tonvikt för just dessa lösningar).

Men jag har ännu inte träffat en IT-människa som inget högre önskat än att deras system är i samklang med verksamheten, att deras system skapar affärsnytta, att deras system får lov att följa verksamhetens fastslagna strategi. Den dröm om "business alignment" av IT, som så många "business"-människor drömmer, den drömmen delas av varenda IT-människa, åtminstone som jag någonsin träffat.

Ändå beskylls ofta IT för att just styra över verksamheten. Driva sin egen agenda. Förmodligen för att "business"-människan alltför många gånger har haft en affärsvision, och sedan upptäckt att gjorda IT-investeringar ligger som feta hinder i vägen för dem. Då styr IT över deras affärer.

Men vänta, vaddå "styr"? Det finns ju ingen inneboende vilja hos de gjorda investeringarna att lägga hinder i vägen. Inte heller någon ond programmerare som avsiktligt driver igenom sin egen affärsstrategi för att hindra "business"-människan.

Det verkar finnas ett tankefel här. I vilken mening "styr" IT?

Tankefelet uppenbarar sig i stycket strax härovan. I orden "och sedan upptäckt att gjorda IT-investeringar..." Varför kom det som en överraskning, kan man ju fråga sig.

"Business alignment", alltså när IT följer och stödjer verksamhetens strategiska mål, sker när "the Business" faktiskt "aligns" IT. Vem är t ex ansvarig för de gjorda investeringarna? Varför ser dessa ut som de gör?

Jo, alltid för att "the Business" då, när de gjordes, tyckte det var en bra tanke. Fattade beslut utan att riktigt inse vidden av det. Eller undvek att fatta beslut (kanske vanligare), eftersom man inte kunde se då hur det skulle komma att påverka en senare.

Det finns en massa olika anläggningstillgångar som på liknande sätt styr affärsstrategierna. Beslutet att lägga lagret i Långtbortistan gav låga löneomkostnader, men höga fraktkostnader. Beslutet att satsa på plastförpackningsmaskinen gör det lite lurigt när marknaden tycker att plåtburkar är skojigare.

Skillnaden är att när det gäller logistik, så är affärsmän hyfsat välutbildade. Och när det gäller maskiner så finns det folk som kan lagom mycket om både maskiner och marknad för att inse de marknadsmässiga aspekterna av plast och plåt.

Men när det gäller IT är kunskapen på många ställen ofattbart låg. Man vill inte heller behöva skaffa sig den nödvändiga kunskapen (och jag talar inte om konsten att programmera, eller att använda PowerPoint, jag talar om IT-kunskap). Nä, varför ska man behöva skaffa sig kunskap om IT, "IT ska ju inte styra över affären"

Fel tänkt. Antingen är du ett offer för omständigheterna, eller så skaffar du dig ett grepp om omständigheterna. Antingen styr verksamheten över IT, eller så "styr" IT din verksamhet. Antingen driver du för vinden, eller så lär du dig segla.

Skaffa kunskap (den behöver inte läras, den kan även anställas eller på annat sätt hyras in), och handla i enlighet med denna kunskap. Då äger du IT och hela affären. Annars blir du ägd.

Idag...

2006-05-13T15:16:00.000+02:00

...ämnar jag inte tänka och vara klok.

Idag ämnar jag fylla år.

Hipp hipp...

Förnya i rätt tid

2006-05-12T09:07:00.000+02:00

Som ett brev på posten, eller åtminstone som en tidning, kom Pravda, förlåt Computer Sweden, med en liten artikel som illustrerar grunkvärde och mjukvaruekonomin.

Det är Accenture som gjort en liten undersökning hur mycket gamla system kostar.

Några citat från teknikstrategen Bob Suh:

Många företag vet hur många it-anställda de har, men vet inte vad de lägger tiden på.

Precis. Och läsare av denna blogg vet precis vad det beror på, nämligen att man heltokigt budgeterar efter antal anställda, och inte efter vilka system/tjänster/grunkor som verksamheten vill ha.

Lösning: Grunkbudget först, sedan kan man börja tänka på hur mycket folk som behövs.

Som man ropar får man nämligen svar. Frågar slanträknarna inte efter vilka grunkor (produkter och tjänster) som IT-avdelningen levererar, så förblir IT-avdelningens arbetstid ett töcken. IT-strategin faller redan redan innan den lämnat ekonomiavdelningen, långt innan den nått utvecklarrummet.

Mer visdomar från Accenture:

Mycket resurser läggs på dokumentation, men lite energi läggs på att se till att systemen verkligen stöder nya affärer.

Förutom att det inte alls är ovanligt att inte alls mycket tid läggs på dokumentation (den går åt till att släcka bränder i gamla skrotfärdiga datasystem i stället), så är det rätt.

Att se till att systemen stöder nya affärer, det börjar man med redan under utvecklingen. Redan i början av utvecklingen. Redan i början av inceptionsfasen (fasen i utvecklingen där man ska börja fatta vad det är man överhuvudtaget ska göra). Och sedan fortsätter man med det. Affären, the Business Case, måste vara drivande i utvecklingen. Det är de dyrbara problemen som ska fixas, annars blir lösningarna inte lönsamma. Och ansvaret för att projektet löser de dyrbara problemen vilar främst på projektets sponsorer och på projektet. Gemensamt. Och projektet är inte liktydigt med utvecklarna, utan däri ingår även beställarna.

Lösning: en projekt- och utvecklingsmetod som från början är inriktad på lönsamhet. Till exempel RUP. Och den metoden börjar och slutar inte i utvecklarrummet. Den börjar långt tidigare, och fortsätter under systemet livslängd.

Företag med gamla system lägger ned för mycket tid på att fixa dem. De är i en loop där de inte kan investera i nya system, medan de som frigjort resurser för att investera i nytt har färre problem och lättare att dra nytta av de fördelar som systemen ger.

Lösning: 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.

Om man utvecklar system som ska vara lönsamma, då måste man beräkna kostnaden för systemet. Och kostnaden är hela kostnaden, under hela systemets livslängd. Och då måste man från början ha bestämt sig för hur stor livslängd systemet ska ha. Och systemets livslängd beror inte på systemet i sig självt, utan systemet satt i sin omgivning (dvs verksamheten). Och om verksamheten förändras tillräckligt på, låt säga två år (vilket inte är ovanligt), så är systemets livslängd tjugofyra månader, no more no less.

Försöker man fuska och säga: "Äh, vi räknar på tre år istället", då har man förbundit sig att inte förändra sin verksamhet så mycket under dessa tre år. Visst, kan man stå för det så är det OK. Men vill du om två år vara bakbunden av att nya affärer hindras pga gamla system? Vill du kasta in dina IT-resurser i precis den dyrbara hantering som artikeln talar om (handpåläggning, brandsläckning, fix och jox), och aldrig få tid för att utveckla vare sig affär eller system?

Det är ditt val. Men skyll inte på någon annan om du hamnar i träsket. Skyll i synnerhet inte på IT-avdelningen för att du själv glömt matematiken.

Så länge det finns ett gap mellan dem som använder tekniken bra och de som gör det dåligt, kommer it att spela roll, säger Bob Suh.

Välj rätt.

(http://computersweden.idg.se/2.139/1.45773)

Ärade läsare

2006-05-11T23:25:00.000+02:00

Med all respekt för ert val att läsa dessa mina usla rader, så vill jag ändå drista mig att påpeka att mina tankar blott är flugskitar i jämförelse med vad andra, långt klokare personer, tänkt.

Här finns en artikel om SOA som är helt och hållet sann. Läs och begrunda. Möjligen att jag skulle vilja lyfta fram "Challenge 4: Apply SOA Principles to Your Data Too" något mer än vad artikeln gör.

In Case of Emergency

2006-05-11T22:44:00.000+02:00

Ett kedjebrev har börjat dyka upp i världen. Ett bra kedjebrev, här i Sverige sponsrat av självaste sosalarm.se (a k a ett-ett-två). Det går ut på att i sin mobiltelefon lägga in kontakten "ICE" (InCaseofEmergency) med det nummer som man vill att folk ska ringa om det hänt en något. Genial idé som härmed vidarebefordras. Sprid den till alla ni känner!

Vad man gör om man känner någon som faktiskt heter ICE (nån hip-hop-musiker t ex), förtäljer dock inte brevet.

Hej!

Ett snabbt sätt för räddnings/sjukvårdspersonal att i händelse av olyckshändelse/akut sjukdom komma i kontakt med anhöriga är att söka i den nödställdes telefonbok.

I takt med att telefonböckerna ökar i omfång, blir det allt svårare för räddningspersonalen att snabbt finna rätt nummer. För att underlätta sökningen föreslog en frustrerad ambulanssjukvårdare i Storbritannien följande enkla lösning: lägg in nummer till närmast anhörig i mobiltelefonen under rubriken ICE (In Case of Emergency).

Förslaget håller nu på att bli standard genom att det snabbt sprider sig över världen.

Anders Klarström, presstalesman på SOS Alarm: "Om du hittas akut sjuk eller skadad kan ett telefonnummer medbokstavskombination ICE i din mobils telefonbok få avgörande betydelse."

ICE står för In case of emergency. Idén kommer från en ambulanssjukvårdare vid East Anglian Ambulance, som tröttnat på att leta efter anhörigas telefonnummer. I telefonboken i sin mobiltelefon lägger man in kontaktpersonen "ICE" och numret till någon nära anhörig som behöver nås när man själv råkat ut för något och inte är kontaktbar.

Använd utlandsprefix så att det även fungerar när du är utomlands. Det är också viktigt att man informerar den eller de personer som lagts in som kontaktpersoner.På så vis kan räddningspersonalen snabbt nå närmast anhörig och få viktiga besked om medicinering eller om man lider av någon sjukdom, säger Anders Klarström, central presstalesman vid SOS Alarm.

Bokstäverna har sedan dess fått spridning både i Storbritannien och USA, och Klarström tror på ett ökat användande i Sverige. Det är smart och enkelt och kostar ingenting. Se det som att du har en försäkring som du i bästa fall aldrig behöver utnyttja men händer något allvarligt har du förberett dig för att öka din trygghet, säger han.

Skicka gärna informationen vidare till andra så att den sprids i hela Sverige, hälsar Anders Klarström, som gör vad han kan för att få ut budskapet via media.

Att informationen är korrekt och internationellt gångbar kan du själv bekräfta med ett besök på bifogade länkar (eller med en sökning på "In case of emergency" på Google):

http://www.sosalarm.se/press/pressklipparkiv.asp?onPage=1&ID=604&Read=

http://www.hoax-slayer.com/ice-campaign-email.html

Kanske även vore en bra relation att ha med i LDAP (tänker min systemutvecklarhjärna) ice=xxxxxxxxx?

Update! Följande även hämtat från den engelskspråkiga världen: "For more than one contact name ICE1, ICE2, ICE3 etc".

The times they are a-changing

2006-05-11T14:09:00.000+02:00

En tanke som ibland dyker upp är att "det svåraste med att införa SOA är de politiska hindren". Hmmm...

Om politiken är ett hinder, så betyder det att skälet för att införa SOA inte är politiskt. Och då undrar jag om man verkligen ska införa SOA. Om den egna organisationen är mogen för det.

De utlovade bra följderna av SOA är ju allesammans i första hand politiska. Visst, det finns en massa goda tekniska skäl att införa SOA, men om de bara betraktas som tekniska, så betyder det att icke-tekniska befattningshavare tänker: "Jag bryr mig inte om hur ni implementerar dessa-och-dessa funktioner, bara ni gör det!".

Men det är ett ignorant sätt att förhålla sig. Hur du beskriver ditt data i organisationen bestämmer helt och hållet vad du kan göra med det. Vilka processer du identifierar som viktiga för många (som alltså lämpar sig som tjänster i en SOA) är en i högsta grad icke-teknisk fråga.

Så SOA löser inte i första hand ett tekniskt problem (även om det visserligen löser vissa tekniska problem). SOA löser i första hand politiska, verksamhetsnära, problem. Vilket betyder att initiativet och ansvaret för genomdrivandet ska ske från dem som har ansvar för företagspolitiken.

Och om dessa inte förstår varför (det är ju trots allt inte teknik), så är det så illa, att man måste ta till Bob Dylan för att rätt beskriva det:

Come mothers and fathers throughout the land
and don't criticize what you don't understand
Your sons and your daughters are beyond your command
Your old road is rapidly ageing
Please get out of the new one, if you can't lend a hand
'cause the times, they are a-changing

Meh....

2006-05-11T10:53:00.000+02:00

Mitt förtroende för den svenska varianten av CIO http://cio.idg.se har dalat ytterligare från en alldeles för låg nivå.

Lyssna på denna säljpitch för en nedladdningsbar PDF-artikel om SOA:

Vi tipsar om vad du bör tänka på i upphandlingen, och bjuder på en guide till marknadens lösningar.
(http://cio.idg.se/globalincludes/applikationer/pdf_arkivet/articleBuy.asp?item=17419)

Upphandlingen? Hallååå!? Du kan inte köpa en strategi. Du kan inte köpa en strategi.

Låt mig gissa: detta är ytterligare ett försök att lansera SOA som en teknik. Något som en chef liksom kan köpa in, likt en skurmopp eller en ny server, eller chokladkaka till personalfikat.

Men är det något som svenska chefer definitivt inte behöver höra, är att koncept och tankesätt och strategiskt värdefulla metoder är produkter, som gör att de slipper tänka eller bry sig. Det har vi sett tillräckligt av.

Man kan fråga sig varför den svenska tidningen har så låga tankar om chefer, när den engelskspråkiga modertidningen tar frågan på allvar.

Jeeeesh!

SOA, magistern, SOA

2006-05-11T00:10:00.000+02:00

Visst är det härligt när en god tanke får ett namn, som dessutom blir ett surreord?

Nu är det Service Oriented Architectures som myntats (ja, ja, det var några år sedan), och renderat en del bla bla bla runt om i världen.

Mjukvaruförsäljarna är inte långsamma med att rycka ordet till sig och gärna knyta något av sina produktnamn till surret. Microsofts .NET-teknik, t ex, eller Javas J2EE. SOAP-server. Protokoll.

Och så blir det (återigen, suck) fokus på tekniken, medan filosofin trängs undan. Vilket får till följd att de teknikrädda men smarta människorna som borde tagit till sig filosofin, istället tror att det är fråga om att välja rätt teknik.

När det handlar om att välja rätt tänkesätt. Och det är inte teknik. Jag upprepar: inte teknik.

För den som vill läsa på tycker jag att Wikipedia i vanlig ordning ger en bra beskrivning: http://en.wikipedia.org/wiki/Service_Oriented_Architecture.

Rent tekniskt (ja, jag måste börja i den ändan) handlar det om att göra vissa funktioner tillgängliga för verksamheten, fast inte med grafiska gränssnitt för människor att klicka på, utan som maskinläsbara gränssnitt för dataprogram att använda.

Tänk dig att ni har ett intranät där de anställda kan rapportera tid, effektuera kundordrar, göra valuaomvandlingar eller någonting annat. Ett fantastiskt arbetsbesparande redskap.

Tänk dig nu att ni även har en grupp gravt handikappade men lojala och effektiva anställda (begåvade med handikappet intelligensbefrielse). Dessa anställda brukar i vanliga fall kallas "datasystem". Jag tycker om att tänka mig dem som robotar i äkta Plåtniklas-skrud (med lampor som ögon och antenner på huvudet).

Om ert intranät innehåller tjänsterna även för denna grupp anställda, vad betyder det? Jo, det betyder att de själva inte behöver innehålla någon kod för att räkna om valutor, eller för att ta sig in i tidrapporteringssystemet, eller för att effektuera kundordrar.

Och ett dataprogram som inte behöver innehålla så mycket kod är ett på alla sätt bra dataprogram. Få kodrader = få fel = enkelt att underhålla = billigt. Billiga, men ändå lika kapabla som deras mer välväxta kusiner som inte använder intranätet.

Det är SOA. Ett smart sätt att centralisera funktionerna som behövs.

Nå, vad är haken? Jo, haken är att verksamheten måste identifiera vilka tjänster (Services) som ska ingå i arkitekturen. Tjänsten måste ingå i företagets allmäna medvetande som en grunka, på precis samma villkor som de verktyg som människorna använder.

Och det betyder att samma strategiska tänkande som identifierade tjänster väl värda att ha på intranätet, även måste appliceras på robotarnas behov.

Och det betyder i sin tur att folk på strategisk nivå måste börja bry sig om robotarna och deras behov.

Och det betyder att folk som är utbildade och tränade på att känna robotarnas behov måste beredas plats i åtminstone den delen av verksamhetens strategiutveckling. Precis som alla andra som sysslar med arbetsledning.

För det är det som en mjukvaruarkitekt är: en arbetsledare. Låt vara att arbetarna är av plåt (eller kisel och elektroner), men likväl en arbetsledare. Är arbetets organisation en strategisk fråga, så är företagets mjukvaruarkitektur en strategisk fråga.

Det är alltid trevligt att vara på rätt spår!

2006-05-10T17:02:00.000+02:00

Det är fler namn, och betydligt tyngre än mitt, som insett vitsen med grunkvärde

Här är det den amerikanske konsulten Dean Meyer som talar om IT-budget.

Lägg märke till detta citat:

Traditional budgets -- listing cost factors like compensation, travel, and training by group -- cause numerous problems. Two problems are really damaging:

First, they don't support sound financial decision making, since the full cost of individual projects and services is not known.

Second, they don't define exactly which projects and services are covered by the budget. As a result, organizations face expectations well beyond their resources, and are blamed when they can't satisfy every request.

Instead, budgets should list deliverables -- the products and services produced by the organization -- and present the full cost of each.

Exakt! Alltför ofta ser man en massa aktiviteter budgeterade, gärna som kostnadsposter. Bla bla personalkostnad, bla bla utbildningskostnad bla bla. Men det är fortfarande GRUNKOR som genererar pengar, och GRUNKOR som kostar pengar.

"Grunkor" är alltså "deliverables" i hans terminologi. Produkter och tjänster som uppfyller någon sorts funktion i verksamheten. Som tar del i värdeskapandet.

Om man inte värdesätter grunkorna, både för vad de är värda och för vad de kostar (och det första ska överstiga det sista), så har man ingen finansiell koll på sin IT.

Har man koll på vad personalen kostar, så har man koll på en illusion. All personaltid, effektiv och nyttig, eller ineffektiv och skadlig, kostar enligt den modellen lika mycket. Vilket ju inte är fallet. En krona lagd på ett värdefullt system är betydligt billigare än en krona lagd på ett värdelöst.

Det är så enkelt: håll koll på grunkorna (budget, intäkt, kostnad), så kommer den andra kollen av sig själv. Gör du tvärtom har du ingen koll.

Och nu kan ni...

2006-05-10T11:46:00.000+02:00

...kommentera det som jag skriver, om ni vill! Jag hade missat den inställningen.

Mjukvaruekonomi 4: Hur prioritera?

2006-05-08T23:25:00.000+02:00

(forts. fr. Del 3)

OK, vad har vi lärt oss? Jo, att det är smart med

Få men välfungerande grunkor...
..som var och en stöder många värdeskapande processer

Vi har också lärt oss att det är skillnad mellan

Stödtrupper, dvs grunkor som även dina konkurrenter har, och...
Spjutspets, dvs grunkor som bara du har och som ger dig konkurrensfördelar

Och att fel i dessa grunkor innebär större kostnader än man tror. Och att du förmodligen bör ge dem en rejäl översyn, kanske vidareutveckla eller förbättra dem vartannat år.

Nu börjar vi närma oss den punkt då vi faktiskt kan veta svaret på frågan

Lektion 4: Hur prioritera?

Givet vad vi lärt oss innan kan vi dra några slutsatser, beroende på vad det är för system vi talar om:

Dina konkurrenter har samma IT-stöd för vanliga grejer som du (stödtrupperna). Det är alltså inte befogat att satsa pengar på att försöka förbättra stödtrupperna. Vinnare är den som tvärtom håller nere kostnaderna.

Men för att kunna hålla nere kostnaderna krävs det kanske satsningar. Stödtruppssystemen ska bara ticka och gå, utan att göra så mycket väsen av sig. Ingen ska behöva lägga mer än en ynka del av sin tid på att hålla stödtrupperna rullande.

Eftersom stödtruppssystem ofta är av det slaget att det finns många leverantörer, är det lite "köparens marknad" över dem. Det kan löna sig att omförhandla eller lägga ut på kontrakt (även om du har intern IT-personal). Detta sänker kostnaderna.

Även stödtruppssystemen behöver ses över vartannat år. Därför bör de vara av ett flexibelt snitt, så att de lätt låter sig ses över och konfigureras om och anpassas efter nya förutsättningar. Eftersom spjutspetsar alltid byggs för att kommunicera med stödsystemen, bör stödsystemen dessutom vara av typen "öppna lösningar", alltså bygga på öppna standarder för kommunikation. Leverantörerna och tillverkarna av stödsystem vet detta. Därför bygger de ofta in spärrar som gör det svårt att integrera spjuspetsar med stödtrupperna. Det gör att en all-in-all-lösning för t ex e-post som verkar vara väldigt billig blir svindyr eftersom varje försök att göra något mer av dem blir svårt, dyrt, och krångligt.

Just bland stödsystemen har FOSS (Free & Open Source Software) funnit sin nisch. Dessa system är oftare enklare att bygga ut än andra.

Den stora kostnaden för illa fungerande stödsystem är ju allt som krävs för att hålla dem under armarna. Den stora vinsten med att satsa på felfria och självgående stödtrupper, är att du frigör resurser för att utveckla och/eller underhålla det andra slaget: spjutspetsarna. Det är i spjutspetsarna dina stora vinster genereras.

Så din första prioritering måste vara att se till att dina stödtrupper, de grundläggande funktionerna som även dina konkurrenter har, fungerar smärtfritt. Få ner antalet fel. Minska antalet tillfällen då IT-personal måste syssla med handpåläggning för att få det att fungera. Satsa på att göra dem självgående. Kanske outsourcing?

Mottot för stödtrupperna är "Varför ska en sån enkel skitsak som alla andra har krångla för oss?". Tänk på KISS (Keep It Super Simple).

När konstnaderna och krånglet för stödtrupperna går ner, då frigörs resurser. Dessa ska naturligtvis läggas på sådant som direkt påverkar marginalerna. Nu kan du få tid och pengar att faktiskt utveckla din verksamhet. Automatisera, fixa till webbplatsen och göra den till ett proaktivt verktyg för att kommunicera med kunden, ordna och fixa så att du blir bättre än dina konkurrenter.

Men då är det viktigt att vi slutar titta på IT-ekonomin för en stund. Annars är risken att vi låser blicken i IT-träsket. Nu handlar det i första hand om hur du vill utveckla din verksamhet, och det kan du bäst själv.

Däremot, när du kommit på ungefär vad det är du vill du ska göra, då är det dags att ta på sig IT-glasögonen igen. För även utveckling kan bedrivas på antingen ett ekonomiskt eller ett fullständigt vansinnigt sätt.

Thunderbird rockar!

2006-05-08T23:06:00.000+02:00

Nyss hemkommen från ett par kompisar som behövde lite omvårdnad. Alltså, datorn deras behövde att någon gullade med den. Windows XP, förstås. Min linuxinstallation klarar sig väldigt bra på egen hand, men kompisarnas Windows XP har ett aldrig sinande ömhetsbehov.

Först en rejäl koll efter suspekta processer och dylikt. Sedan avinstallation av en massa toolbars till Internet Explorer. Sedan fixa prenumeration på antivirusprogram och en genomgång av hårddisken. Lite borttag av program som bråkade med varandra och gjorde hela systemet instabilt. Sedan hade CD-spelaren fått storhetsvansinne och kallade sig för SCSI-enhet, fast det är en vanlig IDE-spelare. Fixa fixa.

Sedan... in med Firefox som standardwebbläsare. Den hade de kört innan och gillat. Men the killer app: Thunderbird.

-"Kan du fixa epostkontot också?"

-"Kanske, vi får se..."

Klick, klick, klick. Klart.

-"Woah, så enkelt?"

Thunderbird rular! Och som jag nämnde här, så är fullfjädrad kryptering och digitala signaturer enklare på Thunderbird än att lägga barnens Bamsepussel. Klick, klick, klick. Klart.

http://www.mozilla.com/thunderbird/ (e-postprogrammet)

http://www.gnupg.org/(en)/download/index.html#auto-ref-1 (kryptomotorn)

http://enigmail.mozdev.org/ (kopplar kryptomotorn till e-postprogrammet)

Mjukvaruekonomi 3: Kassa grunkor?

2006-05-08T19:45:00.000+02:00

I förra lektionen fick du en räknemodell för att räkna ut nettovärdet av dina IT-investeringar, genom att se hur de stödjer dina processer. På köpet tvingades du se dina processer, för vad de är värda. Vilket är viktigt. De som känner att IT-stödet har en oklar roll i organisationen, har ofta en oklar bild av själva organisationen nämligen. Vad datasystemen gör är glasklart, men den roll de spelar avgörs av sammanhanget de är insatta i.

Dina processers intäkter och dina IT-satsningars andel i den intäkten är A & O när det gäller att räkna med IT. Dels vid införandet av nya IT-satsningar, men också när det gäller att se över underhållsbehovet.

Allt handlar om "the business case", alltså det affärsmässiga skälet till att utföra förändringar i ett arbetssätt (och att införa ett IT-system är ingenting annat än just det). "Är det dyrt?" vill många fråga. "Lönar det sig?" menar jag är den rätta frågan. Och hur ska man prioritera sina satsningar? Vi börjar med att lära oss hur man ser på saker som fungerar dåligt.

Lektion 3: Kassa grunkor?

På kostnadssidan för varje IT-grunka radas allt det dyra upp: införandekostnader, service, licenser osv. Och personaltid för att hantera grunkan, inte bara systemfolk, utan alla inblandade. Även chefens tid.

Det man missar om man bara tittar på kostnadsspalten är den dolda kostnaden, när något inte finns eller fungerar som det är tänkt. När alltså den intäktsbringande delen av systemet inte levererar, och det blir ett intäktstapp.

Om man har rätt system på plats, så är de lönsamma, dvs intäkterna för processen överstiger de sammanlagda kostnaderna för processen. Men det betyder att om systemet fungerar dåligt, så slår det obönhörligen på intäkterna. Slår det inte på intäkterna, så kanske inte systemet alls behövs, eller hur?

Orden "fungerar dåligt" kan både syfta på att systemet är instabilt, och på att systemets roll i organisationen inte riktigt motsvarar vad organisationen kräver. Hur som helst innebär "fungerar dåligt" en avsevärd kostnad.

Här kommer felrapporteringen in. För varje system måste organisationen hålla sig med en fellogg, där driftstörningar rapporteras och, om möjligt, vad detta inneburit för intäkterna. Glöm inte bort följdfel och oväntade kostnader för att rädda systemet osv. Ju mer precist man kan hänföra direkta kostnader till direkta fel och driftstopp, desto bättre.

När det gäller systemets roll i organisationen är det viktigt med uppföljningar där de drabbade av systemet får säga sitt. Efter två år har förmodligen verksamheten förändrats så mycket att det är dags för en översyn (tidigare i vissa slags organisationer), men eftersom förändringen oftast sker smygande, så degraderar systemets intäktsbringande roll gradvis. Det kallas för "bitröta" eftersom känslan är att systemet ruttnar ihop, men det är naturligtvis inte systemet som degraderar, utan resten av världen som rör på sig.

Också när det gäller uppföljningar ska man försöka hitta kostnaderna. Vad innebär det i tid för användarna att de behöver gnugga systemets data manuellt, om det skulle kunna automatiseras? Vad innebär det för intäkten att systemet bara kan hantera beställningar av typen X och Y när vi nu faktiskt har typen Z också, och det blir fler och fler Z-beställningar?

Dessa kostnader är viktiga, för de är de som är själva motivet för att göra något åt situationen. Denna kostnad är en förbättringspotential, alltså en framtida intäkt. Därför ska du inte gömma undan dessa kostnader genom att blanda den med de kostnader du redan identifierat. Skapa en ny spalt för förbättringspotentialen istället. Kostnadsspalten beskriver vad det kostar att hålla systemet på dagens nivå. Förbättringspotentialen är vad du kan tjäna på att ändra dagens nivå.

Nu har vi kommit så långt att vi kan se

Vad ett system är värt
Vad ett system kostar
Hur ett system kan förbättras

Nu borde vi väl kunna, utifrån dessa siffror, prioritera?

Nej.

Vi betraktar nämligen än så länge systemen som isolerade företeelser. Visst, vi har en processbild att utgå ifrån, men det finns betydligt mer att titta på, som har med de större sammanhangen att göra.

Men det är en lektion för sig.

Använd kryptering, människor!

2006-05-06T23:29:00.000+02:00

E-post borde inte heta e-post. Det borde heta e-vykort, för det är precis vad det är. Allt som du skriver syns för hela världen, om någon bara bryr sig om att titta efter. Och inte heller kan man vara säker på att avsändaren är den rätta heller. Det är bara för vem som helst att skicka ett brev från knugen@kungahuset.se eller president@whitehouse.gov.

Med kryptering, däremot, kan obehöriga inte läsa vad du har skrivit, och alla kan vara säkra på att det är just du som har skrivit. Titta här på ett e-brev jag skriver:

Detta är en hemlis. Hemlis, hemlis.

Hälsningar Ola.

Jag skickar det till en kompis. Jag har fått kompisens "publika nyckel" (alltså en nyckel som alla får se på och använda för att kryptera meddelanden till den kompisen). Mitt epostprogram (Thunderbird) krypterar meddelandet:

-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

hQIOA4hpCTpSCv3WEAgAraoLHrH+ophzwFzS1xxZKOnGlo1kEXe3cMiycxYfzcIW
VEOqLvoOx4mBKz8SiX9xtmCFjjbyRyBpGVPQerL2VyfjXx4btZ9hbXNt91p2nhEk
u1c2sTIJ+DjmILgIgtY/CdvKSoK65oAY7lSfCWcfXhlQ+T6EbVFaly0SDTyxf2YD
Us9YknTXdKIjfFJGwPSlMYvvXC0380tgQ4pJV3MG3vhnmIRnID+a+eHYjGoGdY55
mDuTrJh+Cw4sLVgAngtk+QjJ/WKodbgKVWT0DnYl/DIGkq7t4poqkEpbsC1fE4eu
tawD79RkqiEoT74xuNuo4RApuqiFdrkrh2EI8EyXwgf+PNbJMnn1LDEOQHhIaxkG
qgKpb0Vm4ti+eaIJ1gXgSEM+F0vpBCGi0FU/CQEJ+aGGt4nGT5kOtLmIHfnLU5Dw
U0RZsonbXa+4DXyGRMIbDVpOf3s417F6MnE46cyQglCYqms+SoB77bWqOtUUbiAu
bfhq5DisQX6pA1s7rWb+xD8bXkHrETyPUImf3nuvewIVWEILLN57kRmG5hu4Tx+B
lKe5k/O2SBeF5AYJJ1BgGerSwbrm37qhu3P9Wt9Bkelh5WZwCH3sxshlgng3a9oM
E5fpcCuuZ9H4gn18tquMDpVbJ9trpGKyu2l0X/ZXHCxb8w9LhmyVqY7LLzX2LvmT
xYUCDgMG7KwiDgYAoBAH/jwzC9y3oglJvVrey5rx/znwdjzJeQfNwtHJc58ppKbt
J22cZ9HYVPar/RM9gNiQZdTqwcPRbeCUblWKGTlgS523aTR/R2OnJG03z8UCEYWF
PG1W9pl1Oca+UFN0iKIYwgiNDwKyfptrsIqrtAVWYnVWEIvmR06fzNX3A0xg4Xyf
f/dgWPbvYOi+439z/BsKTVy4sIOWfql8Iii+YtKhJS+i9InIEbpURfyPP1hTvNj8
4FjW2sKEZyJkLjV1cEGlnpW/U73zZfTUdO35R8VM4v+WfFpNE1J6YDDTQxRn1wJM
kvraLpg/tiWObkuEXpbbKjd7Jzk/f7p+gCBmmjyWXXYH/Rp9i07bfDlGsSLbZ3vM
i8xsa36E9UWb0Bo3hIdJOhHLOJvd1/vAnwkrGJlwCVzAgX6z3rTf4M9k0u0zcV7t
FmhuACQLYkZO6M6RcD7rDlfW9b+w/8kOHxlSyBDXLfWfVpB7dJ3dZfeIdVyAopOn
DRAgprzPYDjtOAnkhFuTw0TdgQNXGJYNP6OJF+Vd9fw9m/9BGV+PDgakjtcBq3Nd
jLifO97uyMGhLtnLuI4VppbDARWPa6xfhBZxaJmOpp02XGqbwlsIw909xRCjdvet
aQ4JxWfl//HRTUIMSWwVO0zxlQpqcKiADnVJQsm5jfZ6DXsU7KvJ399Dw9JkUDwF
egbStQG0+vWmJF8B7NUBtHMAnai6SCD+knfbS56oKgvv000PzVgVG8N4t2IDOq3G
hvVwFmQK606F3oLuwHxd/xF2FPWcWf77Zcc2+H8oAD4cyDXeGB1q36VrqGQ3vQJy
4tUlE/3+XQtyflfAQ2B2fo3u8jdNw2cr+FJRn98TPbmFo3sGgFPd7nzH/8qGa8zL
fDeY1reGPjlcM3ZI0w8GUCriyM0jpVqPXmIjlZtQL1N1qejpeD9pE8A=
=V96x
-----END PGP MESSAGE-----

Försök läsa den om du kan!

Kompisen kan. Med sin privata nyckel (som bara hon har tillgång till) kan hennes epost-program avkryptera meddelandet. Meddelandet är dessutom först signerat av mitt epost-program, med hjälp av min privata nyckel. Genom att jämföra med min publika nyckel (som ju hon har) så kan hon vara säker på att det är jag som skrivit.

Nuförtiden, med snabba datorer (ja, din dator är tillräckligt snabb, kan din dator surfa detta kan den kryptera), finns det inget skäl att låta bli.

Dessutom: nuförtiden är det så enkelt. Det tog mig mindre än fem minuter att ladda ner all programvara och komma igång! Kontakta mig om du behöver hjälp.

Om någon vill ha tag i min publika nyckel, så har den id "0xB4DD4F5B". Den finns uppladdad (bl. a.) på nyckelservern pgp.mit.edu. Om du hämtar den, så kontrollera att nyckel har fingeravtrycket "39FA 9320 A63E 81F6 312A C014 59F3 69A0 B4DD 4F5B" så att du är säker på att den är min.

Det där med IT-nytta...

2006-05-06T13:29:00.000+02:00

...är inte helt lätt alla gånger. Det finns många tankefällor här.

I Birgitta Fagerströms doktorsavhandling som jag pushade för här finns en intressant formulering rörande nyttomätning:

Ett visst systems ”framgång” i termer av användning.

Tanken är inte ny. Ett infört system dissas när utvärderingsgruppen finner att bara 12% av systemets funktioner faktiskt används.

Hmmm... det finns ett ganska stort utrymme på vår tomt som jag aldrig beträder. Betyder det att det var misslyckat att köpa huset? Jag kör aldrig över 110 km/h. Gör det min bil (som ju kan gå fortare) mindre nyttig? Jag åker tåg och spårvagn 14 från och till jobbet varje dag, och ser inte åt de andra linjerna. Är mitt månadskort i onödan?

Om 88% av funktionerna i ett system aldrig används säger det visserligen att dessa funktioner var i någon mening onödiga. Men nyttan måste väl ändå främst mätas på de funktioner som faktiskt används, eller hur? Det är ju funktionerna som används, som bidrar till systemets positiva effekt i verksamhetens värdeskapande process (se här om det viktiga nyckeltalet "grunkvärde").

Jovisst, de 88 procenten kanske aldrig hade behövt utvecklas (om det är ett egenutvecklat system man pratar om). Men var de svåra att göra, eller bara en enkel spin-off från den grundläggande arkitektur som systemet ändå behövde ha?

Och om det är ett köpesystem, så köper man väl in det utifrån de funktioner man faktiskt behöver? De övriga funktionerna är mer "på köpet". En ordbehandlare blir ju inte sämre, bara för att majoriteten av dess användare inte förmår eller ens har behov av att skapa komplicerade makron.

Och vad är en "funktion"? Ur användarens synvinkel är det en del av ett användningsfall. Men om man väljer att implementera ett användningsfall som en eller flera "funktioner" kan ju bero på en massa olika överväganden.

Så nä... "endast 12% av funktionerna används" säger ingenting om systemets nytta. Det säger en del om att systemet inte riktigt används som det var tänkt, men det är ju någonting helt annat.

Så hur bör man tänka då? Jo...

Är nyttan av de användningsfall vi behöver ordentligt utredda (med prislapp!), innan vi sätter igång att implementera/köpa in dem?
Vilken nytta har systemet, sådant det faktiskt används, för vår värdeskapande process (kom ihåg vad jag skrivit om "grunkvärde")? Där har du nyttan!
Är det ett problem att de 88 procenten inte används? Alltså, gör det något? Egentligen? Om det gör något, så kasta för all del in systemet och/eller dess användare i någotslags förändringsprocess och lös problemet. Men är det inget problem så strunta i det och gå vidare. Kanske bör du se över din utvecklings- eller införandeprocess (och det bör du alltid göra) så att du inte implementerar onyttiga användningsfall, men häng inte upp dig på "funktioner". Funktioner är inget, användningsfall och arkitektur är allt.

En jätteintressant bok

2006-05-06T02:05:00.000+02:00

Om man är intresserad av problemställningarna kring mjukvaruinförande och utvärdering och sånt, så är denna doktorsavhandling från Luleå Tekniska Högskola superintressant. Den är akademisk, men absolut inte teknisk i sin karaktär. Den behandlar inte mjukvaruekonomi i sig, men talar om effekter på organisationer.

Det är bra att det forskas på sådant här. Jag är ju en varm anhängare av RUP, och inbyggt i den metodiken är ju en utvärdering både av användarnas nytta liksom att man hela tiden håller koll på att det som tillverkas är ekonomiskt sunt att tillverka. Då är en utvärderingsmetod av nöden.

Hennes slutsatser är tankeväckande. Om du inte orkar läsa hela (hon har ett ganska långt och tråkigt metodkapitel där hon nästan defensivt går igen grundläggande saker om kvalitativa analyser - måhända för att folket vid en teknisk högskola är mer vana vid kvantitativa), så läs åtminstone hennes Abstract (i början) och Conclusions (i slutet).

Mjukvaruekonomi 2: Hur dyrt är dyrt?

2006-05-05T12:04:00.000+02:00

I förra lektionen fick du lära dig att tänka på dina system som antingen spjutspets eller stödtrupp, och att man kan se lite olika på dessa två.

Vad som dessutom hände var att du började tänka på dina system som grunkor, om du inte redan gjort det. En vanlig åkomma är nämligen att man ser sina system som enbart processer, dvs man ser inte systemen alls och vill helst inte tänka på dem. Det är sant att processerna är viktiga, men de realiseras trots allt av grunkor, och grunkor kostar.

Finessen med god IT-ekonomi är nämligen att maximera värdet av processerna som realiseras av grunkor med maximalt nettovärde.

Nu har grunkorna fått varsitt namn, och du har till och med börjat dela upp dem lite. Ditt epostsystem som förutom att leverera epost dessutom kan ta emot och behandla ordrar på ett finurligt sätt, är ju i själva verket två system: stödsystemet "Epost", och spjutspetsen "Ordermottagning med e-post".

Nu kan man göra sig en karta över detta, en karta där vi dessutom noterar processerna.

Lektion 2: Hur dyrt är dyrt?

-"Men fattar du inte Ola, det kostar ju 17 000!" Orden kom från en mellanchef. "Hur vet vi om det är dyrt?" frågade jag.

Det är grundfrågan. Om man inte kan sätta en kostnad i relation till någonting annat, hur vet vi om det är dyrt? När det gäller företagsekonomi gäller ju i alla fall inte samma regler som för hushållskassan. I ett företag ska vi inte bränna pengar, där ska vi tjäna pengar. I ett företag är 5000 kr ut i tomma intet jättedyrt, men 500 000 kr som kostnad för att tjäna 2 miljoner kan vara ett acceptabelt pris.

Processer

Alla IT-grunkor (maskiner och mjukvara) i ett företag betjänar minst en process. Det är i processerna värdet skapas. Ett datasystem genererar inga pengar. Affärsprocesser genererar pengar. System stöder (i bästa fall) processer, men är aldrig processer i sig själva. Så första steget för att få reda på vad "dyrt" betyder, är att kolla in värdena på intäktsidan för processerna. Hur mycket stålar drar processerna in?

En värdelös process, eller en process med negativa värden, är dyra i sig själva. Naturligtvis blir varje enkrona som läggs, antingen på maskiner, mjukvara eller människor i en sådan process, oerhört dyr. Men att städa upp bland dyra processer är inte specifikt IT-relaterat, utan ingår i normal verksamhetsutveckling. Dock är det så att eftersom IT-ekonomi kräver att vi sätter kostnaderna i relation till processerna, så kan en IT-ekonomisk genomgång vara ett bra tillfälle för att genomföra en genomgång av verksamheten i stort.

Grunkans andel i processen

Nu vet vi vad som står på spel. Nu tittar vi på den aktuella grunkans andel i processen, genom att tänka vad som händer om grunkan lyfts bort. I vilken grad kan processen fortgå utan IT-stödet? För e-postsystemet är andelen mycket hög (utan e-postserver stannar e-posten och får 0%, e-postserverns andel är alltså 100%). För andra system, t ex den automatiserade ordermottagningen över e-post, är andelen lägre (man kan ju hantera ordrarna för hand även om det går långsammare). Om ordermottagningen hanterar en order fyra gånger snabbare än för hand, så sjunker produktiviteten i processen till 20% om IT-stödet tas bort. Värdet av den automatiska ordermottagningen blir alltså 80% av hela ordermottagningsprocessens värde.

Bra grunkor stöder dessutom flera processer. Då lägger man samman värdet för varje process, gånger grunkans andel i varje process, för att få grunkans värde.

För en IT-intensiv verksamhet kan det mycket väl vara så att systemens andel i varje process är 100%. Då kanske det är dags att se över processen för att minska risken, men det faller utanför ämnet för dagens lektion.

Systemets totalkostnad

Nu vet vi värdet av varje grunka (skriv ner det). I nästa spalt skriver vi den sammanlagda kostnaden för varje grunka. Den sammanlagda konstnaden alltså, över hela systemets livslängd. Från det att det började kravställas, köpas in, byggas, införas, finjusteras, lagas, förbättras osv fram till dess att det skrotas. Kostnaden för personal, maskiner, licenser, konsulter, allt ska bokföras.

Grunkans nettovärde är dess bruttovärde minus dess totalkostnad.

Och för hur lång tid? Det där beror väldigt mycket på. En god tumregel säger att man bör betrakta systemets livslängd på cirka två år. Detta för att det tar ungefär två år för systemets omgivning (verksamheten) att ha förändrats såpass mycket att någon form av radikal omstrukturering av systemet måste ske. Systemet ändras inte, men det gör omgivningen. Vid en omstrukturering/omimplementering av systemet (efter ungefär två år) kan man naturligtvis ofta återanvända stora delar av systemet. Men räkna inte med det från början. Det är en vinst som kommer systemet till del genom minskade utvecklings- och införandekostnader under nästa tvåårsperiod. Dividera med tjugofyra och du får en månadskostnad.

Dyrt?

Nu kan vi plötsligt jämföra värdet av en process, med de sammanlagda kostnaderna för alla grunkor som stödjer densamma (för grunkor som stöder flera processer ska naturligtvis kostnaden spridas ut på dessa).

Och vi kan jämföra kostnaden för varje grunka med värdet av densamma. På så sätt får vi syn på olönsam och lönsam, och viktig respektive oviktig teknikanvändning. Och vi kan sätta kostnaden för underhåll i relation till kostnaden för att byta ut grunkan, eller i relation till att arbeta om processen helt.

Vi kan också dra några andra slutsatser:

Det är dyrt med grunkor som ofta går sönder, och som inte riktigt motsvarar verksamhetens krav.
Det är dyrt med många grunkor i en verksamhet, när färre räcker.
Det är ekonomiskt lönsamt om samma grunka stöder många värdeskapande processer.

Inga banbrytande insikter, men vi vet nu inte bara att vissa saker är dyra, utan också hur dyra de är.

Öka varje grunkas värde genom att ha värdefulla processer som stöds av totalt sett få grunkor av hög kvalitet!

Notera att jag skriver om "grunkor i en verksamhet" och inte "grunkor i en process". Det finns nämligen en frestelse här att suboptimera genom att försöka minska antalet grunkor i varje process. Men ofta leder det till att grunkorna blir väldigt specialiserade och lämpar sig dåligt för användning i olika processer, vilket leder till ett ökat antal grunkor i verksamheten och därmed sämre total ekonomi. Märk hur värdet av en grunka drastiskt höjs när den är del av flera processer, och hur kostnaden för en process drastiskt sänks när kostnaden för en grunka delas upp på flera processer.

Och notera att det inte gäller att höja hela verksamhetens grunkvärde genom att ha många grunkor. Värdet på verksamheten är i varje given stund inte högre än värdet av dess processer. Det är värdet på varje grunka som ska höjas, genom att man har optimalt få och välfungerande sådana.

Mjukvaruekonomi: Spänn av, det är inte teknik

2006-05-05T11:41:00.000+02:00

Det första jag ska flytta över är mitt svammel / mina halvstrukturerade tankar om mjukvaruekonomi.

Spänn av, det är inte teknik

- "Ja det är ju IT det", sägs det, och blicken blir flackande. "Jag kan ju inte IT". Man misstänker att den som just yttrat sig inte riktigt vet vad som är bak och fram på en nätverkskabel. Vill inte riktigt befatta sig med saken. Det är ju IT.

Men samma person kan glatt räkna med personalkostnader, utan att för den sakens skull vara expert på HR-frågor. Eller förhandla om hyreskontrakt utan att veta hur man bygger hus. Eller göra en avräkningskalkyl på en plåtpress utan att veta något om hur styr- och reglersystemet för den är uppbyggt.

Att räkna kostnader och intäkter för en mojäng kräver ju inte att man känner till hur den fungerar. Det är inte programmerarkunskaper som krävs för att göra beräkningar på mjukvara. Däremot finns det naturligtvis saker som man måste känna till. Det blir ofta fel när någon applicerar beräkningsmodeller som grundas i helt felaktiga antaganden.

Med det är alltså inte djup kunskap om programmeringstekniker som krävs. Till och med en ekonom kan lära sig räkna med IT.

Lektion 1: Det finns två slags IT i organisationen

På Beda Olssons Bageri finns det maskiner. Alltifrån truckarna som kör mjölsäckar, till det specialanpassade hypereffektiva förpackningsbandet. Skulle du fråga Beda Olsson skulle hon säga att det är rätt stor skillnad mellan truckarna och förpackningsbandet.

Truckar finns i många industrier. Men förpackningsbandet är hon ganska ensam om. Det är det som är hemligheten bakom den höga produktiviteten i hennes bageri.

Både trucken och bandet är teknik. Men medan den första är en stapelvara och vanlig syn i större bagerier, så är den andra diversifierande. Den skiljer ut Beda Olssons från andra bagerier, och hjälper henne att göra goda affärer.

På precis samma sätt fungerar IT. Det finns IT som alla andra har, och det finns IT som är diversifierande. Stödtrupper och spjutspets. Ett e-postsystem är viktigt, men ingår i allmänhet inte i spjutspetsen. Man tjänar i oftast inga pengar på att vidareutveckla e-posten i sig, däremot skulle man förlora pengar utan den, och man kan spara pengar om den har så låga omkostnader som möjligt.

Googles sökmaskiner däremot, det är pengagenererande spjutspets. Naturligtvis applicerar man inte riktigt samma beräkningsmodell för spjutspetsen som för stödtruppen. Stödtruppen är ett kostnadsställe, medan spjutspetsen är intäkt. För stödtruppen ska man hålla nere kostnaden, för spjutspetsen ska man se hur många kronor varje satsad krona ger.

Så hemläxan till nästa gång blir att tänka över vilket slags IT hos dig som är spjutspets respektive stödtrupp. Vad krävs för att hålla verksamheten rullande, och var sker själva produktionen? Vad har du och alla andra, och vad har du men inte de andra? Vad kan man köpa eller hyra, och vad måste man specialanpassa?

Kanske är din spjutspets ditt e-postsystem, medan söket är stödtruppen. Förmodligen har du system hos dig som är båda delarna. Försök då dela upp systemen i delsystem:

vad i systemet utgör spjutspets, och vad utgör stödtrupp?

Sisådär

2006-05-05T11:38:00.000+02:00

Nu flyttar jag över en del av mina gamla bloggningar till den här nya.

På sikt ska jag försöka fixa så att det som postas här kommer att synas på min gamla adress: www.fundament.se

Ska bara se om jag kan grokka det här...