September 2009: NGI-rapport "Wegwijzer voor methoden bij Enterprise Architectuur"

Info: Van Haren Publishing, 1e oplage, augustus 2009, ISBN 978-90-8753-097-6, diverse schrijvers NGI-werkgroep

Hoofdstuk 6: Methoden met elkaar vergeleken

In het algemeen

 

Opmerkingen

1. aaa
2. aaa
3. aaa

Amsterdams raamwerk voor informatiemanagement. Classificatie raamwerk. Vooral gebruikt bij het evalueren van bestaande situaties, maar ook omgezet in methoden
9-vlak een
ANSI/IEEE 1471-2000. Standaard
Archimate. Hulpmiddel gekoppeld aan TOGAF, zie hierna.
BIP. Business Informatie Planning van Novius Adviesgroep.
DEMO. Een methode voor het in kaart krijgen van de verschillende bedrijfsprocessen van een (deel van een ) organisatie.
Dragon1. Hulpmiddel. Uitwerking van de denk- en werkwijze van een persoon.
DYA. Zeer algemeen raamwerk waarbinnen IT-elementen ingepast kunnen worden.
IAF. Een door Capgemini op de markt gebracht classificatieschema. Een afgeleide van het Zachman framework
RUP: taal
TOGAF: Een door The Open Group, een commercieel samenwerkingsverband van de IT-leveranciers Capgemini, HP, IBM, NEC, SAP, Sun en HSBC-bank.
Zie een twee
Zachman. Door Zachman zelf een classificatieschema van XXXX genoemd.
Opmerkingen:
Wat opvalt is dat de meeste beschreven enterprise-architectuurmethoden elk iets nogal anders willen doen in de informatie- en IT-sector. Het is daarom sterk de vraag waarom voor deze methoden gekozen is, want omdat ze iets anders beogen zijn ze per definitie onvergelijkbaar. En dat is, zie de hoofdstukken 4 en 6, de bedoeling van dit rapport.
We spreken bij de 11 beschreven enterprise-architectuurmethoden feitelijk niet of nauwelijks over methoden of technieken:
Een methode wordt algemeen gedefinieerd als een verzameling van voorschriften en regels, die werkelijk worden gehanteerd of die gehanteerd zouden moeten worden bij het uitvoeren van wetenschappelijk onderzoek of bij het oplossen van praktijkproblemen. Een methode kan een reeks voorschriften bevatten voor de manier waarop een analyse wordt uitgevoerd, maar ook voor de aanpak van projecten, de manier van plannen, enz.
Een techniek is het "gereedschap" dat wordt gebruikt ter ondersteuning van het werken volgens een methode (of een onderdeel daarvan). Voorbeeld zijn diagrammen, tabellen, talen, enz., waarbij de specifieke syntactische regels (bijvoorbeeld "input boven de streep en output onder de streep") onderdeel van de techniek zijn.
Een hulpmiddel (of "tool") wordt gebruikt te ondersteuning van het werken met de methode en.of de techniek. Het kan om een potlood gaan, of om een template, software voor documentatie, ontwerp, realisatie enz.

Aardig is trouwens dat de termen methodiek en methodologie niet aan de orde komen. Een methodologie wordt ook als "de leer der methoden" uitgelegd, waarbij methoden voor theorievormend onderzoek worden bedoeld. De term methodiek wordt ook uitgelegd als "de leer der methoden". Een methodiek wordt gezien als een geheel van samenhangende methoden gericht op de oplossing van een bepaalde categorie van praktijkproblemen. Waar de term methodiek in het kader van praktijkproblemen gebruikt worden, worden methodologieen gebruikt voor theorieproblemen.
Het woord enterprise-architectuurmethoden en de context van deze wegwijzer voor de praktijk suggereert dat de beschreven methoden feitelijk methodieken zouden zijn. Gezien wat de beschreven enterprise-architectuurmethoden voorstellen en laten zien is geen van hen een echte methodiek. Sterker nog, sommige zijn puur een methode om een bepaald probleem op te lossen (zoals DEMO), andere zijn feitelijk technieken (zoals RUP) of gebaseerd op hulpmiddelen (Archimate en Dragon1). De meeste van de 11 beschreven enterprise-architectuurmethoden is een andere mix van bovenstaande termen uitgelegd worden. Geen van hen, hoewel enkele dat zullen beogen, is kompleet. Daarmee is feitelijk gezegd dat ze niet met elkaar te vergelijken zijn.
De schrijvers geven in hun tekst ook aan dat RUP, XXXXXXXXXXXXXX geen enterprise-architectuurmethode is. Waarom deze manieren van aanpak meegenomen zijn in dit rapport is daarmee een raadsel.
De spindiagrammen die gebruikt worden voor de "positionering" van de beschreven "methode". Ze geven echter nauwelijks informatie omdat de 11 vergeleken "methoden" niet of nauwelijks over hetzelfde gaan. Deze diagrammen kunnen daarom alleen waarde hebben als het doel van de enterprise-architectuurmethoden goed in acht gehouden worden. Het naast elkaar leggen van de spindiagrammen is verder volledig zinloos.
Het feit dat DEMO een werkwijze kent en daar dus sterk scoort is bijvoorbeeld onvergelijkbaar met dat RUP ook een werkwijze kent. De manier waarop bedrijfsprocessen aangepakt kunnen worden heeft immers niets te maken met de manier waarop RUP de werking van een te ontwikkelen IT-applicatie beschrijft. Vergelijk dit maar met boeken: het feit dat er een boek over de architectuur van Gaudi en een boek over bouwkundig ontwerpen bestaat zegt niets over waar die boeken voor bedoeld zijn en wat hun effect is. En datzelfde geldt voor denkwijze, representatie- en modelleerwijze, ondersteuningswijze, gebruikswijze, neheer- en exploitatiewijze gebruiker en beheer- en exploitatiewijze eigenaar. Steeds weer worden koeien en paarden vergeleken op een manier die vergelijkbaarheid minimaal suggereert.
A