Overleg:Enterprisearchitectuur

Wat staat hier?

Als eerste zin stel ik voor:

..met het in samenhang ontwerpen van de een organisatie. in al haar aspecten.

want wat zou het anders moeten zijn, een onsamenhangend ontwerp dat slechts betrekking heeft op een deel van alle aspecten?

daarna

Enterprise-architectuur biedt organisaties een kader voor veranderen, neergeslagen in een samenhangende en consistente beschrijving van de gewenste situatie op hoofdlijnen. Deze beschrijving biedt harde en zachte grenzen die de ontwerpruimte op lagere niveaus zodanig in probeert te perken dat de veranderingen in lijn zijn met de doelstellingen van de organisatie als geheel. Enterprise-architectuur geeft daarmee richting en biedt concrete handvatten voor het toetsen van veranderingen. Enterprise-architectuur wordt dan ook vaak gezien als een belangrijk stuurinstrument.

want is nietszeggend, bovendien begon het met ontwerpen, waarmee de term 'architectuur' verklaard wordt, (maar niet gerechtvaardigd), één zin later gaat het ineens om 'een kader voor veranderingen', aan het einde is het een stuurinstrument, wat is het nou? Is het wel iets? Enterprise-architectuur zou voor een consistente beschrijving moeten zorgen, maar alleen maar in hoofdlijnen, en dan ook nog met harde en zachte grenzen die de ontwerpruimte op lagere niveaus probeert in te perken om, ja wat eigenlijk? Ik kan hier helemaal niets van maken, de tweede alinea maar helemaal doorhalen lijkt me. Verderop zie ik alleen maar meer van hetzelfde, als het al iets is, is de uitleg volkomen onbegrijpelijk. Wat denken anderen ervan? Groet, Vier Tildes 19 nov 2009 21:50 (CET)

Suggestie 1 is aangepast. T.a.v. 2 staat hier nu:

"Enterprise-architectuur biedt met haar ontwerp van de gewenste situatie voor organisaties een kader voor veranderen. Het omschreven ontwerp begrenst ruimtes op lager niveau zodat de veranderingen in lijn zijn met de doelstellingen van de organisatie. Enterprise-architectuur geeft dus richting en biedt handvatten voor het toetsen van veranderingen. Enterprise-architectuur wordt dan ook vaak gezien als een sturingsmiddel om veranderingen door te voeren."

Jip en Janneke-taal blijft verder (nog meer) gewenst. --Theo Oppewal 20 nov 2009 01:56 (CET)

Dank je, zo is het al iets beter. De tweede alinea is ook iets verbeterd, maar blijft problematisch. Uit het hele artikel maak ik op dat deze werkwijze niet zozeer bedoeld is om vanuit het niets een organisatie te ontwerpen, maar om een bestaande situatie te beschrijven, en vervolgens een gewenste situatie te ontwerpen. Verder zijn de vaststellingen wat mij betreft iets te stellig, ik zou zeggen poogt een kader voor verandering te bieden, en poogt richting te geven en handvatten te bieden. Het 'vaak gezien worden als een sturingsmiddel', trek ik ook in twijfel, ik had er nog nooit van gehoord. Verder valt op dat men zich op veranderen richt, alsof veranderen an sich iets oplevert. Daar staat tegenover dat ik nu al een jaar of tien het ene debacle na het ander zie ontstaan en zich voltrekken, als gevolg van iets waarvan ik nu weet dat men het Enterprise-architectuur kan noemen, dus die laatste zin is misschien toch juist. "Het begrenzen van ruimtes op een lager niveau zodat de veranderingen in lijn zijn met de doelstellingen van de organisatie", is abacadabra, beter schrappen.

Voor de tweede alinea stel ik dus voor:

"Enterprise-architectuur beschrijft de bestaande situatie, en poogt met haar ontwerp van de gewenste situatie een kader voor verandering te bieden. Enterprise-architectuur probeert dus richting te geven en handvatten te bieden voor het toetsen van veranderingen. Enterprise-architectuur wordt dan ook vaak gezien als een sturingsmiddel om veranderingen door te voeren."

Onder Jip en Janneke-taal versta ik iets anders dan je, (denk ik), bedoelt, ik ben niet bang van een moeilijk woord of een lastige formulering, mits dat gepast en noodzakelijk is. Juist in dit soort onderwerpen ontspoort het taalgebruik nogal eens, omdat het de schrijver zelf niet duidelijk is wat nu eigenlijk de kern van de zaak is. Verderop gaat het mis met een raamwerk, de betekenis daarvan verandert in de loop van het verhaal, daar kom ik later op terug. Groet, Vier Tildes 20 nov 2009 21:40 (CET)

Een andere invulling

Ik ben begonnen, dit artikel een andere invulling te geven. Verder commentaar, correcties en aanvullingen zijn daarbij zeker welkom. -- Mdd 22 nov 2009 22:11 (CET)

De opening

Ik heb de opening aangepast, maar over die (nieuwe) opzet ben ik echter nog niet erg tevreden. Om te beginnen wil ik de verschillende openingen eens de revu laten passeren, die dit artikel al heeft versleten.

Dit artikel begon 12 feb 2007 met:

• Enterprise architecture is de discipline die zich bezig houdt met het vanuit de ondernemingsdoelstellingen in samenhang ontwerpen van de structuur en het gedrag van een organisatie in al haar aspecten waaronder producten, processen, organisatie, informatie en informatietechnologie.

Dit is dan verder uitgewerkt tot (22 aug 2007):

• Enterprise architecture is de discipline (of het vakgebied) die zich bezig houdt met het vanuit de strategische ondernemingsdoelstellingen in samenhang ontwerpen van de kwalitatief gewenste functie, vorm, structuur en het gedrag van een onderneming of een bedrijf (die beiden organisaties zijn) in al haar aspecten waaronder producten, services (diensten), processen, organisatie, informatie en informatietechnologie.

En niet veel later (zie hier vereenvoudigd tot:

• Enterprise architecture is het vakgebied dat zich bezig houdt met het in samenhang ontwerpen van de organisatie in al haar aspecten.

Recentelijk is dit omgewerkt tot:

• Enterprise-architectuur of ontwerp voor organisatiestructuren en/of informatiestromen (Eng.: enterprise architecture) is het vakgebied dat zich bezighoudt met het ontwerpen van een organisatie.

En hier heb ik nu van gemaakt (met enige verbetering van ErikB:

• Enterprise-architectuur (Eng.: enterprise architecture) is een benaming voor het "geheel van een onderneming", en een gelijknamig opkomend vakgebied van informatica en bedrijfskunde dat dit geheel wil bestuderen. Dit vakgebied richt zich in het bijzonder op het optimaliseren van de ontwikkeling en aanwending van informatietechnologie en informatiesystemen in organisaties.

In dit geheel vind ik mijn nieuwe opening nog niet echt een verbetering. Wat ik wel goed vind is dat ik de vakdisciplines gespecificeerd heb, en een concrete doelstelling heb geformuleerd. Misschien kan het vereenvoudigd worden tot:

• Enterprise-architectuur (Eng.: enterprise architecture) is een opkomende informatica discipline gericht op het optimaliseren van informatietechnologie en informatiesystemen in organisaties.

De eerste definities geven in mijn ogen vooral aan wat men zou willen dat AE is. Met de laatste definitie(s) wil ik graag benaderen wat het werkelijk is. -- Mdd 24 nov 2009 11:34 (CET)

Sectie "Raamwerken" verwijderd

Ik heb de volgende sectie verwijderd:

Onderdeel van het werk van de 'architect' is het ontwerpen van structuren van bedrijfsafdelingen. Die raamwerken hebben doorgaans twee dimensies, soms aangevuld met een extra derde dimensie om bijvoorbeeld thema's als informatiebeveiliging erbij te betrekken. Zo'n structuur kan een handig hulpmiddel zijn dat de bouwmeester ondersteunt in zijn werk, vooral bij het beschrijven van en communiceren over het ontwerp. Een raamwerk brengt de beschrijvingen visueel in kaart.

De raamwerken kunnen onder meer helpen om:

• de volledigheid van een architectuurbeschrijving te borgen
• de samenhang in een ontwerp expliciet te maken
• 'blinde vlekken' in het ontwerp te ontdekken
• architectuurbeschrijvingen beter overdraagbaar te maken

Er zijn vele ontwerpmogelijkheden. Welke structuur het meest geschikt is, verschilt per organisatie. Er zijn bijvoorbeeld raamwerken waarin de verschillende deelontwerpen en bouwstenen van een organisatie centraal staan, maar ook raamwerken waarin specifiek aandacht besteed wordt aan belanghebbenden (planner, eigenaar, architect, aannemer, onderaannemer e.d.). Andere structuren laten het tijdsverloop terugkomen om de dynamiek van het ontwerp inzichtelijk te maken.

Aan het gebruik van structuren kleven ook nadelen, zoals:

• bijzondere gevallen die over het hoofd worden gezien
• belangen die uit het oog worden verloren
• overbeschrijven
• oversimplificeren
• te vroeg of te laat beschrijven
• visualisatie een lagere prioriteit geven dan beschrijvingen.

Voorbeelden van bekende raamwerken zijn:

• Het Zachman-raamwerk
• Het TOGAF-raamwerk
• Het DYA-raamwerk
• Het IAF-raamwerk
• De architectuurmatrix uit de Nederlandse Overheids Referentie Architectuur (NORA)

En wel om de volgende redenen:

• Deze tekst gaat over Enterprise-architectuur raamwerken >> raamwerken zijn een elementair onderdeel van de discipline. Zachman - die het begrip heeft uitgevonden kwam direct met een raamwerk. TOGAF recenter staat voor The Open Group Architecture FRAMEWORK. Oftewel haal ajb niet zomaar iets weg zonder eerst research te doen.
• Zo'n onderwerp moet je voor een lekenpubliek niet zomaar gaan afkorten tot "raamwerk", zonder enige tekst of uitleg vooraf. >> zit wat in dus dat kan beter
• Dit onderwerp past wel in dit artikel, maar een stukje als deze dient eerst uit te leggen >> punt is duidelijk
  • Wat het is? Waar het vandaan komt? Wat het doet? ... etc
• Het spreken van "architect" of zelf "bouwmeester" is hier echt niet op zijn plaats. Het zijn volgens mij informatie-analysten of organisatie-adviseurs, die zich met dergelijke zaken bezig houden. >> argument is niet feitelijk. Er zijn veel volledige functies Enterprise Architect. Google bv. op vacature en Enterprise Architect en overtuig jezelf. Wederom, doe nu eerst wat research voordat je een artikel sloopt. Dit motiveert niet om bij te dragen.

ER is nog wel meer, maar daar kom ik later nog wel op terug. -- Mdd 25 nov 2009 02:22 (CET)

Hierboven in >> reageer ik graag op je motivatie

Jip en Janneke taal

De afgelopen maand ben ik met Jos van Boston bezig geweest om dat artikel wat minder abstract te maken, waarbij we besloten hebben een en ander uit te leggen.

• Zoals de herkomst van het begrip architectuur
• Redenen voor de opkomst van EA in de 1980er jaren, meer dan dat John achman een eerste artikel schreef.

Met de recente wijziging(en) zie hier van een anon lijken we weer terug bij af.

• Die aanvullingen zijn veelal verwijderd
• En er zijn weer van de fantastische nietzeggende zinnen voor teruggekomen als: Enterprise-architectuur biedt organisaties een kader voor veranderen, neergeslagen in een samenhangende en consistente beschrijving van de gewenste situatie op hoofdlijnen. Deze beschrijving biedt harde en zachte grenzen die de ontwerpruimte op lagere niveaus zodanig in probeert te perken dat de veranderingen in lijn zijn met de doelstellingen van de organisatie als geheel. Enterprise-architectuur geeft daarmee richting en biedt concrete handvatten voor het toetsen van veranderingen. Enterprise-architectuur wordt dan ook vaak gezien als een belangrijk stuurinstrument.

Ik was eigenlijk in de veronderstelling, dat we dit soort opgeklopte lucht niet meer in Wikipedia dulden. De anon is waarschijnlijk een student of expert, die de hedendaagse literatuur goed heeft gelezen... en daar alles van heeft geloofd zoals dat er "EA afdelingen" in bedrijven zijn ontstaan. Is dat wel zo? wat hij kennelijk geen kaas van heeft gegeven is EA uitleggen tegenover het "Jip en Janneke" publiek.

Ik kan het hier helemaal mis hebben. Ik wil geensinds beweren, dat we al een geweldig artikel geschreven hadden. Hiervoor moet nog een hoop gedaan worden. Maar de laatste veranderingen lijken mij hierbij een grote stap terug...!? -- Mdd 9 dec 2009 22:32 (CET)

Met alle respect maar enkele suggestieve opmerkingen in dir overleg slaan nergens op. Jip-en-Janneke OK, daar kan nog zeker het nodige aan gebeuren. Maar kwalificaties als 'opgeklopte lucht' zijn natuurlijk niet constructief. Daarnaast geeft de auteur blijk van onkunde met de twijfel inzake Enterprise Architectuur afdelingen. Lees bijvoorbeeld de interviews op http://www.via-nova-architectura.org/de-architect-antwoordt/de-architect-antwoordt/index.php en http://www.via-nova-architectura.org/de-cio-spreekt/de-cio-spreekt/index.php

Dus met klem het verzoek om niet te editen op stukken waar de kennis niet aanwezig is. Zet - bij twijfel - zo nodig opmerkingen als <eenvoudiger formuleren> of <literatuurverwijzing> en laat het invullen dan aan anderen. Op deze wijze kost het veel minder energie om er een behoorlijk artikel van te maken.

User:85.146.98.126 10 dec 2009 23:20 (CET)

Correctie op links

Ik merk dat onderstaande links ten onrechte zijn verwijderd. Het betreft hier stuk voor stuk links die relevant zijn voor het vakgebied. Het zijn drie links (GIA, NGI en NAF) naar de relevante gevestigde - not for profit - beroepsverenigingen. Een link naar het door deze verenigingen onderstaande - not for profit - portaal (van Stichting Digital Architecture) en naar een belangrijk - open - standaard (inmiddels geratificeerd door The Open Group). Oftewel deze horen bij dit artikel.

Externe links

• Genootschap van InformatieArchitecten
• Nederlands Architectuur Forum
• Nederlands Genootschap van Informatici - afdeling Architectuur
• Via Nova Architectura
• ArchiMate (en)

Laten we eerst maar eens proberen een behoorlijk artikel te schrijven. In Wikipedia dient dit te berusten op betrouwbare bronnen en die externe links zijn maar bijzaak. -- Mdd 10 dec 2009 23:49 (CET)

Onderbouwing niet voor het basisartikel

Om te voorkomen dat er weer zaken worden verwijderd die wel berusten op waarheid stel ik voor om hieronder links te sparen met bewijsvoering, bv.:

architectuur binnen financiële instellingen: http://www.ing.com/cms/idc_cgi_isapi.dll?IdcService=GET_FILE&dDocName=073956_EN&RevisionSelectionMethod=latestReleased – De voorgaande bijdrage werd geplaatst door 85.146.98.126 (overleg · bijdragen)

Wat bedoel je met je voorstel "om hieronder links te sparen met bewijsvoering"? En wat mag dat voorbeeld dan wel aantonen? -- Mdd 12 dec 2009 12:41 (CET)

Ik wil graag een rubriek waarin we VOOR verwijdering of grove edit de auteur van de oorspronkelijke tekst de kans geven om eerst bewijs te leveren voor gemaakte claims. Overigens ook omdat links onder het basisartikel vaak rücksichtslos worden weggegooid.

Hierboven wordt bijvoorbeeld in twijfel getrokken of er Enterprise Architectuur afdelingen bestaan "daar alles van heeft geloofd zoals dat er "EA afdelingen" in bedrijven zijn ontstaan". Dat vraagt om bewijsvoering.

Zie bijvoorbeeld ook http://www.via-nova-architectura.org/de-architect-antwoordt/de-architect-antwoordt/index.php waarin verschillende chief / lead / hoofd etc. van architectuurafdelingen het woord doen.

Oftewel er zijn zeker EA afdelingen bij financiële instellingen (al dan niet onder deze letterlijke naam) bij o.a.: ABN Amro, ING, Rabobank, Achmea. Overigens zijn er ook buiten de financiële instellingen veel bedrijven met een aparte (Enterprise) Architectuur afdeling. Binnen enkele instellingen bestaat deze afdeling al vanaf midden jaren negentig (of mogelijk zelfs daarvoor).

Is deze wijze van inspringen met de dubbele punten overigens goed gebruik? Slaat dit ergens op, of is er een beter alternatief? Ik heb ook maar een gebruikerspagina aangemaakt onder pseudo Eek

Hoi Eek, eerst maar de huishoudelijke mededelingen: die dubbele punten zijn goed, maar je kan gewoon ondertekenen met de vier tildes (~~~~) en dan genereerd het programma automatisch een gebruikersnaam + datum + tijd.

Verder kort over die EA afdelingen. Ik weet best wel dat sommige experts zich tegenwoordig enterprise architect noemen en dat er op IT en beleidsafdelingen over EA gesproken wordt... maar je kan niet hier schrijven, dat EA afdelingen algemeen gebruikelijk zijn in bedrijven zoals bv personeelsafdelingen, financiele afdelingen of een technische dienst dit wel zijn. Schrijven dat het wel zo is, is in mijn ogen wishful thinking. Zover is het nog helemaal niet.

Maar je hebt veel grotere probelem. Na mijn commentaar van 9 dec 2009 hierboven komt nu een andere gebruiker genaamd Marrakech met een zelfde commentaar, zie hier, waarin hij dus beweerd:

zeer onduidelijk artikel. Na lezing weet je nog niet wat de term enterprise-architectuur precies inhoudt. Uit de eerste alinea zou je kunnen opmaken dat het iets betekent als: ervoor zorgen dat een organisatie zich op alle niveaus in dezelfde richting ontwikkelt, maar dat blijft noodgedwongen giswerk. Verder wemelt het van de tautologische en ondoorgrondelijk geformuleerde passages. Neem deze zin: "Deze samenhang wordt verkregen door een groot aantal aspecten van de organisatie in beschouwing te nemen en aan elkaar te relateren". Eigenlijk staat daar: deze samenhang wordt verkregen door samenhang aan te brengen in een groot aantal aspecten van de organisatie. Of deze zin: "Dit ontwerp, dat voor de gehele organisatie geldt, probeert de ontwerpruimte op lagere niveaus zodanig in te perken (...)". Met andere woorden: het ontwerp probeert zijn eigen ruimte in te perken. Of deze: "De doelstellingen van de organisatie als geheel worden vertaald in een beschrijving van de gewenste organisatie-inrichting gezien vanuit de verschillende aspecten". Doelstellingen die worden vertaald in een beschrijving van de inrichting gezien vanuit aspecten - kan het nog vager? Het antwoord is ja. Verderop in de tekst is er sprake van een referentiekader voor implementatieprojecten. Encyclopedische artikelen moeten duidelijk en concreet zijn. Aan dat criterium voldoet dit artikel (vooralsnog) niet.

Het verschil is dat hij dit artikel meteen maar op de verwijderlijst hebt gezet... wat betekent, dat het over twee weken in z'n geheel wordt verwijderd indien er niets wordt verbeterd.

Ik begrijp dat jij heel wat ervaring in de praktijk hebt, zoals je hier aangaf. Op de Engelse Wikipedia heb ik al heel wat over dit onderwerp geschreven, zie bv hier. -- Mdd 14 dec 2009 23:04 (CET)

N.a.v. het commentaar hierboven. Wat het precies inhoudt zal nog wel even duren (het is een relatief jong vakgebied). Enkele punten zijn denk ik relatief eenvoudig te verhelpen. Maar daar wil ik wel even de tijd voor nemen. Daarnaast is het vakgebied ook wel een beetje 'vaag' dat gaan we vrees ik niet in een wikipedia artikel oplossen. Groet, Eek 15 dec 2009 14:57 (CET)

Nieuwe poging

Ik heb een nieuwe poging gedaan om de eerste alinea ook voor leken leesbaar te maken. Ik ben nog niet helemaal gelukkig met de formulering. Een eerste steekproef (van 1) in de huiskamer was positief ;-).

"Enterprise-architectuur (Engels: Enterprise Architecture) is een jong vakgebied dat zich bezig houdt met de analyse en ontwerp van organisaties. Het vertrekpunt zijn de lange termijn doelstellingen van de organisatie. Het doel van enterprise-architectuur is de complexiteit van de organisatie beter te begrijpen en kaders te scheppen om deze te beheersen. Hierbij worden alle aspecten van de organisatie-inrichting betrokken waaronder de processen, de informatievoorziening en de IT. Om de complexiteit te beheersen worden richtinggevende afspraken gemaakt en worden er tekeningen gemaakt van de gewenste situatie. Enterprise-architectuur geeft daarmee richting en biedt concrete handvatten voor het toetsen van veranderingen." Groet, Eek 17 dec 2009 22:50 (CET)

Welke "complexiteit", wat betekent dat?

Stratologie is de een jong vakgebied dat zich bezig houdt met de analyse en het ontwerp van mobiliteit. Het vertrekpunt is de langetermijn doelstelling van de mobiliteit. Het doel van stratologie is de complexiteit van mobiliteit beter te begrijpen en kaders te scheppen om deze te beheersen. Hierbij worden alle aspecten van de mobiliteitsfactoren betrokken waaronder de middelen van verkeersrichtingen, de afstanden en de vervoermiddelen. Om de complexiteit te beheersen worden richtinggevende afspraken gemaakt en worden er tekeningen gemaakt van de gewenste situatie. Stratologie geeft daarmee richting en biedt handvatten voor het toetsen van nieuwe wegen.

Blufdeskundigheid, met ingewikkelde formuleringen de indruk wekken over een theorie te beschikken die toepasbaar is op een organisatie, en die alleen door ingewijden toegepast kan worden om de organisatie "beter" te maken. Daarom zijn de formuleringen zo ingewikkeld, en tegelijkertijd nietszeggend. Groet, Vier Tildes 18 dec 2009 01:14 (CET)

Vier Tildes. Wat een onzin reactie. Dit is een serieus vakgebied en geen bluf. Het kan best dat je je twijfels hebt, maar staaf dit dan ajb met de praktijk. Ik verwijs je hierbij naar een serie interviews met zowel CIO's als architecten waaruit je zelf kunt concluderen dat je reactie kant-nog-wal raakt. Het doel moet niet zijn om jou te overtuigen maar om een helder artikel te schrijven. Doe ajb constructieve verbetervoorstellen. Jouw reactie is respectloos. 85.146.98.126 18 dec 2009 23:02 (CET)

Eek (=85.146.98.126), al ben je Jaap zelf, of een discipel van hem, ik heb inderdaad geen enkel respect voor waarzeggers, wichelroedelopers en andere zwamneuzen die met mooie praatjes anderen willen overbluffen. Je zou niet de eerste zijn die met een toga om uit zijn nek staat te kletsen voor een publiek van Hooggeleerden. Ik heb wél serieus willen bijdragen aan een goed artikel over dit onderwerp, maar hier gebeurt hetzelfde als met alle andere moeders die hun baby beschrijven: het moet met pracht en praal, het is de mooiste baby op aarde. Je hebt aangegeven een specialist te zijn op dit gebied, en je hebt, dan weer als Eek, en dan weer als 85.146.98.126, meer dan eens anderen willen overbluffen met grootspraak in de zin van "ik ben de specialist, ik weet hoe het zit, jullie onwetenden moeten mij niet voor de voeten lopen". Ik heb er geen vertrouwen meer in dat je kan bijdragen aan een evenwichtig artikel. Als dat niet mogelijk is, dan mag de troep van mij de vuilnisbak in. Groet, Vier Tildes 18 dec 2009 23:52 (CET)

Mede gezien zijn volgende uitspraak vraag ik me in gemoede af of Eek wel de aangewezen persoon is om dit artikel naar een aanvaardbaar niveau te tillen:

"Wat ik onbegrijpelijk vind is dat het criterium voor het verwijderen blijkbaar is dat het door iedereen begrepen moet worden. Ik geef toe dat het artikel nog zeker beter kan, maar ik ben er vrij zeker van dat zelfs de huidige versie heel behoorlijk weergeeft waar het in ieder geval voor degene[n] die iets dichter bij het onderwerp staan over gaat."

Encyclopedische artikelen moeten begrijpelijk en toegankelijk zijn voor de geïnteresseerde leek, niet alleen voor 'degene[n] die iets dichter bij het onderwerp staan over gaat'. Dat is een fundamenteel punt en het is een veeg teken dat Eek dat niet lijkt in te zien.

Verder is Vier Tildes' bijdrage hierboven wel degelijk constructief. Aan de hand van een ludiek voorbeeld toont hij precies aan waar het in het artikel aan schort. Ook ik heb nog steeds de indruk dat met veel gepuf en geblaas wordt verhuld dat enterprise-architectuur eigenlijk iets heel eenvoudigs is: ervoor zorgen dat een organisatie zich in al haar geledingen in dezelfde richting ontwikkelt. Marrakech 19 dec 2009 07:51 (CET)

Een opmerking als "Blufdeskundigheid" is niet constructief wat mij betreft. Ik heb me stevig ingespannen om het artikel een stapje verder te brengen en ben er vrij zeker van dat het nu een heel stuk beter is dan voorheen. En ja... het kan waarschijnlijk nog beter. En ja.. het zou goed zijn als ook even een andere deskundige ernaar kijkt (maar graag iemand die veel ervaring heeft in het vakgebied omdat het anders - denk ik - eenvoudigweg lastig is om voldoende dicht bij de werkelijkheid te blijven). Hierbij is het wel - en ik spreek uit ervaring - van belang dat de deskundige een beetje begrijpt wat de intentie is. Het risico is anders heel groot dat het artikel weer terug gaat richting de gangbare definities in het vakgebied (terug bij af). Ik voel me zeker gestimuleerd door inhoudelijke kritiek op de tekst zelf (ook door Marrakech en Vier Tildes) vandaar ook dat ik er nog de nodige energie in heb gestopt. Ik zal nog eens een keer kijken naar het ludieke trucje om te snappen waar de kritiek nu nog zit. Dit trucje hoeft overigens helemaal niet per definitie iest te zeggen (probeer het maar eens op wat andere artikelen). En ik zal ook nog eens kijken of er in eerdere pogingen nog herbruikbare suggesties zitten. Tot slot is er een belangrijk verschil tussen 'de geïnteresseerde leek' en voor iedereen. Ik onderstreep helemaal dat het leesbaar moet zijn voor 'de geïnteresseerde leek' (dat zijn vaak mensen die iets dichter bij het vakgebied staan). En vervolgens is er nog een belangrijk verschil tussen 'de geïnteresseerde leek' en alle geïnteresseerde leken. De reden dat er soms Eek en soms een ip adres staat is eenvoudigweg omdat ik soms vergeet aan te loggen (dit is geen trucje of zo). Groet, Eek 19 dec 2009 15:21 (CET)

lol... ik ben geen discipel van (die) Jaap. Ik denk overigens dat hij niet zo vrolijk zal worden van deze referentie. Ik heb wel veel op met (deze) Jaap. Maar ik betwijfel of hij veel op heeft met Enterprise-architectuur. Vier Tildes ik heb ook je gebruikerpagina bekenen (wordt daar overigens niet helemaal wijs uit met al die verschillende ID's) en zie dat je wel vaker denigrerende opmerkingen maakt. Een stijl die mij wat minder aanspreekt (maar nu kan ik je wat beter plaatsen). De reden dat ik anoniem bijdraag heeft overigens juist te maken met het gegeven dat het te vaak over de ego's gaat dan over de inhoud. Ik hoop op een beetje begrip; maar nu ik je wat beter kan plaatsen begin ik te vermoeden dat mijn hoop misplaatst is. Groet, Eek 19 dec 2009 15:46 (CET)

Overigens zijn de quotes niet correct (en buiten context altijd gevaarlijk) "ik ben de specialist, ik weet hoe het zit, jullie onwetenden moeten mij niet voor de voeten lopen".Groet, Eek 19 dec 2009 15:50 (CET)

Helaas kan ik - na bestudering - van het stratologie grapje niet de vinger leggen op het bedoelde probleem. Als stratologie zich zou richten op de mobiliteit voor grote complexe gebieden dan zou dit een aardig begin kunnen zijn voor een lemma hierover.Groet, Eek 19 dec 2009 16:13 (CET)

In de opmerking van Marrakech 19 dec 2009 07:51 (CET) staat een uitstekende suggestie. Ik heb deze verwerkt in de tekst (van dezelfde heb ik gewenste gemaakt).

Dit is de bluf die ik bedoel, "in de zin van" schreef ik, dus niet letterlijk: "Dus met klem het verzoek om niet te editen op stukken waar de kennis niet aanwezig is. Zet - bij twijfel - zo nodig opmerkingen als <eenvoudiger formuleren> of <literatuurverwijzing> en laat het invullen dan aan anderen. Op deze wijze kost het veel minder energie om er een behoorlijk artikel van te maken".

"Beste, op verzoek wil ik me graag even mengen in de bewerking van het artikel Enterprise-architecture. Ik heb het hele vakgebied vanaf midden jaren 90 zeer actief mee mogen maken en ben voor meerdere organisaties verantwoordelijk geweest als (chief / lead / etc.) enterprise architect".

"Daarnaast overweeg ik om een door mij zelf aangebracht artikel maar van wikipedia te laten verwijderen omdat waarschijnlijk goedbedoelende maar niet kundige auteurs er niet in slagen het artikel verder te brengen...een stapje vooruit en dan weer twee achteruit... grrr... op zo'n manier gaan we nooit een fatsoenlijke encyclopedie krijgen (althans niet op dit lemma)".

"Ik kan zo een hele groep mensen mobiliseren om voor te gaan stemmen".

De vraaggesprekken waar je met links naar verwijst, en die moeten aangeven hoe serieus het allemaal wel niet is, zijn tenenkrommende marketingtoneelstukjes, zoals je die alleen maar in reclamefolders aantreft. ("en, vertel eens Bill, hoe werkt deze ongelooflijk handige Masterchef pannendekselhouder?") Het valt op hoe noodzakelijk je het kennelijk vindt om te benadrukken dat dit 'not for profit'-organisaties zijn, zie je werkelijk niet hoe dat in elkaar zit? Groet, Vier Tildes 19 dec 2009 18:15 (CET)

Vier Tildes er is geen woord bluf bij. Ik heb eenvoudig weg vanaf midden jaren 90 ervaring in het vakgebied; in verschillende rollen en meermalen in leidinggevende functies. Ik zie niet zo 123 waarom je hier aan zou willen twijfelen. Wat ik aan heb proberen te geven (maar blijkbaar lukt me dat heel slecht) is dat ik van mening ben dat het voor leken op het betreffende gebied niet eenvoudig is om een feitelijk artikel te schrijven over een vakgebied; dit vereist op zijn minst dat ze zich heel goed in moeten lezen (zeker op een jong vakgebied als dit waar het heel lastig is om feit en fictie uit elkaar te houden). Wel zie ik veel meerwaarde in leken (op het betreffende vakgebied) die kritiek leveren op een artikel door (bij voorkeur op de overlegpagina) aan te geven dat ze iets niet begrijpen. Ook kunnen leken teksten uitstekend redigeren.

Ik kan me vergissen, maar quotes gebruik je in citaten en niet in de zin van (lees je eigen suggestieve interpretatie). De vraaggesprekken waar naar wordt verwezen zijn van organisaties die hier serieus in investeren (en ze zijn ook niet uitsluitend positief, lees bijvoorbeeld de kritieken op de beoefenaars).

Wederom geef je blijk geen enkel respect te hebben voor betrokkenen door ze "tenenkrommende marketingtoneelstukjes" te verwijten. Het zijn onder meer interviews met CIO's van gerenommeerde organisaties; alleen als ze de meerwaarde zien zullen ze hierin investeren. Vanwaar je sceptisme? Kortom ik begrijp je redenatie in het geheel niet.

Natuurlijk is het van belang kritisch te zijn; het vakgebied staat nog in de kinderschoenen en de doelstellingen worden zeker niet altijd gehaald. Een ander punt van kritiek dat ik zou kunnen ondersteunen is dat het artikel nu nog teveel de indruk wekt dat het richting geeft voor alle aspecten. (inmiddels heb ik hier iets aan gedaan). De realiteit is dat het richting geeft aan de informatievoorziening en de IT (wel vaak in de context van de organisatiestructuur en de processen).

Enterprise-architectuur heeft zeker niet alleen voordelen voor 'profit' organisaties. Sterker nog het zijn de 'not for profit' organisaties (overheden) die heel veel investeren in enterprise-architectuur (in Nederland bv. de NORA, MARIJ en GEMMA als referentie-architecturen voor enterprise-architectuur binnen overheidsorganisaties) en in de US (heb ik minder kennis over, maar de TOGAF bv. heeft haar roots in de overheid).

Ga je overigens nog moeite nemen om je startologie grapje uit te leggen? Groet, Eek 19 dec 2009 20:57 (CET)

Onderzoekers Jeanne Ross en Peter Weill hebben veel onderzoek gedaan naar enterprise-architecture. Lees bijvoorbeeld het artikel over enterprise architecture as strategy. Ze vragen aandacht voor het begrip Target Operating Model. Hierin staan de mate van integratie en standaardisatie centraal. Is zeker niet een op een geschikt voor dit artikel, maar zitten nog wel bruikbare elementen in. Verder ben ik van mening dat deze opvattingen zijn niet 1:1 reflecteren hoe we in NL tegen dit vakgebied aankijken. Groet, Eek 19 dec 2009 21:59 (CET)

Ultieme poging voor de intro

Ik heb onder aanmoediging van Viert Tildes en Marrakech en met hulp van Mdd een - voor mij - ultieme poging gedaan. Ik kom op de volgende intro:

Enterprise-architectuur (Engels: Enterprise Architecture) is een jong vakgebied dat zich bezig houdt met de analyse en het ontwerp van organisaties.

Het doel van enterprise-architectuur is ervoor te zorgen dat een organisatie zich in al haar geledingen in de gewenste richting ontwikkelt. Dit vakgebied wil de complexiteit van de organisatie beter begrijpen en schept kaders om met name de ontwikkeling van de informatievoorziening en de ondersteunende informatietechnologie te beheersen. Het begrip wordt onder meer verkregen door de relaties tussen de organisatiedoelstellingen, de producten, de organisatiestructuur, de processen, de informatievoorziening en de informatietechnologie te analyseren en te ontwerpen. De kaders bestaan uit richtinggevende afspraken en tekeningen van de gewenste situatie.

Ik heb nieuwe (inhoudelijke) kritieken nodig om deze intro nog verder te verbeteren. Al ben ik er zelf inmiddels tevreden over. Merk op dat het van binnenuit (het vakgebied) niet altijd even eenvoudig is (getuige de hele stapel aan definities die binnen het vakgebied circuleren). Ik kan het waarderen als we vanaf nu weer even terugkeren tot het artikel (met een beetje geluk vanaf de intro). Mijn excuses aan degene die zich hebben geërgerd aan mijn expertise-claim; aanstoot geven was niet mijn intentie. Overigens krijg ik het vermoeden dat er nog een heleboel aanpalende artikelen zijn die een stevige redactieslag kunnen gebruiken (bv. Informatie-infrastructuur en Informatie-architectuur). Groet, Eek 20 dec 2009 11:19 (CET)

Verder heb ik het stuk processen even geparkeerd. Hier is nog wel een stevige slag op nodig om te voldoen aan de criteria.

Bij de inrichting van de enterprise-architectuur als organisatiediscipline worden de volgende processen onderscheiden:

• Bepalen scope en visie
• Inrichten van de besturing (ook wel: enterprise architecture governance)
• Opstellen en onderhouden van het structuurontwerp
• Formaliseren van het structuurontwerp
• Communiceren over de architectuurproducten
• Inbedden van het gebruik
• Toezicht op de naleving

- De voorgaande niet ondertekende opmerking werd toegevoegd door Eek (overleg|bijdragen) 20 december 2009

Dag Eek, ik waardeer je nieuwe poging, maar de inleiding is nog steeds te veel een grabbelton van abstracte termen die maar geen duidelijk geheel willen vormen. De volgende vragen en opmerkingen borrelden bijvoorbeeld in me op (geen uitputtende opsomming):

• Wat voor kaders? Geef daar eens een zo concreet mogelijk voorbeeld van.
• Informatievoorziening: wat voor informatie? Van wie? Aan wie? Waarover?
• De zin "Het begrip wordt onder meer verkregen door de relaties tussen de organisatiedoelstellingen, de producten, de organisatiestructuur, de processen, de informatievoorziening en de informatietechnologie te analyseren en te ontwerpen" bevat onder meer de volgende informatie: je krijgt inzicht in de complexiteit van een organisatie door de relaties tussen de producten en de processen te ontwerpen. Wat betekent dat? Hoe kun je ergens inzicht in verwerven door iets — in dit geval relaties — te ontwerpen? En wat houdt dat precies in — relaties ontwerpen?

Het is vaak een goed idee om bij het schrijven een bepaalde lezer voor ogen te houden, bijvoorbeeld een nieuwsgierige havo- of vwo-leerling. Denk je dat hij of zij na lezing van jouw intro werkelijk begrijpt wat enterprise-architectuur behelst?

Ten slotte: klopt mijn volgende interpretatie?

Enterprise-architectuur (Engels: Enterprise Architecture) is een jong vakgebied dat als doel heeft ervoor te zorgen dat een organisatie zich in al haar geledingen in de gewenste richting ontwikkelt. Gezien de complexiteit van veel organisaties is dat geen geringe opgave. Enterprise-architecten proberen daarom een beter inzicht te verkrijgen in de manier waarop de verschillende organisatie-onderdelen op elkaar ingrijpen, zodat zij kunnen voorkomen dat deze langs elkaar heen werken.

Groet, Marrakech 20 dec 2009 22:14 (CET)

Dank voor je kritieken; daar kan ik zeker iets mee. Je interpretatie klopt grotendeels. Twee punten:

Het gaat niet zozeer over de organisatie-onderdelen (ik lees dit als business units, directies, afdelingen, etc.) maar om de verschillende aspecten (in het vakgebied concerns).

Het is van belang om de scope helder te maken; het gaat in de praktijk meestal om in volgorde van voorkomen 1) de informatietechnologie, 2) de informatievoorziening en 3) de processen. Soms ook de organisatiestructuur en producten.

Ik ga ermee aan de slag. En ga zo weer inloggen, Groet Eek 85.146.98.126 21 dec 2009 10:34 (CET)

Het wordt beter, maar zoals het er nu staat, is het net alsof die invalshoeken op elkaar inwerken, wat me nogal zonderling voorkomt. Verder zou ik de inleidende alinea zo algemeen mogelijk houden. De specifieke afdelingen/onderdelen/geledingen kunnen later wel genoemd worden. Ik geef maar weer even een voorzetje:

Enterprise-architectuur (Engels: Enterprise Architecture) is een jong vakgebied dat als doel heeft ervoor te zorgen dat een organisatie zich in al haar geledingen in de gewenste richting ontwikkelt. Gezien de complexiteit van veel organisaties is dat vaak geen geringe opgave. Enterprise-architecten proberen daarom beter inzicht te krijgen in de manier waarop de verschillende onderdelen op elkaar ingrijpen, en vervolgens maken zij een beschrijving en tekeningen van de gewenste situatie, die als leidraad dienen voor de hele organisatie. Op die manier kan worden voorkomen dat de afzonderlijke onderdelen langs elkaar heen werken.

Overigens kan ik me moeilijk voorstellen dat dit allemaal zo nieuw is. Vroeger moesten bedrijven er toch ook op toezien dat de ene afdeling niet iets ondernam wat haaks op de activiteiten van een andere afdeling stond? Groet, Marrakech 21 dec 2009 16:44 (CET)

Het probleem waar enterprise-architectuur een antwoord op zoekt is de gebrekkige afstemming tussen de business aspecten enerzijds en de IT aspecten anderzijds (in de Angelsaksische literatuur het Business-IT alignment probleem). IT en business moeten in samenhang worden ontworpen; ze grijpen op elkaar in. Daarnaast speelt ook het probleem van 'misalignment' tussen verschillende onderdelen van de organisatie (bv. bij internationale bedrijven de verschillende landenorganisaties). In de praktijk heeft dit erin geresulteerd dat er vaak grote (onnodige) versnippering is ontstaan in de IT-landschappen (bv. in grote banken gaat het dan om duizenden IT-systemen). Het gevolg daarvan is dat IT niet zozeer de organisatie helpt, maar in toenemende mate een blok aan het been is geworden. Voor wat betreft vroeger. Is een beetje afhankelijk van wanneer vroeger begint. Enterprise-architectuur is ontstaan uit de informatieplanningsaanpakken (bv. BSP dat ergens begonnen is in de jaren '70). Overigens wijst dit overleg erop dat er nog behoorlijk wat verbetering mogelijk (nodig) is om tot een echt goed lemma te komen. Groet, Eek 21 dec 2009 20:55 (CET)

Gezien de complexiteit is dat geen geringe opgave.

De zinsnede "Gezien de complexiteit ... is dat geen geringe opgave" is practisch op ieder wetenschappelijk onderwerp van toepassing en daarom een loze opmerking, en daarom hier verwijderd. Maar ja... helaas toch weer teruggezet. -- Mdd 21 dec 2009 17:07 (CET)

O, bedoel je dat. Dan ben ik bang dat je niet precies weet wat een broodjeaapverhaal is, namelijk iets heel anders dan een 'loze opmerking'. Maar goed, als je die zin opnieuw wilt verwijderen heb je van mij geen tegenkanting meer te verwachten. Marrakech 21 dec 2009 17:18 (CET)

Vereenvoudiging van de verschillende gebruiken van de term enterprise-architectuur

Ik heb de overzicht paragraaf toch een beetje vereenvoudigd. In de praktijk zien we inderdaad dat de term enterprise-architectuur gebruikt wordt om 1) het proces, 2) de beschrijving van de enterprise-architectuur, 3) de enterprise-architectuur zelf en 4) het vakgebied aan te duiden. Echter 1) en 2) zijn eigenlijk afkortingen en er zijn ook alternatieven beschikbaar.Groet, Eek 22 dec 2009 14:56 (CET)

Aspect / invalshoek / gezichtspunt / perspectief

Ik wil graag één term consistent in het artikel gebruiken om de verschillende aspecten / invalshoeken / gezichtspunten aan te duiden. In de NL praktijk kom ik met name aspect en gezichspunt tegen. Lastig om de knoop te hakken. Als we dicht bij de termen in het vakgebied willen blijven dan is gezichtspunt waarschijnlijk de beste keuze. Groet, Eek 22 dec 2009 14:56 (CET)

Lastige zin

Ik ben nog niet helemaal gelukkig met 'Principes zijn richtinggevende afspraken die een overtuiging weergeven over de wijze waarop de gewenste situatie bereikt kan worden.'. Te abstract (al hoop ik dat de voorbeelden een beetje helpen). Suggesties zijn welkom. Groet, Eek 22 dec 2009 14:56 (CET)

Dat is inderdaad een wel erg abstracte formulering. Het grootste probleem is dat het woord 'principe' een betekenis krijgt opgedrongen die het in het normale spraakgebruik niet echt heeft.

Ik heb het wiu-sjabloon overigens weggehaald, omdat ik wel de indruk heb dat het de goede kant op gaat met dit artikel. Groet, Marrakech 22 dec 2009 18:19 (CET)

Dank voor het vertrouwen Groet, Eek 22 dec 2009 19:38 (CET)

Principe zoals hier bedoeld komt redelijk overeen met value. Groet, Eek 22 dec 2009 19:38 (CET)

Dit is nog steeds reclame en wensdroom

De pretenties zijn wat minder geworden, dat is mooi, maar 'not for profit' bestaat eenvoudigweg niet in de adviesbranche. Het hele stuk is nog steeds reclame, in dit geval voor bedrijfskundige adviseurs die zich in het bijzonder op de toepassing van informatica in bedrijven richten. Alle betrokkenen die ik kan natrekken zijn zelfstandige adviseurs, en hebben dus belang bij een 'neutraal' stukje over dit onderwerp, maar vooruit.

Deze passages zijn wat mij betreft nog steeds reclame, bladvulling en wensdroom:

"Rond de eeuwwisseling ontstaan er in Nederland verschillende vakgenootschappen die zich met het onderwerp enterprise-architectuur bezig houden waaronder: het Genootschap van Informatie Architecten (GIA), het Nederlands Architectuur Forum (NAF), en de afdeling 'architectuur' van het Nederlands Genootschap voor Informatica. Het Landelijk Architectuur Congres (LAC) is een belangrijke motor achter het vakgebied. Het eerste LAC wordt georganiseerd in 1998. In 2006 wordt Via Nova Architectura opgericht met als doel om de primaire informatiebron te worden voor (enterprise-)architecten in het veld."

"Het gespecialiseerd beroep van enterprise architect wordt hierbij steeds gangbaarder."

Het is geen toeval dat de omschrijving in de eerste instantie zo ruim mogelijk moest zijn, al die adviseurs doen namelijk hetzelfde: ze willen zich profileren met een mooie kreet als Enterprise-architect, maar tegelijkertijd willen ze geen kansen missen dus moeten ze toch van alle markten thuis zijn. Het is dan ook geen verrassing dat de Genootschap van Informatie Architecten gevestigd is op hetzelfde adres als de Orde van Organisatiekundigen en ‑adviseurs.

De voorbeelden van 'principes' zijn eenvoudige uitgangspunten van een basisregistratie, die ken ik al heel lang, lang voordat ik van enterpraaisarsjitektuur gehoord had. Met uitzondering van de aangehaalde passages, kan het er mee door. Groet, Vier Tildes 23 dec 2009 01:42 (CET)

Ik begrijp je opmerking met betrekking tot 'not for profit' niet.

• Als je bedoelt dat er adviesbureau's zijn die for profit advies geven over enterprise-architectuur geven dan heb je helemaal gelijk. Hetzelfde is van toepassing voor heel veel vakgebieden (inclusief de bouwarchitectuur).
• De passage die je aanhaalt met o.a. GIA, NAF, NGI en Via Nova Architectura zijn stuk voor stuk verenigingen / stichtingen. Van het NAF zijn er 33 leden "gebruikers"organisaties en 13 "wetenschap en onderwijs".
• Enterprise-architecture heeft haar roots in de US (DoD) en speelt ook in Nederland een belangrijke rol (bv. NORA, MARIJ, GEMMA).

Voor wat betreft je opmerking m.b.t. principes zie ik de relevantie niet. De claim is niet dat deze principes zo nieuw zijn. Als je verwijst naar de GBA (als basisregistratie) dan klopt het dat dit mogelijk relevante principes zijn. De praktijk is - ook in het huidige stelsel - dat het nog niet zo eenvoudig is om een architectuur te maken op basis van deze (en de nieuwe NORA) principes. Kijk bijvoorbeeld naar de discussie rond de modernisering van de GBA.

Tot besluit: Enterprise-architect is een baan die je steeds vaker (of juist) ziet binnen "gebruikers"organisaties.

Groet, Eek 23 dec 2009 22:19 (CET)

Dat een organisatie kiest voor de rechtsvorm 'vereniging' of 'stichting' zegt niets over zijn of haar bedoelingen. Denk aan de Bovag of de ANWB, verder is het zo dat multinationals dankbaar gebruik maken van de Nederlandse wetgeving op dit gebied om via stichtingen (een gedeelte van) hun winst belastingvrij weg te sluizen. Wanneer een aantal adviseurs een coole naam voor hun werkzaamheden kiest, en een vereniging of stichting opricht om de kennis te delen, werkt die vereniging of stichting ook als een promotievehikel, zelfs als niet hardop gezegd wordt, of in de statuten vermeld wordt. Zolang die vereniging of stichting alleen maar bekend is bij de mensen die erbij betrokken zijn, of een hele kleine kring er omheen, lijkt me opname in een encyclopedie voorbarig. Ik sluit niet uit opname gewenst wordt om bekend te wórden, zoals we dat dagelijks tientallen keren zien gebeuren. Dit jonge vakgebied moet zich nog maar even ontwikkelen, dan komt de Bovag van Enterprise-architecten (GIA), en het vakblad vol reclame (Via Nova) vanzelf ook in beeld. Dan kan ook een buitenstaander beoordelen of er steeds meer aandacht voor het vak van Enterprise-architect ontstaat. Groet, Vier Tildes 25 dec 2009 16:20 (CET)

Ik deel je mening dat een rechtsvorm niet alles hoeft te zeggen over de bedoelingen. Dit vereist meer kennis van de betreffende organisatie. Wel is het bij wet zo dat een stichting / vereniging niet het maken van winst tot doelstelling mag hebben en dat de winst ten goede moet komen aan respectievelijk een ideëel of sociaal doel / het gemeenschappelijke doel. Er zullen vast wel mazen in de wet zitten die door multinationals worden gebruikt, maar in deze context lijkt me deze opmerking niet op zijn plaats. Ook de rest van je opmerkingen zijn suggestief en doen denk ik geen recht aan de intenties van betrokkenen. Zoals ik het beleef ga je respectloos om met mensen die zich inspannen voor de goede zaak. Heel jammer dat je de (jonge) NL geschiedenis van dit vakgebied niet geschikt acht voor wikipedia. En spijtig voor de geïnteresseerde leek die nu half wordt geïnformeerd. Ik laat het er maar even bij, want het kost me allemaal veel te veel moeite. Ook ben je erin geslaagd om me te demotiveren om voorlopig aan andere artikelen te werken. Maar als ik je inmiddels een beetje in kan schatten dan vind je dat helemaal niet jammer. Jij wint Groet, Eek 28 dec 2009 15:56 (CET)

De schrijver heeft drie jaar geleden een onleesbaar promopraatje geplaatst, en zich nooit om iets anders bekommerd, maar nu ineens grote krokodillentranen! "Zo wil ik niet meer bijdragen aan deze encyclopedie!" De schrijver zet zich in voor "de goede zaak", hoera, zij het "met veel moeite", oei oei, wat een zelfopoffering! De teleurstelling is dan ook groot, wanneer zijn goede intenties zo misverstaan worden. Vervolgens geeft de reclamemaker zich gewonnen, ik moet maar raden naar de betekenis. Het lijkt me dat deze bizzniss-verzinsels, zo ingewikkeld en nietszeggend als ze zijn, alsnog verwijderd kunnen worden, aangezien de aanmaker kennelijk niets meer in de huidige versie ziet. Verwonderlijk is dat niet, aangezien de beoogde zelfpromotie niet wilde lukken. Dan maar liever niets, zo maak ik uit zijn woorden op, is er nog iemand die hier iets nuttigs in ziet? Gelukkig nieuwjaar, Vier Tildes 1 jan 2010 03:39 (CET)

Beste Vier Tildes. Keer op keer verkies je provocatie en suggestie. Je aanhoudende kritiek dat het gaat om reclame is eenvoudigweg niet terecht. Dit is de originele versie. Met heel veel fantasie zou je het reclame voor een vakgebied kunnen noemen. Maar dan hebben we het niet meer over reclame in de normale betekenis van het woord. Als je consequent bent dan zou je ook artikelen over bijvoorbeeld cognitieve psychologie reclame kunnen noemen.

Als ik vervolgens kijk naar de verschillen met de huidige versie dan zijn er voor wat betreft de inhoudelijke strekking geen significante verschillen (de leesbaarheid is wel stukken beter geef ik toe).

Voor wat betreft het bekommeren om. Ik geef direct toe dat ik nog geen groot bijdrager ben op wikipedia. Wat niets hoeft te zeggen over de intentie om wat meer bij te dragen. Ik was overigens net gestart me ook over verwante artikelen te bekommeren (die het veel harder nodig hebben zoals bv. informatie-architectuur). Maar na je aanhoudende weinig constructieve kritieken zakt mij de moet eenvoudigweg in de schoenen. Ik heb geen enkele zekerheid dat je daar niet op dezelfde wijze je vernietigende activiteiten voort gaat zetten.

Voor wat betreft de "goede zaak" bedoel ik beroepsverenigingen als NGI, GIA en NAF. Als het gaat om jouw respectloosheid dan bedoel ik bijvoorbeeld je opmerking in de context van Jaap (Schekkerman) "ik heb inderdaad geen enkel respect voor waarzeggers, wichelroedelopers en andere zwamneuzen die met mooie praatjes anderen willen overbluffen". Niet alleen bevestig je zelf dat je moeite hebt met respect maar doe je er direct nog een schepje bovenop. Leuk voor een duister forum, maar wat mij betreft wikipedia onwaardig.

Ik kan er vanuit mijn eigen belang prima mee leven als dit artikel van wikipedia wordt verwijderd. Als ik redeneer vanuit het algemeen belang (de reden waarom ik destijds met dit artikel ben gestart) dan denk ik dat er nog behoorlijk wat artikelen ontbreken (vergelijk maar eens wat er over dit en aanpalende vakgebieden is geschreven op de Engelstalige wikipedia). Wat ik wel persoonlijk jammer zou vinden is dat Enterprise-architectuur alleen vanuit de Amerikaanse zienswijze in wikipedia belicht wordt. Hier heeft in mijn optiek de Nederlandse wikipedia juist haar meerwaarde.

Overigens heb je nog steeds moeite om netjes te citeren en heb ik je inderdaad goed ingeschat; het lijkt wel een doel om auteurs te demotiveren. Groet, Eek 1 jan 2010 15:14 (CET)

Wie kan er overigens mijn argument beter bevestigen dan minister Ter Horst over bijvoorbeeld het NAF. 85.146.98.126 2 jan 2010 21:35 (CET)

Kennelijk vindt ieder van ons dat we de ander goed hebben ingeschat, en dat de ander ons niet goed heeft ingeschat. Dat je het filmpje van Ter Horst als argument gebruikt, bevestigt mijn vermoeden dat je met promopraatjes bezig bent, immers, op dat moment heeft ze het boek nog niet gelezen, en wie weet of ze het ooit leest. Wie weet of ze zich überhaupt nog kan herinneren waar het over ging tijdens die bijeenkomst? (Bijeenkomst van het NAF: De missie van het NAF is het bevorderen van het werken onder architectuur en het bevorderen van de professionaliteit van architecten in de wereld van organisatie en IT.) Wat zou ze anders moeten zeggen daar op dat podium? "Ik heb niets begrepen van waar jullie het over hebben, maar veel geluk ermee"? Verder zou het me niet verbazen als ook zij gewoon over een zin als

"Deze beschrijving biedt harde en zachte grenzen die de ontwerpruimte op lagere niveau's zodanig in probeert te perken dat de veranderingen in lijn zijn met de strategie van de organisatie als geheel"

heen zou lezen, zonder zich te realiseren dat dat onzin is. Politici zijn zeer gevoelig voor mooie praatjes. Dat er mensen bezig zijn met dit onderwerp, en zelf denken dat het heel wat is, is duidelijk, daarom mag het ook een plaatsje hebben in deze encyclopedie. Ik heb mij bezig gehouden met het fatsoeneren van het stukje, zodat er niet meer gesuggereerd wordt dan er werkelijk is. Dat je als afsluiting huilerig komt melden dat ik zo'n gemenerik ben, die als hoofddoel zou hebben om anderen te demotiveren, en dat jij daar erg door getroffen bent, bevalt me niet zo. Groet, Vier Tildes 3 jan 2010 16:05 (CET)

Laat ik beginnen met je laatste opmerking; ‘bevalt me niet’. Deze komt mij enigszins hypocriet over voor iemand die meermalen op onfatsoenlijke wijze de aanval heeft ingezet (ik citeer nog maar even ‘blufdeskundigheid’, ‘waarzeggers, wichelroedelopers en andere zwamneuzen’ ‘met een toga om uit zijn nek staat te kletsen voor een publiek van Hooggeleerden’ ‘overbluffen met grootspraak’, ‘tenenkrommende marketingtoneelstukjes’, ‘huilerig’). Maar afgaande op je allereerste bijdrage op deze overlegpagina ben ik er wel van overtuigd dat je in aanleg bij hebt willen dragen aan een beter artikel. Je volharding op de overlegpagina onderstreept dit. Al kan ik er inhoudelijk weinig / niets mee (bv. je 'stratologie' voorbeeld). Overigens was mijn eerste kritiek gericht op deze versie. Hierin zaten eenvoudigweg teveel onjuistheden. Vandaar dat ik een eerdere (inderdaad – naar ik nu inzie - te abstracte en onvoldoende scherpe) versie had teruggezet.

Waarom het niet opschiet tussen ons heeft mogelijk haar wortels in een relevante misvatting. Eerder gaf je aan de overtuiging te hebben dat “… ik nu al een jaar of tien het ene debacle na het ander zie ontstaan en zich voltrekken, als gevolg van iets waarvan ik nu weet dat men het Enterprise-architectuur kan noemen”. Om de jouw bekende debacles met terugwerkende kracht in de schoenen te schuiven van dit vakgebied lijkt me ongegrond en zeer waarschijnlijk onjuist (welke debacles heb je het over? kunnen we dit verifiëren?). Natuurlijk is lang niet ieder enterprise architectuur initiatief even succesvol; maar de schade blijft dan meestal beperkt tot de investering in de enterprise architectuur zelf (en vaak is dit leergeld om er vervolgens wel een succes van te maken). Sterker nog uit verschillende onderzoeken blijkt (en ga me ajb niet weer promotie verwijten want daar wordt ik echt moe van) dat enterprise architectuur een mogelijk middel is om debacles te voorkomen (zie bijvoorbeeld Ross).

Voor wat betreft het filmpje. Ik had wederom niet de intentie om reclame te maken (vandaar ook een filmpje van een minister en niet van zegge een CIO of een architect want deze wees je eerder al – onterecht – van de hand als reclame). Ik ken de herkomst van het filmpje niet, maar afgaande op de achtergrond is het waarschijnlijk geen bijeenkomst van het NAF (maar ik sluit dit niet uit, hoe kom je tot je conclusie?). Wat ik met het filmpje van minister Ter Horst wilde zeggen is niet dat het NAF nu zo’n goed boek heeft geschreven (ik heb het zelf niet gelezen). Als je goed luistert hoor je haar praten over een rapport van de rekenkamer. Een van de aanbevelingen van de rekenkamer (voor zover mij bekend geen politieke organisatie en ook geen commerciële organisatie) om debacles te voorkomen is om een gestandaardiseerde concern-informatiearchitectuur te ontwikkelen. De afgelopen jaren worden op dit gebied grote stappen gezet met onder meer NORA (overheid), MARIJ (rijksoverheid) en GEMMA (gemeente). Daarnaast heeft de minister het over de afspraken die in de ministerraad is gemaakt om binnen de overheid te gaan werken onder architectuur (deze afspraak heeft ze echt niet gemaakt omdat ze een boek van het NAF kreeg aangeboden). Of ze het boek wel of niet gaat lezen is voor hier geloof ik niet van belang (maar we mogen niets uitsluiten). Dat ze zich positief uitlaat over het NAF is natuurlijk gepast als je een boodschap inspreekt (maar niet verplicht) ze wijst daarbij op het algemeen belang dat door het NAF wordt gediend. Bij mijn weten is dit een terechte conclusie en ook niet verwonderlijk omdat verschillende overheden (15 en dan tel ik de wetenschap en onderwijsleden niet mee) lid zijn van het NAF.

Verder ben ik ervan overtuigd dat een belangrijke meerwaarde van wikipedia de externe links zijn naar kennisbronnen / vakorganisaties (dit kon niet zo eenvoudig met de klassieke encyclopedie). Veel lezers hechten hier geloof ik veel waarde aan.

Wat vinden andere lezers, wel of geen Nederlandse historie? wel of geen externe links naar beroepsverenigingen / kennisbronnen? Groet, Eek 4 jan 2010 21:48 (CET)

• Nu ga ik bijna huilen. Ik meld dat het me niet bevalt. Daar is niets hypocriet aan, dat kun je alleen maar voor kennisgeving aannemen.
• Je hebt alle lelijke dingen in ieder geval goed gelezen, zo reageer ik als iemand nadat het hem tien keer uitgelegd is, blijft volhouden dat één plus één iets anders dan twee is, of in elk geval iets anders zou kunnen zijn.
• Dit noem ik op huilerige toon beklag doen, te meer daar je je in drie jaar met niets anders als met dit onderwerp hebt beziggehouden, maar nu ineens, nadat ik zo onaardig ben geweest, niet meer aan andere artikelen zegt bij te willen dragen:

"Zoals ik het beleef ga je respectloos om met mensen die zich inspannen voor de goede zaak. Heel jammer dat je de (jonge) NL geschiedenis van dit vakgebied niet geschikt acht voor wikipedia. En spijtig voor de geïnteresseerde leek die nu half wordt geïnformeerd. Ik laat het er maar even bij, want het kost me allemaal veel te veel moeite. Ook ben je erin geslaagd om me te demotiveren om voorlopig aan andere artikelen te werken. Maar als ik je inmiddels een beetje in kan schatten dan vind je dat helemaal niet jammer. Jij wint"

• Jouw volharding op de overlegpagina's om de door jou geformuleerde nonsens te verdedigen onderstreept dat het meer om promotie van een marketingterm gaat dan om het algemeen belang.

• Ik hou je uitsluitend verantwoordelijk voor wat je hier schrijft. Nu je het zelf ter sprake brengt, je hebt naar eigen zeggen dit hele vakgebied al vanaf vanaf midden jaren 90 zeer actief mee mogen maken en je was voor meerdere organisaties verantwoordelijk als (chief / lead / etc.) enterprise architect, maar je was niet in staat om uit te leggen waar je al die tijd mee bezig was. De hulpeloze formulering waarmee je informatie denkt over te brengen doet me het ergste vrezen voor je capaciteiten om volgens de regels van de Enterprise-architectuur een model te formuleren. Het lijkt me goed goed mogelijk dat je voor debacles verantwoordelijk bent waar ik geen weet van heb, maar dat terzijde.

• De uitspraak: "maar de schade blijft dan meestal beperkt tot de investering in de enterprise architectuur zelf" is niet te onderbouwen met die enkele link, hoeveel indrukwekkende pijlschema's er ook in staan.

• Vanwege de zin waarmee je afsluit:"Wie kan er overigens mijn argument beter bevestigen dan minister Ter Horst over bijvoorbeeld het NAF", is het logisch dat ik veronderstel dat het een bijeenkomst van de NAF is. Om dan triomfantelijk te melden dat je zelf niet eens weet waar het vandaan komt, en ik dus zonder grond geconcludeerd moet hebben dat het van de NAF is, is een doorzichtige en zwakke poging om lezers te misleiden, door net te doen alsof je een sterk punt hebt. Je weet donders goed dat die vergissing van mij niet uitmaakt, het doet niet ter zake of dit een bijeenkomst van de NAF, de NUF, de BLAF of de BLUF is.

Het punt is dat een beleefd en aardig praatje van een politica op een van de vele bijeenkomsten waar ze haar dagen mee vult, helemaal niets bewijst.

• Dit is een, ik wil het nog wel een keer herhalen, tenenkrommend marketingtoneelstukje, maar jij voert dit aan om te laten zien dat het allemaal heel belangrijk is:

Daan: “In 2005 you introduced the HPW (High-Performance Workplace) as an architectural concept. Can you say something about the adoption in the market place?” ( Ik hoor het al: "..ken joe see somsing ahbaut zee adopsjion in zee marketplees?")

Tom: “HPW is a way of thinking about where and how to add value. ( "..eetsj pie wie iz ah wee of sinking ahbaut wèèrr ent hauw toe et veljoe..") It needs to be a search for an excellence to be obtained by best equipping your employees, particularly the highest impact ones, with tools and strategies to increase their impact further. HPW is not about squeezing out cost through automation (a noble goal that will persist). We have likely been too politically correct wrapping cost control and performance improvement in the same term.

Tot slot een tip: vraag nooit om de uitleg van een grap. Groet, Vier Tildes 6 jan 2010 01:22 (CET)

Reactie per punt.

Ik neem direct van je aan dat het je niet bevalt. Mij bevalt jouw bijdrage mogelijk nog veel minder. Het is hypocriet als je mij huilerigheid aanwrijft (na herhaalde onfatsoenlijke en suggestieve niet onderbouwde aanvallen) en vervolgens aangeeft dat een (ik geef toe beetje suggestieve) opmerking niet bevalt.

Blijkbaar wil jij mensen overtuigen op basis van je eigen zeer selectieve en niet onderbouwde werkelijkheid en dan blijf je maar doorbeuken totdat.. Tja totdat wat? Je legt niets uit je wekt suggestie en komt vervolgens met geen enkel bewijs voor je claims. Ik geloof dat ik dat wel netjes doe, maar dit bewijs veeg je met alle gemak van tafel als promotie. Onafhankelijk van de bron. Maar de bronnen zijn Chief Information Officers, architecten, onderzoekers, overheidsinstanties zoals de rekenkamer en een minister. En ja er zal best wel ergens een zinnetje in het vele materiaal te vinden zijn dat je uit zou kunnen leggen als promotie voor het vakgebied of een concept.

Prima. Jij mag denken dat ik een huiler ben die zijn beklag doet. Mijn doel is waarheidsgetrouwe content op wikipedia voor een vakgebied waaraan ik mij verbonden voel. Dat mijn initiële tekst niet jip-en-janneke was heb ik inmiddels meermalen aangeven en de laatste tekst is inderdaad stukken beter. Maar niet compleet! Dank voor de correcte quote (eindelijk). De inhoud mag je voor kennisgeving aannemen (zoals ik ook jouw emotie voor kennisgeving aan heb genomen). Wel jammer dat je daar allerlei op de persoon gerichte kwalificaties bij moet plaatsen.

Wat een onzin om te denken dat het mij op deze overlegpagina te doen is om reclame. Ik weiger eenvoudigweg om akkoord te gaan met een onvolledig artikel. Maar ik zal de stukken niet meer toevoegen; maak je geen zorgen. Dit had ik anders al lang gedaan. Ik wil graag van anderen horen of ze denken dat de NL-geschiedenis van dit vakgebied relevant is en of links naar beroepsverenigingen in deze context ook handig zijn. Ik zie dit ook bij andere artikelen (bv. Psychologie). Ik vind dit praktisch.

Ik ben gelukkig altijd prima in staat geweest om mijn werk te doen. Nog steeds. Dank voor je zorgen. Het is wel altijd lastig om het uit te leggen aan de geïnteresseerde leek (maar dat geldt voor een heleboel vakgebieden). Binnen het vakgebied hebben we talloze definities die binnen het vakgebied wel worden begrepen (al is er geen consensus over de definitie, maar ook dit is van toepassing op heel veel vakgebieden). Oh… het bevalt me overigens helemaal niet dat je nu ook nog eens een keer mijn competenties in twijfel moet gaan trekken. Voor je het weet ga je ook nog diploma’s vragen en referenties. Is er hier op wikipedia niet ergens een protocol dat dit soort beschimpingen aanpakt?

Voor wat betreft de onderbouwing van de meerwaarde heb ik ook andere bronnen aangebracht en er zijn er zeker meer. Kom jij nog met je bewijs dat jouw debacles toe te schrijven zijn aan Enterprise Architectuur? Lijkt me zeer interessant en om eerlijk te zeggen – als het zo is - heel waardevol voor de ontwikkeling van het vakgebied. Ook als dit betekent dat het zich op zou moeten heffen of moeten transformeren. Maar zo is het niet geloof ik.

En ik begrijp nu nog beter wat je bijdrage is. Je bent niet alleen bezig met suggestie en provocatie. Je bent ook nog eens de Max Tailleur van wikipedia (ik bedoel grappenmaker). Ik heb al eens eerder om je kunnen lachen (de 'lol' rond Jaap) en nu rol ik helemaal over de grond van het lachen. Derhalve is dit ook de laatste zin die ik zal besteden aan alle niet onderbouwde en niet op de inhoud gerichte opmerkingen. Noem het huilerig… noem het laf… mij maakt het niet meer uit. Dus leef je uit. Groet, Eek 6 jan 2010 22:59 (CET)

Vergelijking...

Als ik de lengte van het artikel vergelijk met de lengte van de overlegpagina, zou ik bijna denken dat het belang van het eerste ondergeschikt is aan het tweede. Verder vind ik de argumentatie her en der tenenkrommend. Ik wil me geen mening aanmatigen over het artikel, de encyclopedische waarde van het vakgebied of deze of gene bijdrager (aan zowel artikel als overleg), maar het lijkt me wenselijk dat de discussie bevrijd wordt van pejoratieven, beschuldigingen en verdere niet ter zake dienende opmerkingen.

Just my two cents, zoals dat heet. Kleuske 6 jan 2010 01:33 (CET)

Sectie over de standaard opbouw van AE

Ik heb de sectie over de standaardopbouw van AE teruggezet, zie hier om de in Overleg:Informatie-architectuur genoemde redenen. -- Mdd 20 jan 2010 18:21 (CET)

Deze sectie was een slordig ratjetoe en wemelt nu nog steeds van de spel- en taalfouten. Ik heb ze hieronder vet en cursief weergegeven. Bovendien mag Joost weten wat bijvoorbeeld het 'zienspunt van systemen' betekent. Vandaar voor de zoveelste keer het verzoek om alleen tekst (terug) te plaatsen die presentabel is. Marrakech 20 jan 2010 19:01 (CET)

Een veelgebruikt model splitst de enterprise-architecture in vier delen:

1. Business-architectuur
   1. Strategie-diagrammen, doelstellingen, bedrijfsregels, Operationele model.
   2. Functionele structuur, capaciteiten van het bedrijf, organisatiemodel
   3. Bedrijfsprocessen, workflow en de beschrijving van de zeggenschap, verantwoordlijkheid en regels voor de afdelingen.
   4. Externe leveranciers en partners, en hoe deze bedragen tot het functioneren van het bedrijf
2. Informatie-architectuur
   1. Metadata - gegevens die de dataelementen van het bedrijf beschrijft
   2. Datamodellen
3. Applicatie-architectuur
   1. Applicatiesoftware lijst van applicaties en diagrammen, vanuit het zienspunt van functionaleit of van systemen.
   2. Interfaces tussen applicaties - events, berichten, dataflow.
   3. Intranet, Extranet, Internet, e-commerce, EDI verbindingen met interne en externe gebruikers.
4. Technologie-archtectuur
   1. Hardware, platforms, en hosting: applicatieservers, en waar ze geplaatst zijn
   2. Local en wide area networks, Internet verbindingsdiagrammen
   3. Operating System
   4. Infrastructuresoftware: databaseservers, DBMS
   5. Programmeringstalen, etc. voor het gehele bedrijf of per afdeling

In dit raamwerk bepaalt de business-architecture de eisen voor de informatie-architecture, die met toenmende details de eisen voor de applicatie-architectuur bepaalt, waarna de applicatie-architectuur de gedetaileerd eisen voor de technologie-architectuur bepaalt.

Sommige modellen gebruiken een vijfde laag, door de informatie-architectuur verder op te splitsen door een data-architectuur in te voegen.

@Marrakech. Excuses voor de taalfouten in de oorspronkelijk tekst. Ik hoop ze nu gecorrigieerd te hebben. -- Mdd 20 jan 2010 20:50 (CET)

Er moet inderdaad nog even goed naar worden gekeken. Merk op dat er belangrijke verschillen zijn tussen informatie-architectuur en informatiesysteem-architectuur (in NL gebruiken we dit begrip overigens zelden op deze manier). Maar een kapstok is wel handig. Wat mij betreft ook eerst even op de OP tot overeenstemming komen. Groet, Eek 20 jan 2010 20:01 (CET)

Ik heb de sectie, zoals gezegd, een eerste stap uitgewerkt, en sta open voor verdere suggesties. -- Mdd 20 jan 2010 21:23 (CET)

Ik heb mijn suggestie direct verwerkt. Dit is in mijn optiek de meest neutrale kapstok (business, informatie en IT). Ik stel voor om eerst de betreffende artikelen over deze vakgebieden uit te werken en later eventueel een korte samenvatting hier toe te voegen. Groet, Eek 21 jan 2010 21:57 (CET)

Zie mijn reactie onder verder commentaar -- Mdd 21 jan 2010 22:32 (CET)

Opbouw van de beschrijving van deze fundamentele ordening

Een veel gebruikte gelaagdheid in enterprise-architectuur.

Een veelgebruikt model splitst de enterprise-architectuur in vier delen:

Business-architectuur

Dit wordt gebruikt wordt om informatietechnologie optimaal te integreren in een bedrijfsorganisatie. De business-architectuur bestudeert alle aspecten van de bedrijfsorganisatie, met het doel om beter te begrijpen hoe de informatietechnologie past in de algemene bedrijfsvoering. Het kan oa bestaan uit:

• Strategie-diagrammen, doelstellingen, bedrijfsregels, operationeel model.
• Functionele structuur, capaciteiten van het bedrijf, organisatiemodel
• Bedrijfsprocessen, workflow en de beschrijving van de zeggenschap, verantwoordelijkheid en regels voor de afdelingen.
• Overzicht van externe leveranciers en partners, en hoe deze bijdragen tot het functioneren van het bedrijf

Data-architectuur

Dit geeft een overzicht van de aanwezige en benodigde gegevens in een organisatie. Hetwordt bepaald door middel van analyse van de informatiebehoeften van een organisatie en wordt weergegeven met behulp van diverse modellen en technieken. Bij het beschrijven van de data-architectuur worden bijvoorbeeld de volgende 'artefacten' gebruikt. Dit kan bestaan uit:

• Metadata - gegevens die de dataelementen van het bedrijf beschrijven
• Datamodellen

Applicatie-architectuur

Dit beschrijft de samenhang van applicaties en informatiesystemen binnen een organisatie. Het is een modelmatige beschrijving van het applicatielandschap, de daadwerkelijk in productie zijnde systemen. Met oa.:

• Applicatiesoftware lijst van applicaties en diagrammen, vanuit het gezichtspunt van functionaliteit of van systemen.
• Interfaces tussen applicaties - events, berichten, dataflow.
• Intranet, Extranet, Internet, e-commerce, EDI verbindingen met interne en externe gebruikers.

Technologie-archtectuur

Dit is een geheel van inrichtingsprincipes en afspraken over de toe te passen van technologie

• Hardware, platforms, en hosting: applicatieservers, en waar ze geplaatst zijn
• Local en wide area networks, Internet verbindingsdiagrammen
• Operating System
• Infrastructuresoftware: databaseservers, DBMS
• Programmeringstalen, etc. voor het gehele bedrijf of per afdeling

In dit raamwerk bepaalt de business-architectuur de eisen voor de data-architectuur, die met toenemende details de eisen voor de applicatie-architectuur bepaalt, waarna de applicatie-architectuur de gedetailleerde eisen voor de technologie-architectuur bepaalt.

Sommige modellen gebruiken een vijfde laag, door de data-architectuur verder op te splitsen door een informatie-architectuur in te voegen.

Opbouw van het AE vakgebied

Binnen de enterprise-architectuur komen de volgende vakgebieden samen:

• business-architectuur
• informatie-architectuur
• IT-architectuur

Deze vakgebieden leggen zich toe op een deel van de enterprise-architectuur. Over de preciese inhoud van deze vakgebieden is nog volop discussie. Ook binnen deze vakgebieden zijn er nog verdere specialisaties. Daarvoor wordt verwezen naar de betreffende artikelen.

Naast de vakgebieden die zich toeleggen op een deel van de enterprise-architectuur zijn er ook nog vakgebieden die zich toeleggen op een aspect zoals beveiligings-architectuur.

Verder commentaar

Beste Eek, wat jij nou gedaan hebt is een beschrijving van de Opbouw van de beschrijving van deze fundamentele ordening vervangen door een beschrijving van de Opbouw van het AE vakgebied. -- Mdd 21 jan 2010 22:32 (CET)

Eens, opbouw van de architectuurbeschrijving is iets voor het lemma over raamwerken (wat je merkwaardig genoeg hebt aangemaakt onder view model). Het artikel gaat in eerste aanleg over het vakgebied -wat logisch is - dus een beschrijving van de vakgebieden die erin samenkomen (want dat is de praktijk) lijkt me voor de hand te liggen. Groet, Eek 21 jan 2010 22:59 (CET)

Ok, we zitten toch (gedeeltelijk) op één lijn. Alleen heb ik het artikel view model aangemaakt bedoeld als het Engelse en:Enterprise architecture framework, maar daarnaast gewoon als vertaling van het Engelse en:view model artikel.

In mijn ogen ontbreekt hier op de Nederlandse Wikipedia gewoon een artikel over Enterprise-architectuur framework, Enterprise-architectuur raamwwerk of kortweg architectuurraamwerk. Daar zou zo'n uitwerking over de "AE Opbouw van de beschrijving van deze fundamentele ordening" inderdaad kunnen passen. Ik zeg uitdrukkelijk kunnen... want in de Engelse artikelen is dat ook (nog) niet zo. Ik blijf er dus bij dat die opbouw hier in dit artikel besproken zou kunnen worden.

Los hiervan zou jouw uitwerking van de "Opbouw van het AE vakgebied" besproken kunnen worden. Op jouw uitwerking heb ik nog wel wat af te dingen, maar dat staat hier verder los van.

Dus, volgens mij kunnen beide hier nu besproken worden. -- Mdd 22 jan 2010 00:33 (CET)

Een artikel architectuurraamwerk is op zijn plek. Ik had hier eerder een stuk over geschreven, maar dit is weggesnoeid. Maar ik zie niet zo snel het verschil met view model (komt dit dan te vervallen?). Groet, Eek 22 jan 2010 19:58 (CET)

Een en:View model kan op zichzelf staan, zoals het en:Zachman Framework of deel zijn van een en:Enterprise Framework framework. Zo heb ik he in ieder geval op de Engelse wikipedia uitgewerkt. Kijk maar eens maar de documentatie van de DoDAF of FEAF. Die beslaat zo honderden pagina's en in dit geheel is het view model maar een onderdeel. -- Mdd 22 jan 2010 20:24 (CET)

Maar wat is dan het verschil tussen een view model en een framework?

Voor wat betreft de (architectuur) definities van perspectief, view, viewpoint (en de vertalingen in het Nederlands voor zover mogelijk) ben ik van mening dat het weinig zinvol is om op wikipedia te pogen deze Babylonische wirwar te ontwarren. Hier is geen enkele lezer mee geholpen. De meest relevante raamwerken kunnen wat mij betreft in het betreffende lemma onder externe links worden gezet. Het is dan aan de lezer om hier zijn oordeel over te vormen (het is niet anders). Eventueel zouden de voor de Nederlandse wikipedia belangrijkste raamwerken als apart lemma neergezet kunnen worden; maar persoonlijk ben ik daar geen voorstander van (te veel onderhoud, te veel promotie en te veel verwarring). Wat mij betreft dus een lemma over architectuurraamwerken, view model laten vervallen en niet te veel moeilijk doen over hetgeen allemaal is beweerd en geschreven. Groet, Eek 22 jan 2010 20:51 (CET)

Verder over architectuurraamwerk

In de allereerste versie staat een stuk over architectuur raamwerken. Wellicht nog te gebruiken voor een apart lemma. Groet, Eek 22 jan 2010 20:51 (CET)

Ter verduidelijking. Jij hebt die eerste versie geschreven, toch? En hierbij stel je het Zachman, TOFAG en NORA op één lijn. Op de Engelse Wikipedia probeer ik dit te voorkomen. Volgens mij zijn er namelijk ten minste drie lijnen:

1. Modellen die de benaderingen/aanzichten definieren, zoals en:Three schema approach, en:Zachman Framework, en:4+1 Architectural View Model
2. Raamwerken zoals DoDAF, TOGAF, FEAF, TEAF, DYA, NORA die een geheel van modellen, methoden en principes bieden
3. Generieke referentie architectuur zoals en:CIMOSA en en:GERAM

Die eerste klasse noem ik view modellen. Nou tracht ik die driedeling daar op de Engelse Wikipedia in stand te houden, maar dat betekent niet dat dit hier ook zo zou moeten zijn. Die drie zal ik echter nog steeds niet op een lijn plaatsen. -- Mdd 22 jan 2010 21:15 (CET)

TOGAF hoort inderdaad niet echt in het rijtje thuis. Deze had ik er omwille van de eenvoud - per slot van rekening laat framework zich vertalen als raamwerk - tussen gezet. De andere twee zijn overigens wel van een gelijke orde, ik heb het namelijk over de architectuurmatrix (en niet over de NORA zelf) en het Zachman raamwerk. Het praktisch nut van raamwerken is overigens voor discussie vatbaar, ik wil er dan zelf ook niet te veel tijd aan besteden. Groet, Eek 22 jan 2010 23:58 (CET)

Om dit voor nu af te sluiten heb ik die opzet in het artikel teruggezet. Wanneer er een opzet komt van een architectuurraamwerk artikel, kunnen we deze dingen wellicht verder bespreken. Ok? -- Mdd 23 jan 2010 00:17 (CET)

Ik ben nog niet enthousiast over het nieuwe plaatje (wat is de bron want ik herken het niet als een veelgebruikt plaatje). Ik mis in ieder geval de informatie-architectuur. Kijk ook nog eens even naar de andere twee plaatjes (wat mij betreft hebben we daar voor een lemma al meer dan voldoende aan; of vervang ze alle drie door een - abstracter maar wel correct - nieuw plaatje.Groet, Eek 23 jan 2010 22:41 (CET)

De huidige tekst rust nog steeds op het Engelse orgineel. Dit geheel mag je van mij aan (jou visie op) de Nederlandse situatie aanpassen. Bv door een informatie-architectuur laag toe te voegen. En dat plaatje zelf kunnen we ook vervangen. Succes ermee. -- Mdd 24 jan 2010 00:38 (CET)

Er bestaat geen standaard opbouw

Afgaande op de grote verzameling aan raamwerken lijkt het mij een utopie te denken dat er een standaard opbouw bestaat. Het lijkt me beter om een artikel te schrijven over raamwerken en daar de belangrijkste raamwerken (incl. de verschillende opvattingen over de opbouw van een architectuurbeschrijving) weer te geven. Het begin is gemaakt zie architectuurraamwerk.

Zoals gezegd heb ik in het Engelse en:Enterprise Architecture framework mijn opvattingen hierover uitgewerkt. Daar kunnen we wellicht enige zaken uit overnemen. Ik zal dit op de OP van het artikel zelf aankaarten. Succes daarmee. -- Mdd 24 jan 2010 00:41 (CET)

Ik heb inmiddels het lemma architectuurraamwerk denk ik op een acceptabel beginniveau gebracht. Daarmee wil ik voorstellen het stuk rond standaard opbouw hier te laten vervallen. Ik zie weinig toegevoegde waarde om hier een lijst van termen overeind te houden waar in de markt geen consensus over bestaat. Groet, Eek 25 jan 2010 21:26 (CET)

Dat lijkt me een slecht plan. Beide tekst is complementair en bijna niet overlappend. -- Mdd 25 jan 2010 21:32 (CET)

Derde betekenis van het begrip AE

Ik heb een derde betekenis van AE toegevoegd aan de algemene inleiding, waarmee de tekst wordt:

Het woord "Enterprise-architectuur" kan betrekking hebben op:

• de ordening van organisaties en de factoren die de ontwikkeling hiervan bepalen
• de afspraken over en inrichtingsprincipes van deze ordening, ook wel referentie architectuur genoemd
• en het vakgebied dat dit bestudeert

Deze drie betekenissen zie je in de Engelse taal ook terug. Ik heb echter zo'n vermoeden, dat dit weer op bezwaren gaat stuiten omdat hiermee het artikel het "Jip en Janneke-niveau" gaat overstijgen? -- Mdd 21 jan 2010 14:12 (CET)

Vaak wordt met Enterprise-architectuur bedoeld de beschrijving van de fundamentele ordening. Overigens is daar wel de nodige kritiek op te leveren; zo zal een bouwkundig architect de plattegrond niet snel de architectuur noemen, maar inmiddels is het wel ingeburgerd (in de IEEE 1471 staat het overigens wel correct). Referentie architectuur wordt op verschillende manieren gebruikt, maar meestal als voorbeeldarchitectuur voor een industrie (bv. de eTOM voor Telco's en de IAA voor de verzekeraars, de NORA voor de rijksoverheid in brede zin. Niet voor de modellen, principes en richtlijnen (dit zijn elementen van een architectuurbeschrijving). Groet, Eek 21 jan 2010 20:42 (CET)

Okee, bedankt. Je bent het dus wel eens met die driedeling. Ik ben het met je eens, dat hier best wel wat op af te dingen is. Het belangrijkste lijkt me dat we deze drie betekenissen toch expliciet onderscheiden hier. -- Mdd 22 jan 2010 02:16 (CET)

Gezichtspunten

Het huidige artikel, zie hier meldt nu:

De belangrijkste gezichtspunten zijn de processen, de informatievoorziening en de informatietechnologie.

Volgens mij worden deze zaken in de practijk niet zozeer als gezichtspunten gezien, en wordt onder gezichtspunten iets anders verstaan, bv de namen van de rijen en kollomen van het Zachman Framework. -- Mdd 22 jan 2010 11:48 (CET)

Zie mijn eerdere opmerking op deze pagina. Een gezichtspunt (gezicht is geen goed Nederlands) groepeert een aantal belangen (in dit geval die van - over voor het gemak op C-level de CEO / CIO / CTO). In het Nederlands laten view en viewpoint zich overigens niet zo handig vertalen. Dit zijn de definities uit de IEEE 1471:

• "view: A representation of a whole system from the perspective of a related set of concerns."
• "viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis."

Raamwerken bevatten inderdaad viewpoints (maar dit sluit het gebruik van dit woord niet uit in een andere - gelijkwaardige - context).Groet, Eek 22 jan 2010 19:29 (CET)

Hier nog een heleboel over views / viewpoints en frameworks. Eerlijk gezegd niet om vrolijk van te worden deze Babylonische smeltkroes. De praktijk is in mijn observatie dat alles door elkaar heen wordt gebruikt. Voor hier lijkt het me praktisch om gezichtspunt te hanteren omdat dit voor leken denk ik het best aangeeft waar het om gaat; verschillende manieren om naar de organisatie te kijken. Groet, Eek 22 jan 2010 19:56 (CET)

Ik lees net het lemma view model en kom daar de volgende zin tegen. "Bij software ontwikkeling is een "view" een "representatie van het gehele systeem vanuit een bepaald perspectief". Een enkele view op een bepaald systeem wordt wel een perspectief of "viewpoint" genoemd.". Dit maakt het er voor mij niet helderder op. Dit lijkt tenminste op een strijdigheid met bijvoorbeeld de IEEE 1471 (voor wat betreft "viewpoint").Groet, Eek 22 jan 2010 20:11 (CET)

Tja... Het artikel view model rust vooral op de eerste twee bronnen, die ieder de IEEE 1471 als uitgangspunt gebruiken. Dus die discrepatie kan ik ook zo snel niet verklaren. Misschien kunnen we dit beter ter plekke nog eens beter bekijken. Nu dit artikel beter geformuleerd is, kan wellicht dat artikel ook beter beschreven worden.

Terug naar dit artikel. Ik heb (om te beginnen) de betreffende zin anders geformuleerd. -- Mdd 22 jan 2010 20:50 (CET)

Ik heb geen harde voorkeur voor het een of het ander, maar een beetje consistentie door de verschillende architectuur artikelen hen kan denk ik geen kwaad. Daar kan nog het nodige aan worden verbeterd. Hier is het wat mij betreft nu in orde. Groet, Eek 23 jan 2010 00:03 (CET)

Bedankt, en ik ben het verder helemaal met je eens (zie ook OP Data-architectuur) -- Mdd 23 jan 2010 02:22 (CET)

grappig om te zien dat men hier op Wikipedia veelal dezelfde mening aanhangt als wat ik vind van deze architecturen. Ik word geacht hier mee te werken, maar het enige wat men voorschotelt is opgeklopte lucht waarbij je in 5 zinnen Bullshit bingo hebt uitgespeeld. Indien men serieus wil genomen als vakgebied dient men wellicht een stuk meer duidelijkheid neer te zetten zonder holle frasen en andere marketingonzin.

Je kan ook zelf meehelpen op deze pagina. Een dergelijk bericht als dit hier te plaatsen heeft geen nut, hier krijgen wij geen informatie mee. Dqfn13 19 okt 2010 16:51 (CEST)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 1 externe link(s) gewijzigd op Enterprisearchitectuur. Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• Archief https://web.archive.org/web/20140714073845/http://www.xr-magazine.nl/artikelen/287/methoden-tools/bouwen-aan-een-eigen-begrippenkader-referentiearchitectuur toegevoegd aan http://www.xr-magazine.nl/artikelen/287/methoden-tools/bouwen-aan-een-eigen-begrippenkader-referentiearchitectuur

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 7 mrt 2020 02:01 (CET)