En ældre kollega i arkitektur-team, jeg arbejdede i en gang, gnækkede tit ”metoder er krykker for dem, som ikke kan selv”. Underforstået at han ikke selv behøvede en krykke og at resten af teamets arbejde med metoder var for at kompensere for vores egne utilstrækkeligheder.
Det havde han naturligvis ikke ret i. Metoder, principper og processer er nyttige i flere sammenhænge: Når flere personer skal arbejde sammen om noget, når der er afstand mellem hvor beslutninger træffes og hvor de skal udføres, eller når vores arbejde skal overleve længere tid på arbejdspladsen end vi selv gør. Og metodeløshed kan i lige så høj grad som metode-stringens være udslag af inkompetence og give dårlige resultater.
Men det er efterhånden min erfaring, at for mange arkitekter ser it-governance-processen og arkitekturprincipper som guldstandarden for arbejdet med arkitektur. Bare de to ting er i orden, er vejen banet for arkitekturens fuldbyrdelse over tid. Arkitekturprincipperne sætter rammerne for projekterne og projekterne skal igennem godkendelses-gates hvor arkitekten kontrollerer overholdelsen af rammerne. Done. Flere lader til at tro, at de kan programmere en organisation til at følge en arkitektur på sammen måde som da de programmerede et system til at eksekvere algoritmer, men sådan virker det ikke. De arkitekter oplever at ”vi bliver ikke inviteret med” eller ”vi er ikke blevet informeret om projekterne” og frustrationen er tydelig over at ”projekterne ikke følger principperne”. I det hele taget er deres oplevelse, at projekterne forsøger at undgår arkitekturafdelingen så meget som muligt.
Ærgerligt er det naturligvis, men arkitekterne kan selv gøre noget for at ændre situationen. Og de skal gøre noget, ingen andre gør det for dem. De har ikke brug for et kursus i arkitekturframeworks, men i stedet at udvikle deres kommunikation og personlige gennemslagskraft. Uden ændret adfærd skaber de ikke værdi og skal nok snart se sig om efter et nyt job.
Vil du som arkitekt gøre en positiv forskel, kommer du ikke uden om at bruge dig selv og bringe dig selv og din faglighed i spil i mødet mellem mennesker. Her er et par bud på hvordan du gør det.
Principper og arkitekturmodeller skal ikke sættes imellem dig og dine kollegaer – det skaber afstand. Svaret på en henvendelse (hvis du skulle være så heldig at nogen rent faktisk spørger dig i stedet for at undgå dig) må aldrig være ”læs principperne” eller ”her ligger arkitektur-manualen, der står det hele”. I stedet er principperne og modellerne dit udgangspunkt for en dialog med en kollega og en hjælp til at skabe et bedre projekt for ham eller hende.
Hold brugen af dine rammeværk i kommunikationen til et minimum. Det er dine værktøjer, ikke dine omgivelsers. Og, som en it-direktør for en større virksomhed fortalte mig, ”hvis din arkitekt kun fortæller dig om rammeværk, så find en anden …”
Et arkitektur-review, som et led i it-governance processen, skal heller ikke minde om mødet med den spanske inkvisition. Den værdiskabende arkitekt har sørget for at være nærværende og hjælpe projektet med at bestå reviewet i god tid inden mødet. I processen har han skubbet projektet i den retning, der er rimelig og nødvendig.
Til sidst, tilpas din stil. Der er ikke én rigtig måde at arbejde med arkitektur på. Skalaen mellem principfast stivstikker og laissez-faire pragmatiker er et kontinuum over måder at være arkitekt på, som den dygtige arkitekt behersker og anvender alt efter situationen. Vi har naturligvis alle vores personlige præferencer og vi skal også have en dagligdag hvor vi føler os hjemme. Hvis du ikke kan lide at stille dig op i større forsamlinger og formidle dine tanker, skal du bruge din tid på en anden måde. Hvis du er mere hjemme blandt it-folk end forretningsudviklere, så find en rolle, som tillader dig at fokuserer der. Men husk at bruge dig selv som det primære værktøj, ikke dine principper, metoder eller modeller.
En anden måde at sige det, er at nogle arkitekter tror de sidder i kommunens byggesagsbehandling.
En arkitekts opgave er ikke bare at checke om normer og regler er overholdt.
En arkitekts primære opgave er at finde en god og økonomisk løsning der opfylder opgaven.
Det har aldrig været lettere for en forretning, der ikke føler sig hjulpet, at stemme med fødderne og opbygge sin egen skygge-IT - langt fra principper og governance. Faktisk bliver det lettere for hver dag, så hvis hvad man kunne kalde "principarkitekterne" ikke selv kravler ned fra deres elfenbenstårne, styrter de sammen om ørerne på dem.
Som konsulent kommer man rundt mange steder og oplever ofte Arkitekturafdelingen som showstopper, og vil ofte gøre meget for at holde sig under radaren.
Eksempler:
For 11 år siden havde jeg en heftig diskussion med nogle dyrt betalte arkitekter som havde udregnet en arkitektur som skulle bruges til alle typer applikationer. De havde blandt andet i deres visdom udtænkt at al database adgang skulle foregå med Container Managed Persistence (EJB, 1.1). Jeg skulle hjælpe en kollega som havde behov for at fyre en lille triviel SQL mod databasen og foreslog kækt: det er så her vi bruger et fastlane-pattern. Svaret var NEJ, det må man aldrig gøre! Du kan pakke din query ind i et view og bygge en CMP udenpå...
Et andet sted jeg var for nylig. Arkitekturafdelingen var besat af en håndfuld forholdsvis tunge drenge, hvoraf jeg genkender flere navne. Problemet er bare at de holder fast i nogle arkitekturpricipper som var fine for 10 år siden, men som forlængst er gået af mode. Desuden en masse hjemmelavde frameworks og modeller som undstøtter disse principper. Begge ufravigelige krav til systemudvikling.
Senest et sted, hvor arkitekterne faktisk er ganske pragmatiske og "til at snakke med". De havde blot ansvar for at godkende revl og krat med det resultat at intet kom igennem, og at de af og til godkendte krat som aldrig burde være godkendt... Det er så blevet besluttet at arkitekturafdelingen ikke længere skal godkende. Til gengæld er der udleveret en liste med 30+ dokumenter man bør læse for at sikre sig man overholder principperne...
(Min) konklusion:
Arkitekturprincipper skal ikke være ufravigelige principper, men guidelines som bør følges. Arkitekter skal ikke være standhaftige politimænd, men pragmatiske inhouse-konsulenter, som med sparring og reviews i alle projektets faser indgår dialog med dem der reelt har ansvaret. De skal være klar til at acceptere en løsning, selvom den ikke er født i arkitekturafdelingen, hvis den passer til opgaven. Arkitekturafdelingen bør ikke udvikle hjemmelavde frameworks og tilsvarende - arkitekturen bør så vidt muligt understøttes af eksisterende (defacto-) standarder. Ellers risikerer de at sidde fast i en tidslomme og holde hånden over millioninvesteringer der burde være smidt ud for længe siden.
Og så en idé:
Ingen kan være ansat i arkitekturafdelingen i mere end 4 år ad gangen - så er det videre eller tilbage til udvikling. Det vil sikre at der kommer "nyt blod" og nye ideer til arkitekturafdelingen, og at der måske bliver ryddet ud i tåbelige beslutninger...
Ingen kan være ansat i arkitekturafdelingen i mere end 4 år ad gangen - så er det videre eller tilbage til udvikling
Jeg vil stille det endnu skarpere op: Ingen bør arbejde udelukkende som arkitekter. Hvis ikke arkitekterne får hænderne i koden, drømmer de umulige konstruktioner, som er til unødig hindring for udviklerne.
Hvis arkitekterne selv udvikler, mærker de eventuelle problemer på egen krop. Så forsvinder de værste misfostre helt af sig selv.
...altså her Løsningsarkitekter eller Infrastrukturarkitekter, ikke? ;)
Jeg er Arkitekt(tm). Jeg laver strategi for it og forretning. Men jeg kan ikke kode. Jeg har en god grundforståelse for, hvad der er muligt og umuligt, og hvad det koster af blod, sved og tårer, hvis jeg f.eks. siger "open source strategi".
Men jeg kan ikke dybden i det, så skal jeg lave noget der retter sig specifikt mod udvikling, tager jeg eksperter på det område med på råd.
Pointen er, at en "arkitekt" er andet og mere end en løsningsarkitekt. Det er de færreste, der rummer hele spektret fra strategi til kode/hardware etc. - det er it/forretningsverdenen sgu for kompleks til, og det er det, man har et projektteam til :)
Mvh En-arkitekt-der-er-lidt-træt-af-at-få-sin-profession-præsenteret-for-énstrenget :)
Fuldkommen enig. Og det minder mig for øvrigt om Anders Hejlsberg som en gang sagde "When you don't code, you tend to become one of those architects who thinks everything is possible"
Peter skrev nok primært om enterprise-arkitektur - jeg er helt enig med Thomas.
Hvis principper og standarder ikke kan retfærdiggøres i forhold til virksomhedens værdiskabelse (eller overholdelse af lovgivning) så har de ingen berettigelse og vil blive ignoreret. Det kan godt være et problem i virksomheder, hvor enterprise-arkitektur er opstået som en metamorfose af tidligere tiders metodeafdeling.
Udfordringen for enterprise-arkitekten er at projekter, som ændrer på systemlandskabet, skal arbejde efter nogle fælles spilleregler, så der ikke er uklarhed om den basale begrebsmodel, ejerskab af data, supportansvar, etc. etc. For det enkelte projekt kan det til tider se ud som unødvendigt bureaukrati, men for at det samlede landskab som helhed fortsat kan tilpasses og udvikles, er det nødvendigt at de fælles spilleregler overholdes.
Ud over at Peter har helt ret i at enterprise-arkitektur leveres langt mere effektivt som en rådgivningsindsats end gennem publikation af dokumenter, så er det i min erfaring også vigtigt at forankre principper og standarder i IT-strategier, der baserer sig på forretningens værdikæde-model og de egenskaber og processer, der realiserer den.
Rigtigt at jeg primært skrev om EA. Men det gælder også (måske endda mere) ved it-arkitektur i forskellige former for her er både arkitekt-funktionen og governance mere almindelig, men ikke nødvendigvis mere populær.
Helt rigtigt at arkitekten ofte har den utaknemmelige rolle at være garant for, at udviklingen på det lange sigt går i den rigtige retning. Han/hun er dermed nærmest per definition til gene for projekter med korte deadline. Så på en vis måde er konflikten naturlig.
Men ser vi også for ofte at arkitekterne tager det langsigtede perspektiv mere seriøst end den forretning, de skal servicere. Altså at arkitekterne ender med at arbejde med arkitektur for arkitekturens egen skyld. Arkitekturmodeller og -principper kan være med at forstærke den tendens.
Derfor skal arkitekten bringe sig selv i spil i en frugtbar dialog, ikke blot for at ændre projekternes brug af arkitektur, men i lige så høj grad for løbende at tilpasse arkitekturen til virkeligheden.
Helt enig.
Arkitektur er ikke kun løsningsarkitektur, MEN hvis man laver arkitektur uden at tage hensyn til den forretning, der skal implementere inden for rammerne, så har man fejlet.
Der er intet i arkitektur rammeværkerne, der retfærdiggør at man er verdensfjern. Det er et "simpelt" spørgsmål om at være en god/dårlig arkitekt, i mine øjne ;)
det er en af de mest interessante debatter i vores fag - specielt hen over øl, for der er mange religiøse holdninger til emnet. Jeg møder mange EA die hard arkitekter som er som Peter beskriver. Jeg møder mange som mener, at de laver EA arkitektur samtidig med, at de sidder i en IT afdeling og reelt blot forsøger at aligne forretningens ønsker med IT mål i et design. Jeg møder mange, som mener at de optimerer 'enterprisen', således at IT og forretningen smelter sammen om at nå et strategisk mål for enterprisen. Jeg møder mange arkitekter som er frustreret og som reelt bliver holdt ude af de rigtige beslutninger. De samme mennesker bliver også overrasket over, hvor meget forretningen kan reelt selv og hvor lidt de har behov for en arkitekt. Det vil være en øjenåbner for de fleste, hvis de tog en snak med en person fra Group Product Development eller lignende afdelinger (har kun være i større internationale virksomheder, så jeg kender ikke hvad man vil kalde dem andre steder) og se hvor lidt en arkitekt har at gøre i deres verden. Jeg vil ønske, at de fleste arkitekter kikkede med kritiske briller på sig selv og spurgte - hvad er ens rolle og giver man egentlig værdi i forhold til den rolle. Der er mange ultra-skarpe folk omkring, dem har jeg også mødt mange af, men kik lige på dig selv. Kik på din rolle i organisationen og hvorledes den bruger dig, er du så virkelig enterprise arkitekt? eller er du blot IT arkitekt som forsøger at implementere forretningens ønsker med din IT chefs ønsker som f.eks. lav omkostning niveau for operations? Ignorer at du kender TOGAF, Zachman og du synes, bare at det er det rigtige... Hvor meget bliver du egentligt brugt i optimeringen af organisationen og hvad den arbejder efter for at implementere strategien fastlagt af top-ledelsen? Det er den ene vinkel. Den anden er... Udviklere føler sig som dem som leverer hvad forretningen (implicit kunden) ønsker. Det er dem som får systemerne til at virke, dem som koder om natten hvis det behøves og som føler, at de gjorde forskellen for kunden. Så, at de ser på nogen som ikke koder og dermed blot tilføjer (for udviklere) administrativt bøvl - hvad end det er projektledere eller EA - så reagerer man negativt. I Miracle (har jeg hørt) det udtryk, at arkitekter er dem som ikke kan kode. Det passer sikkert med deres operation model - det vil jeg ikke blande mig i. Løsningsarkitekter er så tætte på løsningen at de får lidt street credit af de fleste udviklere. Specielt fordi de har svar på problematikker som f.eks. operationelle aspekter i løsningen eller hvorledes man kan lave styring af revisionens krav igennem systemer. Så mange EA folk får kritik fra den gruppe - fordi man har forskellig fokus simpelhen.
EA er i mine øjne et umodent område. Det siger jeg med mange års erfaring på EA, LA og udvikler roller i forskellige internationale virksomheder. Der er mange som falder i TOGAF fælden - når vi følger det, så kan vi komme langt. Det er såvidt rigtig, men det kræver at du har skabt meget tillid i de forskellige områder af din virksomhed - forretning som IT. Du kommer ingen steder, hvis produkt udvikling ikke ønsker at have en EA gut tæt på dem. Ingen steder. Du skal levere løsningen for at skabe tillid - hvis en IT chef ikke leverer sikker drift som en løsning, så får han ikke tilliden til at få lov til at snakke om strategi. Det gælder også for dig som arkitekt. Det kræver en masse løsningsarkitektur (løsninger skaber tillid) og en masse forretningsviden. Hvis jeg fik lov vil jeg give mine EA ressourcer en MBA og 2-5 års erfaring i forretningen som alm. forretningsmand før jeg ser dem igen. Jeg hørte en gang, at Disney ser det som en nemmere opgave at uddanne tegnere i IT systemer end at uddanne IT folk til at tegne (sjovt nok fra deres EA chef), jeg er efterhånden kommet til det samme med forretningsfolk -> EA end IT folk -> EA
