Vad förväntas en certifierad arkitekt kunna?

En av mina utbildningar och certifieringar som arkitekt heter ”Certifierad Microsoft .NET-arkitekt av Microsoft Sverige och Sundblad & Sundblad” som jag gick 2006. Tänkte lyfta fram det jag skrev om kraven för det gäller fortfarande.

Certifieringen innebar utbildning hos Sundblad&Sundblad under under 4 ggr 3 dagar, tillsammans 12 dar.  Den kanske största behållningen av kursen var diskussionerna med kursledningen och de andra kursdeltagarna. Nästan alla var erfarna utvecklare, en del var konsulter, andra anställda på stora företags IT-avdelningar.

Tyngdpunkten låg på att förstå verksamhetens krav och hur de skall överföras till lösningar. För att riktigt kunna ta till sig utbildningen anser jag att man måste ha gått och funderat på verksamhetsprocesser och problem kring dessa och hur de borde lösas i tio år. Så var det nog inte för alla. Sedan var det väldigt mycket om SOA. Det är inte vanligt med så bra kurser.

Utbildningen utvärderades av Microsoft Learning i Redmond och de fann att materialet och effekterna på deltagarna var mycket goda. Därför har man köpt ut utbildningssmaterialet och skall genomföra utbildningen on-line webbaserat över hela världen tillsammans med Sten och Per Sundblad.

Microsoft tog för några år sedan fram ett certifieringsprogram för arkitekter som är mycket exklusivt och dyrt. Målgruppsmässigt är det avsett för kanske 5-10 personer totalt i Sverige. Kraven är tydligen extremt höga men områdesindelningen av vad man skall kunna är intressant.

Lösningsarkitekter(Solution architects) förväntas ha goda kunskaper inom följande områden:

  • Ledarskap
  • Kommunikation
  • Organisationslära
  • Strategi
  • Arbetssätt och taktik (innefattar kravhantering, modellering, informationsmodellering, stödja teknisk projektledning, metodkunskap, förståelse för driftsättningsstrategier och begrepp som SLA och ITIL)
  • Teknisk bredd
  • Tekniskt djup

Även om jag inte alls tillhör de fem svenskar som skall prova att certifiera mig enligt det programmet anser jag att områdena väl beskriver vad som krävs av en arkitekt. Det är en bred roll. Många av områdena är mjuka områden som ledarskap och förmåga att hantera konflikter. Det är också tydligt att det inte är teknisk projektledning, utan man skall ge bidrag till de som arbetar med teknisk projektledning. Teknisk projektledning är en egen specialitet även om kunskapskraven är ganska lika.

Läs mer vad varje område innehåller och om Microsofts certifieringsprogram för arkitekter här

Man verkar inte behöva kunna något om Agile eller Lean Software Development. Det är en brist i deras program.

Annonser

Vilket är framtidens programspråk för företag?

Vilket programspråk är störst? Vad är på gång? Vilket språk skall man satsa på? Som företag eller när man vill lära sig något nytt? Ett svar finns här:
TIOBE Programming Community Index

IT-branschen sägs vara kreativ och nytänkande. När man ser dessa resultat undrar man om det inte är det motsatta. Eller är för att man gjort så stora projekt/investeringar i C att man inte kan göra annat än att fortsätta?

Ett kriterium borde vara att välja det programspråk/miljö som ger bäst produktivitet. Det argumentet borde styra både nystartade och etablerade företag. Dynamiska språk som Ruby och Python har en potential men det är mycket långt kvar till världsherravälde enligt listan.

Ett annat alternativ är Microsofts LightSwitch eller liknande. Kan det förena både rapid-development med att man inte blir instängd?

Future of inventing and creating ideas?

In an interesting video Bret Victor gives some insight to what could be the future. This could be a BIG break-through. The current model of interaction can be changed to something that supports creativity better.

Guided by the principle of ”Creators need immidiate connection” – to see the results from their work immediately – he shows ways to follow that principle in programming and in other fields and compares this to other previous inventions.

The talk is called ”Inventing on Principle” and can be found here. The fun begins after a couple of minutes. In the end he has some really interesting thoughts.

Mobil datatrafik exploderar

Antalet mobila telefoner som kräver bra prestanda i nätverket växer lavinartat de närmaste åren. Priset för en bra Androidtelefon bedöms 2012 sjunka till under en tusenlapp. Lägre pris och fler enheter spär på behoven ytterligare.

Telefonoperatörerna har i år minskat sina investeringar i nya nät till följd av den senaste krisen. Ericsson som är beroende av dessa investeringar redovisade ett svagt kvartalsresultat i veckan.

Borde inte explosionen av datatrafik göra att investeringarna i nät ökar? Köpläge i Ericsson? Och säljläge i telekomoperatörerna när det blir uppenbart att det krävs stora investeringar? Tydligen har Ericsson senaste kvartalet satsat på denna utveckling när man valt att sänka priset för att öka marknadsandelen i USA. Var det rätt strategi? Klarar Ericsson av att höja priserna igen? Blir behoven tillräckligt stora? Jag tror det.

User Interface(UI) för appar är enklare att utveckla

Har testat att bygga några enkla appar för Android. Det slog mig hur mycket enklare det är att bygga User Interface(UI) för dessa appar än att skriva HTML+javascript för en webblösning. Flera saker ligger bakom detta faktum. Apparna har färre möjliga alternativ. Ett inmatningssida är en enkel sida, iofs kan den ha olika storlek men inmatningsfälten placeras dynamiskt. En nedfällbar lista fungerar av sig själv utan javascript. Det mesta fungerar enklare än i HTML.

Kommer appar att ta över även för interna applikationer inom företagen? Troligen kommer det att ske på sikt. Det behövs dock viss vidareutveckling och mognad. Idag är det komplicerat och dyrt att integrera apparna med interna system. Det man vinner på att UI-delen  är enklare förloras ibland genom att integration är mer komplicerad. Apparna har hittills mest handlat om nya lösningar med små behov av integration. Dessutom är det tidskrävande att utveckla för både Android, iPhone och Windows. Det finns fortfarande många delar som kan förenklas.

Apparna är det senaste i raden av exempel där lösningar för hemma-användare sprider sig in i företagen. Tidigare exempel är persondatorn(PC) och molntjänster( som Google Mail ) som först blev vanligt hemmavid innan företagen valde att införa dem.

Nya databasalternativ BASE och VMDBMS

Den databas-teknologi vi idag använder har varit oförändrad sedan 70-talet. Nu kommer nya alternativ eftersom de äldre  inte klarar dagens höga krav. Databasen är en flaskhals och man kan kanske inte lösa det så enkelt som att lägga till mer datorkraft. Som grupp kallas dessa databaser NoSQL, men det finns olika grundideer. No SQL skrivs numera (Not only SQL) och många lösningar bygger på SQL, men utan de gamla flaskhalsarna.

Alternativen är obeprövade i stor skala och har sina nackdelar och problem, men idéerna och tankarna bakom är intressanta.

BASE

BASE är ett annorlunda tankesätt där man tummar på en av grundreglerna. BASE betyder (basically available, soft state, eventually consistent) och bygger på idéen att man i vissa fall kan tillåta icke-konsistent data under korta perioder för användarna som några sekunder. Efter en tidsperiod blir data konsistent. Användarna av lösningarna måste acceptera detta, men det är inte mer konstigt än att saldot för kreditkort blir korrekt först några dagar efter att transaktionerna gjorts.

Läs mer på http://queue.acm.org/detail.cfm?id=1394128

VMDBMS – hämtat från en produkt från Starcounter

I Java och C# finns en virtuell maskin (VM) som lagrar programmets objekt i minnet. Med RAM-databaser har man kunnat förbättra prestanda med tusentals ggr. Svårigheten och begränsningarna finns i att lagra data permanent. För det är en vanlig databas(DBMS) bättre. Med VMDBMS menas en kombination.

Jag har läst om en intressant produkt inom området från ett svenskt bolag Starcounter. Som jag förstått deras material fungerar det så här: VM lagrar normalt data i en HEAP som i detta fallet inte är RAM-minne utan istället en DBMS. Skrivningen delas upp så att enbart transaktionerna loggas direkt på disk medan själva lagringen i tabellerna sker asynkront i bakgrunden. Man får styrkan från RDBMS och hastigheten från skrivningar i RAM-minnet.

En intressant konsekvens är att man får transaktionshantering av minnet(HEAP) vilket gör att man inte behöver hantera samtidig skrivning från flera parallella processer(thread-safety). Transaktionshanteringen gör att man styr när förändringen blir synlig för andra processer.

Produkten bygger på optimistisk låsning, men det känsliga tidspannet blir kortare när skrivningarna går fort och därmed sjunker risken för konflikt.

Läs mer på: http://www.starcounter.com/VMDBMS-white-paper.pdf

MacBook Pro

Har köpt in en MacBook Pro. Min första Mac. För 18 år sedan på tekniska högskolan i Linköping blev jag ”frälst” på Appledatorer. Jag tänkte mig att jag bara skulle arbeta med Mac. Så blev det inte. Det blev PC istället. Det finns mycket mer IT-jobb och systemutveckling i PC-världen.

Fast en gång hade jag ett konsultuppdrag med ett specialanpassat verktyg för Mac som hette HyperCard. Hypercard hade hyperlänkar för navigering innan webbsidor ens var påtänkta.

Men nu är jag tillbaka. Fast jag har också minst 4 PC hemma…

Världens största SOA-projekt?

För några år sedan lyssnade jag på ett föredrag om Microsofts IT-avdelning som sedan 2001 drivit ett imponerande SOA-projekt(Alchemy) för deras egna interna system och applikationer. Erfarenheterna som redovisas gäller även idag för många organisationer därför vill jag redovisa dem igen.

Microsoft började med att på ett halvår exponera webbtjänster från fem av deras stuprörssystem som Siebel för CRM mm och bygga en gemensamt  användargränssnitt för alla dessa system. På det sättet kunde man minska utbildningstiden för att lära sig applikationerna och även arbetstiden som gick åt för att växla mellan applikationerna och manuellt kopiera information dem emellan. Man räknar med att varje anställd tjänat 2 timmar per vecka i snitt på systemet och eftersom man är 17 000 anställda så blir det en hel del tid intjänat. 34 000 timmar/vecka vilket blir en massa miljarder i intjänade bucks.

Om man är utvecklare och vill anropa en tjänst så är målet att Alchemy skall extrahera bort all komplexitet och göra det enkelt för utvecklaren. Anropet görs mot ett namngivet system men allt som händer på vägen är dynamiskt och samtliga anrop loggas i detalj. I början hade man 100 k anrop per dag och nu är man uppe i 1 miljon anrop. Loggdatabasen fylls på med ytterligare 10 Gb data på sex timmar. Ungefär den mängden data analyseras och flyttas till en datawarehouselösning. I den bygger man en kub med 83 dimensioner som ger informeration om allt möjligt, mest prestanda och ifall man uppfyller de hårda SLA(Service Layer Agreement) som finns. Efter analysen kastar man det mesta av dessa 10 Gb, men ändå, tänk att logga allt. Verkligen kraftfullt.

Varje anrop kontrolleras avseende på säkerhet och konfiguration. Det är svårt att styra en så stor park med servrar. Att få ut gällande konfiguration är en utmaning. Den anropande tjänsten börjar därför med att kolla om det finns ny konfiguration för anropande delar, om det finns laddas det ned automatiskt, sedan sker anropet, eventuellt i flera steg, för varje steg läggs en säkerhetsidentitet till, så att man slutligen kan avgöra rättigheterna och garantera att ingen obehörig får access. Som sista steg laddar man ner konfiguration för tjänsten också och sedan körs anropet. Det måste kräva en enorm datorpark, alla dessa servrar som bara används för infrastrukturen innan själva anropet, men eftersom man har som krav att det skall vara enkelt med maximal kontroll i kombination så är det en intressant lösning.

Konfigurationsstödet innebär att man centralt kan slå av så att en av de 105 system som anropar tjänster inte längre tillåts göra det, eller att hälften av anropen till en viss tjänst skall omdirigeras till en ny server. Väldigt imponerande och jag kommer inte ens ihåg hälften av vad som sas.

Idag tar det 2 minuter för utvecklaren att installera stöd för Alchemy. Tidigare krävdes det 20 minuters programmering för att använda Alchemy. 20 minuter upplevdes som otroligt lång tid. Systemet fick dåligt rykte därför(man har inte haft problem, bara totalt 30 min downtime på de centrala delarna av systemet sedan våren 2003) och man har därför centralt inom IT beslutat sig för att överge Alchemy för ett nytt system kallat ”Rome”. Huvudorsaken för det är att det nya kommer att vara ännu enklare för utvecklarna att använda och därigenom få ännu mera genomslag inom organisationen. Det finns nästan inga som svårare att övertyga än ”högt betalda” programmerare. Målet är att det skall ta 30 sekunder att lära sig hur man anropar en tjänst. Inte mer. Det är inte en lösning att någon hög chef ger order om vilka system som skall användas. Det måste vara lätt, mycket lätt, för att användas mycket och i många sammanhang.

Det andra rådet man gav är att man måste ha högsta ledningens stöd. De måste vara insatta. SOA handlar inte om teknik; Det handlar om företagande. Om man inte har högsta ledningens verkliga stöd så bör man lägga ner projektet. Annars fungerar det inte. Problemen som uppkommer, och de kommer, måste kunna hanteras. Hela organisationen måste stå bakom förändringen, åtminstone hela ledningen.

”Du kan sälja det kunden (tror han) vill ha, och jag kan leverera det kunden behöver!”

En erfaren verksamhetsarkitekt sa så till mig i ett sammanhang. Han hade sagt det till den kundansvarige och erfarne säljaren på konsultbolaget.

Verksamhetsarkitekten menar att ledningen/cheferna egentligen inte på djupet förstår och är insatt i detaljerna och därmed inte heller i vad de verkligen behöver. Detsamma gäller säljaren. Säljaren tror också, liksom cheferna, ibland att de vet vad de behöver. Låt alla tro det. Verksamhetsarkitekten, om han har riktigt stor erfarenhet, levererar det kunden behöver. Det blir win/win det. Fast på ett ovanligt sätt.

Det finns en variant av ovanstående som ofta förekommer, som får riktigt allvarliga konsekvenser. Det är när IT-folket tror att de förstår verksamheten och inte verkligen försöker förstå verksamheten. Då blir det fel. Och dyrt. 

Erfarenhet är nog enda sättet för att förstå vilket av alternativen som sker i ett specifikt fall för en viss kund. Att chefer och säljare skulle förstå alla detaljer går inte heller. Det kallas micro-management och funkar inte heller.

En IT-arkitekts perspektiv

Nej, det här är ingen företagsblogg om datateknik, inte heller en reklamblogg för det bolag som jag arbetar på! Det är en personlig blogg om allt som intresserar mig. Jag ogillar den bild som finns av de som arbetar med IT och tänker försöka visa att man inte alls är en nörd som bara håller på med en sak bara för att man arbetar med IT.

Ungefär en tredjedel av mig är mitt intresse för teknik och systemarkitektur och minst en tredjedel av inläggen kommer att vara inom mitt professionella område. Mitt område är faktiskt intressant och handlar mycket om människor och teambuilding, även om datatekniken är grunden i de projekt som jag är engagerad i professionellt.

Jag blev inspirerad till att starta bloggen av Karolina Lassbo (glamourprinssessan). Hon höll ett bra föredrag om bloggandet på en konferens. Tänk bara att som jag får betalt för att träffa och lyssna på Karolina på en konferens. Jag tjänade nog mer den timmen jag lyssnade på henne än vad Karolina gjorde. Det är inte rättvist egentligen.

En tredjedel av mig är mitt intresse för människor, psykologi och ”mjuka sidor”. Det är svårt med det ingår i arkitektrollen och IASA, en branschorganisation, kallar området ”Human Dynamics”.

Jag har lärt mig en del inom området genom att gå kurser, dels genom coachingutbildning och praktik och dels genom att jag utbildat mig till certifierad Scrum Master och praktiserat detta. Människor är intressanta. När jag i ett samtal kommer fram till orden, bakom orden, och man får tala om det som verkligen berör människor på djupet.

Vi svenskar undviker verklig närhet, enligt Fredrik Lindströms program, så ur den aspekten känner jag mig osvensk. Jag vill ha en annan ordning.