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

Arkitektrollen ifrågasätts

Det pågår en debatt om arkitektrollen och försöken att definiera rollen. Den angrips från Agile-förespråkare som  som i detta ett inlägg kallat Skolan för arkitektur

Utdrag: Jag är övertygad om att det finns många som kallar sig
arkitekter som i själva verket fungerar som arkitekturcoacher, speciellt
bland personer som omfattar agila värderingar; som skapar god matjord
för det samarbete som vi så förtvivlat behöver för lyckade
projektresultat. Men den stora arkitektmassan kommer att titulera sig
“certifierad arkitekt” och tyvärr tolka detta som ett mandat att fungera
som expert och av andra kräva att behandlas som en sådan…

Mina reflektioner:

1. Arkitekten som expert
Jag håller helt med om mycket. En arkitekt som med hög svansföring skall ta alla beslut rörande arkitektur är helt fel för projektet. Det blir snarare ett hinder. Däremot om utvecklarna delat upp sig i två läger och tycker olika, då tycker jag att arkitekten kan vara med och lösa upp knuten och i några fall bestämma vilken väg man skall välja bland de två. I din coachroll så saknar jag just denna aspekt; att ytterst vara ansvarig för besluten. Jag anser att arkitektrollen skall vara delegerande/stödjande för de som arbetar som lösningsarkitekter.

2. Perspektivet är alltför begränsat till utvecklingsprojekt
Problemen som jag ser i branschen finns inte alltid inne i ett utvecklingsprojekt. Arkitektrollen är större än bara ett visst utvecklingsprojekt. Om jag granskar min erfarenhet så är vanligt att de verkliga hindren för att få ett gott resultat ligger utanför själva utvecklingsprojektet.

I övrigt tycker jag att det är synd att vissa arbetsuppgifter skulle uppfattas som “finare” än andra. Det tycker inte jag. Alla är lika viktiga. Vi är alla ömsesidigt beroende av varandra. Däremot tycker jag att vissa frågor intresserar mig och har alltid intresserat mig. Jag märker också att jag är bättre på dem än många andra, men även här har jag också föredömen/mentorer som är bättre och som jag lär mig av. Sedan att dessa uppgifter är “högre” upp i värdekedjan är bara ett lyckligt sammanträffande för mig.

Jag satsar numera på arkitektrollen med inriktning på VA(verksamhetsarkitektur) och tjänstebaserad arkitektur(SOA). Därutöver vill jag speciellt ägna mig åt frågor som kallas “Human Dynamics” inom IASA och jag hoppas att jag kan bli respekterad för det valet på samma sätt som jag respekterar andra som gjort andra val.

Har du i din roll problem med att respektera det?