Kender du it-arkitekten der har problemer med at komme ned i projekterne og forklare udviklerne hvad de skal gøre' En simpel sproganalyse afslører, at han nærmest ser sig som Udvalgt der beærer de indfødte med sin tilstedeværelse for at gennemtvinge at de efterlever de ti Arkitektur-Bud. Han er ikke et dårligt menneske ' blot et menneske med en overbevisning og tilhørende en kategori af personer, der er fagligt stærk og ser sin viden om verdens indretning som objektiv korrekt.
Han oplever en modstand mod sin mission, som for ham er uforklarlig og irrationel. Derfor ender han med at klynke "hvorfor er der dog ingen der lytter og bare gør hvad jeg siger?". Det er fordi han ikke leverer varen!
Klaus Kvorning Hansen, Senior Vice President og Director of Strategy and Development i PenSam samt formand for Dansk-IT, brillerede ved EA|09 i sidste måned med et provokerende og tankevækkende indlæg om forskellige opfattelser af hvad it er. Hans oversigtsslide ser ca. sådan ud:
De tre grundlæggende opfattelser af it er, at det er
It-arkitekter, der typisk har en akademisk uddannelse, har ofte den selvopfattelse, at de bedriver en objektiv videnskab med målet at skabe den bedst mulige løsning til et givet problem. Sådan en har jeg selv været og jeg har fortsat stor respekt for deres arbejde. De bedste af dem har ud over en enorm viden også en nysgerrighed og en vis ydmyghed over for forretningen og en bevidsthed om hvor de ikke er stærke.
Konflikten kommer, hvis it-arkitektens omgivelser blot ønsker et billigt fix og i forvejen synes at it er for dyrt. Eller hvis arkitektens rolle bliver set som at levere hurtige og kreative nye løsninger til at hjælpe med at tjene penge mens it-arkitekten efterlyser mere viden og tid før han kan rådgive om den bedste løsning. Ud over til belysning af selvopfattelsen, kan de tre kategorier nemlig også bruges til at beskrive omgivelsernes forventninger.
Hvis vi zoomer ud, kan de tre kategorier i følge Kvorning også bruges til at karakterisere forretningens opfattelse af it's væsentligste arbejdsområde. Det nytter for eksempel ikke at it-afdelingen vil være innovativ og værdiskabende hvis den bliver set som et (alt, alt for dyrt) omkostningscenter.
Hvad gør man så, som individ eller chef for en afdeling, for at ændre på tingene i den rigtige retning? Det første trin er at blive klar over forskellene mellem sin selvopfattelse kontra den opfattelse, som omgivelserne har af en.
Kvorning har i sine slides nogle konkrete bud på hvordan kan ændre opfattelsen af at være et omkostningscenter til at være forretningens medspiller i at skabe forandringer. Kort fortalt handler det i hans opskrift om at tvinge forretningen til at prioritere nogle af de mange valg, der er nødvendige for at skabe værdi. Dermed tvinges forretningen tættere ind i beslutningsprocesserne og it fratages muligheden for at træffe egensindige beslutninger, som ikke demonstrerer forretningsværdi.
Selvom jeg har den akademiske arkitekt-baggrund, har jeg sjældent været i den situation hvor jeg har haft brug for at beklage mig opad i organisationen, eller at "klynke", som Kvorning kalder det. Måske fordi jeg ofte har søgt at overbevise folk i stedet for prøve at tvinge dem. Måske fordi jeg har overholdt ordsproget "speak softly but carry a big stick".
Men hvad er din oplevelse, er arkitekter gode nok til at overbevise og dermed bevise deres værdi' Har Kvorning i det hele taget ret i sin opdeling'
Selvom jeg har den akademiske arkitekt-baggrund
Spørgsmålet må være: "Har du nogensinde bygget et system, og fulgt det til ende?"
Jeg tænker ikke på akademiske slides osv, men praktisk erfaring?
Analyse af forretningsmæssige behov, impact analyse osv. osv. ?
Eller, lidt mere makabert:
Har du nogensinde haft blodige fingre?
Jeg kan sagtens, i min daglige gang, drage parallellen til den slide. Der er forskellige interesser som man skal forsøge at dække så godt det er muligt. Ikke helt uinteressant.
Martin Fowlers gode skriv: "Who needs an architect" http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf har en række gode pointer om emnet :-)
Når man tager denne problemstilling op, bør man skelne mellem 2 forskellige situationer - der hvor fejl straffes af sig selv og der hvor fejl rammer andre.
En privat virksomhed vil normalt lære af fejl og gradvist blive klogere / reducere tendensen til at gentage de samme fejl.
Derimod en offentlig "virksomhed" med en "nul-fejl" kultur vil normalt ignorere fejl og fokusere på at skjule disse, mens man blot tørrer skaden af på enten skatteyderne eller ved at skrue ned for serviceniveauet.
Det værste eksempel pt. er den Digitale Taskforce / Finansministeriet som udmærker sig ved at gentage disse fejl i stadigt større skala og påtvinge deres syn på alle andre.
Man har låst sig fast på en tilgang som udelukkende har til formål at understøtte regnskabsfolk og planøkonomer i ministerierne uden på nogen måde at se på den manglende værdiskabelse, den kroniske fastlåsning og undermineringen af både sikkerhed og retssikkerhed som følger.
En pointe er at synet på IT i Centraladministrationen ikke overholder nogen af de 3 beskrevne. For centraladministrationen er paradigmet nærmest "IT som magt-middel" til at kunne overvåge, kontrollere og tvinge samfundet i den retning som planøkonomerne vil og bilder sig ind er den rigtige.
Man designer med tvang egne styringsinteresser ind i de teknologiske grundstrukturer uden mekanismer til at kompensere eller rette op.
Der er behov for en fjerde model "IT som magtfaktor" - uanset om det skyldes inkompetance eller bevidst magtmisbrug. Både dårlige it-afdelinger og planøkonomer har jo behov for eksistensberettigelse.
It som magtfaktor
Indstilling Politisk Viden Tvangsstandardisering Ydelse Magt og kontrol Krav Centralisering Opfattelsen Styringsmiddel
"Har du nogensinde bygget et system, og fulgt det til ende?"
Hvis dit spørgsmål var rettet til mig, Stig, så er svaret: ja, flere gange.
Ellers er det netop et godt spørgsmål at stille. Uden den slags erfaring bliver vægtningen af det teoretiske nemt for høj.
Generelt er arkitektur med henblik på at sikre bestemte fremtidige egenskaber ved systemet - uden at forretningen er enig i at netop [i]de[/i] egenskaber er de vigtigste - dømt til at ende med klynk.
Arkitektrollen er en neopotistisk opfindelse med formål at chefens svagbegavede nevø også kan få et job i firmaet. Alle kan tegne 5 kasser på en tavle og forbinde nogle af dem med streger. Og det er altid den samme standard tegning der diskes op med, så jobbet kræver ikke man forstår den pågældende konkrete løsning eller fornyer sig meget.
En gang hver andet år lykkes det dog en arkitekt at finde på en ny kasse at tegne på tavlen(ESB,SOA,SAN f.eks.), som så altid fremover altid indgår i standardarkitekturen (tegningen). Dette giver store klapsalver og ryg-klapperi til arkitekt-konferencerne.
Desværre lider alle fremtidige udviklingsopgaver nu under denne kompleksistet. Hvad der for 5 år siden var en simpel 3-lags arkitektur (Client,Server,DB) er nu 'obfuskeret' til ukendelighed.
Samtidigt kan arkitekten udmærke sig med ved også at bundle standard-tegningen med en mængde 'standard' software, der selvfølgelig er udviklet af arkitektens firma eller arkitektens firma er partner det pågældende softwarehus. Denne software er ofte mega-produkter som skyder langt over målet for den pågældende løsning og yderligere øger kompleksisteten, timeplanen og prisen unødvendigt.
@Thomas Egense:
At nogen har ansat chefens nevø som arkitekt er et meget ringe påskud for at skælde ud på alle, der formaster sig til at kalde sig arkitekter. It bruges snart set overalt i virksomheder/organisationer, og nogen skal have et blik for at finde den bedste it-understøttelse, og det har så fået en titel (og for mange er det ikke en separat titel, blot noget direktøren/finanschefen/salgslederen/it-chefen bare også kan, uden at kalde sig arkitekt af den grund).
For nogen tid siden snakkede jeg i anden sammenhæng "titler" med en bygningsarkitekt som sin rolle som at "kunne bevæge sig i rum, der ikke er bygget endnu". Og jeg mener sådan set at den beskrivelse passer rigtig godt på it-arkitektens rolle hvis den overføres direkte til vores it-verden: En it arkitekt kan beskrive og forklare sammenhænge imellem systemer, der ikke er implementeret endnu (på en måde som kan få de relevante interessenter, herunder udviklere og systemejere, til at forstå det). En enterprisearkitekts opgave er tilsvarende, blot på forretningsproces- og systemniveau. I begge tilfælde handler det om at lytte til behovene, finde de gældende realiteter, og de midler (tid, penge, udviklere, etc.), der er til rådighed og så operere inden for det. Den opgave kræver selvfølgelig rigtig meget praktisk erfaring, et rigtig godt overblik, og gode formidlingsevner. Og en realisering af at man på et vist niveau er nødt til at overlade visse detaljer til dem, der ved bedre, f.eks. dem der skal (re)designe systemerne, eller forretningen, komponenterne alt efter niveauet, også selvom man som arkitekt jo også tit har baggrund som udvikler ell. lign)
Bygningsarkitekten kunne i øvrigt sagtens se sammenhængen. (Han tegner i øvrigt også nogle flotte huse, jeg gerne ville bo i. Og han bygger i øvrigt selv på sit eget.)
Altid brugbart at udvide sin horisont lidt og se tingene fra en andens verden.
Arkitekter, der kommer med et softwareprodukt under armen, kan vel bedst sammenlignes med en arkitekt i et typehusfirma - en del af løsningen ER netop bygget på forhånd, og deres tilstedeværelse afspejler dette. Det må den, der hyrer arkitekten jo også vide.
Arkitekter, der kommer med et softwareprodukt under armen, kan vel bedst sammenlignes med en arkitekt i et typehusfirma - en del af løsningen ER netop bygget på forhånd, og deres tilstedeværelse afspejler dette. Det må den, der hyrer arkitekten jo også vide.
Jeg troede man kaldte en sådan for en sælger?
Se på løsningen, indeholder den den lovede funtionalitet, har den den lovede kvalitet, overholdt den planen og sidst men ikke mindst har forretningen fået det ud af investeringen på kort og lang sigt som de ønskede. Herefter er der vel ikke så svært at dømme den ansvarlige arkitekt. Dog er det oftest sådan at når det begynder at brænde på er arkitekten pist forsvundet, og udviklerne hænger på den. Eller ednu bedre, når det går skævt, mander vi op på admin, og ansætter flere jakkesæt, for det må jo være der den er gal - til sidst har vi flere "ledere" end udviklere... Så skal vi nok spørge os selv, hvad det var kunden have bestilt og indvilget i at betale for - software. Det er ikke arkitektur som "center of the world", og heller ikke test, selvom flere og flere slår sig op på dette. Siden hvornår har man kunnet teste kvalitet ind i et produkt? Aldrig, og det vil man aldrig kunne.
Det der efterhånde er brug for er nogle system designere (de hedder vel også Solution Architects i dag), som kan omsætte det værdiskabende univers lavet af en arkitekt, til handling (implementation), for det kan ganske få Enterprise Arkitekter (hvor mange enterprises er det lige vi har i Danmark?).
Hvad er en IT arkitekt???
Enterprise Arkitektens formål er at forstå forretningen og sammen med deres vision, skabe et IT system. Derefter skal han kunne formidle dette videre til udviklingsorganisationen. Og så kræver det en hel del innovativitet, ellers ender denne forretning også bare med en .NET/IBM/Oracle standard løsning, nøjagtig som konkurrenten - med all the new bells and whistles. Derfor er den rolle næsten bedst besat med et team, bestående af en forretningskonsulent og en system desginer, og ikke en eller anden kloge åge, som ikke kan hverken det ene eller andet ordenligt, men har taget en masser kurser og fået flotte certificeringer, og nu kan gå igennem verdens længste og dyreste metodeapparat for at fremstille en powerpoint slide med tilhørende hyldemeter af word dokumenter (eller er det OOXML/ODF dokumenter :-).
Jeg troede man kaldte en sådan for en sælger?
:-) Det kunne man også. Jeg ville heller ikke selv entrere med sådan én, med mindre jeg vidste jeg ville købe noget (bestemt). Og så ville jeg ikke klynke hvis jeg fik det. Jeg forsøgte bare at drage en parallel.
Om det skal hedde softwarearkitekt, løsningsarkitekt, it-arkitekt, enterprisearkitekt - meh, vælg hvad der passer, YMMV, det handler vel bare om hvilket scope, man har med at gøre, jeg benyttede termen it-arkitekt fordi understøttelse af noget ny forretning jo somme tider forudsætter andre elementer end software, f.eks. hardware. Somme tider er det en hel "enterprise", der arbejdes på, somme tider er virkefeltet mindre, men opgaven er vi så vidt jeg kan se enige om: At forstå forretningen, at skabe et it system, at formidle det til dem, der skal implementere det (og de andre interessenter!) Og gøre det bedre end konkurrenten.
Når det brænder på: Jeg ved ikke om {løsnings|software|enterprise}arkitekter generelt er værre eller bedre til at se tingene til ende, end f.eks. topchefer, ministre, LEAN-konsulenter, etc. men man kan jo ikke binde folk på hænder og fødder indtil projektet/valgperioden/... er slut. Derimod kan man vel med rimelighed godt kræve at arkitekten for det meste følger sine projekter til dørs (og kan dokumentere det). Hvordan skulle han/hun ellers kunne lære af evt. successer og fiaskoer? (Ikke spor anderledes end andre professioner, kun længere tidsforløb)
Kendte ikke YMMV. Slog det op. Betyder nok ”Your Mileage May Vary”, men det kan også være ”You Make Me Vomit” :-)
Jeg tror bare det er væsentligt at huske på forskellen mellem bygningsarkitektur og software-/systemarkitektur (har er Martin Fowlers dokument uvurderligt inklusive Ralph Johnson korrespondancen).
Altså at software kan laves om, og det er ikke dyrt som udgangspunkt, man kan dog begrave sig i et hul der gør det dyrt. Bygningsarkitektur er temmelig dyrt at lave om, når først det står færdigt.
Derfor er arkitektur rollen også væsentlig anderledes, da en bygningsarkitekt skal indsamle så meget information han kan up front. Det behøver en software (eller hvad vi nu skal kalde ham) ikke, da det senere kan (og skal) laves om.
Vi prøver ofte med djævlens vold og magt, at definere og låse en hel ting masse up front (og nu er det service grænseflader og ikke database skemaer), og laver på den måde en masse meget dyre begrænsninger. Hvis man følger nogle principper (eks. Postel's Law), kan man bevæge sig langt mere agilt og produktivt. OCP giver iøvrigt også rigtig god mening i en SOA.
havde man en titel som "Rationaliseringsekspert" og det er vel den rolle som nutidens Enterprise Arkitekter skal opfylde. Altså hvordan får jeg forretningen til at blive mere effektiv ved at optimere samspillet mellem mennesker, teknologi og processer. Jeg kan være bange for at en del Enterprise Arkitekter har placeret sig selv i teknologi stolen og derfor kan have svært ved at levere varen. Noget andet jeg er bange for er, at de fleste arkitekter er meget fokuseret på at tegne "flotte huse" uden at tænke på om de nu også kan holde. Derfor ser man mange systemer der bliver sat i drift hvor driftsafdelingen ryster på hovedet og siger "det lort kommer aldrig til at performe ordentligt". Men som i alt andet i denne verden så er er gode håndværkere og dårlige håndværkere også blandt arkitekter, så lad mig slutte med mit yndlingscitat:
"Hellere jord under neglene end i hovedet".
Kære Nikolaj.
Altså at software kan laves om, og det er ikke dyrt som udgangspunkt, man kan dog begrave sig i et hul der gør det dyrt. Bygningsarkitektur er temmelig dyrt at lave om, når først det står færdigt.
Software er bare et abstraktionsniveau på linje med marmor eller skumgummi. Software i sig selv er ikke hverken billig eller dyr at ændre. Systemer derimod er dyre at ændre, jo dybere de stikker.
F.eks kan det da ikke koste en formue at ændre CPRs årsangivelse fra at bruge to tal til 4 til, vel ? Det er jo bare en softwareændring ?
Hvor mange milliarder tror du det ville koste ?
med venlig hilsen
Peter Maersk-Moller
Kære hr Maersk-Moller,
Dejlig ironisk tone :-)
Men... alt kan jo abstraheres, og derfor er vi nødt til at trække en grænse et sted for at noget begynder at giver mening. At marmor og skumgummi er abstrakte er i mine øjne ikke særlig anvendeligt, i min verden er de temmelig konkrete begge dele. Pointen er, at bygger du et badeværelse, så er det rimelig problematisk (endsige dyrt), at flå dit marmorgulv af for at få et af træ (skulle du ønske det). Software er for det meste også ganske konkret, i og med det er en realisering af noget abstrakt.
Husk nu på hvorfor software opstod (historie lektionen om software og hardware), og hvorfor det hedder "soft".
Jeg kan ikke lige på stående for huske hvornår CPR har brugt 2 cifre (ikke tal) til at repræsentere fødselsår, og så vidt jeg er orienteret aldrig, men det kan være lige meget.
Du misforstå pointen (om det så er med vilje, eller hvorfor du gør ved jeg ikke). Pointen er at man kan rette det, og det nok er ganske meget billigere at rette samtlige verdens IT systemer for en fejl, end hvis vi skulle rette samtlige verdens bygninger for en fejl (f.eks. lave en ekstra kælderetage på dem alle).
Wikipedia om Y2K problemet, da jeg tror det er det du referere til.
Countries that spent very little on tackling the Y2K bug (including Italy and South Korea) experienced as few problems as those that spent much more (such as the United Kingdom and the United States), causing some to question whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated.
I øvrigt har Y2K ikke noget med funktionalitetsændring undervejs i et implementeringsforløb, og det er det jeg taler om at gøre, men at der for længe siden blev indbygget en forudseelig fejl i it systemerne. Så dit ressonement omkring CPR (som jeg tror du forveksler med Y2K bug) holder ikke.
Og så lige for at svare på dit spørgsmål (google virker fatisk også på dette): Y2K kostede estimeret US$ 300 mia.
Og så til sidst har du læst Fowler? Er du uenig? Hivs du er, er det så fordi han angriber din position som rådgiver og arkitekt? jeg har svært ved at se hvorfor han ikke har en særdeles god og vigtig pointe.
Peter hvad mener du ellers om Postel's Law og OCP i en SOA?
/NEKO
@Jan Flodin
Men som i alt andet i denne verden så er er gode håndværkere og dårlige håndværkere også blandt arkitekter...
Men dette gælder kun i den vestlige verden, i out sourcing landene er der kun gode håndværkere... ;-)
Hej Nikolaj.
Jeg kan ikke lige på stående for huske hvornår CPR har brugt 2 cifre
Øhhh, altid. "Ciffer 5 og 6 angiver et tocifret årstal personen er født i." Se http://da.wikipedia.org/wiki/CPR-nummer
og det nok er ganske meget billigere at rette samtlige verdens IT systemer for en fejl, end hvis vi skulle rette samtlige verdens bygninger for en fejl (f.eks. lave en ekstra kælderetage på dem alle).
NPrincipielt set taler vi om at sammenligne et tordenskrald og Rundetårn, så vi er ude i dyndet allerede. Min pointe er bare, at jeg kan ikke se at det skulle være indlysende at det er billigt eller billigere at ændre noget som helst bare fordi det er software. Det er simpelt hen ikke givet. Det kan være afsindigt rasende dyrt eller fuldstændigt uladesiggørligt. Prøv bare at ændre noget fundamentalt i nogle af de offentlige IT-systemer. Det koster altid mellem et par hundre millioner og et par milliarder. Man kan immervæk lave en del byfornyelse for et par milliarder.
Amanda, komplet forfejlet i sin arkitektur, stod ikke til at redde trods flere hundrede millioner. Der var vist også et fælles IT-system til de videregående uddannelser, der ikke stod til at redde på trods af nogle hundrede millioner eller mere. En halv milliard og så blev problemet ikke fixet. Det er da rasende dyrt.
At ændre software, kan være billigt, at ændre i systemer koster som regel altid spidsen af en jetjager, en bondegård eller en fucking masse lidt afhænggig af, hvor i landet du bor.
Er jeg så enig med Fowler ? Ja delvist. Nogle kalder sig arkitekter uden at forstå de underliggende mekanismer, hvilket meget let kan lede til at de konstruerer komplekse systemer, som de ikke forstår konsekvenserne af. Fowler slutter af med at skrive
[quote]Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”[quote]
Det lyder godt og ritigt, men holder ikke helt. Software er også bundet af [laws of] physics, bare på en anden måde end en bygning. I virkeligheden mener jeg nok, at der giver kun forvirring at prøve at sammenligne en bygning med software eller en bygningsarkitekt med en softwarearkitekt. Spild af tid.
Find hellere ud af, hvorfor så mange, der kalder sig [IT-]arkitekter, næppe er andet end administratorer med begrænset indsigt, vision eller dybe forståelse. Deri ligger en del af de fejlslagne projekter.
At være en [IT-]arkitekt, kræver ofte en nærmest autistisk evne til at se mønstre og sammenhænge og de fleste mangler den. Det er ikke noget man lære. Enten har man det elelr ej. Til gengæld kræver det træning at bruge sit talent.
Men bevares, i mangel af naturlig evne kan man prøve at bruge metoder og strukturer, men det rækker kun så langt.
mvh.
Hej Peter,
Øhhh, altid. "Ciffer 5 og 6 angiver et tocifret årstal personen er født i." Se http://da.wikipedia.org/wiki/CPR-nu...
Klart! min fejl :-) Ja altid.
NPrincipielt set taler vi om at sammenligne et tordenskrald og Rundetårn, så vi er ude i dyndet allerede.
Nej vi gør ej, vores forudsætninger er blot forskellige. Du forudsætter at software for det meste koster rigtig mange penge at ændre. Jeg forudsætter anderledes, for jeg vil hellere til det jeg ser som kernen af problemet, som er det oftest spage tankesæt der spiller sig ud hos administratorene af en IT implementation.
Amanda, komplet forfejlet i sin arkitektur, stod ikke til at redde trods flere hundrede millioner.
Meget forsimplet udlæg af sagen, men delvis rigtig. Dog kostede det faktisk over 1 mia. for meget :-)
At ændre software, kan være billigt, at ændre i systemer koster som regel altid spidsen af en jetjager, en bondegård eller en fucking masse lidt afhænggig af, hvor i landet du bor.
Problemet er oftest at IT system implementering behandles som en statisk transformation, ligesom BPR. Det er en stakket frist, som ikke ændre noget i det lange løb, andet end at de må lave BPR igen (eller implementere IT forfra igen). Det offentlige, som vi jo nu taler om, har jo deres garati periode, hvorefter systemet skal konkurrenceudsættes, her bringes det så igen i udbud, og ofte starte en reimplementation af projektet (borger.dk, virk.dk m.fl.).
Det ville være rart at behandle IT, med den forudsætning at verden faktisk ændrer sig, og dermed også krav mm. Derfor skal systemerne laves så det kan ændres.
Jeg mener ikke det hjælper noget at sidde og sige at software er dyrt at ændre, for det ændre intet - tværtimod bliver det den selvopfyldende profeti. Man kan ikke sige at det er dyrt at ændre i software, men man kan sige at det er en dyr proces at ændre i softwaren, fordi man har et forkrøblet og forkert proces-apparat (og totalt utidsvarende), at følge. Jeg mener stadig vi har en del at lære af andre inden for udviklings- og produktionsbranchen - det være sig bygninger, biler m.fl. For de kan noget vi ikke kan - bla. kan nogen af dem også fortælle hvor meget noget koster (Øresunds broen f.eks.).
Min pointe (nok provokerende), er at kan vælge at lukke øjnene og bare acceptere den tilstand vi har - men det vil jeg så ikke.
PS:
Find hellere ud af, hvorfor så mange, der kalder sig [IT-]arkitekter, næppe er andet end administratorer med begrænset indsigt, vision eller dybe forståelse. Deri ligger en del af de fejlslagne projekter.
At være en [IT-]arkitekt, kræver ofte en nærmest autistisk evne til at se mønstre og sammenhænge og de fleste mangler den. Det er ikke noget man lære. Enten har man det elelr ej. Til gengæld kræver det træning at bruge sit talent.
Men bevares, i mangel af naturlig evne kan man prøve at bruge metoder og strukturer, men det rækker kun så langt.
Helt enig, dig kunne jeg godt drikke en øl med en dag :-)
/NEKO
