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?
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!
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:
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.
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.
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.
Mer klokskap. Denna gång är det Thomas Murphy som ger goda råd.
I korthet:
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
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.
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:
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:
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.
Jag har ävensom placerat in denna blogg på http://bloggkartan.se/registrera/7129/goeteborg/
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:
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.
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.
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.
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=
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".
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
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!
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.
