Enkelhet – o vad svårt!

Igår var jag på ett föredrag om facilitering. Det betyder kortfattat att man hjälper en grupp att nå sina mål snabbare genom att lyfta perspektivet från sak- till process-nivå. Några exempel på frågor som facilitatorn kan komma med: Vad är det som händer i gruppen nu? Leder det som händer nu till att vi når vårt mål snabbare? Vilka grundläggande värderingar skall gälla i vår grupp? Området är mycket intressant och jag kommer att skriva mer om det senare.

Föredraghållaren hade lång erfarenhet och hade arbetat i många länder med utbildning i facilitering. Han var utbildad psykolog och över 50 år hade startat eget bolag som nu efter femton år hade alla stora svenska koncerner som kunder inom området. Han var framgångsrik på alla sätt. Ändå upplevde jag honom som han inte var till 100% trygg. Kanske var det otryggheten som gjorde att han valde ett svårt ord i ett kritiskt tillfälle. Han skulle beskriva att vi i västerlandet blir värderade utifrån våra resultat. När vi träffar någon ny bekant frågar vi tidigt: ”Vad jobbar du med?”. Sedan skulle han beskriva den andra gruppen av länder där det viktigaste är vad man är. Då valde han ett jättekomplicerat ord för det, en försvenskning av ett engelskt ord, tror jag. Jag hade aldrig hört det tidigare och jag har redan glömt bort det. Jag fick känslan att han gjorde det för att imponera på oss andra. Ingen av de 100 som lyssnade förstog hans ord och någon frågade vad han sa. Han fick förklara ordet och trodde nog att han fick briljera med sin kunskap, men jag och säkert flera andra uppfattade det istället som att han var nog egentligen inte till 100% trygg.

Är det den här viljan att vara betydelsefull, att briljera, som gör att vi inte uttrycker oss enkelt?

Jag tror det. Fungerar det? Nej.

När man läser om SOA-diskussionen tidigare mellan stockholmsbaserade svenskar på engelska så undrar man också. Varför? Jag kan förstå att en del som Mats Helander som har en internationell publik tycker att det är motiverat för honom att skriva på engelska, men gäller det verkligen alla som är inblandade? Jag tänkte också så när jag läste det sista inlägget i diskussionen från Anders Tornblad(eller är det Törnblad?). Vissa delar förstår jag, men inte alla. Är jag mindre vetande som inte fattar? Eller är det något annat som ligger bakom? Vad upplever du när du läser hans sista kommentar? Den sista meningen är central, tror jag:

If we can agree that nothing is ever really cut in stone, including service contracts, the fusion of SOA, which I believe is very healthy for the business, and Agile methodologies, which I believe is very healthy for software development, should be able to coexist.

Är det i huvudsak ”Agile och SOA kan existera tillsammans” han menar? Varför komplicera det så mycket?

Nu ställer jag ju indirekt höga krav på mig själv och mitt skrivande. Lyckas jag skriva enkelt? Jag tror inte det. Inte alltid. Jag hamnar också i det läget att jag vill göra ett intryck, visa att jag minsann kan, men jag har insett att det är fel väg att gå, så jag försöker lära mig att skriva enkelt. Att blogga är en bra plats för att öva sig på att skriva klart och enkelt. Det är svårt, men viktigt för kommunikationen, för att nå fram till mottagaren. Därför skriver jag på svenska i den här bloggen.

Morgonens drama genom fönstret

 

Ruby on Rails(RoR) kommer att förändra världen!

Det finns ett nytt ramverk, ett open-source-ramverk, som jag tror kommer att förändra IT-världen. Bakom ramverket finns en grupp som leds av David Heinemeier Hanson, vilket förkortas DHH, som ursprungligen kommer från Köpenhamn, men som sedan ungefär ett år ungefär bor i Chicago. På ”nörd?”-konferenser i USA skojar man och säger att han är redan större än Oprah, som också bor i Chicago.

Jag hittade ramverket Rails och språket Ruby för ett och ett halvt år sedan. Det är annorlunda. Språket ställer mycket av det vi lärt oss om programspråk på ända. Ruby är dynamiskt på en nivå högre än jag mött. Ramverket och det dynamiska gör att det går fort att bygga lösningar (kolla in Davids videos). Det skall också sägas att Rails ur många aspekter är omoget ännu. Det inte har ett väl utvecklat stöd för exempelvis SOA via webbservices, man har valt en enklare variant som kallas REST istället. Istället innehåller Rails annat som kommer att påverka hur vi ser på och bygger system, nämligen idéer och koncept som ger ytterligare en nivå av enkelhet, fast på ett nytt sätt.

Här är ett exempel. Klassen Inlagg, i detta exempel inlägg i en blogg, ser ut så här:

 

class Inlagg < ActiveRecord::Base
  belongs_to :user
  before_save :transform_body
  validates_presence_of :name, :title, :body
  validates_uniqueness_of :name
end

Man kan se att den här klassen Inlagg ärver från en basklass ActiveRecord(som hanterar lagring/hämtning från databasens tabell med samma namn) och tillhör klassen Blogg. Det innebär att för varje Inlagg finns angivet vilken Blogg som Inlagg tillhör. Man har också deklarativt(fast egentligen i anpassad Ruby-kod) angett att fälten namn, rubrik och text skall vara obligatoriska, samt att namn-fältet är unikt bland samtliga Inlagg-objekt. Det är svårt att tänka sig en enklare implementation, eller hur?

 

DHH är också, förutom arkitekt och utvecklare, en bra marknadsförare. Kolla bara in hur hans presentationer ser ut! Rakt och enkelt. Inget tjafs. Precis som de webbplatser som redan funnits ett par år och som byggts med Rails. I Rails finns det inbyggt stöd för Ajax och Web 2.0 redan från början. Det finns ETT sätt att arbeta testdrivet redan från början. Det gör att alla nästan utan undantag använder det inbyggda stödet. I Java och .NET finns det ofta många alternativ för varje del. I Rails finns det inbyggt i grunden.

Det finns mycket att lära av David. Jag väljer bara en: ”Convention over configuration!”. I motsvarande ramverk i Java finns det tonvis med xml-filer i vilka man kan konfigurera exakt hur ramverket skall fungera. Det är tungt att lära sig alla filers innehåll och alla värden och vad de påverkar i ramverket. Detta är speciellt tydligt när man är nybörjare på ramverket och alla användare är nybörjare någon gång. I Rails finns det istället bara EN fil för konfiguration och den är mycket enkel. Istället finns det ett antal konventioner, t.ex. så finns en färdig filstruktur redan från början, en annan är att primärnyckeln i varje tabell i databasen heter ”id”. Om man inte är nöjd med det går det att ändra, men om accepterar konventionen fungerar allt utan konfiguration. Det gör det enkelt att komma igång. Det är fortfarande svårt att göra riktigt annorlunda saker, men så är det i både i java och i Rails, men i Rails så belönar man de som gör som det är tänkt. Då är det precis så rakt och enkelt som man vill.

Ruby on Rails kommer att påverka branschen. Idéerna påverkar redan nya ramverk inom .NET och Java. Microsoft har t.o.m. anställt en utvecklare med Rubykompetens som många gissar skall göra nåt som kanske kan kallas ruby.NET. Det finns liknande i python.NET för språket Python. Kanske kommer ruby.NET redan i slutet av 2007. Det blir intressant.

Jag har varit lite aktiv och ordnade tillsammans med andra en av de första träffarna i Stockholm som rörde Rails. Vi var 20 personer som sågs för ungefär ett år sedan. Trots att Rails var rättså okänt insåg jag att det var riktigt kvalificerade utvecklare som tröttnat på Java. Det som saknas är att företagen satsar på Rails, men att det kommer, det är jag säker på. Jag själv hinner inte, men det skulle vara kul att jobba mer med Rails.

Grabbar ni talar förbi varandra!

Igår stötte jag på Patrik Löwendahl i entren på Nordic Light Hotel. Han är ju välkänd för många i branschen sedan flera år. Jag har träffat honom tidigare på en konferens för arkitekter i Göteborg. Jag tog mod till mig och gick fram och hälsade. Han kände inte igen mig, men när jag sa vad jag hette visste han vem jag var. Hans chef var nämligen den förste som kommenterade min blogg. Det märkliga var att runt bordet var det först en annan kille och sedan en annan tjej som sa: ”Jag var inne på din blogg igår!” Otroligt. Hur sannolikt är det? Det känns konstigt, att bli igenkänd för bloggen och bara efter en dryg veckas bloggande. Nu måste jag skriva bra saker!

Patrik Löwendahl har i sin blogg skrivit om ”Why SOA is broken!”. Jag håller med om det mesta av det han säger, men jag ser kanske andra saker och även problem när man anser att verksamhetsperspektivet och utvecklarperspektivet är två helt separata områden. Enligt Patrik, om jag uppfattat honom rätt, vore det bäst att kraven från verksamhetsfolket kom som ”user stories” och att utvecklarteamet fick sköta sig helt själva och själva definiera sina tjänster och gränssnitt.

Som jag ser det finns det ett antal problem som Patrik tar upp som är hinder:

- Vi kommer alltid att ha problem med beställare/verksamhetsfolk som har stort kontrollbehov och tror att BDUF(Big-Design-Up-Front) eller vattenfallsmodellen är lösningen. Ett exempel på att det inte fungerar med detaljerade specar är bilindustrin där japanerna slog amerikanerna med hästlängder på 80-talet. I Japan såg man mer tillåtande på förändringar och man genomförde många små ändringar i bilmodellerna ungefär som man vill inom Agile, eller Lean Software Development som det kallas. Resultatet blev snabbare resultat, högre kvalitet till ett lägre pris.

- Likaså kommer vi alltid att ha problem med personer som anser att de är för ”fina” och befinner sig på en nivå över oss andra. De anser att de inte skall behöva bry sig om detaljerna. De är svåra att kritisera eftersom de tycker att alla andra är teknik-nördar och att de inte skall behöva befatta sig med sådana. De inser inte att de själva och deras attityd är problemet.

Men det betyder inte att jag rekommenderar uppdelning i två separata team.

I kommentarerna till inlägget kommer en annan sedan en annan röst fram, Anders Tornblad. Han menar, farligt nära det ”fina” folket ovan, att man inom SOA och arkitekten specifikt skall se tjänsterna utifrån ur ett verksamhetsperspektiv, från en hög nivå och från den bestämma exakt hur gränssnitten skall se ut i detalj. Arbetssättet är ”Contract First”. Jag tycker faktiskt nästan likadant som Anders, verksamhetsperspektivet är mycket centralt inom SOA. Jag anser att det är från det hållet det mesta av gränssnittsspecifikationen skall komma, men inte allt.

Varför kan man bara inte låta utvecklarna styra helt och hållet då? Jo, det finns ju nämligen utvecklare som inte klarar av att se sin tjänst från ett utifrån-perspektiv. De ser inte tjänsten med det perspektiv som den som skall konsumera tjänsten har. De fastnar lätt i interna detaljer och gränssnittet som blir resultatet blir inte vackert. De utvecklarna tycker jag lite synd om och hoppas att de skall lära sig se saker ur ett utifrån-perspektiv på sikt när de blir mer erfarna.

Om alla utvecklare var lika duktiga som Patrik skulle hans arbetssätt med självstyrande utvecklarteam separat från SOA-arkitekterna kanske fungera. Om alla arkitekter var väl insatta i alla detaljer i implementationen skulle SOA-arkitekt-tanken kanske fungera. Med riktigt kompetent folk i alla positioner fungerar båda varianterna. Problemet är att så är det inte i verkligheten. Kompetensen och erfarenheten hos projektmedlemmarna är inte alltid vad den borde vara.

Slutsatsen och lösningen för mig blir istället att vi behöver bli bättre på kommunikation och dialog och förståelse av varandras olika perspektiv. Om den ena fraktionen får rätt att styra över den andra utan öppen dialog blir det nästan alltid fel. Om man inser att dialogen mellan olika roller, man kan även kalla det kravdialog, är central, då kan man tillsammans få fram en acceptabel lösning, även om man har normalt kompetenta projektmedlemmar.

Min syn på grundfrågan blir alltså att man bör utifrån ett verksamhetsperspektiv definiera sina processer och analysera varje process informationsbehov. Detta ligger som grund för definition av tjänster och gränssnitt. Arbetssättet bör tillåta förändrade krav(som japanerna) och baseras på ett iterativt arbetssätt där både arkitekter/verksamhetsfolk och utvecklare för en dialog och båda grupperna är delaktiga.

Att från en hög nivå som arkitekt detaljstyra utvecklargrupper är inte acceptabelt, inte heller att som utvecklare ta emot en specifikation och sedan förkasta hela eller delar av den, utan dialog, är inte heller acceptabelt. Utvecklaren har också ett ansvar för att dialogen finns. Projektarbete som bygger på respekt för varandras olika rolller, samarbete och kommunikation leder enligt min erfarenhet till lyckade och kostnadseffektiva projekt.

Se också: Sent skall syndaren vakna!

Kris i projektet!

Jag är med i ett viktigt projekt på jobbet. Den högsta ledningen är engagerad och vill ha en förstudie gjord. Jag blev kallad till ett möte för några veckor sedan och träffade där projektledaren för första gången. Hon sitter i staben och har arbetat som managementkonsult och projektledare länge.

Det blev en räcka intressanta möten när hon beskrev uppdraget. Vi hade direkt en öppen och givande kommunikation. Det var raka puckar direkt och mycket skratt och skojande. Jag kände mig lycklig och förtjust över att få vara med i projektet. Det var snabba puckar. Förstudierapporten skulle ha varit framme i fredags efter bara tre veckor. Min roll var att säkra den valda arkitekturen för lösningsförslaget och hjälpa till i tidsuppskattningen. Lösningen bygger på en ny produkt som verkar lovande. En expert på produkten är inhyrd från leverantören och han säger att det är en helt ny nivå vad gäller systemutveckling. Det går snabbare än tidigare för så mycket finns inbyggt. Spännande.

Det är jag, experten och projektledaren. Kul.

Första verksamhetsområdet, där vi ser störst potential, är dock komplicerat. Jag säger till projektledaren att det är komplext. Jag är ingen expert på verksamhetsområdet, men inser att vi behöver mycket mer kunskap om processerna som skall stödjas för att kunna ge en tidsuppskattning, Vi skall ge en uppfattning på hög nivå hur mycket utvecklingen kommer att kosta. Projektledaren hör, men tar inte direkt notis över mina invändningar. Experten har en attityd i vissa fall när vi kommer in på något komplext krav att ”skulle man inte kunna tänka om och göra på ett annat sätt”. Om man hårddrar det han säger så blir det: ”Tekniken/produkten klarar inte detta krav – kan vi inte förändra verksamheten?”. Känner igen det. Farligt. Den vägen funkar aldrig. Speciellt inte inom detta lagreglerade verksamhetsområde. Vi skriver ju knappast om lagarna pga brister i tekniken/produkten. Skrämmande att höra detta år 2007. Liknar det jag fick höra på Stadshypotek 1995: ”Vi har en kultur här inom IT – vi lyssnar inte på verksamheten!”. Det skulle vara ett skämt, sa man, men verkligheten visade att IT såg verksamhetens krav som ett hinder. Jag fortsatte att hävda att vi skulle lyssna på verksamheten. Projektet las ner, eller var det så att jag inte fick vara med längre, har glömt. Det blev inga fler uppdrag åt Stadshypotek för mig, att ha en avvikande åsikt kostar ibland mycket.

Börjar ana att det är mycket internpolitik inblandat i projektet. Beställaren, en hög chef, är på resa. Går inte få tag i. Han har från sin position på hög höjd sett potentialen. Han vill så gärna att vi den här gången har fått ett verktyg som är supereffektivt. Han träffar chefsutvecklaren för produkten utomlands. Chefsutvecklaren säger, enligt chefen, att det fungerar. Projektledaren hänger på. Jag känner att det går inte att räkna på det här. Det saknas en nedbrytning till rätt nivå på vilka processer och informationsobjekt som skall hanteras. Det känns som om jag är gisslan. Jag förväntas ju vara garant för kostnadsuppskattningen som vi kommer fram till.

Söndag: Skriver ner i ett mejl till projektledaren att det saknas underlag.
Måndag: Projektledare skriver ner i ett mejl vad jag skall göra under veckan. Jag är på kurs(se tidigare inlägg). Jag svarar och säger igen att det saknas underlag och önskar ses. Vill inte vara kritisk via mejl.
Tisdag: Experten skriver ett lösningsförslag på superhög nivå. Han tar med tekniska objekt från produkten och ser det som verksamhetsbaserade tjänster. Fel! Farligt. Verksamhetens objekt ser han som anpassningar av de tekniska objekten och på det djupet(?) slutar hans analys i lösningsförslaget. Chefen sägs gilla dokumentet. Det stödjer chefens hypotes.
Onsdag: Jag får höra att projektledaren tagit sin hand från arkitekturen(verkligheten?) och hänvisar allt ansvar till mig. Jag mailar och ber att få tala med projektledaren igen. Inget svar. Jag ringer. Inget svar.
Torsdag: Projektledaren skriver och efterfrågar resultatet enligt måndagens mejl. Det med arbetsuppgifter som jag inte tog på mig – för underlag saknades. Jag ber att få träffas. Hon skriver tillbaka att hon inte hinner mötas och tala med mig. Hon skriver ”Jag förstår inte vad som är problemet! Gör det vi sade i måndags!”. Besvärligt. Blir upprörd. Hon lyssnar tydligen inte. Samtidigt håller experten på med fel saker, enligt min åsikt. Kommer jag att få kritik senare för att han gjort fel grejer? Jag anser att han och vi snarast borde göra ett ”Proof-of-concept”, ett kort projekt för att utvärdera produkten och lösningen för en enkel process från verksamheten.

Här har vi tydligen lite olika kommunikationsstilar. Projektledaren, som vanligen är en analytisk person, verkar i det pressade läget(hon har ju lovat en rapport till cheferna och alla andra är ovilliga att åka med på hennes/deras tåg) gå över och blir starkt pådrivande. Super-pådrivande. Hon verkar ju inte lyssna alls. Det är tydligen vanligt för pådrivande personer. Jag förstår inte det då, utan förstår det först efteråt på lördagen efter att ha talat med en tidigare kollega som precis gått UGL-utbildningen och som  kommit fram till att han just är sån.

Vad hände då? Hur slutar sagan? Jag letar stöd i organisationen och hittar stöd, dels hos andra arkitekter, dels hos de som är experter på verksamheten. Jag är själv upptagen på torsdag eftermiddag då det viktiga mötet skall ske. Har projektledaren medvetet lagt mötet på en tid då jag tidigt anmält frånvaro? Vi skall fira att vi genomfört ett annat projekt med go-cart och middag. Projektledaren hittar en ny arkitekt – en kollega jag inte känner. Söker hon efter någon som ger ”rätt” svar? Jag berättar mina farhågor för honom på fem minuter. Han säger att han inte kan ta ställning för han är inte insatt. Jag får samtidigt tio enkla tydliga frågeställningar från verksamhetsexperterna, skriver ner mina svar i ett arkitekturdokument. Projektledare ger faktiskt beröm via mejl för det dokumentet. Överraskande. Hon har tydligen lite tid över för att läsa i alla fall.

På mötet på torsdagen blev resultatet, enligt min arkitektkollega, precis som jag ville. Överraskande. Man skissade fram ett förslag på projektupplägg med 5-6 iterationer. Den första är en PoC. Under iterationerna kommer vi att lära oss om verktyget fungerar som det sägs av experten. Jag är till 90% säker på att det inte gör det. Vissa saker är säktert enkla med det nya verktyget, men samtidigt innebär förenklingen att andra delar blir krångligare. I alla fall för användarna. Jag hoppas att jag har fel, att vi denna gång verkligen hittat en verklig genväg. Det blir intressant att följa fortsättningen. Hoppas bara att projektledaren och chefen också har samma bild som arkitekten. Det måste jag kolla idag.

Det var skönt och imponerande att organisationen som helhet klarade av utmaningen/pressen att inte ge en tidsuppskattning på bristfälligt underlag. Jag tror att det var rätt att inte ge vika för chefernas krav/förväntningar. Hoppas jag inte får problem med relationen till projektledaren, som jag ju egentligen gillar, eller till cheferna. Måste bara kolla det idag. Hoppas jag får fortsatt förtroende och får vara med i fortsatta etapper.

Lördag: Åker långfärdsskridsko på sjön utanför bostaden. Har varit så väldigt stimulerad under veckan av allt som hänt, alla intryck och allt jag lärt mig, att jag nu drabbas av abstinens. Ingen ringer. Ingen mailar. Försöker ringa vänner. Ingen svarar. Reflekterar över livet, nu när det finns tid. Det är ju underbart egentligen. Härligt att finnas i ett sammanhang. Skönt att känna sig behövd. Konstigt att ungdomar inte vill jobba med IT. De förstår nog inte vad de går miste om.

Tjänstebaserad arkitektur blir accepterat av fler och fler

Mats Helander har skrivit ett intressant inlägg om tjänstebaserad arkitektur(SOA) och varför det är viktigt ur ett verksamhetsperspektiv. Han har tydligen insett det efter att ha talat med nämnde Beat Schwegler. Jag tycker att Mats artikel på ett bra sätt beskriver det man kan kalla ”Business Agility”, dvs att företagen kräver mer flexibla systemlösningar, helst tjänstebaserade, för att kunna stödja en verklighet där företag och verksamheter, hela enheter och avdelningar, köps och säljs i en allt högre takt.

Tack Beat! Jag försökte förklara SOA för Mats för några år sedan. Vi träffades på konferenser och i lite andra sammanhang. Jag trodde att det var min egen brist som gjorde att jag inte kunde hitta rätt argument i samtal med honom. Mats Helander är väldigt kunnig, han har tydliga drag av analytisk och uttrycksfull kommunikationstil. Det är en ovanlig kombination som jag egentligen gillar, men ofta kommer till korta mot i diskussioner. Diskussionerna kanske hamnade för mycket i de tekniska delarna och där är Mats verkligen insatt och min överman.

Tack igen Beat, du har väl visat att du kunde förklara och få fram dina argument till Mats, eller så är det många bäckar små, för Mats har framfört sin kritik av SOA i många samtal genom åren. Han ansåg tidigare att SOA egentligen inte är något nytt.

Läs också: Sent skall syndaren vakna II – Microsoft talar om SOA!

Intressant utbildning för arkitekter

Microsoft bjuder in till sin andra arkitektdag den 27 februari i år. Det skall handla om ”The Social Life of Information”. Det kommer att handla om Enterprise Content Management(ECM), mitt specialområde, om verktyg för ”collaboration” och om Office 2007 med SharePoint. Jag var även på förra utbildningsdagen om Software as a Service(SaaS). Det var absolut den bästa gratisutbildningen inom IT-arkitekturfrågor jag varit på. Heder åt Daniel Akenine, som är ansvarig för programmet.

Talare är Beat Schwegler. Jag känner honom inte, men jag gillar verkligen hans statement på hans egen blogg: ”It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change – Charles Darwin”. Det är väl agile, eller hur? Jag tänker gå. Det blir intressant att höra honom.

På konferens – dag 3

Det bästa innehållet idag var kring de nya möjligheter som finns för sökning i nya SharePoint. Det sämsta var ett föredrag som hette ”SharePoint” och hade ordet ”arkitektur” i titeln. Det var en kille från Fujitsu i London som hade skaffat sig en femtedel av den erfarenhet som vi själva har skaffat oss i Stockholm. Han stog och berättade att de hade installerat senaste beta-versionen av SharePoint på hemmadatorn och att man skall tänka på kundens behov innan man kör igång ett projekt. Inget om arkitektur för hela produkten. Har de ingen bättre talare? Det är torftigt. Jag kunde inte vara kvar. Jag gick därifrån och lyssnade på de intressanta föredragen som presenterades parallellt.

På kvällen åt jag middag med en Redmondkille som ville ha input till sin nya bok om ”Hur blir man en arkitekt?”. Har du något att bidra med så kan jag skicka in det till honom? Jag har ägnat denna morgon åt att skriva ner allt jag kunde komma på så därför blir det inte så mycket mera inlägg idag.

Skillnaden mellan stora och små konsultbolag

Skillnaden mellan stora och små konsultbolag är stor och jag gillar det stora bolaget. Här får jag vara arkitekt fullt ut. På små bolag kämpar alla om rollen arkitekt, och ingen får egentligen rollen fullt ut. Det finns oftast inte plats eller ekonomi för att ha någon utpekad arkitekt på heltid.

För tre år sedan jobbade jag, Dag König och André Henriksson i samma grupp på samma lilla konsultbolag. Båda två är mina vänner/kollegor och jag uppskattar dem verkligen. Båda är mycket kunniga, resultatinriktade och uppskattade professionellt, de tillhör datateknikeliten, läs deras bloggar så får du se. Vem av oss tre skulle vara arkitekt? Alla tre försökte inom sina egna områden, ingen blev det riktigt, utom möjligen Dag. Idag jobbar de båda som evangelister på Microsoft. Jag är den enda som är trogen konsultyrket. De andra är hoppjerkor

I små konsultbolag ägnar man mycket tid till försäljning. Man måste alltid berätta om vem man är och etablera sig hos varje kund. Här i det stora konsultbolaget verkar vi nästan inte behöva det. Uppdragen verkar mer komma av sig själva, men det kan också komma sig av alla kontakter med olika företag från en stor säljkår. 

Jag måste lära mig att säga nej, behöver och hinner inte alls leta egna uppdrag. Annars blir jag överstimulerad och mitt privatliv och även kvaliteten på det jag gör blir lidande. (Jag måste ju ha tid att skriva på den här bloggen! Den tiden är väl inom privatlivsdelen i mitt fall, eller hur =).

Det är dock märkligt att skillnaden kan vara så stor. Jag tror att det beror på det Kotler inom marknadsföringen kallar skillnaden mellan att vara dominerande aktör eller niche-aktör på en given marknad.

I Köpenhamn på konferens för erfarna arkitekter

För några veckor sedan fick jag mitt första mail från en engelsk kollega inom samma koncern. Han bjöd in mig att vara vårt företags, ja hela vår internationella koncerns representant på en konferens som hålls i Köpenhamn nästa vecka. Namnet på konferensen är “Microsoft EMEA Partner Senior Architect Forum” och jag kommer att följa “Business Productivity IO Track” vilket kommer att handla mest om Microsoft Office SharePoint Server 2007 och hur man kan och bör en grupp av produkter som alla har målet att förbättra för rollen “Information Worker”. Väldigt förenklat innebär det Microsoft Office verktygen och SharePoint tillsammans.

Jag blev väldigt glad. Tänk att få representera alla 40 000 kollegor. Intressant att få träffa engelsmannen och holländaren som är de andra representanterna från vår koncern. Jag tänkte blogga varje dag från konferensen som börjar vid lunch måndag den 5e mars.

Vad skulle du vilja veta om konferensen? Könsfördelningen mellan män och kvinnor? Skriv gärna en fråga bland kommentarerna så att det här ännu mer blir en interaktiv blogg.