View Source

Her følger noen noterte utsagn fra Open Space gjennomføringen på [IASA-medlemsmøte 2009-04-22 - Hva er arkitektens ansvar?] (ofte parafrasert noe). Dersom du ønsker å videre detaljere utsagnene eller komme med innspill som mangler oppfordrer vi til å fylle det inn på denne siden.

Det er også opptil flere gode utgangspunkter for lyntaler i denne materien, og flere som var innom gruppen later til å ha nok å melde til å kunne sette sammen noe slikt. Tenk på dét:-)

h2. Noterte utsagn fra Open Space
* _Mye diskusjon rundt arkitektrollen_
* Får alle roller/posisjoner i teknologiprosjekter med et visst snev av ledelse, ansvar eller senioritet en "-arkitekt" suffiks? Og er dette formålstjenelig?
* Er det enighet om at arkitektrollen HAR ledelse som et hovedparameter?
** De fleste holdt på at rollen betinget å få en gruppe til å handle i samme retning så derfor stort sett: JA
* I softwareprosjekter blir alt repetetivt automatisert. Det betyr at det gjenstående (som da blir arkitektens ansvar) er det manuelle og uforutsigbare
* Arkitektens muligheter for å lykkes med å forankre budskap oppover i store organisasjoner er svekket av kommunikasjonsimpedans
* "Street-cred" arkitekten virker å være en velkjent stereotyp: Den operative problemløseren som kan putte penga der kjeften befinner seg til enhver tid
* Visse arkitektroller kan gjøres fullstendig irrellevante av omkringliggende beslutninger. Eks: Street-cred arkitekten mister hele sitt fundament om bedriften gjør et strategisk teknologiskifte ( feks .net -> java)
** Indikerer dette et hovednivå for arkitektrollen: De som kan overleve slike skifter og de som ikke kan det?
* Kan du kalle deg arkitekt dersom du ikke har mandat, ansvar eller valgfrihet for at ditt leveranseområde skal lykkes?
* Uklare roller er ofte grunnen til at mange prosjekter feiler
* Bør arkitekten evne å tilpasse sin lederstil til hva som skal leveres og til teamet som skal levere?
* Har arkitektrollen tydelige nok ROI måleparametre?
* Bør arkiteken ansvarliggjøres for "essensielle" feil som får overleve (ref. Jasons lyntale)?
* Hvordan skal arkitekten velge lederstil dersom hun ikke vet hvordan suksess måles?
* Dersom alle arkitekter benytter en lederstil, er den predominante utgaven "Kreativ leder" som beskrevet av Johannes (fasiliterende, overlater ansvar til teamet, lite instruerende)?
** Hvilke andre lederstiler er effektive/relevante å ha i kofferten som arkitekt?
** Er det i det hele tatt mulig å ha en lederstil som motiverer ALLE? (Noen som har noe lederskapsteori for hånden (?))
* Pecking-order og militæranalogien:
** Kapteinen vs. Sersjanten: Sistnevnte har street-cred mens førstnevnte er formelt utdannet ved West Point til å ta strategiske beslutninger og får derfor (kombinert med rang) autoritet. Men innen software teller bare street-cred siden alle er "utdannet på West Point".
** Er utvikler-rollen for godt betalt til at en gruppe talenter tar seg bryet med å formalisere en "West Point" differensiering?
** Kan Johannes scenario om at top-down policies fra arkitekt-befal brukes til ansvarsfraskrivelse på utviklernivå sammenlignes med soldaters ansvarsfraskrivelse ved beordrede krigsforbrytelser?
* Arkiteken må bruke sine "uoffisielle våpen":
** Økonomisk "Cloak & Dagger": Ta kontroll over budsjetter og estimater nok til å skape et skjult rom for teamet til eksperimentering, feiling, og oppgaver som skaper verdi men ikke lar seg kommunisere til forretning i første runde
** Eksperimenter med middagen på lørdag når du har skapt deg rom for å feile. Ikke lag thaimat for første gang mellom SFO og fotballtrening og foreldremøte. M.a.o. LAG rom for å feile, tilrettelegg og eksekver i trygge rammer. Dette er et tegn på en god arkitekt (eller er dette prosjektleders oppgave?)
** Skill mellom høy-, og lavrisiko elementer og prioritér for å sikre sikre seiere, og potensielle wow-suksesser
* Hvilken rolle spiller arkitektonisk stil? Blir feil valg her spesielt dyre?

h2. Videre detaljeringer

h3. _Lag din egen header her_
_og gå bananas her_ :-)