Skal en arkitekt kode? (Skal en murer male?)

Fornuftigt og morsomt indlæg. Det er tit sjovt at sammenligne software med byggeprojekter, da mange af tingene godt kan sammenlignes. Hos os tvivler jeg også stærkt på at nogle af arkitekterne koder. Højest tilpasser de lidt konfigurationsfiler, eller kigger på nogle fejlrapporter.

Og ja, som helt nyuddannet softwareudvikler (kun været i arbejde siden 1. september) kan det være svært at gennemskue hvad det egentligt er arkitekterne laver. Det er jo os som skriver koden! Men jeg er alligevel sikker på at en god arkitekt kan spare os for at skrive et par tusinde linjer unødig kode ;-)

Hej, Jeg har sikkert misforstået hvad en IT arkitekt laver, men i min forståelse af hvad arkitekter bør beskæftige sig med, så er det bl.a prototyping af nye metoder/teknologier - men også bidrage med leverancer på de områder der ikke er trivielle. Analogien til arkitekt-mureren mener jeg ikke holder, da murernes arbejde overvejende er gentagelsespræget, og det er udviklerens i meget mindre grad. Derudover, risikerer arkitekter der ikke løbende har praktisk berøring med udviklernes virkelig, at træffe beslutninger der ikke i praksis er de rigtige, eller som udviklerne ikke kan se pointen i - fordi gevinsten ikke kan præsenteres fra udviklerens perspektiv. Jeg mener snarere at for megen tid i Excel er problematisk - er det ikke mere opgaver for projektlederen?

Bloggen viser også hvorfor mange funktioner, herunder arkitekter i forskellige roller, kan have så pokkers svært ved at bevise deres værdi. Og i mange tilfælde heller ikke direkte giver værdi svarende til deres løn men er uundværlige for at hele maskineriet kører.

Evnen til at være med i de daglige opgaver og projekter samtidig med lidt visionære tanker og strategi arbejde og... er undertiden en udfordring.

En god arkitekt kan forhindre projekterne i rework, en god teknisk arkitekt kan skabe god grobund for eks. udviklernes dagligdag, etc. Fælles er stadig at det nemt bliver usynligt at arkitekten bidrager. En forretningsarkitekt fylder eksempelvis godt op i backloggen lang tid inden en udvikler kommer på.

Det er interessant at se et indlæg på Version2 hvor jeg for en gang skyld er meget uenig :-)

Jeg kan godt se din pointe, Anders, så vidt det gælder at man som arkitekt ikke nødvendigvis har tid til også at blive en god udvikler, men så synes jeg at kæden hopper af.

Problemet er, at uden relativt god forståelse for systemudvikling - også i praksis og også ny teknologier - kan en ariktekt ikke gøre meget andet, end være i vejen for udviklerne. Hun (eller han) vil designe systemer baseret på en forældet eller manglende forståelse af hvordan sådan nogle bør fungere.

Derfor ser jeg arkitektur og systemudvikling som to vekselvirkende arbejdsområder. Alle arkitekter skal i perioder kode for at blive opdaterede - ellers kan de ikke bidrage.

Så min opfordring til dig og alle de andre som arbejder meget med arkitektur: meld dig i flokken blandt udviklerne for en tid - det gør dig til en rigtig god arkitekt.

Så ja - alle der arbejder med systemudvikling skal kode (nu og da) :-)

I min optik er der intet i vejen med, at en bygningsarkitekt vedligeholder det håndværk som vedkommende blev uddannet i og personlig ville jeg blive mere tryk ved min nye +1 MDKK tilbygning der var projekteret af en arkitekt der havde den praktiske erfaring end hvis det var projekteret af en arkitekt , der helt havde tabt følingen med det praktiske. Selvfølgelig forventer jeg, at der anvendes specialister på VVS, EL, m.m. da arkitekten naturligvis kender og respekterer sine begrænsninger.

Analogien til IT er vel snarere det der tidligere hed EFG hvor man snuste til alle fag men specialiserede sig i et. De fleste af os har en grunduddannelse i IT som datamatiker, datalog, ingeniør osv, men tilfældigheder og interesser har gjort, at de fleste også har specialiseret sig i bestemte værktøjer, drift, udvikling, design, arkitektur m.m.

Jeg arbejder primært som Enterprise arkitekt, men jeg kan sagtens konfigurerer en server og har holdt mine programmerings evner ved lige - bl.a. fordi jeg ikke kunne lade være :) Det er ikke det samme som at jeg ville bryde mig om at udvikle et modul i en løsning, eller at jeg prøver at kloge mig på områder, hvor jeg ikke længere har min primære arbejdstid, men det er min måde at stå på moder jord i bare fødder :)

Nu har jeg muligvis fuldstændig misforstået hvad en softwarearkitekt skal lave, men så vidt jeg kan se, er det eneste arkitektur jeg kan se på dagens program fra 14:30 til 14:32 og selv om nogle kan skrive hurtigere end andre er det vel begrænset hvor meget arkitektur, der kan komme ud af de 2 minutters arbejde.

Projektledelse er selvfølgelig vigtigt, men det synes jeg ikke er det samme som arkitektur. I min verden er softwarearkitekter meget tættere på de folk der koder og har selv fingrene i en server, applikation eller prototypekode en gang imellem.

There are two kinds of architects - those with their hands in the code, and those with their head up their asses

Spøg til side, problemet er at arkitekttitlen er så bred, at den stort set er blevet meningsløs. Du kunne også spørge, om en forsker skal gå med gummihandsker, det får du heller ikke et entydigt svar på.

Som arkitekt kan jeg overhovedet ikke nikke genkendende til den person som skildres i indlægget.

I agile setups vil en arkitekt ikke kunne sidde og fedte med at læse en rapport og divs. referater. Jeg er enig i at arkitekten ikke har meget tid til at kode, men han er noget tættere på koden end den overflødige person som er beskrevet i artiklen.

Når det brænder på, sætter han sig til tasterne og opretter en tabel eller koder et program, på linje med alle andre i teamet. Han ved hvordan, fordi han var frontrunner for projektet og satte sig ind i alle værktøjer og arkitektursstack inden projektet gik i gang.

Han skal kende fordele og ulemper ved programmeringsværktøjer og teknikker, for ellers kan han jo slet ikke sikre en fornuftig arkitektur. Gør han ikke det, vil alle hans anbefalinger på standarder og lign. blot være ævl. Vi har nok alle prøvet at snakke med en sådan arkitekt som fortalte at standarden skulle være sådan og sådan, fordi det på papiret ser godt ud, eller fordi han havde hørt det på et eller andet fancy salgsshow.

Arkitektens fornemste rolle er at kende virkeligheden, og IMHO synes jeg at eksemplet i artiklen lyder som en overflødig person som mest flytter lidt papirbunker rundt.

Det samme gælder bygningsarkitekter. Nok skal han ikke selv mure bygningen op, men han skal vide hvad en mursten er, og hvad den kan bruges til. Ellers ender det bare med at han designer en bygning af sammenklisterede ispinde, med et lag maling på.

Det er den slags vi kalder kunst, og det har intet med solidt håndværk at gøre.

Ja for pokker da - men hold jer til PowerPoint :o)

Der er jo flere niveauer af arkitektur. En enterprisearkitekt vil næppe beskæftige sig med kode. Derimod vil det nok være mere nærliggende for en application architect at gøre det - og sikkert også mere relevant.

Og så drillespørgsmålet, er der en arkitekt der kan fortælle mig hvad forskellen er på en arkitekt og en projektleder, udover alderen ?

Og så drillespørgsmålet, er der en arkitekt der kan fortælle mig hvad forskellen er på en arkitekt og en projektleder, udover alderen ?

Alt, jeg kan ikke finde en eneste ting som de to har til fælles. Måske bortset fra alderen :-)

Sat på spidsen: Projektlederen kan lede et projekt uden overhovedet at ane hvad produktet egentlig er. Arkitekten ved nøjagtigt hvad produktet er, da det er hans job at vide det, og svare på alverdens spidsfindige spørgsmål om det.

Hvis projektlederen var den eneste ansatte, så blev det færdigt til tiden, men produktet var forkert. Hvis arkitekten var den eneste ansatte, så blev produktet fantastisk, bortset fra at det aldrig blev færdigt.

Der er tydeligvis mange af jer herinde der slet ikke ved hvad arkitekterne lave. Og det er ikke så mærkeligt.

Langt de fleste af jer der snakker om arkitekter skal kunne kode, i snakker om system arkitekter. Og i den forbindelse er jeg helt enig.

men set i et international perspektiv, "prøv at Google togaf". så findes der følgende arkitekter. Enterprise arkitekt, teknologi arkitekt, forretnings arkitekt, applikations arkitekt.

Ingen af dem koder.. ingen af dem. de samler tråde.

Hvad vil ledelsen med et nyt system? Hvordan kan vi opnå det med vores nuværende hardware? Integrerer det med vores nuværende løsninger? Hvad kan vi lave selv, hvad skal laves ude i byen.

En arkitekt i den internationale forstand har intet med programmering at gøre, og sidder faktisk sjældent i IT afdelingen.

Men den mere danske anvendte 'System Arkitekt' ja, det er en der sidder og programmere.

Og forskellen på en projektleder og en IT arkitekt(til dem der spurgte) Er at en projektleder træffer beslutninger, også uden at have nogen som helst faglige kompetencer. en It arkitekt rådgiver projektlederen, men beslutter ikke.

kommer an på hvilken arkitekt vi snakker.

Enterprise arkitekt? .. System Arkitekt?

Du koder programmer, men arkitekten er ham der sørger for du faktisk koder det firmaet skal bruge, og ikke noget de bliver nød til at skifte ud igen om 1 år.

Det er dig der bygger huset, men grunden til du bygger det 3 etager højt og ikke 4, og du i øvrigt bruger røde mursten. Det er fordi arkitekten har fulgt reglerne beskrevet i lokalplanen ;). Som du ikke har læst.

Hvis jeg ser på Anders' arbejdsdag, virker det som om han er rendyrket projektleder. Så han skal naturligvis ikke kode. Men han burde også holde sig fra arkitektur.

Som arkitekt bør man altid være parat til at spise sin egen hundemad. Det design, der ser simpelt ud på papiret, kan være umuligt at arbejde med i praksis. Hvis man holder sig fra koden, får man en tendens til at affeje fejldesign med en idé om at udviklerne er uduelige og piver over ingenting. Derimod er det god læring, når man selv er med til at rage kastanjerne ud af ilden. Så er det tilbage til tegnebrættet og rette på designet.

Den type "arkitekt", som Anders beskriver, har alt for travlt til at kode - og i virkeligheden også for travlt til at tænke over arkitekturen. Så er der en stor risiko for, at man ender med næsen solidt plantet i skyerne og kun går i vejen for udviklerne.

Hvis det så var sådan, at der kom brilliante nye idéer ud af det, ville det måske være det værd. Men hvornår skulle han få tid til at få idéer med alle de møder og papirnusseri?

Hans job er sikkert vigtigt, men lad for guds skyld være med at kalde ham for arkitekt.

Inden vi diskutere hvorvidt skribenten giver et retvisende billede af, en it-arkitekts hverdag - så skal vi lære at skelne mellem fx EA arkitekter og systemarkitekter. Hvis vi skal forsætte analogien fra byggeriets forunderlige verden, så ser en EA arkitekt på byen og systemarkitekter på bygningen. Præcis som tilfældet er ved en by- og landskabsarkitekt og en traditionel bygningsarkitekt. De skal snakke sammen og forstå hinanden, men deres roller er forskellige. I min verden skal en EA arkitekt ikke kode, han skal opstille retningslinjer som er langt bredere og i tråd med forretningens overordnede strategi og mål. En systemarkitekt har sikkert stor fordel i at kunne kode. Begge er i min optik it-arkitekter, men begrebet skaber mere forvirring end klarhed.

I min verden skal en EA arkitekt ikke kode, han skal opstille retningslinjer som er langt bredere og i tråd med forretningens overordnede strategi og mål

Hvis forretningen er nødt til at bevæge sig hurtigt med f.eks. massivt IT understøttede processer / produkter er det ikke længere nok med overordnede og langsigtede planer - så skal der handling og løsninger på bordet nu! Hvis EA arkitekten så ikke kan manøvrere i en situation, hvor IT løsninger og forretning blandes og går hånd i hånd, hvor løsningskomponenter såsom Microservices, Containers, Cloud Services, DevOps osv. osv kastes på bordet får vedkommende hurtig et problem.

På samme måde skal en byplanlægger kunne opererer med letbaner, metroer. cykelstier etc. og skal kunne klare pludseligt opståede behov for regnvandssikring m.m.

I begge tilfælde skal man vide hvad man har med at gøre, eller meget hurtigt kunne skaffe sig nok viden til at være en handlekraftig og reel partner for forretningen. Så kan indgangen i og for sig være hvad som helst - herunder evnen til at omgive sig med de rigtige personer. Det er bare en stor fordel, hvis arkitekten selv har en faglig ballast.

Det mener jeg stadig ikke er EA arkitektens rolle - hvis det er det behov man har i virksomheden, så skal man ikke ansætte en EA arkitekt (i teorien naturligvis, verden er sjældent sort/hvid). De markedstendenser som kræver hurtig tilpasning, de skal klares af små teams med relativt stor teknisk forståelse og stor autonomi - her passer en EA arkitekt slet ikke ind. Her kan der være tale om en software arkitekt som har kodekompetence, men en EA arkitekt vil være fuldstændig fejlplaceret og nærmere et tegn på dårlig ledelse. Hvis man så alligevel ender i den situation, ja så er det klart at man må krydse fingre for at vedkommende kan kode.

Desværre er alt for mange arkitekt blive efterhånd powerpoint /excel arkitekter, sidder i alt for mange møder diskutere nogen fiktiv arkitektur, og bevæger sig længere og længere væk fra teknisk felter, og mangler nogen teknisk forstårelse for hvad god løsning er. Nogen har engang kode en linie i 5+ år, og når udvikler hører hvad de komme med, så har løsning ikke en gang på jord eller rammer helt skævt. Hvis man vil være en god arkitekt, så skal man have mere dybgående forståelse for teknologi, fordel og ulemper for hver løsning, hvad der kan lade sig gøre og hvad er varm luft. Det bør ikke være arkitekts ansvar at sidde i møde hver dag og tager kunderkontakt, og det bør projekt leder og sales person tage sig af. Hvis man sidder i virksomheder, hvor hverdag består af 90% møder og kunderkontakt, så er man per definition ikke arkitekt. Desværre sidder for mange "arkitekt" i deres lyserød sky og tegner deres regnbuer, mens der forgår nogen helt anden ned på jorden, når udvikler skal lave en velfungerende løsning. Ved at kode og find løsning på konkret problemer, og interagere med udvikler, andre teknisk kyndig, lærer og sætter sig ind på teknologi, gøre man til en bedre arkitekt. Det betyder jo ikke ens med at man skal kode 100% af tid.

Og forskellen på en projektleder og en IT arkitekt(til dem der spurgte) Er at en projektleder træffer beslutninger, også uden at have nogen som helst faglige kompetencer. en It arkitekt rådgiver projektlederen, men beslutter ikke.

Det er jeg så absolut ikke enig i. Arkitektur er jo netop valg og fravalg, og det er en af arkitektens primære funktioner netop at vælge og dokumentere, hvad der blev valgt og hvorfor. Og også hvad der ikke blev valgt.

Der er en hel del arkitekt frameworks, og kært barn har mange navne, så der findes et hav af arkitekt betegnelser.

Min helt egen personlige holdning, er at man som arkitekt skal vide noget om det man beskæftiger sig med. Og jeg mener at grænserne mellem de forskellige rolle er ikke så skarpe. Som arkitekt skal du helst have noget projektleder erfaring, du må meget gerne vide hvad en kodestok er.. og og og..

Den IMHO nok sværeste arkitekt rolle er nok Entreprise Arkitekten, da sådan en helst skal have viden om alle (Forretning, Data, Teknologi og Applikation) områderne. Det er også derfor at sådan noget som en Junior EA ikke eksisterer :)

// Jesper

Det er vel et spørgsmål om titler og ord,- som begge er et spørgsmål om tolkning.

For mig er en projektleder en, der ikke nødvendigvis har den dybere tekniske viden,- men som koordinerer mange involverede og holder godt øje med at tingene leveres til aftalt tidspunkt.

En arkitekt er en der har teknisk forståelse. Han kan på et eller andet niveau udvælge de rigtige produkter, eller samarbejde med andre teknisk kyndige, således at det endelige produkt lever op til forventningerne.

Man fokuserer meget på kodning i denne tråd,- men det emne er jo kun en af mange teknologier der er i spil i IT-verdenen. Jeg har endnu til gode at møde en, der kan det hele. Dem der påstår de kan det meste, er som regel dem der kan mindst.

Jeg opfatter arkitekten i IT-verdenen på samme måde som en arkitekt i bygnings-verdenen. Dvs., man kan blive undervist i alle arkitektfagets hemmeligheder - og det kan man lave en hel del udmærkede ting med. Men uden en praktisk forståelse er der nuancer, man mister.

I den virkelige verden er det værdifuldt at vide, at man ikke kan anvende mursten på samme måde som træ, og at fliser kan knække. Man finder ud af, at der er ting som ikke kan lade sig gøre med de muligheder, man har til rådighed.

Det er så ikke det samme som at sige, at så må en arkitekt ikke forlange det umulige alligevel!

Selvfølgelig kan man insistere på, at en løsning skal foregå på en bestemt måde, uanset om det er "best practice" eller en del af GoF. Koderne vil sikkert brokke sig (de er jo fagfolk), og det er muligt nye ting skal opfindes - men i sidste ende er det ikke koderne, der skal bestemme. Til gengæld skal de advare om "farlige" / besværlige løsninger, og arkitekten skal sammen med koderne finde de nødvendige workarounds. Her er det naturligvis en fordel, hvis arkitekten kender faget.

Jeg har arbejdet i IT-faget i 35+ år, det meste af tiden som udvikler - og en hel del også som arkitekt på forskelligt niveau (dog ikke EA). I den seneste tid har jeg ikke kodet, men jeg har siddet i som part i pair-programmering, og jeg har skrevet pseudokode. Først og sidst har jeg skulle være bindeledet mellem "bygherren" med 117 møder - og "håndværkeren". Det er der, jeg ser min rolle som arkitekt.

men en EA arkitekt vil være fuldstændig fejlplaceret

Der er vi ikke enige. Hvis virksomheden eller en del af den er nødt til at bevæge sig meget hurtigt for at bevare eller erobre markedsandele er det EA's opgave at kunne understøtte dette med overblik, råd og beslutningskraft, hvis det er det der kræves.

Jeg tror ikke jeg skal forstå din argumentation som om at EA kun er relevant i den traditionelle / langsommere del af en bi-modal model :)

Nu er det jo rigtig meget vandfald det der beskrives her og bevares, jeg arbejder selv som konsulent i enterprise virksomheder og ved hvor svært det er at ændre på kulturen.

Men der er en grund til at Scrum ikke anerkender Arkitektrollen, men betragter arkitektur som en naturlig del af udviklernes ansvarsområde og som grundlæggende set bør udvikles lige så agilt som produktet selv. Dermed ikke sagt at det ikke er tilladt at tænke lidt længere ud i fremtiden når man sidder med noget, men det handler ikke om at lave en 6 måneder forundersøgelse hvor man får det hele på plads inden der skrives en linie kode.

I de store virksomheder vil der stadig være et behov for Enterprise Arkitekter, som nok oftest vil stå udenfor Scrum teamet, men assistere med viden om generelle retningslinjer for forretningens systemer og måder at flytte data rundt på, krav til dataene, sikkerhed osv. - de er reelt repræsentanter for forretningen.

Men Application Architecture rollen er reelt døende efterhånden som vi overgår mere og mere til agil udvikling, det er færdigheder som alle udviklere bør forsøge at tilegne sig og det er svært at være på toppen af Application Architecture hvis det er 10 år siden man sidst har skrevet en stump kode, dertil går udviklingen alt for hurtigt og derfor er det nød til at være en kernekompetence blandt udviklerne selv.