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.

Scaling Software Agility

Har blivit inspirerad av ett ramverk. Scaled Agile Framework. Det verkar intressant eftersom det både innehåller agila begrepp och styrningsbegrepp som portfölj och portföljstyrning. http://scaledagileframework.com/

ScaledAgileFramework

En annan mycket intressant artikel som påvisar aspekter och jämför olika former av utvecklingsarbete är http://www.lostgarden.com/2007/02/rockets-cars-and-gardens-visualizing.html

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.

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

Youtube fanns inte 2005 – nu kommer Google Wave

Utvecklingen går rasande fort. Youtube.com skapades 2005 och spreds 2006. Spridningen till en globalt känd sajt har inte skett med reklam utan från person till person. Nu i december 2009 kan ingen tänka sig att Youtube är bara fyra år gammalt.

Här är den först uppladdade videon till Youtube…

Den slutar med ”that is all that is to it”. New York Times har värderat Youtube som ägs av Google till minst 1 miljard dollar.

Jag har börjat använda Google Wave. Min gissning är att Wave kommer att ha en liknande utveckling som Youtube…

Google Wave använder en arkitekturprincip kallad ”Live collaborative editing” som medger att uppdateringar sker både ute hos användaren och på servern samtidigt. Det kommer att revolutionera ”chatttjänsterna” för det blir möjligt att parallellt och samtidigt skriva kommentarer hos flera användare med bibehållen ordning på inläggen. Häftigt. En mindre revolution arkitekturmässigt. Se denna video om du är nyfiken och nördig som jag och vill veta hur det fungerar…

Krav på delaktighet växer överallt!

Staten måste stöpas om säger Don Tapscott, kanadensisk e-förvaltningsguru. Nu gäller Staten 2.0, där myndigheterna interagerar med medborgarna på deras villkor. Det är bara ett exempel på en trend där kraven på delaktighet och dialog växer.

Folk accepterar inte det gamla sättet att ledas ”top-down” utan väljer med fötterna det de gillar.

Man kan fråga sig om inte traditionell web skriven av redaktörer och annonser är gammalt tänkande och att det kommer att ersättas av mer sociala webbplatser som facebook och twitter.

Jag tror det och jag hittade ett bra föredrag som talar om detta Social Media Workshop – New Economy

Projekt i den nya globala världen

Vi kommer att arbeta mer och mer i globala projekt. I Asien växer IT-satsningarna starkt. Läs Reuven Cohens blogg om framgångar för Cloud Computing i Asien.

Det kommer att bli viktigt att veta vad som fungerar och inte fungerar när teamet är spritt över hela världen och man måste leverera resultat varje dag, vecka och månad.

Jag hittade en riktigt bra inlägg, ett pattern, för detta. Läs J.D. Meiers blog ”Patterns and practices for distributed teams” om du vill.

Lycka till. Framtiden tillhör de som har erfarenhet av globala projekt.

Verksamhetsarkitektur(VA) och behovet av VA

En insikt efter paneldebatten är att vi deltagare talar förbi varandra. Anledningen är att vi har olika definitioner av vad en arkitekt är och att vi har olika problembilder som vi vill lösa.

Rollen som jag företräder här i detta inlägg heter verksamhetsarkitekt och området heter verksamhetsarkitektur(VA). Jag vill ge ett exempel på ett problem som är lagom komplext men som visar på behovet av VA. Nedan finns en skiss över Scrum-teamens ansvar:

3 team med totalt 20 personer

3 Scrum-team med totalt 20 personer

Utvecklingsarbetet är uppdelat i tre olika oberoende Scrum-team som samarbetar eftersom det anses vara det mest effektiva i den aktuella situationen. Om alla 20 skulle arbeta i samma team blir resultatet sämre. Uppdelningen i team leder i sin tur till problem som redovisas längre ner.

Kund – teamet utvecklar ett CRM-system som fokuserar på kunder, många länder, många marknader, komplicerade kundorganisationer med dotterbolag, marknadsbolag och internationella koncernbolag med personal med olika roller.

Produkt – teamet utvecklar ett produkt och konfigurationssystem med många olika produkter som består av komponenter, där produkterna kan sättas samman i sammansatta produkter och där man ute vid sälj- och leveransprojekt önskar få hjälp med vilka komponenter som fungerar i vilka produkter och i olika versioner.

Installerade produkter – teamet utvecklar ett system som har som mål att hålla reda vilka produkter i vilka konfigurationer har installerats hos vilka kunder och på vilka platser. Man vill kunna svara på frågor som:  Vilka avtal finns och vad avser de? Vilka tjänster, garantier och service ingår? Vem är kontaktpersonerna hos det egna företaget och hos kunderna?

I verksamhetsarkitekturen beskrivs i enkla modeller och innehåller övergripande processbeskrivningar, informationsmodeller, existerande system och gemensamma tjänster enligt SOA. Det finns också matriser som visar existerande beroenden mellan processer, informationsobjekt, system och SOA-tjänster.

Verksamhetsarkitekturens modeller ligger lagrat gemensamt och tillgängligt för att alla teamen skall ha tillgång till en gemensam bild på helhetsnivån. Avsikten är att modellerna skall underhållas ute i de olika teamen och att ändringar av gemensamma modeller skall ske kontrollerat och därefter spridas.

Problem: De olika teamen har olika syn

Det finns i exemplet tydliga beroenden mellan teamen men trots att man utsett en ansvarig för modellerna och möts i gemensamma möten enligt federativ modell så kan man inte enas. Produkt och Kundteamen tycker inte att det är viktigt att uppdatera de gemensamma modellerna. ”Installerade produkter”-teamet anser att det är viktigt. De är också i högsta grad beroende av de andras modeller.

Min fråga till agilisterna: Vad gör man?

Vad gör man om man är renlärig agilist (förespråkare av Agile Manifesto) om man är beroende av varandras modeller mellan teamen men ett eller flera team prioriterar kortsiktigt och man efter samtal inte kan påverka de andra teamen att ändra sig? Samlar man produktägarna? Eller beställaren? Eller bidar man sin tid till fler blir medvetna/mogna och inser problemet och vill lösa det?

Mitt förslag på lösning: Verksamhetsarkitektens arbete och ansvar

En utsedd ansvarig verksamhetsarkitekt eller en styrgrupp går in med mandat och anger ramarna för hur viktiga modellerna är och hur de skall underhållas av teamen. Teamen anpassar sig till dessa ramar. De gör fortfarande inte lika (vilket är tillåtet), men de håller sig inom de uppsatta ramarna, om inte så måste någon styra upp det hela efter sitt mandat. Det finns ett motsatt problem när teamen arbetar för mycket med sina modeller. Det är inte heller tillåtet.

Problem med Agile-synen

Agilisterna(förespråkare av Agile Manifesto) saknar lösning på problemet ovan om de inte accepterar någon som har mandat att styra när teamen har olika åsikter och inte kan påverkas. Agilisterna gillar oftast inte heller det faktum att teamen måste uppdatera de centrala modellerna. Anledningen är att modeller inte är fungerande programvara som är det enda resultat som verkar räknas inom Agile, eller som det står i manifestetWorking software over comprehensive documentation”. Egentligen är källkoden också slags en modell, ett perspektiv över systemet. Fast det har man ofta inte tänkt på.

Lösning: Vidareutveckla Scrum/Agile

Min åsikt är att agilisterna är alltför begränsade i sin problemdefinition. Deras nuvarande arbetssätt fungerar bara i mindre sammanhang i små företag eller för arkitektur inom en lösning.

Det bör vi ändra på. Det kan lösas om vi vidareutvecklar Scrum/Agile-rollerna och tillåter modeller som resultat och använder redan etablerade och fungerande sätt att snabbt ta fram dessa modeller.

Modellerna får inte ta för mycket tid

Modellerna får inte ta mer än max 2 månader att ta fram initialt och de finns sedan gemensamt tillgängliga. Specialister(verksamhetsarkitekter) och inte teamen är ansvariga för att det finns modeller att utgå ifrån. De första modellerna tas fram i seminarieform av erfarna seminariehandledare tillsammans med sakkunniga från verksamheten.

Teamens ansvarar för återkoppling

Teamen är ansvariga för att underhålla och uppdatera modellerna mer eller mindre kontinuerligt och att bevaka och anpassa sig och införa förändringar i de gemensamma modellerna som berör teamets ansvarsområde.

Lösningen ovan finns nästan i verkligheten också

Lösningen ovan är inspirerad av ett företag i telekombranschen. Mandatet att ge riktlinjer, granska och styra projekten är i den organisationen delegerat till en grupp, ett forum (Information Model Architect Forum). På det företaget har man inte anammat Agile/Scrum än annat inom små projekt inom teknisk produktutveckling.

Vinster med verksamhetsarkitektur(VA)

Företag som har ordning och reda på sin verksamhetsarkitektur kan tjäna mycket på det eftersom det ger klarhet och tydlighet. IT-systemen förbättras. Ledningen får bättre kontroll, även på kostnaderna. Kvaliteten höjs. Systemlösningarna kan bli mer flexibla och beslutsunderlagen för ledningen kan förbättras inför stora förändringar som inför uppköp och sammanslagningar.