anders lisdorf bloghoved

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

Jeg blev for nyligt spurgt, om det skulle være en arkitekts primære opgave at kode på quora - hvilket jeg bruger alt for meget tid på (men hvem kan ikke undgå at blive fanget af vigtige spørgsmål som: “Why aren’t trucks designed aerodynamically?” , “What happens if I drop an ant from the top of a skyscraper?”, “If the United States disappeared how would the world be affected?”)

Det er et interessant spørgsmål, for normalt ville man nok ikke spørge, om en bygningsarkitekt skulle tage det som sin primære opgave at mure eller lave elinstallationer. Jeg synes, at det umiddelbart er klart, at en arkitekt ikke skal tage det som sin primære opgave at kode. Hvis han gør det, er han jo udvikler, og så er der ingen grund til at kalde ham arkitekt.

Min holdning, som jeg lod skinne igennem i svaret , er, at man som arkitekt har brug for nogle andre kompetencer, end man har brug for som udvikler.

Nu indrømmer jeg, at jeg ikke har kodet siden 1985, men til gengæld har jeg været arkitekt i en del år efterhånden. Hvis man primært har arbejdet med at udvikle IT-løsninger, er der muligvis nogle ting, som man ikke har lagt mærke til, at arkitekten gør. Derfor tænkte jeg, at det måske var interessant at vise, hvad det er, en arkitekt egentlig gør. Lad os derfor prøve at se, hvad en arkitekt laver i løbet af en almindelig dag. Det følgende er inspireret af virkeligheden, men ethvert sammenfald med virkelige begivenheder og personer er tilfældigt.

A day in the life

Kl. 7: står op, vækker børn, går med hunden, får børnene ud af huset…overvejer, om man skal cykle…finder bilnøgler, af sted.

Kl. 8-9: Finder kaffemaskinen som det første. Logger på computeren og krydser fingre for, at jeg ikke skal skifte password eller have installeret nyt software. Kigger på kalenderen for at se, hvilke møder der er i dag. Ca. 80% er booket. Læser og sletter emails. Leder efter regneark med projekter, der skal reviewes.

Kl. 9.00: Første møde med projekt X. som vil bygge en app, der skal bruge kundeinformationer. De spørger, hvordan de skal gøre det

Kl. 10.00: Læser firmaets intranetsider og leder igen efter regneark.

Kl. 10.15: Prøver at finde ud af, hvad API management systemer kan bruges til, og om det kan anbefales at investere i det. CIO er blevet kontaktet af en sælger og synes, det lyder smart.

Kl.10.30: Næste møde er om opdatering af IT-strategien. Sidder med ledelsen og snakker om, hvilke tiltag der skal fokuseres på. Skriver referat.

Kl.11.30: Frokost

Kl.11.43: Kigger efter regneark igen, startede det mon med “reviewJuly” eller “JulyReviews”. Finder intet. Begynder på referat af IT-strategimøde

Kl. 12.00: Møde med projekt, som undersøger muligheder for at få data fra produktdatabasen.

Kl. 12.30: Møde med forretning om projektplanlægning.

Kl. 13.30: Læser guideline til databehandling af kundedata (igen)

Kl. 13.41: Bliver ringet op af frustreret projektleder, som ikke kan forstå, hvorfor projekt Y ikke gør som aftalt.

Kl. 13.45: Prøver at få fat på i nogen fra projekt Y, men de er på team building event (hvor de skal klæde sig ud som superhelte for at forstå, hvordan roller påvirker den måde, vi agerer på). Fortsætter med referat af IT-strategimøde

Kl. 14.00: Indtaster information i EA-system om to nye systemer, som er blevet opdaget i produktion. Finder ud af, at der stadig er spørgsmål. Prøver at efterspore, hvem der mon kan vide noget om det. Går rundt i bygningen og snakker med folk om det.

Kl. 14.30: Skriver videre på arkitekturvision for komponent til arkivering af data. Tjekker databehandlingsstrategien, undersøger, om der er specielle tilfælde eller lovgivninger. Det er der. Regnskabsdata kan have længere periode, hvor det skal opbevares.

Kl. 14.32: Overvejer, om man skulle købe en kage i kantinen… Betaler for kagen i kantinen og går tilbage til min plads.

Kl. 14.37: Hvad var jeg i gang med?

Kl. 14.42: Kommer i tanke om, at projekt Z har en løsning, som skal reviewes. Jeg finder ud af, at de bruger en tabel i vores Data Warehouse til at finde information, der bruges i input til senere skridt. Egentligt fint nok, men der findes ikke noget test-og demomiljø til vores Data Warehouse. Iøvrigt tjekker jeg dets SLA og finder ud, at der er servicevinduer hver nat, men projekt Z’s løsning er et online 24/7 system. Skriver notaterne ind i reviewsystemet, så det er klar til den officielle gate review på torsdag.

Kl. 15.00: Møde med dynamisk leder, som har en ide om, at noget skal skrives. Ikke klart, hvad det er, eller hvorfor. Leder skal hurtigt videre til næste møde, men vil gerne have det inden fredag. Tilbage til skrivebordet og gætte på, hvad det kunne være, han tænkte på, eller hvorfor han ville have noget. Starter på dokumentet.

Kl. 15.32: Projektleder kommer forbi og kalder mig arrigt for arkitekturpolitiet.

Kl. 15.40: Starter på dokumentation af systemanalyse, som skal bruges til foranalyse for projekt Q.

Kl. 15.42: Leder ringer og spørger, om jeg ikke kan lave fem slides om vores integrationsprincipper. De eksisterende slides ser ikke så pæne ud, og så mangler der vist en boks eller en pil, og man skal også gerne kunne se, vi har styr på det, men samtidig mangler penge til at få “helt” styr på det.

Kl. 16.00: Sent ekstramøde, hvor afdeling for kundeservice og salgsafdelingen skal diskutere, hvem der er ansvarlig for autorisation i CRM systemet.

Hello world

Selv hvis jeg kunne kode på et tilstrækkeligt niveau ville jeg simpelthen ikke vide, hvornår jeg skulle få tid til det. En arkitekt bliver hele tiden bombarderet med forskellige forespørgsler, problemer og dokumenter, som skal læses og skrives.

En stor del af en arkitekts arbejde er skjult for udviklere og kan derfor måske godt se trivielt eller ligegyldigt ud. Det handler om at afholde møder med ikke-tekniske personer og formidle tekniske informationer samt at forstå, hvad deres interesser og krav er. Disse møder kan nogle gange være med besværlige personer, men det er helt sikker med mange forskellige personer. Det kan godt være, at man synes, det lyder ukompliceret, men jeg indrømmer gerne, at det tog mig flere år at lære, hvordan jeg tackler mange forskellige persontyper.

Samtidig skal man sætte sig ind i en del ikke-teknisk information. Det kan være forretningsmæssigt omkring den industri, man er i, men også lovgivningsmæssigt eller anden form for regulatorisk dokumentation. I mange brancher er det nemlig ikke nok at kigge på, hvad brugerne gerne vil have i de specificerede user stories, hvis man skal designe en løsning.

Generelt er der brug for en åbenhed overfor verden i arbejdet som arkitekt. Ofte handler det om at få mange forskellige informationer til at falde på plads. Det handler om at trække på mange forskellige kilder og personer.

Hvorfor arkitekter ikke skal kode

Til sidst vil jeg gerne endnu en gang gøre det klart, at det ikke handler om, at programmører ikke kan blive gode arkitekter, men at det er nogle helt andre kompetencer, som man skal bruge for at være effektiv som arkitekt. For det første vil man ikke have tid til at kode, hvis man arbejder i bare en lille smule kompliceret virksomhed, og for det andet vil man ikke have tid til at vedligeholde sine kodeevner, hvis man skal følge med i de andre kompetenceområder, som man skal udvikle som arkitekt.

Relateret indhold

Kommentarer (24)
Niklas Larsen

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 ;-)

Steffen Schumacher

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?

Denny Christensen

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å.

Michael Zedeler

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) :-)

Palle Simonsen

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 :)

Lars Gregersen

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.

Jonas Høgh

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å.

Jens Jensen

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.

Jens Jensen

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.

Allan Pedersen

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.

Allan Pedersen

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.

Jørgen Elgaard Larsen

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.

Peter Hansen

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.

Palle Simonsen

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.

Peter Hansen

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.

Min Wu

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.

Jesper Frimann

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

Jn Madsen

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.

Normann Aa. Nielsen

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.

Palle Simonsen

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 :)

Martin Jünckow

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.

Log ind eller Opret konto for at kommentere