De grens tussen Architect & Designer

[kasper_vk]

Laatst merkte een collega op dat nogal moeilijk is om een duidelijke beschrijving te geven van de rol Architect en om anwoord te geven op de vraag: waar houdt de verantwoordelijkheid van de architect op en begint die van de designer?
Zijn stelling is dat wanneer je die vraag aan 10 mensen stelt, je waarschijnlijk 10 min-of-meer verschillende opvattingen krijgt. Ik denk dat hij daar redelijk gelijk in heeft, en vandaar nu dit topic.

Mijn vragen
Waar ligt de grens tussen Architect & Designer?
En daaraan verwant: wat is het dus taken-pakket van de architect (en van de designer)?
Verschilt dat per soort project (game, kantoorapplicatie, etc) ?

Hoe ligt dat in jullie bedrijf ?
Wie bepaalt waar die grens ligt; de projectleider, het hoofd ICT, wie anders?
Of 'ontstaat' die grens geleidelijk aan, wellicht omdat iemand de rol architect 'op zich neemt' ?
Wat vind je van die verdeling?
Pakt deze verdeling in de praktijk ook zoals bedoeld uit? En waarom dan niet?

Mijn beeld / opvatting
Ik merk dat ik zelf ook niet echt een duidelijk beeld daarvan heb. Mijn beeld:
De architect
- kiest in mijn ogen op welke platform een toepassing ontwikkeld word (indien er meerdere platformen ter beschikking zijn).
- bepaald op welke wijze een nieuwe systeem met legacy systemen gaat communiceren
- kiest een setup in tiers & layers, definieert de grenzen daartussen en bedenkt een deployment-scenario
- bewaakt tijdens het ontwikkelen dat zijn richtlijnen aangehouden worden
- is het eerste terugkoppelpunt bij onduidelijkheid over vragen omtrent bovenstaande

De (groep van) designer(s) heeft een wat bescheidener takenpakket:
- beslist package / namespace structuur
- wanneer definieer je een aparte class
- ontwerp het database model of werkt het iig verder uit

Praktisch gezien is de designer, denk ik, meestal ook een ontwikkelaar / progger.

Mijn Ervaring
Bij mijn bedrijf is er binnen per project eigenlijk 1 persoon aangesteld die de rol als architect op zicht neemt en verder is iedereen progger-en-designer -in-1.
Onderling merk ik trouwens dat er toch vrij weinig overleg plaatsvind, waardoor (ondanks de betrokkenheid / benoeming van een architect) classes vaak een merkbaar verschillende 'look-en-feel' hebben en het bewaken van welke-code-gaat-waar (iets wat BL is toch vaak dubbel in GUI-laag) nauwelijks gebeurd.

[whoami]

Waarom alles zo in hokjes plaatsen ? Waarom zou je een architect & een designer moeten hebben ? Waarom zou een architect ook geen programmeur kunnen zijn, die gewoon de verantwoordelijkheid heeft om met de architectuur bezig te zijn ?

[Rukapul]

whoami schreef op dinsdag 20 februari 2007 @ 11:32:
Waarom alles zo in hokjes plaatsen ? Waarom zou je een architect & een designer moeten hebben ? Waarom zou een architect ook geen programmeur kunnen zijn, die gewoon de verantwoordelijkheid heeft om met de architectuur bezig te zijn ?

Hij zegt toch niet dat dat niet kan? Uiteindelijk kan niet iedereen belast zijn met alles, en is er (hopelijk) minder architectuur werk dan designer en programmeerwerk.

De exacte grens lijkt me typisch iets wat zich natuurlijk ontwikkelt op basis van interesses en capaciteiten

De rol van architect wordt hier overigens wel heel erg vanuit een programmeursperspectief beschreven. Communicatie met de klant, etc. zie ik bv niet terugkomen.

[ Voor 11% gewijzigd door Rukapul op 20-02-2007 11:40 ]

[F_J_K]

Sterker nog, er zijn net zo veel mensen die iets rond ICT-architectuur op hun kaartje hebben staan die helemaal niets van doen hebben met het proces van applicaties bouwen en zich puur bezig houden met applicaties, informatie, etc. en hun relaties onderling. Datzelfde heb je natuurlijk ook met designer, waar je ook de grafische mensen onder kan scharen.

In het algemeen bepaalt (IMHO) een architect in samenspraak met alle stakeholders (sic) de globale structuren van applicaties / organisaties, incl. de relaties tussen globale componenten en vooral externe applicaties, de impact op gebruikers / beveiliging / de bestaande systemen / etc. Hij/zij gaat vooral in op de hoofdlijnen, kent alle technische alternatieven voldoende om hier keuzes te kunnen maken maar gaat geen volledig functioneel of technisch ontwerp maken.

[EfBe]

Een architect ontwerpt gebouwen. Dus ik denk dat we snel klaar zijn met deze vraag.

En dit is geen flame. Ik erger me steeds meer en meer aan het gebruik van het woord 'Architect' in de software engineering. Iemand die een automotor ontwerpt is ook geen architect, een persoon die software ontwerpt dus ook niet.

[F_J_K]

offtopic:
Hmmm. Ben ik niet met je eens, IMHO kan een term als architect best uitgebreid worden richting andere gebieden zolang het eenzelfde insteek heeft (overzicht, niet de details). Zo niet doet iemand die designer is alleen aan (pak-em-beet) kledingdesign en een schijver heet typist als deze niet met pen-en-papier werkt.

[ Voor 7% gewijzigd door F_J_K op 20-02-2007 13:08 ]

[Dido]

Ik vind de beschrijving van de designer in de TS wel erg summier.

De beschrijving van de architect kan ik m ewel in vinden, maar een designer ken ik in twee smaken: functioneel en technisch.
De functioneel designer gaat absoluut niet over een database of andere technische zaken, maar draagt bijvoorbeeld zorg voor een functioneel datamodel en een functionele procesbeschrijving.

De technisch designer ontfermt zich over het technisch datamodel (hoe komt het in de/een datase) en dergelijke.

Wie bepaalt wanneer een class gedefinieerd wordt laat ik in het midden. Begin bij de vraag of je met classes werkt

De architect staat "boven" dat alles, in de zin dat ik hem verantwoordelijk acht voor het framework waarbinnen de designers werken. Welke hardware is er / komt er, op wat voor platform wordt er ontwikkeld, wat wordt er ondersteund. Wat voor standaards worden er gevolgd bij interfacing , etc, etc, etc. Dat soort beslissingen horen m.i. echter los te staan van specifieke projecten.

[RedRose]

Ik vind het eigenlijk een beetje een non-discussie, behoudens geouwehoer over terminolgie. Volgens mij is de scope of het domein waarin iemand werkt veel meer een maatstaf voor wat die persoon doet. Daarnaast hangt het er ook maar net vanaf hoeveel mensen er in een ontwikkelteam zitten die, op basis van specifieke kwaliteiten specifieke taken uitvoeren, geholpen door functionele, bedrijfsmatige en / of projectmatige input van anderen.

Ik vind overigens de term softwareengineer beter passen dat softwarearchitect, omdat ik engineering beter de lading vind dekken van wat er allemaal gebeurt in het software ontwikkelproces.

[MicroWhale]

Een architect ontwerpt architecturen.

In de software ontwerpt deze persoon (of meerderen) meestal de kaders waarbinnen software-engineer zijn werk kan gaan doen.

Er zijn personen nodig die verder kijken dan de scope van een software-engineer en zich bezig houden met het op elkaar afstemmen van meerdere processen en werkgebieden. Binnen zijn eigen kader/opdracht kan de software-enigneer natuurlijk zijn eigen architectuur opzetten, maar ook dit wordt vaak aan banden gelegd om de code aan bepaalde eisen te laten voldoen.

Voor een grotere opdracht waarin meerdere ontwikkelteams aan delen van de oplossing werken heeft de software-enigneer gewoon het overzicht niet en kunnen bepaalde delen van een systeem niet aan het toeval overgelaten worden. Daarvoor zijn er voordat de software-engineer zijn ding moet doen al afspraken gemaakt over het hoe en wat van de oplossing. En bij die afspraken horen ook die van de architectuur van het systeem.

[EfBe]

MrWilliams schreef op dinsdag 20 februari 2007 @ 19:12:
Een architect ontwerpt architecturen.

In de software ontwerpt deze persoon (of meerderen) meestal de kaders waarbinnen software-engineer zijn werk kan gaan doen.

Er zijn personen nodig die verder kijken dan de scope van een software-engineer en zich bezig houden met het op elkaar afstemmen van meerdere processen en werkgebieden. Binnen zijn eigen kader/opdracht kan de software-enigneer natuurlijk zijn eigen architectuur opzetten, maar ook dit wordt vaak aan banden gelegd om de code aan bepaalde eisen te laten voldoen.

Voor een grotere opdracht waarin meerdere ontwikkelteams aan delen van de oplossing werken heeft de software-enigneer gewoon het overzicht niet en kunnen bepaalde delen van een systeem niet aan het toeval overgelaten worden. Daarvoor zijn er voordat de software-engineer zijn ding moet doen al afspraken gemaakt over het hoe en wat van de oplossing. En bij die afspraken horen ook die van de architectuur van het systeem.

Dit klinkt echt als het goedpraten dat er iemand als 'Architect' door het leven gaat terwijl die persoon gewoon ook een software engineer is. Want is het niet zo dat als we jouw redenatie volgen, de architect eigenlijk na een uurtje al klaar is? Immers, zodra je langer nadenkt moet je meer details invullen en dat is nu juist volgens jou de taak van de software engineer...

Bovendien plaatst jouw redenatie de 'architect' boven de engineer. No offence, maar dat gaat er bij mij echt niet in. Als een software engineer geen ontwerp kan maken is het een prutser en moet deze iets anders gaan doen.

[ Voor 3% gewijzigd door EfBe op 21-02-2007 08:48 ]

[Rukapul]

EfBe, hoe zie je dat dan bij wat grotere systemen (grote software, gedistribueerd, niet alleen SW, etc.)? Als ik jouw goed begrijp gaat dat een fantastisch systeem worden met 10+ gelijkwaardige software engineers

En het is al eerder gezegd: de rol van architect omvat meer dan het maken van een ontwerp

Je kunt terecht of onterecht ageren tegen de rol van architecten (of tegen de naam maar dat is flauw), maar geef dan wel aan waar alle functies die normaal bij een architect liggen terecht komen.

[ Voor 0% gewijzigd door Rukapul op 21-02-2007 10:01 . Reden: typo ]

[MicroWhale]

ik zeg niet dat een architect er boven staat... het ging er mij meer om dat een architect in de breedte werkt (multidisciplinair, over meerdere afdelingen/bedrijven, draagvlak creëren voor bepaalde oplossingen, etc...) terwijl een software engineer in de diepte werkt (een deel van de oplossing ontwerpen en maken).

[F_J_K]

Inderdaad. Waarbij dus inderdaad best gesteld kan worden dat een architect niets te doen heeft bij standalone applicaties (behalve zeer grote apps) en bij kleinere organisaties. Maar grotere organisaties of ontwikkeling/implementatie van een verzameling applicaties heeft inderdaad op een gegeven moment iemand nodig die de verschillende systemen (incl. technologien, heilige huisjes, vooroordelen, machtsspelletjes, tegenstrijdige wensen, etc etc) overstijgt. Maar inderdaad niet (perse) overruled.

[whoami]

Laatst heb ik een paar interessante artikels gelezen waarin gesteld werd dat een 'architect' ook actief bij de ontwikkeling moet betrokken zijn.

http://stal.blogspot.com/...ct-always-implements.html
http://weblogs.asp.net/pg...chitects-should-code.aspx

[EfBe]

Rukapul schreef op woensdag 21 februari 2007 @ 08:58:
EfBe, hoe zie je dat dan bij wat grotere systemen (grote software, gedistribueerd, niet alleen SW, etc.)? Als ik jouw goed begrijp gaat dat een fantastisch systeem worden met 10+ gelijkwaardige software engineers

Binnen elk project heb je mensen met andere taken, maar IMHO zijn de meeste leden engineers en wellicht een aantal programmeurs die uitvoeren, maar het is IMHO te prefereren dat er niet een of ander ego boven staat die louter de grote lijnen uitzet als zijnde 'de architectuur' en dan de invulling overlaat aan de 'engineers' en dan ook nog zo dat deze t.a.t. binnen de lijntjes van wat de architect heeft bedacht blijven, want dat gaat echt niet werken.

En het is al eerder gezegd: de rol van architect omvat meer dan het maken van een ontwerp

Mja, wat dan? Taken die de software engineer uitvoert? . Is de 'architect' dan niet gewoon een engineer met als taak dat deze zich bezig houdt met een aantal ontwerptaken?

Je kunt terecht of onterecht ageren tegen de rol van architecten (of tegen de naam maar dat is flauw), maar geef dan wel aan waar alle functies die normaal bij een architect liggen terecht komen.

Ageren tegen de naam is niet flauw. Ten eerste doet een groepje architecten dat al (en om aan te geven dat ze gelijk hebben, moet ik nu gaan uitleggen dat ik met 'architecten' hier dus bedoel mensen die gebouwen ontwerpen) en ten tweede vind ik het wel welletjes zo langzamerhand mbt de wildgroei van namen binnen de software engineering.

De benadering van Architect zoals geschetst door een aantal hier riekt trouwens wel erg naar waterfall... Niet dat waterfall 100% slecht is, maar het is zeker niet de silver bullet. M.a.w., De architect kan niet alles bepalen in jullie geval, want hij / zij heeft ook geen totale overview.

[kasper_vk]

Als ik zo de reacties lees dan kan ik me ergens wel erg vinden in EfBe's reacties, bv als het erom gaat dat de rol/functie van 'Architect' eigenlijk niet bestaat, maar dat je eerder een lead-designer kunt aanwijzen die in het begin de grote lijnen uitzet, maar daarna 'opgaat in de kudde' van engineers en dan wellicht nog een controlerende rol heeft.
Of lees ik nu iets tussen jouw regels door wat je niet bedoeld?

Aanleiding voor dit topic is ook dat ik merk dat men bij mijn bedrijf de behoefte lijkt te heeft aan iemand die die overview heeft en dan wat grote lijnen uitzet. De persoon heeft natuurlijk een heel interessante rol toebedeeld gekregen en krijgt het hier ook voor elkaar om daar pakweg 80% van z'n tijd mee te vullen.
Maar die persoon is wat betreft functie & talenten echt niet hoger of beter dan ik, alleen werkt ie er gewoon wat langer waardoor ie meer kennis heeft van hoe zaken er binnen de SO afdeling, maar ook erbuiten, er aan toe gaan.
Dus ook wel wat EfBe zegt, als ik het goed begrijp .

Meer samengevat is de eerste reactie (van Whoami) wel erg terecht, ik merk dat ik stiekum een beetje besmet ben met een bepaalde hokjes-gedachte die hier erg leeft.

offtopic:
Om maar helemaal te zwijgen over de neiging die hier ook erg leeft om inderdaad voor alles maar weer nieuwe namen te verzinnen (en het liefst hippe afkortingen natuurlijk!).

[MicroWhale]

*probeert nog een keer*

De architect (of whoever je hem/haar wilt noemen) heeft een plaatje van het grotere geheel en zorgt ervoor dat er in de verschillende onderdelen van een bedrijf (of bedrijven) een samenhangend geheel ontstaat zonder redundatie, met compatibele systemen. Probeert hier problemen in te signaleren en oplossingen voor te bedenken.

Deze persoon werkt dus op een hoger abstractienivo met automatisering dan de engineer. Niet noodzakelijkerwijs op een hoger functienivo. Deze persoon bepaalt absoluut niet op implementatienivo wat er moet gebeuren, dat doet de engineer.

Uit het werk van de architect kan bijvoorbeeld wel voortkomen dat een bepaalde oplossing in een bepaald database-systeem geschreven dient te worden, omdat het later wellicht samen moet gaan met een al bestaand systeem. Dit laatste valt voor de software-engineers op het moment dat ze de oplossing gaan maken buiten hun scope (het bestaan van het systeem hoeft in principe niet bekend te zijn voor de engineers), maar is toch belangrijk voor de continuiteit en flexibiliteit van de organisatie.

[F_J_K]

Denken dat je met een dozijn systeemeigenaren rond de tafel er uit kan komen is imho een beetje te veel poldermodel. Een van de systeemeigenaren tijdelijk de overkoepelende pet geven lijkt me nog erger. We blijven toch mensen, die de eigen belangen nastreven en die van het geheel vaak dan niet zien of die van anderen als minder belangrijk zien.

offtopic:
In 1 zin een wildgroei aan namen noemen en dan zelf software engineering roepen. Dat klopt imho niet, trek dan een lijn bij alles na programmeur

En inderdaad staan hierarchie / loon / etc hier helemaal los van.

[ Voor 6% gewijzigd door F_J_K op 21-02-2007 14:10 ]

[kasper_vk]

EfBe schreef op dinsdag 20 februari 2007 @ 12:41:
Een architect ontwerpt gebouwen. Dus ik denk dat we snel klaar zijn met deze vraag.

En dit is geen flame. Ik erger me steeds meer en meer aan het gebruik van het woord 'Architect' in de software engineering. Iemand die een automotor ontwerpt is ook geen architect, een persoon die software ontwerpt dus ook niet.

Tja, bij mijn zoektocht naar wat meer houvast in deze discussie kwam ik dit Wikipedia artikel tegen.
Samengevat: de titel Architect is beschermd en het voorbeeld dat een ICT-er zichzelf architect noemt wordt zelfs letterlijk een overtreding op de wet van de architectentitel genoemd...

Een ICT-er die zichzelf Architect noemt is dus wettelijk in overtreding

[F_J_K]

Er is een verschil tussen de titel en de functie. Er zullen weinig mensen zeggen dat ze de titel vakkenvuller hebben terwijl er velen die functie hebben...

[MicroWhale]

De termen Architectuur en Business-, Information- en Infrastructure-Architect vind ik persoonlijk nog niet eens zo slecht gekozen.

In kleine organisaties vind ik de functie zwaar overbodig. Deze kan ook vervuld worden door de SE's die er zitten. Voor grotere organisaties lijken me zo'n functies noodzakelijk, omdat het me onmogelijk lijkt voor (zeg) 100-en software-engineers over meerdere afdelingen om te bepalen wat wel of niet goed is voor de organisatie/informatievoorziening.

Op het hogere abstractienivo zorgen deze mensen ervoor dat er (een beetje) orde in de chaos blijft bestaan, zodat 'als bedrijf' de koppen dezelfde kant op blijven staan, de juiste info op de juiste plek komt en er een beetje uniformiteit blijft bestaan in gebruikte systemen.

Omdat het over een hoger abstractienivo gaat, is de functie wel moeilijker uit te leggen en verdedigen bij mensen van het (hoger) management. Het lijkt er namelijk op dat deze functie 'niks toevoegt' aan de bestaande structuur.

[EfBe]

MrWilliams schreef op woensdag 21 februari 2007 @ 14:02:
*probeert nog een keer*

Je kunt het blijven proberen, het blijft neuzelen in de marge. Ik zie mezelf bv als een software engineer. Toch zie ik geen dingen op mn pad waar ik niet voor opgeleid ben of waar een echte architect bij moet komen kijken. Ik vind dat ook altijd sterk overdreven, temeer omdat ik de 1e architect nog moet tegenkomen die orders aanneemt van een software engineer, het is altijd andersom geregeld. Verder behoort wat jij de architect toebedeeld gewoon toe tot het vak van Software Engineering.

De architect (of whoever je hem/haar wilt noemen) heeft een plaatje van het grotere geheel en zorgt ervoor dat er in de verschillende onderdelen van een bedrijf (of bedrijven) een samenhangend geheel ontstaat zonder redundatie, met compatibele systemen. Probeert hier problemen in te signaleren en oplossingen voor te bedenken.

Deze persoon werkt dus op een hoger abstractienivo met automatisering dan de engineer. Niet noodzakelijkerwijs op een hoger functienivo. Deze persoon bepaalt absoluut niet op implementatienivo wat er moet gebeuren, dat doet de engineer.

Dat doet een ANDERE engineer. Wat jij nl. aan het doen bent is zaken die gewoon bij software engineering horen buiten dat vak plaatsen want het is kennelijk het werk van een architect. Ik ben pertinent tegen uitholling van mijn professie, en al helemaal door mensen die vinden dat ze architect moeten worden genoemd.

Uit het werk van de architect kan bijvoorbeeld wel voortkomen dat een bepaalde oplossing in een bepaald database-systeem geschreven dient te worden, omdat het later wellicht samen moet gaan met een al bestaand systeem. Dit laatste valt voor de software-engineers op het moment dat ze de oplossing gaan maken buiten hun scope (het bestaan van het systeem hoeft in principe niet bekend te zijn voor de engineers), maar is toch belangrijk voor de continuiteit en flexibiliteit van de organisatie.

Ik geloof niet in dat soort dingen, je kunt geen technische oplossingen verzinnen voor de mensen die die oplossingen eigenlijk moeten verzinnen, het zijn immers ENGINEERS, geen code generators.

MrWilliams schreef op woensdag 21 februari 2007 @ 14:50:
De termen Architectuur en Business-, Information- en Infrastructure-Architect vind ik persoonlijk nog niet eens zo slecht gekozen.

Wat houden die termen in vredesnaam in? Ik ontwikkel al 13 jaar op hoog niveau software maar ik zou niet een definitie op kunnen hoesten voor die termen die klopt. "Hallo, ik ben infrastructure architect"... ik denk dan meteen aan een systeembeheerder die kabels trekt naar patchkasten.

In kleine organisaties vind ik de functie zwaar overbodig. Deze kan ook vervuld worden door de SE's die er zitten. Voor grotere organisaties lijken me zo'n functies noodzakelijk, omdat het me onmogelijk lijkt voor (zeg) 100-en software-engineers over meerdere afdelingen om te bepalen wat wel of niet goed is voor de organisatie/informatievoorziening.

Volgens mij zit er iets scheef bij jou mbt de term 'software engineer'. Een software engineer MOET in staat zijn software te maken from scratch to finish EN daarna, vooral ook daarna. Dus daar hoort ook ontwerp bij, want dat hoort ook bij software engineering.

Op het hogere abstractienivo zorgen deze mensen ervoor dat er (een beetje) orde in de chaos blijft bestaan, zodat 'als bedrijf' de koppen dezelfde kant op blijven staan, de juiste info op de juiste plek komt en er een beetje uniformiteit blijft bestaan in gebruikte systemen.

Dat heette vroeger een informatie-analist, later een system analist en weer later kennelijk architect of business analist (of is die alweer 'uit' ?)

Wellicht ten overvloede: een software engineer moet ook informatie analyse kunnen doen, anders is het een code generator.

Omdat het over een hoger abstractienivo gaat, is de functie wel moeilijker uit te leggen en verdedigen bij mensen van het (hoger) management. Het lijkt er namelijk op dat deze functie 'niks toevoegt' aan de bestaande structuur.

En waardoor zou dat nou komen?

Binnen de hardware wereld heb je electric engineers. That's it. Binnen de software wereld heb je Software engineers, en thats it. Iedere klassificatie met meerdere termen houdt nl. in dat een persoon zoals ondergetekende met meerdere petten oploopt en dat geeft IMHO aan dat degene die al die termen verzint te weinig tijd spendeert aan software engineering.

[ Voor 36% gewijzigd door EfBe op 21-02-2007 15:48 ]

[MicroWhale]

Ik zie inderdaad dat het geen zin heeft.

Je ziet blijkbaar niet in dat iemand die op een ander abstractienivo een aantal van dezelfde taken uitvoert als de software-engineer (ik zal maar even jouw woorden gebruiken), meerwaarde kan creëren voor de situatie van een bedijf in het geheel.

Verbreed je gezichtsveld eens, doe je oogkleppen af. Er gebeurt meer dan alleen dat deel van een systeem waar jij op dat moment mee bezig bent. Er is een groter plan en dat is al veel eerder opgemaakt dan dat jij bezig moest gaan zijn met een opdracht. Daarvoor is het verkeer meestal van de analist (weer jouw woorden) naar de engineer en niet andersom.

Maar ja, het heeft geen zin om je daarop attent te maken, dus ik staak bij deze mijn pogingen.

[ColdSTone|IA]

Wat is dan exact de rol van een architect in de bouwwereld? Die kent ook geen constructieve details, ontwerpt een gebouw grotendeels op het uiterlijke en functionele (alhoewel dit laatste wel eens wil ontbreken). Het ontwerpen van een constructie die het ontwerp van de architect mogelijk moet maken wordt vaak geleverd door een civiel ingenieur.
Kunnen we dit model doortrekken naar software ontwikkeling, en dus stellen dat de Software Architect het overzicht heeft, een model ontwerpt waar bepaalde functionele eisen mee gerealiseerd kunnen worden, waarna de Software Engineer hier invulling aan geeft middels detail ontwerpen (de afzonderlijke componenten) en de implementatie hiervan.

[whoami]

Ik ben het ermee eens dat een 'software-architect' zich niet alleen met het 'hogere niveau' moet bezighouden, maar ook daadwerkelijk mee moet werken aan de implementatie. Eat your own dogfood.

Een architect in de bouwwereld moet wel op de hoogte zijn van constructieve details, want hij is ook verantwoordelijk voor werfopvolging. Hij moet op de hoogte zijn van constructieve details om te kunnen bijsturen waar nodig; hij moet dus kunnen zien of een aannemer een constructieve fout gemaakt heeft, wat dus wil zeggen dat hij op de hoogte moet zijn van die details.

[Antwan46]

En ik maar denken dat een architect bij bouw bedrijven hoort.
Dit werd eerder in het topic al vermeld, dus gelieve on-topic te reageren

[ Voor 40% gewijzigd door whoami op 21-02-2007 16:53 ]

[Rukapul]

whoami schreef op woensdag 21 februari 2007 @ 16:47:
Ik ben het ermee eens dat een 'software-architect' zich niet alleen met het 'hogere niveau' moet bezighouden, maar ook daadwerkelijk mee moet werken aan de implementatie. Eat your own dogfood.

M.i. hoeft een architect niet per se mee te coden. Wel moet een architect zo dicht bij de implementatie staan dat hij de beperkingen en mogelijkheden van deze implementatie kent en mee kan wegen. Een belangrijke taak van een architect is immers om de technische feasibility te bepalen. Een architect moet zich begeven onder het team van engineers en zeker niet een 'papieren architectuur' creeren en af en toe over de schutting gooien. Is samen voor een whiteboard staan ook 'meewerken aan de implementatie'? M.i. wel.

Een architect in de bouwwereld [...]

Waarom laten we de hele discussie over naamgeving niet achterwege? Uit de hele analogie met de bouwwereld heb ik nog nooit iets goeds voort zien komen.

[EfBe]

MrWilliams schreef op woensdag 21 februari 2007 @ 16:19:
Ik zie inderdaad dat het geen zin heeft.

Je ziet blijkbaar niet in dat iemand die op een ander abstractienivo een aantal van dezelfde taken uitvoert als de software-engineer (ik zal maar even jouw woorden gebruiken), meerwaarde kan creëren voor de situatie van een bedijf in het geheel.

Tuurlijk is het nuttig als op verschillende abstractieniveaus gewerkt wordt, ik zie mezelf dat ook niet ontkennen. Ik beweer alleen dat AL die abstractieniveaus gedaan moeten worden door een software engineer, m.a.w.: boven een zeker (en dat is dus echt onbepaald, of je moet het nu kunnen formuleren) abstractieniveau wordt de engineer niet ineens een architect. Benoem dan eens dat abstractieniveau. Ik zou het niet weten waar dat zich bevindt.

Verbreed je gezichtsveld eens, doe je oogkleppen af. Er gebeurt meer dan alleen dat deel van een systeem waar jij op dat moment mee bezig bent. Er is een groter plan en dat is al veel eerder opgemaakt dan dat jij bezig moest gaan zijn met een opdracht. Daarvoor is het verkeer meestal van de analist (weer jouw woorden) naar de engineer en niet andersom.

Volgens mij weet jij niet echt waar ik me al jaren mee bezig hou en op welk abstractieniveau ik over software praat / gevraagd wordt mee te praten, ik weet echt wel waarover ik praat.

Maar ja, het heeft geen zin om je daarop attent te maken, dus ik staak bij deze mijn pogingen.

Tja, jij bent toch degene die wollig blijft praten zonder dingen echt te benoemen.

Want geef nu eens aan, wat JIJ onder een software engineer verstaat? En wat dat zekere abstractieniveau is waarboven een engineer zich NIET meer begeeft maar een architect zich juist bevindt? Dat is me volstrekt onduidelijk.

Verder, ALS er een abstractieniveau is wat als plafond dient voor de software engineer, dan moet dat dus ook inhouden dat een software engineer dus minder kennis heeft van hoe software te bouwen, immers deze heeft geen kunde en kennis zich te begeven op een dermate hoog abstractieniveau.

No offence maar dat slaat echt als een tang op een varken.

ColdSTone schreef op woensdag 21 februari 2007 @ 16:40:
Wat is dan exact de rol van een architect in de bouwwereld? Die kent ook geen constructieve details, ontwerpt een gebouw grotendeels op het uiterlijke en functionele (alhoewel dit laatste wel eens wil ontbreken). Het ontwerpen van een constructie die het ontwerp van de architect mogelijk moet maken wordt vaak geleverd door een civiel ingenieur.

Maak niet de fout om software engineering te vergelijken met de bouwwereld. Dat kan nl. niet, want de bouwwereld zit heel anders in elkaar en een huis is niet een metafoor voor software. Er is nl. geen metafoor voor software.

Kunnen we dit model doortrekken naar software ontwikkeling, en dus stellen dat de Software Architect het overzicht heeft, een model ontwerpt waar bepaalde functionele eisen mee gerealiseerd kunnen worden, waarna de Software Engineer hier invulling aan geeft middels detail ontwerpen (de afzonderlijke componenten) en de implementatie hiervan.

Dus jij bent ook van mening dat een software engineer geen kunde hoeft te hebben om een model te ontwerpen (whatever 'model' inhoudt hier, mij onduidelijk), immers dat valt buiten de engineer zijn / haar scope ?

[ Voor 22% gewijzigd door EfBe op 21-02-2007 19:08 ]

[EfBe]

Een ander gevaar van het 'boven abstractieniveau X is de architect bezig'-denken is dat het impliceert dat een software engineer dat eigenlijk niet zou moeten doen, en je dus discussies krijgt waarbij een persoon die zich architect vindt en zich goed genoeg vindt om op dat abstractieniveau X te denken en te handelen, niet op gelijk niveau met een software engineer kan praten over die zaken want die software engineer is geen architect (in de ogen van de eerste). Waarbij de software engineer zich dus genoodzaakt ziet zich te bewijzen dat niveau X niet te hoog gegrepen is, om die indruk weg te nemen.

[LauPro]

@EfBe, ik weet niet precies wat jouw positie is maar ik neem aan dat je na 13 jaar wel een leidinggevende rol hebt en je toch een aantal verhoudingen moeten zijn opgevallen. In ieder geval zijn er binnen een project altijd verschillende lagen. En bij software is het zeker wenselijk om een goede architectuur op te zetten. Natuurlijk kan deze architectuur ook tot stand komen door middel van een aantal developers die gezamelijk de architectuur op stellen. Dit is volgens mij meer de gang van zaken in de Open Source wereld. Daar is meestal de oorspronkelijke auteur 'architect' - of soms juist niet.

Om even terug te komen: Bij commerciële softwareontwikkeling is er altijd een winstoogmerk. Om het commerciële doel zo snel mogelijk te behalen dient de software zo goed mogelijk te zijn afgestemd op de bedrijfsprocessen en filosofie. Meestal dient de software architect dan als brug (en spreekbuis) tussen 'het management' (de klant) en 'de programmeurs/engineers'. Om in bouwwereldanalogiën te blijven : de klant praat met de aannemer en niet met de bouwvakkers.

Afhankelijk van een project kan ik me voorstellen dat een programmeur best wel taken doet die de architect ook doet. Het gaat hierbij dus niet om softwareontwikkeling als een kunstvorm, maar met een commercieel doel. En binnen die kaders is het niet wenselijk dat engineers zich bemoeien met de architects. Natuurlijk is er wel intern overleg maar de uiteindelijke beslissing (en verantwoording) ligt bij de architect.

En als programmeur kan (en hoef) je veelal niet direct (te) zien welke consequenties het implementeren van een bepaalde functie voor het bedrijf heeft. Dat wordt bedoeld met het plafond. Een vakkenvuller is ook niet aangenomen om een nieuwe reclame compagne te lanceren.

[NDF82]

Een belangrijke taak van een architect is immers om de technische feasibility te bepalen.

Bullshit, ik hou me als SE voortdurende bezig met feasibility studies. Sommige mensen denken m.i. te veel hokjes om hun eigen ego te strelen.

[LauPro]

Volgens mij is het juist het tegengestelde van hokjes denken. Veel SE's doen de taken van een architect en voelen zich daarom ook als 'architect', dat kan wel zo zijn maar de vraag blijft voor welke functie je aangenomen bent...

[Rukapul]

NDF82 schreef op woensdag 21 februari 2007 @ 20:42:
[...]

Bullshit, ik hou me als SE voortdurende bezig met feasibility studies. Sommige mensen denken m.i. te veel hokjes om hun eigen ego te strelen.

Het een sluit het ander uiteraard uit in de 3e orde bullshitlogica. Net als LauPro zie ik dat anders.

[ Voor 6% gewijzigd door Rukapul op 21-02-2007 22:53 ]

[EfBe]

LauPro schreef op woensdag 21 februari 2007 @ 19:43:
@EfBe, ik weet niet precies wat jouw positie is maar ik neem aan dat je na 13 jaar wel een leidinggevende rol hebt en je toch een aantal verhoudingen moeten zijn opgevallen. In ieder geval zijn er binnen een project altijd verschillende lagen. En bij software is het zeker wenselijk om een goede architectuur op te zetten. Natuurlijk kan deze architectuur ook tot stand komen door middel van een aantal developers die gezamelijk de architectuur op stellen. Dit is volgens mij meer de gang van zaken in de Open Source wereld. Daar is meestal de oorspronkelijke auteur 'architect' - of soms juist niet.

Waar roep ik dat iedereen in een project hetzelfde doet? Nergens toch? Ik zeg alleen dat een SOFTWARE ENGINEER dat allemaal moet kunnen. De een doet echter A, de ander B. that's it.

Nu wil een groepje mensen degenen die A doen anders noemen. Dit houdt dan AUTOMATISCH in dat mensen die B doen kennelijk niet behoren tot het groepje van A.

En nu mag dat groepje roepen wat het wil dat het op gelijke hoogte staat als de mensen die B doen, maar dat is niet zo, althans niet qua salariering of macht binnen een project. En dat is nou NET wat er mis is aan dit hele geneuzel.

Ikzelf zie me als software engineer, want ik ontwerp en bouw software. Dat is nl. de taak van een software engineer. Nu kan een architect daar anders over denken, maar dat is dan zijn/haar probleem.

Ik heb nog steeds geen antwoord trouwens op mijn vraag op WELK abstractie niveau men zich moet begeven alvorens een 'architect' te zijn volgens die personen.

Om even terug te komen: Bij commerciële softwareontwikkeling is er altijd een winstoogmerk. Om het commerciële doel zo snel mogelijk te behalen dient de software zo goed mogelijk te zijn afgestemd op de bedrijfsprocessen en filosofie. Meestal dient de software architect dan als brug (en spreekbuis) tussen 'het management' (de klant) en 'de programmeurs/engineers'. Om in bouwwereldanalogiën te blijven : de klant praat met de aannemer en niet met de bouwvakkers.

Niet metaforen gebruiken, die gaan mank.
De architect is niet de spreekbuis, want wie ontwerpt dan de software? Ook de architect? Wie communiceert dan hetgeen de architect met de klant heeft gecommuniceerd naar de software engineers (in jullie kader dan) ? Ook de architect? En de software engineers praten an sig niet met anderen?

Afhankelijk van een project kan ik me voorstellen dat een programmeur best wel taken doet die de architect ook doet. Het gaat hierbij dus niet om softwareontwikkeling als een kunstvorm, maar met een commercieel doel. En binnen die kaders is het niet wenselijk dat engineers zich bemoeien met de architects. Natuurlijk is er wel intern overleg maar de uiteindelijke beslissing (en verantwoording) ligt bij de architect.

Volgens mij is er geen verschil in wat voor software ontwikkeling dan ook, de hobby-sfeer even buiten beschouwing gelaten.

Zoals je zelf al zegt, de architect is kennelijk hoger dan de engineer, immers de architect is bij machte om de mening van de engineer te overrulen. Dat lijkt me onzin, tenzij de architect ook een engineer is.

En als programmeur kan (en hoef) je veelal niet direct (te) zien welke consequenties het implementeren van een bepaalde functie voor het bedrijf heeft. Dat wordt bedoeld met het plafond. Een vakkenvuller is ook niet aangenomen om een nieuwe reclame compagne te lanceren.

Als dit gaat over baanbeschrijvingen dan zijn we gauw klaar, want dat is sowieso een zinloze discussie daar iedere organisatie zelf bepaalt welke random naam ze op welke stoel plakken.

Dit gaat over algemene termen. Persoon A komt persoon B tegen. A vraagt aan B wat B doet. B zegt "Ik ben architect", en A weet dan wat B doet. Althans, dat is waar de TS IMHO naar zoekt en tot op heden roepen er wel een aantal mensen iets over een abstractieniveau, maar welke dat is is onduidelijk.

Binnen een team heb je ervaren en minder ervaren software engineers. De ervaren software engineers hebben wellicht meer ervaring met het opzetten van een ontwerp dan de minder ervaren software engineers en worden daar dan dus ook mee belast, en als de organisatie slim is laat men de minder ervaren software engineers af en toe meelopen met de ervaren software engineers zodat kennis gedeeld wordt.

Kom dan niet aan met 'op dit abstractieniveau heb je een architect nodig' want dan snap je niet wat software engineering inhoudt. Voor de mensen die dat inderdaad niet weten: software engineering is niet gelijk aan code kloppen.

[EfBe]

LauPro schreef op woensdag 21 februari 2007 @ 22:00:
Volgens mij is het juist het tegengestelde van hokjes denken. Veel SE's doen de taken van een architect en voelen zich daarom ook als 'architect', dat kan wel zo zijn maar de vraag blijft voor welke functie je aangenomen bent...

Sinds wanneer is je taakbeschrijving leidend voor wat je doet binnen de professie van software engineering? Ik ken mensen die senior software engineer zijn bij een grote consultancy firma, maar ik zou ze nog geen VB applicatietje laten bouwen, botweg omdat je met HEAO CE en 2 cursussen niet een software engineer bent.

Meer en meer bekruipt me het gevoel hier dat een software engineer minderwaardig is aan hetgeen sommigen classificeren als 'architect'. Degene die dat beweert, wat is HUN functie trouwens? Toevallig 'architect' ?

[Verwijderd]

EfBe schreef op woensdag 21 februari 2007 @ 23:40:
Meer en meer bekruipt me het gevoel hier dat een software engineer minderwaardig is aan hetgeen sommigen classificeren als 'architect'.

En dit is volgens mij de kern van het hele verhaal. Een engineer (ingenieur in het nederlands) is iemand die hetzelfde werk doet als wat jullie aan een architect toebedelen. Een civiel ingenieur is hetzelfde als een architect, maar dan voor weg- en waterbouw (om even in de bouwwereld te blijven). Het is gewoon een functie op HBO-nivo (voor de gein nog even gekeken bij HvA en daar gebruiken ze dezelfde definitie).

Een software ingenieur kan bepaalde taken uitvoeren, zoals de software architectuur bepalen, overleg voeren met management en klanten, leiding geven, etc, maar geen regel code typen. Echter dan verandert niet opeens zijn naam omdat hij maar een deel van de taken uitvoert, waarvoor hij geleerd heeft.

Tuurlijk zijn er goede en slechte software engineers, maar om dan maar de 'goede' de naam architect te geven? Ik denk dat we eerder de mensen die niet kunnen voldoen aan de kennis en kunde van een software ingineer en andere naam moeten geven... voldoet de naam programmeur hier niet aan?

[LauPro]

EfBe schreef op woensdag 21 februari 2007 @ 23:35:
Waar roep ik dat iedereen in een project hetzelfde doet? Nergens toch? Ik zeg alleen dat een SOFTWARE ENGINEER dat allemaal moet kunnen. De een doet echter A, de ander B. that's it.

Er lopen nogal wat definities door elkaar heb ik het idee. Laten we voor de duidelijkheid even een aantal temen op een rijtje zetten:
• Software Architect
• Software Engineer
• Software Developer

In mijn optiek is een developer een programmeur. Iemand die zich alleen bezig houdt met het maken van implementaties of het oplossen van bugs. De tweede graad is dan Software Engineer, die zowel een developer is, alswel een Software Architect. Die kan een architectuur opzetten en bepaalt de scope van de developers. Wanneer er binnen een project meerdere functies zijn voor een engineer, dan kan het wenselijk zijn om 1 Software Engineer aan te stellen als Software Architect die op zijn beurt dan weer de scope aan de engineers stelt. Dit allemaal afhankelijk van de grootte van het project, bedrijfssituatie etc.

Wie er communiceert binnen een bedrijf met de klant is afhankelijk van de situatie. Ik ken bedrijven die bestaan uit 2 mensen, 1 programmeur en 1 verkoper die allebij contact hebben met de klant. De verkoper doet het klantencontact en een stukje after sales. Als de vragen dan te specifiek worden wordt er doorverwezen naar de programmeur (developer). Maar ik heb ook situaties gezien waar de programmeur zeer strikt geen contact had met de klant maar via een aparte accountmanager.

Over het algemeen worden kleine bedrijfjes groot en vindt er zeker wel een vorm van schaalvergroting plaats waar ook het duidelijk afkaderen van de verantwoordelijkheden bij hoort. (Zoals ik de wat grotere bedrijven ken.) En dan kan het best wenselijk zijn om meer nivelering te maken tussen de verschillende functies waarbij in het kader van deze distinctievere functies wel degelijk een duidelijk abstractieniveau wordt bepaald. En dan puur managenttechnisch gezien wordt er onderscheid gemaakt tussen de engineers en de architects.

Ik heb nog steeds geen antwoord trouwens op mijn vraag op WELK abstractie niveau men zich moet begeven alvorens een 'architect' te zijn volgens die personen.

Zie mijn bovenstaande betoog.

Zoals je zelf al zegt, de architect is kennelijk hoger dan de engineer, immers de architect is bij machte om de mening van de engineer te overrulen. Dat lijkt me onzin, tenzij de architect ook een engineer is.

Een architect kan uiteindelijk hetzelfde doen als een engineer of developer. Dit lijkt mij ook wel noodzakelijk omdat deze de scope moet bepalen. En dat is vrij moeilijk als je in the field geen kennis hebt.

Als dit gaat over baanbeschrijvingen dan zijn we gauw klaar, want dat is sowieso een zinloze discussie daar iedere organisatie zelf bepaalt welke random naam ze op welke stoel plakken.

Daar zou ik niet zo luchtig over doen. Natuurlijk kan iets discutabel zijn en klopt het wel eens niet. En natuurlijk doen ook veel mensen die niet die titel hebben het werk. Echter als het gaat om de verantwoordelijk dan zit het meestal heel duidelijk in elkaar, en dat is waar het om draait bij die titels.

EfBe schreef op woensdag 21 februari 2007 @ 23:40:
Sinds wanneer is je taakbeschrijving leidend voor wat je doet binnen de professie van software engineering? Ik ken mensen die senior software engineer zijn bij een grote consultancy firma, maar ik zou ze nog geen VB applicatietje laten bouwen, botweg omdat je met HEAO CE en 2 cursussen niet een software engineer bent.

Dat klopt, zie ook mijn vorige stukje. Een functieomschrijving niet natuurlijk niet geheel leidend maar binnen een project als het gaat om het zetten van verantwoordelijkheden wel.

Meer en meer bekruipt me het gevoel hier dat een software engineer minderwaardig is aan hetgeen sommigen classificeren als 'architect'. Degene die dat beweert, wat is HUN functie trouwens? Toevallig 'architect' ?

Ik voel een beetje een breuk ontstaan tussen het SE v.s. SA kamp . Zelf zou ik me niet direct willen classificeren als Software Architect. Ik ben zelfstandig ondernemer en doe vrij allround werk, ik ben me deels nog aan het oriënteren welke functie ik over een jaar of 10 wil bekleden maar alle kansen die tegen kom die pak ik. Formeel sta ik nu bij wijze van spreken wel als 'Software Architect' op papier bij een project nu, echter doe ik ook werk als developer, dit mede omdat het een relatief klein team is. Over het algemeen heb ik altijd vrij veel projecten en ben nooit echt wekenlang dedicated bezig met 1 ding, dus vandaar dat ik die verantwoordelijkheden zo belangrijk vind.

Wat leesvoer nog:
http://en.wikipedia.org/wiki/Chief_software_architect
http://en.wikipedia.org/wiki/Software_engineer
(Daar zijn ze overigens wel keihard en wordt de SA boven de SE geplaatst.)

[EfBe]

Verwijderd schreef op donderdag 22 februari 2007 @ 00:21:
[...]
En dit is volgens mij de kern van het hele verhaal. Een engineer (ingenieur in het nederlands) is iemand die hetzelfde werk doet als wat jullie aan een architect toebedelen. Een civiel ingenieur is hetzelfde als een architect, maar dan voor weg- en waterbouw (om even in de bouwwereld te blijven). Het is gewoon een functie op HBO-nivo (voor de gein nog even gekeken bij HvA en daar gebruiken ze dezelfde definitie).

(je kunt ook WO civiel ingenieur zijn overigens, dacht ik).
Inderdaad, een civiel ingenieur is ineens dezelfde persoon die bij gebouwen een architect heet. Goed voorbeeld.

Een software ingenieur kan bepaalde taken uitvoeren, zoals de software architectuur bepalen, overleg voeren met management en klanten, leiding geven, etc, maar geen regel code typen. Echter dan verandert niet opeens zijn naam omdat hij maar een deel van de taken uitvoert, waarvoor hij geleerd heeft.

Tuurlijk zijn er goede en slechte software engineers, maar om dan maar de 'goede' de naam architect te geven? Ik denk dat we eerder de mensen die niet kunnen voldoen aan de kennis en kunde van een software ingineer en andere naam moeten geven... voldoet de naam programmeur hier niet aan?

Er kleeft nog een ander nadeel aan het classificeren van 'architects' en dat is wat je ook in de bouwwereld ziet (zonder daar nou weer een metafoor van te maken): de credits voor een gebouw worden toegeschreven aan de architect.

Ik hoop nooit dat we in de software wereld ook zo diep zakken dat de credits voor een systeem worden toegeschreven aan de persoon die de stikker 'architect' op zn borst geplakt heeft gekregen. Net of die persoon het in zn eentje geklaard heeft en alle problemen die hij op zn abstracte niveau onmogelijk kon hebben gezien heeft opgelost...

LauPro schreef op donderdag 22 februari 2007 @ 01:59:
Er lopen nogal wat definities door elkaar heb ik het idee. Laten we voor de duidelijkheid even een aantal temen op een rijtje zetten:
• Software Architect
• Software Engineer
• Software Developer

In mijn optiek is een developer een programmeur. Iemand die zich alleen bezig houdt met het maken van implementaties of het oplossen van bugs. De tweede graad is dan Software Engineer, die zowel een developer is, alswel een Software Architect. De kan een architectuur opzetten en bepaalt de scope van de developers. Wanneer er binnen een project meerdere functies zijn voor een engineer, dan kan het wenselijk zijn om 1 Software Engineer aan te stellen als Software Architect die op zijn beurt dan weer de scope aan de engineers stelt. Dit allemaal afhankelijk van de grootte van het project, bedrijfssituatie etc.

Maar die classificatie werkt dan alleen binnen een project en is eigenlijk niets anders dan "X doet het ontwerp deze keer". Dit maakt X niet een architect, X blijft een software engineer.

Het punt is nl. dat je bij dit soort classificaties je tegen problemen aanloopt bij personen die bij dit soort classificaties meerdere petten dragen, of wanneer X in een ander project zich niet bezig houdt met de architectuur van het project. Die domme fout heeft MS bv gemaakt bij VS.NET 2005: er zijn verschillende SKU's, waarbij de een voor de tester is, de andere voor de developer en weer een andere voor de architect... Net of er geen personen zijn die alle 3 die taken uitvoeren, of 2 van de 3. Dit is 1 practisch voorbeeld maar er zijn er meerdere. Een andere heb ik al eerder aangegeven, waarbij er miscommunicatie plaatsvindt over de kunde en kennis van een persoon, wanneer die persoon zichzelf software engineer vindt/noemt/genoemd wordt en met een persoon praat die zich architect vindt/genoemd wordt.

Nu is die miscommunicatie er al omdat we geen standaard termen hebben anders dan software engineer en die wordt al misbruikt door bedrijven om hun eigen mensen maar op te hemelen. Alles wat die miscommunicatie kan vermijden of iig verminderen is wenselijk.

Over het algemeen worden kleine bedrijfjes groot en vindt er zeker wel een vorm van schaalvergroting plaats waar ook het duidelijk afkaderen van de verantwoordelijkheden bij hoort. (Zoals ik de wat grotere bedrijven ken.) En dan kan het best wenselijk zijn om meer nivelering te maken tussen de verschillende functies waarbij in het kader van deze distinctievere functies wel degelijk een duidelijk abstractieniveau wordt bepaald. En dan puur managenttechnisch gezien wordt er onderscheid gemaakt tussen de engineers en de architects.

Maar, die classificatie zou gemaakt moeten worden op basis van het werk wat men doet op project X. Als die classificatie doorgevoerd wordt in salariering en macht binnen projecten waar die personen aan deelnemen, waarop is dat dan gebaseerd? Op de grotere hoeveelheid kennis of iets dergelijks? Ik vermoed van niet. Immers, een software engineer die zich bezighoudt met architectuur binnen een project die doet ander werk dan een ander persoon binnen het project, maar waarom zou die persoon die zich bezighoudt met architectuur nu ineens zoveel meer kennis en kunde in huis hebben?

[...]
Daar zou ik niet zo luchtig over doen. Natuurlijk kan iets discutabel zijn en klopt het wel eens niet. En natuurlijk doen ook veel mensen die niet die titel hebben het werk. Echter als het gaat om de verantwoordelijk dan zit het meestal heel duidelijk in elkaar, en dat is waar het om draait bij die titels.

Die titels zijn alleen van nut binnen het bedrijf. Jij kunt niet communiceren dat je XYZ bent naar iemand buiten het bedrijf waar XYZ bedacht is, tenzij XYZ een algemene term is. Zoals ik al aangaf, als iemand senior software engineer is bij bedrijf A en die zegt dat tegen mij, dan heb ik daar geen reet aan, ookal is 'software engineer' een algemene term. Helaas is die niet beschermd en is er geen set regels waaraan je moet voldoen om die titel te dragen. Niet dat ik geil op titels maar het zou wel helpen in de communicatie wat iemand voor kunde en kennis in huis heeft want dat is nu echt zoek.

[...]
Ik voel een beetje een breuk ontstaan tussen het SE v.s. SA kamp . Zelf zou ik me niet direct willen classificeren als Software Architect. Ik ben zelfstandig ondernemer en doe vrij allround werk, ik ben me deels nog aan het oriënteren welke functie ik over een jaar of 10 wil bekleden maar alle kansen die tegen kom die pak ik. Formeel sta ik nu bij wijze van spreken wel als 'Software Architect' op papier bij een project nu, echter doe ik ook werk als developer, dit mede omdat het een relatief klein team is. Over het algemeen heb ik altijd vrij veel projecten en ben nooit echt wekenlang dedicated bezig met 1 ding, dus vandaar dat ik die verantwoordelijkheden zo belangrijk vind.

Je voelt nu toch dat het wrikt? Die taak die je hebt bij dit project is architectuur EN development, dat is toch gewoon software engineering, dan kun je er wel een stikker op plakken 'ik ben architect', maar dat zegt dan toch niks?

Wat dat aangaat voel ik me dan meer verbonden met de term die Eric Sink ooit introduceerde: "Software Craftsman", aangezien ik ook met meerdere petten op zit (alle petten eigenlijk, alleen geen 1e lijns support )

Wat leesvoer nog:
http://en.wikipedia.org/wiki/Chief_software_architect
http://en.wikipedia.org/wiki/Software_engineer
(Daar zijn ze overigens wel keihard en wordt de SA boven de SE geplaatst.)

Tja, ze doen maar. Hoe meer classificaties, hoe minder duidelijk het wordt, want de mensen die meerdere petten op hebben vallen buiten deze classificaties en wat dan? Want zijn deze classificaties niet gewoon bedoeld voor het afbakenen van groepen mensen binnen de software engineering wereld welke meer en minder kennis/kunde hebben?

[ Voor 60% gewijzigd door EfBe op 22-02-2007 08:46 ]

[LauPro]

EfBe schreef op donderdag 22 februari 2007 @ 08:20:
Er kleeft nog een ander nadeel aan het classificeren van 'architects' en dat is wat je ook in de bouwwereld ziet (zonder daar nou weer een metafoor van te maken): de credits voor een gebouw worden toegeschreven aan de architect.

Ik hoop nooit dat we in de software wereld ook zo diep zakken dat de credits voor een systeem worden toegeschreven aan de persoon die de stikker 'architect' op zn borst geplakt heeft gekregen. Net of die persoon het in zn eentje geklaard heeft en alle problemen die hij op zn abstracte niveau onmogelijk kon hebben gezien heeft opgelost...

Dat is toch een hele andere discussie? Per definitie worden mensen die kop uit steken bij succes goed beloond. Als een bouwkundig architect iets heeft ontworpen dan gaat dat niet even over een schetsje dat ze op een zondagmiddag maken en daarnaast snap iedereen wel - als je doorvraagt - dat die mensen op de werkvloer die daar 2 jaar mee bezig zijn geweest ook veel werk hebben verzet.

Ik krijg bijna het idee dat je een beetje verbitterd bent over je huidige functie en dat je eigenlijk hogerop wil? Het staat je vrij om bij een ander of voor jezelf te gaan werken lijkt me.

[F_J_K]

EfBe schreef op woensdag 21 februari 2007 @ 23:35:
En nu mag dat groepje roepen wat het wil dat het op gelijke hoogte staat als de mensen die B doen, maar dat is niet zo, althans niet qua salariering of macht binnen een project. En dat is nou NET wat er mis is aan dit hele geneuzel.

Nogmaals: niemand hier heeft het over geld of macht, wel over breedte van kennis (van technologien en de bestaande en toekomstige situaties). En dat betekent automatisch dat je op bepaalde gebieden inderdaad de manier van de architect zou moeten volgen.

Niet metaforen gebruiken, die gaan mank.
De architect is niet de spreekbuis, want wie ontwerpt dan de software? Ook de architect? Wie communiceert dan hetgeen de architect met de klant heeft gecommuniceerd naar de software engineers (in jullie kader dan) ? Ook de architect? En de software engineers praten an sig niet met anderen?

Praten <> beslissen. En soms moet een van de mensen iets slikken dat vele meer geld en moeite kost en zelfs een slechter prograsmma oplevert. Voorbeeld: er is bijv. een centraal klantenbestand die alleen ontsloten is via een bepaald wsdl'etje en Oracle is de enige database die de DBA's kennen. Dan moet er iemand in de organisatie zijn die afspreekt dat jouw team geen eigen klantgegevens opslaat maar via webservices gebruikt en muteert en dat je geen MySQL gebruikt. Ook als dat je eigen werkzaamheden bemoeilijkt. Immers zijn er in een beetje organisatie nogal eens honderden applicaties en tientallen "ERP-achtige" apps met bijbehorende gegevensbanken. En als dat niet genoeg is, moet je in overleg de standaardset zien uit te breiden. Maar als iedereen in zijn eigen clubje zelf technieken en informatiestructuren verzint wordt het een chaos waar afdeling X niet weet wat afdeling Y doet. Binnen grote ontwikkeltrajecten heb je iets dergelijks intern.
Nogmaals: kan best dezelfde persoon zijn, als deze heel goed zijn eigen belang kan scheiden van dat van de organisatie nu en over 3 jaar.

Inderdaad zie ik geen rol achter toetsenbord voor een architect binnen een ontwikkeltraject dat meer is dan een paar dozijn randvoorwaarden en aandachtspunten noemen en bewaken. De rest is niet met een architectenpet op (maar bijv. engineer).

Zoals je zelf al zegt, de architect is kennelijk hoger dan de engineer, immers de architect is bij machte om de mening van de engineer te overrulen. Dat lijkt me onzin, tenzij de architect ook een engineer is.

Die redenering snap ik niet. %Ik% mag niet overrulen op zaken die jouw eigen (bijna altijd relatief kleine) project overstijgen, omdat %ik% geen engineer ben? Dus mogen klant en de directeur van je bedrijf het dan ook niet?

Als iemand die ook software engineer is een dag in de week een overkoepelende pet opzet: prima. Maar dat verandeert toch niets aan het feit dat het een andere rol is?

En hoe dan ook heb je altijd mensen die op bepaalde gebieden je overrulen. Je kan de klant niet zomaar dicteren dat er een paar extra mensen in dienst genomen moeten worden en de mensen van financien lachen je uit als je om veel meer geld vraagt dan je in je budget hebt.

Dit gaat over algemene termen. Persoon A komt persoon B tegen. A vraagt aan B wat B doet. B zegt "Ik ben architect", en A weet dan wat B doet.

[....]

Kom dan niet aan met 'op dit abstractieniveau heb je een architect nodig' want dan snap je niet wat software engineering inhoudt. Voor de mensen die dat inderdaad niet weten: software engineering is niet gelijk aan code kloppen.

Als je een willekeurig persoon zegt software engineer te zijn, hebben ze geen idee waar je het over hebt. Je bent programmeur.
En met een architectenpet opzitten is niet gelijk aan software engineering. Om even jouw woorden te gebruiken:
"Waar roep ik dat iedereen in een project hetzelfde doet? Nergens toch? Ik zeg alleen dat een programmeur dat allemaal moet kunnen. De een doet echter A, de ander B. that's it. "
"Ikzelf zie me als programmeur, want ik ontwerp en bouw software. Dat is nl. de taak van een programmeur. Nu kan een software engineer daar anders over denken, maar dat is dan zijn/haar probleem". (Voor een willekeurige ik: ik ben o.a. analist, sinds 1998 geen programmeur).

Trouwens helemaal eens met LauPro in "De grens tussen Architect & Designer"

edit:

Trouwens meen ik het programmeur <> SE niet helemaal, maar ik zie het hetzelfde als SE <> SA

En inderdaad wordt er nogal eens veel te veel gepatst en/of gesmeten met termen als architect(uur).

[ Voor 3% gewijzigd door F_J_K op 22-02-2007 15:18 ]

[EfBe]

LauPro schreef op donderdag 22 februari 2007 @ 08:28:
[...]
Dat is toch een hele andere discussie? Per definitie worden mensen die kop uit steken bij succes goed beloond. Als een bouwkundig architect iets heeft ontworpen dan gaat dat niet even over een schetsje dat ze op een zondagmiddag maken en daarnaast snap iedereen wel - als je doorvraagt - dat die mensen op de werkvloer die daar 2 jaar mee bezig zijn geweest ook veel werk hebben verzet.

Ik krijg bijna het idee dat je een beetje verbitterd bent over je huidige functie en dat je eigenlijk hogerop wil? Het staat je vrij om bij een ander of voor jezelf te gaan werken lijkt me.

Err, ik ben al 10 jaar ondernemer, LauPro, en o.a. de architect (en developer) van een van de meest gebruikte o/r mappers voor .NET ter wereld, om maar in jouw jargon te blijven . Het is niet een kwestie van hogerop, het is een kwestie van de introductie van titels die IMPLICEREN dat je meer kunt dan een ander met een andere titel terwijl DIE pesoon met de titel die die persoon heeft hetzelfde werk OOK kan, m.a.w. er wordt een hierarchie geschapen die er helemaal niet is, want qua kennis is die hierarchie niet aanwezig.

Ik ben helemaal niet verbitterd omtrent mijn functie, waarom zou ik? Waar ik me mateloos aan erger is dat ik mensen zie die zich architect noemen en zich bv boven mensen plaatsen die software engineer zijn, terwijl die hierarchie nergens op gebaseerd is.

[MicroWhale]

EfBe schreef op donderdag 22 februari 2007 @ 08:51:
Ik ben helemaal niet verbitterd omtrent mijn functie, waarom zou ik? Waar ik me mateloos aan erger is dat ik mensen zie die zich architect noemen en zich bv boven mensen plaatsen die software engineer zijn, terwijl die hierarchie nergens op gebaseerd is.

Daar ben ik het met je eens.

Waar ik het niet met je eens bent is dat als er takenpakketten A, B en C zijn... (ja, ik blijf wollig ) te verdelen over twee mensen dat jij zegt dat beide mensen alle 3 de takenpakketten goed moeten beheersen, terwijl ik denk dat het beter is dat het onderscheid maakt tussen iemand die A+B uitvoert en iemand die B+C uitvoert. Vooral als je weet dat het een aantal jaar duurt voordat je een takenpakket goed onder de knie hebt.

Is het dan niet beter om onderscheid te maken tussen de mensen die A+B goed beheersen, maar C alleen globaal en de mensen die B+C goed beheersen, maar A alleen globaal?

(hierbij is B de overlap, kunnen ze allebei goed, bijv. ontwerpen en A en C zijn de wat meer functiespecifieke delen bijv.
A - Diepgaande kennis van bedrijfs- en informatiestructuren, communicatie, vergader- en onderhandel technieken, presenteren,
C - Coderen.)

[Verwijderd]

MrWilliams schreef op donderdag 22 februari 2007 @ 13:15:
[...]
Is het dan niet beter om onderscheid te maken tussen de mensen die A+B goed beheersen, maar C alleen globaal en de mensen die B+C goed beheersen, maar A alleen globaal?

Dan zijn het nog steeds 2 software engineers, maar met verschillende specialiteiten. Je bedoelt hiermee dat een SA eigenlijk een Senior SE is, gespecialiseerd op bijv. het communicatieve vlak? Zo komt het op mij in ieder geval over. Maar het blijven toch echt 2 SE's lijkt me?

[EfBe]

Verwijderd schreef op donderdag 22 februari 2007 @ 14:21:
[...]

Dan zijn het nog steeds 2 software engineers, maar met verschillende specialiteiten. Je bedoelt hiermee dat een SA eigenlijk een Senior SE is, gespecialiseerd op bijv. het communicatieve vlak? Zo komt het op mij in ieder geval over. Maar het blijven toch echt 2 SE's lijkt me?

Precies!

[mulder]

EfBe schreef op donderdag 22 februari 2007 @ 14:51:
[...]

Precies!

1)

C#:

se = new SoftwareEngineer()
sa = new SoftwareArchitect()

of
2)

C#:

se = new SoftwareEngineer()
se.Type = EngineerType.Engineer
sa = new SoftwareEngineer()
sa.Type = EngineerType.Architect

Ik ga voor 1

[RedRose]

Don Facundo schreef op donderdag 22 februari 2007 @ 15:11:
[...]

1)

C#:

se = new SoftwareEngineer()
sa = new SoftwareArchitect()

of
2)

C#:

se = new SoftwareEngineer()
se.Type = EngineerType.Engineer
sa = new SoftwareEngineer()
sa.Type = EngineerType.Architect

Ik ga voor 1

C#:

se = new SoftwareEngineer();
se.setTask(Tasks.ARCHITECTURE);
se.run();

[mulder]

RedRose schreef op donderdag 22 februari 2007 @ 15:23:
[...]

C#:

se = new SoftwareEngineer();
se.setTask(Tasks.ARCHITECTURE);
se.run();

Dan zou je dus gewoon een Employee class kunnen maken waar je taken in stopt. Zoiets als: se.SetTasks(SoftwareArchitect.GetAllTasks())

Meer ontopic: volgens mij stuurt een architect gewoon engineers aan en niet andersom, is een architect adviserend naar managment en naar de engineers, maakt een architect beslissingen, maakt de architect zich druk om het grote plaatje en staat in de hierarchie gewoon boven de SE en is dit ook gewoon wenselijk.

Ik geef EfBe gelijk dat er beunen rondlopen die gewoon architect op hun kaartje zetten en zo slapend rijk worden, en tegelijk denk ik daarbij dat EfBe in het dagelijks leven met zo'n figuur te maken heeft gehad en daar z'n oordeel op baseert

[MicroWhale]

Ik vermoed dat het bedrijfsleven daar om een of andere reden een ander naampje aan wil hangen... wellicht om onderscheid te maken tussen wat persoon A en B doen. Maar pin me er niet op vast.

Bij mijn nieuwe werkgever krijg ik een heel ander naampje als dat ik nu heb, terwijl ik feitelijk hetzelfde blijf doen. Als zij dat naampje eraan willen geven om iets duidelijk te maken, prima toch?

Bovendien krijg je als je de functie Software Engineer uniform maakt, een groot aantal sub-rollen of -functies. Wat feitelijk op hetzelfde neer komt als de huidige naamgeving. Bovendien lijkt het me fijner om te zeggen dat je een "Information Analist" ben dan een "Software Engineer specialized in Information Analysis". Fijn voor op je visitekaartje.

Ik vermoed dat men meer moeite heeft met mensen die het hoog in hun bol hebben, dan het naamkaartje wat er aan hangt.

[RedRose]

Don Facundo schreef op donderdag 22 februari 2007 @ 15:38:
[...]
Dan zou je dus gewoon een Employee class kunnen maken waar je taken in stopt. Zoiets als: se.SetTasks(SoftwareArchitect.GetAllTasks())

Dat was niet het punt.. Het punt was dat 'architectuur'-ontwerp onder software engineering valt.

MrWilliams schreef op donderdag 22 februari 2007 @ 15:55:
Ik vermoed dat het bedrijfsleven daar om een of andere reden een ander naampje aan wil hangen... wellicht om onderscheid te maken tussen wat persoon A en B doen. Maar pin me er niet op vast.

Bij mijn nieuwe werkgever krijg ik een heel ander naampje als dat ik nu heb, terwijl ik feitelijk hetzelfde blijf doen. Als zij dat naampje eraan willen geven om iets duidelijk te maken, prima toch?

Bovendien krijg je als je de functie Software Engineer uniform maakt, een groot aantal sub-rollen of -functies. Wat feitelijk op hetzelfde neer komt als de huidige naamgeving. Bovendien lijkt het me fijner om te zeggen dat je een "Information Analist" ben dan een "Software Engineer specialized in Information Analysis". Fijn voor op je visitekaartje.

Ik vermoed dat men meer moeite heeft met mensen die het hoog in hun bol hebben, dan het naamkaartje wat er aan hangt.

Dat denk ik ook. Dat is dus precies de reden dat competenties van mensen niet makkelijk in een titel te verpakken zijn. Iemand die goed kan communiceren met het management, maar eigenlijk programmeur is, zal indien daar geen beter geschikt persoon voor is de communicatie naar het management verzorgen. Ik ben ook geen projectmanager omdat ik vaak mijn deadlines haal en goed kan plannen. Juist om die reden bestaat volgens mij ook het C.V., waarin je uitgebreider je ervaring en competenties kan uitlichten.

Ik denk ook dat het gebruiken van de genoemde termen te veel met elkaar samenhangende werkzaamheden binnen de software engineering van elkaar scheidt, waardoor je jezelf juist beperkt in de kennis die een software-engineer zou moeten hebben.

[ Voor 70% gewijzigd door RedRose op 22-02-2007 16:06 ]

[LauPro]

EfBe schreef op donderdag 22 februari 2007 @ 08:20:
Maar die classificatie werkt dan alleen binnen een project en is eigenlijk niets anders dan "X doet het ontwerp deze keer". Dit maakt X niet een architect, X blijft een software engineer.

Het punt is nl. dat je bij dit soort classificaties je tegen problemen aanloopt bij personen die bij dit soort classificaties meerdere petten dragen, of wanneer X in een ander project zich niet bezig houdt met de architectuur van het project. Die domme fout heeft MS bv gemaakt bij VS.NET 2005: er zijn verschillende SKU's, waarbij de een voor de tester is, de andere voor de developer en weer een andere voor de architect... Net of er geen personen zijn die alle 3 die taken uitvoeren, of 2 van de 3. Dit is 1 practisch voorbeeld maar er zijn er meerdere. Een andere heb ik al eerder aangegeven, waarbij er miscommunicatie plaatsvindt over de kunde en kennis van een persoon, wanneer die persoon zichzelf software engineer vindt/noemt/genoemd wordt en met een persoon praat die zich architect vindt/genoemd wordt.

Het is niet alleen een classificatie! Het is een verantwoordelijkheid, dat is iets heel anders. En over het algemeen als iemand meer verantwoordelijkheid heeft, staat hij 'boven' de rest. En ik denk dat de SA vrijwel altijd een grote verantwoordelijkheid heeft binnen een project. Je hebt verder (SKU's) over een specifieke implementatie. Misschien voor jouw bedrijfssituatie volledige overkill, maar dat het bij Microsoft intern wel perfect werkt. Daarbij gaat het er helemaal niet om wat iemand 'vind' het gaat erom welke functie die bekleed.

Nu is die miscommunicatie er al omdat we geen standaard termen hebben anders dan software engineer en die wordt al misbruikt door bedrijven om hun eigen mensen maar op te hemelen. Alles wat die miscommunicatie kan vermijden of iig verminderen is wenselijk.

Ik zou zeggen hou die functies zoals omgeschreven op wikipdia aan, dit zijn redelijk internationale standaarden. Laatst had ik een document gevonden van iemand die erop was gepromoveerd (+/- 160 pagina's) waar deze verhoudingen en arbeidsprocessen haarfijn werden uitgelegd.

Maar, die classificatie zou gemaakt moeten worden op basis van het werk wat men doet op project X. Als die classificatie doorgevoerd wordt in salariering en macht binnen projecten waar die personen aan deelnemen, waarop is dat dan gebaseerd? Op de grotere hoeveelheid kennis of iets dergelijks? Ik vermoed van niet. Immers, een software engineer die zich bezighoudt met architectuur binnen een project die doet ander werk dan een ander persoon binnen het project, maar waarom zou die persoon die zich bezighoudt met architectuur nu ineens zoveel meer kennis en kunde in huis hebben?

Als hij eenmalig bij een project wordt aangesteld niet. Misschien binnen het specifieke domein van dat project. Als hij vast die functie bekleed, dan is dat wel zeker aan de orde.

Die titels zijn alleen van nut binnen het bedrijf. Jij kunt niet communiceren dat je XYZ bent naar iemand buiten het bedrijf waar XYZ bedacht is, tenzij XYZ een algemene term is. Zoals ik al aangaf, als iemand senior software engineer is bij bedrijf A en die zegt dat tegen mij, dan heb ik daar geen reet aan, ookal is 'software engineer' een algemene term. Helaas is die niet beschermd en is er geen set regels waaraan je moet voldoen om die titel te dragen. Niet dat ik geil op titels maar het zou wel helpen in de communicatie wat iemand voor kunde en kennis in huis heeft want dat is nu echt zoek.

Er zijn in het algemeen vrij weinig absolute termen. En mensen beoordelen op wat er op hun visitekaartje staat lijkt me ook geen goede ontwikkeling. Zo te horen ben je op zoek naar een uniform model voor benamingen van functies binnen softwareontwikkeling. Denk niet dat je die gaat vinden persoonlijk.

Je voelt nu toch dat het wrikt? Die taak die je hebt bij dit project is architectuur EN development, dat is toch gewoon software engineering, dan kun je er wel een stikker op plakken 'ik ben architect', maar dat zegt dan toch niks?

Het wrikt, maar wel op een andere reden. Ik doe meer dan alleen softwareontwikkeling, dus mezelf kwalificeren als 'Architect' vind ik te hoog gegrepen persoon.

Wat dat aangaat voel ik me dan meer verbonden met de term die Eric Sink ooit introduceerde: "Software Craftsman", aangezien ik ook met meerdere petten op zit (alle petten eigenlijk, alleen geen 1e lijns support )

Mja, het is leuk als je zo breed inzetbaar bent maar een beetje duidelijkheid waar je je primair op richt kan geen kwaad.

Tja, ze doen maar. Hoe meer classificaties, hoe minder duidelijk het wordt, want de mensen die meerdere petten op hebben vallen buiten deze classificaties en wat dan? Want zijn deze classificaties niet gewoon bedoeld voor het afbakenen van groepen mensen binnen de software engineering wereld welke meer en minder kennis/kunde hebben?

Deels, het dient als doel om inzichtelijk te krijgen welke functies mensen bekleden. je kan wel heel simpel stellen van 'ik maak software als beroep'. Maar dat geeft totaal geen beeld welk deel van de ketting en welke verantwoordelijkheid je draagt.

[Verwijderd]

Op m'n visitekaartje staat 'senior software architect', maar dat is een foutje van de drukker: had 'senior software engineer' moeten zijn. Maar in feite boeit me dat nauwelijks. Door m'n ervaring en kennis van zowel de markt als de gebruikte ontwikkelomgevingen, etc. ben ik vaak de eerste aangewezen persoon om het stramien te bepalen en m'n collega's te instrueren en begeleiden, maar dat maakt me niks beter of hoger dan hen.

Je hebt doodsimpel samen een klus te klaren, en dat gaat het best door goed gebruik te maken van de kwaliteiten van de mensen in het team. Daar hoeft geen enkele vorm van hierarchie in te zitten, sterker nog: als die er wel zou zijn zou ik me er niet prettig in voelen en uiteindelijk minder presteren, ondanks 't 'senior software architect' titeltje op m'n naamkaartje.

EfBe, ik denk dat ik me in jouw ontwikkelteam prima op m'n plek zou voelen, ware het niet dat ik al in een soortgelijk team zit...

[Scare360]

Bij ons is dit iemand die in “business” en “informatie” denkt, dus iemand die requirements in de vorm van business, informatie, governance etc weet te vertalen naar horizontale oplossingen. Dit is iemand met gedegen domeinkennis en flink wat ervaring in dit domein. De architect verantwoord de oplossing richting stakeholders waaronder de CEO/CTO en lijnmanagement, daarnaast ondersteund hij programmanagement bij het definiëren van projecten. Uiteindelijk werkt hij de startarchitectuur uit voor project(en) en dwingt deze af over de lifecycle van het project/systeem in een controlerende rol. Dit door bijvoorbeeld proof-of-concepts te maken en te onderwijzen in ontwikkelteams en hands-on te coachen indien nodig.

De softwarearchitect (iemand die wij overigens gewoon software engineer noemen) maakt mbv de startarchitectuur een software architectuur document waarin hij op verschillende manieren naar het (deel)systeem kijkt (conceptueel, processen, logisch, physiek, deployment, infrastructuur etc). Uiteindelijk werkt hij de verticale oplossing uit in layers, componenten, packages en de implementatie daarvan. Samen met de software designers kom je dan tot stories, use case model, use cases, use case realizations, class diagrams, package diagrams, component diagrams etc.

[ Voor 4% gewijzigd door Scare360 op 22-02-2007 23:38 ]

[Verwijderd]

Met alle respect, maar dat lijkt me een omgeving waar ik als toch wel een tikkie creatieve ontwikkelaar nooit zou willen werken. Klinkt net zo erg als Origin's "ontwikkelstraat"...

[mulder]

Verwijderd schreef op vrijdag 23 februari 2007 @ 00:09:
Met alle respect, maar dat lijkt me een omgeving waar ik als toch wel een tikkie creatieve ontwikkelaar nooit zou willen werken. Klinkt net zo erg als Origin's "ontwikkelstraat"...

Waarom niet? Het is ontwikkelstraat, geen ontwikkelfabriek, wie zegt dat je hierin niet creatief kunt zijn, bovendien is het mijn ogen wel wat proffessioneler.

[EfBe]

LauPro schreef op donderdag 22 februari 2007 @ 18:06:
[...]
Het is niet alleen een classificatie! Het is een verantwoordelijkheid, dat is iets heel anders. En over het algemeen als iemand meer verantwoordelijkheid heeft, staat hij 'boven' de rest.

Dat heb je mij ook niet horen ontkennen. Het punt is alleen: maak je er een aparte tak van sport van en zo ja, HOE word je dan lid van die club, is er een referentiekader? Ik vind dat te onduidelijk, waardoor je dus de wildgroei krijgt die je ook om je heen ziet waarbij iedere laml*l met 2 maanden LOI wordperfect achter de knopen een software engineer genoemd wordt door de manager om de persoon in kwestie maar weg te kunnen zetten bij klanten (die ik in die context eerder als slachtoffers zou willen omschrijven).

En ik denk dat de SA vrijwel altijd een grote verantwoordelijkheid heeft binnen een project. Je hebt verder (SKU's) over een specifieke implementatie. Misschien voor jouw bedrijfssituatie volledige overkill, maar dat het bij Microsoft intern wel perfect werkt. Daarbij gaat het er helemaal niet om wat iemand 'vind' het gaat erom welke functie die bekleed.

Het gaat om algemeen erkende termen, zodat men weet waarover men praat. Als iemand zegt "Ik ben chirurg" dan weet je wat die persoon doet. Als iemand zegt "Ik ben software engineer" dan is dat tegenwoordig al verwaterd en de term "Software Architect" helemaal.

Die verloedering moet stoppen. Het ergert me al jaren en iedere keer dat ik er iets aan kan doen, hoe klein ook zal ik het niet nalaten.

[...]
Ik zou zeggen hou die functies zoals omgeschreven op wikipdia aan, dit zijn redelijk internationale standaarden. Laatst had ik een document gevonden van iemand die erop was gepromoveerd (+/- 160 pagina's) waar deze verhoudingen en arbeidsprocessen haarfijn werden uitgelegd.

Dat zal best, maar daarom ben ik het er nog niet mee eens.

[...]
Er zijn in het algemeen vrij weinig absolute termen. En mensen beoordelen op wat er op hun visitekaartje staat lijkt me ook geen goede ontwikkeling. Zo te horen ben je op zoek naar een uniform model voor benamingen van functies binnen softwareontwikkeling. Denk niet dat je die gaat vinden persoonlijk.

Waarom niet? Binnen allerlei andere vakgebieden is dit al jaren gemeengoed omdat men daar al jaren geleden doorhad dat je geen wildgroei van termen moet hebben. Zo is een jaar geleden (kan iets langer geleden zijn) bv de term 'plastisch chirurg' beschermd en is dit de term voor artsen die zaken herstellen, dus niet de schumachers die 60 jarige tieten opnieuw de zon laten zien, die heten cosmetisch chirurg.

Dan duurt het nog wel een aantal jaren voordat die termen gemeengoed zijn, maar OMDAT die termen er zijn, is het OOK duidelijk wat je moet kunnen, doen en kennen om die titel te krijgen. Dat is nu in onze branch compleet random en onduidelijk. Het is niet dat ik titels wil, ik gebruik mn ing. /b.sc. titel nooit, maar ik wil duidelijkheid, zodat ik weet wanneer ik met iemand praat dat die persoon een zeker niveau kent en niet maar wat klepel-klok verhalen ophangt waar ik mn tijd dus mee verdoe.

Het wrikt, maar wel op een andere reden. Ik doe meer dan alleen softwareontwikkeling, dus mezelf kwalificeren als 'Architect' vind ik te hoog gegrepen persoon.

Even spiekend in jouw profile alhier, en ervan uitgaand dat dat correct is, lijkt me dat inderdaad ook, mits er uberhaupt consensus bestaat over de term 'architect' en dat is IMHO al niet zo.

Mja, het is leuk als je zo breed inzetbaar bent maar een beetje duidelijkheid waar je je primair op richt kan geen kwaad.

Het gaat niet over breed inzetbaar vs. specialisme, het gaat over duidelijkheid over welke eisen behoren bij een zekere titel zodat communicatie makkelijker wordt. Als iemand zich nu software architect noemt maar nog nooit van informatieanalyse gehoord heeft, dan is die persoon voor mij althans een ouwehoer die beter printers kan gaan bijvullen. Daar gaat het om: als iemand zich architect noemt bij vastgestelde termen dan weet de gesprekspartner dat die persoon DUS informatieanalyse beheerst of althans daar dermate veel kennis van heeft dat met een uurtje details opsnuiven daar mee gewerkt kan worden.

Deels, het dient als doel om inzichtelijk te krijgen welke functies mensen bekleden. je kan wel heel simpel stellen van 'ik maak software als beroep'. Maar dat geeft totaal geen beeld welk deel van de ketting en welke verantwoordelijkheid je draagt.

Welke verantwoordelijkheid je draagt is toch volledig niet relevant? Immers dat is gerelateerd aan de organisatie, niet aan je vakinhoudelijke bezigheden. Je kunt nl. ook een projectleider boven je hebben of meerdere projectleiders die de verantwoordelijkheid van je wegnemen en jou meer ruimte geven. Het hebben van erg veel verantwoordelijkheid kan ook erg remmend werken nl. Een van de redenen waarom creatievelingen bij reclamebureaus niet de verantwoordelijkheid dragen voor het slagen van een campagne, terwijl ze wel de de doorslaggevende factor zijn hoe de campagne eruit gaat zien.

[EfBe]

Don Facundo schreef op vrijdag 23 februari 2007 @ 08:53:
[...]
Waarom niet? Het is ontwikkelstraat, geen ontwikkelfabriek, wie zegt dat je hierin niet creatief kunt zijn, bovendien is het mijn ogen wel wat proffessioneler.

offtopic:
schrijf 'professioneler' het dan ook in ieder geval correct

Ontwikkelstraat is ook zo'n term die erg vaak wordt geoverload. Het idee is dat je met onderdelen 'van de plank' en methodieken die gestandaardiseerd zijn en DUS getest, sneller en betere kwaliteit software kunt maken. Creatief zijn kan dan IMHO alleen binnen de strakke kaders van de ontwikkelstraat, immers zelf gaan knutselen zorgt ervoor dat het hele idee van de straat teniet gedaan wordt, je gaat immers met non-standaard spullen software maken.

[MicroWhale]

EfBe schreef op vrijdag 23 februari 2007 @ 09:08:
[...]

Dat heb je mij ook niet horen ontkennen. Het punt is alleen: maak je er een aparte tak van sport van en zo ja, HOE word je dan lid van die club, is er een referentiekader? Ik vind dat te onduidelijk, waardoor je dus de wildgroei krijgt die je ook om je heen ziet waarbij iedere laml*l met 2 maanden LOI wordperfect achter de knopen een software engineer genoemd wordt door de manager om de persoon in kwestie maar weg te kunnen zetten bij klanten (die ik eerder als slachtoffers zou willen omschrijven).

Dat is een manco van de manager in kwestie, niet van de persoon die een LOI cursus WordPerfect heeft gedaan.

[Verwijderd]

Don Facundo schreef op vrijdag 23 februari 2007 @ 08:53:
Waarom niet? Het is ontwikkelstraat, geen ontwikkelfabriek, wie zegt dat je hierin niet creatief kunt zijn, bovendien is het mijn ogen wel wat proffessioneler.

Creatief zijn binnen een keurslijf van standaarden is niet mijn ambitie. Zoals EfBe al zei, als je buiten die grenzen treedt, valt de straat uit elkaar.
Bovendien vind ik 't feit dat iedereen binnen die straat niet alleen z'n eigen expertise heeft maar zich ook bij die expertise moet houden nogal benauwend. Ik ben bv. nogal goed in de business logic en data access layers van onze applicaties, maar op het moment dat ik niet ook een bijbehorende user interface en grafische presentatie (mee) zou kunnen ontwikkelen/ontwerpen gaat voor mij de lol er gauw af.

Waarom een ontwikkelstraat professioneler zou zijn dan een klein team dat gezamenlijk een project aanpakt en waarbij ieder z'n specialiteiten heeft maar niemand wordt beperkt tot die specialiteiten ontgaat me overigens volkomen.

[Verwijderd]

Hallo,

Ik volg deze topic al een tijdje en ik dacht ik geef even mijn gedachten hierover.

Allereerst wil ik zeggen dat ik er absoluut mee eens ben dat tegenwoordig de termen “architect” en “architectuur” gebruikt worden zonder er bij stil te staan wat deze termen nou eigenlijk betekenen. Het lijkt alsof mensen belangrijker worden wanneer ze worden beschouwd als architect (software-architect, business architect, etc.) van iets.

Laat ik het volgende duidelijk maken: Ontwerpers ontwerpen. Het resultaat hiervan is een ontwerp. Belangrijk hierbij is dat het helemaal NIETS uitmaakt op welk abstractie niveau dit gebeurt. Een ontwerp beschrijft wat er uiteindelijk gerealiseerd moet worden. Dit geldt zowel op software-niveau (ontwerp voor een applicatie) als op proces-niveau (procesmodellen) en zelfs op business niveau (business model).

Ik neem aan dat velen van jullie zelf een keer een ontwerp van iets hebben gemaakt (van een applicatie, of misschien een schets van een stoel of een auto). Dan hebben jullie waarschijnlijk ook te maken gehad met de enorme vrijheden die een ontwerper geniet. In een omgeving waar meerdere ontwerpers met elkaar moeten samenwerken levert dit geheid problemen op. (Zoals MrWilliams hierboven het mooi verwoord boven z’n avatar: “The problem is choice”)

Hier is waar architectuur een rol speelt: architectuur is een beperking van deze ontwerpvrijheid.
De vrijheden van een ontwerper moeten zodanig beperkt worden dat ontwerpers gegarandeerd kunnen worden dat hun ontwerpen consistent zijn met het groter geheel. Deze beperkingen zorgen er tevens voor dat ontwerpers hun energie kunnen steken in de issues waar hun creativiteit van pas komt.

In de praktijk komt architectuur neer op een verzameling principes die voorschijven hoe iets gerealiseerd moet worden itt een ontwerp die beschrijft wat er gerealiseerd moet worden. Wat je vaak ziet gebeuren is dat als je iets ontwerpt, dan ga je je eigen principes (impliciet) gebruiken (stoelen moeten altijd comfortabel zitten, toch? Of misschien niet?). Deze principes komen van bronnen als je opleiding, ervaring, best practices van anderen, cultuur, etc.

De bedoeling van architectuur is om de principes die door ontwerpers worden gebruikt expliciet te maken zodat men hierover overeenstemming kan bereiken (met de neuzen dezelfde richting op). Hieruit kan je opmaken dat de rol van een architect FUNDAMENTEEL anders is dan die van een ontwerper.

Merk op dat ik het heb over rollen en niet functies. Iemand zou best zowel de rol van ontwerper als de rol van architect op zich nemen. In sommige situaties is het zelfs gewenst dat iemand die veel ervaring heeft met het ontwerpen de rol van architect op zich neemt.