Idag var jag med på ITARC 2016, en årlig konferens för it-arkitekter, denna gång på fina Elite Hotel Marina Tower strax utanför stan.
På förmiddagen var jag med på en workshop om
Den leddes av Per-Erik Padron, konsult på Perago och Joakim Jerbrant, chefsarkitekt på Nordea.
Runt 17 personer deltog och presenterade sig med titlar som, Enterprise Arkitekt, Chefsarkitekt, Verksamhetsarkitekt och var mestadels verksamma inom större organisationer. (Det var roligt att se deltagare från 2 större organisationer där jag installerat Lync och kanske bidragit till kommunikationen på ett hörn.)
Kommentarer och diskussioner startade direkt under presentationerna i stil med:
- Vi diskuterar ofta begreppen inom arkitektur och vad ansvaret för arkitekten är.
- Hos oss är det mycket "tyckande", var är vi? vad är vi bra på?
hur förbättrar vi det vi inte är bra på? - "I en stor organisation finns både guldklimpar och surdegar."
- Hur kan vi mäta om vi blir bättre inom arkitektur?
Nedan följer mina spridda anteckningar från dagen, som kanske kan användas som stöd för minnet i arbetet med nästa bok.
Swenglish är ett generellt problem inom arkitektur området då mycket av litteraturen och influenserna kommer på engelska.
Vad är arkitekturell förmåga?
Många definitioner finns, och sammantagna kan de kanske kokas ner till:
"De förutsättningar och skickligheter en organisation har att utforma delarna i den sociotekniska strukturen (människor, relationer, IT-stöd, etc) och få dem att samverka för att organisationen ska kunna uppnå sitt mål."
Arkitektur i en organisation är inte en soloaktivitet utan ett lagarbete.
Var ska ansvaret ligga?
Tidigare var detta ofta personberoende, seniora personer med "guru-status" som kanske inte kommunicerade så bra, kom inte med lösningar utan talade mest om vad som var fel.
Det pendlar ofta mellan centralt / lokalt, och inbegriper ofta internpolitik.
Arkitekten behöver vara insatt i var organisationen är på väg.
Tycker inte personen om mig så lyssnar hon inte.
Att mäta förmågan, hur gör man?
Resultat kanske inte är så viktigt, det är viktigare att få igång diskussionerna kring arkitekturarbetet.
Hur mäter man att ett projekt lyckas? Resultatet av projektet eller att projektet levererade på tid och inom / under budget?
Många ramverk och standardmetoder finns (ITIL, TOGAF, RUP, SAFe, Zachman) som kan användas "som inspiration", d.v.s. de måste alltid anpassas till "vår" organisation. Passar ramverket oss, kan vi plocka bitar av det? Först när man utvärderar så ser man allt som är bra med metoden, sedan när man sätter igång och implementerar ser man problemen med metoden. Med ett ramverk som grund kan det bli lättare att sälja in en förändring mot ledningen, i stil med - om företaget / konkurrenten x använder detta ramverk - då måste det väl vara bra och fungera för oss?
Sedan följde en lång diskussion i mindre och större grupper angående förutsättningar och skickligheter för den arkitekturella förmågan.
Efter lunch följde en något större workshop med temat
Att kommunicera arkitektur – handboken
och det är alltså den bok vi håller på att skiva nu.
Per-Erik Padron och Stefan Asanin, IT-arkitekt på Vattenfall, ledde denna workshop med 38 deltagare.
Vi fick bra feedback kring de roller vi tänkt behandla och även kring vissa beskrivningar som troligen behöver "moderniseras" något. Vi behandlar förstås ett område som utvecklas mycket snabbt.
Boken kommer handla om kommunikation eftersom:
- Kommunikation är en kritisk framgångsfaktor för arkitekturarbetet.
- Kommunikation mellan arkitekter och mellan arkitekten och personer som inte direkt arbetar med arkitektur skiljer sig åt och måste fungera.
- Arkitekten ska inte bygga eller utföra själva arbetet - därför måste arkitekten kunna kommunicera väl vad resultatet ska bli.
Diskussionen flöt på bra trots att vi vår så många som 40 personer i rummet, och jag tog med mig ett par bra tankar som jag hoppas utveckla i text i boken vi skriver.
Tack IASA Sverige för en bra konferens, ett bra tillfälle att träffa medförfattare och samla feedback.
No comments:
Post a Comment